From: Robin Getz <[email protected]>
Allow embedded developers to turn support for USB Hubs off even if they have a
full root hub. This saves the overhead (RAM and Flash size).
Allow embedded developers the capabilities of the "otg_whitelist.h" - a
product whitelist, so USB peripherals not listed there will be rejected
during enumeration. This is the desired operation for many embedded products.
Signed-off-by: Robin Getz <[email protected]>
---
drivers/usb/core/Kconfig | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6.x/drivers/usb/core/Kconfig
===================================================================
--- linux-2.6.x/drivers/usb/core/Kconfig (revision 4074)
+++ linux-2.6.x/drivers/usb/core/Kconfig (working copy)
@@ -95,8 +95,9 @@
config USB_OTG_WHITELIST
bool "Rely on OTG Targeted Peripherals List"
- depends on USB_OTG
- default y
+ depends on USB_OTG || EMBEDDED
+ default y if USB_OTG
+ default n if EMBEDDED
help
If you say Y here, the "otg_whitelist.h" file will be used as a
product whitelist, so USB peripherals not listed there will be
@@ -111,7 +112,7 @@
config USB_OTG_BLACKLIST_HUB
bool "Disable external hubs"
- depends on USB_OTG
+ depends on USB_OTG || EMBEDDED
help
If you say Y here, then Linux will refuse to enumerate
external hubs. OTG hosts are allowed to reduce hardware
On Wednesday 02 January 2008, Robin Getz wrote:
> From: Robin Getz <[email protected]>
>
> Allow embedded developers to turn support for USB Hubs off even if they have a
> full root hub. This saves the overhead (RAM and Flash size).
ISTR that it won't save very much code though ... the Linux USB
stack structures all its enumeration logic around hubs.
> Allow embedded developers the capabilities of the "otg_whitelist.h" - a
> product whitelist, so USB peripherals not listed there will be rejected
> during enumeration. This is the desired operation for many embedded products.
>
> Signed-off-by: Robin Getz <[email protected]>
This is probably the right thing to do. Correct me if I'm wrong,
but USB-IF recently put out some specs about "embedded hosts" which
basically boil down to saying you can adopt the same functionality
restrictions that used to be OTG-only. Which is why now there are
embedded developers who'd like this option. :)
- Dave
>
> ---
>
> drivers/usb/core/Kconfig | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
>
> Index: linux-2.6.x/drivers/usb/core/Kconfig
> ===================================================================
> --- linux-2.6.x/drivers/usb/core/Kconfig (revision 4074)
> +++ linux-2.6.x/drivers/usb/core/Kconfig (working copy)
> @@ -95,8 +95,9 @@
>
> config USB_OTG_WHITELIST
> bool "Rely on OTG Targeted Peripherals List"
> - depends on USB_OTG
> - default y
> + depends on USB_OTG || EMBEDDED
> + default y if USB_OTG
> + default n if EMBEDDED
> help
> If you say Y here, the "otg_whitelist.h" file will be used as a
> product whitelist, so USB peripherals not listed there will be
> @@ -111,7 +112,7 @@
>
> config USB_OTG_BLACKLIST_HUB
> bool "Disable external hubs"
> - depends on USB_OTG
> + depends on USB_OTG || EMBEDDED
> help
> If you say Y here, then Linux will refuse to enumerate
> external hubs. OTG hosts are allowed to reduce hardware
>
On Jan 2, 2008 1:47 PM, David Brownell <[email protected]> wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <[email protected]>
> >
> > Allow embedded developers to turn support for USB Hubs off even if they have a
> > full root hub. This saves the overhead (RAM and Flash size).
>
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.
perhaps the code size is arguable as to whether it really matters.
the reason we want it is that we have a USB host controller that will
not work with USB hubs, so we want to make sure the system does not
attempt such things. (yes, such a USB host controller is retarded,
but the decision was out of our hands.)
-mike
On Wednesday 02 January 2008, Felipe Balbi wrote:
> The problem I see here is that my only
> "user" is musb driver, currently only available on linux-omap git tree.
>
> Maybe it's time to send it to mainline, what do you think Dave?
Probably time, yes. ISTR the main open issues are on host side
behavior, and it'll be easier to sort those out if musb_hdrc can
be updated without a few months intervening lag time.
Plus that'll make it easier to merge the Blackfin platform updates
for that driver. It's fine that musb_hdrc works on N800, N810,
DaVinci, OMAP2430, and more ... but non-TI chips also integrate
that high speed OTG silicon. :)
- Dave
On Wednesday 02 January 2008, Mike Frysinger wrote:
> > >
> > > Allow embedded developers to turn support for USB Hubs off even if they have a
> > > full root hub. This saves the overhead (RAM and Flash size).
> >
> > ISTR that it won't save very much code though ... the Linux USB
> > stack structures all its enumeration logic around hubs.
>
> perhaps the code size is arguable as to whether it really matters.
> the reason we want it is that we have a USB host controller that will
> not work with USB hubs, so we want to make sure the system does not
> attempt such things. ?(yes, such a USB host controller is retarded,
> but the decision was out of our hands.)
Well, it won't work with *external* hubs. Root hubs are a different
story. :)
I think that's one of a class of decisions sometimes made by folk
who need to conserve silicon real estate. Supporting external hubs
has always been optional for OTG systems.
- Dave
On Wed, Jan 02, 2008 at 10:47:15AM -0800, David Brownell wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <[email protected]>
> >
> > Allow embedded developers to turn support for USB Hubs off even if they have a
> > full root hub. This saves the overhead (RAM and Flash size).
>
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.
>
>
> > Allow embedded developers the capabilities of the "otg_whitelist.h" - a
> > product whitelist, so USB peripherals not listed there will be rejected
> > during enumeration. This is the desired operation for many embedded products.
> >
> > Signed-off-by: Robin Getz <[email protected]>
>
> This is probably the right thing to do. Correct me if I'm wrong,
> but USB-IF recently put out some specs about "embedded hosts" which
> basically boil down to saying you can adopt the same functionality
> restrictions that used to be OTG-only. Which is why now there are
> embedded developers who'd like this option. :)
otg whitelist is not a blocker. A device that is not listed on TPL
might or might not work. The logic around that should be something like:
parse_whitelist()
if (!listed) {
match_class_with_tpled_devices();
if (match_any)
check_power_need();
if (power_need <= 100mA)
allow_enumeration();
else
deny_enumaration_and_message();
If you check n810, you'll see that even though a usb memory stick is not
listed on its TPL, we allow it to enumerate as long as it draws less
then 100mA and this is true on something around 95% of usb memory
sticks.
I'm kinda busy with other tasks right now, but when I finish formating
proper patches for current mainline head, I'll release some code adding
support for dynamic otg tpl. The problem I see here is that my only
"user" is musb driver, currently only available on linux-omap git tree.
Maybe it's time to send it to mainline, what do you think Dave?
In any case, I'll format such patches when I'm done with twl4030 and
isp1301 development, something around 3 ~ 4 weeks from now.
Even though, embedded hosts should have the same behavior.
Best Regards,
Felipe Balbi
On Wed, 2 Jan 2008, Mike Frysinger wrote:
> perhaps the code size is arguable as to whether it really matters.
> the reason we want it is that we have a USB host controller that will
> not work with USB hubs, so we want to make sure the system does not
> attempt such things. (yes, such a USB host controller is retarded,
> but the decision was out of our hands.)
Just out of curiosity, how does a host controller manage to avoid
working with external hubs? Is it a matter of power consumption? It
seems to me that in all other respects a hub should appear the same as
any other USB device.
Or is it a question of whether the controller works when communicating
with devices behind an external hub? And if it is, what is the
difficulty?
Alan Stern
On Wednesday 02 January 2008, Alan Stern wrote:
> On Wed, 2 Jan 2008, Mike Frysinger wrote:
>
> > perhaps the code size is arguable as to whether it really matters.
> > the reason we want it is that we have a USB host controller that will
> > not work with USB hubs, so we want to make sure the system does not
> > attempt such things. (yes, such a USB host controller is retarded,
> > but the decision was out of our hands.)
>
> Just out of curiosity, how does a host controller manage to avoid
> working with external hubs?
The transaction translators in external high speed hubs require
hosts to issue particular USB transactions. If the host controller
doesn't implement the that split transaction support, then it won't
be supporting external hubs.
The Mentor USB High Speed Dual Role Host Controller silicon IP (using
the aforementioned musb_hdrc driver) is one example of such silicon.
The "Multipoint" licensing option is basically for the TT support,
as I understand it.
One example of its use in a product is with TI's DaVinci chips. You
can go to http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html
and download the USB controller docs. Ignore the nasty CPPI DMA glued
onto it, and observe that there are host side TX and RX HUB registers
that won't be present on designs that omit the "multipoint" support.
(Which evidently include one of the Blackfin designs.)
- Dave
On Wed, 2 Jan 2008, David Brownell wrote:
> On Wednesday 02 January 2008, Alan Stern wrote:
> > On Wed, 2 Jan 2008, Mike Frysinger wrote:
> >
> > > perhaps the code size is arguable as to whether it really matters.
> > > the reason we want it is that we have a USB host controller that will
> > > not work with USB hubs, so we want to make sure the system does not
> > > attempt such things. (yes, such a USB host controller is retarded,
> > > but the decision was out of our hands.)
> >
> > Just out of curiosity, how does a host controller manage to avoid
> > working with external hubs?
>
> The transaction translators in external high speed hubs require
> hosts to issue particular USB transactions. If the host controller
> doesn't implement the that split transaction support, then it won't
> be supporting external hubs.
So in theory one could connect a high-speed hub to such a host
controller and expect it to communicate with high-speed devices. So
long as no full- or low-speed devices are added there wouldn't be any
split transactions. It wouldn't be USB-2.0 compliant but it should
still work.
Alan Stern
On Wed 2 Jan 2008 13:47, David Brownell pondered:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <[email protected]>
> >
> > Allow embedded developers to turn support for USB Hubs off even if
> > they have a full root hub. This saves the overhead (RAM and Flash size).
>
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.
Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB &&
USB_GADGET).
This just enables cutting more code out, with out having to have USB_GADGET &
USB_OTG enabled. When I checked - that is where most of the savings came
from.
-Robin
On Jan 3, 2008 2:47 AM, David Brownell <[email protected]> wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <[email protected]>
> >
> > Allow embedded developers to turn support for USB Hubs off even if they have a
> > full root hub. This saves the overhead (RAM and Flash size).
>
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.
>
>
> > Allow embedded developers the capabilities of the "otg_whitelist.h" - a
> > product whitelist, so USB peripherals not listed there will be rejected
> > during enumeration. This is the desired operation for many embedded products.
> >
> > Signed-off-by: Robin Getz <[email protected]>
>
> This is probably the right thing to do. Correct me if I'm wrong,
> but USB-IF recently put out some specs about "embedded hosts" which
> basically boil down to saying you can adopt the same functionality
> restrictions that used to be OTG-only. Which is why now there are
> embedded developers who'd like this option. :)
>
> - Dave
>
>
Yes, "embedded hosts" which currently not support whole USB 2.0 spec
is what Robin's patch serving for.
Although in MUSB of Blackfin can support USB_OTG and we can enable
this, some real embedded application just use the MUSB_HOST mode. So
just enable MUSB_HOST can save some embedded space because it does
not including MUSB_PERIPHERAL code.
I believe some embedded SoC including embedded USB host controller
also need this option open for them.
Thanks
-Bryan Wu
>
>
> >
> > ---
> >
> > drivers/usb/core/Kconfig | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> >
> > Index: linux-2.6.x/drivers/usb/core/Kconfig
> > ===================================================================
> > --- linux-2.6.x/drivers/usb/core/Kconfig (revision 4074)
> > +++ linux-2.6.x/drivers/usb/core/Kconfig (working copy)
> > @@ -95,8 +95,9 @@
> >
> > config USB_OTG_WHITELIST
> > bool "Rely on OTG Targeted Peripherals List"
> > - depends on USB_OTG
> > - default y
> > + depends on USB_OTG || EMBEDDED
> > + default y if USB_OTG
> > + default n if EMBEDDED
> > help
> > If you say Y here, the "otg_whitelist.h" file will be used as a
> > product whitelist, so USB peripherals not listed there will be
> > @@ -111,7 +112,7 @@
> >
> > config USB_OTG_BLACKLIST_HUB
> > bool "Disable external hubs"
> > - depends on USB_OTG
> > + depends on USB_OTG || EMBEDDED
> > help
> > If you say Y here, then Linux will refuse to enumerate
> > external hubs. OTG hosts are allowed to reduce hardware
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wednesday 02 January 2008, Robin Getz wrote:
> On Wed 2 Jan 2008 13:47, David Brownell pondered:
> > On Wednesday 02 January 2008, Robin Getz wrote:
> > > From: Robin Getz <[email protected]>
> > >
> > > Allow embedded developers to turn support for USB Hubs off even if
> > > they have a full root hub. This saves the overhead (RAM and Flash size).
> >
> > ISTR that it won't save very much code though ... the Linux USB
> > stack structures all its enumeration logic around hubs.
>
> Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB &&
> USB_GADGET).
>
> This just enables cutting more code out, with out having to have USB_GADGET &
> USB_OTG enabled. When I checked - that is where most of the savings came
> from.
Right. I'm not objecting to this at all. Just pointing
out that usbcore will still end up including quite a lot
of hub functionality, because there's still going to be
a root hub in the system and a khubd managing it.
This patch might be improved slightly -- in ways that, as I
understand things, could save some RAM on Blackfin! -- by
having the BLACKLIST_HUB option get rid of the transaction
translator support (changing C code not just Kconfig).
It's pretty minimal, but won't be used...
Also, as you point out, it's no longer OTG specific, so
renaming the option would improve clarity. Maybe to
something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
No big deal, at least now.
- Dave
On Wednesday 02 January 2008, Alan Stern wrote:
>
> > The transaction translators in external high speed hubs require
> > hosts to issue particular USB transactions. ?If the host controller
> > doesn't implement the that split transaction support, then it won't
> > be supporting external hubs.
>
> So in theory one could connect a high-speed hub to such a host
> controller and expect it to communicate with high-speed devices. ?So
> long as no full- or low-speed devices are added there wouldn't be any
> split transactions. ?It wouldn't be USB-2.0 compliant but it should
> still work.
Yes ...
But that would be a nightmare in terms of support calls. Take
two USB trees, and swap the hub ... suddenly one of the downstream
devices (the full speed one) starts (or stops!) working! That's
not the sort of issue any support line wants to cope with on a
day-to-day basis.
The accounting for those products is often along the lines of:
if you got a support call, you didn't profit from that sale.
(And from the user perspective it's just a PITA and waste of
time.) So *every* confusion like that one gets removed.
- Dave
On Jan 3, 2008 4:58 AM, Alan Stern <[email protected]> wrote:
> On Wed, 2 Jan 2008, David Brownell wrote:
>
> > On Wednesday 02 January 2008, Alan Stern wrote:
> > > On Wed, 2 Jan 2008, Mike Frysinger wrote:
> > >
> > > > perhaps the code size is arguable as to whether it really matters.
> > > > the reason we want it is that we have a USB host controller that will
> > > > not work with USB hubs, so we want to make sure the system does not
> > > > attempt such things. (yes, such a USB host controller is retarded,
> > > > but the decision was out of our hands.)
> > >
> > > Just out of curiosity, how does a host controller manage to avoid
> > > working with external hubs?
> >
> > The transaction translators in external high speed hubs require
> > hosts to issue particular USB transactions. If the host controller
> > doesn't implement the that split transaction support, then it won't
> > be supporting external hubs.
>
> So in theory one could connect a high-speed hub to such a host
> controller and expect it to communicate with high-speed devices. So
> long as no full- or low-speed devices are added there wouldn't be any
> split transactions. It wouldn't be USB-2.0 compliant but it should
> still work.
>
Hmmm, basically, I think the answer is yes.
But when you tell customers your devices support USB 2.0, they will
try to plug-in lots of USB devices that you can not even imagine.
If they plug-in a combo USB device including an external USB hub, the
whole embedded Linux system maybe crash or hang there.
So this patch is to refuse enumerate such unsupported USB devices.
-Bryan Wu
On Jan 3, 2008 11:43 AM, David Brownell <[email protected]> wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > On Wed 2 Jan 2008 13:47, David Brownell pondered:
> > > On Wednesday 02 January 2008, Robin Getz wrote:
> > > > From: Robin Getz <[email protected]>
> > > >
> > > > Allow embedded developers to turn support for USB Hubs off even if
> > > > they have a full root hub. This saves the overhead (RAM and Flash size).
> > >
> > > ISTR that it won't save very much code though ... the Linux USB
> > > stack structures all its enumeration logic around hubs.
> >
> > Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB &&
> > USB_GADGET).
> >
> > This just enables cutting more code out, with out having to have USB_GADGET &
> > USB_OTG enabled. When I checked - that is where most of the savings came
> > from.
>
> Right. I'm not objecting to this at all. Just pointing
> out that usbcore will still end up including quite a lot
> of hub functionality, because there's still going to be
> a root hub in the system and a khubd managing it.
>
> This patch might be improved slightly -- in ways that, as I
> understand things, could save some RAM on Blackfin! -- by
> having the BLACKLIST_HUB option get rid of the transaction
> translator support (changing C code not just Kconfig).
> It's pretty minimal, but won't be used...
>
> Also, as you point out, it's no longer OTG specific, so
> renaming the option would improve clarity. Maybe to
> something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
> No big deal, at least now.
>
Thanks, that's the point.
Maybe Robin can choose a good name of this option.
I am just very happy that when plug-in an external hubs or something
like that will not make our system hangs, -:)))
B.T.W, 2 questions about the MUSB driver:
1. What's the plan for mainline merge of the whole MUSB driver? maybe
I can cleanup current Blackfin ports to you guys.
2. Do you remember the PING issue I reported in OMAP list? How do you
think of that?
Best Regards,
-Bryan Wu
On Wednesday 02 January 2008, Bryan Wu wrote:
> B.T.W, 2 questions about the MUSB driver:
> 1. What's the plan for mainline merge of the whole MUSB driver? maybe
> I can cleanup current Blackfin ports to you guys.
It might as well merge in 2.6.25-early. It'll be easier to integrate
patches that way. Including your Blackfin port. When I asked before,
nobody hugely objected to "one big patch".
> 2. Do you remember the PING issue I reported in OMAP list? How do you
> think of that?
Yes, something needs to be done. EHCI might benefit from the same
kind of patch, to cope with ill-behaved usb thumb drives.
> > I have an idea: the USB_NAKLIMIT0 should be set to some value, when we
> > got NAK timeout interrupt, we can disable PING. When enumerating normal
> > USB stick, there is no NAK timeout, because PING is efficient for
> > handshaking. While problem USB stick will generate NAK timeout
> > interrupt, we disable PING for this kind of USB device enumeration.
That sounds much better than your original patch, which disabled it
always. It might even be worth allocating a flag somewhere in the
usb_device structure to record when ep0 pings seem to misbehave.
- Dave
On Wed 2 Jan 2008 22:43, David Brownell pondered:
> This patch might be improved slightly -- in ways that, as I
> understand things, could save some RAM on Blackfin! -- by
> having the BLACKLIST_HUB option get rid of the transaction
> translator support (changing C code not just Kconfig).
> It's pretty minimal, but won't be used...
>
> Also, as you point out, it's no longer OTG specific, so
> renaming the option would improve clarity. Maybe to
> something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
> No big deal, at least now.
Are these two things something that you want me to have a stab at, or since
you are more familiar with it - you want to do it.
Thanks
-Robin
On Jan 3, 2008 3:36 PM, David Brownell <[email protected]> wrote:
> On Wednesday 02 January 2008, Bryan Wu wrote:
> > B.T.W, 2 questions about the MUSB driver:
> > 1. What's the plan for mainline merge of the whole MUSB driver? maybe
> > I can cleanup current Blackfin ports to you guys.
>
> It might as well merge in 2.6.25-early. It'll be easier to integrate
> patches that way. Including your Blackfin port. When I asked before,
> nobody hugely objected to "one big patch".
>
>
> > 2. Do you remember the PING issue I reported in OMAP list? How do you
> > think of that?
>
> Yes, something needs to be done. EHCI might benefit from the same
> kind of patch, to cope with ill-behaved usb thumb drives.
>
>
> > > I have an idea: the USB_NAKLIMIT0 should be set to some value, when we
> > > got NAK timeout interrupt, we can disable PING. When enumerating normal
> > > USB stick, there is no NAK timeout, because PING is efficient for
> > > handshaking. While problem USB stick will generate NAK timeout
> > > interrupt, we disable PING for this kind of USB device enumeration.
>
> That sounds much better than your original patch, which disabled it
> always. It might even be worth allocating a flag somewhere in the
> usb_device structure to record when ep0 pings seem to misbehave.
>
OK, I will work on it and send out a patch for that fix.
Thanks
-Bryan Wu
> -----Original Message-----
> From: [email protected] [mailto:linux-kernel-
> [email protected]] On Behalf Of Alan Stern
> Sent: Thursday, January 03, 2008 2:29 AM
> To: David Brownell
> Cc: Mike Frysinger; [email protected]; linux-usb-
> [email protected]; Robin Getz; [email protected]
> Subject: Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB
> options normally reserved for OTG
>
> On Wed, 2 Jan 2008, David Brownell wrote:
>
> > On Wednesday 02 January 2008, Alan Stern wrote:
> > > On Wed, 2 Jan 2008, Mike Frysinger wrote:
> > >
> > > > perhaps the code size is arguable as to whether it really
> matters.
> > > > the reason we want it is that we have a USB host controller that
> will
> > > > not work with USB hubs, so we want to make sure the system does
> not
> > > > attempt such things. (yes, such a USB host controller is
> retarded,
> > > > but the decision was out of our hands.)
> > >
> > > Just out of curiosity, how does a host controller manage to avoid
> > > working with external hubs?
> >
> > The transaction translators in external high speed hubs require
> > hosts to issue particular USB transactions. If the host controller
> > doesn't implement the that split transaction support, then it won't
> > be supporting external hubs.
>
> So in theory one could connect a high-speed hub to such a host
> controller and expect it to communicate with high-speed devices. So
> long as no full- or low-speed devices are added there wouldn't be any
> split transactions. It wouldn't be USB-2.0 compliant but it should
> still work.
Perhaps we could reject any low/full speed devices after the USBV
enumeration phase itself. This would need perhaps a flag in the struct
hc_driver which the hub code (that does the enumeration) can check and
reject further enumeration?
Atleast this way we can support high speed devices.
Does all USB Host controller hardware have the ability to disable PING?
> > > 2. Do you remember the PING issue I reported in OMAP list? How do
> you
> > > think of that?
> >
> > Yes, something needs to be done. EHCI might benefit from the same
> > kind of patch, to cope with ill-behaved usb thumb drives.
> >
> >
> > > > I have an idea: the USB_NAKLIMIT0 should be set to some value,
> when we
> > > > got NAK timeout interrupt, we can disable PING. When enumerating
> normal
> > > > USB stick, there is no NAK timeout, because PING is efficient for
> > > > handshaking. While problem USB stick will generate NAK timeout
> > > > interrupt, we disable PING for this kind of USB device
> enumeration.
On Thu 3 Jan 2008 12:04, Richard D pondered:
> Does all USB Host controller hardware have the ability to disable PING?
I think they do. (or at least should)...
http://www.intel.com/technology/usb/download/ehci-r10.pdf
==================
4.11 Ping Control (page 88)
USB 2.0 defines an addition to the protocol for high-speed devices called
Ping. Ping is required for all USB 2.0 High-speed bulk and control endpoints.
Ping is not allowed for a split-transaction stream. This extension to the
protocol eliminates the bad side-effects of Naking OUT endpoints. The Status
field has a Ping State bit, which the host controller uses to determine the
next actual PID it will use in the next transaction to the endpoint (see
Table 3-16).
Table 4–12 illustrates the state transition table for the host controller's
responsibility for maintaining the PING protocol.
Refer to Chapter 8 in the USB Specification Revision 2.0 for detailed
description on the Ping protocol.
===============
I think the musb is just missing the PING/OUT State table, as described in
table 4-12.
I think this is controlled in the ehci driver with:
host/ehci.h:#define QTD_STS_PING (1 << 0) /* issue PING? */
-Robin