From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gupta, Pekon" Subject: RE: support DUAL and QUAD[patch v1] Date: Tue, 16 Jul 2013 11:20:26 +0000 Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9E85D0@DBDE04.ent.ti.com> References: <20980858CB6D3A4BAE95CA194937D5E73E9E84D2@DBDE04.ent.ti.com> <20980858CB6D3A4BAE95CA194937D5E73E9E851E@DBDE04.ent.ti.com> <593AEF6C47F46446852B067021A273D6D93B49E1@MUCSE039.lantiq.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , "Poddar, Sourav" , "broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" To: "thomas.langer-th3ZBGNqt+7QT0dZR+AlfA@public.gmane.org" , "wangyuhang2014-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" Return-path: In-Reply-To: <593AEF6C47F46446852B067021A273D6D93B49E1-6yu8tajIPx7U45ihrnOXy0EOCMrvLtNR@public.gmane.org> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org > = > Hello Pekon, > = > Gupta, Pekon wrote on=A02013-07-16: > > > > > > Hi, Gupta > > > > > > > > > > [Pekon]: Instead of adding new fields you can use existing 'mode' f= ield > to > > > > pass on the platform specific configurations. And if 'u8 mode' does= not > > > > suffice you can increase it to 'u32'. > > > > #define QSPI_MODE 1 << 5; // just check which bit-fields are = un- > used > > > > spi_board_info->mode |=3D QSPI_MODE; > > > > > > > > > > well, can dual and quad be regarded as a spi mode? if so, your comment > > > seems > > > to be right. > > > > Yes, Quad and Dual modes should be regarded as extension of SPI > protocol. > > - They follow the same basic principle of synchronous data transfer. Ri= ght ? > > - These modes are not adding any extra side-band | In-band signaling or > > controls to modify the protocol. They are just increasing the width of > > data-channel for better throughput. > > > > with regards, pekon > > > = > In general, yes. But I think, for the interface we have to take care of m= ore > details. > = > For example, what happens in the following situation: > We have a spi-controller, which supports the QSPI mode, and a spi-flash, > which fulfils > the requirements, but the board has not connected all signals? > = [Pekon]: So, actual implementation should set QSPI_MODE based on both (1) device capabilities (detected in probe) (2) board-DT properties (this would take care of your other constrains) > And the interface for the slave-driver (like m25p80) should allow to spec= ify > the transfer mode > for each spi_message. > This will be necessary, because it depends on the flash and mode, how each > phase of "cmd", > "address", and "data" will be transferred. > = [Pekon]: Are you saying that same controller can send interleaved = Quad-SPI and Single-SPI spi_messages to same device (here flash device)? Is it due to flash-device constrain that it accepts some flash-commands = (like erase, etc) only on Single-wire-SPI, whereas data transfers can be = Performed on Quad-SPI mode ? In such case you need to add 'mode' field in struct spi_message, so that this information moves along with the spi_message in queue. And then when that message reaches spi_pump_message() and = transfer_one_message() is called, then you can do needful configs. However, I still don't think you need to control 'QSPI_MODE' at granularity of spi_transfer level, because m25p80 flash-driver use spi_write() API to pass data to SPI driver, which internally creates a spi_message in each cal= l. Following best explains use of spi_message in /include/linux/spi.h --------------------------------------------------- * A @spi_message is used to execute an atomic sequence of data transfers, * each represented by a struct spi_transfer. The sequence is "atomic" * in the sense that no other spi_message may use that SPI bus until that * sequence completes. On some systems, many such sequences can execute as * as single programmed DMA transfer. On all systems, these messages are * queued, and might complete after transactions to other devices. Messages * sent to a given spi_device are alway executed in FIFO order. --------------------------------------------------- > I don't know, if it is only me, but I would like to see some more abstract > description for all > these scenarios, before the details of an interface really could be discu= ssed > and decided. > = Agree.. Does above matches your requirement ? = with regards, pekon > Best Regards, > Thomas ---------------------------------------------------------------------------= --- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=3D48808831&iu=3D/4140/ostg.cl= ktrk From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from devils.ext.ti.com ([198.47.26.153]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Uz3JT-0000S3-JS for linux-mtd@lists.infradead.org; Tue, 16 Jul 2013 11:21:00 +0000 From: "Gupta, Pekon" To: "thomas.langer@lantiq.com" , "wangyuhang2014@gmail.com" Subject: RE: support DUAL and QUAD[patch v1] Date: Tue, 16 Jul 2013 11:20:26 +0000 Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9E85D0@DBDE04.ent.ti.com> References: <20980858CB6D3A4BAE95CA194937D5E73E9E84D2@DBDE04.ent.ti.com> <20980858CB6D3A4BAE95CA194937D5E73E9E851E@DBDE04.ent.ti.com> <593AEF6C47F46446852B067021A273D6D93B49E1@MUCSE039.lantiq.com> In-Reply-To: <593AEF6C47F46446852B067021A273D6D93B49E1@MUCSE039.lantiq.com> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spi-devel-general@lists.sourceforge.net" , "Poddar, Sourav" , "broonie@kernel.org" , "linux-mtd@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >=20 > Hello Pekon, >=20 > Gupta, Pekon wrote on=A02013-07-16: > > > > > > Hi, Gupta > > > > > > > > > > [Pekon]: Instead of adding new fields you can use existing 'mode' f= ield > to > > > > pass on the platform specific configurations. And if 'u8 mode' does= not > > > > suffice you can increase it to 'u32'. > > > > #define QSPI_MODE 1 << 5; // just check which bit-fields are = un- > used > > > > spi_board_info->mode |=3D QSPI_MODE; > > > > > > > > > > well, can dual and quad be regarded as a spi mode? if so, your commen= t > > > seems > > > to be right. > > > > Yes, Quad and Dual modes should be regarded as extension of SPI > protocol. > > - They follow the same basic principle of synchronous data transfer. Ri= ght ? > > - These modes are not adding any extra side-band | In-band signaling or > > controls to modify the protocol. They are just increasing the width of > > data-channel for better throughput. > > > > with regards, pekon > > >=20 > In general, yes. But I think, for the interface we have to take care of m= ore > details. >=20 > For example, what happens in the following situation: > We have a spi-controller, which supports the QSPI mode, and a spi-flash, > which fulfils > the requirements, but the board has not connected all signals? >=20 [Pekon]: So, actual implementation should set QSPI_MODE based on both (1) device capabilities (detected in probe) (2) board-DT properties (this would take care of your other constrains) > And the interface for the slave-driver (like m25p80) should allow to spec= ify > the transfer mode > for each spi_message. > This will be necessary, because it depends on the flash and mode, how eac= h > phase of "cmd", > "address", and "data" will be transferred. >=20 [Pekon]: Are you saying that same controller can send interleaved=20 Quad-SPI and Single-SPI spi_messages to same device (here flash device)? Is it due to flash-device constrain that it accepts some flash-commands=20 (like erase, etc) only on Single-wire-SPI, whereas data transfers can be=20 Performed on Quad-SPI mode ? In such case you need to add 'mode' field in struct spi_message, so that this information moves along with the spi_message in queue. And then when that message reaches spi_pump_message() and=20 transfer_one_message() is called, then you can do needful configs. However, I still don't think you need to control 'QSPI_MODE' at granularity of spi_transfer level, because m25p80 flash-driver use spi_write() API to pass data to SPI driver, which internally creates a spi_message in each cal= l. Following best explains use of spi_message in /include/linux/spi.h --------------------------------------------------- * A @spi_message is used to execute an atomic sequence of data transfers, * each represented by a struct spi_transfer. The sequence is "atomic" * in the sense that no other spi_message may use that SPI bus until that * sequence completes. On some systems, many such sequences can execute as * as single programmed DMA transfer. On all systems, these messages are * queued, and might complete after transactions to other devices. Message= s * sent to a given spi_device are alway executed in FIFO order. --------------------------------------------------- > I don't know, if it is only me, but I would like to see some more abstrac= t > description for all > these scenarios, before the details of an interface really could be discu= ssed > and decided. >=20 Agree.. Does above matches your requirement ? =20 with regards, pekon > Best Regards, > Thomas