| Message ID | 1386059589-4030-1-git-send-email-marek.belisko@open-nandra.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: > Without this change when booting omap3 device (gta04) with board file > leads to follwing errors: > > [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy > [ 1.209075] HS USB OTG: no transceiver configured > [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 > > and usb isn't working. > > This is probably regression caused by commit: 6c27f939 I think a better fix would be to have this merged.. https://lkml.org/lkml/2013/7/26/91 > > Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> > --- > arch/arm/mach-omap2/twl-common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c > index b0d54da..3640ce0 100644 > --- a/arch/arm/mach-omap2/twl-common.c > +++ b/arch/arm/mach-omap2/twl-common.c > @@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void) > > #if defined(CONFIG_ARCH_OMAP3) > struct phy_consumer consumers[] = { > - PHY_CONSUMER("musb-hdrc.0", "usb"), > + PHY_CONSUMER("musb-hdrc.0.auto", "usb"), the index '0' might vary for some boards leading it to again break musb. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: > Hi, > > On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: >> Without this change when booting omap3 device (gta04) with board file >> leads to follwing errors: >> >> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy >> [ 1.209075] HS USB OTG: no transceiver configured >> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 >> >> and usb isn't working. >> >> This is probably regression caused by commit: 6c27f939 > > I think a better fix would be to have this merged.. > https://lkml.org/lkml/2013/7/26/91 Yes I see but how this could help with current situation? Ho you then specify device number? This patch is fixing 3.13-rcx regression. >> >> Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> >> --- >> arch/arm/mach-omap2/twl-common.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c >> index b0d54da..3640ce0 100644 >> --- a/arch/arm/mach-omap2/twl-common.c >> +++ b/arch/arm/mach-omap2/twl-common.c >> @@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void) >> >> #if defined(CONFIG_ARCH_OMAP3) >> struct phy_consumer consumers[] = { >> - PHY_CONSUMER("musb-hdrc.0", "usb"), >> + PHY_CONSUMER("musb-hdrc.0.auto", "usb"), > > the index '0' might vary for some boards leading it to again break musb. If you run grep for musb-hdrc : arch/arm/mach-omap2/board-3430sdp.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-devkit8000.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-overo.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-omap3beagle.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-omap3touchbook.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-cm-t35.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-omap3stalker.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-omap3logic.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-2430sdp.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-ldp.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-rx51.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); arch/arm/mach-omap2/board-omap3pandora.c: usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); Until mentioned patch isn't merged and PHY_CONSUMER isn't updated I think this is correct solution. > > Thanks > Kishon BR, marek
Hi, On Tuesday 03 December 2013 02:38 PM, Belisko Marek wrote: > Hi, > > On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: >> Hi, >> >> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: >>> Without this change when booting omap3 device (gta04) with board file >>> leads to follwing errors: >>> >>> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy >>> [ 1.209075] HS USB OTG: no transceiver configured >>> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 >>> >>> and usb isn't working. >>> >>> This is probably regression caused by commit: 6c27f939 >> >> I think a better fix would be to have this merged.. >> https://lkml.org/lkml/2013/7/26/91 > Yes I see but how this could help with current situation? Ho you then > specify device number? With this we can for sure know the device numbering (of MUSB) starts from '0'. If we use PLATFORM_DEVID_AUTO, we won't know what dev number has been assigned to us. In your case you get "musb-hdrc.0.auto" because no one else is creating a device using PLATFORM_DEVID_AUTO (before your device is created). > This patch is fixing 3.13-rcx regression. > >>> >>> Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> >>> --- >>> arch/arm/mach-omap2/twl-common.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c >>> index b0d54da..3640ce0 100644 >>> --- a/arch/arm/mach-omap2/twl-common.c >>> +++ b/arch/arm/mach-omap2/twl-common.c >>> @@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void) >>> >>> #if defined(CONFIG_ARCH_OMAP3) >>> struct phy_consumer consumers[] = { >>> - PHY_CONSUMER("musb-hdrc.0", "usb"), >>> + PHY_CONSUMER("musb-hdrc.0.auto", "usb"), >> >> the index '0' might vary for some boards leading it to again break musb. > If you run grep for musb-hdrc : > arch/arm/mach-omap2/board-3430sdp.c: usb_bind_phy("musb-hdrc.0.auto", > 0, "twl4030_usb"); > arch/arm/mach-omap2/board-devkit8000.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-overo.c: usb_bind_phy("musb-hdrc.0.auto", 0, > "twl4030_usb"); > arch/arm/mach-omap2/board-omap3beagle.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-omap3touchbook.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-cm-t35.c: usb_bind_phy("musb-hdrc.0.auto", > 0, "twl4030_usb"); > arch/arm/mach-omap2/board-omap3stalker.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-omap3logic.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-2430sdp.c: usb_bind_phy("musb-hdrc.0.auto", > 0, "twl4030_usb"); > arch/arm/mach-omap2/board-ldp.c: usb_bind_phy("musb-hdrc.0.auto", 0, > "twl4030_usb"); > arch/arm/mach-omap2/board-rx51.c: usb_bind_phy("musb-hdrc.0.auto", 0, > "twl4030_usb"); > arch/arm/mach-omap2/board-omap3pandora.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); hmm.. that patch was in a series that fixes this too https://lkml.org/lkml/2013/7/26/88 Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek <marek.belisko@gmail.com> wrote: > Hi, > > On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: >> Hi, >> >> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: >>> Without this change when booting omap3 device (gta04) with board file >>> leads to follwing errors: >>> >>> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy >>> [ 1.209075] HS USB OTG: no transceiver configured >>> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 >>> >>> and usb isn't working. >>> >>> This is probably regression caused by commit: 6c27f939 >> >> I think a better fix would be to have this merged.. >> https://lkml.org/lkml/2013/7/26/91 > Yes I see but how this could help with current situation? Ho you then > specify device number? I was too fast with reply sorry. I can see whole series and it is of course correct solution. But as I said can we except to be merged to 3.13. If not Tony can you pick my patch. > This patch is fixing 3.13-rcx regression. > >>> >>> Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> >>> --- >>> arch/arm/mach-omap2/twl-common.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c >>> index b0d54da..3640ce0 100644 >>> --- a/arch/arm/mach-omap2/twl-common.c >>> +++ b/arch/arm/mach-omap2/twl-common.c >>> @@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void) >>> >>> #if defined(CONFIG_ARCH_OMAP3) >>> struct phy_consumer consumers[] = { >>> - PHY_CONSUMER("musb-hdrc.0", "usb"), >>> + PHY_CONSUMER("musb-hdrc.0.auto", "usb"), >> >> the index '0' might vary for some boards leading it to again break musb. > If you run grep for musb-hdrc : > arch/arm/mach-omap2/board-3430sdp.c: usb_bind_phy("musb-hdrc.0.auto", > 0, "twl4030_usb"); > arch/arm/mach-omap2/board-devkit8000.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-overo.c: usb_bind_phy("musb-hdrc.0.auto", 0, > "twl4030_usb"); > arch/arm/mach-omap2/board-omap3beagle.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-omap3touchbook.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-cm-t35.c: usb_bind_phy("musb-hdrc.0.auto", > 0, "twl4030_usb"); > arch/arm/mach-omap2/board-omap3stalker.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-omap3logic.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > arch/arm/mach-omap2/board-2430sdp.c: usb_bind_phy("musb-hdrc.0.auto", > 0, "twl4030_usb"); > arch/arm/mach-omap2/board-ldp.c: usb_bind_phy("musb-hdrc.0.auto", 0, > "twl4030_usb"); > arch/arm/mach-omap2/board-rx51.c: usb_bind_phy("musb-hdrc.0.auto", 0, > "twl4030_usb"); > arch/arm/mach-omap2/board-omap3pandora.c: > usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); > > Until mentioned patch isn't merged and PHY_CONSUMER isn't updated I > think this is correct solution. >> >> Thanks >> Kishon > > BR, > > marek > > -- > as simple and primitive as possible > ------------------------------------------------- > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com BR, marek
* Belisko Marek <marek.belisko@gmail.com> [131203 01:21]: > On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek <marek.belisko@gmail.com> wrote: > > Hi, > > > > On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: > >> Hi, > >> > >> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: > >>> Without this change when booting omap3 device (gta04) with board file > >>> leads to follwing errors: > >>> > >>> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy > >>> [ 1.209075] HS USB OTG: no transceiver configured > >>> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 > >>> > >>> and usb isn't working. > >>> > >>> This is probably regression caused by commit: 6c27f939 > >> > >> I think a better fix would be to have this merged.. > >> https://lkml.org/lkml/2013/7/26/91 > > Yes I see but how this could help with current situation? Ho you then > > specify device number? > I was too fast with reply sorry. I can see whole series and it is of > course correct solution. But as I said > can we except to be merged to 3.13. If not Tony can you pick my patch. If it's a regression, then let's get it merged for the -rc cycle. So please try to follow up on getting the proper fix merged, meanwhile I'll mark this thread as read. If you need this one merged for some reason, then please report to get it back to my radar. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren <tony@atomide.com> wrote: > * Belisko Marek <marek.belisko@gmail.com> [131203 01:21]: >> On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek <marek.belisko@gmail.com> wrote: >> > Hi, >> > >> > On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: >> >> Hi, >> >> >> >> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: >> >>> Without this change when booting omap3 device (gta04) with board file >> >>> leads to follwing errors: >> >>> >> >>> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy >> >>> [ 1.209075] HS USB OTG: no transceiver configured >> >>> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 >> >>> >> >>> and usb isn't working. >> >>> >> >>> This is probably regression caused by commit: 6c27f939 >> >> >> >> I think a better fix would be to have this merged.. >> >> https://lkml.org/lkml/2013/7/26/91 >> > Yes I see but how this could help with current situation? Ho you then >> > specify device number? >> I was too fast with reply sorry. I can see whole series and it is of >> course correct solution. But as I said >> can we except to be merged to 3.13. If not Tony can you pick my patch. > > If it's a regression, then let's get it merged for the -rc cycle. Yes it is regression and without that usb on most omap3 based boards without DT will not work. > > So please try to follow up on getting the proper fix merged, meanwhile > I'll mark this thread as read. If you need this one merged for some > reason, then please report to get it back to my radar. > > Regards, > > Tony BR, marek
* Belisko Marek <marek.belisko@gmail.com> [131208 23:36]: > Hi Tony, > > On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren <tony@atomide.com> wrote: > > * Belisko Marek <marek.belisko@gmail.com> [131203 01:21]: > >> On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek <marek.belisko@gmail.com> wrote: > >> > Hi, > >> > > >> > On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: > >> >> Hi, > >> >> > >> >> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: > >> >>> Without this change when booting omap3 device (gta04) with board file > >> >>> leads to follwing errors: > >> >>> > >> >>> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy > >> >>> [ 1.209075] HS USB OTG: no transceiver configured > >> >>> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 > >> >>> > >> >>> and usb isn't working. > >> >>> > >> >>> This is probably regression caused by commit: 6c27f939 > >> >> > >> >> I think a better fix would be to have this merged.. > >> >> https://lkml.org/lkml/2013/7/26/91 > >> > Yes I see but how this could help with current situation? Ho you then > >> > specify device number? > >> I was too fast with reply sorry. I can see whole series and it is of > >> course correct solution. But as I said > >> can we except to be merged to 3.13. If not Tony can you pick my patch. > > > > If it's a regression, then let's get it merged for the -rc cycle. > Yes it is regression and without that usb on most omap3 based boards > without DT will not work. > > > > So please try to follow up on getting the proper fix merged, meanwhile > > I'll mark this thread as read. If you need this one merged for some > > reason, then please report to get it back to my radar. I'm still clueless which USB regression fix to apply for the -rc cycle though.. Hoping to see a single patch which clearly states the issue and has acks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 9, 2013 at 6:50 PM, Tony Lindgren <tony@atomide.com> wrote: > * Belisko Marek <marek.belisko@gmail.com> [131208 23:36]: >> Hi Tony, >> >> On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren <tony@atomide.com> wrote: >> > * Belisko Marek <marek.belisko@gmail.com> [131203 01:21]: >> >> On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek <marek.belisko@gmail.com> wrote: >> >> > Hi, >> >> > >> >> > On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: >> >> >> Hi, >> >> >> >> >> >> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: >> >> >>> Without this change when booting omap3 device (gta04) with board file >> >> >>> leads to follwing errors: >> >> >>> >> >> >>> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy >> >> >>> [ 1.209075] HS USB OTG: no transceiver configured >> >> >>> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 >> >> >>> >> >> >>> and usb isn't working. >> >> >>> >> >> >>> This is probably regression caused by commit: 6c27f939 >> >> >> >> >> >> I think a better fix would be to have this merged.. >> >> >> https://lkml.org/lkml/2013/7/26/91 >> >> > Yes I see but how this could help with current situation? Ho you then >> >> > specify device number? >> >> I was too fast with reply sorry. I can see whole series and it is of >> >> course correct solution. But as I said >> >> can we except to be merged to 3.13. If not Tony can you pick my patch. >> > >> > If it's a regression, then let's get it merged for the -rc cycle. >> Yes it is regression and without that usb on most omap3 based boards >> without DT will not work. >> > >> > So please try to follow up on getting the proper fix merged, meanwhile >> > I'll mark this thread as read. If you need this one merged for some >> > reason, then please report to get it back to my radar. > > I'm still clueless which USB regression fix to apply for the -rc cycle > though.. Hoping to see a single patch which clearly states the issue > and has acks. Kishon can you please comment on that? Would be possible to get your patch to 3.13 (I seen some comments from Felipe). Otherwise I think only possible option to avoid non-working usb in 3.13 for omap is took my patch. Thanks. > > Regards, > > Tony BR, marek
Hi, On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: > On Mon, Dec 9, 2013 at 6:50 PM, Tony Lindgren <tony@atomide.com> wrote: >> * Belisko Marek <marek.belisko@gmail.com> [131208 23:36]: >>> Hi Tony, >>> >>> On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren <tony@atomide.com> wrote: >>>> * Belisko Marek <marek.belisko@gmail.com> [131203 01:21]: >>>>> On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek <marek.belisko@gmail.com> wrote: >>>>>> Hi, >>>>>> >>>>>> On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: >>>>>>>> Without this change when booting omap3 device (gta04) with board file >>>>>>>> leads to follwing errors: >>>>>>>> >>>>>>>> [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy >>>>>>>> [ 1.209075] HS USB OTG: no transceiver configured >>>>>>>> [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 >>>>>>>> >>>>>>>> and usb isn't working. >>>>>>>> >>>>>>>> This is probably regression caused by commit: 6c27f939 >>>>>>> >>>>>>> I think a better fix would be to have this merged.. >>>>>>> https://lkml.org/lkml/2013/7/26/91 >>>>>> Yes I see but how this could help with current situation? Ho you then >>>>>> specify device number? >>>>> I was too fast with reply sorry. I can see whole series and it is of >>>>> course correct solution. But as I said >>>>> can we except to be merged to 3.13. If not Tony can you pick my patch. >>>> >>>> If it's a regression, then let's get it merged for the -rc cycle. >>> Yes it is regression and without that usb on most omap3 based boards >>> without DT will not work. >>>> >>>> So please try to follow up on getting the proper fix merged, meanwhile >>>> I'll mark this thread as read. If you need this one merged for some >>>> reason, then please report to get it back to my radar. >> >> I'm still clueless which USB regression fix to apply for the -rc cycle >> though.. Hoping to see a single patch which clearly states the issue >> and has acks. > Kishon can you please comment on that? Would be possible to get your > patch to 3.13 (I seen some comments from Felipe). I'm not sure as my patch modifies all the board files. There was initially some confusion w.r.t when the board files will be dropped. But since board files will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways if you have tested my patch (series), pls give your Tested-by. Tony, summary of the issue.. After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. So had to make the corresponding changes in board files. [1] -> http://lists.scusting.com/index.php?t=msg&th=375579&start=0&S=Google Thanks Kishon > Otherwise I think only possible option to avoid non-working usb in > 3.13 for omap is took my patch. Thanks. >> >> Regards, >> >> Tony > > BR, > > marek > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kishon Vijay Abraham I <kishon@ti.com> [131213 03:57]: > On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: > > Kishon can you please comment on that? Would be possible to get your > > patch to 3.13 (I seen some comments from Felipe). > > I'm not sure as my patch modifies all the board files. There was initially some > confusion w.r.t when the board files will be dropped. But since board files > will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways > if you have tested my patch (series), pls give your Tested-by. > > Tony, summary of the issue.. > After the platform devices are created using PLATFORM_DEVID_AUTO, the > device names given in usb_bind_phy (in board file) does not match with > the actual device name causing the USB PHY library not to return the > PHY reference when the MUSB controller request for the PHY in the non-dt boot > case. So removed creating platform devices using PLATFORM_DEVID_AUTO in > omap2430.c. So had to make the corresponding changes in board files. OK. Can you please repost with a proper commit id for what caused the regression and summararize why it should be fixed this way. Something like: Commit abcd1234 (usb: blah foo bar) caused blah blah blah. Fix the issue with blah blah blah. Note that the board-*.c files will be removed soon, but for v3.13 we still support both legacy booting and device tree based booting and need to fix it. Regards, Tony > [1] -> http://lists.scusting.com/index.php?t=msg&th=375579&start=0&S=Google -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Friday 13 December 2013 11:06 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I <kishon@ti.com> [131213 03:57]: >> On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: >>> Kishon can you please comment on that? Would be possible to get your >>> patch to 3.13 (I seen some comments from Felipe). >> >> I'm not sure as my patch modifies all the board files. There was initially some >> confusion w.r.t when the board files will be dropped. But since board files >> will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways >> if you have tested my patch (series), pls give your Tested-by. >> >> Tony, summary of the issue.. >> After the platform devices are created using PLATFORM_DEVID_AUTO, the >> device names given in usb_bind_phy (in board file) does not match with >> the actual device name causing the USB PHY library not to return the >> PHY reference when the MUSB controller request for the PHY in the non-dt boot >> case. So removed creating platform devices using PLATFORM_DEVID_AUTO in >> omap2430.c. So had to make the corresponding changes in board files. > > OK. Can you please repost with a proper commit id for what caused the > regression and summararize why it should be fixed this way. Something like: > > Commit abcd1234 (usb: blah foo bar) caused blah blah blah. Fix the issue > with blah blah blah. Note that the board-*.c files will be removed soon, > but for v3.13 we still support both legacy booting and device tree based > booting and need to fix it. huh.. I think we can have a much simpler fix. All this binding in board file was introduced to support platforms that has multiple PHYs of the same type. But musb/omap2430.c serves platforms that has only one PHY of a particular type. We can just go back to usb_get_phy(enum usb_phy_type type) instead of 'usb_get_phy_dev' in omap2430.c. Felipe, what do you think? Cheers Kishon > > Regards, > > Tony > >> [1] -> http://lists.scusting.com/index.php?t=msg&th=375579&start=0&S=Google -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 16 December 2013 02:22 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 13 December 2013 11:06 PM, Tony Lindgren wrote: >> * Kishon Vijay Abraham I <kishon@ti.com> [131213 03:57]: >>> On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: >>>> Kishon can you please comment on that? Would be possible to get your >>>> patch to 3.13 (I seen some comments from Felipe). >>> >>> I'm not sure as my patch modifies all the board files. There was initially some >>> confusion w.r.t when the board files will be dropped. But since board files >>> will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways >>> if you have tested my patch (series), pls give your Tested-by. >>> >>> Tony, summary of the issue.. >>> After the platform devices are created using PLATFORM_DEVID_AUTO, the >>> device names given in usb_bind_phy (in board file) does not match with >>> the actual device name causing the USB PHY library not to return the >>> PHY reference when the MUSB controller request for the PHY in the non-dt boot >>> case. So removed creating platform devices using PLATFORM_DEVID_AUTO in >>> omap2430.c. So had to make the corresponding changes in board files. >> >> OK. Can you please repost with a proper commit id for what caused the >> regression and summararize why it should be fixed this way. Something like: >> >> Commit abcd1234 (usb: blah foo bar) caused blah blah blah. Fix the issue >> with blah blah blah. Note that the board-*.c files will be removed soon, >> but for v3.13 we still support both legacy booting and device tree based >> booting and need to fix it. > > huh.. I think we can have a much simpler fix. All this binding in board file > was introduced to support platforms that has multiple PHYs of the same type. > But musb/omap2430.c serves platforms that has only one PHY of a particular > type. We can just go back to usb_get_phy(enum usb_phy_type type) instead of > 'usb_get_phy_dev' in omap2430.c. Felipe, what do you think? Never-mind, that doesn't work. I'll just re-send the patch the way you suggested. Cheers Kishon > > Cheers > Kishon > >> >> Regards, >> >> Tony >> >>> [1] -> http://lists.scusting.com/index.php?t=msg&th=375579&start=0&S=Google > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c index b0d54da..3640ce0 100644 --- a/arch/arm/mach-omap2/twl-common.c +++ b/arch/arm/mach-omap2/twl-common.c @@ -92,7 +92,7 @@ void __init omap_pmic_late_init(void) #if defined(CONFIG_ARCH_OMAP3) struct phy_consumer consumers[] = { - PHY_CONSUMER("musb-hdrc.0", "usb"), + PHY_CONSUMER("musb-hdrc.0.auto", "usb"), }; struct phy_init_data init_data = {
Without this change when booting omap3 device (gta04) with board file leads to follwing errors: [ 1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy [ 1.209075] HS USB OTG: no transceiver configured [ 1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 and usb isn't working. This is probably regression caused by commit: 6c27f939 Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com> --- arch/arm/mach-omap2/twl-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)