09:55 <tolszak> narmstrong: Hello, could you please let me know if there is something I can do, debug etc to find the cause of detecting the screen on odroid c2?

09:58 <narmstrong> hi, you can try to boot with kernel cmdline "drm.debug=0x3f"

10:20 <tolszak> narmstrong: That's the boot log https://dpaste.com//F7FZ9PDQQ

10:21 <tolszak> That's the XOrg.log http://dpaste.com//G9DSM3L89

10:22 <tolszak> narmstrong: dri state: http://dpaste.com//HVNJ8AY8H

12:09 <tolszak> narmstrong: /sys/class/drm/card1-HDMI-A-1/status show connected status but it is /sys/class/drm/card1-HDMI-A-1/enabled shows "disabled"

13:09 <narmstrong> tolszak: can you disconnect and reconnecte the hdmi cable and cat /proc/interrupts ?

13:38 <tolszak> narmstrong: I'm sorry my client didn't show me notifications. Doing it right away

13:39 <tolszak> narmstrong: before replug http://dpaste.com//5TSKELXHJ

13:41 <tolszak> narmstrong: after replug: http://dpaste.com//E3MN9N4V7

13:44 <narmstrong> ~1000 interrupts is way to much !

13:44 <narmstrong> can you try another cable ?

13:45 <tolszak> Sure I have plenty

13:47 <tolszak> narmstrong: second cable: http://dpaste.com//9NQ465QAJ

13:52 <tolszak> narmstrong: Second cable was long (like 3 meters) and screen doesn't blink.

13:52 <tolszak> third cable: http://dpaste.com//A56T6LTUJ

13:52 <tolszak> with first and third screen looks like is initialized but after couple of seconds it shows no hdmi signal. But definitely sbc does something as screen wakes up.

13:53 <tolszak> With long cable it didn didn't waker

13:53 <tolszak> With long cable it didn't wake up

13:56 <narmstrong> weird, looks like the HPD is not stable

14:04 <tolszak> narmstrong: I've checked the other odroid c2 I have. the same issue

14:04 <tolszak> narmstrong: those devices are from 2018, but I don't think there was updater hw since then

14:12 <narmstrong> :-/

14:12 <narmstrong> can you check an armbian image ? maybe there's a fix missing

14:23 <tolszak> Sure

14:36 <tolszak> narmstrong: Those are interrupts from armbian: http://dpaste.com//E2TZFKQJE , screen does work.

14:38 <narmstrong> Weird I’ll have a look at the armbian patchset

14:42 <tolszak> narmstrong: I'm checking one more thing. For n2 plus I needed to compile 0001-drm-bridge-display-connector-implement-bus-fmts-call even for 5.15 kernel. I mean I removed max and min version from the patch. The comment from a few motnhs ago is fix black screen issue

14:43 <tolszak> narmstrong: Will let you know

14:49 <tolszak> narmstrong: Works! Damn. I'm sorry, I checked vanilla meta meson not the copy I have. The only difference is this: http://dpaste.com//9EXU2LWAJ

14:50 <tolszak> narmstrong: I mean the X doesn't start still, but the screen is not off and I can see cursor.

14:50 <tolszak> narmstrong: And yocto splash was visible.

14:51 <narmstrong> ok indeed, what branch is it ?

14:51 <narmstrong> my fixup attempt is wrong anyway, but this patch should'nt be needed anymore, did you update poky recently ?

14:52 <tolszak> kirkstone

14:53 <tolszak> narmstrong: the last commit was from 12th of Sept. I use kirkstone-4.0.4

14:54 <tolszak> I will try new one

16:02 <tolszak> narmstrong: Updated poky works with vanilla meson. Although X11 doesn't start still. It is not a problem for me though. I don't use X11. If you would like to have some more logs please let me know.

16:29 <narmstrong> tolszak: X11 doesn't load all all boards or only on the C2 ?

16:30 <tolszak> narmstrong: I think I tried 4.0.4 amlogic image sato on n2. But it was couple of months ago. I can check it if you want.

16:31 <tolszak> narmstrong: Actually I will check it tomorrow morning and let you know. I already have the odroid c2 bits cached and n2 should be almost the same.

16:32 <narmstrong> tolszak: ok thanks, if X11 on n2 doesn't boot, I'll need to fix that

16:33 <tolszak> narmstrong: I mean devices boots, there is also cursor on screen, it's just there is error from X11 that no screen available or something

16:38 <mkorpershoek> narmstrong: I've worked a little on "Port USB OTG to use Driver Model dwc2_otg instead of legacy in board_usb_* functions in mach-meson".

16:38 <mkorpershoek> I'm testing as following:

16:38 <mkorpershoek> 1. Halt in U-Boot

16:38 <mkorpershoek> If you have some time, I'm looking for suggestions.

16:38 <mkorpershoek> 2. => fastboot usb 0

16:38 <mkorpershoek> 3. Observe board being listed from host

16:38 <mkorpershoek> 4. hit Ctrl-c in U-Boot shell

16:38 <mkorpershoek> 5. Observe board disconnect from host

16:38 <mkorpershoek> With CONFIG_DM_USB_GADGET=y, this no longer happens. From what I observe, this is because both the usb glue

16:38 <mkorpershoek> (dwc3-meson-g12a) and the udc driver (dwc2-udc-otg) call generic_phy_init(). (for phy@3a000)

16:38 <mkorpershoek> Because of this double generic_phy_init() call, the usage count of the USB phy is 2, and when we Ctrl-c in U-Boot

16:38 <mkorpershoek> to halt fastboot, generic_phy_power_off() does not *really* powers off the phy.

16:38 <mkorpershoek> This is because dwc3_meson_g12a_remove() is not called (only dwc2_udc_otg_remove() is called).

16:38 <mkorpershoek> In my opinion, it's a little odd that both the glue driver and the udc driver are owners of the phy.

16:38 <mkorpershoek> dwc3-meson-g12a is probed because it's a parent device of dwc2-udc-otg (usb@ff400000), but on removal of dwc2-udc-otg,

16:38 <mkorpershoek> we don't remove dwc3-meson-g12a.

16:38 <mkorpershoek> The "fix" so far i've found is to let dwc2-udc-otg handle the OTG phy (phy@3a000) and

16:38 <mkorpershoek> let dwc3-meson-g12a handle the other PHYs. but that seems kind of wonky.

16:42 <narmstrong> mkorpershoek: thx for the status, let me check something

16:42 <narmstrong> u-boot usb was a little bit wonky

16:42 <mkorpershoek> if it is of any help, my (wip) branch is here:

16:42 <mkorpershoek> https://gitlab.baylibre.com/baylibre/amlogic/atv/u-boot/-/commits/mkorpershoek/wip-meson-dm-usb-debug

16:44 <narmstrong> on linux, the support is the same, but to exit gadget otg switch is done to go back to host

16:44 <narmstrong> I suppose this isn't done right ?

16:46 <mkorpershoek> no. dwc2_udc_otg_remove() just deletes the gadget and some other resources (reset, clk, phy)

16:46 <narmstrong> how is mode switching supported now since the u-boot phy interface doesn't support to setup mode ?

16:47 <narmstrong> I'm surprise you get gadget without calling `dwc3_meson_g12a_force_mode(dev, USB_DR_MODE_PERIPHERAL);`

16:48 <narmstrong> oh I know why, it's because dr-mode is set to peripheral on the vim3

16:48 <narmstrong> without proper usb role switching implemented on u-boot like the linux, this won't work

16:50 <mkorpershoek> https://dpaste.com/4E7W9KW7Z is a (verbose) log. dwc3-meson-g12a being a parent pf dwc-udc-otg it gets probed as well

16:50 <mkorpershoek> /s/pf/of

16:53 <mkorpershoek> I have not looked much into mode switching for now. I wanted the basic "=> fastboot, Ctrl-c" to work reliably first (i.e. host enumerates and detects a gadget disconnection)

16:53 <narmstrong> yep so today it works because the usb_board_init() calls dwc3_meson_g12a_force_mode(PERIPHERAL), and then usb_board_cleanup() calls dwc3_meson_g12a_force_mode(HOST) and this does the trick

16:54 <narmstrong> and for GXL, dwc3_meson_gxl_force_mode() calls phy_meson_gxl_usb2_set_mode() into the PHY

17:00 <mkorpershoek> hmm. the issue with CONFIG_DM_USB_GADGET is that it's dwc2_udc_otg_remove() that's called when usb_gadget_release() is called

17:02 <mkorpershoek> are you suggesting that I should call dwc3_meson_g12a_force_mode(HOST) in dwc2_udc_otg_remove() for g12a based boards? seems weird/hacky

17:04 <narmstrong> well DM_USB should implement a sort of USB role switch

17:04 <narmstrong> either when using usb host or usb gadget

17:05 <narmstrong> so by switching to gadget when trying to setup a gadget then setting it back like before when stopping, and the reverse for usb host comments