Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756876AbbHZMUJ (ORCPT ); Wed, 26 Aug 2015 08:20:09 -0400 Received: from s159.web-hosting.com ([68.65.121.203]:36310 "EHLO s159.web-hosting.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752105AbbHZMUH (ORCPT ); Wed, 26 Aug 2015 08:20:07 -0400 MIME-Version: 1.0 In-Reply-To: <1440570367-22569-1-git-send-email-ranjit.waghmode@xilinx.com> References: <1440570367-22569-1-git-send-email-ranjit.waghmode@xilinx.com> Date: Wed, 26 Aug 2015 17:49:59 +0530 Message-ID: Subject: Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller From: Jagan Teki To: Ranjit Waghmode Cc: David Woodhouse , Brian Norris , broonie@kernel.org, Michal Simek , Soren Brinkmann , zajec5@gmail.com, ben@decadent.org.uk, =?UTF-8?B?TWFyZWsgVmHFoXV0?= , Huang Shijie , knut.wohlrab@de.bosch.com, juhosg@openwrt.org, beanhuo@micron.com, "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , linux-spi@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , harinik@xilinx.com, punnaia@xilinx.com Content-Type: text/plain; charset=UTF-8 X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server159.web-hosting.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openedev.com X-Get-Message-Sender-Via: server159.web-hosting.com: authenticated_id: jteki@openedev.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3016 Lines: 68 On 26 August 2015 at 11:56, Ranjit Waghmode wrote: > This series adds dual parallel mode support for Zynq Ultrascale+ > MPSoC GQSPI controller driver. > > What is dual parallel mode? > --------------------------- > ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities: > 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. > 2) Chip selects and clock are shared to both the flash devices > 3) This mode is targeted for faster read/write speed and also doubles the size > 4) Commands/data can be transmitted/received from both the devices(mirror), > or only upper or only lower flash memory devices. > 5) Data arrangement: > With stripe enabled, > Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus > Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. > > This series also updated MTD layer files for adding parallel mode support. > > 1) Added Support for two flashes > 2) Support to enable/disable data stripe as and when required. > 3) Added required parameters to spi_nor structure. Initialized all > added parameters in spi_nor_scan() > 4) Added support for dual parallel in spi_nor_read/write/erase functions by: > a) Increasing page_size, sector_size, erase_size and toatal flash size > as and when required. > b) Dividing address by 2 > c) Updating spi->master->flags for qspi driver to change CS > 5) Updated read_sr() to get status of both flashes > 6) Also updated read_fsr() to get status of both flashes > > These all are very high level changes and expected to make an idea clear. > Comments and suggestions are always welcomed > > --- > V2 Changes: > a) Splitted patches based on logical changes > b) Added error handling for newly added APIs in SPI core > --- > > Ranjit Waghmode (4): > spi: add support of two chip selects & data stripe > mtd: add spi_device instance to spi_nor struct > spi-nor: add dual parallel mode support > spi: zynqmp: gqspi: add support for dual parallel mode configuration I don't find any previous discussion about way to inform flash dual-ness into spi-nor from spi drivers. Here is my idea, probably others may think same. Informing dual_flash from drivers/spi through flags or any other mode bits is not a better approach as dual flash feature is specific to spi-nor flash controller (controller specially designed for spi-nor flash not the generic spi controller). So if the driver sits on drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash specific things to spi-nor as it's not touching generic spi stack in Linux. But there is a defined-drawback if the driver is moved to drivers/mtd/spi-nor ie it can't use spi core API's at-all. thanks! -- Jagan | openedev. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/