This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.
Signed-off-by: Kuninori Morimoto
---
drivers/usb/phy/Kconfig| 11
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/rcar-phy.c | 137
3 files changed,
On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork wrote:
> Suspending an open usbnet device results in constant
> rescheduling of usbnet_bh.
>
> commit 65841fd5 "usbnet: handle remote wakeup asap"
> refactored the usbnet_bh code to allow sharing the
> urb allocate and submit code with usbnet_resume. In
>
[CC'ing an USB audio heavyweight - Daniel Mack]
On Tue, Sep 4, 2012 at 12:39 AM, Alan Stern wrote:
> On Mon, 3 Sep 2012, Jassi Brar wrote:
>
>> On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern
>> wrote:
>> > Clemens and Laurent (and anyone else who's interested):
>> >
>> > How should the lower USB
> In such a situation, the delay is much bigger than the device's buffer,
> so just sending more samples afterwards will not help.
>
It is ISO transfer, if the delay is too much, and the buffer at device side is
empty, it is normal the screen is stopped like we watch movie on Internet
(buffering...
Despite the patch
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1018, 0xff, 0xff,
0xff),
.driver_info = (kernel_ulong_t)&net_intf3_blacklist },
is included in option, it has no effect.
[ 1109.116127] usb 1-4: new high-speed USB device number 3 using ehci_hcd
[ 1109.251733]
On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> >> The audio driver wouldn't care. Logically, it starts a new stream.
> >
> > Really? Why not just skip a few packets and carry on with the existing
> > stream?
> > Logically, the situ
Alan Stern wrote:
> On Mon, 3 Sep 2012, Clemens Ladisch wrote:
>> The audio driver wouldn't care. Logically, it starts a new stream.
>
> Really? Why not just skip a few packets and carry on with the existing
> stream?
> Logically, the situation isn't very different from what happens when
> packet
Dnia poniedziałek, 3 września 2012 o 22:00:03 Alan Stern napisał(a):
> On Mon, 3 Sep 2012, Marek Floriańczyk wrote:
> > HI,
> >
> > Debian testing, kernel 3.2.0-3 and results are the same. Order in which I
> > call devices is important, first device I call always gives reply,
> > second one almost
On Mon, 3 Sep 2012, Marek Floriańczyk wrote:
> HI,
>
> Debian testing, kernel 3.2.0-3 and results are the same. Order in which I
> call
> devices is important, first device I call always gives reply, second one
> almost
> never, no matter on what bus number they are. When I insert some delay
Dnia sobota, 1 września 2012 o 22:51:42 Alan Stern napisał(a):
> On Sat, 1 Sep 2012, Marek Floriańczyk wrote:
> > > It's possible that data is getting lost, but it's pretty unlikely. The
> > > only way to get more detailed debugging information is to use a USB bus
> > > analyzer.
> >
> > HI,
> >
With "select USB_ISP1301 ...", it could happen that I2C isn't selected although
USB_ISP1301 depends on it. Fixing with "depends on ..." and emulating the
condition via "|| !()".
Signed-off-by: Roland Stigge
Acked-by: Alan Stern
---
drivers/usb/host/Kconfig |2 +-
1 file changed, 1 insertion
On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> >> Alan Stern wrote:
> >>> Alternatively, the host controller driver could fail the next 40 ms
> >>> worth of isochronous URBs, so that the higher-level client catches up
> >>> to where
On Mon, 3 Sep 2012, Jassi Brar wrote:
> On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern
> wrote:
> > Clemens and Laurent (and anyone else who's interested):
> >
> > How should the lower USB layers handle delays in transferring
> > isochronous data? I'm asking you because the most common usages of
Alan Stern wrote:
> On Mon, 3 Sep 2012, Clemens Ladisch wrote:
>> Alan Stern wrote:
>>> Alternatively, the host controller driver could fail the next 40 ms
>>> worth of isochronous URBs, so that the higher-level client catches up
>>> to where it should be. The failure could occur during submission
Andrew Lunn wrote:
>The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0
>and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this.
>
>Reported-by: Sebastian Hesselbarth
>Signed-off-by: Andrew Lunn
>---
> drivers/usb/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
>diff --gi
The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0
and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this.
Reported-by: Sebastian Hesselbarth
Signed-off-by: Andrew Lunn
---
drivers/usb/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/Kconfig b/drive
From: Bjørn Mork
Date: Mon, 3 Sep 2012 11:20:33 +0200
> The rx_urb_size is set to the same value for every device
> supported by this driver. No need to keep a per-device
> data structure to do that. Replacing with a macro constant.
>
> This was the last device specific info, and removing it
>
From: Bjørn Mork
Date: Mon, 3 Sep 2012 11:20:32 +0200
> Signed-off-by: Bjørn Mork
Applied.
--
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
From: Bjørn Mork
Date: Mon, 3 Sep 2012 11:20:31 +0200
> Signed-off-by: Bjørn Mork
Applied.
--
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
From: Bjørn Mork
Date: Mon, 3 Sep 2012 10:26:18 +0200
> Suspending an open usbnet device results in constant
> rescheduling of usbnet_bh.
>
> commit 65841fd5 "usbnet: handle remote wakeup asap"
> refactored the usbnet_bh code to allow sharing the
> urb allocate and submit code with usbnet_resum
From: Forest Bond
Certain eGalax devices expose an interface with class HID and protocol
None. Some work with usbhid and some work with usbtouchscreen, but
there is no easy way to differentiate. Sending an eGalax diagnostic
packet seems to kick them all into using the right protocol for
usbtouc
On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern wrote:
> Clemens and Laurent (and anyone else who's interested):
>
> How should the lower USB layers handle delays in transferring
> isochronous data? I'm asking you because the most common usages of
> isochronous transfers are for audio and video.
>
>
On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > How should the lower USB layers handle delays in transferring
> > isochronous data? [...] when this happens the endpoint's queue
> > drains completely.
> >
> > Clearly this will cause a glitch in the data stream. The question is:
On 09/03/2012 05:39 PM, Roland Stigge wrote:
> Hi Marc and Sascha,
>
> On 09/03/2012 04:49 PM, Marc Kleine-Budde wrote:
>>> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
Hi,
this is my first try on activating EHCI on imx53 (primarily via
dt). However, probe() s
Only this part of the question about kernel 3.x is actual.
In older kernel I have problems with clock domains and their dependencies.
--
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.
Hi Marc and Sascha,
On 09/03/2012 04:49 PM, Marc Kleine-Budde wrote:
>> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
>>> Hi,
>>>
>>> this is my first try on activating EHCI on imx53 (primarily via
>>> dt). However, probe() still hangs on the first ehci_writel()
>>> l.189. I gues
On Sun, 2 Sep 2012, Matthew Hall wrote:
> > > What about a quirk which gets the blocksize from the smaller commands and
> > > combines with the device size from the larger command?
> >
> > It's not quite that simple. The trace showed that two different
> > commands gave the right block size, a
ACPI provide "_PLD" and "_UPC" aml methods to describe usb port
visibility and connectability. This patch is to use those information
to set usb port's DeviceRemovable.
Signed-off-by: Lan Tianyu
---
v2: Set DeviceRemovable according acpi infomation in the hub_configure()
instead of calling get_hu
This patch is to add "auto" option to attribute portX/control.
When echo "auto", the port's feature PORT_POWER would be clear
if the port's connect type was mark not-used(connectability and
visibility are both cleared) and with no device attached.
Signed-off-by: Lan Tianyu
---
This patchset is ba
On 09/03/2012 04:37 PM, Sascha Hauer wrote:
> Hi Roland,
>
> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
>> Hi,
>>
>> this is my first try on activating EHCI on imx53 (primarily via dt). However,
>> probe() still hangs on the first ehci_writel() l.189. I guess some
>> clock/enab
Hi Roland,
On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
> Hi,
>
> this is my first try on activating EHCI on imx53 (primarily via dt). However,
> probe() still hangs on the first ehci_writel() l.189. I guess some
> clock/enabling is still missing?
>
> Sascha, do you already hav
Hi,
this is my first try on activating EHCI on imx53 (primarily via dt). However,
probe() still hangs on the first ehci_writel() l.189. I guess some
clock/enabling is still missing?
Sascha, do you already have EHCI running on imx53?
Any hint would be very much appreciated.
Thanks in advance,
R
Hi,
On Wed, Aug 29, 2012 at 12:17:01PM +0530, Venu Byravarasu wrote:
> As otg.h is containing lots of phy interface related
> stuff, moving all phy interface related stuff to new
> file named phy.h
>
> Signed-off-by: Venu Byravarasu
this doesn't apply to my "xceiv" branch. Please rebase there s
On Mon, Sep 03, 2012 at 05:00:44PM +0530, Sachin Kamat wrote:
> Hi
>
> On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY wrote:
> > Hi,
> >
> > On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat
> > wrote:
> >> Silences the following type of sparse warnings:
> >> warning: Using plain integer as NULL p
On Fri, Aug 31, 2012 at 08:37:26PM -0400, Forest Bond wrote:
> From: Forest Bond
>
> Certain eGalax devices expose an interface with class HID and protocol
> None. Some work with usbhid and some work with usbtouchscreen, but
> there is no easy way to differentiate. Sending an eGalax diagnostic
On Friday 24 August 2012 16:42:20 Yann Cantin wrote:
> Hi,
>
> Le 24/08/2012 13:41, Oliver Neukum a écrit :
> > On Friday 24 August 2012 11:37:45 Yann Cantin wrote:
> >> Hi,
> >>
> >> Le 23/08/2012 09:23, Oliver Neukum a écrit :
> >>> On Thursday 23 August 2012 00:11:54 Yann Cantin wrote:
> >
> >
Peter Chen wrote:
>> How should the lower USB layers handle delays in transferring
>> isochronous data?
>> I have seen reports from users where URB completion interrupts were
>> delayed by as much as 50 ms.
>>
>> What should we do to recover and re-synchronize?
>
> I am not sure if feedback endpoin
Alan Stern wrote:
> How should the lower USB layers handle delays in transferring
> isochronous data? [...] when this happens the endpoint's queue
> drains completely.
>
> Clearly this will cause a glitch in the data stream. The question is:
> What should we do to recover and re-synchronize?
The
Hi
On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat wrote:
>> Silences the following type of sparse warnings:
>> warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> drivers/usb/gadget/s3c-hsudc.c
Hi,
On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat wrote:
> Silences the following type of sparse warnings:
> warning: Using plain integer as NULL pointer
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/usb/gadget/s3c-hsudc.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
>
devm_* functions are already used in this file. Hence
convert clk_get to devm_clk_get for completeness.
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsotg.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s
Silences the following type of sparse warnings:
warning: Using plain integer as NULL pointer
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsud
Silences the following checkpatch warning:
WARNING: sizeof *hsreq should be sizeof(*hsreq)
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
inde
devm_* functions are used to replace kzalloc, request_mem_region, ioremap
clk_get and request_irq functions in probe call. With the usage of devm_*
functions explicit freeing and unmapping is not required.
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c | 41
The rx_urb_size is set to the same value for every device
supported by this driver. No need to keep a per-device
data structure to do that. Replacing with a macro constant.
This was the last device specific info, and removing it
allows us to delete the sierra_net_info_data struct.
Signed-off-by:
Signed-off-by: Bjørn Mork
---
drivers/net/usb/sierra_net.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 7be49ea..596ddaa 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cx82310_eth.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index 49ab45e..1e207f0 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx823
Hi,
I'm facing some problems with USB power management on OMAP3 (Beagleboard-Xm).
Lately I have tried kernel 3.6-rc3 for omap but usb bus suspend/resume is
switched off there due to some problems with clocks:
This is described in:
[PATCH] OMAP: USB : Fix the EHCI enumeration and core retention is
Suspending an open usbnet device results in constant
rescheduling of usbnet_bh.
commit 65841fd5 "usbnet: handle remote wakeup asap"
refactored the usbnet_bh code to allow sharing the
urb allocate and submit code with usbnet_resume. In
this process, a test for, and immediate return on,
ENOLINK from
49 matches
Mail list logo
