On Fri, May 22, 2015 at 09:03:17AM +0200, 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. I think the situation is somewhat more complicated for Intel than it is for ARM because most of these interfaces have grown out of the ARM camp as a means to address the absence of things like ACPI to deal with this kind of resource. It seems one of the obstacles Intel is facing in the mobile/embedded market is that some aspects of the SoCs are structured very similarly to what we're used to from the ARM world, but there's not enough infrastructure to deal with this disconnect. I think they are pretty much at a point now where ARM was a couple of years ago, and I suspect they might run into similar problems unless they address this early on. One of the examples I've seen, and I think that was where you were involved too, was that they now need essentially board files to set up these types of resources. I've always thought x86 should adopt device tree more aggressively, especially in the embedded/mobile space where they're facing the same problems that we've long solved on ARM. Most of the glue is already there, and platforms exist that use it successfully (I've worked on some of them before myself). > >> 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. Thanks for being pragmatic here. I think there's potential to make the job as a maintainer more difficult because now you have to scan more than a single directory when you update API, and you potentially have a harder time build testing. But I think that problem can be addressed by improving our tooling rather than by imposing artificial barriers on driver code. Thierry
Attachment:
pgphAuUh8NDcG.pgp
Description: PGP signature
