* (no subject)
@ 2010-01-20 19:47 Ben Gamari
2010-01-21 0:04 ` Ben Dooks
` (5 more replies)
0 siblings, 6 replies; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread
* Re:
@ 2015-09-01 12:01 Zariya
0 siblings, 0 replies; 36+ messages in thread
From: Zariya @ 2015-09-01 12:01 UTC (permalink / raw)
To: Recipients
Help me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you
Yours
ZariyaHelp me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you
Yours
Zariya
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re:
@ 2015-09-01 16:06 Zariya
0 siblings, 0 replies; 36+ messages in thread
From: Zariya @ 2015-09-01 16:06 UTC (permalink / raw)
To: Recipients
Help me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you
Yours
ZariyaHelp me and my 2 kids here in Syria We will share the 6,600,000 USD
I have here with you for your help, sorry to mention it
we want to leave Syria, put the kids in school and buy a new home
You will give us guidance when we arrive Their father died in the chemical weapon airstrike
I will send you our family pictures and more details as I read from you
Yours
Zariya
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE:
@ 2017-02-23 15:09 Qin's Yanjun
0 siblings, 0 replies; 36+ messages in thread
From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw)
How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which. Looking forward to read from you soon.
Qin's
______________________________
Sky Silk, http://aknet.kz
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re:
@ 2017-11-13 14:55 Amos Kalonzo
0 siblings, 0 replies; 36+ messages in thread
From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw)
Attn:
I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.
Best Regards
Amos Kalonzo
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re:
@ 2020-02-06 6:36 Viviane Jose Pereira
0 siblings, 0 replies; 36+ messages in thread
From: Viviane Jose Pereira @ 2020-02-06 6:36 UTC (permalink / raw)
--
Hallo, ich entschuldige mich dafür, dass ich deine Privatsphäre gestört habe. Ich kontaktiere Sie für eine äußerst dringende und vertrauliche Angelegenheit.
Ihnen wurde eine Spende von 15.000.000,00 EUR angeboten Kontakt: cristtom063@gmail.com für weitere Informationen.
Dies ist keine Spam-Nachricht, sondern eine wichtige Mitteilung an Sie. Antworten Sie auf die obige E-Mail, um immer mehr Informationen über die Spende und den Erhalt von Geldern zu erhalten.
^ permalink raw reply [flat|nested] 36+ messages in thread
* (unknown)
@ 2020-02-11 22:34 Rajat Jain
[not found] ` <20200211223400.107604-1-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 36+ messages in thread
From: Rajat Jain @ 2020-02-11 22:34 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Mark Brown,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Evan Green, rajatja-hpIqsD4AKlfQT0dZR+AlfA,
rajatxjain-Re5JQEeQqe8AvxtiuMwx3w,
evgreen-hpIqsD4AKlfQT0dZR+AlfA,
shobhit.srivastava-ral2JQCrhuEAvxtiuMwx3w,
porselvan.muthukrishnan-ral2JQCrhuEAvxtiuMwx3w
From: Evan Green <evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Date: Wed, 29 Jan 2020 13:54:16 -0800
Subject: [PATCH] spi: pxa2xx: Add CS control clock quirk
In some circumstances on Intel LPSS controllers, toggling the LPSS
CS control register doesn't actually cause the CS line to toggle.
This seems to be failure of dynamic clock gating that occurs after
going through a suspend/resume transition, where the controller
is sent through a reset transition. This ruins SPI transactions
that either rely on delay_usecs, or toggle the CS line without
sending data.
Whenever CS is toggled, momentarily set the clock gating register
to "Force On" to poke the controller into acting on CS.
Signed-off-by: Evan Green <evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
drivers/spi/spi-pxa2xx.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4c7a71f0fb3e..2e318158fca9 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -70,6 +70,10 @@ MODULE_ALIAS("platform:pxa2xx-spi");
#define LPSS_CAPS_CS_EN_SHIFT 9
#define LPSS_CAPS_CS_EN_MASK (0xf << LPSS_CAPS_CS_EN_SHIFT)
+#define LPSS_PRIV_CLOCK_GATE 0x38
+#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK 0x3
+#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON 0x3
+
struct lpss_config {
/* LPSS offset from drv_data->ioaddr */
unsigned offset;
@@ -86,6 +90,8 @@ struct lpss_config {
unsigned cs_sel_shift;
unsigned cs_sel_mask;
unsigned cs_num;
+ /* Quirks */
+ unsigned cs_clk_stays_gated : 1;
};
/* Keep these sorted with enum pxa_ssp_type */
@@ -156,6 +162,7 @@ static const struct lpss_config lpss_platforms[] = {
.tx_threshold_hi = 56,
.cs_sel_shift = 8,
.cs_sel_mask = 3 << 8,
+ .cs_clk_stays_gated = true,
},
};
@@ -383,6 +390,22 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable)
else
value |= LPSS_CS_CONTROL_CS_HIGH;
__lpss_ssp_write_priv(drv_data, config->reg_cs_ctrl, value);
+ if (config->cs_clk_stays_gated) {
+ u32 clkgate;
+
+ /*
+ * Changing CS alone when dynamic clock gating is on won't
+ * actually flip CS at that time. This ruins SPI transfers
+ * that specify delays, or have no data. Toggle the clock mode
+ * to force on briefly to poke the CS pin to move.
+ */
+ clkgate = __lpss_ssp_read_priv(drv_data, LPSS_PRIV_CLOCK_GATE);
+ value = (clkgate & ~LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK) |
+ LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON;
+
+ __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, value);
+ __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, clkgate);
+ }
}
static void cs_assert(struct spi_device *spi)
--
2.25.0.225.g125e21ebc7-goog
^ permalink raw reply related [flat|nested] 36+ messages in thread
end of thread, other threads:[~2020-02-12 10:24 UTC | newest]
Thread overview: 36+ 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
2015-09-01 12:01 Zariya
2015-09-01 16:06 Re: Zariya
2017-02-23 15:09 Qin's Yanjun
2017-11-13 14:55 Amos Kalonzo
2020-02-06 6:36 Re: Viviane Jose Pereira
2020-02-11 22:34 (unknown) Rajat Jain
[not found] ` <20200211223400.107604-1-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-02-12 9:30 ` Jarkko Nikula
[not found] ` <b3397374-0cb8-cf6c-0555-34541a1c108c-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2020-02-12 10:24 ` Re: Andy Shevchenko
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).