Re: [RFC] tegra: dpaux: pinctrl proposal

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 05/22/2015 01:03 AM, 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.
>
> There are good reasons for. These drivers are usually so complex
> that things like probing and power up/down become a nightmare
> with cross-subsystem dependencies.
>
> They are a special case. I had a long discussion with Intel's
> Daniel Vetter about this and they (Intel) eventually used GPIO
> for some stuff where it would fit nicely, but didn't go to use fixed
> regulators as I had suggested.
>
>>> However, it does mean that all the pinctrl/pinmux/pinconf ops for this
>>> pinctrl device will need to live in drivers/gpu/drm/tegra/dpaux.c which
>>> is fine,
>
> Yeah that's cool I already have e.g. GPIO chips all over the map,
> including DRM IIRC.
>
>>> but I *believe* that would require moving
>>> drivers/pinctrl/pinctrl-utils.h to include/linux/pinctrl/ in order to
>>> make use of these functions.
>
> Well I originally intended that to be private and neat, but whatever.
> Call it pinctrl-utils-internal.h or something then.

Sorry for the bikeshed: perhaps s/internal/provider/? If all providers 
would need this, does it even make sense to merge it into 
include/linuxp/pinctrl/pinctrl.h, which defines all the other stuff 
providers use?