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 _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss