From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Thu, 9 Aug 2018 16:50:38 +0200 Subject: [U-Boot] [PATCH 1/4 v2] spi: spi-mem: Use 2 SPI messages instead of a single full-duplex one In-Reply-To: <23c2b26b-15f1-8ddd-f7d9-282cf28ac783@denx.de> References: <20180807121655.22346-1-sr@denx.de> <20180807152802.0a3d1332@bbrezillon> <20180808105653.1cca3bc0@xps13> <20180809101313.3fd0175f@xps13> <23c2b26b-15f1-8ddd-f7d9-282cf28ac783@denx.de> Message-ID: <20180809165038.1a729960@xps13> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi Stefan, Stefan Roese wrote on Thu, 9 Aug 2018 11:10:15 +0200: > Hi Miquel, >=20 > On 09.08.2018 10:13, Miquel Raynal wrote: > > Stefan Roese wrote on Thu, 9 Aug 2018 07:24:14 +0200: =20 > > >> Hi Miquel, =20 > >> > >> On 08.08.2018 10:56, Miquel Raynal wrote: =20 > >>> Boris Brezillon wrote on Tue, 7 Aug 2018 > >>> 15:28:02 +0200: =20 > >>>>> On Tue, 7 Aug 2018 14:16:52 +0200 =20 > >>>> Stefan Roese wrote: =20 > >>>> >>>>> Some SPI controller do not support full-duplex SPI transfers= . This patch =20 > >>>>> changes the SPI transfer into 2 separate transfers - or 1, if no da= ta is > >>>>> to transmitted. > >>>>> > >>>>> With this change, no buffers need to be allocated anymore. We use t= he > >>>>> TX and RX buffers that are passed to spi_mem_exec_op() directly. > >>>>> > >>>>> Signed-off-by: Stefan Roese > >>>>> Suggested-by: Boris Brezillon > >>>>> Cc: Miquel Raynal > >>>>> Cc: Boris Brezillon > >>>>> Cc: Jagan Teki =20 > >>>> > >>>> Looks good overall, just a few comments (that you might chose to ign= ore > >>>> if you disagree). > >>>> > >>>> Reviewed-by: Boris Brezillon > >>>> > >>>> Sorry for being a bit late on the discussion, but while I do agree w= ith =20 > >>> the change, I'm not sure about its implementation : I think SPI > >>> controllers are supposed to be abstracted by the SPI layer. > >>> Addressing the controller's limitations in the SPI-mem layer would > >>> not be appropriate. =20 > >>>> Would it be possible to adapt spi_xfer() to handle such case? =20 > >> > >> No, I don't think so. Its impossible to guess in the SPI driver layer, > >> which parts of the message are TX data and which are RX data. So this > >> message can't be split up into a half-duplex one here. This can only > >> be done in the driver which constructs the SPI messages. > >> > >> Or did I miss something here? > > > Actually I'm fine with it as SPI-mem only uses half-duplex. It's not = =20 > > necessary to limit its use to SPI controllers (drivers) supporting > > full-duplex. =20 > > > Stefan, shall I fold your changes in my series and resend? Or do I =20 > > resend only my original patches and Jagan/Tom will apply yours on top > > of it? =20 >=20 > Do you need to re-send your original patches? If yes, then please do > with my patches folded in. If a re-send is not necessary, then Jagan > or Tom should be able to apply your latest patchset and mine on top > of it. I suppose Jagan prefers formal patches than a Github branch so basically I have to pull Boris fixes, squash them, do the same with yours and resend. As we missed the merge window, maybe I'll also take the time to rework mtdparts. I plan to do that next week. Thanks for your help, Miqu=C3=A8l