05:49 <Segfault0> hi, does anyone here know much about dsi on rk3588? i'm mainlining the fydetab duo and having a hard time getting the lcd to do anything

05:54 <Segfault0> the panel uses dsc and edk2 was leaving the vop in a state that rkdrm couldn't clean up so i made it reset the vop axi clock before starting up, that cleared up the problems stopping the driver from probing and based on the SYS registers changing it seems to be trying to send out video but the panel is just blank

05:55 <Segfault0> i know rkdrm doesn't support dsi dsc yet so i'm not enabling that, based on past devices i'd expect it to make the panel to at least start up and show a garbled display

05:59 <Segfault0> also if i try to turn off the display from userspace i get a "failed to enter data stream mode" from the dw dsi2 driver, i think that's meant to say command mode but regardless i think that means no data is getting to the dsi controller? not sure

09:07 <mmind00> Segfault0: I guess first check, the backlight likely comes from some pwm ... does that turn on?

09:08 <mmind00> Segfault0: also I guess the panel driver might be of interest

09:08 <Segfault0> backlight is just a pwm-backlight controlled completely separately from the lcd, for some reason bl_power is set to 4 by default so it doesn't come on until i set it to 0 but once i do it turns on as expected

09:10 <Segfault0> panel driver is a himax hx83121a, it doesn't have an upstream driver so i made one from hx83112b, just changed the timings and init sequence to match the downstream kernel on the fydetab

09:10 <Segfault0> good point though i should probably test that it works with a downstream kernel

09:11 <mmind00> Segfault0: and Ijust remembered the most important part of dsi on rk3588: do you have an equivalent of https://source.denx.de/u-boot/u-boot/-/commit/702dc3c0b39a7867d05931e77fbbe2a931dd0793 in your early firmware

09:12 <Segfault0> should do, seeing as the panel works in edk2

09:12 <mmind00> right

15:56 <dsimic> Dex2x: (re: got my A1 kingston today) nice, I hope you'll like it

15:58 <dsimic> pooyam: basically, if you really need an ARM device, either because of the openness of the platform or some of its specific features, then the juice is well worth the squeeze; otherwise, it's better to get an x86_64 box that "just works" in most cases

15:59 <dsimic> though, my recent experience with a couple of Ryzen-based laptops has shown that the whole x86_64 thing is far from being trouble-free

15:59 <dsimic> and you're basically out of luck if the vendor-provided firmware has some issues, which is the case on those laptops

20:31 <Dex2x> I also got my odroid H4 plus :D

20:31 <Dex2x> The store I bought from, is also an official rpi distributor, and what was curious is they would show to pair the scandisk A1 industrial with the rpi

20:32 <Dex2x> dsimic, I also have a few A2 high endurance from lenovo and Xiaomi on their way

21:18 <dsimic> Dex2x: ah, so you're back a bit to the x86_64 town :)

21:20 <dsimic> it's good to know that SanDisk industrial cards are A1-rated, and it's good that they suggest such high-endurance cards

21:20 <dsimic> it's also good to hear that more A2-rated cards are on their way... more options for testing the future patches :)

21:23 <dsimic> I've also ordered a few A2-rated microSD cards

21:30 <Dex2x> well I don't know if the industrial are high endurance? They just seemed to support a larger temp range ?

21:31 <Dex2x> dsimic, as for the X86_64, the one tool I need doesn't support ARM at all, due to directly talking to SATA hardware

21:31 <dsimic> oh, I just went with what you wrote, i.e. "they would show to pair the scandisk A1 industrial with the rpi"

21:32 <dsimic> I actually can't remembed any A1-rated SanDisk industrial microSD cards

21:32 <dsimic> s/remembed/remember/

21:32 <Dex2x> I think they are pairing them with that, so the rpi doesn't toast the card :D

21:32 <dsimic> oh, for sure

23:47 <naoki> I've seen an issue with the ROCK 5 ITX+ (and maybe other RK3588 boards?) where the PCI bus enumeration order changes. Specifically, PCI bus 3/4 (eth0/1) get swapped. Is this a known issue?

23:49 <dsimic> I don't think the enumeration order is guaranteed

23:52 <dsimic> maybe something could be done about that, though; I've already put a little bit of work into implementing some kind of stable numbering for the on-board network interfaces, which is also needed for linking them with the on-board LEDs

23:55 <CounterPillow> correct, enumeration order is not guaranteed and that's the entire reason why stable interface names that don't depend on it were introduced