* (no subject) @ 2010-01-20 19:47 Ben Gamari 2010-01-21 0:04 ` Ben Dooks ` (5 more replies) 0 siblings, 6 replies; 29+ messages in thread From: Ben Gamari @ 2010-01-20 19:47 UTC (permalink / raw) To: Ben Dooks Cc: David Brownell, Michael Hennerich, beagleboard, Eric Miao, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-omap Bcc: Subject: GPIO chip select support in omap2_mcspi driver Hey, Recently I have been looking to use a BeagleBoard to drive several serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the BeagleBoard is severely limited by the number of SPI controllers it exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 with one). This is insufficient for our application and thus I have been investigating adding support to the mcspi driver for using GPIO lines as chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. To this end, I have a few questions about how this support was implemented. First, it seems that the s3c24xx driver is built on the spi_bitbang driver, despite interfacing with a dedicated hardware SPI controller. What is the reason for this? Was this done specifically for the purpose of incorporating support for GPIO CS pins? It seems like the rough idea is to add a cs_gpio field to the device struct (omap2_mcspi) and add the appropriate code to the omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The potential problem I can see with this is that omap2_mcspi_set_enable() is called to enable the channel before the force_cs() is called (in omap2_mcspi_work()). If I'm interpreting the documentation correctly, the enable bit starts the clocks, meaning that the chip will begin clocking out data before CS is brought high. I must be missing something here, no? For reference, I included a short list of relevant commits below, largely for my own benefit. I would greatly appreciate any feedback you might have. Thanks, - Ben pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2010-01-20 19:47 (no subject) Ben Gamari @ 2010-01-21 0:04 ` Ben Dooks 2010-01-21 0:04 ` (no subject) Ben Dooks ` (4 subsequent siblings) 5 siblings, 0 replies; 29+ messages in thread From: Ben Dooks @ 2010-01-21 0:04 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, Grant Likely, spi-devel-general Ben Gamari wrote: > Bcc: > Subject: GPIO chip select support in omap2_mcspi driver > > Hey, > > Recently I have been looking to use a BeagleBoard to drive several > serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the > BeagleBoard is severely limited by the number of SPI controllers it > exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 > with one). This is insufficient for our application and thus I have been > investigating adding support to the mcspi driver for using GPIO lines as > chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. > > To this end, I have a few questions about how this support was > implemented. First, it seems that the s3c24xx driver is built on the > spi_bitbang driver, despite interfacing with a dedicated hardware SPI > controller. What is the reason for this? Was this done specifically for > the purpose of incorporating support for GPIO CS pins? The spi_bitbang driver also has a really useful spi queue and workqueue built into it, which is what the s3c24xx spi driver actually bothers to use. > It seems like the rough idea is to add a cs_gpio field to the device > struct (omap2_mcspi) and add the appropriate code to the > omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The > potential problem I can see with this is that omap2_mcspi_set_enable() > is called to enable the channel before the force_cs() is called (in > omap2_mcspi_work()). If I'm interpreting the documentation correctly, > the enable bit starts the clocks, meaning that the chip will begin > clocking out data before CS is brought high. I must be missing something > here, no? > > For reference, I included a short list of relevant commits below, largely for > my own benefit. I would greatly appreciate any feedback you might have. > > Thanks, > - Ben > > > pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 > bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: (no subject) 2010-01-20 19:47 (no subject) Ben Gamari 2010-01-21 0:04 ` Ben Dooks @ 2010-01-21 0:04 ` Ben Dooks 2010-01-21 0:04 ` Ben Dooks ` (3 subsequent siblings) 5 siblings, 0 replies; 29+ messages in thread From: Ben Dooks @ 2010-01-21 0:04 UTC (permalink / raw) To: Ben Gamari Cc: David Brownell, Michael Hennerich, beagleboard, Eric Miao, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, linux-omap Ben Gamari wrote: > Bcc: > Subject: GPIO chip select support in omap2_mcspi driver > > Hey, > > Recently I have been looking to use a BeagleBoard to drive several > serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the > BeagleBoard is severely limited by the number of SPI controllers it > exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 > with one). This is insufficient for our application and thus I have been > investigating adding support to the mcspi driver for using GPIO lines as > chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. > > To this end, I have a few questions about how this support was > implemented. First, it seems that the s3c24xx driver is built on the > spi_bitbang driver, despite interfacing with a dedicated hardware SPI > controller. What is the reason for this? Was this done specifically for > the purpose of incorporating support for GPIO CS pins? The spi_bitbang driver also has a really useful spi queue and workqueue built into it, which is what the s3c24xx spi driver actually bothers to use. > It seems like the rough idea is to add a cs_gpio field to the device > struct (omap2_mcspi) and add the appropriate code to the > omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The > potential problem I can see with this is that omap2_mcspi_set_enable() > is called to enable the channel before the force_cs() is called (in > omap2_mcspi_work()). If I'm interpreting the documentation correctly, > the enable bit starts the clocks, meaning that the chip will begin > clocking out data before CS is brought high. I must be missing something > here, no? > > For reference, I included a short list of relevant commits below, largely for > my own benefit. I would greatly appreciate any feedback you might have. > > Thanks, > - Ben > > > pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 > bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2010-01-20 19:47 (no subject) Ben Gamari 2010-01-21 0:04 ` Ben Dooks 2010-01-21 0:04 ` (no subject) Ben Dooks @ 2010-01-21 0:04 ` Ben Dooks 2010-01-22 15:53 ` Re: Ben Gamari ` (2 subsequent siblings) 5 siblings, 0 replies; 29+ messages in thread From: Ben Dooks @ 2010-01-21 0:04 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, Grant Likely, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- Attachment #1: Type: text/plain, Size: 1981 bytes --] Ben Gamari wrote: > Bcc: > Subject: GPIO chip select support in omap2_mcspi driver > > Hey, > > Recently I have been looking to use a BeagleBoard to drive several > serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the > BeagleBoard is severely limited by the number of SPI controllers it > exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 > with one). This is insufficient for our application and thus I have been > investigating adding support to the mcspi driver for using GPIO lines as > chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. > > To this end, I have a few questions about how this support was > implemented. First, it seems that the s3c24xx driver is built on the > spi_bitbang driver, despite interfacing with a dedicated hardware SPI > controller. What is the reason for this? Was this done specifically for > the purpose of incorporating support for GPIO CS pins? The spi_bitbang driver also has a really useful spi queue and workqueue built into it, which is what the s3c24xx spi driver actually bothers to use. > It seems like the rough idea is to add a cs_gpio field to the device > struct (omap2_mcspi) and add the appropriate code to the > omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The > potential problem I can see with this is that omap2_mcspi_set_enable() > is called to enable the channel before the force_cs() is called (in > omap2_mcspi_work()). If I'm interpreting the documentation correctly, > the enable bit starts the clocks, meaning that the chip will begin > clocking out data before CS is brought high. I must be missing something > here, no? > > For reference, I included a short list of relevant commits below, largely for > my own benefit. I would greatly appreciate any feedback you might have. > > Thanks, > - Ben > > > pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 > bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 [-- Attachment #2: Type: text/plain, Size: 409 bytes --] -- You received this message because you are subscribed to the Google Groups "Beagle Board" group. To post to this group, send email to beagleboard-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: 2010-01-20 19:47 (no subject) Ben Gamari ` (2 preceding siblings ...) 2010-01-21 0:04 ` Ben Dooks @ 2010-01-22 15:53 ` Ben Gamari 2010-01-28 4:10 ` McSPI questions pertaining to GPIO chip select support Ben Gamari [not found] ` <1264651770-sup-5197@ben-laptop> 5 siblings, 0 replies; 29+ messages in thread From: Ben Gamari @ 2010-01-22 15:53 UTC (permalink / raw) To: Ben Gamari Cc: Ben Dooks, beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, Grant Likely, spi-devel-general Excerpts from Ben Gamari's message of Wed Jan 20 14:47:23 -0500 2010: > Bcc: > Subject: GPIO chip select support in omap2_mcspi driver > > It seems like the rough idea is to add a cs_gpio field to the device > struct (omap2_mcspi) and add the appropriate code to the > omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The > potential problem I can see with this is that omap2_mcspi_set_enable() > is called to enable the channel before the force_cs() is called (in > omap2_mcspi_work()). If I'm interpreting the documentation correctly, > the enable bit starts the clocks, meaning that the chip will begin > clocking out data before CS is brought high. I must be missing something > here, no? Could someone comment on how this ordering works? As I said, it seems to me like the SPI controller starts sending before CS is brought high. I would appreciate any feedback. Thanks! - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* McSPI questions pertaining to GPIO chip select support 2010-01-20 19:47 (no subject) Ben Gamari ` (3 preceding siblings ...) 2010-01-22 15:53 ` Re: Ben Gamari @ 2010-01-28 4:10 ` Ben Gamari [not found] ` <1264651770-sup-5197@ben-laptop> 5 siblings, 0 replies; 29+ messages in thread From: Ben Gamari @ 2010-01-28 4:10 UTC (permalink / raw) To: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hey all! Recently I've been thinking about adding support to the McSPI driver for using GPIO pins as chip selects. As a starting point, I've browsed the driver source trying to identify what changes would be necessary to add this support. It seems like the rough idea is, a) add a cs_gpio field to the device struct (omap2_mcspi) b) modify omap2_mcspi_force_cs() to use cs_gpio instead of the CHxCONF[FORCE] bit if cs_gpio is valid Unfortunately, I'm having a bit of difficulty seeing how the existing configuration works. In master mode, it seems that the controller is configured in single forced channel mode (MCSPI_MODULECTRL_SINGLE). As far as I can tell, this means that the driver is responsible for managing the chip selects through the MCSPI_CHxCONF[FORCE] bits. It seems that this is ideal as little will need to be changed to incorporate GPIO CS support. Nevertheless, the timing of the various operations isn't making sense to me. As far as I understand it, the callgraph is as follows, omap2_mcspi_work(): loop over messages omap2_mcspi_set_enable(1) loop over transfers: configure bus parameters if (!cs_active) cs = 1 if (dma): omap2_mcspi_txrx_dma() else: omap2_mcspi_txrx_pio() if (cs_change) cs = 0 end loop if (cs_active) cs = 0 omap2_mcspi_set_enable(0) end loop It seems that omap2_mcspi_set_enable() is called to enable the channel (MCSPI_CHCTRLx[EN] is set) before force_cs() is called. If I'm interpreting the hardware documentation correctly, the enable bit (among other things) starts the SPI clock, meaning that the chip will begin clocking out zeros to the device before CS is brought high. Furthermore, even after CS is brought high, it seems there could be a fair amount of time before the chip begins actually clocking out valid data. As I am writing this, it now occurs to me that perhaps the chip doesn't start SPI_CLK until it has data to send. It seems that if this were the case my concerns would be resolved. However, it is not at all clear that this is the case from the documentation. When exactly does the controller start the bus clock? Is this stated explicitly anywhere in the documentation? Any input you could offer would be greatly appreciated. Thanks for your time. - Ben P.S. The more and more I think about it, it seems like my hypothesis is the only logical behavior. It would be great if someone could confirm my suspicions, however. It really seems like this should be in the documentation either way. P.P.S. I apologize if this is something someone familiar with SPI should just know. My knowledge is a little spotty on this sort of thing. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1264651770-sup-5197@ben-laptop>]
* Re: McSPI questions pertaining to GPIO chip select support [not found] ` <1264651770-sup-5197@ben-laptop> @ 2010-01-28 4:15 ` Bill Gatliff 2010-01-28 4:25 ` Ben Gamari 2010-01-28 4:33 ` jassi brar 2011-08-30 10:14 ` McSPI questions pertaining to GPIO chip select support Raju Sana 2 siblings, 1 reply; 29+ messages in thread From: Bill Gatliff @ 2010-01-28 4:15 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, Grant Likely, spi-devel-general Ben Gamari wrote: > As I am writing this, it now occurs to me that perhaps the chip doesn't > start SPI_CLK until it has data to send. ... or receive. This is indeed the case. b.g. -- Bill Gatliff Embedded systems training and consulting http://billgatliff.com bgat@billgatliff.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: McSPI questions pertaining to GPIO chip select support 2010-01-28 4:15 ` Bill Gatliff @ 2010-01-28 4:25 ` Ben Gamari 2010-01-28 4:27 ` Bill Gatliff 0 siblings, 1 reply; 29+ messages in thread From: Ben Gamari @ 2010-01-28 4:25 UTC (permalink / raw) To: Bill Gatliff Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, Grant Likely, spi-devel-general Excerpts from Bill Gatliff's message of Wed Jan 27 23:15:05 -0500 2010: > Ben Gamari wrote: > > As I am writing this, it now occurs to me that perhaps the chip doesn't > > start SPI_CLK until it has data to send. > > ... or receive. This is indeed the case. > Thanks for your prompt reply. Hopefully you'll see a patch from me about this in the next few days. I'm assuming this functionality would be welcome in mainline? - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: McSPI questions pertaining to GPIO chip select support 2010-01-28 4:25 ` Ben Gamari @ 2010-01-28 4:27 ` Bill Gatliff 0 siblings, 0 replies; 29+ messages in thread From: Bill Gatliff @ 2010-01-28 4:27 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, Grant Likely, spi-devel-general Ben Gamari wrote: > Thanks for your prompt reply. Hopefully you'll see a patch from me about > this in the next few days. I'm assuming this functionality would be > welcome in mainline? > Heck if I know. :) But seriously, seems like SPI slave-selects are always in short supply. So yeah, people will find your patches very useful. b.g. -- Bill Gatliff Embedded systems training and consulting http://billgatliff.com bgat@billgatliff.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: McSPI questions pertaining to GPIO chip select support [not found] ` <1264651770-sup-5197@ben-laptop> 2010-01-28 4:15 ` Bill Gatliff @ 2010-01-28 4:33 ` jassi brar [not found] ` <1b68c6791001272033q60dd31dbif4de285cd9bac83d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> [not found] ` <1292954195-20204-2-git-send-email-bgamari.foss@gmail.com> 2011-08-30 10:14 ` McSPI questions pertaining to GPIO chip select support Raju Sana 2 siblings, 2 replies; 29+ messages in thread From: jassi brar @ 2010-01-28 4:33 UTC (permalink / raw) To: Ben Gamari Cc: David Brownell, Michael Hennerich, beagleboard, Eric Miao, spi-devel-general, linux-omap On Thu, Jan 28, 2010 at 1:10 PM, Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Hey all! > > Recently I've been thinking about adding support to the McSPI driver for > using GPIO pins as chip selects. As a starting point, I've browsed the > driver source trying to identify what changes would be necessary to add > this support. It seems like the rough idea is, You may loot at drivers/spi/spi_s3c64xx.c in Grant Likely's tree. It doesn't put limit on the number of CS and not even on whether the CS mechanism is simple GPIO toggling(though the callback type is defined to match gpio_set_value). For platform side of it, you need to look in to Ben Dooks' tree. hth ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1b68c6791001272033q60dd31dbif4de285cd9bac83d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: McSPI questions pertaining to GPIO chip select support [not found] ` <1b68c6791001272033q60dd31dbif4de285cd9bac83d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-01-29 0:32 ` Ben Gamari 2010-01-29 1:09 ` jassi brar 2010-12-21 17:56 ` [RFC PATCH] GPIO chip select support for McSPI Ben Gamari 2010-12-21 17:56 ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari 2 siblings, 1 reply; 29+ messages in thread From: Ben Gamari @ 2010-01-29 0:32 UTC (permalink / raw) To: Grant Likely; +Cc: spi-devel-general Excerpts from jassi brar's message of Wed Jan 27 23:33:20 -0500 2010: > On Thu, Jan 28, 2010 at 1:10 PM, Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Hey all! > > > > Recently I've been thinking about adding support to the McSPI driver for > > using GPIO pins as chip selects. As a starting point, I've browsed the > > driver source trying to identify what changes would be necessary to add > > this support. It seems like the rough idea is, > You may loot at drivers/spi/spi_s3c64xx.c in Grant Likely's tree. > Grant, I think that you might be missing a file in your spi-next branch. I've been unable to find <plat/s3c64xx-spi.h> as referenced in drivers/spi/spi_s3c64xx.c. I don't have an ARM toolchain to try compiling the tree at the moment, but both ctags and find have been unable to find this header. Sorry if I'm just being dense. Cheers, - Ben ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: McSPI questions pertaining to GPIO chip select support 2010-01-29 0:32 ` Ben Gamari @ 2010-01-29 1:09 ` jassi brar [not found] ` <1b68c6791001281709l7d11da30lee486632e85b99cb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: jassi brar @ 2010-01-29 1:09 UTC (permalink / raw) To: Ben Gamari; +Cc: spi-devel-general On Fri, Jan 29, 2010 at 9:32 AM, Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Excerpts from jassi brar's message of Wed Jan 27 23:33:20 -0500 2010: >> On Thu, Jan 28, 2010 at 1:10 PM, Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> > Hey all! >> > >> > Recently I've been thinking about adding support to the McSPI driver for >> > using GPIO pins as chip selects. As a starting point, I've browsed the >> > driver source trying to identify what changes would be necessary to add >> > this support. It seems like the rough idea is, >> You may loot at drivers/spi/spi_s3c64xx.c in Grant Likely's tree. >> > Grant, > > I think that you might be missing a file in your spi-next branch. I've > been unable to find <plat/s3c64xx-spi.h> as referenced in > drivers/spi/spi_s3c64xx.c. I don't have an ARM toolchain to try > compiling the tree at the moment, but both ctags and find have been > unable to find this header. Sorry if I'm just being dense. the arch/mach specific stuff will come via the SoC maintainer's(Ben Dooks) tree as I already mentioned. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1b68c6791001281709l7d11da30lee486632e85b99cb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: McSPI questions pertaining to GPIO chip select support [not found] ` <1b68c6791001281709l7d11da30lee486632e85b99cb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-01-29 1:58 ` Ben Gamari 0 siblings, 0 replies; 29+ messages in thread From: Ben Gamari @ 2010-01-29 1:58 UTC (permalink / raw) To: jassi brar; +Cc: spi-devel-general Excerpts from jassi brar's message of Thu Jan 28 20:09:47 -0500 2010: > the arch/mach specific stuff will come via the SoC maintainer's(Ben > Dooks) tree as I already mentioned. Crap. Sorry for the noise. Looks like I just need to learn to read. - Ben ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC PATCH] GPIO chip select support for McSPI [not found] ` <1b68c6791001272033q60dd31dbif4de285cd9bac83d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-01-29 0:32 ` Ben Gamari @ 2010-12-21 17:56 ` Ben Gamari 2010-12-21 17:56 ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari 2 siblings, 0 replies; 29+ messages in thread From: Ben Gamari @ 2010-12-21 17:56 UTC (permalink / raw) To: beagleboard, linux-omap, David Brownell, Eric Miao, Michael As you may recall, about a year ago I wrote wondering whether it was possible to use GPIO lines as chip selects in the McSPI driver. A few of you pointed out that this functionality had been added to other drivers and it should be quite simple to do the same for McSPI. Two semesters then passed without a followup from me. Thankfully, classes are over and I've had some downtime due to sickness, finally freeing up some time to look at this (just in time as we'll soon need this functionality). This morning I looked through the relevant code and put together this patch to add support for GPIO CSs. As was suggested, I modelled this after the approach taken in the s3c24xx-spi driver. Let me know whether this looks sane. It has yet to see hardware, but in principle things look alright (famous last words). Cheers, - Ben P.S. In case people are curious to see an example of usage I have a patch adding support for multiplexed chip selects to support a data acquisition board for the BeagleBoard that I've been working on[1]. I can send these out if people are interested. [1] http://goldnerlab.physics.umass.edu/wiki/BeagleBoardDaq ------------------------------------------------------------------------------ Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] mcspi: Add support for GPIO chip select lines [not found] ` <1b68c6791001272033q60dd31dbif4de285cd9bac83d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-01-29 0:32 ` Ben Gamari 2010-12-21 17:56 ` [RFC PATCH] GPIO chip select support for McSPI Ben Gamari @ 2010-12-21 17:56 ` Ben Gamari 2 siblings, 0 replies; 29+ messages in thread From: Ben Gamari @ 2010-12-21 17:56 UTC (permalink / raw) To: beagleboard, linux-omap, David Brownell, Eric Miao, Michael This mechanism is in large part stolen from the s3c64xx-spi module. To use this functionality, one simply must define a set_level function to set the CS state and a omap2_mcspi_csinfo struct for each chip select in the board file. Each spi_board_info.controller_data should then be set to point to the appropriate csinfo struct. This will cause the driver to call the csinfo->set_level function instead of toggling the McSPI chip select lines. Signed-off-by: Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> --- arch/arm/plat-omap/include/plat/mcspi.h | 14 ++++++++++++++ drivers/spi/omap2_mcspi.c | 14 +++++++++----- 2 files changed, 23 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/mcspi.h b/arch/arm/plat-omap/include/plat/mcspi.h index 1254e49..ab84b8d 100644 --- a/arch/arm/plat-omap/include/plat/mcspi.h +++ b/arch/arm/plat-omap/include/plat/mcspi.h @@ -1,6 +1,20 @@ #ifndef _OMAP2_MCSPI_H #define _OMAP2_MCSPI_H +/** + * struct omap2_mcspi_csinfo - Chip Select description + * @line: Custom 'identity' of the CS line + * @set_level: Function to set the state of a given CS line + * + * This is to allow use of GPIO lines as CS lines. Allocate and initialize one + * in the machine init code and make spi_board_info.controller_data point to + * it. + */ +struct omap2_mcspi_csinfo { + unsigned line; + void (*set_level)(unsigned line_id, int lvl); +}; + struct omap2_mcspi_platform_config { unsigned short num_cs; }; diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index 2a651e6..92ccbd6 100644 --- a/drivers/spi/omap2_mcspi.c +++ b/drivers/spi/omap2_mcspi.c @@ -35,6 +35,7 @@ #include <linux/slab.h> #include <linux/spi/spi.h> +#include <linux/gpio.h> #include <plat/dma.h> #include <plat/clock.h> @@ -235,11 +236,14 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable) static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active) { - u32 l; - - l = mcspi_cached_chconf0(spi); - MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); - mcspi_write_chconf0(spi, l); + if (spi->controller_data) { + struct omap2_mcspi_csinfo *csinfo = spi->controller_data; + (*csinfo->set_level)(csinfo->line, cs_active); + } else { + u32 l = mcspi_cached_chconf0(spi); + MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); + mcspi_write_chconf0(spi, l); + } } static void omap2_mcspi_set_master_mode(struct spi_master *master) -- 1.7.1 ------------------------------------------------------------------------------ Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew ^ permalink raw reply related [flat|nested] 29+ messages in thread
[parent not found: <1292954195-20204-2-git-send-email-bgamari.foss@gmail.com>]
* Re: [PATCH] mcspi: Add support for GPIO chip select lines [not found] ` <1292954195-20204-2-git-send-email-bgamari.foss@gmail.com> @ 2010-12-23 19:59 ` Tony Lindgren 2010-12-23 21:38 ` Grant Likely 1 sibling, 0 replies; 29+ messages in thread From: Tony Lindgren @ 2010-12-23 19:59 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, Grant Likely, spi-devel-general * Ben Gamari <bgamari.foss@gmail.com> [101221 09:56]: > This mechanism is in large part stolen from the s3c64xx-spi module. To > use this functionality, one simply must define a set_level function to > set the CS state and a omap2_mcspi_csinfo struct for each chip select in > the board file. > > Each spi_board_info.controller_data should then be set > to point to the appropriate csinfo struct. This will cause the driver to > call the csinfo->set_level function instead of toggling the McSPI chip > select lines. > > Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> This one should go via the SPI list: Acked-by: Tony Lindgren <tony@atomide.com> > --- > arch/arm/plat-omap/include/plat/mcspi.h | 14 ++++++++++++++ > drivers/spi/omap2_mcspi.c | 14 +++++++++----- > 2 files changed, 23 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/mcspi.h b/arch/arm/plat-omap/include/plat/mcspi.h > index 1254e49..ab84b8d 100644 > --- a/arch/arm/plat-omap/include/plat/mcspi.h > +++ b/arch/arm/plat-omap/include/plat/mcspi.h > @@ -1,6 +1,20 @@ > #ifndef _OMAP2_MCSPI_H > #define _OMAP2_MCSPI_H > > +/** > + * struct omap2_mcspi_csinfo - Chip Select description > + * @line: Custom 'identity' of the CS line > + * @set_level: Function to set the state of a given CS line > + * > + * This is to allow use of GPIO lines as CS lines. Allocate and initialize one > + * in the machine init code and make spi_board_info.controller_data point to > + * it. > + */ > +struct omap2_mcspi_csinfo { > + unsigned line; > + void (*set_level)(unsigned line_id, int lvl); > +}; > + > struct omap2_mcspi_platform_config { > unsigned short num_cs; > }; > diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c > index 2a651e6..92ccbd6 100644 > --- a/drivers/spi/omap2_mcspi.c > +++ b/drivers/spi/omap2_mcspi.c > @@ -35,6 +35,7 @@ > #include <linux/slab.h> > > #include <linux/spi/spi.h> > +#include <linux/gpio.h> > > #include <plat/dma.h> > #include <plat/clock.h> > @@ -235,11 +236,14 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable) > > static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active) > { > - u32 l; > - > - l = mcspi_cached_chconf0(spi); > - MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); > - mcspi_write_chconf0(spi, l); > + if (spi->controller_data) { > + struct omap2_mcspi_csinfo *csinfo = spi->controller_data; > + (*csinfo->set_level)(csinfo->line, cs_active); > + } else { > + u32 l = mcspi_cached_chconf0(spi); > + MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); > + mcspi_write_chconf0(spi, l); > + } > } > > static void omap2_mcspi_set_master_mode(struct spi_master *master) > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines [not found] ` <1292954195-20204-2-git-send-email-bgamari.foss@gmail.com> 2010-12-23 19:59 ` Tony Lindgren @ 2010-12-23 21:38 ` Grant Likely 2010-12-23 23:09 ` Ben Gamari 1 sibling, 1 reply; 29+ messages in thread From: Grant Likely @ 2010-12-23 21:38 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, spi-devel-general On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari <bgamari.foss@gmail.com> wrote: > This mechanism is in large part stolen from the s3c64xx-spi module. To > use this functionality, one simply must define a set_level function to > set the CS state and a omap2_mcspi_csinfo struct for each chip select in > the board file. > > Each spi_board_info.controller_data should then be set > to point to the appropriate csinfo struct. This will cause the driver to > call the csinfo->set_level function instead of toggling the McSPI chip > select lines. > > Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> I'd rather see the spi driver modified to use the gpio api directly. The drivers are already tending in that direction and it doesn't require machine specific set_level functions to be defined. g. > --- > arch/arm/plat-omap/include/plat/mcspi.h | 14 ++++++++++++++ > drivers/spi/omap2_mcspi.c | 14 +++++++++----- > 2 files changed, 23 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/mcspi.h b/arch/arm/plat-omap/include/plat/mcspi.h > index 1254e49..ab84b8d 100644 > --- a/arch/arm/plat-omap/include/plat/mcspi.h > +++ b/arch/arm/plat-omap/include/plat/mcspi.h > @@ -1,6 +1,20 @@ > #ifndef _OMAP2_MCSPI_H > #define _OMAP2_MCSPI_H > > +/** > + * struct omap2_mcspi_csinfo - Chip Select description > + * @line: Custom 'identity' of the CS line > + * @set_level: Function to set the state of a given CS line > + * > + * This is to allow use of GPIO lines as CS lines. Allocate and initialize one > + * in the machine init code and make spi_board_info.controller_data point to > + * it. > + */ > +struct omap2_mcspi_csinfo { > + unsigned line; > + void (*set_level)(unsigned line_id, int lvl); > +}; > + > struct omap2_mcspi_platform_config { > unsigned short num_cs; > }; > diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c > index 2a651e6..92ccbd6 100644 > --- a/drivers/spi/omap2_mcspi.c > +++ b/drivers/spi/omap2_mcspi.c > @@ -35,6 +35,7 @@ > #include <linux/slab.h> > > #include <linux/spi/spi.h> > +#include <linux/gpio.h> > > #include <plat/dma.h> > #include <plat/clock.h> > @@ -235,11 +236,14 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable) > > static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active) > { > - u32 l; > - > - l = mcspi_cached_chconf0(spi); > - MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); > - mcspi_write_chconf0(spi, l); > + if (spi->controller_data) { > + struct omap2_mcspi_csinfo *csinfo = spi->controller_data; > + (*csinfo->set_level)(csinfo->line, cs_active); > + } else { > + u32 l = mcspi_cached_chconf0(spi); > + MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); > + mcspi_write_chconf0(spi, l); > + } > } > > static void omap2_mcspi_set_master_mode(struct spi_master *master) > -- > 1.7.1 > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines 2010-12-23 21:38 ` Grant Likely @ 2010-12-23 23:09 ` Ben Gamari 2010-12-24 0:37 ` Grant Likely 0 siblings, 1 reply; 29+ messages in thread From: Ben Gamari @ 2010-12-23 23:09 UTC (permalink / raw) To: Grant Likely Cc: beagleboard, linux-omap, David Brownell, Eric Miao, Michael Hennerich, spi-devel-general On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely <grant.likely@secretlab.ca> wrote: > On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari <bgamari.foss@gmail.com> wrote: > > This mechanism is in large part stolen from the s3c64xx-spi module. To > > use this functionality, one simply must define a set_level function to > > set the CS state and a omap2_mcspi_csinfo struct for each chip select in > > the board file. > > > > Each spi_board_info.controller_data should then be set > > to point to the appropriate csinfo struct. This will cause the driver to > > call the csinfo->set_level function instead of toggling the McSPI chip > > select lines. > > > > Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> > > I'd rather see the spi driver modified to use the gpio api directly. > The drivers are already tending in that direction and it doesn't > require machine specific set_level functions to be defined. > The reason I left this up to the board is it's easy to foresee cases where you want a non-trivial mapping between logical CS numbers and CS pin states. In my case, I using a 2-to-4 multiplexer as the source of chip select. - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines 2010-12-23 23:09 ` Ben Gamari @ 2010-12-24 0:37 ` Grant Likely 2010-12-24 2:27 ` Ben Gamari 0 siblings, 1 reply; 29+ messages in thread From: Grant Likely @ 2010-12-24 0:37 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Michael Hennerich, spi-devel-general, Eric Miao On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari <bgamari.foss@gmail.com> wrote: > On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely <grant.likely@secretlab.ca> wrote: >> On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari <bgamari.foss@gmail.com> wrote: >> > This mechanism is in large part stolen from the s3c64xx-spi module. To >> > use this functionality, one simply must define a set_level function to >> > set the CS state and a omap2_mcspi_csinfo struct for each chip select in >> > the board file. >> > >> > Each spi_board_info.controller_data should then be set >> > to point to the appropriate csinfo struct. This will cause the driver to >> > call the csinfo->set_level function instead of toggling the McSPI chip >> > select lines. >> > >> > Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> >> >> I'd rather see the spi driver modified to use the gpio api directly. >> The drivers are already tending in that direction and it doesn't >> require machine specific set_level functions to be defined. >> > The reason I left this up to the board is it's easy to foresee cases > where you want a non-trivial mapping between logical CS numbers and CS > pin states. In my case, I using a 2-to-4 multiplexer as the source of > chip select. Hi Ben, I understand and appreciate the motivation. However in practice, the gpio api is sufficient for pretty much any use case, even when the backing gpio controller driver ends up driving some oddball device with different constraints. The big downside to using a callback is that it forces all users to do the extra work of implementing the callback. With the gpio api, only the oddball cases have to do extra code (to adapt the custom device to the gpio api). g. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines 2010-12-24 0:37 ` Grant Likely @ 2010-12-24 2:27 ` Ben Gamari 2010-12-24 3:28 ` Grant Likely 0 siblings, 1 reply; 29+ messages in thread From: Ben Gamari @ 2010-12-24 2:27 UTC (permalink / raw) To: Grant Likely Cc: beagleboard, linux-omap, David Brownell, Michael Hennerich, spi-devel-general, Eric Miao On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely <grant.likely@secretlab.ca> wrote: > On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari <bgamari.foss@gmail.com> wrote: > > The reason I left this up to the board is it's easy to foresee cases > > where you want a non-trivial mapping between logical CS numbers and CS > > pin states. In my case, I using a 2-to-4 multiplexer as the source of > > chip select. > > Hi Ben, > > I understand and appreciate the motivation. However in practice, the > gpio api is sufficient for pretty much any use case, even when the > backing gpio controller driver ends up driving some oddball device > with different constraints. The big downside to using a callback is > that it forces all users to do the extra work of implementing the > callback. With the gpio api, only the oddball cases have to do extra > code (to adapt the custom device to the gpio api). I understand your concerns, but I'm not sure how to satisfy them without crippling the design's ability to accomodate my use-case. I can't pass a GPIO line per spi_board_info since in my case of a multiplexed CS configuration a single pin's state does not uniquely determine the desired CS. The only other option I can think of is that we somehow provide a list of GPIOs for each bus and map the CS numbers to permutations of GPIO states. Unfortunately, I don't know of any suitable structure to put this GPIO list in. Perhaps I'm missing something obvious? - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines 2010-12-24 2:27 ` Ben Gamari @ 2010-12-24 3:28 ` Grant Likely 2010-12-24 6:05 ` Ben Gamari 0 siblings, 1 reply; 29+ messages in thread From: Grant Likely @ 2010-12-24 3:28 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Michael Hennerich, spi-devel-general, Eric Miao On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote: > On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely <grant.likely@secretlab.ca> wrote: > > On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari <bgamari.foss@gmail.com> wrote: > > > The reason I left this up to the board is it's easy to foresee cases > > > where you want a non-trivial mapping between logical CS numbers and CS > > > pin states. In my case, I using a 2-to-4 multiplexer as the source of > > > chip select. > > > > Hi Ben, > > > > I understand and appreciate the motivation. However in practice, the > > gpio api is sufficient for pretty much any use case, even when the > > backing gpio controller driver ends up driving some oddball device > > with different constraints. The big downside to using a callback is > > that it forces all users to do the extra work of implementing the > > callback. With the gpio api, only the oddball cases have to do extra > > code (to adapt the custom device to the gpio api). > > I understand your concerns, but I'm not sure how to satisfy them without > crippling the design's ability to accomodate my use-case. I can't pass a > GPIO line per spi_board_info since in my case of a multiplexed CS > configuration a single pin's state does not uniquely determine the > desired CS. The only other option I can think of is that we somehow > provide a list of GPIOs for each bus and map the CS numbers to > permutations of GPIO states. Unfortunately, I don't know of any suitable > structure to put this GPIO list in. Perhaps I'm missing something obvious? Close, but not quite. Assign one gpio number to each cs state, and write a gpio controller driver that maps the linux-gpio number to the physical gpio state permutation. The mapping from gpio# to ss# is 1:1, but the driver behind the gpio# can do whatever you need it to do. g. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines 2010-12-24 3:28 ` Grant Likely @ 2010-12-24 6:05 ` Ben Gamari 2011-02-12 8:33 ` Grant Likely 0 siblings, 1 reply; 29+ messages in thread From: Ben Gamari @ 2010-12-24 6:05 UTC (permalink / raw) To: Grant Likely Cc: beagleboard, linux-omap, David Brownell, Michael Hennerich, spi-devel-general, Eric Miao On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely <grant.likely@secretlab.ca> wrote: > On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote: > > I understand your concerns, but I'm not sure how to satisfy them without > > crippling the design's ability to accomodate my use-case. I can't pass a > > GPIO line per spi_board_info since in my case of a multiplexed CS > > configuration a single pin's state does not uniquely determine the > > desired CS. The only other option I can think of is that we somehow > > provide a list of GPIOs for each bus and map the CS numbers to > > permutations of GPIO states. Unfortunately, I don't know of any suitable > > structure to put this GPIO list in. Perhaps I'm missing something obvious? > > Close, but not quite. Assign one gpio number to each cs state, and > write a gpio controller driver that maps the linux-gpio number to the > physical gpio state permutation. The mapping from gpio# to ss# is > 1:1, but the driver behind the gpio# can do whatever you need it to > do. > I see. I'm still not convinced that this is the route to take, however. It seems like this virtual gpio interface is not only pretty clunky (simple board file glue turns into an entire gpio chip driver), it seems like this is a very inaccurate and not very useful way to expose a multiplexed CS configuration; e.g. what is this chip driver to do if the user tries to set two CS pins at once? Is there precedent for using the GPIO subsystem in this way? Cheers, - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines 2010-12-24 6:05 ` Ben Gamari @ 2011-02-12 8:33 ` Grant Likely 2011-02-13 22:07 ` Ben Gamari 0 siblings, 1 reply; 29+ messages in thread From: Grant Likely @ 2011-02-12 8:33 UTC (permalink / raw) To: Ben Gamari Cc: beagleboard, linux-omap, David Brownell, Michael Hennerich, spi-devel-general, Eric Miao On Fri, Dec 24, 2010 at 01:05:56AM -0500, Ben Gamari wrote: > On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely <grant.likely@secretlab.ca> wrote: > > On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote: > > > I understand your concerns, but I'm not sure how to satisfy them without > > > crippling the design's ability to accomodate my use-case. I can't pass a > > > GPIO line per spi_board_info since in my case of a multiplexed CS > > > configuration a single pin's state does not uniquely determine the > > > desired CS. The only other option I can think of is that we somehow > > > provide a list of GPIOs for each bus and map the CS numbers to > > > permutations of GPIO states. Unfortunately, I don't know of any suitable > > > structure to put this GPIO list in. Perhaps I'm missing something obvious? > > > > Close, but not quite. Assign one gpio number to each cs state, and > > write a gpio controller driver that maps the linux-gpio number to the > > physical gpio state permutation. The mapping from gpio# to ss# is > > 1:1, but the driver behind the gpio# can do whatever you need it to > > do. > > > I see. I'm still not convinced that this is the route to take, > however. It seems like this virtual gpio interface is not only pretty > clunky (simple board file glue turns into an entire gpio chip driver), > it seems like this is a very inaccurate and not very useful way to > expose a multiplexed CS configuration; e.g. what is this chip driver to > do if the user tries to set two CS pins at once? (Sorry for the really laggy reply) I don't see it being that big a deal. gpio drivers are pretty lightweight and it is fine to have domain-specific limitations on how gpios for a particular "gpio controller" behave. In your example, if the hardware doesn't support enabling 2 CS pins at once, then you make a choice, either setting one when the other is already set simply does not work; or it could reset the other state. Either choice would be fine. The SPI driver must do the right thing regardless and deselect the previous CS line before enabling a new one. The other alternative would be to implement a new SPI chipselect common infrastructure, but IMO, that would just end up looking like a duplication of the gpio infrastructure. Regardless, my point still stands, platform callbacks for what amounts to gpio manipulations doesn't make a whole lot of sense. > Is there precedent for > using the GPIO subsystem in this way? Yes, in drivers/spi look at mpc52xx_spi.c, davinci_spi.c, ath79_spi.c, atmel_spi.c, and many more. Grep for gpio in drivers/spi. g. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] mcspi: Add support for GPIO chip select lines 2011-02-12 8:33 ` Grant Likely @ 2011-02-13 22:07 ` Ben Gamari 0 siblings, 0 replies; 29+ messages in thread From: Ben Gamari @ 2011-02-13 22:07 UTC (permalink / raw) To: Grant Likely Cc: beagleboard, linux-omap, David Brownell, Michael Hennerich, spi-devel-general, Eric Miao On Sat, 12 Feb 2011 01:33:24 -0700, Grant Likely <grant.likely@secretlab.ca> wrote: > (Sorry for the really laggy reply) > No worries, I was just starting to think about this again myself. > I don't see it being that big a deal. gpio drivers are pretty > lightweight and it is fine to have domain-specific limitations on how > gpios for a particular "gpio controller" behave. In your example, if > the hardware doesn't support enabling 2 CS pins at once, then you make > a choice, either setting one when the other is already set simply does > not work; or it could reset the other state. Either choice would be > fine. The SPI driver must do the right thing regardless and deselect > the previous CS line before enabling a new one. > Having now finally having had a chance to implement a gpio_chip driver, I agree. It's quite simple and seems to fill the need pretty well > The other alternative would be to implement a new SPI chipselect > common infrastructure, but IMO, that would just end up looking like a > duplication of the gpio infrastructure. > I think you are probably right. GPIO seems to be a good fit. Patch coming shortly. I use spi_board_info.controller_data to pass the gpio number to the controller which doesn't seem like the best way forward, but I wasn't sure how else to proceed. Also, since the gpio numbers are dynamically determined spi_board_info.controller_data must be filled in at runtime, which is also a bit of a bummer (although not easily solved as far as I can tell). Let me know what you think. - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: McSPI questions pertaining to GPIO chip select support [not found] ` <1264651770-sup-5197@ben-laptop> 2010-01-28 4:15 ` Bill Gatliff 2010-01-28 4:33 ` jassi brar @ 2011-08-30 10:14 ` Raju Sana 2011-08-30 13:50 ` Ben Gamari 2 siblings, 1 reply; 29+ messages in thread From: Raju Sana @ 2011-08-30 10:14 UTC (permalink / raw) To: Ben Gamari Cc: David Brownell, Michael Hennerich, beagleboard, Eric Miao, spi-devel-general, linux-omap Hi Ben, Could you please post your patch as I am also working the similar design. I need to modify the existing McSPI driver to support 3 codec chips. Thanks. Venkat Raju. On Thu, Jan 28, 2010 at 9:40 AM, Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Hey all! > > Recently I've been thinking about adding support to the McSPI driver for > using GPIO pins as chip selects. As a starting point, I've browsed the > driver source trying to identify what changes would be necessary to add > this support. It seems like the rough idea is, > > a) add a cs_gpio field to the device struct (omap2_mcspi) > b) modify omap2_mcspi_force_cs() to use cs_gpio instead of the > CHxCONF[FORCE] bit if cs_gpio is valid > > Unfortunately, I'm having a bit of difficulty seeing how the existing > configuration works. In master mode, it seems that the controller is > configured in single forced channel mode (MCSPI_MODULECTRL_SINGLE). As > far as I can tell, this means that the driver is responsible for > managing the chip selects through the MCSPI_CHxCONF[FORCE] bits. It > seems that this is ideal as little will need to be changed to > incorporate GPIO CS support. > > Nevertheless, the timing of the various operations isn't making sense to > me. As far as I understand it, the callgraph is as follows, > > > omap2_mcspi_work(): > loop over messages > omap2_mcspi_set_enable(1) > loop over transfers: > configure bus parameters > if (!cs_active) cs = 1 > if (dma): > omap2_mcspi_txrx_dma() > else: > omap2_mcspi_txrx_pio() > if (cs_change) cs = 0 > end loop > > if (cs_active) cs = 0 > omap2_mcspi_set_enable(0) > end loop > > > It seems that omap2_mcspi_set_enable() is called to enable the channel > (MCSPI_CHCTRLx[EN] is set) before force_cs() is called. If I'm > interpreting the hardware documentation correctly, the enable bit (among > other things) starts the SPI clock, meaning that the chip will begin > clocking out zeros to the device before CS is brought high. > Furthermore, even after CS is brought high, it seems there could be a > fair amount of time before the chip begins actually clocking out valid > data. > > As I am writing this, it now occurs to me that perhaps the chip doesn't > start SPI_CLK until it has data to send. It seems that if this were the > case my concerns would be resolved. However, it is not at all clear that > this is the case from the documentation. When exactly does the > controller start the bus clock? Is this stated explicitly anywhere in > the documentation? > > Any input you could offer would be greatly appreciated. > Thanks for your time. > > - Ben > > > P.S. The more and more I think about it, it seems like my hypothesis is > the only logical behavior. It would be great if someone could confirm my > suspicions, however. It really seems like this should be in the > documentation either way. > > P.P.S. I apologize if this is something someone familiar with SPI should > just know. My knowledge is a little spotty on this sort of thing. > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ^ permalink raw reply [flat|nested] 29+ messages in thread
* GPIO chip select support 2011-08-30 10:14 ` McSPI questions pertaining to GPIO chip select support Raju Sana @ 2011-08-30 13:50 ` Ben Gamari 2011-08-30 13:50 ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari 2011-08-30 13:52 ` [PATCH] beagledaq: Hack in cs_gpios Ben Gamari 0 siblings, 2 replies; 29+ messages in thread From: Ben Gamari @ 2011-08-30 13:50 UTC (permalink / raw) To: Raju Sana; +Cc: beagleboard, linux-omap, spi-devel-general Thanks for the poke. I've been meaning to send this set out again anyways. This is the patch I am currently using (on top of v3.0). Conceptually it's quite similar to the first patches I sent out but some implementation details were slightly reworked to account for the generalization of the McSPI driver to other silicon. I would say that the patch is close to mergable save the fact that there is currently no clean way to set up GPIO CS pins from a board file. I'll send the horrible hack I currently use shortly. If anyone has any ideas on how this might be done cleanly please let me know. It's sad that the mere lack of a configuration interface is the reason this isn't upstream. Cheers, - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] mcspi: Add support for GPIO chip select lines 2011-08-30 13:50 ` Ben Gamari @ 2011-08-30 13:50 ` Ben Gamari 2011-08-30 13:52 ` [PATCH] beagledaq: Hack in cs_gpios Ben Gamari 1 sibling, 0 replies; 29+ messages in thread From: Ben Gamari @ 2011-08-30 13:50 UTC (permalink / raw) To: Raju Sana; +Cc: beagleboard, linux-omap, spi-devel-general, Ben Gamari Many applications require more chip select lines than the board or processor allow. Introduce a mechanism to allow use of GPIO pins as chip select lines with the McSPI controller. To use this tionality, one simply provides a table mapping CS line numbers to GPIO numbers omap2_mcspi_platform_config.cs_gpios. Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> --- arch/arm/plat-omap/include/plat/mcspi.h | 1 + drivers/spi/omap2_mcspi.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/mcspi.h b/arch/arm/plat-omap/include/plat/mcspi.h index 3d51b18..c5670f2 100644 --- a/arch/arm/plat-omap/include/plat/mcspi.h +++ b/arch/arm/plat-omap/include/plat/mcspi.h @@ -10,6 +10,7 @@ struct omap2_mcspi_platform_config { unsigned short num_cs; unsigned int regs_offset; + int *cs_gpios; }; struct omap2_mcspi_dev_attr { diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index f41c906..20dec5d 100644 --- a/drivers/spi/omap2_mcspi.c +++ b/drivers/spi/omap2_mcspi.c @@ -36,6 +36,7 @@ #include <linux/pm_runtime.h> #include <linux/spi/spi.h> +#include <linux/gpio.h> #include <plat/dma.h> #include <plat/clock.h> @@ -121,6 +122,7 @@ struct omap2_mcspi { /* SPI1 has 4 channels, while SPI2 has 2 */ struct omap2_mcspi_dma *dma_channels; struct device *dev; + int *cs_gpios; }; struct omap2_mcspi_cs { @@ -227,7 +229,11 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable) static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active) { u32 l; + struct omap2_mcspi* mcspi = spi_master_get_devdata(spi->master); + if (mcspi->cs_gpios) + gpio_set_value(mcspi->cs_gpios[spi->chip_select], cs_active); + // TXS times out unless we force the CHCONF reg as well l = mcspi_cached_chconf0(spi); MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); mcspi_write_chconf0(spi, l); @@ -1088,6 +1094,8 @@ static int __init omap2_mcspi_probe(struct platform_device *pdev) struct omap2_mcspi *mcspi; struct resource *r; int status = 0, i; + struct omap2_mcspi_platform_config* pconfig = pdev->dev.platform_data; + int num_dma; master = spi_alloc_master(&pdev->dev, sizeof *mcspi); if (master == NULL) { @@ -1110,6 +1118,13 @@ static int __init omap2_mcspi_probe(struct platform_device *pdev) mcspi = spi_master_get_devdata(master); mcspi->master = master; + if (pconfig && pconfig->cs_gpios) { + mcspi->cs_gpios = pconfig->cs_gpios; + num_dma = 1; + } else { + mcspi->cs_gpios = NULL; + num_dma = master->num_chipselect; + } r = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (r == NULL) { @@ -1139,14 +1154,14 @@ static int __init omap2_mcspi_probe(struct platform_device *pdev) INIT_LIST_HEAD(&mcspi->msg_queue); INIT_LIST_HEAD(&omap2_mcspi_ctx[master->bus_num - 1].cs); - mcspi->dma_channels = kcalloc(master->num_chipselect, + mcspi->dma_channels = kcalloc(num_dma, sizeof(struct omap2_mcspi_dma), GFP_KERNEL); if (mcspi->dma_channels == NULL) goto err2; - for (i = 0; i < master->num_chipselect; i++) { + for (i = 0; i < num_dma; i++) { char dma_ch_name[14]; struct resource *dma_res; -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [PATCH] beagledaq: Hack in cs_gpios 2011-08-30 13:50 ` Ben Gamari 2011-08-30 13:50 ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari @ 2011-08-30 13:52 ` Ben Gamari [not found] ` <1314712343-27367-1-git-send-email-bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 29+ messages in thread From: Ben Gamari @ 2011-08-30 13:52 UTC (permalink / raw) To: Raju Sana; +Cc: beagleboard, linux-omap, spi-devel-general, Ben Gamari --- arch/arm/mach-omap2/board-omap3beagle.c | 4 ++-- arch/arm/mach-omap2/devices.c | 15 +++++++++++++++ 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 67999da..481c1a9 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -661,8 +661,8 @@ static struct spi_board_info beagledaq_mcspi_board_info[] = { }, }; -static int mcspi3_cs_gpios[4]; -static int mcspi4_cs_gpios[4]; +int mcspi3_cs_gpios[4]; +int mcspi4_cs_gpios[4]; static void __init beagledaq_init(void) { diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 5b8ca68..6808251 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -341,6 +341,9 @@ struct omap_device_pm_latency omap_mcspi_latency[] = { }, }; +extern int mcspi3_cs_gpios[4]; +extern int mcspi4_cs_gpios[4]; + static int omap_mcspi_init(struct omap_hwmod *oh, void *unused) { struct omap_device *od; @@ -369,6 +372,18 @@ static int omap_mcspi_init(struct omap_hwmod *oh, void *unused) return -EINVAL; } + /* HACK: Not enough time to figure out how to export cs_gpios from + * board file to driver correctly */ + if (spi_num == 2) { + // Setup McSPI3 cs_gpios + pdata->num_cs = 4; + pdata->cs_gpios = mcspi3_cs_gpios; + } else if (spi_num == 3) { + // Setup McSPI4 cs_gpios + pdata->num_cs = 4; + pdata->cs_gpios = mcspi4_cs_gpios; + } + spi_num++; od = omap_device_build(name, spi_num, oh, pdata, sizeof(*pdata), omap_mcspi_latency, -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
[parent not found: <1314712343-27367-1-git-send-email-bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH] beagledaq: Hack in cs_gpios [not found] ` <1314712343-27367-1-git-send-email-bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2011-09-05 12:42 ` Raju Sana 0 siblings, 0 replies; 29+ messages in thread From: Raju Sana @ 2011-09-05 12:42 UTC (permalink / raw) To: Ben Gamari Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, beagleboard-/JYPxA39Uh5TLH3MbocFFw, linux-omap-u79uwXL29TY76Z2rM5mHXA Hi Ben, The McSPI1 has got "num_cs" as 4. I would like to use McSPI1 to select my 3 chips based on the two GPIO pins. Could you please give me some pointers on this. Thanks, Venkat Raju. On Tue, Aug 30, 2011 at 7:22 PM, Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > --- > arch/arm/mach-omap2/board-omap3beagle.c | 4 ++-- > arch/arm/mach-omap2/devices.c | 15 +++++++++++++++ > 2 files changed, 17 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-omap3beagle.c > b/arch/arm/mach-omap2/board-omap3beagle.c > index 67999da..481c1a9 100644 > --- a/arch/arm/mach-omap2/board-omap3beagle.c > +++ b/arch/arm/mach-omap2/board-omap3beagle.c > @@ -661,8 +661,8 @@ static struct spi_board_info > beagledaq_mcspi_board_info[] = { > }, > }; > > -static int mcspi3_cs_gpios[4]; > -static int mcspi4_cs_gpios[4]; > +int mcspi3_cs_gpios[4]; > +int mcspi4_cs_gpios[4]; > > static void __init beagledaq_init(void) > { > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c > index 5b8ca68..6808251 100644 > --- a/arch/arm/mach-omap2/devices.c > +++ b/arch/arm/mach-omap2/devices.c > @@ -341,6 +341,9 @@ struct omap_device_pm_latency omap_mcspi_latency[] = { > }, > }; > > +extern int mcspi3_cs_gpios[4]; > +extern int mcspi4_cs_gpios[4]; > + > static int omap_mcspi_init(struct omap_hwmod *oh, void *unused) > { > struct omap_device *od; > @@ -369,6 +372,18 @@ static int omap_mcspi_init(struct omap_hwmod *oh, void > *unused) > return -EINVAL; > } > > + /* HACK: Not enough time to figure out how to export cs_gpios from > + * board file to driver correctly */ > + if (spi_num == 2) { > + // Setup McSPI3 cs_gpios > + pdata->num_cs = 4; > + pdata->cs_gpios = mcspi3_cs_gpios; > + } else if (spi_num == 3) { > + // Setup McSPI4 cs_gpios > + pdata->num_cs = 4; > + pdata->cs_gpios = mcspi4_cs_gpios; > + } > + > spi_num++; > od = omap_device_build(name, spi_num, oh, pdata, > sizeof(*pdata), omap_mcspi_latency, > -- > 1.7.4.1 > > ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2011-09-05 12:42 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-01-20 19:47 (no subject) Ben Gamari 2010-01-21 0:04 ` Ben Dooks 2010-01-21 0:04 ` (no subject) Ben Dooks 2010-01-21 0:04 ` Ben Dooks 2010-01-22 15:53 ` Re: Ben Gamari 2010-01-28 4:10 ` McSPI questions pertaining to GPIO chip select support Ben Gamari [not found] ` <1264651770-sup-5197@ben-laptop> 2010-01-28 4:15 ` Bill Gatliff 2010-01-28 4:25 ` Ben Gamari 2010-01-28 4:27 ` Bill Gatliff 2010-01-28 4:33 ` jassi brar [not found] ` <1b68c6791001272033q60dd31dbif4de285cd9bac83d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-01-29 0:32 ` Ben Gamari 2010-01-29 1:09 ` jassi brar [not found] ` <1b68c6791001281709l7d11da30lee486632e85b99cb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-01-29 1:58 ` Ben Gamari 2010-12-21 17:56 ` [RFC PATCH] GPIO chip select support for McSPI Ben Gamari 2010-12-21 17:56 ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari [not found] ` <1292954195-20204-2-git-send-email-bgamari.foss@gmail.com> 2010-12-23 19:59 ` Tony Lindgren 2010-12-23 21:38 ` Grant Likely 2010-12-23 23:09 ` Ben Gamari 2010-12-24 0:37 ` Grant Likely 2010-12-24 2:27 ` Ben Gamari 2010-12-24 3:28 ` Grant Likely 2010-12-24 6:05 ` Ben Gamari 2011-02-12 8:33 ` Grant Likely 2011-02-13 22:07 ` Ben Gamari 2011-08-30 10:14 ` McSPI questions pertaining to GPIO chip select support Raju Sana 2011-08-30 13:50 ` Ben Gamari 2011-08-30 13:50 ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari 2011-08-30 13:52 ` [PATCH] beagledaq: Hack in cs_gpios Ben Gamari [not found] ` <1314712343-27367-1-git-send-email-bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-09-05 12:42 ` Raju Sana
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).