09:20 <digetx> hexdump0815: check /sys/kernel/debug/devices_deferred

09:25 <digetx> the "probe of 7001b000.external-memory-controller failed with error -2" should be the reason

09:27 <digetx> I guess you don't have memory freq tables in DT, but soctherm should be made to continue to work in that case, it's a bug

09:28 <digetx> or T210 EMC driver should continue to work, like T20/30 EMC drivers do that

09:34 <digetx> although, seems that should be some other -ENOENT error

09:35 <digetx> are you using DTB of 5.16 kernel?

09:39 <digetx> I also see now that T210 EMC uses emc->nominal, but I don't see where it's assigned, that is strange

09:41 <digetx> tagr: where emc->nominal is assigned?

09:44 <digetx> ah, I see now

09:47 <digetx> and I see now " /external-memory-controller@7001b000: could not get #clock-cells for /i2c@7000d000/pmic@3c/pinmux"

09:51 <digetx> that error doesn't make sense, maybe bootloader patches DTB and corrupts it

11:15 <tagr> yeah, I think depending on the bootloader version it might try to copy some stuff from the bootloader DTB and try to pass that to the kernel

11:15 <tagr> depending on what it will try to copy it'll copy phandles from an incompatible DTB...

11:16 <tagr> kwizart: that "Failed to setup IOMMU" is harmless, it's not actually a failure

11:16 <tagr> it usually just means that no IOMMU was hooked up to the display controller (or whatever device is warns about)

11:53 <kwizart> tagr, right, but isn't it more efficient for dc to have IOMMU ? I'm not sure to know which exact context for sure but I think in one situation the message wasn't present and the display was smooth under wayland (no tearing) another hypothesis was when using CONFIG_IOMMU_DEFAULT_DMA_STRICT (instead of lazy) but I wasn't able to reproduce twice...

12:17 <digetx> IOMMU is always less efficient, but you won't have sparse memory without it

12:23 <kwizart> you mean that without IOMMU one needs to enable CMA allocated and then the IO must be handled (PIO ?) how about DMA ? and tegra SMMU ? btw I was experiencing tearing in the tk1 context (so with nouveau involved), not previous tegra

12:26 <kwizart> I remember to have hard time to request the fedora kernel team to allow some amount of CMA in the fedora kernel, mostly because they were expecting IOMMU to be available for display...but that was few years ago...

12:30 <digetx> CMA will be used automatically if IOMMU unavailable, DMA memory allocations will be contiguous without IOMMU, PIO is unrelated here

12:30 <digetx> you could specify CMA size in device-tree

12:32 <digetx> in general, it's better to make CMA large, it won't waste any extra memory if unused and shared (default)

13:00 <kilobyte_ch> I'm trying to get a ADV7282-M CSI2 Video Decoder running with an Jetson Nano Developer Kit. I built the Kernel and Device Tree manually. If I leave tegra210-p3448-0000-p3449-0000-b00.dts original I see in dmesg that it tries to initialize a imx219. I removed the include for imx477 and imx219 and added an include of a adv7280m dtsi: https://pastebin.com/va8Hqiuc But I don't see anything regarding adv in dmesg.

13:00 <kilobyte_ch> I configured extlinux to load the devicetree with FDT.

13:01 <kilobyte_ch> (Also enabled building of the adv7180 kernel module and updated /lib/modules)

13:01 <kilobyte_ch> modprobe 7180 doesn't yield any error so the module is there. But it also doesn't initialize when modprobing it, so I guess there must be something wrong with the device tree.