From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [RFC] tegra: dpaux: pinctrl proposal Date: Fri, 22 May 2015 09:41:05 -0600 Message-ID: <555F4E11.3050201@wwwdotorg.org> References: <1431963229-12867-1-git-send-email-jonathanh@nvidia.com> <20150519144654.GG26748@ulmo.nvidia.com> <555C901F.8090009@nvidia.com> <20150520154022.GB7734@ulmo.nvidia.com> <555CAE47.6070907@nvidia.com> <555CDC82.1010104@wwwdotorg.org> <555DD7B3.6020608@nvidia.com> <20150521140356.GA28021@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Walleij , Thierry Reding Cc: Jon Hunter , Alexandre Courbot , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On 05/22/2015 01:03 AM, Linus Walleij wrote: > On Thu, May 21, 2015 at 4:03 PM, Thierry Reding > 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?