On Tue, Jan 4, 2011 at 2:00 PM, Arnaud Patard <arnaud.patard@xxxxxxxxxxx> wrote: > Igor Grinberg <grinberg@xxxxxxxxxxxxxx> writes: > > Adding Matt Sealey in CC:. he's the product development analyst so he > knows the hardware (unlike me). >>>> Also, what ulpi vendor/product id is reported in ulpi_init()? >>> ULPI transceiver vendor/product ID 0x0424/0x0006 >>> Found SMSC USB3319 ULPI transceiver. >> >> SMSC USB3319 does not have either an integrated Vbus switch or Charge Pump, >> For the device connected to that transceiver could work properly, >> there is a need in _external Vbus switch_ , that should be enabled using >> some kind of CPEN pin (can be GPIO). >> This means, that you don't even need to call ulpi_set_vbus(). >> >> Either way, this patch is NAK. >> I think you need to check your hardware (in particular Vbus supply). Hey guys, On the Smartbook at least both USB host ports (H1 and H2) on the board (one port each) are connected directly to 4-port USB hubs (SMSC2514). We don't have anything on there except that connection: the hub should handle VBUS properly. Both ports use an SMSC3317 (just a 3311 with a built in 3.3V supply so the id and behavior should be identical). On the Smarttop H1 is connected to a 4-port USB hub (Terminus FE1.1) with the same configuration. Same PHY. The DR port is connected directly to an ASIX ethernet controller. VBUS seems routed to a test point. I'm curious exactly what the real problem here is: that VBUS is basically not being handled correctly? It should be driven or not? I'm not entirely familiar with the specification. -- Matt Sealey <matt@xxxxxxxxxxxxxx> Product Development Analyst, Genesi USA, Inc. -- 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
