On Tuesday 25 November 2008, Jaya Kumar wrote: > In the area of framebuffers for lower end display devices, I find this > to be quite common. I'd have said "display modules" myself, although I don't currently have any Linux systems using them. Some of those modules use SPI, since it tends support DMA for downloading the image data ... although admittedly those are not the very lowest end devices. > I have also seen this in systems such as 8-bit A2D devices, also with > various coprocessor solutions where a smaller CPU like a msp430 or > HC05 would clock data to the host using 8-bit gpio data. When I hear "coprocessor" I think more like Video DSPs. ;) And for microcontrollers (msp430, avr8, etc) hooking up, I've usually seen them use a serial bus (I2C, SPI, etc). But it's also true that when data transfer rates matter, it's faster to talk to microcontrollers using a parallel bus than such a serial bus. The Linux SOC it's talking to can probably clock SPI an order of magnitude faster than the microcontroller tolerates. And the reason you want a dedicated microcontroller is for predictable (a.k.a. "realtime") monitoring tasks, which they can't do if they're spending all their time talking to Linux. Sounds like you're working with a bunch of semicustom monitoring/control designs? If you want to pursue this, I'd like to get the gpio_chip proposal in place first: bitmask read and write, without forcing an "all bits are contiguous" policy. Lightweight. Maybe it should suffice to have a gpio_chip support the bitmask ops, instead of just bit-at-a-time ones... so it'd be practical to incorporate this by itself, given patches to convert a couple gpio_chip implementations. Then separately two more things: - A gpio_* interface proposal for higher-level bitmask calls. This is worth some discussion; the calls should clearly be optional (not everything will implement them), and I can't help but suspect <linux/bitmap.h> interfaces should interoperate smoothly. - A gpiolib based implementation, using those new gpio_chip methods as accelerators if they're present. This should probably also be optional, even at the Kconfig level; many systems won't need to spend memory on these calls. Right now you seem to have smooshed together those three things, which probably helped get your sample driver going faster but isn't a very good way to move forward. Don't assume gpiolib when defining the interface. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
