Spi slave devices with two chip selects, how best to handle?

Spi slave devices with two chip selects, how best to handle?

[J.I. Cameron]

Hi,

I've just been looking through some recent drivers from Analog Devices that 
are in staging-next (and hence linux-next 
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=drivers/staging/iio/gyro/adis16060_core.c;h=fc48aca04bd3420b705b79d3cbb5c0117e187568;hb=HEAD 
) and ran into something I haven't seen before.

The adis16060
http://www.analog.com/static/imported-files/data_sheets/ADIS16060.pdf
uses two chip selects. One is for writing to the device and one
is for reading.

At the moment, the adis16060 driver registers a pair of spi drivers, 
adis16060_r and adis16060_w. The problem comes in how these two get 
information about each other. Currently there is a global pointer in that 
file. Obviously this means that we can only have one of these devices 
running at a time and should be removed. So what I'm basically asking is if 
anyone else has run into a similar situation and what their solution was. 
We could put a magic code in the platform data for the two devices and use 
that to link them together but that's ugly and would mean having the driver 
handle lists of the drivers that are currently registered but not paired so 
as to be able to pair them up. Anyone have a better idea or an example of 
what someone else has done in similar circumstances?

Thanks,

Jonathan 

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

Re: Spi slave devices with two chip selects, how best to handle?

[Grant Likely]

On Thu, Nov 25, 2010 at 3:08 PM, J.I. Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org> wrote:
> Hi,
>
> I've just been looking through some recent drivers from Analog Devices that
> are in staging-next (and hence linux-next
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=drivers/staging/iio/gyro/adis16060_core.c;h=fc48aca04bd3420b705b79d3cbb5c0117e187568;hb=HEAD
> ) and ran into something I haven't seen before.
>
> The adis16060
> http://www.analog.com/static/imported-files/data_sheets/ADIS16060.pdf
> uses two chip selects. One is for writing to the device and one
> is for reading.
>
> At the moment, the adis16060 driver registers a pair of spi drivers,
> adis16060_r and adis16060_w. The problem comes in how these two get
> information about each other. Currently there is a global pointer in that
> file. Obviously this means that we can only have one of these devices
> running at a time and should be removed. So what I'm basically asking is if
> anyone else has run into a similar situation and what their solution was. We
> could put a magic code in the platform data for the two devices and use that
> to link them together but that's ugly and would mean having the driver
> handle lists of the drivers that are currently registered but not paired so
> as to be able to pair them up. Anyone have a better idea or an example of
> what someone else has done in similar circumstances?

Have a single driver private data structure that contains and
registers 2 spi_device instances.  Have both spi_device instances
point back at the same driver private data structure.

g.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

Re: Spi slave devices with two chip selects, how best to handle?

[David Brownell]

--- On Thu, 11/25/10, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:

> > as to be able to pair them up. Anyone have a better
> idea or an example of
> > what someone else has done in similar circumstances?
> 
> Have a single driver private data structure that contains
> and
> registers 2 spi_device instances.  Have both
> spi_device instances
> point back at the same driver private data structure.

And consider having a chardev or blockdev to
access (indirectly) both the read and write
sides of the chip. using that driver-private
structure.  ((and, tricky, making the linkage
between the three devices visible through the
driver model, if you can).

- Dave

> 
> g.
> 

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

Re: Spi slave devices with two chip selects, how best to handle?

[Jonathan Cameron]

On 11/26/10 04:19, David Brownell wrote:
> 
> 
> --- On Thu, 11/25/10, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> 
>>> as to be able to pair them up. Anyone have a better
>> idea or an example of
>>> what someone else has done in similar circumstances?
>>
>> Have a single driver private data structure that contains
>> and
>> registers 2 spi_device instances.  Have both
>> spi_device instances
>> point back at the same driver private data structure.
> 
> And consider having a chardev or blockdev to
> access (indirectly) both the read and write
> sides of the chip. using that driver-private
> structure.  ((and, tricky, making the linkage
> between the three devices visible through the
> driver model, if you can).
Thanks all.  This is looking complex enough that I'll probably
want to actually have the part or leave it to someone who does...

One for your list Michael (I can put suitable element in your
tracker if that is helpful?)

Jonathan

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

RE: Spi slave devices with two chip selects, how best to handle?

[Hennerich, Michael]

Jonathan Cameron wrote on 2010-11-26:
> On 11/26/10 04:19, David Brownell wrote:
>>
>>
>> --- On Thu, 11/25/10, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>>
>>>> as to be able to pair them up. Anyone have a better idea or an
>>>> example of what someone else has done in similar circumstances?
>>>
>>> Have a single driver private data structure that contains and
>>> registers 2 spi_device instances.  Have both spi_device instances
>>> point back at the same driver private data structure.

Sorry - I'm not quite sure how this should work, without using a global.
Having a single private data structure is obvious, however spi drivers are
registered and not spi devices. container_of() is not going to help here either.

Can you explain how you would pass the pointer?

>> And consider having a chardev or blockdev to access (indirectly)
>> both the read and write sides of the chip. using that driver-private
>> structure.  ((and, tricky, making the linkage between the three
>> devices visible through the driver model, if you can).
> Thanks all.  This is looking complex enough that I'll probably want to
> actually have the part or leave it to someone who does...
>
> One for your list Michael (I can put suitable element in your tracker
> if that is helpful?)
>
> Jonathan

I'll add a tracker item.
Thanks.

Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev