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