USB OTG on Orange Pi PC

[Ondřej Jirman]

Hi,

if anyone wants to play with the OTG port support on Orange Pi PC, you
can try these patches:

https://files.megous.com/orange-pi-dvfs/linux-4.7-OrangePI/usb-otg/

I don't have much time to test it extensively, but it seems to work.

I'm not yet submitting them "formally". This is just a heads up that I'm
doing some work on configuring this and making it work on this SBC.

Early testing is very welcome. :)

regards,
Ondrej Jirman

[boo...@gmail.com]

Nice work.
Sure i will try your path, last time i tried otg i had kernel exception when loading musb driver.
I would like setup usb otg in device mode as g_ether or cdrom drive emulation to loading bootable iso with gpio sw for iso selection yes i dream :)

But for now I try to translate audio codec driver from kernel 3.4,,,removing lot of config from fex file, remove undocumented R-PRCM (0x01f01400) read/Write (seem to be configuration area for current setting to restore after a reboot, not vital..), setup PLL2 (audio_pll) directly in driver since there isn't no clk driver PLL2 for now (I think it's related to I2S driver, and it's a complex clock with multi factor to adjust PLL frequency). For now i just configure it at 24.57Mhz/22.57Mhz and i have succes to have something in /sys/class/device/sunxi_codec/ and /sunxi-pcm-codec/, no kernel exception but no sound card available :(
When i see in sun4i audio driver, there is lot of new code to create card in /dev/snd/...
It's seem I'm lost deeply in nowhere for now, but I will try your work for sure (just one source of kernel opps at the same time!).

[Ondřej Jirman]

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.

Good luck with the audio driver.

regards,
o.

[Michal Suchanek]

Hello,

On 30 June 2016 at 16:44, Ondřej Jirman <me...@xff.cz> 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).

I can ssh into OPi One over usb gadget. This gives way better terminal
capability than serial uart.

Maybe squashing the two code patches or using patch order marks would
be helpful here. When ordered by hash the first two patches are
reversed.

Thanks

Michal

>
> On 30.6.2016 07:17, boo...@gmail.com wrote:
>> Nice work.
>> Sure i will try your path, last time i tried otg i had kernel exception when loading musb driver.
>> I would like setup usb otg in device mode as g_ether or cdrom drive emulation to loading bootable iso with gpio sw for iso selection yes i dream :)
>>
>> But for now I try to translate audio codec driver from kernel 3.4,,,removing lot of config from fex file, remove undocumented R-PRCM (0x01f01400) read/Write (seem to be configuration area for current setting to restore after a reboot, not vital..), setup PLL2 (audio_pll) directly in driver since there isn't no clk driver PLL2 for now (I think it's related to I2S driver, and it's a complex clock with multi factor to adjust PLL frequency). For now i just configure it at 24.57Mhz/22.57Mhz and i have succes to have something in /sys/class/device/sunxi_codec/ and /sunxi-pcm-codec/, no kernel exception but no sound card available :(
>> When i see in sun4i audio driver, there is lot of new code to create card in /dev/snd/...
>> It's seem I'm lost deeply in nowhere for now, but I will try your work for sure (just one source of kernel opps at the same time!).
>>
>

> --
> 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 linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michal Suchanek]

On 30 June 2016 at 20:06, Michal Suchanek <hram...@gmail.com> wrote:
> Hello,
>
> On 30 June 2016 at 16:44, Ondřej Jirman <me...@xff.cz> 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.

>
>>
>> On 30.6.2016 07:17, boo...@gmail.com wrote:
>>> Nice work.
>>> Sure i will try your path, last time i tried otg i had kernel exception when loading musb driver.
>>> I would like setup usb otg in device mode as g_ether or cdrom drive emulation to loading bootable iso with gpio sw for iso selection yes i dream :)

Actually, the cdrom drive emulation is not out of question. You will
need to tune the linux mass storage gadget to identify as CD-rom
rather than USB stick. I wanted this for IDE CD-rom. The systems that
boot from USB CD-rom usually can do USB stick too.

Thanks

Michal

[Ondřej Jirman]

On 30.6.2016 20:21, Michal Suchanek wrote:
> On 30 June 2016 at 20:06, Michal Suchanek <hram...@gmail.com> wrote:
>> Hello,
>>
>> On 30 June 2016 at 16:44, Ondřej Jirman <me...@xff.cz> 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.

Or you can force the mode to peripheral in the dts. That may be a
workaround for now.

regards,
o.

[Michal Suchanek]

On 30 June 2016 at 22:30, Ondřej Jirman <me...@xff.cz> wrote:
> On 30.6.2016 20:21, Michal Suchanek wrote:
>> On 30 June 2016 at 20:06, Michal Suchanek <hram...@gmail.com> wrote:
>>> Hello,
>>>
>>> On 30 June 2016 at 16:44, Ondřej Jirman <me...@xff.cz> 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.

Thanks

Michal

[Michal Suchanek]

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

Thanks

Michal

[Ondřej Jirman]

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.

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?)

regards,
Ondrej

> Thanks
>
> Michal
>

[Michal Suchanek]

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