Message ID | 1369866529-6372-2-git-send-email-horms+renesas@verge.net.au (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hello. On 05/30/2013 02:28 AM, Simon Horman wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > 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 <sergei.shtylyov@cogentembedded.com> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> I suspect this is needed in -stable. The bug is older than 3.10-rc1. WBR, Sergei
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 <laurent.pinchart+renesas@ideasonboard.com> > > > > 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 <sergei.shtylyov@cogentembedded.com> > > Signed-off-by: Laurent Pinchart > > <laurent.pinchart+renesas@ideasonboard.com> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > 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 <laurent.pinchart+renesas@ideasonboard.com> Date: Thu Mar 7 13:38:51 2013 +0100 sh-pfc: r8a7779: Add USB pin groups and functions Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> and got applied to mainline in v3.10-rc1.
Hello. On 30-05-2013 3:51, Laurent Pinchart wrote: >>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >>> 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 <sergei.shtylyov@cogentembedded.com> >>> Signed-off-by: Laurent Pinchart >>> <laurent.pinchart+renesas@ideasonboard.com> >>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> >> 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 <laurent.pinchart+renesas@ideasonboard.com> > Date: Thu Mar 7 13:38:51 2013 +0100 > sh-pfc: r8a7779: Add USB pin groups and functions > Signed-off-by: Laurent Pinchart > <laurent.pinchart+renesas@ideasonboard.com> > Acked-by: Linus Walleij <linus.walleij@linaro.org> > 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
On Thu, May 30, 2013 at 12:28 AM, Simon Horman <horms+renesas@verge.net.au> wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > 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 <sergei.shtylyov@cogentembedded.com> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> 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
On Thu, May 30, 2013 at 10:08:56PM +0200, Linus Walleij wrote: > On Thu, May 30, 2013 at 12:28 AM, Simon Horman > <horms+renesas@verge.net.au> wrote: > > > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > > > 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 <sergei.shtylyov@cogentembedded.com> > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > 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?
Hi, On Thu, May 30, 2013 at 5:17 PM, Simon Horman <horms@verge.net.au> 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 >> <horms+renesas@verge.net.au> wrote: >> >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >> > >> > 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 <sergei.shtylyov@cogentembedded.com> >> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> >> >> 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
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 <horms@verge.net.au> 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 > >> <horms+renesas@verge.net.au> wrote: > >> > >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >> > > >> > 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 <sergei.shtylyov@cogentembedded.com> > >> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > >> > >> 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.
On Thu, May 30, 2013 at 10:45 PM, Simon Horman <horms@verge.net.au> 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 <horms@verge.net.au> 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 >> >> <horms+renesas@verge.net.au> wrote: >> >> >> >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >> >> > >> >> > 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 <sergei.shtylyov@cogentembedded.com> >> >> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >> >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> >> >> >> >> 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
On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <olof@lixom.net> 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
On Thu, May 30, 2013 at 11:11:36PM -0700, Olof Johansson wrote: > On Thu, May 30, 2013 at 10:45 PM, Simon Horman <horms@verge.net.au> 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 <horms@verge.net.au> 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 > >> >> <horms+renesas@verge.net.au> wrote: > >> >> > >> >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >> >> > > >> >> > 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 <sergei.shtylyov@cogentembedded.com> > >> >> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > >> >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > >> >> > >> >> 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.
On Fri, May 31, 2013 at 09:21:46AM +0200, Linus Walleij wrote: > On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <olof@lixom.net> 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.
On Fri, May 31, 2013 at 09:21:46AM +0200, Linus Walleij wrote: > On Fri, May 31, 2013 at 8:11 AM, Olof Johansson <olof@lixom.net> 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
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[] = {