* Re: [PATCH 00/22] SH pinctrl and pinmux implementation
2013-01-03 18:17 [PATCH 00/22] SH pinctrl and pinmux implementation Laurent Pinchart
@ 2013-01-04 15:53 ` Linus Walleij
2013-01-07 13:27 ` Laurent Pinchart
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Linus Walleij @ 2013-01-04 15:53 UTC (permalink / raw)
To: linux-sh
On Thu, Jan 3, 2013 at 7:17 PM, Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> Here's a patch set that implements pinctrl and pinmux support for the SuperH
> and SH Mobile pin controllers (PFC). The patches are based on my previous PFC
> patch series ("[PATCH v4 00/81] SH pin control and GPIO rework") and are
> available from my git tree at
>
> git://linuxtv.org/pinchartl/fbdev.git pinmux-pinctrl
Looking good to me, you can add my Acked-by and take it
in through the SH tree as agreed.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH 00/22] SH pinctrl and pinmux implementation
2013-01-03 18:17 [PATCH 00/22] SH pinctrl and pinmux implementation Laurent Pinchart
2013-01-04 15:53 ` Linus Walleij
@ 2013-01-07 13:27 ` Laurent Pinchart
2013-01-08 9:49 ` Linus Walleij
2013-01-08 17:58 ` Laurent Pinchart
3 siblings, 0 replies; 5+ messages in thread
From: Laurent Pinchart @ 2013-01-07 13:27 UTC (permalink / raw)
To: linux-sh
Hi Linus,
On Friday 04 January 2013 16:53:47 Linus Walleij wrote:
> On Thu, Jan 3, 2013 at 7:17 PM, Laurent Pinchart wrote:
> > Here's a patch set that implements pinctrl and pinmux support for the
> > SuperH and SH Mobile pin controllers (PFC). The patches are based on my
> > previous PFC patch series ("[PATCH v4 00/81] SH pin control and GPIO
> > rework") and are available from my git tree at
> >
> > git://linuxtv.org/pinchartl/fbdev.git pinmux-pinctrl
>
> Looking good to me, you can add my Acked-by and take it in through the SH
> tree as agreed.
Thank you.
Would you have time to share your thoughts about the following issue (copied
from the cover letter of this patch series) ?
I ran into an issue when trying to port the bonito board (the only other
r8a7740 board in mainline) to the pinmux API. My board patches use system pin
control hogging to apply the initial pinmux configuration. This mechanism
requires registering the pinctrl mappings before registering the pinctrl
device, as the default states are selected when the pinctrl device is
registered. However, the mappings vary depending on board configuration read
through GPIOs, and the GPIOs are implemented by the pinctrl driver. One
possible solution would be to apply updates to the selected state as mappings
are registered, but that looks pretty complex at first sight. Other ideas (or,
better, patches :-)) are welcome.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH 00/22] SH pinctrl and pinmux implementation
2013-01-03 18:17 [PATCH 00/22] SH pinctrl and pinmux implementation Laurent Pinchart
2013-01-04 15:53 ` Linus Walleij
2013-01-07 13:27 ` Laurent Pinchart
@ 2013-01-08 9:49 ` Linus Walleij
2013-01-08 17:58 ` Laurent Pinchart
3 siblings, 0 replies; 5+ messages in thread
From: Linus Walleij @ 2013-01-08 9:49 UTC (permalink / raw)
To: linux-sh
On Mon, Jan 7, 2013 at 2:27 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Would you have time to share your thoughts about the following issue (copied
> from the cover letter of this patch series) ?
>
> I ran into an issue when trying to port the bonito board (the only other
> r8a7740 board in mainline) to the pinmux API. My board patches use system pin
> control hogging to apply the initial pinmux configuration. This mechanism
> requires registering the pinctrl mappings before registering the pinctrl
> device, as the default states are selected when the pinctrl device is
> registered. However, the mappings vary depending on board configuration read
> through GPIOs, and the GPIOs are implemented by the pinctrl driver. One
> possible solution would be to apply updates to the selected state as mappings
> are registered, but that looks pretty complex at first sight. Other ideas (or,
> better, patches :-)) are welcome.
Hm, yes today we require that mappings be in place before the pinctrl driver
is registered in order for hogs to work.
With device tree I guess the problem goes away.
But I guess for those not using device tree it'd be nice to modify the map
registration function to check if something needs to be hogged by an already
existing device at that point. If you write a patch for this we can
discuss it...
There is another issue making it desireable to have mappings
registered as early as possible, and that is my patch moving default
pinctrl grabbing into the device core, but generally of course all devices
need their maps in place before probing anyway.
Linus Walleij
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 00/22] SH pinctrl and pinmux implementation
2013-01-03 18:17 [PATCH 00/22] SH pinctrl and pinmux implementation Laurent Pinchart
` (2 preceding siblings ...)
2013-01-08 9:49 ` Linus Walleij
@ 2013-01-08 17:58 ` Laurent Pinchart
3 siblings, 0 replies; 5+ messages in thread
From: Laurent Pinchart @ 2013-01-08 17:58 UTC (permalink / raw)
To: linux-sh
Hi Linus,
On Tuesday 08 January 2013 10:49:32 Linus Walleij wrote:
> On Mon, Jan 7, 2013 at 2:27 PM, Laurent Pinchart wrote:
> > Would you have time to share your thoughts about the following issue
> > (copied from the cover letter of this patch series) ?
> >
> > I ran into an issue when trying to port the bonito board (the only other
> > r8a7740 board in mainline) to the pinmux API. My board patches use system
> > pin control hogging to apply the initial pinmux configuration. This
> > mechanism requires registering the pinctrl mappings before registering
> > the pinctrl device, as the default states are selected when the pinctrl
> > device is registered. However, the mappings vary depending on board
> > configuration read through GPIOs, and the GPIOs are implemented by the
> > pinctrl driver. One possible solution would be to apply updates to the
> > selected state as mappings are registered, but that looks pretty complex
> > at first sight. Other ideas (or, better, patches :-)) are welcome.
>
> Hm, yes today we require that mappings be in place before the pinctrl driver
> is registered in order for hogs to work.
>
> With device tree I guess the problem goes away.
>
> But I guess for those not using device tree it'd be nice to modify the map
> registration function to check if something needs to be hogged by an already
> existing device at that point. If you write a patch for this we can discuss
> it...
>
> There is another issue making it desireable to have mappings registered as
> early as possible, and that is my patch moving default pinctrl grabbing into
> the device core, but generally of course all devices need their maps in
> place before probing anyway.
That's exactly what I need :-) With that patch in place I can register the
pinctrl device before registering the mappings, as long as the mappings are
registered before their associated device.
Is there a chance the patch will make it to v3.9 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 5+ messages in thread