From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl-sunxi: fix pin attribute handling.
Date: Sun, 23 Jun 2013 12:20:57 +0200 [thread overview]
Message-ID: <20130623102057.GD26008@lukather> (raw)
In-Reply-To: <A06309D9-3340-4F5B-AFB5-4B3DC3997411@upgrade-android.com>
Hi Ithamar,
On Fri, Jun 21, 2013 at 09:41:13AM +0200, Ithamar R. Adema wrote:
> Dear Maxime,
>
> On Jun 20, 2013, at 10:49 , Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi Ithamar,
> >
> > You should probably put in the recipients Linus Walleij that will
> > probably be the one that will merge this patch anyway.
>
> Ah okay, thanks for the heads-up.
> >> + strength = 0;
> >> if (!of_property_read_u32(node, "allwinner,drive", &val)) {
> >> - u16 strength = (val + 1) * 10;
> >> - pinconfig[j++] =
> >> - pinconf_to_config_packed(PIN_CONFIG_DRIVE_STRENGTH,
> >> - strength);
> >> + strength = (val + 1) * 10;
> >> }
> >> + pinconfig[0] =
> >> + pinconf_to_config_packed(PIN_CONFIG_DRIVE_STRENGTH,
> >> + strength);
> >
> > Why are you making the configuration of the strength in any cases? It's
> > an optional property, it should be treated as such.
>
> My reasoning, which I can see is very subjective, is that if those
> properties (same for pull up/down) are not specified, you still want
> them to be in a defined state. Setting the drive strength (and pull
> up/down) to the default 0 value is just so that any configuration that
> might have been done the kernel started is undone.
>
> I can understand your reasoning here, but are you sure you would want
> them left in undefined state?
While your reasoning is correct here, the point is that the platform is
still a little obscure, with not a lot of documentation and so on. So
relying on the bootloader to do some muxing could still prove useful.
> >
> >> val = readl(pctl->membase + sunxi_pull_reg(g->pin));
> >> mask = PULL_PINS_MASK << sunxi_pull_offset(g->pin);
> >> - writel((val & ~mask) | 1 << sunxi_pull_offset(g->pin),
> >> + writel((val & ~mask) | arg << sunxi_pull_offset(g->pin),
> >
> > I'd rather see an obvious assignment of 1 here. It's the value that is
> > documented in the datasheet, it pops to the mind. You can always put
> > this inside an if(arg) statement if you want to.
>
> Just to make sure I understand, are you suggesting to stretch that
> writel() onliner into an if (arg) writel() else writel() ?
Yes, something like
case PULL_UP:
val = readl(pctl->membase + sunxi_pull_reg(g->pin));
mask = PULL_PINS_MASK << sunxi_pull_offset(g->pin);
if (arg)
writel((val & ~mask) | 1 << sunxi_pull_offset(g->pin), reg);
else
writel(val & ~mask, reg);
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130623/02b42f03/attachment.sig>
next prev parent reply other threads:[~2013-06-23 10:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-20 17:12 [PATCH] pinctrl-sunxi: fix pin attribute handling Ithamar R. Adema
2013-06-20 20:49 ` Maxime Ripard
2013-06-21 7:41 ` Ithamar R. Adema
2013-06-23 10:20 ` Maxime Ripard [this message]
2013-06-23 10:24 ` Ithamar R. Adema
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=20130623102057.GD26008@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox