10:05 <topi`> I understand there are some issues with the OTG controller in rk3288. Anything that gets connected to usb1 (dwc2) acts sometimes funny

10:05 <topi`> worst of all, I can't get a LTE modem to work in the internal usb slot (mini-pcie)

10:05 <topi`> does not even identify. Is there anything I can do? force the dwc2 to act as a Host permanently?

10:53 <robmur01> topi`: yes, see the "dr_mode" DT property

10:59 <topi`> dr_mode is now "Host" if I look at /sys/firmware/devicetree

11:00 <topi`> usb@ff500000 usb@ff540000 usb@ff580000 usb@ff5c0000

11:00 <topi`> several nodes to choose from. The internal modem bay seems to be at 54000000

11:01 <topi`> Why 4? I thought there are only 2 usb controllers on the rk3288. The host one and the dwc2

11:14 <robmur01> the upstream DTSI shows at least 5 - two DWC2s, the EHCI/OHCI pair, plus an additional EHCI (likely intended for some mildly-specialised purpose)

11:16 <robmur01> yup, datasheet says two hosts, one OTG and one USIC, whatever that is

11:21 <Net147> vicencb: Did you ever try 1280x800 on RK3399? I haven’t been able to get it to work even after applying your latest patch set.

11:28 <topi`> usb 1-1.2: new high-speed USB device number 7 using dwc2

11:28 <topi`> it seems things like USB sticks work just fine with dwc2

11:29 <topi`> robmur01: if I understand correctly, dwc2 is just one kind of USB2.0 controller silicon. The other usb (host) is not dw (DesignWare) then?

11:29 <topi`> anything I connect to it, just works.

11:31 <robmur01> well, technically it might be - Synopsys do license boring "standard" EHCI/OHCI IP as well as their fancy DWC controllers

11:32 <robmur01> note that you have one dual-role DWC2 and one host-only DWC2, which in most board designs are likely to be used for "general-purpose" USB ports

11:33 <topi`> dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason is unknown

11:33 <topi`> this is likely the cause of my problems with this port

11:33 <topi`> or maybe a symptom

11:33 <robmur01> in the reference design the EHCI port tends to be for stuff like soldered-down wifi modules

11:34 <topi`> yeah, the dual-role DWC2 also supplies the OTG port (micro-usb) on the back of the deice

11:34 <topi`> this device has a M.2 slot for a usb-based wifi, and a miniPCIe slot for LTE module

11:34 <topi`> I wish I had the schematics, to be able to peek at which lead goes where

11:35 <robmur01> IIRC on my 3288 the OTG runs one of the type-A ports, the DWC2 host drives the other three via an on-board hub, and the EHCI is unused

11:39 <robmur01> are there any jumpers/switches/etc. on the board to physically mux the USB connection between slots? (i.e. does the board explicitly support using both at the same time or are they just giving you an either/or option of form factors) Sometimes board vendors do that when the number of host interfaces is relatively limited

11:41 <robmur01> otherwise, most weird USB behaviour I would be inclined to attribute to "phy stuff"

11:41 <robmur01> that's pretty much my level of expertise there ;)

11:43 <robmur01> beyond carefully checking regulator/io-domain setup and poking with a meter/scope to check that power is where power should be, of course

11:55 <vicencb> Net147: no, but i've tested 1280x720@50 and it works fine on my 2560x1440 monitor

11:57 <vicencb> in any case, my patch is for enabling resolutions beyond FHD, 1280x800 is less than FHD, so, if it works, it should also work without patches

11:57 <robmur01> vicencb: plenty of "small" resolutions also require odd pixel clocks that don't match those for the standard TV resolutions that upstream currently supports ;)

12:00 <vicencb> i thought that different resolutions had a minimum bandwidth required and not an exact bandwidth, so, any clock speed higher than that odd value should work. Isn't it this way?

12:00 <robmur01> maybe I should dig out the old 1680x1050 monitor where that (and its 1280x1024 mode) were also prominent offenders...

12:03 <vicencb> the patchset i've sent out is stalled because it breaks other SoCs, it would be great if somebody with a variety of HW to test could move it forward

12:03 <robmur01> in terms of the phy configuration alone that's probably true, however I guess that relaxing the existing restrictions there exposes fragility elsewhere in the pipeline

12:08 <robmur01> yeah, if I can find time I'll try to see if https://patchwork.kernel.org/project/linux-rockchip/list/?series=362565 helps for RK3328

13:16 <Net147> robmur01: my HDMI monitor can handle a variety of resolutions that are not in its EDID because the scaler is quite flexible. I just override the EDID with another that has the resolutions I want to test by writing it to /sys/kernel/debug/dri/0/HDMI-A-1/edid_override and then use modetest from Mesa drm git to list and test the different modes supported by the EDID. Clear EDID override afterwards with echo -n reset > /sys/kernel/debug/dri/0/HDMI-A

13:21 <robmur01> Net147: ah, Mesa modetest sounds like exactly the tool I was thinking I'd have to go look for - thanks for the tip!

13:22 <robmur01> last time I tried testing specific modes I was just rebooting the kernel with different "video=..." arguments and seeing how well the console worked :)