From: "André Schwarz" <andre.schwarz@matrix-vision.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: LinuxPPC List <linuxppc-dev@ozlabs.org>,
DevTreeDiscuss <devicetree-discuss@lists.ozlabs.org>
Subject: Re: How to define an I2C-to-SPI bridge device ?
Date: Fri, 10 Sep 2010 10:11:33 +0200 [thread overview]
Message-ID: <1284106293.2267.42.camel@swa-m460> (raw)
In-Reply-To: <c843f864-2a5a-4146-bd95-13c2fb91f430@email.android.com>
Grant, Anton,
>
> There is no longer any need for separate of and non-of drivers for the same hardware. Any device may have the of_node pointer in struct device set, and drivers can use the pointer as an alternative to platform_data to get information about the hardware configuration.
> Just read the data out of the node in the driver's probe hook.
ok - will do it that way.
>
> For i2c and (soon) spi, the core code will even register child devices for you.
excellent.
Thinking about this device raises even more questions. Since there are
several possible solutions I'd like to hear your opinions :
1.
The SC18IS602 is capable of generating interrupts which is *extremely*
useful triggering on the end of the actual SPI transaction and not the
end of I2C chip access. Since we need an IRQ_ACK over I2C (which takes
loooong with IRQ being still asserted) I'm thinking about using an edge
triggered interrupt.
Since all transactions are in-order there's no risk of missing multiple
edges ... what do you think about this ? Any known issues with edge
triggered IRQs ?
2.
chips select generations is a little tricky.
The device has up to four cs# lines with their assertion being encoded
as subaddr representing a bitfield, i.e. Subaddr 0x01 generates cs0,
0x04 asserts cs3 and 0x07 asserts cs0-2.
At first I thought about registering 4 SPI busses representing the 4 cs#
lines and hide the cs# generation from the user. This would make
multiple cs# assertions for a single write impossible which is a very
useful feature.
Exposing the desired cs# setting for the next transaction via sysfs or
libGPIO requires the user to serialize cs# config and actual SPI
read/write. I also wouldn't know how to properly present the cs# lines
from multiple chips to the user in a clear and unambiguous way.
Any suggestions ?
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
next prev parent reply other threads:[~2010-09-10 8:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-03 8:36 How to define an I2C-to-SPI bridge device ? André Schwarz
2010-09-03 12:08 ` Anton Vorontsov
2010-09-06 11:40 ` Andre Schwarz
2010-09-06 14:37 ` André Schwarz
2010-09-09 18:23 ` Grant Likely
2010-09-10 8:11 ` André Schwarz [this message]
2010-09-10 17:37 ` Grant Likely
2010-09-10 18:14 ` André Schwarz
2010-09-10 18:27 ` Anton Vorontsov
2010-09-10 18:28 ` Grant Likely
2010-09-12 15:10 ` André Schwarz
2010-09-13 4:39 ` Grant Likely
2011-03-25 9:28 ` Andre Schwarz
2011-03-29 16:21 ` Andre Schwarz
2011-03-31 3:43 ` Grant Likely
2010-09-09 17:06 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1284106293.2267.42.camel@swa-m460 \
--to=andre.schwarz@matrix-vision.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).