Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1222809 > unrolled thread
| Started by | Mark Brown <broonie@kernel.org> |
|---|---|
| First post | 2015-09-11 14:40 +0200 |
| Last post | 2015-09-11 18:30 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe Mark Brown <broonie@kernel.org> - 2015-09-11 14:40 +0200
Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe Harini Katakam <harinikatakamlinux@gmail.com> - 2015-09-11 18:30 +0200
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-09-11 14:40 +0200 |
| Subject | Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe |
| Message-ID | <q7vMv-1Di-41@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Sep 04, 2015 at 12:02:21PM +0000, Ranjit Abhimanyu Waghmode wrote: Please fix your mail client to word wrap within paragraphs and to quote text without reflowing it - your messages are very hard to read. > > > + /* Controller may support more than one chip. > > > + * This flag will enable that feature. > > > + */ > > > +#define SPI_MASTER_BOTH_CS BIT(8) /* enable both > > chips */ > > This isn't saying that the controller supports more than one chip, it's saying that > > the controller supports asserting more than one chip select at once which isn't > > the same thing. I'm also not entirely sure that this makes sense as a separate > > feature to the data striping one - I'm struggling to think of a way to use this > > sensibly separately to that. > If the SPI controller is having more than one chip select and the data lines are distributed equally. > And also there is requirement to activate all the chip selects in one go. I'm not sure I understand the above, sorry. At least not in so far as how it relates to my concerns, especially the fact that the comment says this enables support for more than one chip which is obviously a basic SPI feature. > Now we can consider following use cases: > Suppose we need to send the same data to multiple slaves of same kind: > Here the application need not to do individual slave access for writing, instead it can send data to all the devices in one go. That's a *very* specific application which will only work for write only devices - I'd be surprised if such systems actually had distinct chip select lines at the CPU level. > Let's take another case where application is trying to send data in such a way that first nibble of the byte will got to the one slave and the second nibble of the byte will go to the other slave: > Here data in slave devices can be organized by taking advantage of above topology along with the support in hardware. But do such devices actually exist? I can imagine systems that might be able to do that but I'd be very surprised to see anyone practically designing them, they're going to be quite hard to use.
[toc] | [next] | [standalone]
| From | Harini Katakam <harinikatakamlinux@gmail.com> |
|---|---|
| Date | 2015-09-11 18:30 +0200 |
| Subject | Re: [LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe |
| Message-ID | <q7zn3-6Xj-5@gated-at.bofh.it> |
| In reply to | #1222809 |
Hi Mark, On Fri, Sep 11, 2015 at 6:06 PM, Mark Brown <broonie@kernel.org> wrote: > On Fri, Sep 04, 2015 at 12:02:21PM +0000, Ranjit Abhimanyu Waghmode wrote: > > Please fix your mail client to word wrap within paragraphs and to quote > text without reflowing it - your messages are very hard to read. > >> > > + /* Controller may support more than one chip. >> > > + * This flag will enable that feature. >> > > + */ >> > > +#define SPI_MASTER_BOTH_CS BIT(8) /* enable both >> > chips */ > >> Now we can consider following use cases: > >> Suppose we need to send the same data to multiple slaves of same kind: >> Here the application need not to do individual slave access for writing, instead it can send data to all the devices in one go. > > That's a *very* specific application which will only work for write only > devices - I'd be surprised if such systems actually had distinct chip > select lines at the CPU level. > Agreed that it is very specific but here are a few ways it is used when communicating with two flash devices in parallel configuration: - Write enable is sent to both devices using a single operation. - Writing to any configuration registers in the flash is done in one go - Some application that want to mirror important data to both devices. Even with reading, the assertion of multiple cs combined with stripe will mean: - Two status bytes, one form each will be obtained in one operation - Similarly data that was written using stripe is read back and combined. Such systems could still maintain separate chip selects to perform individual operations such as reading flash ID, debugging failures or locking specific sectors. Regards, Harini -- 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/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web