10:31 <robmur01> Oh wow, just noticed someone from Rockchip is working on proper upstream TypeC support for RK3399, hurrah!

11:04 <CyReVolt> Nice, I'll gladly forward that to some folks I know will be happy about USB-C support in mainline. :-)

12:43 <jakllsch> robmur01: including DP over Type C?

12:46 <ndufresne2> was my obvious question ^

12:46 <ndufresne2> but if we can do more OTG, its already a win

12:47 <robmur01> jakllsch: specifically DP alt mode: https://lore.kernel.org/linux-rockchip/20250729090032.97-1-kernel@airkyi.com/

12:49 <robmur01> but hopefully finally integrating with the proper TypeC framework instead of the extcon hacks brings whatever else with it too

13:14 <warpme> guys: i want to play a bit with ufs booting on 3576 rock4d. For start i want to use radxa uboot ( https://github.com/radxa/u-boot/commits/next-dev-v2024.10/ ) as it looks it should support booting from ufs. Unfortunately building it not generates .itb image. defconfig is https://github.com/radxa/u-boot/blob/next-dev-v2024.10/configs/rock-4d-rk3576_defconfig Can somebody hint me what is missing in defconfig to get .itb generation?

13:20 <detlevc> warpme: You need to explicitely build the target with downstream. I usually run "ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) spl/u-boot-spl.bin u-boot.dtb u-boot.itb"

13:23 <warpme> detlevc : for mainline uboot i'm using '$(BUILD_ARGS) $(MAKE) $(PARALLELMFLAGS) -C $(WORKSRC) $(PARALLELMFLAGS) ROCKCHIP_TPL=$(TPL) BL31=$(BL31) all' And all works well. Do you believe in radxa (wich is on 2024.10) 'all' not works?

13:23 <rtp> robmur01: that sounds great. I bet it's replacing things like that https://codeberg.org/megi/linux/src/branch/orange-pi-6.11/drivers/usb/typec/typec-extcon.c ?

13:25 <warpme> detlevc: you are right. with explicitly declaring targets it builds :-) thx!

13:26 <warpme> detlevc : btw: are you booting your's rock4d from ufs?

13:27 <detlevc> warpme: Yes, I've been booting from ufs for quite some time

13:28 <detlevc> I'm surprised that it needs the target still for 2024.10

13:31 <warpme> detlevc : accordingly to your exp with ufs booting: will dd idbloader.img and u-boot.itb to ufs dev in the same way like to sdcard be enough to get ufs booting?

13:32 <detlevc> ho sorry, I meant /boot and rootfs are on UFS, bootloaders are still on SPI for me

13:34 <detlevc> but UFS uses 4096 bytes blocks, so they are not written at the same place. The UFS chip should expose multiple areas (some 16 MB, some 8 MB and then the rest), you need to write the bootloaders to one of the small area, but I don;t know which and I never had that working

13:42 <warpme> ah i see you already faced issues i'm facing now :-)

13:45 <detlevc> Yes, but I use a pre-release version of the board, so it has never been clear if it was able to boot from UFS or not

13:47 <warpme> interesting is that uboot reports ufs devices geo with 512 sector size but kernel with 4096. i need to look is it possible to ask kernel to report/use 512 sector size. with this install of os to ufs can be just dd of sdcard image to ufs device (then resize on booted os)

14:03 <detlevc> Not really, the the sector size comes from the chip, so overwriting that would be hard. Also, you can't just copy the sd card to ufs, because the GPT header will not be at the right place (should be in second sector IIRC)

14:03 <detlevc> u-boot seem to say 512 for me too, but will still use 4096 when looking at the GPT

16:25 <mmind00> robmur01: it only took 10 years ;-) , but I really really like a lot of all the recent work they provide ... especially in the graphics area

16:26 <mmind00> robmur01: as I see your name a lot in the arm-smmu commits, do you have a hint what to poke when arm_smmu_device_shutdown() hangs ? ... of course related to the pcie iommus

16:27 <mmind00> (on the rk3588)

16:35 <robmur01> mmind00: almost certainly a clock/power domain which is getting turned off by the client device(s) shutting down first, since SMMUv3 doesn't have RPM support yet (and there's nothing in the DT anyway)

16:36 <mmind00> robmur01: ah, so the problem like stems from that particular board not using pcie at all ... but the smmu being probed and "shutdown"'ed

16:37 <robmur01> if it's built-in and probed before the unused stuff is turned off, certainly

16:38 <robmur01> by that logic, maybe confirm if building it as a module and loading it later hangs in probe :)

16:38 <robmur01> then clk_ignore_unused/pd_ignore_unused

16:38 <mmind00> robmur01: and I could confirm that by accident right now too ... another board had PCIe defer probing (for whatever reason), but the smmu probed ... on reboot, the hang

16:38 <mmind00> after a kernel rebuild and PCIe probing again ... reboot works without hangs

16:39 <robmur01> then RFC patches here: https://lore.kernel.org/linux-iommu/20250616203149.2649118-1-praan@google.com/

16:39 <mmind00> ah ... nice ... the benefits of using mainline ... someone else most likely has had the same problems already

16:40 <mmind00> thanks for that pointer

16:41 <robmur01> although my hunch would be to try slapping "power-domains = <&power RK3588_PD_PCIE>;" on mmu600_pcie straight away - IIRC the platform bus code will then hold it open automatically even if the driver doesn't do RPM itself

16:42 <mmind00> robmur01: tried that already ... somehow didn't help

16:49 <robmur01> ah, might be more subtle then, like maybe one of the clocks that a pcie node claims but the domain itself doesn't

16:50 <mmind00> also I think the pmdomain driver right now only does the enable when handling the domain, but does not keep the clock on afterwards, expecting the user to do its own clk_enable

16:59 <robmur01> Ah, good point, seems it does only enable them for its own transitions in rockchip_pd_power()