<Marijn[m]>
kholk @_oftc_kholk:matrix.org: lumag: the message chain seems to suggest that that patch was never applied, but already working in an undocumented way by setting `CHECK_DTBS=y` when building individual dtb files: https://lore.kernel.org/all/20221102214300.309347-1-nfraprado@collabora.com/ (similar to the `VALIDATE_DT=1` proposed by lumag in the patch I linked earlier)
<kholk>
no the patch wasn't applied
<kholk>
I blocked it after learning that there was another way
<kholk>
sorry for the misunderstanding, in case there was one.
<z3ntu>
If you're already looking into this, can you also check if you can make the the processed-schema.json stuff (and some more) build when necessary for CHECK_DTBS=1?
<z3ntu>
That's what I was saying with that it's kind of buggy
<z3ntu>
e.g. dtbs_check target does at the beginning " LINT Documentation/devicetree/bindings" "CHKDT Documentation/devicetree/bindings/processed-schema.json" " SCHEMA Documentation/devicetree/bindings/processed-schema.json" before actually checking anything which rebuilds some db
<mort_>
and the apq8016-sbc.dts[i] doesn't contain a link-name either, even thought those dts files are supposedly correct
<minecrell>
mort_: that looks like a mistake in the .txt, the link-name is supposed to be in the dai-link node, not in cpu/codec
<minecrell>
mort_: sound/qcom,sm8250.yaml is the current version of the bindings and should be correct
<mort_>
I kinda get the feeling that Linux adds support for an SoC but then lets the code and docs for it bit rot
<mort_>
the driver also considers the qcom,audio-routing and qcom,model properties deprecated and only keeps them around for backwards compat according to the code, they've been replaced by audio-routing and model (without the "qcom," prefix), but the docs still use the old names
<minecrell>
mort_: which docs? the file you linked was already removed (replaced with sound/qcom,sm8250.yaml) so you can't really complain that it's outdated :p
<mort_>
I've had to patch the venus driver to make it not print an error for every single frame encoded and decoded on devices with a devicetree without an opp in the venus node
<mort_>
as another example of bitrot for old SoCs
<mort_>
the file I linked is the current file in the 5.10.y stable branch, which is still supported
<minecrell>
yeah but I doubt anyone bothers backporting binding fixes
<minecrell>
I guess the doc you linked was simply wrong from the start
<mort_>
maybe
<minecrell>
mort_: can you not upgrade to latest Linux? 5.10 is pretty old
<mort_>
upgrading Linux is such a monumental task that I'd prefer to land on a somewhat stable target
<mort_>
5.10 is the longest-supported LTS
<mort_>
5.15 goes out of support next year
<minecrell>
well 5.15 is only shorter because gregkh didn't get enough feedback yet that someone is actively going to use/test it
<mort_>
then I'll reconsider if gregkh gets that feedback and updates the support tables
<mort_>
if I wanna jump to an LTS which doesn't have committed long term support I probably wanna wait for 6.1, right? Since that's gonna be an LTS
<minecrell>
There is not ever going to be a long LTS release if no one does what greg asked for in that blog post :p
<minecrell>
but yeah waiting for 6.1 would probably be even better than 5.15
<mort_>
even more reason to stick with the currently longest supported kernel :p
<mort_>
I truly wish we had the resources to have a big kernel team which is in active communication with upstream and can commit to testing stuff and get patches upstreamed and everything
<mort_>
but that's not in the cards right now
<minecrell>
well, getting patches upstreamed could probably reduce the effort for upgrading at least ;)
<mort_>
I'm aware
<mort_>
well, for some
<mort_>
other patches are of the "this obviously has no place in the upstream kernel" type
<mort_>
others, like making venus support devices without an opp in the dts, really ought to be upstreamed
<mort_>
but the current patch just brings back the behavior from before venus cared about opp, and I don't know what the right way would be to support the old behavior on old devices but the new behavior on new devices
<mort_>
there's also the patch to panel-simple.c to change two panel descriptions; one is a simple addition of a display panel, that could be upstreamed, but the other changes a panel description in a way which we need due to other constraints but which makes absolutely no sense upstream
<minecrell>
mort_: if snd_soc_get_dai_name() fails it usually means that the sound-dai you referenced didn't load yet
<mort_>
one adds a driver which last time I checked was stuck in limbo, yet to be merged into upstream linux
<mort_>
it does fail with eprobe_defer, so that tracks
<minecrell>
then you need to look into the &lpass/&lpass_codec/&adv_bridge or whatever you added there
<mort_>
the cpu node uses lpass, which seems okay, I have a &lpass { status = "okay"; } in my dts, the codec node uses lpass_codec and wcd_codec, as far as I can see my dts does exactly the same as the apq8016-sbc.dtsi file when it comes to those
<mort_>
but I don't know whether apq8016-sbc.dtsi is correct to the point that it'd just work immediately on the hardware it's designed for
<Mis012[m]>
mort_: what sad hw are you working on that needs non-upstreamable patches :(
<mort_>
hardware which uses the apq8016
<minecrell>
the apq8016-sbc sound stuff definitely works and is correct in recent Linux versions, not sure about 5.10
<minecrell>
either your dts is wrong, or your kernel config is missing stuff, or something is broken in 5.10
<Mis012[m]>
using apq8016 is probably not the sad part
<mort_>
and there's a leds-qcom-lpg driver we need
<mort_>
the msm8916's venus node doesn't contain an opp, that makes the kernel print a warning for every frame you encode or decode without my patch
<mort_>
so the apq8016 is one of the sad parts
<Mis012[m]>
you can probably add that node
<mort_>
well I don't know what the right voltages are
<mort_>
didn't feel like risking introducing voltages which makes it slowly fry itself over time, so I brought back the old behavior with a patch instead
<minecrell>
mort_: lpg is upstream since 5.19
<Mis012[m]>
you can probably make it "apply" the same voltage that it's already running at
<mort_>
minecrell: oh nice, I'll be able to remove the patch once I move to 6.1 then
<mort_>
I figured there's a good reason why the msm8916.dtsi has the venus node it has, it's not something I really wanna mess with without a deep understanding how the hardware and the driver
<Mis012[m]>
well, you can always add the opp table in the board dts
<minecrell>
never seen that opp problem, maybe it was fixed already
<minecrell>
but I also don't use venus very often
<mort_>
the only reason I even vaguely know what an "opp" is that venus would print to dmesg for every frame encoded and decoded and I had to fix it, someone who knows what they're doing more than me could certainly have found a better solution
<Mis012[m]>
I feel like adding the opp table in the board dts and making it apply precisely they values that it's already running with would be much cleaner than carrying a patch...
<mort_>
you're not wrong
<mort_>
maybe I'll add it to my todo for what to do once I get this sound thing to work
<minecrell>
doesn't look like it was actually backported to 5.10 even though it was marked so
<mort_>
I'm coming from a vendor 4.9 kernel with custom patches, an upstream 5.10 kernel with a backported driver and a couple tiny custom patches is already a much better state than where I was lol
<Mis012[m]>
well, the sooner you start working on getting rid of unupstreamable stuff, the sooner you can start tracking upstream more closely
<mort_>
weeeell
<Mis012[m]>
wouldn't want to write an upstreamable driver against 5.10 just to realize it doesn't apply cleanly to mainline
<mort_>
in my experience devicetree stuff changes quite a lot between releases
<mort_>
so it's not like the old dts will just work with a new kernel either
<Mis012[m]>
what
<mort_>
just stuff being renamed and moved around and address numbers changing and whatnot
<Mis012[m]>
no..........?
<Mis012[m]>
sounds like you're confusing downstream 4.9 with upstream 4.9
<mort_>
oh, I must've hallucinated those weeks then
<Mis012[m]>
downstream has it's own opinions on devicetree
<Mis012[m]>
but a devicetree that works with mainline should also work with newer mainline
<mort_>
I've looked at the upstream kernel and found that there are definitely things I would've had to change even if I was running an upstream kernel
<mort_>
the vendor kernel is relatively lightly patched, all things considered
<Mis012[m]>
arguably it's possibly good that downstream developers don't upstream their bindings because it seem very likely that something really ugly would slip through and become ABI
<Mis012[m]>
>the vendor kernel is relatively lightly patched, all things considered
<Mis012[m]>
lightly patched compared to qcom's downstream you mean...?
<mort_>
no, compared to upstream linux
<Mis012[m]>
that's certainly interesting considering the fact that it's extremely unlikely they didn't use qcom's downstream
<Mis012[m]>
and qcom's downstream is definitely not "lightly patched"
<mort_>
I don't think they were actually
<minecrell>
Mis012[m]: I don't think downstream is very popular for stuff similar to apq8016/db410c
<minecrell>
I also doubt they ported the entire 8916 downstream stuff to 4.9
<Mis012[m]>
and if qcom's code is close to upstream, that means either they wrote good code that could have been upstream with minimal changes (doesn't seem that likely, maybe it's gotten better lately), or the code reviewer let it slip
<Mis012[m]>
minecrell: interesting, maybe these days?
<Mis012[m]>
pretty sure I saw some 8916 projects that screamed downstream
<minecrell>
would expect 3.10 there
<Mis012[m]>
yeah, good point
<minecrell>
at least qcom's 4.9 branches only have 8909/8937/9607/..., which is very close but I still haven't seen 8916 downstream stuff in those
<mort_>
but my dts was based on apq8016-sbc.dtsi, which also doesn't use labels
<mort_>
(or, well, our, I didn't make the dts I'm upgrading from)
<Mis012[m]>
>a lot of headache
<Mis012[m]>
>they literally provided a oneliner to fix it
<minecrell>
Well, the DT compat Mis012[m] is talking about is on binary (already compiled) level, not source level
<minecrell>
the idea would have been that the DTB you built on 4.9 might have mostly worked on 5.10
<minecrell>
without recompiling it
<mort_>
Mis012[m]: imagine the symptom is that initramfs fails to boot.
<mort_>
obviously once you have tracked it down to one commit which changes addresses it's incredibly easy
<Mis012[m]>
do you not have screen/uart console?
<mort_>
but when you're moving from a 2017 kernel to a 2020 kernel and you have nothing to go off of it's not easy
<mort_>
I do
<mort_>
that means I could figure out that my initramfs init wasn't able to mount the filesystem
<mort_>
I put a self-contained shell in initramfs so I could explore the system, so I could find out that there was no node in /dev for the mmc
<Mis012[m]>
how were there no warnings when compiling the dts
<mort_>
but no part of this is easy to debug, even though the fix is to remove a single 0 from the dts
<mort_>
well there weren't
<mort_>
this also isn't something you would even think could be the issue even if you looked at the specific change, since one would assume, if one isn't very well versed in dts stuff, that sdhci@7824000 and sdhci@07824000 refers to the same thing; it's an address after all, not a name
<minecrell>
it's a name after all, not an address
<minecrell>
the address is in the reg property
<mort_>
well it looks like an address
<mort_>
also, an earlier commit had reordered everything, so diff tools between the old and new apq8016-sbc.dtsi were unusable
<minecrell>
it's just a convention to name it like that, the node name has no functional use
<Mis012[m]>
minecrell: arguably the dtc already warns about `@0x`, so it could also detect this...
<mort_>
I know that now but I didn't then
<minecrell>
shrug
<Mis012[m]>
<del>so it was a positive learning experience in the end
<mort_>
I'm not saying an expert kernel developer wouldn't have been able to figure this stuff out, just that it's very non-obvious all of it
<mort_>
and most importantly, it means you have to assume that kernel upgrades mean spending a lot of time on devicetree stuff
<mort_>
(like I was doing back then for the MMC, and like I'm doing now for this sound thing)
<Mis012[m]>
once you upstream the devicetree, that will fix itself
<mort_>
I won't upstream the devicetree
<Mis012[m]>
if you don't intend to upstream the devicetree but you still want to use the latest .dtsi files from upstream, that's a peculiar usecase...
<mort_>
the drivers change, those changes are reflected in stuff like msm8916.dtsi no?
<minecrell>
ideally the driver changes are made in a way that the old version of msm8916.dtsi would also still work
<mort_>
it feels like those dtsi files is the closest thing to a stable interface there are
<minecrell>
it should be usually the case although there are exceptions sometimes
<mort_>
maybe I'm wrong about this and should just copy over the msm8916.dtsi and pm8916.dtsi and whatever from 4.9
<minecrell>
This doesn't really sound great even though that should indeed mostly work
<mort_>
I'm not against the idea of upstreaming the devicetree by the way, but 1) I'm not sure why the kernel would want the devicetree for some random iot-like product and 2) I seriously doubt I have the time
<minecrell>
but there are exceptions for the DT compat so it might as well not :P
<mort_>
once it's working on 5.10 I'm sure 6.1 is out, once it's working on 6.1 I'm sure 6.5 will be out, once it's working there I'm sure 6.10 will be out
<minecrell>
well, once it's upstream it will ideally work with no effort at all on newer kernel versions
<minecrell>
as others will make the necessary changes to the DT for you
<mort_>
but it has to work on the newest kernel before it can be upstrwamed, right? I can't just give them my 5.10 dts can I
<minecrell>
that's right
<mort_>
considering the amount of effort involved with every kernel upgrade it feels hopeless to ever catch up
<Mis012[m]>
>but it has to work on the newest kernel before it can be upstrwamed, right? I can't just give them my 5.10 dts can I
<Mis012[m]>
and that's why you should prioritize getting rid of stuff that can't be upstreamed :)
<mort_>
especially since I'm not just a kernel person, I have other shit to do
<minecrell>
If you want newer kernel versions on long long term it could very well pay off to have it upstream, as the effort to upgrade would be much lower
<Mis012[m]>
yes
<mort_>
it's not that I don't see why it would be nice to have other people maintain the dts for me
<Mis012[m]>
you don't need to forward port anything if it's already upstream
<mort_>
(exactly how I'm not sure, it's not like kernel developers have the hardware I'm working on)
<minecrell>
The testing would still be up to you
<minecrell>
but the part that makes it easier is that the original author would propose the changes, which are probably similar to some device they have access to
<mort_>
we'll see how easy it is to upgrade from 5.10 to 6.1 when that time comes
<mort_>
if it's doable, I'll consider upstreaming it
<mort_>
hell maybe it's worth it to try to upgrade to 6.0 asap
<mort_>
if 5.19 or whatever added the lpg driver that's a pretty big patch we don't have to keep around
<z3ntu>
mort_: 6.1 should become LTS version so probably makes more sense to directly go onto 6.1, even if it's not fully out yet (which it should be in about 4 or 5 weeks)
<Mis012[m]>
mort_: well, ideally you would get rid of non-upstreamable stuff so that you don't ever need to update that
<mort_>
I agree that that would be ideal
<mort_>
whether it's realistic is another question
<Mis012[m]>
well, the only example you brought up seems fixable
<mort_>
there's another thing where we spawn a kthread to do something which really should've been taken care of in user space but where the people who implemented it wanted it to happen earlier in the boot process than after systemd has started spawning units
<mort_>
but it's something I'm already in the process of getting rid of
<mort_>
the only question is, do I need the kernel to do something at all to make a microcontroller happy during early boot or can I remove that code altogether
<mort_>
stay tuned to find out, in a week or two, assuming I can figure out this audio thing
<Mis012[m]>
mort_: I mean... if you really wanted to have it in kernelspace, you could try to spin it as remoteproc /hides
<Mis012[m]>
why do you need a separate microcontroller anyway, don't you have a mostly unused hexagon core
<mort_>
I probably have to figure out wtf remoteproc since some remoteproc thing fails to start at boot according to systemd
<mort_>
the microcontroller drives some stupid LEDs
<Mis012[m]>
uhm, why do you need a microcontroller for that
<Mis012[m]>
sounds like x86 way of thinking...
<Mis012[m]>
"easier to do it with a microcontroller than with ACPI"
<mort_>
almost certainly not, and I don't even want those stupid LEDs
<mort_>
but I'm working with the hardware I have, not the hardware I wish I had
<Mis012[m]>
mort_: well, I did want to make a spec for universal fw interface for turning useless microcontrollers into i2c/spi/gpio controllers :P
<minecrell>
mort_: how long have you already been messing with the kernel upgrade? :p
<mort_>
quite a while, but with other stuff happening in between
<mort_>
the sound thing and the LED microcontroller communication kernel thread thing are the only major parts left
<mort_>
the userspace-visible GPIO numbering change is taken care of by correctly finding the base of the right gpiochip rather than assuming it's at 0, the ad-hoc video4linux encoding and decoding code is replaced with gstreamer, yocto is upgraded to Kirkstone and everything is adapted to the new bitbake, I no longer rely on the vendor kernel patch to
<mort_>
re-number the camera's i2c address, the devicetree changes are accounted for, etc etc
<mort_>
there's a lot of stuff
<mort_>
oh and all kernel patches we had are either replaced with non-patch stuff or forward ported across 5 years of kernel changes
<minecrell>
fun
<minecrell>
you shouldn't use the gpio sysfs at all that requires the base number
<mort_>
the out of tree WiFi driver is replaced with mwifiex, the kernel size has been reduced to fit in the 32M I have available
<Mis012[m]>
mort_: if you can pretend the microcontroller doesn't exist and that works out for you, seems like the best approach wrt that for now
<mort_>
so much stuff
* Mis012[m]
> <@_oftc_mort_:matrix.org> the out of tree WiFi driver is replaced with mwifiex, the kernel size has been reduced to fit in the 32M I have available
* Mis012[m]
suffers physcial pain thinking about the stuff he was supposed to do wrt u-boot
<Mis012[m]>
still need to get around to unfucking that at some point
<Mis012[m]>
but it's 8916, you could use re-boot :P
<mort_>
I could use newer hardware yeah but eh, it's powerful enough to do what it has to
<Mis012[m]>
8916 is the best hw anyway
<minecrell>
mort_: why is it based on apq8016 if you have custom WiFi? Seems pretty useless
<Mis012[m]>
wait, are you telling me there's also an unused arm9 cpu core? 😏
jhovold has quit [Ping timeout: 480 seconds]
pespin_ has joined #linux-msm
pespin has quit [Ping timeout: 480 seconds]
pevik has quit [Ping timeout: 480 seconds]
pespin_ has quit []
Guest69 is now known as frytaped
<mort_>
minecrell: it was found or assumed that the onboard wifi/bluetooth wasn't good enough, I haven't investigated myself
telent has quit [Read error: Network is unreachable]
telent has joined #linux-msm
_lore_ has joined #linux-msm
_lore_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]