Re: pinctrl and device-tree support in qcom drivers

Re: pinctrl and device-tree support in qcom drivers

[Linus Walleij]

On Thu, Jul 25, 2013 at 11:30 PM, Bird, Tim <Tim.Bird@sonymobile.com> wrote:

>  Qualcomm is just beginning to push
> some pinctrl support based on device tree, for their later SOCs,
> to mainline.

I guess you're referring to this:
http://marc.info/?l=linux-kernel&m=137470211220414&w=2
(Hanumant please include Tim & Bjorn on future postings.)

> My question is this - are all new drivers in mainline expected
> to be based on pinctrl?

Depends on what you mean by that, we certainly do not
allow any more nasty hacks under arch/arm/* or any
custom extenstions to GPIO drivers or such.

> The qcom support looks like its in its
> early stages, and I'm not sure I have the bandwidth to work on
> it, as a precursor to working on the Sony drivers.

Hanumant is working on it I believe, I haven't had time
to review the latest iterations so I don't have a TPS
report on the state and progress as of now ...

> It appears that I could submit a device-tree based driver
> for the Sony hardware, by adding some support for
> device tree to the qcom i2c driver, and then adding the device
> tree support for the sony driver.  But does this lead me into
> a dead end in mainline?  Will I just have to re-write it later
> to base it on pinctrl?

I don't know which driver you are talking about here...
it seems you are referring to drivers which are dependent
on some kind of pin control handle?

Surely, if the I2C driver or so has its pins set up correctly
already at boot or some legacy code that is already
upstream, fine. But expanding and using the legacy
pin control solutions is not encouraged (by me).

The proper pin control framework will grab a "default"
state for the pins when the device (such as I2C) is
probed, making it usable. It's mainly a problem with
dynamic states later on.

> Or am I missing something?  Maybe the migration to the
> pinctrl-based stuff will be trivial once qcom re-implements
> their i2c dirver based on pinctrl - but I've currently got no timeline
> for when that might occur.

Are they calling a lot of custom APIs for this? The device
core will take care of making it usable, it's mainly the
runtime PM aspects that will require drivers to be
pinctrl aware at all. Or some esoteric stuff like
muxing the I2C block across two sets of pins.

Yours,
Linus Walleij

RE: pinctrl and device-tree support in qcom drivers

[Bird, Tim]

On Thursday, July 25, 2013 3:00 PM, Linus Walleij [linus.walleij@linaro.org] wrote:
>
>On Thu, Jul 25, 2013 at 11:30 PM, Bird, Tim <Tim.Bird@sonymobile.com> wrote:
>
>>  Qualcomm is just beginning to push
>> some pinctrl support based on device tree, for their later SOCs,
>> to mainline.
>
>I guess you're referring to this:
>http://marc.info/?l=linux-kernel&m=137470211220414&w=2
>(Hanumant please include Tim & Bjorn on future postings.)

That's exactly right.

>> My question is this - are all new drivers in mainline expected
>> to be based on pinctrl?
>
>Depends on what you mean by that, we certainly do not
>allow any more nasty hacks under arch/arm/* or any
>custom extenstions to GPIO drivers or such.

What if the driver handles the pins directly itself?  That
makes the driver platform-specific.  Is this disallowed now,
or are platform-specific drivers OK?

>> The qcom support looks like its in its
>> early stages, and I'm not sure I have the bandwidth to work on
>> it, as a precursor to working on the Sony drivers.
>
>Hanumant is working on it I believe, I haven't had time
>to review the latest iterations so I don't have a TPS
>report on the state and progress as of now ...

:-)  I am all out of TPS cover sheets myself...

>> It appears that I could submit a device-tree based driver
>> for the Sony hardware, by adding some support for
>> device tree to the qcom i2c driver, and then adding the device
>> tree support for the sony driver.  But does this lead me into
>> a dead end in mainline?  Will I just have to re-write it later
>> to base it on pinctrl?
>
>I don't know which driver you are talking about here...
>it seems you are referring to drivers which are dependent
>on some kind of pin control handle?
>
>Surely, if the I2C driver or so has its pins set up correctly
>already at boot or some legacy code that is already
>upstream, fine. But expanding and using the legacy
>pin control solutions is not encouraged (by me).

There is some out-of-tree code called i2c-qup.c, that is
sort-of device tree aware now, that the Sony code is based 
on now.  The Sony driver I'm looking to contribute is for
a vibrator module on an i2c bus (it's device tree configuration
should be trivial.)

>The proper pin control framework will grab a "default"
>state for the pins when the device (such as I2C) is
>probed, making it usable. It's mainly a problem with
>dynamic states later on.
>
>> Or am I missing something?  Maybe the migration to the
>> pinctrl-based stuff will be trivial once qcom re-implements
>> their i2c dirver based on pinctrl - but I've currently got no timeline
>> for when that might occur.
>
>Are they calling a lot of custom APIs for this? The device
>core will take care of making it usable, it's mainly the
>runtime PM aspects that will require drivers to be
>pinctrl aware at all. Or some esoteric stuff like
>muxing the I2C block across two sets of pins.

I don't think there's anything tricky here.  I'm willing to
do some legwork to get the i2c-qup driver working with
device tree.  Right now it does a lot of pin handling internally
itself (I believe it brings up the needed gpios, functions, etc.
from boot state).

My question is whether I should just do that, or if the pinctrl
support for these pins is required first, in order to mainline the
Sony vibrator driver.

Thanks,
 -- Tim

Senior Software Engineer, Sony Mobile

Re: pinctrl and device-tree support in qcom drivers

[hanumant]

On 7/25/2013 3:56 PM, Bird, Tim wrote:

>
> I don't think there's anything tricky here.  I'm willing to
> do some legwork to get the i2c-qup driver working with
> device tree.  Right now it does a lot of pin handling internally
> itself (I believe it brings up the needed gpios, functions, etc.
> from boot state).
>
> My question is whether I should just do that, or if the pinctrl
> support for these pins is required first, in order to mainline the
> Sony vibrator driver.

David can advise on the i2c-qup driver support from Qualcomm.
But when that does happen it will use the pinctrl framework to manage
the i2c bus lines.

I will try to push through the pinctrl patch as quickly as possible.
Right now as Linus mentioned, its waiting for his review.

For your vibrator module, do you only rely on the i2c bus lines or
do you also need some pins as reset or interrupt line?

Thanks
Hanumant


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
-- 

RE: pinctrl and device-tree support in qcom drivers

[Bird, Tim]

On Friday, July 26, 2013 10:30 AM, hanumant [hanumant@codeaurora.org] wrote:
>On 7/25/2013 3:56 PM, Bird, Tim wrote:
>David can advise on the i2c-qup driver support from Qualcomm.
>But when that does happen it will use the pinctrl framework to manage
>the i2c bus lines.
OK.  Let me know if there's anything I can do to help.

>
>I will try to push through the pinctrl patch as quickly as possible.
>Right now as Linus mentioned, its waiting for his review.

Thanks.

>For your vibrator module, do you only rely on the i2c bus lines or
>do you also need some pins as reset or interrupt line?

It only relies on the i2c bus lines.  So, once the other stuff is
in place, it should drop right in.
 -- Tim

Re: pinctrl and device-tree support in qcom drivers

[Linus Walleij]

On Fri, Jul 26, 2013 at 12:56 AM, Bird, Tim <Tim.Bird@sonymobile.com> wrote:
> On Thursday, July 25, 2013 3:00 PM, Linus Walleij [linus.walleij@linaro.org] wrote:

>>> My question is this - are all new drivers in mainline expected
>>> to be based on pinctrl?
>>
>>Depends on what you mean by that, we certainly do not
>>allow any more nasty hacks under arch/arm/* or any
>>custom extenstions to GPIO drivers or such.
>
> What if the driver handles the pins directly itself?  That
> makes the driver platform-specific.  Is this disallowed now,
> or are platform-specific drivers OK?

How can a driver handle its pins "directly itself"? To me
that sounds like it need to be calling a custom API unless the
registers are grouped together with that very hardware it's
driving (which is very uncommon).

I.e. how would it get a handle to go poking the apropriate
pin control registers...

The right API to do that is invariably <linux/pinctrl/consumer.h>
or implicitly by defining a "default" state which will make it
configure into that state during probe() for this struct device *.

>>Surely, if the I2C driver or so has its pins set up correctly
>>already at boot or some legacy code that is already
>>upstream, fine. But expanding and using the legacy
>>pin control solutions is not encouraged (by me).
>
> There is some out-of-tree code called i2c-qup.c, that is
> sort-of device tree aware now, that the Sony code is based
> on now.  The Sony driver I'm looking to contribute is for
> a vibrator module on an i2c bus (it's device tree configuration
> should be trivial.)

I don't know if I really want to see said code, but if it's not
using pinctrl it's probably a NACK from my side on that
thing.

> I don't think there's anything tricky here.  I'm willing to
> do some legwork to get the i2c-qup driver working with
> device tree.  Right now it does a lot of pin handling internally
> itself (I believe it brings up the needed gpios, functions, etc.
> from boot state).
>
> My question is whether I should just do that, or if the pinctrl
> support for these pins is required first, in order to mainline the
> Sony vibrator driver.

If this code is controlling pin registers but not using the
pinctrl subsystem, then don't spend time on trying to mainline
it IMO.

Yours,
Linus Walleij

RE: pinctrl and device-tree support in qcom drivers

[Bird, Tim]

On Friday, July 26, 2013 3:47 PM, Linus Walleij [linus.walleij@linaro.org] wrote:
>> What if the driver handles the pins directly itself?  That
>> makes the driver platform-specific.  Is this disallowed now,
>> or are platform-specific drivers OK?
>
>How can a driver handle its pins "directly itself"? To me
>that sounds like it need to be calling a custom API unless the
>registers are grouped together with that very hardware it's
>driving (which is very uncommon).
>
>I.e. how would it get a handle to go poking the apropriate
>pin control registers...

The code uses a pre-pinctrl gpio mux module from msm,
that (I believe) hanumant is now converting to pinctrl.

...
>> There is some out-of-tree code called i2c-qup.c, that is
>> sort-of device tree aware now, that the Sony code is based
>> on now.  The Sony driver I'm looking to contribute is for
>> a vibrator module on an i2c bus (it's device tree configuration
>> should be trivial.)
>
>I don't know if I really want to see said code, but if it's not
>using pinctrl it's probably a NACK from my side on that
>thing.
>
...
>If this code is controlling pin registers but not using the
>pinctrl subsystem, then don't spend time on trying to mainline
>it IMO.

OK. Thanks for the clarification.  Sounds like I should either
wait for Qualcomm, or help them out, to get the pre-requisites
in place for my driver.
 -- Tim