Hello.
Daniel Mack wrote:
I still don't get why USB_OTG_DRV_VBUS exists, as well as the
pulldown flags -- these pulldowns are a part of USB/OTG protocol, so
any fixed setting hardly makes sense...
Hmm. I thought this lets you decide whether you use the internal
pulls or use external ones.
And you were right -- 1.5K Ohm pullups are used on device side to
signal the speed. Host side does use 15K Ohm pulldowns. I've mixed
everything up, so rry about that. :-)
How would the OTG core alter the behaviour
then? Which code would be missing to support it the way the OTG stack
works?
OK, I have got my hands on the OTG spec. 1.3 PDF now -- there's
some difference with the pure host mode WRT data line pulldowns:
<<
5.1.6 Data Line Pull-down Resistance
When an A-device is idle or acting a s a Host, it shall activate
pull-*down resistors on both D+ and D- lines. These resistors shall
be within the range of 14.25 kOhm to 24.5 kOhm (Rpd).
When an A-device is acting as a Peripheral, it shall disable the
pull-down on the D+ line but shall not disable the pull-down on D-
line. Maintaining a pull-down on the D- line prevents the A-device
D- line from floating if the B-device becomes unplugged. An
On-The-Go A-device is allowed to disable both pull-down resistors
during the interval of a packet transmission while acting as either
Host or Periperal.
I don't have the OTG spec. at hand (or in any digital form), and
my
It turned out that I do have it in digital form, on a work PC. :-)
memories of the reading are fragmented ATM... :-/ Will try to gfet
my hands on the printout again...
HNP operates using data line pull up, so I must have misremembered here too.
Well, still not clear about the ID pullup/sampling -- do you
want to be able to suppress that fro the board code too? Without
this, it's basically not OTG anymore.
Could be useful to force host only mode though...
Sorry for the long delay on this. I got distracted for some weeks and
admittedly lost track on this issue a little.
Me too. :-)
Could you rephrase the current status of this from your side again? Is
the code generic enough to go in?
I'm still not sure why USB_OTG_DRV_VBUS flag exists. I think that
DRV_VBUS should be set/reset in upli_set_vbus() unconditionally. Well,
unless there really are cases where you don't want ULPI chip to drive
VBUS neither internally not externally (what it's good for then? :-).
And I also think USB_OTG_DRV_VBUS_EXT should be handled in
ulpi_set_flags() like other settings.
I'd love to bring this to an end finally, and can work on it next week.
Unfortunately, I won't be able to do any more reviewing in the next 2
weeks or so due to vacations.
Thanks,
Daniel
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
