09:15 <krzk> hexdump0815: hey, I don't know what is specific for this HP Chromebook around USB. We would need to compare schematics :).

09:16 <krzk> hexdump0815: The Snow (and Arndale 5250) for example has usb3503 which was poorly connected/designed on Odroid U3 (with Exynos4412) board requiring some weird sequency to start.

09:16 <krzk> hexdump0815: This was only for Odroid X2/U3, not later designs... but maybe this Chromebook has something wrong as well?

09:18 <krzk> I don't recall any particular big issues on USB on the SoC side, more or less it works. I rather expect problem with the hub - if you have one...

09:19 <krzk> I would recommend to compare the uboot from Chromebook (vendor/legacy) and check what is different around GPIOs, regulators and USB

10:50 <mszyprow^home> hexdump0815: I didn't check the uboot dts yet, but it sounds like a missing power supply for the usb ports. the kernel dts has some custom 'samsung,vbus-gpio' property defined, make sure that uboot also handles it

10:51 <mszyprow^home> hexdump0815: also check which regulator is used for supplying +5v to usb ports, maybe it is turned off by default in uboot

10:51 <mszyprow^home> hexdump0815: this should be quite easy to check - just plug some stupid usb light/fan and check if it works when uboot is started

12:24 <hexdump0815> mszyprow^home: i already tried that and just forgot to mention it before - the usb ports have power in u-boot, so that seems to not be the problem

12:25 <hexdump0815> would comparing the snow and spring kernel boot output for usb help in any way? in the kernel usb works perfectly fine

12:46 <mszyprow^home> hexdump0815: how many usb ports does the sping have?

12:47 <mszyprow^home> hexdump0815: from comparing kernel's dts I see that spring doesn't have usb 3.0 port (dwc3 and drdphy)

12:52 <mszyprow^home> hexdump0815: you may also check if usb start; usb stop; usb start; help in uboot

12:53 <mszyprow^home> hexdump0815: could you provide the output of usb -t from spring?

13:50 <nergzd723[m]> hey, all! not sure if the Matrix bridge works correctly yet, but here I am. I want to ask some questions about Exynos4412 and Galaxy SIII in mainline kernel.

13:55 <mszyprow^home> nergzd723[m]: how can we help you?

13:59 <nergzd723[m]> oh hey, so it actually works :D

14:00 <mszyprow^home> at least it looks so :)

14:01 <nergzd723[m]> I've been running Linux on S3 yesterday, and I've noticed some strange issue with panel. I don't know how to describe it, perhaps a video could explain it better, but I don't know if it will make it through the bridge

14:01 <nergzd723[m]> basically, the frame order is quite wrong, and it doesn't even draw correctly in some cases

14:02 <mszyprow^home> you would need to upload the video somewhere and paste a link

14:03 <nergzd723[m]> And it gets more interesting than this, I've been experimenting with the kernel on yesterday night, it was completely fine, but as I turn it on today, the panel looks quite bad, it's turning off and on(even in recovery), and there are some artifacts. I'm not sure what is it, and what could've possibly caused it.

14:04 <nergzd723[m]> I've been using a pmOS fork of the kernel, it's basically upstream with some patches to boot with Android bootloader, I think

14:09 <mszyprow^home> nergzd723[m]: frankly I have no idea, never observed such thing

14:09 <nergzd723[m]> https://drive.google.com/file/d/10zCTZp3sjg78zR9hRbcmVOhz11rvy2mk I've uploaded the video on the Google Drive, hope it's fine

14:10 <mszyprow^home> nergzd723[m]: I've never seen such issue

14:10 <mszyprow^home> nergzd723[m]: but I'm not sure if it is kernel related

14:10 <mszyprow^home> nergzd723[m]: have you tried with older/previous release (the one when it worked fine)?

14:11 <mszyprow^home> nergzd723[m]: maybe it is a matter of something changed in the userspace?

14:11 <nergzd723[m]> I can confirm that it is/was completely fine and non-jittery in recovery mode BTW.

14:12 <nergzd723[m]> mszyprow^home the rendering issue, maybe. I did not test many userspace things, I've only been running Wayland compositors such as kwin and wlroots and I've observed this rendering issue on both.

14:13 <nergzd723[m]> hm, which previous release? it's always been like this(jittery, wrong frame order, etc.) for me.

17:26 <hexdump01> mszyprow^home: the spring has two usb ports - did you mean "usb tree" with "usb -t" - that just shows the ehci and the xhci controllers - start, stop, start etc. does not help

17:27 <mszyprow^home> hexdump01: if it has 2 usb ports then I'm really curious how they are connected

17:28 <mszyprow^home> hexdump01: afair 5250 has usb phy for ehci with just one port

17:28 <mszyprow^home> that would mean that there is a hub there

17:28 <mszyprow^home> lsusb -t

17:28 <mszyprow^home> this would show the topology

17:30 <mszyprow^home> xhci listed by the uboot should be ignored, as what I see from kernel's dts, it is not used

17:36 <hexdump01> mszyprow^home: yes - usb tree shows a hub for both ehci and xhci each

17:38 <hexdump01> mszyprow^home: lsusb -t shows both ports on the same hub, which is connected to s5p-ehci/3p using the legacy chromeos kernel

17:39 <mszyprow^home> hexdump01: okay, then maybe one has to figure how to enable or reset that usb hub

17:39 <mszyprow^home> no other idea for now

17:40 <hexdump01> mszyprow^home: thanks a lot so far - in case you have any patch or so in mind, which i could try, please let me know

17:44 <hexdump01> mszyprow^home: i just booted mainline and there the usb ports are connected to exynos-ehci/3p and are working

17:49 <hexdump01> mszyprow^home: i just test booted my snow - there the usb2 port is connected the same way in the kernel and for that "usb tree" shows connected devices properly to the ehci port

17:50 <hexdump01> mszyprow^home: due to the fact that it is working in the kernel, would this mean that the information should somehow be in the mainline kernel spring dts?

20:34 <mszyprow^home> hexdump01: which uboot do you use to boot mainline kernel on spring?

20:35 <mszyprow^home> hexdump01: if you use vendor uboot, then maybe it switches some gpios to enable usb hub, so it works fine then in Linux

20:35 <mszyprow^home> hexdump01: did you check if usb works in vendors uboot?

20:51 <hexdump01> mszyprow^home: i'm booting the mainline kernel either via mainline u-boot (chainloaded as kpart fake fit image) or directly via kpart fit image, so nothing really inbetween which might switch gpios - i can give the vendor u-boot a try, that is a good idea