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. >> May be that is fine too. I could put >> together a patch series and see what everyone thinks. > > I guess it depends mostly on whether Linus (Cc'ed) is willing to have > drivers outside of drivers/pinctrl implement pin controllers. For this case: go ahead. Yours, Linus Walleij -- 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
