USB_CONFGFS_ should appear under a tristate option in order to allow
selecting more than one function without building the legacy gadgets.
Now there are two problems:
1) they can't be selected at all, because they depend on USB_CONFIGFS,
and the patch which adds USB_CONFIGFS has not been merge
Hello Felipe, Hello Greg,
I've seen that you pulled a bunch of my patches. That's nice.
However, Felipe was unable to apply one of them due to some whitespace issues,
so he dropped it.
While dropping the said patch does not break anything, it makes the usb
functions configurable through configfs
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
Documentation/ABI/testing/configfs-usb-gadget | 81
Documentation/ABI/testing/configfs-usb-gadget-acm |8 ++
Documentation/ABI/testing/configfs-usb-gadget-ecm | 16
Documentation/ABI/te
Add documentation for configfs-based usb gadget.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
Documentation/usb/gadget_configfs.txt | 384 +
1 files changed, 384 insertions(+), 0 deletions(-)
create mode 100644 Documentation/usb/gadget_
Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-twl4030-usb.c | 55 -
1 file changed, 12 insertions(+), 4
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.
PHY drivers should create the PHY by
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.
This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded w
Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.
However using the old usb phy library cannot
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break
Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on/get_sync and
power_off/put_sync to align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a s
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/usb-musb.c |6 +-
include/linux/usb/musb.h |3 +++
2 f
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-omap-usb2.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/usb/phy/phy-oma
Changed the inticall from subsys_initcall to module_init for
twl4030-usb.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-twl4030-usb.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl403
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings
On 06/13/2013 01:37 AM, Greg KH wrote:
> On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote:
>> On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote:
> But, I get a build error with your tree pulled in, a
Suspend scenario in case of ohci bus glue was not properly handled as
it was not suspending generic part of ohci controller. Calling
explicitly the ohci_suspend()routine will ensure proper handling
of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without executing further.
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return rig
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return rig
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right awa
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away wi
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return r
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return r
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right
Suspend scenario in case of ohci bus glue was not properly handled as
it was not suspending generic part of ohci controller. Calling
explicitly the ohci_suspend()routine will ensure proper handling
of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without executing further.
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return r
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return r
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return rig
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right awa
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away wi
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return rig
On 13 June 2013 14:41, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-spear glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
Add space after full stop.
> routine in spear_ohci_hcd_drv_suspend() will ensur
Hi Felipe,
On Thu, Jun 13, 2013 at 02:01:04AM +0800, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jun 07, 2013 at 03:50:17PM +0800, Huang Rui wrote:
> > Hi Felipe,
> >
> > I was reading dwc3 codes and found that during the process of
> > configuring event buffer (dwc3_event_buffers_setup), it only writ
Hi,
On 28/05/13 08:18, Kishon Vijay Abraham I wrote:
> Hi Tony,
>
> On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote:
>> In order for controllers to get PHY in case of non dt boot, the phy
>> binding information (phy label) should be added in the platform
>> data of the controller.
>
Hi,
On Thu, Jun 13, 2013 at 12:05:36PM +0300, Roger Quadros wrote:
> On 06/13/2013 01:37 AM, Greg KH wrote:
> > On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote:
> >> On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Wed, Jun 12, 2013 at 11:56:19PM +0300
Hi,
On Thu, Jun 13, 2013 at 08:26:12PM +0800, Huang Rui wrote:
> > > I was reading dwc3 codes and found that during the process of
> > > configuring event buffer (dwc3_event_buffers_setup), it only write the
> > > size of the buffer and doesn't write interrupt mask bit into GEVNTSIZ
> > > register
Hi,
On Thu, Jun 13, 2013 at 10:37:23AM +0200, Andrzej Pietrasiewicz wrote:
> Hello Felipe, Hello Greg,
>
> I've seen that you pulled a bunch of my patches. That's nice.
>
> However, Felipe was unable to apply one of them due to some whitespace issues,
> so he dropped it.
>
> While dropping the
On Thu, 13 Jun 2013, Viresh Kumar wrote:
> > + bool do_wakeup = device_may_wakeup(&pdev->dev);
> > + int ret;
> > +
> > + ret = ohci_suspend(hcd, do_wakeup);
> > + if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
>
> maybe s/ret == 0/!ret
I tend to prefer using ! f
On 06/13/2013 05:17 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jun 13, 2013 at 12:05:36PM +0300, Roger Quadros wrote:
>> On 06/13/2013 01:37 AM, Greg KH wrote:
>>> On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote:
On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote:
> Hi,
>
On Thu, 13 Jun 2013, Ming Lei wrote:
> - using interrupt threaded handler(default)
> 33.440 MB/sec
>
> - using tasklet(#undef USB_HCD_THREADED_IRQ)
> 34.29 MB/sec
>
> - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c )
> 34.260 MB/s
>
>
> So looks usb mass
HI,
On Thu, Jun 13, 2013 at 05:53:50PM +0300, Roger Quadros wrote:
> On 06/13/2013 05:17 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Jun 13, 2013 at 12:05:36PM +0300, Roger Quadros wrote:
> >> On 06/13/2013 01:37 AM, Greg KH wrote:
> >>> On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote
From: Michael Grzeschik
Instead of having a limited number of usable tds in the udc we use a
linked list to support dynamic amount of needed tds for all special
gadget types. This improves throughput.
Signed-off-by: Michael Grzeschik
Reviewed-by: Felipe Balbi
Signed-off-by: Alexander Shishkin
From: Fabio Estevam
There is no need to keep a 'reg_vbus' indirection, so get rid of it.
The motivation for doing this change is that in the case of error, the current
code only sets the local reg_vbus to NULL instead of updating the private
structure 'data->reg_vbus'.
Updating only the local r
From: Fabio Estevam
Similarly as it is done in ci13xxx_imx_remove(), only calls of_node_put if
data->phy_np is not NULL.
Signed-off-by: Fabio Estevam
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Fabio Estevam
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for handling pinctrl.
So remove devm_pinctrl_get_select_default() from the driver.
Cc:
Signed-off-by: Fabio Estevam
Tested-by: Shawn Guo
Signed-off-by: Alexander Shis
From: Michael Grzeschik
This patch adds iso endpoint support to the device controller.
It makes use of the multiplication bits in the maxpacket field
of the endpoint and calculates the multiplier bits for each
transfer description on every request.
Signed-off-by: Michael Grzeschik
Reviewed-by:
From: Sascha Hauer
Even if a chipidea core is otg capable the board may not be. This allows
to explicitly set the core to host/peripheral mode. Without these flags
the driver falls back to the old behaviour.
Signed-off-by: Sascha Hauer
Signed-off-by: Alexander Shishkin
---
.../devicetree/bind
From: Michael Grzeschik
This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
the devicetree.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sascha Hauer
Acked-by: Felipe Balbi
From: Fabio Estevam
If usbmisc_ops->post() fails it should point the error path to release all
previously acquired resources, so adjust it to call ci13xxx_remove_device().
While at it, remove the unnecessary 'plat_ci' indirection, as we can directly
use the private structure.
Signed-off-by: Fab
Hi,
Here's a set of chipidea updates for v3.11. These are mostly fixes and
cleanups, but also include isoch endpoint support and multi-td
transfers by Michael.
On top there are two mass rename patches that I've been meaning to
push for a while, particularly the one that gets rid of "ci13xxx".
Ev
From: Fabio Estevam
Fix the following sparse warnings:
drivers/usb/chipidea/usbmisc_imx.c:246:5: warning: symbol
'usbmisc_imx_drv_init' was not declared. Should it be static?
drivers/usb/chipidea/usbmisc_imx.c:252:6: warning: symbol
'usbmisc_imx_drv_exit' was not declared. Should it be static?
From: Michael Grzeschik
This patch removes the restriction of having a limited amount of only
four active tds on one endpoint. We use the linked list implementation
to manage all tds which get added and removed by hardware_{en,de}queue.
The removal of this restriction adds the driver to run into
From: Peter Chen
Randy Dunlap reported this problem
on i386:
> drivers/built-in.o: In function `ci_hdrc_host_init':
> (.text+0x2ce75c): undefined reference to `ehci_init_driver'
>
> When USB_EHCI_HCD=m and USB_CHIPIDEA=y.
In fact, this problem is existed on all platforms which are using
chipid
From: Michael Grzeschik
The pdata structure gets copied anyway inside ci13xxx_add_device
by platform_device_add. We don't need to have it static.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sascha Hauer
Reviewed-by: Peter Chen
Signed-off-by: Alexander Shi
From: Andy Shevchenko
As drvdata is cleared to NULL at probe failure or at removal by the driver
core, we don't have to call pci_set_drvdata(pci, NULL) any longer in each
driver.
Signed-off-by: Andy Shevchenko
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_pci.c |1 -
From: Michael Grzeschik
This patch makes it possible to configure the PTW, PTS and STS bits
inside the portsc register for host and device mode before the driver
starts and the phy can be addressed as hardware implementation is
designed.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Klei
From: Philipp Zabel
This patch converts the driver to use the module_platform_driver
macro which makes the code smaller and a bit simpler.
Signed-off-by: Philipp Zabel
Signed-off-by: Michael Grzeschik
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/usbmisc_imx.c | 12 +--
From: Andy Shevchenko
This patch makes error path cleaner and probe function tidier.
Signed-off-by: Andy Shevchenko
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_pci.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/chip
On Thu, 13 Jun 2013, Ming Lei wrote:
> > For reasonably sophisticated host controllers like EHCI, the delay in
> > responding to an interrupt doesn't matter much. But for simpler host
>
> EHCI might still benefit from the change: suppose uvc video is playing on
> one EHCI bus, and mass storage's
From: Sascha Hauer
This patch converts the driver to use devm_usb_get_phy_by_phandle
which makes the code smaller and a bit simpler.
Signed-off-by: Sascha Hauer
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 32
1 file changed, 12
From: Fabio Estevam
There is no need to keep a local 'phy_np' as we can directly use the private
structure in data->phy_np.
Signed-off-by: Fabio Estevam
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-
Since someone has added camelcase detection to checkpatch.pl, chipidea
udc patches have been very noisy. To make everybody's life easier, this
patch changes camelcase names into something more appropriate to the
coding style. No functional changes.
Signed-off-by: Alexander Shishkin
---
drivers/u
On Thu, 13 Jun 2013, Chao Xie wrote:
> >> These operations sound generic enough to be done at HCD layer, no? So no
> >> need to
> >> replicate the same stuff in ohci, ehci, xhci, etc.
> >
> > The HCD layer handles suspend and resume only for PCI host controllers.
> > Not for other types.
> >
> >
Kerry Calvert writes:
[adding linux-usb back to the loop]
> Dude, what is with the spamming of this list? Cease and desist please
These things are called patches. This is how they are distributed in
linux kernel development process.
Regards,
--
Alex
--
To unsubscribe from this list: send the
On Thu, Jun 13, 2013 at 05:25:48PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jun 13, 2013 at 10:37:23AM +0200, Andrzej Pietrasiewicz wrote:
> > Hello Felipe, Hello Greg,
> >
> > I've seen that you pulled a bunch of my patches. That's nice.
> >
> > However, Felipe was unable to apply one of th
Hello.
On 06/13/2013 06:59 PM, Alexander Shishkin wrote:
From: Michael Grzeschik
The pdata structure gets copied anyway inside ci13xxx_add_device
by platform_device_add. We don't need to have it static.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sa
Sergei Shtylyov writes:
> Hello.
>
> On 06/13/2013 06:59 PM, Alexander Shishkin wrote:
>
>> From: Michael Grzeschik
>
>> The pdata structure gets copied anyway inside ci13xxx_add_device
>> by platform_device_add. We don't need to have it static.
>
>> Signed-off-by: Michael Grzeschik
>> Signed-o
On 06/13/2013 08:42 AM, Markos Chandras wrote:
Commit 94d83649e1c2f25c87dc4ead9c2ab073305
"USB: remove USB_EHCI_BIG_ENDIAN_{DESC,MMIO} depends on architecture symbol"
caused the following regression in cavium_octeon_defconfig:
warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects
USB_EH
This patch adds a sysfs attribute for the wireless USB host controller
device notification transmit slot(DNTS) count and interval. It also
changes the defaults from 16 slots in every MMC to a more reasonable 4
slots every 2ms.
Signed-off-by: Thomas Pugliese
diff --git a/drivers/usb/wusbcore/
From: Stephen Warren
Rather than allocating struct tegra_ehci_hcd separately, use struct
ehci_hcd's priv field instead.
Signed-off-by: Stephen Warren
Acked-by: Alan Stern
---
v3: New patch.
---
drivers/usb/host/ehci-tegra.c | 70 +--
1 file changed, 35
From: Stephen Warren
The Tegra EHCI driver directly calls various functions in the Tegra USB
PHY driver. The reverse is also true; the PHY driver calls into the EHCI
driver. This is problematic when the two are built as modules.
The calls from the PHY to EHCI driver were originally added in comm
From: Manjunath Goudar
In order to build a ULPI PHY driver as a module, this symbol needs to
be exported.
Signed-off-by: Manjunath Goudar
[swarren, reworked Manjunath's patches to split them more logically]
Signed-off-by: Stephen Warren
Acked-by: Arnd Bergmann
Acked-by: Felipe Balbi
---
v3:
From: Stephen Warren
I'm reposting this because I originally thought Felipe would apply it
to his PHY tree, since it's based on other work there. Now that tree has
been merged into Greg's main USB tree, I believe this series can be
applied there instead. Hence, resending so it shows up in Greg's
This patch adds a sysfs attribute for the wireless host controller
transaction retry count. It also changes the default value from 15
retries to infinite retries because the driver currently does not handle
retry errors gracefully.
Signed-off-by: Thomas Pugliese
diff --git a/drivers/usb/wusb
From: Stephen Warren
When this file is built as a module, it needs a MODULE_LICENSE in order
to access many exported symbols.
Signed-off-by: Stephen Warren
Acked-by: Arnd Bergmann
Acked-by: Felipe Balbi
---
v3: No change.
v2: No change.
---
drivers/usb/phy/phy-tegra-usb.c | 4
1 file ch
From: Manjunath Goudar
Separate the Tegra on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar
[swarren, reworked Manjunath's patches to split them
From: Manjunath Goudar
In order to split ehci-hcd.c into separate modules, handshake() must be
exported. Rename the symbol to add an ehci_ prefix, to avoid any naming
clashes.
Signed-off-by: Manjunath Goudar
[swarren, split Manjunath's patches more logically, limit this change
to export just ha
From: Stephen Warren
The PM routines in ehci-tegra.c use APIs such as ehci_reset(),
ehci_halt(), and ehci_tdi_reset() that would need to be exported to
convert ehci-tegra.c into a separate module from ehci-hcd.c. However,
we'd prefer not to export them.
Instead, simply remove all power managemen
On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote:
> On Thu, 13 Jun 2013, Ming Lei wrote:
>
> > - using interrupt threaded handler(default)
> > 33.440 MB/sec
> >
> > - using tasklet(#undef USB_HCD_THREADED_IRQ)
> > 34.29 MB/sec
> >
> > - using hard interrupt handler(by r
On Thu, 13 Jun 2013, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-at91 glue was not properly
> handled as it was not suspending generic part of ohci controller.
> Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
> will ensure proper handling of suspend sce
On Thu, 13 Jun 2013, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-s3c2410 glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in ohci_hcd_s3c2410_drv_suspend() will ensure
> proper handling of susp
On Thu, 13 Jun 2013, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-da8xx glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in ohci_da8xx_suspend() will ensure proper
> handling of suspend scenario
Hi Manjunath,
On Thursday 13 of June 2013 14:46:24 Manjunath Goudar wrote:
> Suspend scenario in case of ohci-exynos glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in exynos_ohci_suspend() will ensure prope
On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote:
> On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote:
> > On Thu, 13 Jun 2013, Ming Lei wrote:
> >
> > > - using interrupt threaded handler(default)
> > > 33.440 MB/sec
> > >
> > > - using tasklet(#undef USB_HCD_THREADED_IRQ)
> > >
On Thu, 13 Jun 2013, Tomasz Figa wrote:
> > + rc = ohci_suspend(hcd, do_wakeup);
> > + if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
> > + ohci_resume(hcd, false);
> > + rc = -EBUSY;
> > + }
>
> I'm not into USB host subsystem, so I might just ask a stupid quest
On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
> The test results above show a 2.4% degradation for threaded interrupts
> as compared to tasklets. That's in addition to the bottlenecks caused
> by the device; no doubt it would be worse for a faster device. This
> result calls into quest
On Thu, 13 Jun 2013, Steven Rostedt wrote:
> On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
>
> > The test results above show a 2.4% degradation for threaded interrupts
> > as compared to tasklets. That's in addition to the bottlenecks caused
> > by the device; no doubt it would be worse
On Thu, 2013-06-13 at 17:09 -0400, Alan Stern wrote:
> On Thu, 13 Jun 2013, Steven Rostedt wrote:
>
> > On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
> >
> > > The test results above show a 2.4% degradation for threaded interrupts
> > > as compared to tasklets. That's in addition to the
Hi,
On Wed, Jun 12, 2013 at 06:13:26PM +0300, Felipe Balbi wrote:
> On Mon, Jun 10, 2013 at 01:40:05AM +0300, Aaro Koskinen wrote:
> > +void omap_otg_set_mode(enum omap_otg_mode mode)
> > +{
> > + if (!otg_dev) {
> > + WARN(1, "%s: controller not present\n", __func__);
> > +
On Thu, 13 Jun 2013, Steven Rostedt wrote:
> I only took a quick look at the second patch. I'm now looking at both
> patches applied to the code. I didn't realize this was called from the
> top half.
>
> Usually the top half for threaded interrupts is used just to quite the
> interrupt line. Eith
On Thu, Jun 13, 2013 at 03:41:17PM -0400, Alan Stern wrote:
> On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote:
>
> > On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote:
> > > On Thu, 13 Jun 2013, Ming Lei wrote:
> > >
> > > > - using interrupt threaded handler(default)
> > > > 33.44
On Fri, Jun 14, 2013 at 5:09 AM, Alan Stern wrote:
> On Thu, 13 Jun 2013, Steven Rostedt wrote:
>
>> On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
>>
>> > The test results above show a 2.4% degradation for threaded interrupts
>> > as compared to tasklets. That's in addition to the bottlene
Hi,
On Fri, Jun 14, 2013 at 01:37:11AM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Jun 12, 2013 at 06:13:26PM +0300, Felipe Balbi wrote:
> > On Mon, Jun 10, 2013 at 01:40:05AM +0300, Aaro Koskinen wrote:
> > > +void omap_otg_set_mode(enum omap_otg_mode mode)
> > > +{
> > > + if (!otg_dev) {
> >
On Thu, Jun 13, 2013 at 11:08 PM, Alan Stern wrote:
> On Thu, 13 Jun 2013, Chao Xie wrote:
>
>> >> These operations sound generic enough to be done at HCD layer, no? So no
>> >> need to
>> >> replicate the same stuff in ohci, ehci, xhci, etc.
>> >
>> > The HCD layer handles suspend and resume onl
1 - 100 of 111 matches
Mail list logo
