From: David Brownell <david-b@pacbell.net> To: Ingo Oeser <ioe-lkml@rameria.de> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Andrew Morton <akpm@linux-foundation.org>, spi-devel-general@lists.sourceforge.net, lkml <linux-kernel@vger.kernel.org>, Vernon Sauder <vernoninhand@gmail.com> Subject: Re: [patch 2.6.28-rc9] spi: spi_write_then_read() regression fix Date: Tue, 23 Dec 2008 10:37:53 -0800 [thread overview] Message-ID: <200812231037.53955.david-b@pacbell.net> (raw) In-Reply-To: <200812230254.00249.ioe-lkml@rameria.de> On Monday 22 December 2008, Ingo Oeser wrote: > Hi David, > > On Monday 22 December 2008, you wrote: > > The write_then_read() helper is > > simplifying a common half-duplex idiom for short operations, > > but the hardware still does full duplex. Buffer layout is: > > > > Before: WWWWW0000000 > > After: xxxxxRRRRRRR > > > > That is, for every bit shifted out (W, 0) another one gets > > shifted in (x, R). The I/O primitive essentially swaps > > contents of a one-word shift register between master and > > slave; or, sequences of such words. Words don't need to > > be byte-size, though that's a common option. > > ... > > Wow, what interesting hardware logic and a nice explanation. It's standard SPI ... yes, it's kind of interesting, and I've not come across anything else that synchronizes RX and TX in quite the same way. I suspect that hardware designers find the ability to get quick transfers (tens of megabits/second) from just a shift register is fairly attractive. Less work than high speed I2C, for one example. > Could you put that into a comment somewhere close to those helpers? Fair enough. That file does lack any mention of the I/O model for SPI ... and it's certainly a bit of a surprise to anyone who's not had to look at it before! > You can safely assume, that any code which Linus doesn't understand > is non-trivial and needs a comment :-) I'm not sure I'd agree with that -- while he's many things, "expert in everything" is not one of them! -- but I do agree that comment would be worth adding. However, with regards to $PATCH ... considering that the '28 release is just around the corner, I changed my mind and would suggest just reverting f9b90e39cbc5c4d6ef60022fd1f25d541df0aad1 much though I very much like that fix in general. Reason being: it needs a bit more work, I forgot that it will break for example drivers using drivers/spi/omap_uwire.c since that is built on top of truly half-duplex hardware. (Used with OMAP1 SOCs.) The kerneldoc says it's for providing MicroWire style transactions, so it's kind of significant that it work on MicroWire hardware too. ;) So an updated version would need to both zero the TX bits when using normal full-duplex SPI hardware ... and use more or less the current code when running on half-duplex variants. - Dave
WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> To: Ingo Oeser <ioe-lkml-MFZNYGWX9eyELgA04lAiVw@public.gmane.org> Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Vernon Sauder <vernoninhand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [patch 2.6.28-rc9] spi: spi_write_then_read() regression fix Date: Tue, 23 Dec 2008 10:37:53 -0800 [thread overview] Message-ID: <200812231037.53955.david-b@pacbell.net> (raw) In-Reply-To: <200812230254.00249.ioe-lkml-MFZNYGWX9eyELgA04lAiVw@public.gmane.org> On Monday 22 December 2008, Ingo Oeser wrote: > Hi David, > > On Monday 22 December 2008, you wrote: > > The write_then_read() helper is > > simplifying a common half-duplex idiom for short operations, > > but the hardware still does full duplex. Buffer layout is: > > > > Before: WWWWW0000000 > > After: xxxxxRRRRRRR > > > > That is, for every bit shifted out (W, 0) another one gets > > shifted in (x, R). The I/O primitive essentially swaps > > contents of a one-word shift register between master and > > slave; or, sequences of such words. Words don't need to > > be byte-size, though that's a common option. > > ... > > Wow, what interesting hardware logic and a nice explanation. It's standard SPI ... yes, it's kind of interesting, and I've not come across anything else that synchronizes RX and TX in quite the same way. I suspect that hardware designers find the ability to get quick transfers (tens of megabits/second) from just a shift register is fairly attractive. Less work than high speed I2C, for one example. > Could you put that into a comment somewhere close to those helpers? Fair enough. That file does lack any mention of the I/O model for SPI ... and it's certainly a bit of a surprise to anyone who's not had to look at it before! > You can safely assume, that any code which Linus doesn't understand > is non-trivial and needs a comment :-) I'm not sure I'd agree with that -- while he's many things, "expert in everything" is not one of them! -- but I do agree that comment would be worth adding. However, with regards to $PATCH ... considering that the '28 release is just around the corner, I changed my mind and would suggest just reverting f9b90e39cbc5c4d6ef60022fd1f25d541df0aad1 much though I very much like that fix in general. Reason being: it needs a bit more work, I forgot that it will break for example drivers using drivers/spi/omap_uwire.c since that is built on top of truly half-duplex hardware. (Used with OMAP1 SOCs.) The kerneldoc says it's for providing MicroWire style transactions, so it's kind of significant that it work on MicroWire hardware too. ;) So an updated version would need to both zero the TX bits when using normal full-duplex SPI hardware ... and use more or less the current code when running on half-duplex variants. - Dave ------------------------------------------------------------------------------
next prev parent reply other threads:[~2008-12-23 18:38 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-12-21 7:32 [patch 2.6.28-rc9] spi: spi_write_then_read() regression fix David Brownell 2008-12-21 7:32 ` David Brownell 2008-12-21 23:46 ` Linus Torvalds 2008-12-21 23:46 ` Linus Torvalds 2008-12-22 0:48 ` David Brownell 2008-12-23 1:53 ` Ingo Oeser 2008-12-23 18:37 ` David Brownell [this message] 2008-12-23 18:37 ` David Brownell 2008-12-23 18:45 ` Linus Torvalds 2008-12-23 18:45 ` Linus Torvalds 2008-12-23 20:54 ` David Brownell 2008-12-23 20:54 ` David Brownell [not found] ` <200812231254.55284.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 2008-12-24 3:26 ` Tang, Feng [not found] ` <EADF0A36011179459010BDF5142A45750458C7DD-Uz4Je35TzWuiAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2008-12-24 3:53 ` David Brownell [not found] ` <200812231953.26407.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 2008-12-24 4:20 ` Tang, Feng [not found] ` <EADF0A36011179459010BDF5142A45750458C815-Uz4Je35TzWuiAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2008-12-24 8:39 ` David Brownell [not found] ` <200812240039.32008.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 2008-12-24 8:58 ` Baruch Siach [not found] ` <20081224085844.GA11197-l+PWtdWbHAs2zBO71LVbc/qBs+8SCbDb@public.gmane.org> 2008-12-24 19:43 ` David Brownell 2008-12-25 7:03 ` Tang, Feng
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=200812231037.53955.david-b@pacbell.net \ --to=david-b@pacbell.net \ --cc=akpm@linux-foundation.org \ --cc=ioe-lkml@rameria.de \ --cc=linux-kernel@vger.kernel.org \ --cc=spi-devel-general@lists.sourceforge.net \ --cc=torvalds@linux-foundation.org \ --cc=vernoninhand@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.