All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Larsson <andreas@gaisler.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Rob Herring <rob.herring@calxeda.com>,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org, software@gaisler.com
Subject: Re: [PATCH 1/2] gpio: gpio-generic: Fix bug in big endian bit conversion
Date: Tue, 26 Feb 2013 13:17:29 +0100	[thread overview]
Message-ID: <512CA7D9.3040004@gaisler.com> (raw)
In-Reply-To: <512C9287.6000100@gaisler.com>

On 2013-02-26 11:46, Andreas Larsson wrote:
> On 2013-02-26 08:52, Grant Likely wrote:
>> On Sat, 09 Feb 2013 14:58:55 +0000, Grant Likely
>> <grant.likely@secretlab.ca> 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

  reply	other threads:[~2013-02-26 12:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-05 10:33 [PATCH 0/2] gpio: Fix gpio-generic bug and add driver for GRGPIO cores Andreas Larsson
2013-02-05 10:33 ` [PATCH 1/2] gpio: gpio-generic: Fix bug in big endian bit conversion Andreas Larsson
2013-02-09 14:58   ` Grant Likely
2013-02-26  7:52     ` Grant Likely
2013-02-26  7:52       ` Grant Likely
2013-02-26 10:46       ` Andreas Larsson
2013-02-26 12:17         ` Andreas Larsson [this message]
2013-03-02  9:16         ` Grant Likely
2013-02-05 10:33 ` [PATCH 2/2] gpio: Add device driver for GRGPIO cores Andreas Larsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=512CA7D9.3040004@gaisler.com \
    --to=andreas@gaisler.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    --cc=software@gaisler.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.