System_Error has quit [Remote host closed the connection]
eballetbo has quit [Quit: Connection closed for inactivity]
naoki has joined #linux-rockchip
System_Error has joined #linux-rockchip
<naoki>
Kwiboo: sorry for silly question, xhci driver can handle USB2.0/1.1 devices, ehci can handle USB1.1 devices. so enabling redundant node (e.g. ehci/ohci for xhci controller) in dts can be omitted, right?
<naoki>
should be
<naoki>
for booting time
<naoki>
^about u-boot
<naoki>
I'm not sure about linux, need to check it
<mmind00>
naoki: that's generally way more complex ... ehci only does the usb2 things, while the ohci is doing the usb1 speeds ... that's why they get enabled in bundles
<mmind00>
naoki: and for the xhci on for example the rk3588 it's even more interesting ... usb_host0_xhci and usb_host1_xhci can do all 3 speeds
<mmind00>
they are full dwc3 controllers
<mmind00>
naoki: usb_host2_xhci on the other hand can really only do usb3 speeds ... for that reason for example the rk3588-tiger-haikou board routes all 3 of host0_ehci + host0_ohci + host2_xhci to its "upper usb3 port"
<naoki>
anyway, on u-boot, if xhci handles ehci/ohci, ehci handles ohci, redundant controller can/should be "disabled", right?
<mmind00>
no ... the routing just happens automatically ... i.e. when you disable the ohci controllers you probably won't have usb1 speeds anymore
<mmind00>
naoki: also your xhci controllers will be routed to way different ports on your board ... than the ehci/ohci combos
<naoki>
I can see lower speed devices in "usb tree", but it will not be working?
<naoki>
I misunderstand something...
<mmind00>
i.e. usb_host1_ehci has really _nothing_ to do with the usb_host1_xhci ... they are completely different and supply completely different ports generally
<urja>
yes, you do.
<urja>
(misunderstand, lol.)
<urja>
but yeah you wont see plugged in devices on controllers that you dont have drivers for
<urja>
but there are fun complications ... eg, you can have low speed devices on an EHCI controller... if there's a high-speed hub in between
System_Error has quit [Remote host closed the connection]
<naoki>
well
<naoki>
e.g. radxa-zero-3.dtsi only enables xhci
<naoki>
I can see HS/FS devices in "usb tree"
<urja>
but yeah, depending on hardware XHCI can handle all speeds _or_ it can be plugged into only the USB3 lines of a port (the USB3 data lines vs the USB2/1.1 data lines of a port are basically two mostly independent ports :P)
<naoki>
but I don't have any HS/FS device which can be used in u-boot...
<Kwiboo>
for u-boot I have skipped enable ohci drivers for most board I have submitted to speed up usb enumeration, mostly because storage device will likely be usb 2 or 3 and possible slow speed devices like keyboards is typically not usefull without video
<naoki>
if
System_Error has joined #linux-rockchip
<naoki>
xhci -> USB2.0 hub -> USB3.0 mass storage
<naoki>
which is needed, xhci or ehci?
<urja>
xhci
<urja>
well, if the host controller handling the 2.0 lines on that port is xhci, then you need xhci
<urja>
(and the mass storage will only talk at 2.0 speeds)
<urja>
(just pointing out that that's electrically the same case as XHCI - usb 2.0 hub - usb 2.0 mass storage :P)
<urja>
the 3.0 lines on the storage device go nowhere and it talks 2.0
<naoki>
then I can check "USB2.0 hub -> USB3.0 mass storage", if it work, ehci/ohci can be omitted (in u-boot)
<naoki>
^XHCI ->
<Kwiboo>
naoki: last time I tested a usb3 storage device on the zero-3 devices the orientation of cable was important, there is no support for orientation swithing in u-boot
erg_ has quit [Remote host closed the connection]
<urja>
i mean, you should be able to just look at the device tree for what controllers are enabled, right? ...
<urja>
or like, lsusb in linux
<naoki>
if just looking usb tree is enough, my check is easier
<naoki>
why I mentioned about mass storage device is, on u-boot, it's best one to check it really work
<naoki>
(and I don't have USB2.0/1.1 mass storage ;)
<naoki>
anyway, I should send T-b tag for ROCK 3B first :)
<naoki>
another topic, about dr_mode
<naoki>
"otg" is enough to use gadget on u-boot(e.g. ums), right?
<naoki>
or it needs to be "peripheral"?
<Kwiboo>
naoki: on my 3w a directly attaced Samsung SSD T5 is detected, at usb 3.0 speed when cable is in one orientation and at 2.0 speed when in the other orientation
<Kwiboo>
naoki: otg or peripheral and the port will be used for gadget in u-boot
<urja>
otg if the physical port can do otg (that is, it correctly detects use as a host port and can provide the 5v), peripheral if its peripheral only
<naoki>
thanks. I'm thinking if "otg" can be used for gadget on linux, dr_mode = "peripheral" is redundant
<naoki>
well
<naoki>
many Radxa boards uses Type-A for OTG port ;)
<Kwiboo>
on rock 3b and zero 3w/3w I tested ums and could mount my sd-card content on my host machine, for rockusb I only tested if correct product id is reported and if windows correctly load the rockusb driver
<naoki>
Kwiboo: on u-boot, right? I checked ums and it worked. I'm thinking about Linux now. "dr_mode "peripheral" is required to use gadget function on linux?"
<Kwiboo>
yes in u-boot, I am not sure how to use a usb port in gadget mode in linux, have probably only tested attaching usb storage to the port with dr_mode=otg, and the storage device was detected
<naoki>
Kwiboo: for Type-C OTG port, it's expected result. but we have Type-A OTG port ;) (some of then have host/device switch physically)
<Kwiboo>
u-boot does not relly care about such switch, if the port is wired to the otg controller, it is marked as dr_mode otg or peripheral in DT, then u-boot will load the gadget driver for that port regardless of the switch state, and ums/rockusb cmd works
<Kwiboo>
in linux I remember seeing the port chaning when such switch changed from host to device or back
<naoki>
Kwiboo: yes if there is a host/device physical switch, and dr_mode = "peripheral" is NOT defined, it works dual role by switch
<naoki>
^linuz
<naoki>
oopa
<naoki>
^about physical switch on linux
<naoki>
I think I understand u-boot behavior as you explained
<naoki>
hmm, on linux, Type-C OTG dr_mode "otg" port can be used for gadget. but it doesn't work as HOST...
<naoki>
I guess at least "peripheral" is redundant
<naoki>
dr_mode = "host" seems to be required for Type-C OTG port
<Kwiboo>
naoki do you mean the type-c otg port on the zero-3 boards? I have only used it for power and test ums/rockusb in u-boot, can it also function as a usb host if the board is connected to a hub?
<naoki>
yes, ZERO 3E power/otg port. I have two PD source USB3 hub, it can supply power but linux doesn't recognized usb hub if dr_mode is "otg"(this is not expected result)
<naoki>
if dr_mode is "host", usb hub works, but it disable gadget function(expected result)
<naoki>
I'll check ROCK 3 with host/device physical switch
<Kwiboo>
ahh, that is a use-case I have not tested, for power/otg ports I typically only test gadget mode in u-boot, on remaining usb ports I test if my storage device is detected
<Kwiboo>
and in linux I only test if my storage device can be detected on remaining usb ports
<naoki>
btw, I remembered I have USB1.1 only hub :) but I cannot remember where it is ;)
<naoki>
years ago I bought it just for debugging :)
<naoki>
uh... I made mistake... need to test again :(
stikonas has quit [Quit: Konversation terminated!]