Thank you very much for another detailed reply.
On Sat, Nov 30, 2013 at 4:55 PM, Alan Stern wrote:
> By "device", I mean the piece of hardware that is supposed to reply to
> the host. In your case that would be the modem (the hub does not make
> up replies to packets that were sent to the modem)
On Sun, 1 Dec 2013, vichy wrote:
> hi Alan:
>
> 2013/12/1 Alan Stern :
> > On Fri, 29 Nov 2013, vichy wrote:
> >
> >> hi all:
> >> My connection like below
> >> ehci --> high speed hub -> full speed device
> >>
> >> I have some questions about period scheduling.
> >> 1. when creating qh for full
On Sun, 1 Dec 2013, yoma sophian wrote:
> >> Suppose itds are submitted then ehci_work is triggered by bulk
> >> interrupt and ehci->isoc_count >0.
> >>
> >> The race condition may happen if hardware hasn't handled those itds, right?
> >
> > I don't know what race condition you are talking about.
Hi folks.
I have received a new dell precision 4800 with USB 3.0.
I've compiled the gentoo for it. Currently I run
Linux genlap 3.12.1-gentoo #23 SMP Sat Nov 30 19:47:03 CET 2013 x86_64 Intel(R)
Core(TM) i7-4900MQ CPU @ 2.80GHz GenuineIntel GNU/Linux
I have problems connecting my usb 3.0 exte
On Saturday, November 30, 2013 06:20 PM, Peter Chen wrote:
usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
* init the sts flag to 0 (missed)
* Set PORTCS_STS only if VUSB_HS_PHY_TYPE> 1
otherwise the register is ReadOnly
* Set/Reset correct BIT(28)/BIT(29) for STS
On Sat, Nov 30, 2013 at 6:23 AM, Tejun Heo wrote:
> On Tue, Nov 26, 2013 at 12:43:37PM +0800, Ming Lei wrote:
>> sg_copy_buffer() can't meet demand for some drrivers(such usb
>> mass storage), so we have to use the sg_miter_* APIs to access
>> sg buffer, then need export sg_miter_skip() for these
On Mon, Dec 02, 2013 at 10:11:21AM +0800, Ming Lei wrote:
> On Sat, Nov 30, 2013 at 6:23 AM, Tejun Heo wrote:
> > On Tue, Nov 26, 2013 at 12:43:37PM +0800, Ming Lei wrote:
> >> sg_copy_buffer() can't meet demand for some drrivers(such usb
> >> mass storage), so we have to use the sg_miter_* APIs t
From: Fabio Estevam
clk_prepare_enable() may fail, so let's check its return value and propagate it
in the case of error.
Signed-off-by: Fabio Estevam
---
drivers/usb/phy/phy-mxs-usb.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-mxs-usb.c
>
> If you have a look into the function hw_write() you will see that there
> is no
> effect if hw_write(...,sts) is called with sts=0/1, because the mask will
> cut
> off all bits beside BIT(29).
Yes, it is my careless. I thought sts is PORTCS_STS.
> I used BIT(29) rather then PORTCS_STS to m
>
> clk_prepare_enable() may fail, so let's check its return value and
> propagate it
> in the case of error.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/usb/phy/phy-mxs-usb.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-mxs-us
On Monday, December 02, 2013 01:10 PM, Peter Chen wrote:
If you have a look into the function hw_write() you will see that there
is no
effect if hw_write(...,sts) is called with sts=0/1, because the mask will
cut
off all bits beside BIT(29).
Yes, it is my careless. I thought sts is PORTCS_
usb: phy-ulpi: Add EXTVBUSIND,CHRGVBUS flag support
ULPI like ISP1504 support external vbus power indication
used in combination with vbus switches mic2075.
Signed-off-by: Chris Ruehl
---
drivers/usb/phy/phy-ulpi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
This patch set add support
* GPIO ChipSelect
* ULPI support to set VBUS flags for EXTVBUSIND,CHRGVBUS
* ULPI support to set VBUS flags from DT
[PATCH 1/3] usb: phy-generic: Add GPIO based ChipSelect
The ULPI ISP1504 uses the CHIP_SELECT_N (low active) pin to active the
chip. This
usb: phy-generic: Add ULPI VBUS support
Some platforms need to set the VBUS parameters of the ULPI
like ISP1504 which interact with overcurrent protection and
power switch MIC2575. Therefore it requires to set
* DRVVBUS
* DRVVBUS_EXT
* EXTVBUSIND
* CHRGVBUS
of the ULPI.
This patch add support for
usb: phy-generic: Add GPIO based ChipSelect
The ULPI ISP1504 uses the CHIP_SELECT_N (low active) pin to active the
chip. This patch add support for GPIO based ChipSelect almost the same
way implemented for the Reset feature.
Sample DT configuration:
pinctrl_usbphy2: usbphy-2 {
fsl,pins = <
15 matches
Mail list logo