linux-kernel - Re: pinctrl discussions @ Linaro Connect, and also requesting GPIOs

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: <CAJuYYwS465WW-Xp6gk5hzKArTZGzmc6nh+-XR=BPusGfTU=DXw@mail.gmail.com>
Date:	Sat, 12 Nov 2011 16:52:19 +0530
From:	Thomas Abraham <thomas.abraham@...aro.org>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Stephen Warren <swarren@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>
Subject: Re: pinctrl discussions @ Linaro Connect, and also requesting GPIOs

On 11 November 2011 19:39, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Thu, Nov 10, 2011 at 5:33 PM, Stephen Warren <swarren@...dia.com> wrote:
>> Linus Walleij wrote at Thursday, November 10, 2011 1:40 AM:
>>> Stephen Warren <swarren@...dia.com> wrote:
>>> > Many drivers currently call gpio_request(). This is defined /not/ to
>>> > perform any pinmux manipulation.
>>>
>>> Is it?
>>>
>>> I always though that the GPIO driver could call out to the pinctrl
>>> counterpart.
>>
>> I'd originally thought that too, but when I tried to "fix" gpio_request()
>> on Tegra to perform any necessary pinmux actions, it was pointed out that
>> Documentation/gpio.txt says:
>>
>> " Note that requesting a GPIO does NOT cause it to be configured in any
>> " way; it just marks that GPIO as in use.  Separate code must handle any
>> " pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
>>                              ^^^^^^^^^^^^^^^^^^^^^^^
>
> Hm, yeah I see. :-/ You're right of course.
>
> And it is perfectly possible to say, drive a GPIO pin even though it is
> not connected anywhere at all, even though it seem strange,
> there may be cases where a GPIO is used internally on a chip OR
> routed to an external pin, and then this is fully logic.
>
> And it makes the two subsystems mostly orthogonal.
>
>> Given that, it appears that the pinctrl/pinmux API is the way to perform
>> that setup, including muxing the GPIO controller onto the pin if required.
>> Given the similarity of that mux setup with more general non-GPIO mux
>> setup is why I suggested including GPIO muxing in the regular mapping
>> table.
>>
>> (as I think I mentioned) and alternative to a custom GPIO mapping table
>> entry would be to remove the GPIO-specific APIs from pinctrl, and have
>> all pinctrl drivers only expose GPIO as an additional function available
>> on a pin (group). Systems that support N different GPIOs on a pin would
>> need to expose GPIO this way anyway.
>
> Yes. It is already possible to use the mapping table like that if
> all GPIOs are represented as indvidual functions from the
> *driver* (i.e. not using the pinmux_request_gpio() function)
> so currently it's a matter of choice.
>
> We already have a goal to do as much as possible of set-up from
> platform code, including mapping table, or, even better, by direct
> bindings from the device tree (whenever we get that).
>
> The idea with the single GPIO request functions was to make
> things simpler and quicker but maybe it's just cluttering the view :-/
>
> What do others think? Shall we just kill
> pinmux_[request|free]_gpio() and its driver hooks?


Samsung SoC's use two pin functions out of 4/8/16 pin functions to
represent that a pin is used as a gpio. For instance, function 0 means
pin is used as a gpio input, and function 1 means pin is used as gpio
output. A pin cannot support both input and output mode at the same
time.

The existing pinmux_[request|free]_gpio() functions can specify that a
pin has to be set in gpio function mode, but lack the provision to
select input or output mode for the gpio. The alternative approach of
using pin functions to select gpio-input or gpio-output will be used
for samsung pinmux drivers.

This means the gpio_direction_[input|output] api's would remain unused
on samsung platforms. And existing platforms already using this api
will have to be modified to use the pinmux api to select the direction
of the gpio pin. And the role of gpio_request will seem redundant when
used along with pinmux_get().

Another question, not related to the above. The gpio and pinctrl
drivers would operate on the same physical memory space (pinmux and
gpio is just a single controller). Both gpio and pinctrl driver would
do a ioremap of this physical address space. I remember reading that
ioremap of the same physical memory area twice is not correct. So any
suggestions on how to handle this.

Thanks,
Thomas.

>
> I guess I have to convert a driver with mixed GPIO myself
> before I fully understand how to do this the right way...
>
> 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/
>
--
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/