From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Thu, 9 Aug 2018 10:13:13 +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: References: <20180807121655.22346-1-sr@denx.de> <20180807152802.0a3d1332@bbrezillon> <20180808105653.1cca3bc0@xps13> Message-ID: <20180809101313.3fd0175f@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 07:24:14 +0200: > Hi Miquel, >=20 > On 08.08.2018 10:56, Miquel Raynal wrote: > > 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 pa= tch > >>> changes the SPI transfer into 2 separate transfers - or 1, if no data= is > >>> to transmitted. > >>> > >>> With this change, no buffers need to be allocated anymore. We use the > >>> 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 ignore > >> if you disagree). > >> > >> Reviewed-by: Boris Brezillon > >> > > > Sorry for being a bit late on the discussion, but while I do agree wi= th =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 >=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. >=20 > Or did I miss something here? Actually I'm fine with it as SPI-mem only uses half-duplex. It's not necessary to limit its use to SPI controllers (drivers) supporting full-duplex. Stefan, shall I fold your changes in my series and resend? Or do I resend only my original patches and Jagan/Tom will apply yours on top of it? Thanks, Miqu=C3=A8l