On 05/22/2015 01:03 AM, Linus Walleij wrote:
On Thu, May 21, 2015 at 4:03 PM, Thierry Reding
<thierry.reding@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
