After discussing with some people involved with pin control, we agreed
that it will just cause trouble to have separate handles for pin muxing
and pin configuration in callers - they will definately want to set all
pin aspects regarding muxing and other configuration with one single
call.
These three patches take the first step in this transformation by moving
the per-device handles over to core code, and renaming all related
functions with the pinctrl_* prefix.
Linus Walleij (3):
pinctrl: break out a pinctrl consumer header
pinctrl: move generic functions to the pinctrl_ namespace
pinctrl: factor pin control handles over to the core
Documentation/pinctrl.txt | 124 ++++---
arch/arm/mach-u300/core.c | 24 +-
drivers/pinctrl/core.c | 602 +++++++++++++++++++++++++++++++-
drivers/pinctrl/core.h | 34 ++-
drivers/pinctrl/pinctrl-coh901.c | 6 +-
drivers/pinctrl/pinmux.c | 732 ++++++--------------------------------
drivers/pinctrl/pinmux.h | 67 ++++-
include/linux/pinctrl/consumer.h | 118 ++++++
include/linux/pinctrl/machine.h | 8 +-
include/linux/pinctrl/pinconf.h | 39 --
include/linux/pinctrl/pinmux.h | 52 ---
11 files changed, 991 insertions(+), 815 deletions(-)
create mode 100644 include/linux/pinctrl/consumer.h
--
1.7.7.6
On 02/09/2012 11:00 AM, Linus Walleij wrote:
> After discussing with some people involved with pin control, we agreed
> that it will just cause trouble to have separate handles for pin muxing
> and pin configuration in callers - they will definately want to set all
> pin aspects regarding muxing and other configuration with one single
> call.
>
> These three patches take the first step in this transformation by moving
> the per-device handles over to core code, and renaming all related
> functions with the pinctrl_* prefix.
The series,
Acked-by: Stephen Warren <[email protected]>
Note that this series will cause some compile breakage in the series I
previously posted to add a pinctrl-tegra driver and convert mach-tegra
to use it. The following patches in that series should still be OK:
pinctrl: add a driver for NVIDIA Tegra
ARM: tegra: Select PINCTRL Kconfig variables
... so you can still go ahead and apply those, but the following will be
broken:
ARM: tegra: Switch to new pinctrl driver
ARM: tegra: Remove pre-pinctrl pinmux driver
also the separately posted:
ARM: tegra: Add pinmux board file for Cardhu
I'll probably hold off reposting those last 3; with any luck they'll be
eclipsed by my implementing full DT binding support in the near future,
given our consensus on that topic following discussion at Linaro Connect.
--
nvpublic
On Fri, Feb 10, 2012 at 5:58 AM, Stephen Warren <[email protected]> wrote:
>> These three patches take the first step in this transformation by moving
>> the per-device handles over to core code, and renaming all related
>> functions with the pinctrl_* prefix.
>
> The series,
> Acked-by: Stephen Warren <[email protected]>
Thanks, I've managed to push this to -next with the v2 version of
[2/3] and the hog patch.
> Note that this series will cause some compile breakage in the series I
> previously posted to add a pinctrl-tegra driver and convert mach-tegra
> to use it. The following patches in that series should still be OK:
>
> pinctrl: add a driver for NVIDIA Tegra
> ARM: tegra: Select PINCTRL Kconfig variables
>
> ... so you can still go ahead and apply those, but the following will be
> broken:
>
> ARM: tegra: Switch to new pinctrl driver
> ARM: tegra: Remove pre-pinctrl pinmux driver
>
> also the separately posted:
>
> ARM: tegra: Add pinmux board file for Cardhu
>
> I'll probably hold off reposting those last 3; with any luck they'll be
> eclipsed by my implementing full DT binding support in the near future,
> given our consensus on that topic following discussion at Linaro Connect.
OK, alternatively I could remove these for the time being, or I
can fix up the mess I created if you prefer, by just adding
a patch on top, so it gets changed over no matter if the
DT stuff gets sorted out for this merge window?
Thanks,
Linus Walleij
On 02/10/2012 12:51 PM, Linus Walleij wrote:
> On Fri, Feb 10, 2012 at 5:58 AM, Stephen Warren <[email protected]> wrote:
>
>>> These three patches take the first step in this transformation by moving
>>> the per-device handles over to core code, and renaming all related
>>> functions with the pinctrl_* prefix.
>>
>> The series,
>> Acked-by: Stephen Warren <[email protected]>
>
> Thanks, I've managed to push this to -next with the v2 version of
> [2/3] and the hog patch.
>
>> Note that this series will cause some compile breakage in the series I
>> previously posted to add a pinctrl-tegra driver and convert mach-tegra
>> to use it. The following patches in that series should still be OK:
>>
>> pinctrl: add a driver for NVIDIA Tegra
>> ARM: tegra: Select PINCTRL Kconfig variables
>>
>> ... so you can still go ahead and apply those, but the following will be
>> broken:
>>
>> ARM: tegra: Switch to new pinctrl driver
>> ARM: tegra: Remove pre-pinctrl pinmux driver
>>
>> also the separately posted:
>>
>> ARM: tegra: Add pinmux board file for Cardhu
>>
>> I'll probably hold off reposting those last 3; with any luck they'll be
>> eclipsed by my implementing full DT binding support in the near future,
>> given our consensus on that topic following discussion at Linaro Connect.
>
> OK, alternatively I could remove these for the time being, or I
> can fix up the mess I created if you prefer, by just adding
> a patch on top, so it gets changed over no matter if the
> DT stuff gets sorted out for this merge window?
I'll probably want to rework the 3 patches your changes break anyway (in
order to completely remove use of board-*-pinmux.c when booting from DT,
once I write the DT code) and so you may as well not apply them, just
the driver itself. It'll save some churn.
--
nvpublic
On Sat, Feb 11, 2012 at 7:18 AM, Stephen Warren <[email protected]> wrote:
> I'll probably want to rework the 3 patches your changes break anyway (in
> order to completely remove use of board-*-pinmux.c when booting from DT,
> once I write the DT code) and so you may as well not apply them, just
> the driver itself. It'll save some churn.
OK will that happen for this merge window or is the driver going to sit
unused for the 3.4 cycle?
I'm mainly thinking if the underlying driver may be subject to change I
could just keep it out-of-tree, unless you want it merged in for some
practical reason, then I'll just merge it.
Yours,
Linus Walleij
Linus Walleij wrote at Monday, February 13, 2012 12:48 PM:
> On Sat, Feb 11, 2012 at 7:18 AM, Stephen Warren <[email protected]> wrote:
>
> > I'll probably want to rework the 3 patches your changes break anyway (in
> > order to completely remove use of board-*-pinmux.c when booting from DT,
> > once I write the DT code) and so you may as well not apply them, just
> > the driver itself. It'll save some churn.
>
> OK will that happen for this merge window or is the driver going to sit
> unused for the 3.4 cycle?
>
> I'm mainly thinking if the underlying driver may be subject to change I
> could just keep it out-of-tree, unless you want it merged in for some
> practical reason, then I'll just merge it.
IIRC, people hoped that the common pinctrl bindings would make it into
3.4. If that happens, the driver won't be unused in 3.4.
I don't foresee any changes to the driver except those driven by any
changes to the core pinctrl itself, so I don't foresee any need to keep
it out of tree.
--
nvpublic
On Mon, Feb 13, 2012 at 9:01 PM, Stephen Warren <[email protected]> wrote:
> Linus Walleij wrote at Monday, February 13, 2012 12:48 PM:
>>
>> I'm mainly thinking if the underlying driver may be subject to change I
>> could just keep it out-of-tree, unless you want it merged in for some
>> practical reason, then I'll just merge it.
>
> IIRC, people hoped that the common pinctrl bindings would make it into
> 3.4. If that happens, the driver won't be unused in 3.4.
>
> I don't foresee any changes to the driver except those driven by any
> changes to the core pinctrl itself, so I don't foresee any need to keep
> it out of tree.
OK however since the patches no longer mess around in arch/arm/mach-*
I guess it's OK if I just throw it on the top of my patch queue with
everything else rather than as a separate branch?
I'll do that for now, tell me if it causes any problems!
Yours,
Linus Walleij