On 1 July 2016 at 17:57, Ondřej Jirman <[email protected]> wrote: > > > On 1.7.2016 13:19, Michal Suchanek wrote: >> On 1 July 2016 at 13:02, Michal Suchanek <[email protected]> wrote: >>> On 30 June 2016 at 22:30, Ondřej Jirman <[email protected]> wrote: >>>> On 30.6.2016 20:21, Michal Suchanek wrote: >>>>> On 30 June 2016 at 20:06, Michal Suchanek <[email protected]> wrote: >>>>>> Hello, >>>>>> >>>>>> On 30 June 2016 at 16:44, Ondřej Jirman <[email protected]> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb >>>>>>> phy code path for phy0. So I believe it was untested, >>>>>>> because I didn't find any dts file that would use phy0. >>>>>>> >>>>>> >>>>>> This WorksForMe(TM). >>>>> >>>>> There is still small problem left. When I boot with the USB cable >>>>> connected I have to disconnect and reconnect the cable to get the >>>>> gadget working. >>>>> >>>> >>>> Good to know, I'll test this case. It will probably be something around >>>> the iddet handling during phy0 initialization, which leads to the >>>> connected cable being treated as OTG, which would turn the usb port into >>>> host mode. You can verify that by looking into sysfs where there's an >>>> attribute that tells the current mode (peripheral / host). I don't >>>> rember where exactly it could be found. >>>> >>> >>> This is interesting. The USB gadget works (from the start without >>> reconnecting) >>> with one PC + hub and fails with other PC + hub. Both pretty much 100% >>> >>> Ironically the broken hub provides sound voltage above 5.1V and the working >>> one should give about 4.75V given its 0.2V drop from the board power level. >> >> For the record >> >> /sys/devices/platform/soc/1c19000.usb/musb-hdrc.1.auto/mode is >> b_idle when gadget is broken >> b_peripherial when gadget is working > > Hi, you may try adding printks to sun4i_usb_phy0_id_vbus_det_scan in > phy-sun4i-usb.c inside the if (id_notify) and if (vbus_notify), and try > if you can observe any differences between the two hubs in dmesg output.
Hello, I added the debug prints and now cannot reproduce the b_idle state. This somewhat contributes to my suspicion that this is a race with delivering the initial interrupt. Also the debug prints show that the first (and only) irq is fired when the phy is not set up: [ 1.546488] phy phy-1c19400.phy.0: usb phy0 handling irq [ 1.599174] phy phy-1c19400.phy.0: usb phy0 init missing [ 1.632560] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1 [ 1.632569] phy phy-1c19400.phy.0: usb phy0 handling id_notify [ 1.632678] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1 [ 2.632988] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify [ 2.747815] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1 [ 2.747824] phy phy-1c19400.phy.0: usb phy0 handling id_notify [ 2.747833] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1 [ 3.748917] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify No more messages are logged even unplugging and replugging the cable. Also it seems that the detection depends on something dynamically fabricated in the irq handler rather than examining the static phy state. So if the interrupt is handled before musb is set up it may only see the static state which is not all that useful. > > Or first, I'd suggest to add unconditional "return true" to > sun4i_usb_phy0_poll, if that fixes anything. This will enable polling on > the iddet gpio. (Perhaps gpio interrupts are not very reliable?) That sounds like a good plan. However, it does not change anything. Events are properly generated on connecting and disconnecting an OTG cable. Connecting and disconnecting peripherial cable does nothing in the phy at all. It does change something somewhere and the gadget starts working, though. Finally, I have seen the gadget broken with phy mode reporting b_peripherial rather than b_idle. In one state the gadget interface is up, has proper IP address set up, and packets don't go through it. On the other side of the USB cable there is no trace of the gadget interface. No interface, nothing in lsusb. This particular state turns out to be a cable problem. The springs holding the cable in the micro usb socket are worn down and it may have bad contact. Surprisingly, replacing the cable leads to another error state which is pretty much what I have seen initially with the bad cable in b_idle state: The interface is properly set up on both ends. I can see ARP requests going from H3 on the other side, replies are sent, and never seen on H3. Here is a comparison of the broken and working state In the broken state there is extra "init missing" message which is generated in the early return branch. The amount of events processed in phy seems the same but the different init ordering possibly affects something else as well. Will try to add prints to musb later. Thanks Michal [ 1.553534] phy phy-1c19400.phy.0: usb phy0 handling irq [ 1.603051] phy phy-1c19400.phy.0: usb phy0 init missing [ 1.649140] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1 [ 1.649148] phy phy-1c19400.phy.0: usb phy0 handling id_notify [ 1.649278] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1 [ 2.649951] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify [ 2.765006] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1 [ 2.765015] phy phy-1c19400.phy.0: usb phy0 handling id_notify [ 2.765024] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1 [ 3.765885] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify [ 1.546315] phy phy-1c19400.phy.0: usb phy0 handling irq [ 1.616561] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1 [ 1.616571] phy phy-1c19400.phy.0: usb phy0 handling id_notify [ 1.616637] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1 [ 2.616900] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify [ 2.705023] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1 [ 2.705032] phy phy-1c19400.phy.0: usb phy0 handling id_notify [ 2.705040] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1 [ 3.705918] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
