Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Thu, Feb 25, 2016 at 02:08:44PM -0300, Fabio Estevam wrote: > On Wed, Feb 24, 2016 at 10:20 PM, Peter Chen wrote: > > > Would you get any chances to test i.mx28 evk with an external HUB? > > I just would like to know it is not a HUB issue which can't be > > suspended. >

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Wed, Feb 24, 2016 at 10:20 PM, Peter Chen wrote: > Would you get any chances to test i.mx28 evk with an external HUB? > I just would like to know it is not a HUB issue which can't be > suspended. Just connected an external USB hub on a mx28evk and did not see any

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Wed, Feb 24, 2016 at 11:23:01AM -0300, Fabio Estevam wrote: > On Wed, Feb 24, 2016 at 10:29 AM, Felipe Balbi wrote: > > >> [2.814449] usb 1-1: new high-speed USB device number 2 using ci_hdrc > >> [2.857129] fec 800f.ethernet eth0: Freescale FEC PHY driver > >>

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Wed, Feb 24, 2016 at 10:29 AM, Felipe Balbi wrote: >> [2.814449] usb 1-1: new high-speed USB device number 2 using ci_hdrc >> [2.857129] fec 800f.ethernet eth0: Freescale FEC PHY driver >> [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=800f.etherne:00, irq) >> [

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi, Fabio Estevam writes: > On Wed, Feb 24, 2016 at 8:48 AM, Fabio Estevam wrote: > >> and this is the result: > > I missed to post the first print. Here is the complete log: > > [2.375588] usbcore: registered new interface driver usb-storage > [

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Wed, Feb 24, 2016 at 8:48 AM, Fabio Estevam wrote: > and this is the result: I missed to post the first print. Here is the complete log: [2.375588] usbcore: registered new interface driver usb-storage [2.405944] ** Calling ci_hdrc_imx_runtime_suspend

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Wed, Feb 24, 2016 at 8:32 AM, Felipe Balbi wrote: > Then that's the problem. You should _always_ implement your runtime_pm > callbacks otherwise driver model will assume you don't need to do > ANYTHING for runtime pm and runtime suspend you unconditionally. > > As a test,

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi, Fabio Estevam writes: > Hi Felipe, > > On Wed, Feb 24, 2016 at 7:47 AM, Felipe Balbi wrote: > >> Then what DOES get called ? If we don't reach runtime_pm of the PHY, >> we must reach runtime_pm of chipidea. In that case, detect _there_ if >> you're

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi Felipe, On Wed, Feb 24, 2016 at 7:47 AM, Felipe Balbi wrote: > Then what DOES get called ? If we don't reach runtime_pm of the PHY, we > must reach runtime_pm of chipidea. In that case, detect _there_ if > you're running on one of the known broken ones and return -EBUSY or

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi, Fabio Estevam writes: > On Tue, Feb 23, 2016 at 11:44 PM, Peter Chen wrote: > >> Just plug in an external USB HUB at i.mx28 evk host port without pass >> ''usbcore.autosuspend=-1' at bootargs to see if it works. > > Well, the board I have is based on

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Tue, Feb 23, 2016 at 11:44 PM, Peter Chen wrote: > Just plug in an external USB HUB at i.mx28 evk host port without pass > ''usbcore.autosuspend=-1' at bootargs to see if it works. Well, the board I have is based on mx28 and has a USB hub onboard. It does not work without

RE: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

> On Tue, Feb 23, 2016 at 10:20 PM, Peter Chen > wrote: > > > Oh, you said it is called before. > > > > http://www.spinics.net/lists/linux-usb/msg136714.html > > Yes, I have enabled runtime pm previously. Sorry for the confusion. > > > If you make sure the neither

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Tue, Feb 23, 2016 at 10:20 PM, Peter Chen wrote: > Oh, you said it is called before. > > http://www.spinics.net/lists/linux-usb/msg136714.html Yes, I have enabled runtime pm previously. Sorry for the confusion. > If you make sure the neither .runtime_suspend at

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Tue, Feb 23, 2016 at 05:06:12PM -0300, Fabio Estevam wrote: > On Tue, Feb 23, 2016 at 4:47 PM, Fabio Estevam wrote: > > Hi Peter, > > > > On Sun, Feb 21, 2016 at 10:59 PM, Peter Chen wrote: > > > >> Fabio, Felipe is correct. The mx23 and mx28 should

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Tue, Feb 23, 2016 at 4:47 PM, Fabio Estevam wrote: > Hi Peter, > > On Sun, Feb 21, 2016 at 10:59 PM, Peter Chen wrote: > >> Fabio, Felipe is correct. The mx23 and mx28 should NOT call mxs phy's >> suspend API >> since the runtime suspend is not

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi Peter, On Sun, Feb 21, 2016 at 10:59 PM, Peter Chen wrote: > Fabio, Felipe is correct. The mx23 and mx28 should NOT call mxs phy's > suspend API > since the runtime suspend is not enabled for mx23 and mx28 at chipidea driver. > Would you please check if

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Fri, Feb 19, 2016 at 11:05 PM, Fabio Estevam wrote: > On Fri, Feb 19, 2016 at 12:13 PM, Felipe Balbi wrote: > >> h, okay. So you have another problem, actually. Seems like ci_hdrc >> just shouldn't call your phy->suspend(), or your phy->suspend() >>

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Fri, Feb 19, 2016 at 12:13 PM, Felipe Balbi wrote: > h, okay. So you have another problem, actually. Seems like ci_hdrc > just shouldn't call your phy->suspend(), or your phy->suspend() > shouldn't do anything. How about below? > > @@ -370,6 +370,9 @@ static int

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi, Fabio Estevam writes: > On Fri, Feb 19, 2016 at 11:33 AM, Felipe Balbi wrote: > >> alright, in which sense doesn't it help ? Which platform did you use ? > > USB devices are not recognized with your patch applied on a mx28 board > with an on-board USB

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

On Fri, Feb 19, 2016 at 11:33 AM, Felipe Balbi wrote: > alright, in which sense doesn't it help ? Which platform did you use ? USB devices are not recognized with your patch applied on a mx28 board with an on-board USB hub and if I remove 'usbcore.autosuspend=-1' from the

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi, Fabio Estevam writes: > Hi Felipe, > > On Fri, Feb 19, 2016 at 10:05 AM, Felipe Balbi wrote: > >> how about detecting that you're running on mx23/mx28 and returning >> -EBUSY on your runtime_idle implementation ? You already have the basics >> done for

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi Felipe, On Fri, Feb 19, 2016 at 10:05 AM, Felipe Balbi wrote: > how about detecting that you're running on mx23/mx28 and returning > -EBUSY on your runtime_idle implementation ? You already have the basics > done for it. Care to test below and tell me whether it helps ?

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

Hi, Fabio Estevam writes: > From: Fabio Estevam > > On a mx28 board with a USB hub the following error is observed: > > hub 1-1:1.0: USB hub found > hub 1-1:1.0: 2 ports detected > usb 1-1: USB disconnect, device number 2 > usb usb1-port1: cannot

[PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

From: Fabio Estevam On a mx28 board with a USB hub the following error is observed: hub 1-1:1.0: USB hub found hub 1-1:1.0: 2 ports detected usb 1-1: USB disconnect, device number 2 usb usb1-port1: cannot reset (err = -32) usb usb1-port1: cannot reset (err = -32) usb