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@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. >> >> 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 -- 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