On Mon, Jun 10, 2019 at 4:53 AM Joakim Tjernlund
wrote:
>
> We are trying to get fsl_udc up and running on a T1042 with without success.
I am not familiar with T1042, but fsl_udc is from the time i.MX
devices didn't have devicetree support.
i.MX has been converted for devicetree for quite some t
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/usbmisc_imx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index d8b67e150b12
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/ci_hdrc_msm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index b8b3caad889c
dev_err() is more appropriate for printing error messages inside
drivers, so switch to dev_err().
While at it also add the missing newlines.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Keep the orginal string
drivers/usb/chipidea/core.c | 5 +++--
1 file changed, 3 insertions(+), 2
Hi Greg,
On Wed, Jun 5, 2019 at 11:21 AM Greg KH wrote:
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 27749ace2d93..92132b35b7fd 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -523,8 +523,9 @@ int hw_device_reset(s
dev_err() is more appropriate for printing error messages inside
drivers, so switch to dev_err().
While at it also add the missing newlines and remove 'device'
string as the ci_role(ci)->name string will tell if it is host
or gadget.
Signed-off-by: Fabio Estevam
---
Changes si
dev_err() is more appropriate for printing error messages inside
drivers, so switch to dev_err().
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index
Hi Peter,
On Thu, May 30, 2019 at 5:50 AM Peter Chen wrote:
>
> An endpoint conflict occurs when the USB is working in device mode
> during an isochronous communication. When the endpointA IN direction
> is an isochronous IN endpoint, and the host sends an IN token to
> endpointA on another devic
[-Wformat=]
Use %zu for printing size_t type in order to fix the warnings.
Fixes: 597c56e372da ("xhci: update bounce buffer with correct sg num")
Reported-by: kbuild test robot
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fixed a typo when referencing the commit hci-->
[-Wformat=]
Use %zu for printing size_t type in order to fix the warnings.
Fixes: 597c56e372da ("hci: update bounce buffer with correct sg num")
Reported-by: kbuild test robot
Signed-off-by: Fabio Estevam
---
drivers/usb/host/xhci-ring.c | 4 ++--
1 file changed, 2 insertions(+),
Hi Peter,
On Tue, May 14, 2019 at 4:39 AM Peter Chen wrote:
>
> Add imx7ulp support
Since you are adding a new flag CI_HDRC_PMQOS, it would be nice to
expand the commit log a bit to explain about it.
On Mon, Dec 10, 2018 at 6:09 AM Schrempf Frieder
wrote:
> With a separate example for HSIC, we should probably leave the standard
> example unchanged (I think that was one of the reasons for adding a
> separate example).
Yes, I agree. That would make the binding doc clearer.
Thanks
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
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 f
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
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.
>
> Signed
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 loo
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
>
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.
>
> Signed
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, mean
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
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 is
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 we
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 messa
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 b
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 CONFIG_USB_CHIPIDEA
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_US
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 option u
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_US
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 (which also calls usbmisc
Hi Felipe,
On Mon, Jan 22, 2018 at 10:28 AM, Fabio Estevam wrote:
> Hi Felipe,
>
> On Thu, Jan 18, 2018 at 12:22 AM, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> Commit e93650994a95 ("usb: phy: mxs: add usb charger type detection")
>>
From: Fabio Estevam
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
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
---
d
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 thread.
>
> According to this th
Hi Felipe,
On Thu, Jan 18, 2018 at 12:22 AM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> 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
From: Fabio Estevam
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 pointer dereference at virtual
addres
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")
From: Fabio Estevam
Fix the spelling of 'enumerate' in this document.
Signed-off-by: Fabio Estevam
---
Documentation/usb/chipidea.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt
ind
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 speed port using internal
> transce
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 too much power:
>
> [ 53
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
> #50~14.04.1-Ubuntu SMP Wed Jul 13 01:
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
>
>
> root@imx6ulevk:~# modprobe
From: Fabio Estevam
Using devm_ioremap_resource() can make the code simpler, as it
already does the resource NULL check.
Signed-off-by: Fabio Estevam
---
drivers/usb/phy/phy-qcom-8x16-usb.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-qcom
From: Fabio Estevam
The gpiod API checks for NULL descriptors, so there is no need to
duplicate the check in the driver.
Signed-off-by: Fabio Estevam
---
drivers/usb/phy/phy-generic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers
From: Fabio Estevam
The gpiod API checks for NULL descriptors, so there is no need to
duplicate the check in the driver.
Signed-off-by: Fabio Estevam
---
drivers/usb/gadget/udc/pxa27x_udc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc
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
> Date: Tue, 18 Mar 2014 23:33:27 +0
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 4.10.
>
> The codec is :
o 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
Reviewed-by: Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-usb"
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 this list: send the line "unsubscribe
From: Fabio Estevam
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
---
Changes since v1:
- Add a missing 'line' in the commit log.
drivers/usb/chipidea/udc.c | 3 +--
1 file changed, 1 insertion(+), 2
From: Fabio Estevam
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
---
Changes since v1:
- Fix a typo in commit log (Sergei)
drivers/usb/chipidea/udc.c | 6 ++
1 file changed, 2 insertions
From: Fabio Estevam
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
---
Changes since v1:
- None
d
From: Fabio Estevam
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
---
drivers/usb/chipidea/udc.c | 2
From: Fabio Estevam
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
---
drivers/usb/chipidea/udc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb
From: Fabio Estevam
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
---
drivers/usb/chipidea/udc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea
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
> ---
> drivers/hid/usbhid/usbkbd.c | 10 +-
> 1 file changed, 5 insertio
From: Fabio Estevam
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
---
drivers/usb/phy/phy-generic.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy
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
> with USB core or the CI drive
#x27;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
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 issue.
--
To unsubscribe from
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)
>> [2.993879] hub 1-1:
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
[2.412
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, try setting the flag
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
> something like th
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 ''usbcore.autosuspen
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 chipidea driver
> nor mxs_phy_
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 enabled for m
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 CI_HDRC_SUPPORTS_RUNTIME_PM is set wron
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 mxs_phy_suspend(struct usb_
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 kernel command line.
>
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 ?
Thanks for the sugges
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 usb1-port1: cannot reset
On Wed, Feb 3, 2016 at 2:58 PM, Alan Stern wrote:
> On Wed, 3 Feb 2016, Fabio Estevam wrote:
>
>> Hi Alan,
>>
>> On Wed, Feb 3, 2016 at 2:29 PM, Alan Stern wrote:
>>
>> > It seems likely that this script does exactly the same thing that you
>> > di
00.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,
Fabio Estevam
--
To unsubscribe fro
On Wed, Feb 3, 2016 at 1:21 PM, Fabio Estevam 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 the USB host port:
>
&
On Wed, Feb 3, 2016 at 1:21 PM, Fabio Estevam 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 the USB host port:
>
&
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 "unsubscribe
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 usb1-port1: cannot reset
n'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" in
the body of a
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 below?
--- a/drivers/us
From: Fabio Estevam
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
Signed-off-by: Fabio Estevam
---
drivers/usb/phy/phy-mxs-usb.c | 31 +++
1 file changed, 3 inser
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" in
the body of a message to majord...@vger
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 (no CI_HDRC_SUPPORTS_RUN
6aa33221 ("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 "un
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
---
drivers/usb
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
> hang later?
I found the is
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
> +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> @@ -122,7 +1
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 4.3.2 then I do see the USB
st
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
> operate.
>
> The user rep
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 changed, 28 insertions(+)
> create mode 100644
> Docu
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, controller's clock has
> already de
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
> usb:fsl:otg: Add support to
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 performance
> after role rev
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 majord...@vger.kernel.org
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, thanks.
Works fine on both b
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 support is for 3.14.
You
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 linux-usb" in
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: Sudip Mukherjee
> ---
> driv
On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen 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.
It would be better to mention that this is fixing a regression on mx27.
>
> Cc
ck limit = 0xc783e190)
> Stack: (0xc783fe08 to 0xc784)
>
> Signed-off-by: Peter Chen
> Reported-by: Fabio Estevam
> Cc:
Tested-by: 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
1 - 100 of 367 matches
Mail list logo