<DC-IRC>
[Discord] <c0rnelius77> ``` but i suppose it doesn't matter.
<DC-IRC>
[Discord] <Tonymac32> yeah I just wonder how the dtsi --> dts logic is improved by throwing dtso's in there
<DC-IRC>
[Discord] <Tonymac32> for us it makes sense because we can enable/disable random peripherals at boot, but this seems like just a confusion layer
<DC-IRC>
[Discord] <viraniac> its just another file extension that is used for creating device tree overlays in the kernel tree
<DC-IRC>
[Discord] <c0rnelius77> doesn't seem to care about the dtsi at all.
<DC-IRC>
[Discord] <c0rnelius77> @viraniac right
<DC-IRC>
[Discord] <Tonymac32> Neil said they're *applied* at build time
<DC-IRC>
[Discord] <Tonymac32> so what is the point of that?
<DC-IRC>
[Discord] <viraniac> As far as I know thats not true
<DC-IRC>
[Discord] <viraniac> I renamed sunxi overlays to use dtso extension around 6.5 version
<DC-IRC>
[Discord] <viraniac> they are not applied at build time
<DC-IRC>
[Discord] <viraniac> just are mapped so that dtso is converted to dtbo
<DC-IRC>
[Discord] <c0rnelius77> If I'm reading that Makefile correctly `meson-g12a-fbx8am-brcm-dtbs := meson-g12a-fbx8am.dtb meson-g12a-fbx8am-brcm.dtbo` Its dependant on that dts being compiled.
<DC-IRC>
[Discord] <c0rnelius77> I could of course be way off, but then why even put that there?
<DC-IRC>
[Discord] <Tonymac32> yeah I wonder if this got documented somewhere what the reasoning is
<DC-IRC>
[Discord] <viraniac> That just saying that it would built two files, one dtb and one dtbo. The source for dtb will be the dts file and source for dtbo will be dtso file
<DC-IRC>
[Discord] <c0rnelius77> I guess we need the docs.
<DC-IRC>
[Discord] <Tonymac32> there isn't any kernel support for applying run-time overlays as far as I know, so having overlays in the kernel seems odd.
<DC-IRC>
[Discord] <c0rnelius77> well one can apply overlays using extlinux. no special magic there.
<DC-IRC>
[Discord] <viraniac> kernel stance is that overlays needs to be applied at boot time by the bootloader
<DC-IRC>
[Discord] <viraniac> they were never against the idea in general. Just says its too dangerous to apply them at runtime
<DC-IRC>
[Discord] <Tonymac32> yes of course, like I said, but it raises a question of why make them the kernels problem to maintain
<DC-IRC>
[Discord] <Tonymac32> it isn't Linux kernel's issue if a TV box grade vendor can't manage to use a single Wifi chip 😉
<DC-IRC>
[Discord] <c0rnelius77> BPI has a hat 'of sorts' that also provides WIFI options. rtl8822cs sdio actually. So in theory i suppose this could also be applied within this new feature.
<DC-IRC>
[Discord] <Tonymac32> yeah, can't wait to see the new director structure and flood of useless crap the maintainers get subjected to on this one
<DC-IRC>
[Discord] <Tonymac32> 200 million source files in the dts folders 😄 😄
<DC-IRC>
[Discord] <c0rnelius77> my thoughts too
<DC-IRC>
[Discord] <c0rnelius77> They should designate an overlay directory and create caveats in the Makefile.
<DC-IRC>
[Discord] <Tonymac32> Krzysztof Kozlowski was asking why not just a new board dts, which would be my knee-jerk reaction
<DC-IRC>
[Discord] <Tonymac32> anyway, should be interesting to watch unfold
<DC-IRC>
[Discord] <c0rnelius77> indeed
<DC-IRC>
[Discord] <viraniac> Is there a guide on how to migrate from proprietary mali kernel driver to panfrost? I am trying to get panfrost working on vim1s. I have a dts that kind of works in sense that panfrost driver starts to load. But it causes kernel oops when the driver tries to reset the gpu - https://paste.armbian.com/gocubayota.less. The current dts node I have is https://paste.armbian.com/pirinapona.m
<DC-IRC>
[Discord] <viraniac> I have tried different values for reset. None have worked till now and the driver always causes kernel oops during gpu reset. Need some suggestions on how I can determine the value to use for reset