All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Poeschel <poeschel@lemonage.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Lars Poeschel <larsi@wh2.tu-dresden.de>,
	sameo@linux.intel.com, linux-kernel@vger.kernel.org,
	jic23@cam.ac.uk, khali@linux-fr.org, ben-linux@fluff.org,
	w.sang@pengutronix.de, grant.likely@secretlab.ca
Subject: Re: [PATCH v2 2/4] gpio: add viperboard gpio driver
Date: Tue, 16 Oct 2012 15:38:29 +0200	[thread overview]
Message-ID: <201210161538.29571.poeschel@lemonage.de> (raw)
In-Reply-To: <CACRpkda+UufHGEekzRxG7U3CG-_nvx1d0ophqwUUWmjkvaBTmg@mail.gmail.com>

On Tuesday 16 October 2012 at 12:00:13, Linus Walleij wrote:
> On Tue, Oct 16, 2012 at 8:51 AM, Lars Poeschel <poeschel@lemonage.de> wrote:
> > On Monday 15 October 2012 at 15:00:12, Linus Walleij wrote:
> >> > +       /* if io is set to output, just return the saved value */
> >> > +       if (gpio->gpioa_out & (1 << offset))
> >> > +               return gpio->gpioa_val & (1 << offset);
> >> 
> >> That's not going to work if the hardware changes state
> >> behind the back of the driver right? Oh well, maybe
> >> it doesn't matter.
> > 
> > I thought about that and then did this "cache" only in case the gpio is a
> > output to save to usb ping-pong that is needed otherwise. I thought that
> > nothing can change to state of the output but the driver itself.
> 
> On a second note there is already a standard mechanism for caching
> registers in the kernel, and that is regmap. Sadly it's a bit
> undocumented but there are several examples and the code
> lives in drivers/base/regmap and include/linux/regmap.h

I had a look at regmap. This is interesting. But there is no regmap_bus 
implementation for usb. Are you pointing me in this direction ? ;-) I don't 
think you want me as a kernel newbie write this code.
And another thing: I don't think this can be implemented in such a general way 
as it is done already for i2c or mmio. As you see in the example of my 
(viperboard-)adapter, there is a bunch bytes sent, just to set the direction 
bit in a register. And it is not guaranteed, that this "address" and "value" 
are at the same position for other usb adapters. And this is getting even 
worse, if I think of reading values out of the viperboard...
I would stay at the "cache" implementation I presented in the patch - this is 
too special.

Lars

  reply	other threads:[~2012-10-16 13:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-27 13:08 [PATCH] mfd: viperboard driver added larsi
2012-09-19 15:29 ` Samuel Ortiz
2012-09-24 16:46   ` Lars Poeschel
2012-09-25  8:55     ` Samuel Ortiz
2012-09-28 13:59       ` Lars Poeschel
2012-10-12 14:34       ` [PATCH v2 1/4] mfd: add viperboard driver Lars Poeschel
2012-10-12 14:34         ` [PATCH v2 2/4] gpio: add viperboard gpio driver Lars Poeschel
2012-10-15 13:00           ` Linus Walleij
2012-10-16  6:51             ` Lars Poeschel
2012-10-16 10:00               ` Linus Walleij
2012-10-16 13:38                 ` Lars Poeschel [this message]
2012-10-16 17:11                   ` Linus Walleij
2012-10-23 15:24                     ` Lars Poeschel
2012-10-24  7:53                       ` Linus Walleij
2012-10-24 16:31                         ` Mark Brown
2012-10-25 10:02                           ` Lars Poeschel
2012-10-25 14:00                             ` Mark Brown
2012-10-25 16:02                               ` Lars Poeschel
2012-10-25 16:06                                 ` Mark Brown
2012-10-26  9:16                                   ` Lars Poeschel
2012-10-27 16:14                                     ` Linus Walleij
2012-10-27 21:35                                       ` Mark Brown
2012-10-12 14:34         ` [PATCH v2 3/4] i2c: add viperboard i2c master driver Lars Poeschel
2012-10-12 14:34         ` [PATCH v2 4/4] iio: adc: add viperboard adc driver Lars Poeschel
2012-10-15 14:26           ` Lars-Peter Clausen
2012-10-16  7:11             ` Lars Poeschel
2012-10-15 17:09         ` [PATCH v2 1/4] mfd: add viperboard driver Peter Meerwald
2012-10-16  7:15           ` Lars Poeschel
2012-10-16  8:40         ` Lars-Peter Clausen
2012-10-16  9:43           ` Lars Poeschel
2012-10-16 10:58             ` Lars-Peter Clausen
2012-10-18  7:29               ` Lars Poeschel
2012-10-18 14:13                 ` Lars-Peter Clausen

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=201210161538.29571.poeschel@lemonage.de \
    --to=poeschel@lemonage.de \
    --cc=ben-linux@fluff.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jic23@cam.ac.uk \
    --cc=khali@linux-fr.org \
    --cc=larsi@wh2.tu-dresden.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=w.sang@pengutronix.de \
    /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.