preferable method for pinctrl driver

preferable method for pinctrl driver

[Oleksij Rempel]

Hello all,

based on previous experience with clk driver, i know that own research
can be not enough. Before starting to writ pinctrl driver, i would like
to ask your suggestions.

Looks like there is at least two pinctrl driver types:
- imx23 which makes function description insight of DT;
- tegra with function descrption in the source code.
which way is preferable?

Other question, i didn't found exact same HW, do it make sense to merge
this driver with existing one? Are there some similarities with this one?:
http://pastebin.com/hW82Xupq
-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141010/686d4c1a/attachment.sig>

preferable method for pinctrl driver

[Linus Walleij]

On Fri, Oct 10, 2014 at 10:42 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:

> Looks like there is at least two pinctrl driver types:
> - imx23 which makes function description insight of DT;
> - tegra with function descrption in the source code.
> which way is preferable?

The Tegra way. The driver should know about all groups
and functions, the DT should just configure the functions to
groups relation.

The i.MX driver happened before the DT use for pin controllers
was thought through.

> Other question, i didn't found exact same HW, do it make sense to merge
> this driver with existing one? Are there some similarities with this one?:
> http://pastebin.com/hW82Xupq

No idea, that's very little HW information. However
silicon vendors often du their I/O cell layout themselves
so many pin controllers are very unique.

Yours,
Linus Walleij

preferable method for pinctrl driver

[Oleksij Rempel]

Am 13.10.2014 um 11:05 schrieb Linus Walleij:
> On Fri, Oct 10, 2014 at 10:42 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> 
>> Looks like there is at least two pinctrl driver types:
>> - imx23 which makes function description insight of DT;
>> - tegra with function descrption in the source code.
>> which way is preferable?
> 
> The Tegra way. The driver should know about all groups
> and functions, the DT should just configure the functions to
> groups relation.
> 
> The i.MX driver happened before the DT use for pin controllers
> was thought through.
> 
>> Other question, i didn't found exact same HW, do it make sense to merge
>> this driver with existing one? Are there some similarities with this one?:
>> http://pastebin.com/hW82Xupq
> 
> No idea, that's very little HW information. However
> silicon vendors often du their I/O cell layout themselves
> so many pin controllers are very unique.
> 
> Yours,
> Linus Walleij

Hi,
thank you for your previous response. One more question: how pins should
be numbered? Continuous or register offsets can be used?
Documentations for this soc use pin names encoded like this
#NAME_#BANK_#PIN. Register offset can be calculated by ((bank) * 32 +
(pin) * 4)
In this case i need to have extra array to convert pin number to offset,
or use offset as pin number.
-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141107/30aa5c73/attachment.sig>

preferable method for pinctrl driver

[Oleksij Rempel]

Am 07.11.2014 um 09:35 schrieb Oleksij Rempel:
> Am 13.10.2014 um 11:05 schrieb Linus Walleij:
>> On Fri, Oct 10, 2014 at 10:42 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>>> Looks like there is at least two pinctrl driver types:
>>> - imx23 which makes function description insight of DT;
>>> - tegra with function descrption in the source code.
>>> which way is preferable?
>>
>> The Tegra way. The driver should know about all groups
>> and functions, the DT should just configure the functions to
>> groups relation.
>>
>> The i.MX driver happened before the DT use for pin controllers
>> was thought through.
>>
>>> Other question, i didn't found exact same HW, do it make sense to merge
>>> this driver with existing one? Are there some similarities with this one?:
>>> http://pastebin.com/hW82Xupq
>>
>> No idea, that's very little HW information. However
>> silicon vendors often du their I/O cell layout themselves
>> so many pin controllers are very unique.
>>
>> Yours,
>> Linus Walleij
> 
> Hi,
> thank you for your previous response. One more question: how pins should
> be numbered? Continuous or register offsets can be used?
> Documentations for this soc use pin names encoded like this
> #NAME_#BANK_#PIN. Register offset can be calculated by ((bank) * 32 +
> (pin) * 4)
> In this case i need to have extra array to convert pin number to offset,
> or use offset as pin number.

Never mind, i think i found the answer:
This enumeration was arbitrarily chosen, in practice you need to think
through your numbering system so that it matches the layout of registers
and such things in your driver, or the code may become complicated. You
must also consider matching of offsets to the GPIO ranges that may be
handled by the pin controller.

-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141107/9b3e5c31/attachment.sig>

preferable method for pinctrl driver

[Linus Walleij]

On Fri, Nov 7, 2014 at 11:17 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:

>> thank you for your previous response. One more question: how pins should
>> be numbered? Continuous or register offsets can be used?
>> Documentations for this soc use pin names encoded like this
>> #NAME_#BANK_#PIN. Register offset can be calculated by ((bank) * 32 +
>> (pin) * 4)
>> In this case i need to have extra array to convert pin number to offset,
>> or use offset as pin number.
>
> Never mind, i think i found the answer:
> This enumeration was arbitrarily chosen, in practice you need to think
> through your numbering system so that it matches the layout of registers
> and such things in your driver, or the code may become complicated. You
> must also consider matching of offsets to the GPIO ranges that may be
> handled by the pin controller.

Yeah you're right :)

There is some resoning in Documentation/pinctrl.txt but it needs some
intuition etc.

Yours,
Linus Walleij

preferable method for pinctrl driver

[Oleksij Rempel]

Am 14.11.2014 um 11:01 schrieb Linus Walleij:
> On Fri, Nov 7, 2014 at 11:17 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> 
>>> thank you for your previous response. One more question: how pins should
>>> be numbered? Continuous or register offsets can be used?
>>> Documentations for this soc use pin names encoded like this
>>> #NAME_#BANK_#PIN. Register offset can be calculated by ((bank) * 32 +
>>> (pin) * 4)
>>> In this case i need to have extra array to convert pin number to offset,
>>> or use offset as pin number.
>>
>> Never mind, i think i found the answer:
>> This enumeration was arbitrarily chosen, in practice you need to think
>> through your numbering system so that it matches the layout of registers
>> and such things in your driver, or the code may become complicated. You
>> must also consider matching of offsets to the GPIO ranges that may be
>> handled by the pin controller.
> 
> Yeah you're right :)
> 
> There is some resoning in Documentation/pinctrl.txt but it needs some
> intuition etc.
> 
> Yours,
> Linus Walleij
> 

What is preferred method of handling gpio_request_enable in pinctrl
driver? My hw provide GPIO as one of mux variants for each controlled
pin.  if i see it correctly, pin subsystem will not prevent using one
pin as gpio and request for some other functionality? Should it be
prevented by driver?

Here is my current pinctrl driver, in case it help understand my point:
https://github.com/olerem/linux-2.6/commit/5d8963e24493db445207c29dec00a6a848d8e781

-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150209/d679592d/attachment.sig>

preferable method for pinctrl driver

[Linus Walleij]

On Mon, Feb 9, 2015 at 11:41 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:

> What is preferred method of handling gpio_request_enable in pinctrl
> driver? My hw provide GPIO as one of mux variants for each controlled
> pin.  if i see it correctly, pin subsystem will not prevent using one
> pin as gpio and request for some other functionality? Should it be
> prevented by driver?

That is up to the driver writer. We have contemplated adding an
option to pinctrl_desc enforcing "exclusive GPIO" meaning that
GPIO and another mux setting cannot be used at the same time,
but noone got around to implementing that.

Some pin controllers can do GPIO and another function at the
same time, see illustrations and text in
Documentation/pinctrl.txt

Yours,
Linus Walleij