On Fri, Jun 19, 2009 at 7:25 AM, Anton Vorontsov<[email protected]> wrote: > Surely we can hide the bridge into the SPI controller driver, > but I think it would be beneficial to "factor-out" it to a > stand-alone entity, so that other SPI controllers could work > with this setup without any modifications (oh and btw, we could > also create a bridge called "gpio-chipselects-bridge", and > factor out all GPIO stuff from the drivers). > > There are two options of how we can factor out chip-select > machines... the bad and the ugly. :-) No, the first one is bad, > but the second should be OK. [...] > 2. Another option (which I like more), is to create "SPI chip- > select machine driver framework", so we could (finally) > separate two SPI entities: SPI IO and SPI chip-select machine. > CS machines of different flavours: GPIO, built-in, and > board-specific (!) with a lot of demuxing magic.
I agree, I think your option 2 is the way to go. It would probably need to be implemented as some form of logical bridge so that SPI requests don't go straight to the IO driver, but first go through the CS machine so that the CS driver can do funky stuff like inserting or modifying SPI requests before they go to the hardware. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
