How to define an I2C-to-SPI bridge device ?

[André Schwarz]

Grant,

[snip]
> > 
> > 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 ?
> 
> Does the device actually generate edge interrupts?  Or is it a level
> irq device?  If it is a level irq device, then the correct way to
> handle this is to disable the irq line so that the event can be
> handled at non-irq context, and then reenable it when finished.

The irq is level-low active.
Will do it via disable/re-enable then.

> 
> > 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.
> 
> I'm really not sure what is tricky about this.  The spi layer handles
> multiple CS lines on a single bus just fine.

huh - ok ... didn't know that, sorry.

> 
> To start, how the CS lines are manipulated is only a hardware
> implementation detail.  The driver can and should do the work of
> translate Linux CS line numbers into the format/bitfield expected by
> the hardware.  Other drivers do the same thing.

ok - will do it.

> 
> > 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.
> 
> The SPI subsystem doesn't directly support this use-case.  If you want
> to do this, then assign another chip select number for the purpose of
> enabling multiple CS lines at once... and be careful which drivers you
> allow to be bound to the oddball CS number.  The in-kernel drivers
> certainly don't support this use-case, and care must be taken to
> ensure only one device is writing to the input line at a time.
> 
> What specific hardware do you need this feature for?

We have a board with multiple parallel video transmitters connected to
an FPGA. Video timing and general parameters are always the same and
there are quite a lot of settings to write during init/mode change.

Doing this in parallel will speed things up significantly.

Of course this is a write-only scenario, i.e. no combined reads.

> 
> > 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.
> 
> Exposing via sysfs or discrete GPIO manipulations is completely the
> wrong thing to do.

Thanks for pointing this out.


BTW: would "drivers/misc" be a proper location ?
Who's supposed to pick that driver up and on what list shall I post it
for review ?


Will try to get more spi knowledge before moving on and asking stupid
questions. Thanks for your help so far.


Regards,
André



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner