09:56 <pivi> we have some USB warning on TI AM62, `WARNING: CPU: 0 PID: 2626 at drivers/usb/dwc3/ep0.c:284 dwc3_ep0_out_start+0xcc/0xd4`

09:56 <pivi> https://gist.github.com/dolcini/eeb0e203f066d1d6e955c8f0b99400ae

09:56 <pivi> is this something known? is this something on your todo list?

09:56 <pivi> it's not systematic.

09:59 <pivi> (the logs are running TI downstream Linux kernel, updated at 09.01.00.006)

12:44 <dhruvag2000> @pivi can you try the latest RC8 images once - if this is fixed?

12:44 <dhruvag2000> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-6.1.y-cicd&id=247b2535b24894d5ac7f3d8cfc3b48edb7214cc0

12:52 <pivi> dhruvag2000: we can test, limited chances to have a conclusion, given that the issue is not easy to reproduce

12:54 <NishanthMenon> dhruvag2000: cpu hotplug has nothing to do with above log (which seems around runtime pm implementation)

12:55 <NishanthMenon> dhruvag2000: something around the driver's suspend handler to be specific. looks like some sort of race of clock vs reg access

12:57 <pivi> NishanthMenon: I assume dhruvag2000 wanted me to test 09.01.00.008 tag

12:58 <pivi> not sure about the changes between 09.01.00.006 and 09.01.00.008

12:58 <NishanthMenon> pivi aah ok..

12:58 <NishanthMenon> i have'nt been keeping in touch with tisdk :(

13:00 <wadim_> I was thinking about on how to store multiple DDR timing inside a SPL on a AM62 without blowing up the binary size to much since we are kinda limited here.

13:00 <wadim_> One way would be to store multiple R5 dtbs in OF_LIST. But this includes a big overhead so compression may be needed.

13:00 <wadim_> A lighter version would be to use overlays containing only the memorycontroller node. This generates overlays with up to 9KB. Seems also to be a bit to big.

13:00 <wadim_> Another way I was thinking about is to store only diffs of registers and inject them into the DT before DDRSS probes.

13:00 <wadim_> Any ideas for better solutions?

14:16 <NishanthMenon> vigneshr: ^^ hehe.. same problem we have been scratching our heads on..

14:20 <vigneshr> Neha has been experimenting few things internally... Nothing concrete 😕

14:34 <pivi> We store deltas in other (non-TI) platforms for this kind of memory configuration needs ...

15:10 <dhruvag2000> > limited chances to have a conclusion, given that the issue is not easy to reproduce

15:10 <dhruvag2000> OK, have asked internally.. I wasn't aware of any such issue atleast, but will get back if anyone else has seen this/ is tracking this

15:10 <umbramalison> Hi, I'm creating a BSP for an custom AM57xx board. (u-boot, linux, buildroot). I have a booting solution, but only when I use 4.19.y kernel from TI. I thought AM57xx support was usable in upstream, if that is the general consensus then I would like to explore the issue, but if it's not to be expected, then what options give me the latest source with as little vendor lock in as possible?

19:38 <bryanb> umbramalison: haven't checked buildroot recently on am57x but I've seen v6.7-rc4 booting with whatever yocto builds

19:54 <NishanthMenon> heads for contributors to upstream: https://lore.kernel.org/all/170197172648.2974247.13097453111547800548.robh@kernel.org/ - pivi, rogerq et.al..

20:38 <umbramalison> bryanb, do you think buildroot is a factor? I feel like I just need to marry the kernel source with a configuration. I think the configuration is okay, defconfig == omap2plus. How may I know if versions beyond the documented TI 4.19.94 do work? and how does one know if there is parity with upstream?

20:40 <umbramalison> NishanthMenon, thanks.

23:13 <bryanb> umbramalison: yeah I'm not sure I know how to compare features in mainline vs the vendor tree... Ideally there shouldn't be any. I know test builds are starting to show up on kernel-ci (though I'm having trouble loading that atm)

23:15 <bryanb> buildroot doesn't seem to be carrying anything other than just building the binaries. I doubt it would be breaking anything

23:21 <umbramalison> bryanb, thanks. Also for the sake of correctness, the documented kernel version for AM57 from TI SDK (08.02.01.00) is actually 5.10.164 not 4.19.94, what I said there was confused with phytec's SDK.