Re: [PATCH v3 4/4] doc: usb: ci-hdrc-usb2: Add pinctrl properties for HSIC pin groups

On Wed, Dec 5, 2018 at 5:57 AM PETER CHEN wrote: > So, there are two examples at binding-doc, one for normal, one for HSIC? > Fabio, do you > mean that? If DT maintainer agrees it too, I will add it. Yes, I think it will makes things clearer. Thanks

Re: [PATCH v3 4/4] doc: usb: ci-hdrc-usb2: Add pinctrl properties for HSIC pin groups

Hi Frieder, On Tue, Dec 4, 2018 at 12:31 PM Schrempf Frieder wrote: > There are many other optional properties for this driver and a lot of > them are not in the given example. Maybe we should just keep the > pinctrls for HSIC-mode out of the example, too? I am just trying to make life easier

Re: [PATCH] usb: chipidea: imx: unify over-current polarity handling

Hi Uwe, [Adding Matt] On Fri, Nov 30, 2018 at 6:53 PM Uwe Kleine-König wrote: > > The status quo is: > - on i.MX25 the overcurrent polarity is always explicitly configured as >active high which matches the reset default. > - on i.MX6 and i.MX7 the overcurrent polarity is active high after

Re: [PATCH v3 4/4] doc: usb: ci-hdrc-usb2: Add pinctrl properties for HSIC pin groups

Hi Peter, On Tue, Nov 27, 2018 at 7:31 AM PETER CHEN wrote: > > For USB HSIC, the data and strobe pin needs to be pulled down > at default, we consider it as "idle" state. When the USB host > is ready to be used, the strobe pin needs to be pulled up, > we consider it as "active" state. > >

Re: Set reference clock for onboard hub in DT

Hi Frieder, On Thu, Sep 20, 2018 at 10:52 AM Frieder Schrempf wrote: > > Hi, > > I have a question concerning the setup for a board with an onboard USB > hub. The SoC (i.MX6S) is expected to provide a 12 MHz clock on one of > the clock output pins as a reference for the USB hub. > > Now I was

Re: [PATCH v2 4/4] doc: usb: ci-hdrc-usb2: Add pinctrl properties for HSIC pin groups

On Mon, Oct 22, 2018 at 11:55 AM Schrempf Frieder wrote: > I think you forgot to improve this description. Maybe something like this: > > pinctrl-names: Names for optional pin modes for "default", "host" or > "device". In case of HSIC-mode "idle" and "active" pin >

Re: [PATCH 4/4] doc: usb: ci-hdrc-usb2: Add pinctrl properties for HSIC pin groups

Hi Peter, On Tue, Oct 16, 2018 at 2:02 AM Peter Chen wrote: > > For USB HSIC, the data and strobe pin needs to be pulled down > at default, we consider it as "idle" state. When the USB host > is ready to be used, the strobe pin needs to be pulled up, > we consider it as "active" state. > >

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

Hi Peter, On Wed, Jul 4, 2018 at 5:24 AM, Peter Chen wrote: > It seems there is no harm if we always include drivers/usb/chipidea/ulpi.c > except increasing > a little code size, how about always build ulpi.c for the whole chipidea at > Makefile, delete > CONFIG_USB_CHIPIDEA_ULPI as well,

[PATCH v2] usb: chipidea: Always build ULPI code

From: Fabio Estevam Commit 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51") causes a kernel hang on imx51 systems that use the ULPI interface and do not select the CONFIG_USB_CHIPIDEA_ULPI option. In order to avoid such potential misuse, let's always build the chipidea ULPI code into

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

Hi Shawn, On Tue, Jul 3, 2018 at 12:40 AM, Shawn Guo wrote: > We can have the options in defconfig, but they can still be turned off > for whatever reason and we get the hang. Really, missing a user > selectable option in defconfig shouldn't result in a system hang. Yes, 100% agree and this

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

Hi Shawn, On Mon, Jul 2, 2018 at 11:06 PM, Shawn Guo wrote: > A second thought on this - shouldn't such dependency be solved by > Kconfig select clause? I suspect we are not able to fix it via Kconfig as we really don't know if a system uses ULPI interface or not via Kconfig perspective. If

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

On Mon, Jul 2, 2018 at 10:48 PM, Shawn Guo wrote: > I will make sure both defconfig patches go into 4.18-rc. Thanks, Shawn! Peter, Could you please then queue this chipidea patch for 4.18-rc? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

Hi Peter, On Mon, Jul 2, 2018 at 12:08 AM, Peter Chen wrote: > Fabio, since this function has dependency with defconfig, is the defconfig > change a fix for v4.18-rc > or for v4.19-rc1? I have sent the defconfig changes for imx_v6_v7_defconfig and imx_v4_v5_defconfig and hope that they could

Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

Hi Peter, On Mon, Jun 25, 2018 at 11:51 PM, Peter Chen wrote: > Fabio, I wonder it may cause the USB not work at imx27 which > do not use this configuration now. Any possibilities to test and verify it? I don't have access to a mx27 board, but I can send a patch that selects

[PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

From: Fabio Estevam Since commit 03e6275ae381087bd8 ("usb: chipidea: Fix ULPI on imx51") the kernel hangs on a imx51-babbage board, when using the ULPI interface with the CONFIG_USB_CHIPIDEA_ULPI option unselected. Instead of hanging the kernel, let's warn the user that CONFIG_USB_CHI

Re: [PATCH] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

On Mon, Jun 25, 2018 at 11:06 AM, Fabio Estevam wrote: > From: Fabio Estevam > > Since commit 03e6275ae381087bd8 ("usb: chipidea: Fix ULPI on imx51") the > kernel hangs on a imx51-babbage board, when using the ULPI interface with > the CONFIG_USB_CHIPIDEA_ULPI optio

[PATCH] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

From: Fabio Estevam Since commit 03e6275ae381087bd8 ("usb: chipidea: Fix ULPI on imx51") the kernel hangs on a imx51-babbage board, when using the ULPI interface with the CONFIG_USB_CHIPIDEA_ULPI option unselected. Instead of hanging the kernel, let's warn the user that CONFIG_USB_CHI

Re: Continuous USB resets on NXP i.MX 6ULL device

Hi Stefan, On Wed, Feb 28, 2018 at 2:08 PM, Stefan Wahren wrote: > Hi, > > i'm not sure this is related, but i noticed something ugly in > driver/usb/chipidea/usbmisc_imx.c. > > The compatible "fsl,imx6ul-usbmisc" uses imx6sx_usbmisc_ops, which uses > usbmisc_imx6sx_init

Re: [PATCH v2] usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28

Hi Felipe, On Mon, Jan 22, 2018 at 10:28 AM, Fabio Estevam <feste...@gmail.com> wrote: > Hi Felipe, > > On Thu, Jan 18, 2018 at 12:22 AM, Fabio Estevam <feste...@gmail.com> wrote: >> From: Fabio Estevam <fabio.este...@nxp.com> >> >> Commit e9365

[PATCH v2] usb: phy: mxs: Staticize mxs_charger_secondary_detection()

From: Fabio Estevam <fabio.este...@nxp.com> mxs_charger_secondary_detection() is only used in this file, so make it static. This fixes the following sparse warning: drivers/usb/phy/phy-mxs-usb.c:581:23: warning: symbol 'mxs_charger_secondary_detection' was not declared. Should it be

[PATCH] usb: phy: mxs: Stactize mxs_charger_secondary_detection()

mxs_charger_secondary_detection() is only used in this file, so make it static. This fixes the following sparse warning: drivers/usb/phy/phy-mxs-usb.c:581:23: warning: symbol 'mxs_charger_secondary_detection' was not declared. Should it be static? Signed-off-by: Fabio Estevam <fe

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

Hi Michael, On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi wrote: > SION bit should be used in the situation that we need > to read back the value of a pin and should be set by > default. This can generate any kind of random malfunction > as described in this

Re: [PATCH v2] usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28

Hi Felipe, On Thu, Jan 18, 2018 at 12:22 AM, Fabio Estevam <feste...@gmail.com> wrote: > From: Fabio Estevam <fabio.este...@nxp.com> > > Commit e93650994a95 ("usb: phy: mxs: add usb charger type detection") > causes the following kernel hang on i.MX28: > >

[PATCH v2] usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28

From: Fabio Estevam <fabio.este...@nxp.com> Commit e93650994a95 ("usb: phy: mxs: add usb charger type detection") causes the following kernel hang on i.MX28: [2.207973] usbcore: registered new interface driver usb-storage [2.235659] Unable to handle kernel NULL poi

[PATCH] usb: phy: mxs: Do not run charger detection on i.MX23/28

2.271921] PC is at regmap_read+0x0/0x5c [2.275977] LR is at mxs_phy_charger_detect+0x34/0x1dc The USB PHY present on i.MX23/28 does not support charger detection so do not attempt to run it on these SoCs. Fixes: e93650994a95 ("usb: phy: mxs: add usb charger type detection")

[PATCH] doc: usb: chipidea: Fix typo in 'enumerate'

From: Fabio Estevam <fabio.este...@nxp.com> Fix the spelling of 'enumerate' in this document. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- Documentation/usb/chipidea.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/usb/ch

Re: MX25 USB timeout on ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB

Hi Michael, Adding Peter Chen. On Wed, Nov 8, 2017 at 8:41 AM, Michael Nazzareno Trimarchi wrote: > Hi Alan > > I'm working on IMX25 platform where I have a USB251xBi family > connected to the ehci full speed serial port. > IMX25 is capable to manage only full

Re: [PATCH] USB: EHCI: don't reread PORTSC after disabling port power

Hi Uwe, On Fri, Oct 20, 2017 at 5:20 PM, Uwe Kleine-König wrote: > It also works. However I wonder if it's right that I'm spammed by > over-current messages now (independent of which fix I choose) as long as > there is something connected to the port that draws

Re: g_hid loading unloading crash

On Mon, Sep 11, 2017 at 11:16 AM, prabhu kalyan wrote: > Dear Fabio, > > My main objective is to switch between HID, VCP, Mass storage mode. > But as the g_hid.ko crashes i am not able to switch mode. > > I am using nxp kernel Linux cpu49-ub 4.4.0-31-generic >

Re: g_hid loading unloading crash

On Mon, Sep 11, 2017 at 10:32 AM, PRABHU wrote: > Dear all, > I was trying to do a stress test on module insertion and removal. 1st time > modprobe g_hid and rmmod g_hid works. second time when doing insmod g_hid > crashes the core. > > crash trace >

[PATCH] usb: phy: qcom: Use devm_ioremap_resource()

From: Fabio Estevam <fabio.este...@nxp.com> Using devm_ioremap_resource() can make the code simpler, as it already does the resource NULL check. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/usb/phy/phy-qcom-8x16-usb.c | 9 +++-- 1 file changed, 3 inse

[PATCH 2/2] usb: phy-generic: Remove unneeded gpiod NULL check

From: Fabio Estevam <fabio.este...@nxp.com> The gpiod API checks for NULL descriptors, so there is no need to duplicate the check in the driver. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/usb/phy/phy-generic.c | 3 +-- 1 file changed, 1 insertion(+), 2 deleti

[PATCH 1/2] usb: pxa27x_udc: Remove unneeded gpiod NULL check

From: Fabio Estevam <fabio.este...@nxp.com> The gpiod API checks for NULL descriptors, so there is no need to duplicate the check in the driver. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/usb/gadget/udc/pxa27x_udc.c | 3 +-- 1 file changed, 1 insertion(+),

Re: Patch for drivers/usb/serial/ch341.c enabling parity

On Sun, Apr 2, 2017 at 3:00 PM, Leif Neland wrote: > There is a patch > > https://github.com/karlp/ch341-linux/blob/master/0001-usb-serial-ch341-Add-parity-support.patch > > which enables parity selection for the ch341 USB-RS485 adapter. > > From: Karl Palsson

Re: Choppy USB audio on i.MX53 chipidea with 4.4 kernel. Ok in 4.10

Hi Martin, On Tue, Feb 21, 2017 at 1:06 PM, Martin Fuzzey wrote: > Hi, > > I ran into a problem of "choppy" audio when using a USB codec on a i.MX53 > (with the chipidea driver) > The problem occurs on 4.4.47 but not on an old 3.19 > It also does not occur on the latest

Re: [PATCH] ARM: imx25: set default phy_type and dr_mode for usbotg port

ee machines because up to now they had > to specify these two properties in the machine.dts which still takes > precedence by just overwriting the defaults added here. > > Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.este.

Re: [PATCH 1/3] usb: chipidea: udc: Use dma_pool_zalloc()

Hi Sergei, On Fri, Sep 9, 2016 at 9:47 AM, Sergei Shtylyov wrote: >> We can make the code simpler by using dma_pool_zalloc() instead >> of calling dma_pool_zalloc() and then a memset(). > > >dma_pool_alloc(). Thanks, fixed in v2. -- To unsubscribe from

[PATCH v2 2/3] usb: chipidea: udc: Fit into a single line

From: Fabio Estevam <fabio.este...@nxp.com> No need to split the dma_pool_zalloc() line in two lines as it can perfectly fit into a single one. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- Changes since v1: - Add a missing 'line' in the commit log. drivers/usb/chipid

[PATCH v2 1/3] usb: chipidea: udc: Use dma_pool_zalloc()

From: Fabio Estevam <fabio.este...@nxp.com> We can make the code simpler by using dma_pool_zalloc() instead of calling dma_pool_alloc() followed by memset(). Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- Changes since v1: - Fix a typo in commit log (Sergei) drivers/

[PATCH v2 3/3] usb: chipidea: udc: Use the preferred form for passing a size of a struct

From: Fabio Estevam <fabio.este...@nxp.com> According to Documentation/CodingStyle: "The preferred form for passing a size of a struct is the following: p = kmalloc(sizeof(*p), ...); " , so do as suggested to improve readability. Signed-off-by: Fabio Estevam <fa

[PATCH 3/3] usb: chipidea: udc: Use the preferred form for passing a size of a struct

From: Fabio Estevam <fabio.este...@nxp.com> According to Documentation/CodingStyle: "The preferred form for passing a size of a struct is the following: p = kmalloc(sizeof(*p), ...); " , so do as suggested to improve readability. Signed-off-by: Fabio Estevam <fa

[PATCH 2/3] usb: chipidea: udc: Fit into a single line

From: Fabio Estevam <fabio.este...@nxp.com> No need to split the dma_pool_zalloc() line into two as it can perfectly fit into a single line. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/usb/chipidea/udc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH 1/3] usb: chipidea: udc: Use dma_pool_zalloc()

From: Fabio Estevam <fabio.este...@nxp.com> We can make the code simpler by using dma_pool_zalloc() instead of calling dma_pool_zalloc() and then a memset(). Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/usb/chipidea/udc.c | 6 ++ 1 file changed, 2 inse

Re: [PATCH] HID: usbkbd: return proper error code

On Wed, Aug 31, 2016 at 1:28 PM, Sudip Mukherjee wrote: > Use proper error code instead of using -1 on failure to allocate > memory. We may use the error code later in the caller. > > Signed-off-by: Sudip Mukherjee > --- >

[PATCH] usb: phy: phy-generic: Check clk_prepare_enable() error

From: Fabio Estevam <fabio.este...@nxp.com> clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of failure. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/usb/phy/phy-generic.c | 8 ++-- 1 file changed, 6 inse

Re: [PATCH v3 0/6] power: add power sequence library

On Mon, Aug 1, 2016 at 11:55 AM, Joshua Clayton wrote: > Thanks a million, Fabio! > > 'usbcore.autosuspend=-1' quiets the errors. > > ~joshua > > P.S. I guess this technically is a bug in chipidea usb. > I'll give it a quick once over, though I am not very familiar >

Re: [PATCH v3 0/6] power: add power sequence library

it help in your case if you pass 'usbcore.autosuspend=-1' in the kernel command line? Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

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 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

On Wed, Feb 24, 2016 at 8:48 AM, Fabio Estevam <feste...@gmail.com> 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_runtim

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 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

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 .runtime_suspend at

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 <feste...@gmail.com> wrote: > Hi Peter, > > On Sun, Feb 21, 2016 at 10:59 PM, Peter Chen <hzpeterc...@gmail.com> wrote: > >> Fabio, Felipe is correct. The mx23 and mx28 should NOT call mxs phy's >> susp

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 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

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 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 ?

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

From: Fabio Estevam <fabio.este...@nxp.com> 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) us

Wakeup from USB on mx6

ces/usb1/power/wakeup $ echo enabled > /sys/bus/usb/devices/1-1/power/wakeup - Put the system in suspend $ echo mem > /sys/power/state - Clicking in the mouse button does not wakeup the system. Any ideas? Thanks, Fabio Estevam -- To unsubscribe from this list: send the line "unsubsc

Re: Wakeup from USB on mx6

On Wed, Feb 3, 2016 at 1:21 PM, Fabio Estevam <feste...@gmail.com> wrote: > Hi Peter, > > I am running imx6sl-evk with linux-next 20160203 and I am trying to > make it wake up via a USB mouse click. > > These are the steps I am doing: > > - Insert the USB mouse in

Re: Wakeup from USB on mx6

On Wed, Feb 3, 2016 at 1:21 PM, Fabio Estevam <feste...@gmail.com> wrote: > Hi Peter, > > I am running imx6sl-evk with linux-next 20160203 and I am trying to > make it wake up via a USB mouse click. > > These are the steps I am doing: > > - Insert the USB mouse in

Re: Wakeup from USB on mx6

ces/soc0/soc/210.aips-bus/2184200.usb/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/power/wakeup Regards, F

Re: Wakeup from USB on mx6

On Wed, Feb 3, 2016 at 2:58 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Wed, 3 Feb 2016, Fabio Estevam wrote: > >> Hi Alan, >> >> On Wed, Feb 3, 2016 at 2:29 PM, Alan Stern <st...@rowland.harvard.edu> wrote: >> >> > It seems likely th

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

From: Fabio Estevam <fabio.este...@nxp.com> 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) us

Re: MX28 with hub cannot reset

SB2512. > I think we don't know that the issue comes really from the mx28 instead of the > hub. It seems there are other users that reported this same issue at community.freescale.com. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb&quo

Re: [PATCH] usb: phy: mxs: Remove unused flags

On Tue, Dec 29, 2015 at 6:15 AM, Peter Chen wrote: > I prefer to keep it, and it let us know the existing issues although > we have not implemented workaround for them. In future, we may have > solutions for how to implement them. Ok, what about adding the recommendation

[PATCH] usb: phy: mxs: Remove unused flags

From: Fabio Estevam <fabio.este...@nxp.com> MXS_PHY_ABNORMAL_IN_SUSPEND and MXS_PHY_SENDING_SOF_TOO_FAST flags are never used, so let's get rid of them. Reported-by: Stefan Wahren <stefan.wah...@i2se.com> Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/usb

Re: MX28 with hub cannot reset

t is not as mx28evk does not have a hub. > Is i.MX23 affected, too? As far as I know mx23 olinuxino maxi has a USB hub and the issue is not present there. Maybe Peter can confirm. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb&quo

Re: MX28 with hub cannot reset

Hi Peter, On Wed, Dec 23, 2015 at 7:49 AM, Peter Chen wrote: > Fabio, there is a bug for imx28 usb low power mode, and we have no > good way to implement > workaround using current USB PHY framework, would you please test by > add "usbcore.autosuspend = -1" > at bootargs

MX28 with hub cannot reset

t;usb: phy: mxs: Add VF610 USB PHY support") shows the same error messages in the commit log, but trying the same approach of adding the MXS_PHY_NEED_IP_FIX flag does not help on mx28. Any suggestions? Thanks, Fabio Estevam -- To unsubscribe from this list: send the line "unsubs

[PATCH] chipidea: imx: Enable PM runtime for mx28

usb1-port1: cannot reset (err = -32) usb usb1-port1: cannot reset (err = -32) usb usb1-port1: Cannot enable. Maybe the USB cable is bad? Passing CI_HDRC_SUPPORTS_RUNTIME_PM flag fixes the problem. Tested on a mx28evk and also on a mx28 custom board. Signed-off-by: Fabio Estevam <fabio.e

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

Hi Maciej, On Tue, Dec 15, 2015 at 6:19 PM, Maciej S. Szmigiero wrote: > Can we now use this change for repairing the USB support on UDOO board? > > This seems to work fine if not 100% correct: > --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi > +++

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

Hi Peter, On Wed, Dec 16, 2015 at 2:11 AM, Peter Chen wrote: > Thanks, Fabio, but I am curious how things like that? The USBOH3 clock > is not opened, the usb driver will hang when it tries to access > registers. If this clock is always on, then, why the system will >

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

On Tue, Dec 15, 2015 at 4:28 AM, Peter Chen wrote: > Thanks, Fabio. > > I am afraid I forget to set gpio as output, would you please apply > below patch against my original ones: Same error happens with these changes applied. Here are more details: if I run a pure

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

Hi Peter, On Mon, Dec 14, 2015 at 5:26 AM, Peter Chen wrote: > Hi all, > > There is a known issue that the USB code can't handle USB HUB's > external pins well, in that case, it may cause some onboard > USB HUBs can't work since their PHY's clock or reset pin needs to

Re: [PATCH 2/3] doc: dt-binding: generic onboard USB HUB

On Mon, Dec 7, 2015 at 11:37 PM, Peter Chen wrote: > Add dt-binding documentation for generic onboard USB HUB. > > Signed-off-by: Peter Chen > --- > .../bindings/usb/generic-onboard-hub.txt | 28 > ++ > 1 file

Re: Udoo support for chipidea

Hi Peter, On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen wrote: > Add linux-usb. > > Patryk, your problem is you may need to open 24M OSC for HUB 2514 > manually, and you have used IMX6QDL_CLK_CKO for it in the design, > but this clock is not controller's clock,

Re: iperf UDP packet loss with Chipidea HDRC

On Mon, Oct 5, 2015 at 10:57 AM, Jayan John wrote: > We are developing a custom USB device on a iMX6q platform with a Chipidea > HDRC. The device uses a single NCM interface for communication with another > OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP

Re: [PATCH 0/7][v4] Add OTG support for FSL socs

On Thu, Aug 27, 2015 at 1:43 PM, Ramneek Mehresh wrote: > Add support for otg for all freescale socs having internal > usb phy. > > Ramneek Mehresh (7): > usb:fsl:otg: Make fsl otg driver as tristate > usb:fsl:otg: Add controller version based ULPI and UTMI phy

Re: [PATCH 2/2] Doc: usb: ci-hdrc-usb2: Add phy-clkgate-delay-us entry

Hi Peter, On Tue, Sep 8, 2015 at 11:27 PM, Peter Chen wrote: > I will queue both for next rc, thanks. It would be nice if these patches could appear in linux-next soon. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to

Re: [PATCH v3 0/5] usb: change clock information for chipidea

On Sun, Sep 20, 2015 at 9:43 PM, Peter Chen wrote: > This patch set changes usb clock information for legacy i.mx platforms. > At these platforms, they needs three clocks to let controller work. > > Hi Fabio, > > Would you please have a test at imx27 and imx25 boards,

Re: Applying Patch to Change Max Packet Size for Device

On Wed, Sep 16, 2015 at 8:27 PM, Todd Efflam wrote: > We were using EHCI with the 2.6.35 kernel. When disabling XHCI in > 3.14 and using EHCI the device still doesn't work however. > > The reason we are stuck with 3.14 is we use the Yocto build system and > their latest

Re: [PATCH] USB: EHCI: fix dereference of ERR_PTR

On Wed, Sep 16, 2015 at 11:08 AM, Sudip Mukherjee wrote: > On error find_tt() returns either a NULL pointer or the error value in > ERR_PTR. But we were dereferencing it directly without even checking if > find_tt() returned a valid pointer or not. > > Signed-off-by:

Re: MIDI gadget allocating too much from coherent pool

c()/dma_pool_free(). Are there any messages in the > system log? You might want to modify the kernel to check how often > it calls these functions. The udc driver used by mx6 is drivers/usb/chipidea/udc.c. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

apper (pid: 1, stack limit = 0xc783e190) > Stack: (0xc783fe08 to 0xc784) > > Signed-off-by: Peter Chen <peter.c...@freescale.com> > Reported-by: Fabio Estevam <fabio.este...@freescale.com> > Cc: <sta...@vger.kernel.org> > --- > arch/arm/boot/dts/imx27.dtsi | 1

Re: [PATCH 4/4] usb: chipidea: imx: refine clock operations to adapt for all platforms

On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen <peter.c...@freescale.com> wrote: > Some i.mx platforms need three clocks to let controller work, but > others only need one, refine clock operation to adapt for all > platforms. > > Cc: Fabio Estevam <fabio.este...@freescale.com

Re: [PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

On Tue, Sep 15, 2015 at 11:31 PM, Peter Chen wrote: >> mx25.dtsi and mx35.dtsi also need to be changed. > > If you can help to test, I will update. Sure, I can test it on mx25pdk tomorrow. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the

Re: [PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

gt; Process swapper (pid: 1, stack limit = 0xc783e190) > Stack: (0xc783fe08 to 0xc784) > > Signed-off-by: Peter Chen <peter.c...@freescale.com> > Reported-by: Fabio Estevam <fabio.este...@freescale.com> > Cc: <sta...@vger.kernel.org> Tested-by: Fabio

Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

On Tue, Sep 15, 2015 at 11:24 PM, Peter Chen wrote: > but drivers/usb/gadget/udc/fsl_mxc_udc.c has three clocks Ok, looking at the clock driver I see that they used to associate three clocks with mxc-ehci: clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0");

Re: [PATCH 4/4] usb: chipidea: imx: refine clock operations to adapt for all platforms

ression on mx27. > > Cc: Fabio Estevam <fabio.este...@freescale.com> > Signed-off-by: Peter Chen <peter.c...@freescale.com> Tested-by: Fabio Estevam <fabio.este...@freescale.com> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the

Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > Some SoCs needs three clock to let controller work, but others only > need one, add one property to differentiate this. > > Signed-off-by: Peter Chen > --- >

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

Hi Peter, On Mon, Sep 14, 2015 at 11:32 PM, Fabio Estevam <feste...@gmail.com> wrote: > This did not help. > > It is getting late here, so I will be able to try more things tomorrow. I was able to fix it. Your initial patch had a missing 'return 0' in imx_prepare_enable_

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

On Mon, Sep 14, 2015 at 1:54 AM, Peter Chen <peter.c...@freescale.com> wrote: > On Fri, Sep 11, 2015 at 10:17:20AM -0300, Fabio Estevam wrote: > Sorry, a bug at former patch, it the clk_ahb has been override. > Mind to try below one? Applied the patch and still see the issue:

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

ow. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: MIDI gadget allocating too much from coherent pool

On Thu, Sep 10, 2015 at 6:47 AM, Felipe Tonello wrote: > Hi, > > I have the following setup: > > DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB > MIDI GADGET -> HOST > > When the throughput from the DSP is high, thus causing the throughput > on the USB

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

On Mon, Sep 14, 2015 at 9:19 PM, Peter Chen wrote: > That's so strange, do we need to enable clk_ahb before than clk_ipg? > Would you please try below diff based on my patch? Same kernel crash with this one applied on top of the previous one. > > Meanwhile, you may

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

On Mon, Sep 14, 2015 at 9:50 PM, Peter Chen wrote: > > Would you try below? > > diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile > index 4decb12..34e9f6e 100644 > --- a/drivers/usb/chipidea/Makefile > +++ b/drivers/usb/chipidea/Makefile > @@

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

code=0x000b ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b If I revert 73dea4a912b2("usb: chipidea: usbmisc_imx: delete clock information") then the board boots fine. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsu

  1   2   3   4   >