11:04 <indy> hi all, tegra2 still no 3d hw support?

11:05 <indy> digetx, kwizart ^^

11:05 <indy> tagr, ^^ :)

11:05 <indy> kusma, ^^

11:16 <kwizart> indy: no, maybe linux 5.15-rc will have some bits needed to start one as I understand

11:17 <kwizart> digetx: I've reverted https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=7917e90667bc8dce02daa3c2e6df47f6fc9481f7 (and maybe also https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=6f8d39a8ef55efde414b6e574384acbce70c3119" and I've recovered usb-net support on top of current grate

11:18 <kwizart> digetx: actually here is the exact revert I've made (git revert needed to be resolved) https://paste.centos.org/view/72c3f7aa

12:30 <digetx> m4t: you could try to bisect the drivers/usb

12:30 <digetx> indy: we're slowly working on it

12:44 <digetx> kwizart: please run today's most recent grate kernel, check usb-net, unplug usb cable for 15+ seconds and show me kernel log with the new "tegra-phy c5008000.usb-phy: debug: ..." messages

12:45 <digetx> *unplug and plug back usb

12:50 <indy> digetx, does it require some builtin config options or are those changes compilable using out-of-tree approach?

12:53 <digetx> what "it"?

12:54 <indy> that 'what is slowly worked on' :)

13:02 <kwizart> compilation of current grate in progress

13:32 <digetx> kwizart: thanks

13:33 <digetx> indy: could you please rephrase the question

13:33 <m4t> digetx: i'd need to bisect upstream next though yeah?

13:34 <digetx> doesn't matter, either upstream next or grate kernel

13:34 <m4t> how can i bisect grate if it's always rebased and push -f?

13:35 <digetx> it's based on upstream next

13:35 <m4t> yeah, i just couldn't do it with the patches on top

13:35 <digetx> the offending commit should be in upstream

13:35 <m4t> so you say ;)

13:36 <m4t> i'm sure it is

13:36 <indy> digetx, if work for tegra2 3d support, which you slowly work on, is compilable out-of-tree as modules or are there changes which needs to compile whole kernel

13:46 <digetx> you could use upstream kernel

13:49 <digetx> upstream kernel driver has performance and stability issues, certain kernel configurations may not work at all, but in general it works as a proof-of-concept driver from 2013, now we need a real driver if we want to be serious about 3d support

13:53 <digetx> majority of work related to 3d still needs to be done in userspace

13:54 <kusma> indy: Not officially at least, no. We have all the bits and pieces, but lack time to put it all together into a properly working mesa-driver.

13:54 <kusma> In particular, making the shader-compiler backend is the current blocker.

13:55 <digetx> we mostly could develop kernel and userspace separately, syncing them together periodically

13:57 <digetx> indy: if you you want to try to work on 3d driver, then upstream kernel should be good enough as-is for the starter

14:02 <m4t> i saw a similar issue with sunxi/orange pi zero h5 a couple years ago with usb audio

14:03 <m4t> disabling frequency scaling fixed it. but it did not become *completely* unresponsive at the time, but very high cpu load

14:05 <digetx> it's likely to be a software deadlock problem in yours case

14:16 <digetx> DavidHeidelberg: I enabled USB OTG support for nexus 7 2012 and it required smb driver changes; I see that 2013 already had OTG dr_mode in device-tree, but was it working?

15:56 <kwizart> digetx: finally, caught by various issues: here is the dmesg output with usb-net unplugged and replugged seems like there is an interesting message... https://paste.centos.org/view/9f683d96

15:58 <kwizart> digetx: also I've experienced a strage issue on a previous kernel, but not sure which grate+patches reverted or not was that run https://paste.centos.org/view/95cdbe85

16:02 <digetx> kwizart: I see that you disconnected USB "USB disconnect, device number 5", but then nothing happened

16:04 <digetx> I don't see how the reverted code change may affect anything

16:05 <kwizart> digetx: in the first paste: disconnected, then asix 2-1.3:1.0 eth0: Failed to write reg index 0x0000: -19

16:06 <kwizart> I've disconnected it, then reconnected, then disconnected it again

16:06 <digetx> that error should be okay since USB has gone already

16:07 <digetx> I see only one disconnect

16:07 <kwizart> well sounds like something was pending until the asix driver was told to be removed

16:08 <kwizart> there are two disconnects in the first paste

16:08 <kwizart> [ 54.921266] usb 2-1.3: USB disconnect, device number 4

16:08 <kwizart> 1107.080479] usb 2-1.3: USB disconnect, device number 5

16:08 <digetx> ah, right

16:09 <digetx> so usb itself works

16:09 <kwizart> nope, or not fully enough asix 2-1.3:1.0 eth0: Link is Down

16:10 <digetx> usb controller works, but apparently the asix driver not

16:11 <digetx> have you double checked that the reverted code indeed helps?

16:13 <kwizart> digetx: I can double check, the second paste might indicate what's happen then as I think I've experienced the isr "irq nobody cared" with the revert

16:14 <kwizart> maybe it broke something else that made the device to work as a side effect

16:14 <digetx> ah

16:22 <digetx> yes, the interrupt needs to be corrected

16:22 <digetx> it's enabled at a wrong time

16:34 <digetx> kwizart: pushed update with the fixed interrupt, please give it a try

16:46 <leanderglanda[m]> <kusma "indy: Not officially at least, n"> When 3d hardware acceleration is relevant to us Surface RT people, someone may invest some time. But I can't promise anything.

16:47 <kusma> leanderglanda: That's great to hear.

17:41 <kwizart> digetx: indeed reverting my previous commit doesn't help anymore, might have something else, trying random boot

17:50 <digetx> kwizart: have you tried to revert drivers/net/usb/asix* commits?

17:50 <digetx> they are the main culprit

21:28 <DavidHeidelberg> 2013 - I assume not digetx

21:31 <digetx> looking at downstream smb345 driver, it should work using a DT change similar to 2012 + assuming that qcom usb controller driver indeed supports otg