linux-kernel - Re: [PATCH] pinctrl: elaborate a bit on arrangements in doc

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]

Message-ID: <CACRpkdZJ3oP9ARDhwZ1h8CkFXpDTznPChLiSgivTYKGDkWbOZA@mail.gmail.com>
Date:	Thu, 27 Jun 2013 12:08:40 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stephen Warren <swarren@...dia.com>,
	Tony Lindgren <tony@...mide.com>,
	Rob Landley <rob@...dley.net>,
	Christian Ruppert <christian.ruppert@...lis.com>
Subject: Re: [PATCH] pinctrl: elaborate a bit on arrangements in doc

On Tue, Jun 25, 2013 at 11:16 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 06/25/2013 08:19 AM, Linus Walleij wrote:
>> From: Linus Walleij <linus.walleij@...aro.org>
>>
>> This elaborates a bit on the pinctrl vs GPIO arangements
>> in the hardware.
>>
>> Inspired by some drawings in a mail from Christian
>> Ruppert.
(...)
> I'm not really sure quite what these diagrams are attempting to convey
> within the context of this document.

I am trying to help pinctrl kernel developers understand hardware
terminology.

>> +In (A) the GPIO-like functionality of the pin is *always* available.
>
> Well, that can't really be true.
>
> It may be possible that you can always read the physical pin's value via
> a GPIO input register.
>
> However, you obviously can't always write to a GPIO output register to
> set the pin's value. If you could, the pin would simply be a GPIO, and
> never serve any other function.

This is possible on the U300. What happens in practice is
that what you send out on the output from e.g. the I2C block is
OR:ed with the GPIO output, so if that is not zero, you jam it to 1.

> If you're saying that it's always possible to put the pin into a mode
> where you can use the GPIO output register to driver the pin value, well
> then that's just regular pin-muxing, so I'm not sure why it's worth
> mentioning.

That's not really the case. It can drive the pin at the same time.

> In (a) there are really two levels of pinmux configuration, one in the
> GPIO HW block (GPIO-vs-whatever-pinctrl-selects).
>
> In (b) there is another level of pinmux configuration; some block has to
> exist between the physical pins and both GPIO/pinctrl HW modules; it
> simply isn't drawn in the diagram

I've redrawn these a bit to reflect the cases I know exist.
Check the v2 patch.

> In all cases though, this is just attempting to enumerate different HW
> designs for pin-muxing I think. Isn't it better to just let each SoC's
> datasheet specify exactly how things are hooked up?

The intention of this is to understand the datasheet from a kernel
point of view.

Yours,
Linus Walleij
--
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/