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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 29 Nov 2008 14:54:15 -0800
From:	David Brownell <david-b@...bell.net>
To:	"Jaya Kumar" <jayakumar.lkml@...il.com>
Cc:	"Eric Miao" <eric.y.miao@...il.com>,
	"Sam Ravnborg" <sam@...nborg.org>,
	"Jean Delvare" <khali@...ux-fr.org>,
	"Eric Miao" <eric.miao@...vell.com>,
	"Haavard Skinnemoen" <hskinnemoen@...el.com>,
	"Philipp Zabel" <philipp.zabel@...il.com>,
	"Russell King" <rmk@....linux.org.uk>,
	"Ben Gardner" <bgardner@...tec.com>, "Greg KH" <greg@...ah.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org
Subject: Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/