On 2013-02-26 11:46, Andreas Larsson wrote:

On 2013-02-26 08:52, Grant Likely wrote:

quoted

On Sat, 09 Feb 2013 14:58:55 +0000, Grant Likely
[off-list ref] wrote:
We /could/ have a ioread32be/write32be mode in the driver, but I don't
think that is the right approach. It means we need yet another set of
accessors for register except using the 'be' variants. Blech. What I'd
actually like to do is add a bitmask field to the gpio_desc which can be
calculated ahead of time to whatever madness is required from the way
the device is wired. Then the access routines don't need to even care.
they just apply the bitmask to ioread/iowrite and it doesn't even need
to know what the bit number actually is. The new support for gpio_desc
in the core code makes this feasable.

I am not sure I understand what you mean here or what new support for
gpio_desc you are referring to (looking in gpio/next at
git://git.secretlab.ca/git/linux-2.6).

Do you mean to add something like an 'unsigned long bitmask[64]' bitmap
array with one bitmap for each gpio line to struct gpio_desc and use
this primarily by gpio-generic.c, populated in bgpio_init? Is gpio_desc
now available outside of gpiolib.c in some repository/branch that I
might be unaware of?

Ah, I realize that it is the "gpiolib: remove gpio_desc[] static array" 
patch series you refer to, not yet pushed to gpio/next at 
git://git.secretlab.ca/git/linux-2.6.

The question on how you intend the bitmap field to be 
defined/used/populated remains.

Cheers,
Andreas