[1/2] sh-pfc: r8a7779: Don't group USB OVC and PENC pins

Commit Message

Simon Horman May 29, 2013, 10:28 p.m. UTC

From: Laurent Pinchart <[e-mail]>

The USB_OVCn pins are alternate options for USB over-current detection
when using a 3.3V USB interface. As they're not mandatory they can be
used independently of the USB PENC pins. Don't group the USB_OVCn and
PENC pins to avoid conflicts when the USB_OVCn pins are used by another
function.

Reported-by: Sergei Shtylyov <[e-mail]>
Signed-off-by: Laurent Pinchart <[e-mail]>
Signed-off-by: Simon Horman <[e-mail]>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |   45 +++++++++++++++++++++++++++-------
 1 file changed, 36 insertions(+), 9 deletions(-)

Comments

Sergei Shtylyov May 29, 2013, 10:35 p.m. UTC | #1

Hello.

On 05/30/2013 02:28 AM, Simon Horman wrote:

> From: Laurent Pinchart <[e-mail]>
>
> The USB_OVCn pins are alternate options for USB over-current detection
> when using a 3.3V USB interface. As they're not mandatory they can be
> used independently of the USB PENC pins. Don't group the USB_OVCn and
> PENC pins to avoid conflicts when the USB_OVCn pins are used by another
> function.
>
> Reported-by: Sergei Shtylyov <[e-mail]>
> Signed-off-by: Laurent Pinchart <[e-mail]>
> Signed-off-by: Simon Horman <[e-mail]>

    I suspect this is needed in -stable. The bug is older than 3.10-rc1.

WBR, Sergei

Laurent Pinchart May 29, 2013, 11:51 p.m. UTC | #2

Hi Sergei,

On Thursday 30 May 2013 02:35:51 Sergei Shtylyov wrote:
> On 05/30/2013 02:28 AM, Simon Horman wrote:
> > From: Laurent Pinchart <[e-mail]>
> > 
> > The USB_OVCn pins are alternate options for USB over-current detection
> > when using a 3.3V USB interface. As they're not mandatory they can be
> > used independently of the USB PENC pins. Don't group the USB_OVCn and
> > PENC pins to avoid conflicts when the USB_OVCn pins are used by another
> > function.
> > 
> > Reported-by: Sergei Shtylyov <[e-mail]>
> > Signed-off-by: Laurent Pinchart
> > <[e-mail]>
> > Signed-off-by: Simon Horman <[e-mail]>
> 
> I suspect this is needed in -stable. The bug is older than 3.10-rc1.

Is it ? The offending commit is

commit 97d40c4224172451f666febdd865c24b1c3c3fe5
Author: Laurent Pinchart <[e-mail]>
Date:   Thu Mar 7 13:38:51 2013 +0100

    sh-pfc: r8a7779: Add USB pin groups and functions
    
    Signed-off-by: Laurent Pinchart 
<[e-mail]>
    Acked-by: Linus Walleij <[e-mail]>

and got applied to mainline in v3.10-rc1.

Sergei Shtylyov May 30, 2013, 11:50 a.m. UTC | #3

Hello.

On 30-05-2013 3:51, Laurent Pinchart wrote:

>>> From: Laurent Pinchart <[e-mail]>

>>> The USB_OVCn pins are alternate options for USB over-current detection
>>> when using a 3.3V USB interface. As they're not mandatory they can be
>>> used independently of the USB PENC pins. Don't group the USB_OVCn and
>>> PENC pins to avoid conflicts when the USB_OVCn pins are used by another
>>> function.

>>> Reported-by: Sergei Shtylyov <[e-mail]>
>>> Signed-off-by: Laurent Pinchart
>>> <[e-mail]>
>>> Signed-off-by: Simon Horman <[e-mail]>

>> I suspect this is needed in -stable. The bug is older than 3.10-rc1.

> Is it ? The offending commit is

> commit 97d40c4224172451f666febdd865c24b1c3c3fe5
> Author: Laurent Pinchart <[e-mail]>
> Date:   Thu Mar 7 13:38:51 2013 +0100

>      sh-pfc: r8a7779: Add USB pin groups and functions

>      Signed-off-by: Laurent Pinchart
> <[e-mail]>
>      Acked-by: Linus Walleij <[e-mail]>

> and got applied to mainline in v3.10-rc1.

    Ah, then sorry for the false alarm. Consequency of working in the 
'next' branch all the time...

WBR, Sergei

Linus Walleij May 30, 2013, 8:08 p.m. UTC | #4

On Thu, May 30, 2013 at 12:28 AM, Simon Horman
<[e-mail]> wrote:

> From: Laurent Pinchart <[e-mail]>
>
> The USB_OVCn pins are alternate options for USB over-current detection
> when using a 3.3V USB interface. As they're not mandatory they can be
> used independently of the USB PENC pins. Don't group the USB_OVCn and
> PENC pins to avoid conflicts when the USB_OVCn pins are used by another
> function.
>
> Reported-by: Sergei Shtylyov <[e-mail]>
> Signed-off-by: Laurent Pinchart <[e-mail]>
> Signed-off-by: Simon Horman <[e-mail]>

OK, Acked-by, do you want me to take this as a fix in the pinctrl
tree for v3.10?

Just asking because Simon usually takes everything else relating to
the SH. ...

Yours,
Linus Walleij

Simon Horman May 31, 2013, 12:17 a.m. UTC | #5

On Thu, May 30, 2013 at 10:08:56PM +0200, Linus Walleij wrote:
> On Thu, May 30, 2013 at 12:28 AM, Simon Horman
> <[e-mail]> wrote:
> 
> > From: Laurent Pinchart <[e-mail]>
> >
> > The USB_OVCn pins are alternate options for USB over-current detection
> > when using a 3.3V USB interface. As they're not mandatory they can be
> > used independently of the USB PENC pins. Don't group the USB_OVCn and
> > PENC pins to avoid conflicts when the USB_OVCn pins are used by another
> > function.
> >
> > Reported-by: Sergei Shtylyov <[e-mail]>
> > Signed-off-by: Laurent Pinchart <[e-mail]>
> > Signed-off-by: Simon Horman <[e-mail]>
> 
> OK, Acked-by, do you want me to take this as a fix in the pinctrl
> tree for v3.10?
> 
> Just asking because Simon usually takes everything else relating to
> the SH. ...

This was a pull request from my tree to arm-soc, so thats they way
I was planning to handle things.

Olof, Arnd,

should I re-spin the pull request to include Linus's ack?

Olof Johansson May 31, 2013, 4:43 a.m. UTC | #6

Hi,

On Thu, May 30, 2013 at 5:17 PM, Simon Horman <[e-mail]> wrote:
> On Thu, May 30, 2013 at 10:08:56PM +0200, Linus Walleij wrote:
>> On Thu, May 30, 2013 at 12:28 AM, Simon Horman
>> <[e-mail]> wrote:
>>
>> > From: Laurent Pinchart <[e-mail]>
>> >
>> > The USB_OVCn pins are alternate options for USB over-current detection
>> > when using a 3.3V USB interface. As they're not mandatory they can be
>> > used independently of the USB PENC pins. Don't group the USB_OVCn and
>> > PENC pins to avoid conflicts when the USB_OVCn pins are used by another
>> > function.
>> >
>> > Reported-by: Sergei Shtylyov <[e-mail]>
>> > Signed-off-by: Laurent Pinchart <[e-mail]>
>> > Signed-off-by: Simon Horman <[e-mail]>
>>
>> OK, Acked-by, do you want me to take this as a fix in the pinctrl
>> tree for v3.10?
>>
>> Just asking because Simon usually takes everything else relating to
>> the SH. ...
>
> This was a pull request from my tree to arm-soc, so thats they way
> I was planning to handle things.
>
> Olof, Arnd,
>
> should I re-spin the pull request to include Linus's ack?

You can if you want, but for an odd and specific fix like this we'll
all know he's ok with the code going in.


-Olof

Simon Horman May 31, 2013, 5:45 a.m. UTC | #7

On Thu, May 30, 2013 at 09:43:08PM -0700, Olof Johansson wrote:
> Hi,
> 
> On Thu, May 30, 2013 at 5:17 PM, Simon Horman <[e-mail]> wrote:
> > On Thu, May 30, 2013 at 10:08:56PM +0200, Linus Walleij wrote:
> >> On Thu, May 30, 2013 at 12:28 AM, Simon Horman
> >> <[e-mail]> wrote:
> >>
> >> > From: Laurent Pinchart <[e-mail]>
> >> >
> >> > The USB_OVCn pins are alternate options for USB over-current detection
> >> > when using a 3.3V USB interface. As they're not mandatory they can be
> >> > used independently of the USB PENC pins. Don't group the USB_OVCn and
> >> > PENC pins to avoid conflicts when the USB_OVCn pins are used by another
> >> > function.
> >> >
> >> > Reported-by: Sergei Shtylyov <[e-mail]>
> >> > Signed-off-by: Laurent Pinchart <[e-mail]>
> >> > Signed-off-by: Simon Horman <[e-mail]>
> >>
> >> OK, Acked-by, do you want me to take this as a fix in the pinctrl
> >> tree for v3.10?
> >>
> >> Just asking because Simon usually takes everything else relating to
> >> the SH. ...
> >
> > This was a pull request from my tree to arm-soc, so thats they way
> > I was planning to handle things.
> >
> > Olof, Arnd,
> >
> > should I re-spin the pull request to include Linus's ack?
> 
> You can if you want, but for an odd and specific fix like this we'll
> all know he's ok with the code going in.

In that case my preference is to leave the pull request as is.
Could you consider merging it?

As an aside, I do expect to send some more v3.10 fixes for shmobile.
There seem to be more than usual.

Olof Johansson May 31, 2013, 6:11 a.m. UTC | #8

On Thu, May 30, 2013 at 10:45 PM, Simon Horman <[e-mail]> wrote:
> On Thu, May 30, 2013 at 09:43:08PM -0700, Olof Johansson wrote:
>> Hi,
>>
>> On Thu, May 30, 2013 at 5:17 PM, Simon Horman <[e-mail]> wrote:
>> > On Thu, May 30, 2013 at 10:08:56PM +0200, Linus Walleij wrote:
>> >> On Thu, May 30, 2013 at 12:28 AM, Simon Horman
>> >> <[e-mail]> wrote:
>> >>
>> >> > From: Laurent Pinchart <[e-mail]>
>> >> >
>> >> > The USB_OVCn pins are alternate options for USB over-current detection
>> >> > when using a 3.3V USB interface. As they're not mandatory they can be
>> >> > used independently of the USB PENC pins. Don't group the USB_OVCn and
>> >> > PENC pins to avoid conflicts when the USB_OVCn pins are used by another
>> >> > function.
>> >> >
>> >> > Reported-by: Sergei Shtylyov <[e-mail]>
>> >> > Signed-off-by: Laurent Pinchart <[e-mail]>
>> >> > Signed-off-by: Simon Horman <[e-mail]>
>> >>
>> >> OK, Acked-by, do you want me to take this as a fix in the pinctrl
>> >> tree for v3.10?
>> >>
>> >> Just asking because Simon usually takes everything else relating to
>> >> the SH. ...
>> >
>> > This was a pull request from my tree to arm-soc, so thats they way
>> > I was planning to handle things.
>> >
>> > Olof, Arnd,
>> >
>> > should I re-spin the pull request to include Linus's ack?
>>
>> You can if you want, but for an odd and specific fix like this we'll
>> all know he's ok with the code going in.
>
> In that case my preference is to leave the pull request as is.
> Could you consider merging it?

Yes, I will do a pass tomorrow and handle the outstanding merges.

> As an aside, I do expect to send some more v3.10 fixes for shmobile.
> There seem to be more than usual.

A little unfortunate but it's hard to do much about.

Please be conservative with what you pick up for 3.10 vs 3.11 -- Linus
has said he really wants to see things slow down.

And please make our case as easy as possible by making sure it's
pretty clear from the patch descriptions what kind of bugs they fix
(and if they are regressions).



-Olof

Linus Walleij May 31, 2013, 7:21 a.m. UTC | #9

On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <[e-mail]> wrote:
> [Simon]
>> As an aside, I do expect to send some more v3.10 fixes for shmobile.
>> There seem to be more than usual.
>
> A little unfortunate but it's hard to do much about.
>
> Please be conservative with what you pick up for 3.10 vs 3.11 -- Linus
> has said he really wants to see things slow down.

What we might need to think about is the evolutional pace of the ARM
kernel - compared to a few years back we have increased the change
rate by orders of a magnitude (at least that is my feeling...)

There may be some point where we actually need to tell people to
hold changes back because they are just pushing too large volumes
through one merge window, resulting in a corresponding amount of
fixes.

This merge window both Samsung Exynos and SH mobile seem to
have been a little bit trigger-happy :-/

Yours,
Linus Walleij

Simon Horman May 31, 2013, 7:43 a.m. UTC | #10

On Thu, May 30, 2013 at 11:11:36PM -0700, Olof Johansson wrote:
> On Thu, May 30, 2013 at 10:45 PM, Simon Horman <[e-mail]> wrote:
> > On Thu, May 30, 2013 at 09:43:08PM -0700, Olof Johansson wrote:
> >> Hi,
> >>
> >> On Thu, May 30, 2013 at 5:17 PM, Simon Horman <[e-mail]> wrote:
> >> > On Thu, May 30, 2013 at 10:08:56PM +0200, Linus Walleij wrote:
> >> >> On Thu, May 30, 2013 at 12:28 AM, Simon Horman
> >> >> <[e-mail]> wrote:
> >> >>
> >> >> > From: Laurent Pinchart <[e-mail]>
> >> >> >
> >> >> > The USB_OVCn pins are alternate options for USB over-current detection
> >> >> > when using a 3.3V USB interface. As they're not mandatory they can be
> >> >> > used independently of the USB PENC pins. Don't group the USB_OVCn and
> >> >> > PENC pins to avoid conflicts when the USB_OVCn pins are used by another
> >> >> > function.
> >> >> >
> >> >> > Reported-by: Sergei Shtylyov <[e-mail]>
> >> >> > Signed-off-by: Laurent Pinchart <[e-mail]>
> >> >> > Signed-off-by: Simon Horman <[e-mail]>
> >> >>
> >> >> OK, Acked-by, do you want me to take this as a fix in the pinctrl
> >> >> tree for v3.10?
> >> >>
> >> >> Just asking because Simon usually takes everything else relating to
> >> >> the SH. ...
> >> >
> >> > This was a pull request from my tree to arm-soc, so thats they way
> >> > I was planning to handle things.
> >> >
> >> > Olof, Arnd,
> >> >
> >> > should I re-spin the pull request to include Linus's ack?
> >>
> >> You can if you want, but for an odd and specific fix like this we'll
> >> all know he's ok with the code going in.
> >
> > In that case my preference is to leave the pull request as is.
> > Could you consider merging it?
> 
> Yes, I will do a pass tomorrow and handle the outstanding merges.
> 
> > As an aside, I do expect to send some more v3.10 fixes for shmobile.
> > There seem to be more than usual.
> 
> A little unfortunate but it's hard to do much about.
> 
> Please be conservative with what you pick up for 3.10 vs 3.11 -- Linus
> has said he really wants to see things slow down.
> 
> And please make our case as easy as possible by making sure it's
> pretty clear from the patch descriptions what kind of bugs they fix
> (and if they are regressions).

Understood. I will be careful to only send the bare essentials for v3.10.

Simon Horman June 1, 2013, midnight UTC | #11

On Fri, May 31, 2013 at 09:21:46AM +0200, Linus Walleij wrote:
> On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <[e-mail]> wrote:
> > [Simon]
> >> As an aside, I do expect to send some more v3.10 fixes for shmobile.
> >> There seem to be more than usual.
> >
> > A little unfortunate but it's hard to do much about.
> >
> > Please be conservative with what you pick up for 3.10 vs 3.11 -- Linus
> > has said he really wants to see things slow down.
> 
> What we might need to think about is the evolutional pace of the ARM
> kernel - compared to a few years back we have increased the change
> rate by orders of a magnitude (at least that is my feeling...)
> 
> There may be some point where we actually need to tell people to
> hold changes back because they are just pushing too large volumes
> through one merge window, resulting in a corresponding amount of
> fixes.
> 
> This merge window both Samsung Exynos and SH mobile seem to
> have been a little bit trigger-happy :-/

To quantify things, for shmobile I am currently aware of 4 problems that
seem to be worthy of fixing for v3.10. A patche for one has been
accepted into arm-soc, Patches for two are this pull request. And one more
has a patch in the pipeline.

These known problems seem to fall into two categories:

1. Problems that have been in linux-next for a while but only recently
   appeared in the renesas tree. These were observed when boot testing kernels
   during the course of rebasing the renesas tree on v3.10-rcX.

   I believe that these problems could and should have been
   spotted earlier by boot testing linux-next more often,
   allowing them to be resolved in the merge-window rather than
   at -rc time.

   I intend to make this happen.

2. Problems that have been present in the renesas tree and
   thus linux-next for a while but were not observed as
   early as they might have been.

   Statistically the rate of these problems could have
   been reduced by accepting changes more slowly.
   But at this point we are talking about one or two bugs out
   of many many changes. Bugs that only affect a small
   subset of shmobile hardware support.

Olof Johansson June 1, 2013, 4:35 a.m. UTC | #12

On Fri, May 31, 2013 at 09:21:46AM +0200, Linus Walleij wrote:
> On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <[e-mail]> wrote:
> > [Simon]
> >> As an aside, I do expect to send some more v3.10 fixes for shmobile.
> >> There seem to be more than usual.
> >
> > A little unfortunate but it's hard to do much about.
> >
> > Please be conservative with what you pick up for 3.10 vs 3.11 -- Linus
> > has said he really wants to see things slow down.
> 
> What we might need to think about is the evolutional pace of the ARM
> kernel - compared to a few years back we have increased the change
> rate by orders of a magnitude (at least that is my feeling...)

Oh, very much so. And there's a lot of additions of new code.

Linus clarified just this week at LC Japan what ticks him off about -rc
patches too; it's an indication that people aren't sending code that's
baked and tested enough during the merge window, causing all these fixes
on top.

Given the rate of change of arm platforms, some of this is definitely
expected (i.e. proportional to amount of merge window changes). Still,
we have empirical evidence that far from all maintainers keep a close
eye on linux-next status for their platforms. :-)

I have a small board farm that I make sure boot more or less daily
with linux-next now, but my space is limited. It also shouldn't be my
responsibility to make sure that various platforms keep working; it's
up to each submaintainer to do so.

That doesn't mean there won't be corner cases still, hardware that
maintainers don't have themselves affected, etc. But by keeping an eye
on linux-next, a handful of -rc fixes can be avoided.

> There may be some point where we actually need to tell people to
> hold changes back because they are just pushing too large volumes
> through one merge window, resulting in a corresponding amount of
> fixes.

That's essentially what we did with the initial multiplatform changes for 3.10
for Exynos, where they seemed to need more bake time and got held off.

> This merge window both Samsung Exynos and SH mobile seem to
> have been a little bit trigger-happy :-/

Both of them saw a lot of changes. Exynos saw the onslaught of Linaro
engineers starting to work more on Arndale, and shmobile saw a huge
amount of changes due to their cutting over subsystems. The latter
is hard to avoid since it can be complicated to keep both old and new
infrastructure around, and the former we should just make sure to catch
with linux-next testing.

But you do bring up valid points, and it's something to keep in mind going
forward.


-Olof

Patch

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 791a671..8cd90e7 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -2357,27 +2357,48 @@  static const unsigned int sdhi3_wp_mux[] = {
 };
 /* - USB0 ------------------------------------------------------------------- */
 static const unsigned int usb0_pins[] = {
-	/* OVC */
-	150, 154,
+	/* PENC */
+	154,
 };
 static const unsigned int usb0_mux[] = {
-	USB_OVC0_MARK, USB_PENC0_MARK,
+	USB_PENC0_MARK,
+};
+static const unsigned int usb0_ovc_pins[] = {
+	/* USB_OVC */
+	150
+};
+static const unsigned int usb0_ovc_mux[] = {
+	USB_OVC0_MARK,
 };
 /* - USB1 ------------------------------------------------------------------- */
 static const unsigned int usb1_pins[] = {
-	/* OVC */
-	152, 155,
+	/* PENC */
+	155,
 };
 static const unsigned int usb1_mux[] = {
-	USB_OVC1_MARK, USB_PENC1_MARK,
+	USB_PENC1_MARK,
+};
+static const unsigned int usb1_ovc_pins[] = {
+	/* USB_OVC */
+	152,
+};
+static const unsigned int usb1_ovc_mux[] = {
+	USB_OVC1_MARK,
 };
 /* - USB2 ------------------------------------------------------------------- */
 static const unsigned int usb2_pins[] = {
-	/* OVC, PENC */
-	125, 156,
+	/* PENC */
+	156,
 };
 static const unsigned int usb2_mux[] = {
-	USB_OVC2_MARK, USB_PENC2_MARK,
+	USB_PENC2_MARK,
+};
+static const unsigned int usb2_ovc_pins[] = {
+	/* USB_OVC */
+	125,
+};
+static const unsigned int usb2_ovc_mux[] = {
+	USB_OVC2_MARK,
 };
 
 static const struct sh_pfc_pin_group pinmux_groups[] = {
@@ -2501,8 +2522,11 @@  static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(sdhi3_cd),
 	SH_PFC_PIN_GROUP(sdhi3_wp),
 	SH_PFC_PIN_GROUP(usb0),
+	SH_PFC_PIN_GROUP(usb0_ovc),
 	SH_PFC_PIN_GROUP(usb1),
+	SH_PFC_PIN_GROUP(usb1_ovc),
 	SH_PFC_PIN_GROUP(usb2),
+	SH_PFC_PIN_GROUP(usb2_ovc),
 };
 
 static const char * const du0_groups[] = {
@@ -2683,14 +2707,17 @@  static const char * const sdhi3_groups[] = {
 
 static const char * const usb0_groups[] = {
 	"usb0",
+	"usb0_ovc",
 };
 
 static const char * const usb1_groups[] = {
 	"usb1",
+	"usb1_ovc",
 };
 
 static const char * const usb2_groups[] = {
 	"usb2",
+	"usb2_ovc",
 };
 
 static const struct sh_pfc_function pinmux_functions[] = {