Re: [RFC] tegra: dpaux: pinctrl proposal

[Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On 22/05/15 15:37, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Fri, May 22, 2015 at 01:17:02PM +0100, Jon Hunter wrote:
>>
>> On 22/05/15 08:03, Linus Walleij wrote:
>>> On Thu, May 21, 2015 at 4:03 PM, Thierry Reding
>>> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>>>>> I don't see any conceptual reason why the driver that binds to that node
>>>>>> can't register as both a pinctrl driver plus anything else it needs to.
>>> (...)
>>>>> Looking at it there should not be a problem here with regard to the
>>>>> driver_data member of the device struct and so I don't see why the
>>>>> tegra_dpaux_probe() could not call pinctrl_register() to register the
>>>>> device.
>>>>
>>>> Yes, I think that'd be the best solution.
>>>
>>> I'm pretty much ready to go to any compromises to get DRM/GPU
>>> drivers to use internal kernel subsystems. The tendency there
>>> is to reimplement all kernel driver frameworks and hammer registers
>>> they need to access.
>>
>> Thanks Linus, but after looking at this further I don't think this
>> approach will work after all. In order to call pinctrl_register() from
>> outside the pinctrl directory, also means exposing the pinctrl_dev and
>> pinctrl_desc structures and so this will get messy. Or at least a bigger
>> churn than I would have hoped for.
> 
> It's not that much churn, is it? The structure definitions could be
> moved to include/linux/pinctrl/machine.h. That's included by core.h in
> drivers/pinctrl anyway, so that should really be all there is to it.

I took a quick look and I would need to move pinctrl, pinctrl_dev and
pinctrl_state. So may be not too bad. pinctrl/machine.h makes logical
sense, but not sure if they would be more suited to pinctrl/pinctrl.h.

>> Thierry, what if we add a drivers/pinctrl/pinctrl-tegra-dpaux.c and then
>> simply call platform_device_register_data() from tegra_dpaux_probe() to
>> register the device? I could still use the parent of_node to match the
>> platform data for the dpaux pin controller.
> 
> That'd work for me too. But if that's what it comes down to, I don't see
> a need to go through the driver model. Why not simply expose a simple
> set of functions to setup and tear down the pinctrl that the DPAUX
> driver can call?

Sorry, but I don't understand how that would work :-(

> I'd still clearly prefer to have the pinctrl code live directly in the
> DPAUX driver, so I think we should at least give that a shot.

It's fine with me if Linus is ok with the changes.

Cheers
Jon