2013/2/19 Soar Hung soarh...@realtek.com:
Hi all,
I checkout the usb-next branch (on 2/18) and following the
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel.
After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP
Mon Feb 18 18:04:02 CST 2013 i686
Hi,
On Tue, Feb 19, 2013 at 06:50:03PM -0800, Paul Zimmerman wrote:
Here is v4 of the DWC2 patch set. I made most of the changes you asked
for, except for the following:
- I did not convert to a threaded IRQ handler. I would like to postpone
that for now.
without any reasoning ?
- I did
Hi all,
We are facing an issue in one of our platforms which seems to be
indirectly related to how close USB transactions are attempted (in
case of failed transactions). In the EHCI layer, we have these two
defines that deal with retries for failed USB transactions:
#define EHCI_TUNE_CERR
Hi,
On Tue, Feb 19, 2013 at 06:50:07PM -0800, Paul Zimmerman wrote:
This file contains the PCI bus interface glue for the DWC2
driver
Signed-off-by: Paul Zimmerman pa...@synopsys.com
before anything, out of curiosity, do you have DWC2 PCI configured with
OTG support ? I remember that on
HI,
On Tue, Feb 19, 2013 at 06:50:06PM -0800, Paul Zimmerman wrote:
+#include linux/kernel.h
+#include linux/module.h
apparently not used.
+#include linux/moduleparam.h
not used.
+#include linux/spinlock.h
not used
+#include linux/interrupt.h
not used either
+#include
On 02/19/2013 04:48 PM, Sarah Sharp wrote:
Hi Tony,
Greg closed the usb-next tree for 3.9 two weeks ago. The bug fix
patches will have to go in after the 3.9 merge window closes
(approximately two weeks from now).
Understood.
Sorry for the lack of response, I was on vacation. I'll review
It seems that my initial reply did not made it to the mailing list.
I'm reposting it below with links to scribd for the logs.
Would like to note, that the flooding of debug messages continue's
(indefinitly??) after the first USB connection attempt. So, the log
messages of the file containing the
On Tue, 19 Feb 2013, Dâniel Fraga wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=54111
Posting this regression here as suggested by Greg Kroah-Hartman.
After upgrading from kernel 3.7.0 to 3.8.0, the
USB devices (keyboard, mouse etc) will not work at all. My motherboard
On 02/20/2013 10:15 AM, Alan Stern wrote:
On Tue, 19 Feb 2013, Sarah Sharp wrote:
The one thing I wanted to check was my understanding of the hibernate
flow path. As you mentioned, I thought that xhci_suspend would be
called in the hibernate path, but it's not.
Are you sure about that?
On Wed, 20 Feb 2013, Tony Camuso wrote:
On 02/20/2013 10:15 AM, Alan Stern wrote:
On Tue, 19 Feb 2013, Sarah Sharp wrote:
The one thing I wanted to check was my understanding of the hibernate
flow path. As you mentioned, I thought that xhci_suspend would be
called in the hibernate
On Fri, 15 Feb 2013, Arnd Bergmann wrote:
From: Manjunath Goudar manjunath.gou...@linaro.org
With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus
Make sure we do not make tty-driver callbacks or wait for port to drain
on uninitialised ports (e.g. when open failed) in
tty_port_close_start().
No callback, such as flush_buffer or wait_until_sent, needs to be made
on a port that has never been opened. Neither does it make much sense to
add
Move port drain-delay handling to a separate function.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/tty/tty_port.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 506f579..fcb4ccb
These patches against tty-next fix a few issues with tty-port hangup and
close.
The first and third patch are essentially clean ups.
The second patch makes sure DTR is dropped also on hangup and that DTR
is only dropped for initialised ports (where is could have been raised
in the first place).
Move HUPCL handling to port shutdown so that DTR is dropped also on hang
up (tty_port_close is a noop for hung-up ports).
Also do not try to drop DTR for uninitialised ports where it has never
been raised (e.g. after a failed open).
Nine drivers currently call tty_port_close_start directly
On Fri, 15 Feb 2013, Manjunath Goudar wrote:
Separate the SPEAr host controller driver from ehci-hcd host code
into its own driver module.
In V2:
Replaced spear as SPEAr everywhere, leaving functions/variables/config
options.
--- a/drivers/usb/host/Kconfig
+++
On Fri, 15 Feb 2013, Manjunath Goudar wrote:
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -20,6 +20,17 @@
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
+#include linux/kernel.h
+#include linux/module.h
+#include
On Wednesday 20 February 2013, Alan Stern wrote:
Currently there is no Kconfig option to control specifically whether
the ehci-orion driver gets built; it always gets built whenever
CONFIG_PLAT_ORION and CONFIG_USB_EHCI_HCD are both enabled.
Do you think it is a good idea to add an option
On Fri, 15 Feb 2013, Manjunath Goudar wrote:
Separate the Qualcomm On-Chip host controller driver from ehci-hcd host code
into its own driver module.
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
+static const char hcd_name[] = msm_hsusb_host;
This should be
Alan,
On Wed, Feb 20, 2013 at 04:27:04PM +, Arnd Bergmann wrote:
On Wednesday 20 February 2013, Alan Stern wrote:
Currently there is no Kconfig option to control specifically whether
the ehci-orion driver gets built; it always gets built whenever
CONFIG_PLAT_ORION and
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
didn't feel the need to assign an INTx here.
According to PCI-3.0, section 6.8 (Message Signalled Interrupts):
It is recommended that devices
On Wed, Feb 20, 2013 at 10:54:40AM -0500, Alan Stern wrote:
On Wed, 20 Feb 2013, Tony Camuso wrote:
On 02/20/2013 10:15 AM, Alan Stern wrote:
On Tue, 19 Feb 2013, Sarah Sharp wrote:
The one thing I wanted to check was my understanding of the hibernate
flow path. As you mentioned,
On Tue, 19 Feb 2013, Stefan Tauner wrote:
On Tue, 19 Feb 2013 13:27:49 -0500 (EST)
Alan Stern st...@rowland.harvard.edu wrote:
Adding a completely new API that returns a timestamp associated with
the start/end/fixed offset of a frame number sounds like a perfect
solution for my
On Wed, 20 Feb 2013, Don Zickus wrote:
On Wed, Feb 20, 2013 at 10:54:40AM -0500, Alan Stern wrote:
On Wed, 20 Feb 2013, Tony Camuso wrote:
On 02/20/2013 10:15 AM, Alan Stern wrote:
On Tue, 19 Feb 2013, Sarah Sharp wrote:
The one thing I wanted to check was my understanding of
On Tue, Feb 19, 2013 at 11:51:46AM -0500, Alan Stern wrote:
On Tue, 19 Feb 2013, Felipe Balbi wrote:
we will still see the warning since usbcore will continue to call
-drop_endpoint() for disabled eps.
But if xhci-hcd is fixed properly, it won't print out those warnings
when
From: Fabio Estevam fabio.este...@freescale.com
Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack)
there is no need to include asm/mach-types.h, so remove it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/usb/host/ehci-mxc.c |4
1
From: Fabio Estevam fabio.este...@freescale.com
Rather than reporting that the controller is about to be initialized, it is more
useful to indicate a succesful probe instead.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/usb/host/ehci-mxc.c |3 +--
1 file changed, 1
On Fri, Feb 01, 2013 at 02:09:24PM +0800, 洪崇耕 wrote:
Hi,
According to xHCI spec Rev1 page 125, Endpoint context state diagram.
When reset device, the endpoint state transit to disabled state.
Right. And the endpoint resources are supposed to be dropped by the
Reset Device command.
On 02/20/2013 12:35 PM, Alan Stern wrote:
I bet it really was called, but you didn't realize it because of the
way you monitored the output from the printks. You looked at the
log buffer or the kernel log file after resuming, right? You didn't
have a serial console attached to another
On Tue, Feb 19, 2013 at 08:24:38AM +0100, Andrew Lunn wrote:
GregKH: Please can you drop this patch from usb-next. It breaks more
than it fixes.
I've now reverted both of these, and the follow-on patch that Arnd sent
in.
Arnd, sorry, but please be more careful, especially when you ask for
On Wednesday 20 February 2013, Greg KH wrote:
On Tue, Feb 19, 2013 at 08:24:38AM +0100, Andrew Lunn wrote:
GregKH: Please can you drop this patch from usb-next. It breaks more
than it fixes.
I've now reverted both of these, and the follow-on patch that Arnd sent
in.
Arnd, sorry, but
On Wed, 20 Feb 2013, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS
hack)
there is no need to include asm/mach-types.h, so remove it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
On Wed, 20 Feb 2013, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Rather than reporting that the controller is about to be initialized, it is
more
useful to indicate a succesful probe instead.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
On Wed, 20 Feb 2013, Tony Camuso wrote:
On 02/20/2013 12:35 PM, Alan Stern wrote:
I bet it really was called, but you didn't realize it because of the
way you monitored the output from the printks. You looked at the
log buffer or the kernel log file after resuming, right? You didn't
From: Fabio Estevam fabio.este...@freescale.com
Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack)
there is no need to include asm/mach-types.h, so remove it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
From: Fabio Estevam fabio.este...@freescale.com
It is not very useful to indicate the the driver is about to be probed.
Quoting Alan Stern [1]:
Plenty of drivers don't include any message like this at all. You
might as well get rid of it entirely.
Remove such dev_info().
[1]
On Wed, Feb 20, 2013 at 10:14:46AM -0800, Sarah Sharp wrote:
Are you sure the TI host and your host isn't neglecting to drop endpoint
resources when the Reset Device command is handled?
I double checked your test file on the latest Intel xHCI host, and it's
up to over 4,000 successful resets of
On Wed, 20 Feb 2013, Sarah Sharp wrote:
The second paragraph sounds right, but the message isn't actually about
ep-enabled. I think it's about how the USB core manages the
usb_device's ep_in and ep_out arrays.
When usb_reset_and_verify_device() is called, it goes through port
On Wed, 20 Feb 2013, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
It is not very useful to indicate the the driver is about to be probed.
Quoting Alan Stern [1]:
Plenty of drivers don't include any message like this at all. You
might as well get rid of it
Oliver Neukum oli...@neukum.org wrote:
Hi,
I am no longer sure about my test procedure for cdc-wdm.
Do you have a test script?
No, I don't. I probably should have a better system, but I usually just try
some operations I consider normal usage.
I am also including what I currently have for
On Wed, Feb 20, 2013 at 03:21:19PM -0500, Alan Stern wrote:
On Wed, 20 Feb 2013, Sarah Sharp wrote:
Basically, I think this is a host-specific bug. We can certainly work
around it in the xHCI driver with a quirk for all hosts that have this
resource tracking problem. We would issue a
Thanks Alan. Replies inline.
On Wed, Feb 20, 2013 at 7:30 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 20 Feb 2013, Haribabu Narayanan wrote:
Hi all,
We are facing an issue in one of our platforms which seems to be
indirectly related to how close USB transactions are
Quite some time ago, I posted about a problematic PS2-USB converter
that I used to connect an old PS2-connector keyboard to my laptop
dock, where the keyboard wouldn't be recognized at boot unless
I unplugged and reconnected it.
Well, I've recently figured out (partly by obtaining a converter
On Wed, 20 Feb 2013 10:20:07 -0500 (EST)
Alan Stern st...@rowland.harvard.edu wrote:
The important module does not contain usb in its name. :-(
Probably this is not a bug at all, but simply a failure to load the
ehci-pci module. If the USB modules are loaded from your initramsfs
image,
From: Maxin B. John maxin.j...@enea.com
Fixes this build failure:
gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
gcc -Wall -Wextra -g -lpthread -I../include -o ffs-test ffs-test.c
In file included from ffs-test.c:41:0:
../../include/linux/usb/functionfs.h:4:39: fatal error:
On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
From: Maxin B. John maxin.j...@enea.com
Fixes this build failure:
gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
gcc -Wall -Wextra -g -lpthread -I../include -o ffs-test ffs-test.c
In file included from
On Wed, 20 Feb 2013 16:07:49 -0800, Greg Kroah-Hartman said:
PS-2 connectors can not normally handle hotplugging, the protocol
doesn't allow it, and for some unlucky devices, it could actually fry
the motherboard or the PS-2 device.
So that's probably the issue here, the device just doesn't
Hi,
On Thu, Feb 21, 2013 at 2:06 AM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
From: Maxin B. John maxin.j...@enea.com
Fixes this build failure:
gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
gcc -Wall
On Wed, 2013-02-20 at 17:02 +0100, Johan Hovold wrote:
These patches against tty-next fix a few issues with tty-port hangup and
close.
The first and third patch are essentially clean ups.
The second patch makes sure DTR is dropped also on hangup and that DTR
is only dropped for
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Wednesday, February 20, 2013 12:29 AM
On Tue, Feb 19, 2013 at 06:50:03PM -0800, Paul Zimmerman wrote:
Here is v4 of the DWC2 patch set. I made most of the changes you asked
for, except for the following:
- I did not convert to a threaded IRQ
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Wednesday, February 20, 2013 1:20 AM
On Tue, Feb 19, 2013 at 06:50:06PM -0800, Paul Zimmerman wrote:
+#include linux/usb/hcd.h
+#include linux/usb/ch11.h
this doesn't exist anymore (moved to
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Wednesday, February 20, 2013 12:50 AM
On Tue, Feb 19, 2013 at 06:50:07PM -0800, Paul Zimmerman wrote:
This file contains the PCI bus interface glue for the DWC2
driver
Signed-off-by: Paul Zimmerman pa...@synopsys.com
before anything,
Originaly, ehci driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of
The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Direclty writing the phy
Originaly, otg driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of
The patches are divied into 2 parts
1. PHY driver
To remove the callbacks in the platform data, a usb PHY driver
for marvell udc/otg/ehci is written.
For device tree support, it is not good to pass the callback
pointers by platform data. The PHY driver also removes the
block.
usb: phy:
because phy is seperated from the usb controller driver,
we can use the common pxa_device_desc for device register.
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/include/mach/pxa910.h |7 ---
arch/arm/mach-mmp/pxa910.c |4
2 files changed, 8
add the udc/otg/ehci devices for mmp2
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/include/mach/mmp2.h |4
arch/arm/mach-mmp/mmp2.c |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h
for ttc_dkb board, add udc/otg/ehci support
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/ttc_dkb.c | 50 +-
1 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
phy setting are formatted into a phy driver at drivers/usb/phy,
we do not need do the setting in SOC files.
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/devices.c | 278 -
arch/arm/mach-mmp/include/mach/regs-usb.h | 253
For the vbus and idpin detection. It may be completed by some
external chip, for example the pmic chip 88pm860x in driver/mfd
can do it.
Although the usb controller can detect the vbus and id pin, but
it need clock on and PHY enabled to detect the
vbus/idpin. It will increase the power.
Using the
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/pxa168.c | 42 --
1 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index b7f074f..dd3a68b 100644
---
for brownstone board, add the udc/otg/ehci support
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/brownstone.c | 68
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c
Because arch-mmp will make use of irq domain for irq
allocation, the irqs allocated for PMIC is dynamical.
The vbus/idpin irqs from PMIC can not be passed by platform data.
Using the extern chip APIs provides by PHY driver can solve this
problem.
Marvell usb PHY driver provides a middle layer.
The
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/otg/mv_otg.c | 72 +++--
drivers/usb/otg/mv_otg.h |3 ++
2 files changed, 40 insertions(+), 35 deletions(-)
diff --git
Change the board support for usb as extern chip is supported
in marvell usb PHY driver
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/brownstone.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie chao@marvell.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-mv.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c
Change the board support for usb as extern chip is supported
in marvell usb PHY driver.
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/ttc_dkb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
On Thu, Feb 21 2013, maxin.j...@gmail.com wrote:
From: Maxin B. John maxin.j...@enea.com
Fixes this build failure:
gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
gcc -Wall -Wextra -g -lpthread -I../include -o ffs-test ffs-test.c
In file included from ffs-test.c:41:0:
On Thu, Feb 21 2013, Maxin B. John wrote:
Hi,
On Thu, Feb 21, 2013 at 2:06 AM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
From: Maxin B. John maxin.j...@enea.com
Fixes this build failure:
gcc -Wall -Wextra -g -lpthread
On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:
Apparently this device is meant to use MSI _only_ so the BIOS developer
didn't feel the need to assign an INTx here.
According to PCI-3.0, section 6.8 (Message Signalled
71 matches
Mail list logo
