Message ID | 20231125092137.2948-1-amit.kumar-mahapatra@amd.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp1828359vqx; Sat, 25 Nov 2023 01:22:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IH66pxCtuh3CKwsGYEpdTFYAIy/vCR94UukfhTBOa6SDYmAu+pt8mJn5EJnOZjcIbIMkKGq X-Received: by 2002:a05:6a21:3989:b0:186:ae16:103 with SMTP id ad9-20020a056a21398900b00186ae160103mr6081546pzc.30.1700904131359; Sat, 25 Nov 2023 01:22:11 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1700904131; cv=pass; d=google.com; s=arc-20160816; b=Whoxuqx1IwyCo09z5TXrcZcTOH0ylay1VKgQrIX1aAYeJncAyAelL9JdyRcDReN9v3 RnUPCnciIFx6gLqa8uZmPqRkhN4CwiJVat8Km7R+Njs3SSLLDG0RlFq4a+WUYMjfmbM7 gQWYQ/pm9jFiW12RKyqfCqK82sUPQK573QddxLSse+3sWbJe/JQdWVjFBZ1iQUEOkwXT G2jgER+R4OKbjrmCdNU6jV8NaFFGXh+/yCF+2u6KzWZOWQI5SSzv+lPN9J6xAsLui4Ow TpxVk3nlGnRTjC4SHB1Ngmv6aokxAI538CV1DgbDE9B6fWpCcos4KWWeEAmvEdJRu/IM F6ig== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=NOcXqCj/Ujdo7ubKiSjoRigKz4vONyHsJeJ/DMgGmdU=; fh=y/yQ0rKbc/fZLuaHDM+HICbyNQgL7C4dB1dwK2tYFEs=; b=rvV4T5aqF8l5ClXC4WVf2rgFK4hZ/84yODV7cRNFPMd+o2vj+DvfP5sV6JHtWGPY0o JTMf6besh+QFKq+UwH3UPKzL45tzQiH0OBPJcGS+ePU2i8oPkMoMeJ55vxVToii0EvD0 Kvim4ES7qkk0Jd+c2fZFoPdAE0WqhJgGHbHmx7K8ZyrTAOgXGQIUedLAFtMcCwq4dBJI 8+69yiQtMpk3DY1CH/djF1nsk7JUI1+ntG23ta056f5b7NCMeZTjyEIeMBhPrzUpfoT8 CjaJLDKfd544VyaDwxFvYYDBHrR8WMHZnwq6ghkKNfn8DCr3Z3rgExp9H27nJt3jJdSm pNfQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=yDrY78bt; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id nh12-20020a17090b364c00b00283a54ed475si5833732pjb.110.2023.11.25.01.22.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Nov 2023 01:22:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=yDrY78bt; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 0B661804039B; Sat, 25 Nov 2023 01:22:07 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231888AbjKYJVy (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Sat, 25 Nov 2023 04:21:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231908AbjKYJVt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 25 Nov 2023 04:21:49 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2063.outbound.protection.outlook.com [40.107.101.63]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88F0C1988; Sat, 25 Nov 2023 01:21:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jaH0UML3Ok5VkMJ08+qg7Gk8Gjbul0/DMeurEjFBCBOCxTndgRWA/vwdTRuf4kVCPGsPyrZh6ZuwKpXH1bUtpExzuSXrw26V2M+cEgiQVCwqTPdQYTSgNG9wndRf/2unk5mbhCc2JnyniumaNG/HPXbKBmArn5/+Yp834hsmmRcAp+lRaiPVLNqII/GbgECbtHQtjm64oEETRpk2wD3m8+UNGB7ileipPDxtVBB1BpTjsV+ZW5OuRSQcEJAZ27K+NXhy5rjTBqvlKRkcEJZW7436roU8HV4uFPY/L2m0FvJtI3yDZeE0nPM/SL/U2LxknlKibt3XFOW46O9qtHytqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NOcXqCj/Ujdo7ubKiSjoRigKz4vONyHsJeJ/DMgGmdU=; b=bj5EGfhPxFTpbRqXxeydPTL1kPVhnTiKt89pSwPO6Pw6siZwZ6AVozq5n0tDBd9/e838aIGSo9e21GQO5aEI1HOzwtg7kKig7EJw+3hegcZ5hlE7wUwhQ/VRD3p9vJZX6E0Cn+JD8r8S0PEp0SmezL3N5sNNLXTCGdK6bojHpDOghHPG1E9Ir/w/3u/dUxsNepvwTziXGIqvWeXwUAM3HHMT6Zy5exlGh6x3otzh1o6MW+4wSb3n5FHbu/QnRP5rzmIojACycZ+RXVn1hFbailjwuI+ioK0Rm85fsatbzzrAJAXEFOvYpxZvVZkyzsp86ahV9a8Mmq1YlBSZVgVR8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NOcXqCj/Ujdo7ubKiSjoRigKz4vONyHsJeJ/DMgGmdU=; b=yDrY78bt53PAcTlRXeB8FDj6J4I6wSJPQ9dO+/SXvIitVBlid5HbtKMBwFHXxav7oNdhLG62XnQFejptLV06gbKFycXO6kVMxkoql2oWLQj9tLPtAJoYLuG4v5gFlc6mqh9AnTgbIhoz9Pq13IGfFyE9oNN0ns45aRNY1LSQOg8= Received: from DM6PR06CA0062.namprd06.prod.outlook.com (2603:10b6:5:54::39) by BY5PR12MB4179.namprd12.prod.outlook.com (2603:10b6:a03:211::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.24; Sat, 25 Nov 2023 09:21:47 +0000 Received: from CY4PEPF0000E9D7.namprd05.prod.outlook.com (2603:10b6:5:54:cafe::ff) by DM6PR06CA0062.outlook.office365.com (2603:10b6:5:54::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.24 via Frontend Transport; Sat, 25 Nov 2023 09:21:47 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000E9D7.mail.protection.outlook.com (10.167.241.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7046.17 via Frontend Transport; Sat, 25 Nov 2023 09:21:46 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Sat, 25 Nov 2023 03:21:46 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Sat, 25 Nov 2023 03:21:45 -0600 Received: from xhdakumarma40u.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.34 via Frontend Transport; Sat, 25 Nov 2023 03:21:39 -0600 From: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> To: <broonie@kernel.org>, <tudor.ambarus@linaro.org>, <pratyush@kernel.org>, <miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>, <sbinding@opensource.cirrus.com>, <lee@kernel.org>, <james.schulman@cirrus.com>, <david.rhodes@cirrus.com>, <rf@opensource.cirrus.com>, <perex@perex.cz>, <tiwai@suse.com> CC: <linux-spi@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <michael@walle.cc>, <linux-mtd@lists.infradead.org>, <nicolas.ferre@microchip.com>, <alexandre.belloni@bootlin.com>, <claudiu.beznea@tuxon.dev>, <michal.simek@amd.com>, <linux-arm-kernel@lists.infradead.org>, <alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>, <linux-sound@vger.kernel.org>, <git@amd.com>, <amitrkcian2002@gmail.com>, Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Subject: [PATCH v11 00/10] spi: Add support for stacked/parallel memories Date: Sat, 25 Nov 2023 14:51:27 +0530 Message-ID: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D7:EE_|BY5PR12MB4179:EE_ X-MS-Office365-Filtering-Correlation-Id: 90b9c222-9a76-4186-eb47-08dbed97f2a8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QriRegH0EdXlaEFmG2V/BAjzuJ3Uts8uxf4hq38QZ84MiCgxyLCjC6YPFLznD7CIDsyS5QOdAdlFu0/Q74qttSxG/TInHOYLQEgne8jVke7ALHzZyCpt/X86sttIf9ASLbUKbR6GwMapOMIbVycvKCjXcbDqgJuCPqXbH/0bmgDHnqfqFHwgCySqVlej/+1I9h4qoN0ILVLC762s+tNR46PWnBJojPgwFKnWVIikYkgXRA4a+7HGXWnukIFRjSLA+QXajD+mAXVKL+HQhF59/y8IbqcC5bOm3iVBfXf9PHle+cLL++7xkcgT3a4OB6bEQ+h3quiomi0LSSXf8CDbbJs7qjhG0R7LJe3EGVcEx0QTGIzygaF3WyMyITriYfCSIZloGnu3Tj7gipEQaYg8N73+MhF+08ohjVjtltJayUp1Hr/oaQDon3WRm6A9aXmjMPXvdakJzrog1c0qxmV7F19wGKu6N+HCZ6ui5okiUP1poN/w7KvhDl99lArmgVHgBunU0H/2YJLHwGZXx1yKG6EgRkB/EI57skDg2+GC15R6oyLaJVlJSv3+0f48s/Qzi2YnqoC7JbI3a/Y/vEzKuePHaDT6jc2t9ANJthN56J7edNwQ2buv1Oz7fSzHsdLp2jBNNUh/zbsdTsGxw5oD5ncBqchT1b3lVSZnCJac5pjaLFxXW5Auxa5/Fvg/gVA+mEXHdsUtuKuRwRinmpVEhmepV37qW4VRUQ8dGwhcmannA3bqv71kLTCEemOwtCjYTNEJdgYh5x2ryDG+Ul83NJndfslHycXENEqFw4XrPlbfcZOzZyX2Nwcm4wAt/n15VGr79XP1JaaP7sdFyODwe3zvw3nNrCkMSgZKVcZNYS4= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(346002)(396003)(39850400004)(376002)(136003)(230173577357003)(230922051799003)(230273577357003)(1800799012)(64100799003)(82310400011)(451199024)(186009)(46966006)(36840700001)(40470700004)(2906002)(7416002)(70586007)(70206006)(110136005)(54906003)(41300700001)(8936002)(8676002)(316002)(478600001)(966005)(6666004)(5660300002)(4326008)(2616005)(336012)(426003)(26005)(1076003)(83380400001)(47076005)(40480700001)(36860700001)(86362001)(40460700003)(356005)(81166007)(36756003)(82740400003)(921008)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2023 09:21:46.8964 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 90b9c222-9a76-4186-eb47-08dbed97f2a8 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4179 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Sat, 25 Nov 2023 01:22:07 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783527250499345287 X-GMAIL-MSGID: 1783527250499345287 |
Series |
spi: Add support for stacked/parallel memories
|
|
Message
Mahapatra, Amit Kumar
Nov. 25, 2023, 9:21 a.m. UTC
This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support. The first nine patches https://lore.kernel.org/all/20230119185342.2093323-1-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-2-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-3-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-4-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-5-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-6-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-7-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-8-amit.kumar-mahapatra@amd.com/ https://lore.kernel.org/all/20230310173217.3429788-9-amit.kumar-mahapatra@amd.com/ of the previous series got applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next But the rest of the patches in the series did not get applied as failure was reported for spi driver with GPIO CS, so send the remaining patches in the series after rebasing it on top of for-next branch and fixing the issue. CS GPIO is not tested on our hardware, but it has been tested by @Stefan https://lore.kernel.org/all/005001da1efc$619ad5a0$24d080e0$@opensource.cirrus.com/ --- BRANCH: for-next Changes in v11: - Rebased patch series on top of latest for-next branch. - Added a new patch(1/10) to replace spi->chip_select with spi_get_chipselect() call in tps6594-spi.c. - Added a new patch(2/10) to replace spi->chip_select with spi_get_chipseletc() call in cs35l56_hda_spi.c. - In spi.c initialized unused CS[] to 0xff and spi->cs_index_mask to 0x01 in all flows. - Updated spi_dev_check() to compare the CS of old spi device with the new spi device CS. - Updated cover letter description to add information regarding GPIO CS testing and added Stefen's Tested-by tag in 3/10 patch. Changes in v10: - Rebased patch series on top of latest for-next branch and fixed merge conflicts. Changes in v9: - Updated 1/8 patch description to add an high-level overview of parallel(multi-cs) & stacked design. - Initialized all unused CS to 0xFF. - Moved CS check from spi_add_device() to __spi_add_device(). - Updated __spi_add_device() to check to make sure that multiple logical CS don't map to the same physical CS and same physical CS doesn't map to different logical CS. - Updated 1/8, 5/8 & 7/8 to support arbitrary number of flash devices connected in parallel or stacked mode. - Updated documentation for chip_select. - Added a new spi-nor structure member nor->num_flash to keep track of the number of flashes connected. - Added a new patch in the series 4/8 to move write_enable call just before spi_mem ops call in SPI-NOR. - Added comments in SPI core & SPI-NOR. - Rebased the patch series on top of the latest for-next branch. Changes in v8: - Updated __spi_add_device() and spi_set_cs() to fix spi driver failure with GPIO CS. - Rebased the patch series on top of latest for-next branch and fixed merge conflicts. - Updated cover letter description to add information regarding GPIO CS testing and request Stefan to provide his Tested-by tag for 1/7 patch. - Updated 1/7 patch description. Changes in v7: - Updated spi_dev_check() to avoid failures for spi driver GPIO CS and moved the error message from __spi_add_device() to spi_dev_check(). - Resolved code indentation issue in spi_set_cs(). - In spi_set_cs() call spi_delay_exec( ) once if the controller supports multi cs with both the CS backed by GPIO. - Updated __spi_validate()to add checks for both the GPIO CS. - Replaced cs_index_mask bit mask with SPI_CS_CNT_MAX. - Updated struct spi_controller to represent multi CS capability of the spi controller through a flag bit SPI_CONTROLLER_MULTI_CS instead of a boolen structure member "multi_cs_cap". - Updated 1/7 patch description . Changes in v6: - Rebased on top of latest v6.3-rc1 and fixed merge conflicts in spi-mpc512x-psc.c, sfdp.c, spansion.c files and removed spi-omap-100k.c. - Updated spi_dev_check( ) to reject new devices if any one of the chipselect is used by another device. Changes in v5: - Rebased the patches on top of v6.3-rc1 and fixed the merge conflicts. - Fixed compilation warnings in spi-sh-msiof.c with shmobile_defconfig Changes in v4: - Fixed build error in spi-pl022.c file - reported by Mark. - Fixed build error in spi-sn-f-ospi.c file. - Added Reviewed-by: Serge Semin <fancer.lancer@gmail.com> tag. - Added two more patches to replace spi->chip_select with API calls in mpc832x_rdb.c & cs35l41_hda_spi.c files. Changes in v3: - Rebased the patches on top of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next - Added a patch to convert spi_nor_otp_region_len(nor) & spi_nor_otp_n_regions(nor) macros into inline functions - Added Reviewed-by & Acked-by tags Changes in v2: - Rebased the patches on top of v6.2-rc1 - Created separate patch to add get & set APIs for spi->chip_select & spi->cs_gpiod, and replaced all spi->chip_select and spi->cs_gpiod references with the API calls. - Created separate patch to add get & set APIs for nor->params. --- Amit Kumar Mahapatra (10): mfd: tps6594: Use set/get APIs to access spi->chip_select ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select spi: Add multi-cs memories support in SPI core mtd: spi-nor: Convert macros with inline functions mtd: spi-nor: Add APIs to set/get nor->params mtd: spi-nor: Move write enable inside specific write & erase APIs mtd: spi-nor: Add stacked memories support in spi-nor spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver mtd: spi-nor: Add parallel memories support in spi-nor spi: spi-zynqmp-gqspi: Add parallel memories support in GQSPI driver drivers/mfd/tps6594-spi.c | 2 +- drivers/mtd/spi-nor/atmel.c | 17 +- drivers/mtd/spi-nor/core.c | 683 +++++++++++++++++++++++++------ drivers/mtd/spi-nor/core.h | 8 + drivers/mtd/spi-nor/debugfs.c | 4 +- drivers/mtd/spi-nor/gigadevice.c | 4 +- drivers/mtd/spi-nor/issi.c | 11 +- drivers/mtd/spi-nor/macronix.c | 10 +- drivers/mtd/spi-nor/micron-st.c | 35 +- drivers/mtd/spi-nor/otp.c | 48 ++- drivers/mtd/spi-nor/sfdp.c | 33 +- drivers/mtd/spi-nor/spansion.c | 57 +-- drivers/mtd/spi-nor/sst.c | 7 +- drivers/mtd/spi-nor/swp.c | 25 +- drivers/mtd/spi-nor/winbond.c | 2 +- drivers/mtd/spi-nor/xilinx.c | 18 +- drivers/spi/spi-zynqmp-gqspi.c | 58 ++- drivers/spi/spi.c | 259 ++++++++++-- include/linux/mtd/spi-nor.h | 21 +- include/linux/spi/spi.h | 51 ++- sound/pci/hda/cs35l56_hda_spi.c | 2 +- 21 files changed, 1085 insertions(+), 270 deletions(-)
Comments
On Sat, 25 Nov 2023 14:51:27 +0530, Amit Kumar Mahapatra wrote: > This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI > driver to add stacked and parallel memories support. > > The first nine patches > https://lore.kernel.org/all/20230119185342.2093323-1-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-2-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-3-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-4-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-5-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-6-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-7-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-8-amit.kumar-mahapatra@amd.com/ > https://lore.kernel.org/all/20230310173217.3429788-9-amit.kumar-mahapatra@amd.com/ > of the previous series got applied to > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git > for-next But the rest of the patches in the series did not get applied as > failure was reported for spi driver with GPIO CS, so send the remaining > patches in the series after rebasing it on top of for-next branch and > fixing the issue. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [02/10] ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select commit: f05e2f61fe88092e0d341ea27644a84e3386358d [03/10] spi: Add multi-cs memories support in SPI core commit: 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
> This patch series updated the spi-nor, spi core and the AMD-Xilinx > GQSPI > driver to add stacked and parallel memories support. Honestly, I'm not thrilled about how this is implemented in the core and what the restrictions are. First, the pattern "if (n==1) then { old behavior } else { copy old code modify for n==2 }" is hard to maintain. There should be no copy and the old code shall be adapted to work for both n=1 and n>1. But I agree with Tudor, some kind of abstraction (layer) would be nice. Also, you hardcode n=2 everywhere. Please generalize that one. Are you aware of any other controller supporting such a feature? I've seen you also need to modify the spi controller and intercept some commands. Can everything be moved there? I'm not sure we are implementing controller specific things in the core. Hard to judge without seeing other controllers doing a similar thing. I'd like to avoid that. If we had some kind of abstraction here, that might be easier to adapt in the future, but just putting everything into the core will make it really hard to maintain. So if everything related to stacked and parallel memory would be in drivers/mtd/spi-nor/stacked.c, we'd have at least everything in one place with a proper interface between that and the core. -michael
Hello Michael, > -----Original Message----- > From: Michael Walle <michael@walle.cc> > Sent: Tuesday, December 12, 2023 6:05 PM > To: Mahapatra, Amit Kumar <amit.kumar-mahapatra@amd.com> > Cc: broonie@kernel.org; tudor.ambarus@linaro.org; pratyush@kernel.org; > miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; > sbinding@opensource.cirrus.com; lee@kernel.org; > james.schulman@cirrus.com; david.rhodes@cirrus.com; > rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com; linux- > spi@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > mtd@lists.infradead.org; nicolas.ferre@microchip.com; > alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal > <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; alsa- > devel@alsa-project.org; patches@opensource.cirrus.com; linux- > sound@vger.kernel.org; git (AMD-Xilinx) <git@amd.com>; > amitrkcian2002@gmail.com > Subject: Re: [PATCH v11 00/10] spi: Add support for stacked/parallel > memories > > > This patch series updated the spi-nor, spi core and the AMD-Xilinx > > GQSPI driver to add stacked and parallel memories support. > > Honestly, I'm not thrilled about how this is implemented in the core and what > the restrictions are. > First, the pattern "if (n==1) then { old behavior } else { copy old code modify > for n==2 }" is hard to maintain. There should be no copy and the old code > shall be adapted to work for both n=1 and n>1. Stacked mode serves as an extension of single device mode concerning data handling and CS line assertion. In both scenarios, the driver only asserts one CS line at any given time. The existing code has been expanded to determine the CS line to be asserted based on the requested address and data length. This modification accommodates both single (legacy) and stacked use cases. In contrast, parallel mode differs from the legacy (single) mode in terms of data handling. In parallel mode, each byte of data is stored in both devices, with even bits in the lower flash and odd bits in the upper flash. During the transfer, multiple CS lines need to be asserted simultaneously. Consequently, special handling is necessary for parallel mode. > > But I agree with Tudor, some kind of abstraction (layer) would be nice. I agree too. > > Also, you hardcode n=2 everywhere. Please generalize that one. > > Are you aware of any other controller supporting such a feature? I've seen Currently, I am familiar only with the AMD-Xilinx QSPI controllers that support parallel/stacked configurations and AMD-Xilinx OSPI controllers, which support stacked configuration. However, it's important to highlight certain aspects of these configurations. In parallel mode, each byte of data is stored in both flash devices, and the QSPI controller automatically handles the byte split and the simultaneous assertion/de-assertion of multiple CS lines. Hence, it can be stated that parallel operation is a controller feature, and other controllers wishing to operate flashes in parallel mode should be capable of data splitting and asserting multiple CS lines simultaneously. This characteristic might be specific to the AMD-Xilinx controller. In contrast, in stacked mode, only one CS pin is asserted at any given time, determined by the memory address and the accessed data length. Stacked mode, unlike parallel mode, functions as a software abstraction. Once implemented, any SPI controller with multiple CS lines or with a combination of native-CS and GPIO-CS can operate two or more flashes in stacked mode. > you also need to modify the spi controller and intercept some commands. Command interception occurs exclusively in parallel mode, not in stacked mode. In parallel mode, data must be split during flash memory read/write operations. However, during Flash register read/write operations, there should be no data split, as the identical data needs to be written to (or read from) the register of both flashes. Consequently, the driver has to intercept the command before activating the data split feature of the controller. > Can everything be moved there? In stacked mode, determining which flash device needs to be asserted is based on the flash address and the length of the requested data. This information is handled by the spi-nor core. If the operation spans across multiple flashes, the command, address, dummy (if required), and residual data must be issued to multiple flashes. This process should be carried out in the spi-nor core layer( or before spi-mem) and not in the driver. That is why > > I'm not sure we are implementing controller specific things in the core. Hard As explained earlier the parallel mode of operation can be controller specific, But the stacked mode is controller independent. > to judge without seeing other controllers doing a similar thing. I'd like to avoid > that. > > If we had some kind of abstraction here, that might be easier to adapt in the > future, but just putting everything into the core will make it really hard to > maintain. So if everything related to stacked and parallel memory would be in > drivers/mtd/spi-nor/stacked.c, we'd have at least everything in one place with > a proper interface between that and the core. I agree. Regards Amit > > -michael
----- Ursprüngliche Mail ----- > Von: "Amit Kumar Mahapatra" <amit.kumar-mahapatra@amd.com> > This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI > driver to add stacked and parallel memories support. I wish the series had a real cover letter which explains the big picture in more detail. What I didn't really get so far, is it really necessary to support multiple chip selects within a single mtd? You changes introduce hard to maintain changes into the spi-nor/mtd core code which alert me. Why can't we have one mtd for each cs and, if needed, combine them later? We have drivers such as mtdconcat for reasons. Thanks, //richard
Hi Richard, richard@nod.at wrote on Mon, 18 Dec 2023 23:10:20 +0100 (CET): > ----- Ursprüngliche Mail ----- > > Von: "Amit Kumar Mahapatra" <amit.kumar-mahapatra@amd.com> > > > This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI > > driver to add stacked and parallel memories support. > > I wish the series had a real cover letter which explains the big picture > in more detail. > > What I didn't really get so far, is it really necessary to support multiple > chip selects within a single mtd? > You changes introduce hard to maintain changes into the spi-nor/mtd core code > which alert me. > Why can't we have one mtd for each cs and, if needed, combine them later? > We have drivers such as mtdconcat for reasons. The Xilinx SPI controller is a bit convoluted, there are two ways to address the bits in a memory: * Either your extend the memory range with the second chip "on top" of the first (which would typically be a mtd-concat use case) * Or you use the two chips in parallel and you store the even bits in one device (let's say cs0) and the odd bits in the other (cs1). Extending mtd-concat for this might be another solution, I don't know how feasible it would be. Maybe these bindings will help understanding the logic: e2edd1b64f1c ("spi: dt-bindings: Describe stacked/parallel memories modes") eba5368503b4 ("spi: dt-bindings: Add an example with two stacked flashes") However I agree the changes will likely be hard to maintain given the complexity brought with such a different controller. Thanks, Miquèl