Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

[David Brownell]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/