ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
mvaittin has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
Turingtoast has quit [Ping timeout: 252 seconds]
Turingtoast has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
sakman has quit [Quit: Leaving]
Pali has quit [Ping timeout: 246 seconds]
LeSpocky has quit [Ping timeout: 252 seconds]
LeSpocky has joined #armlinux
amitk has joined #armlinux
tudorel has joined #armlinux
milkylainen_ has joined #armlinux
guillaume_g has joined #armlinux
javierm has quit [Remote host closed the connection]
javierm has joined #armlinux
ardb has joined #armlinux
frieder has joined #armlinux
frieder has quit [Ping timeout: 252 seconds]
apritzel has joined #armlinux
milkylainen has joined #armlinux
apritzel has quit [Ping timeout: 245 seconds]
frieder has joined #armlinux
Amit_T has joined #armlinux
Turingtoast has joined #armlinux
milkylainen_ has quit [Quit: Ping timeout (120 seconds)]
jlinton has quit [Quit: Client closed]
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #armlinux
ardb has quit [Quit: Leaving.]
Pali has joined #armlinux
wwilly has quit [Ping timeout: 245 seconds]
nsaenz_ has quit [Quit: Leaving]
nsaenz has joined #armlinux
ardb has joined #armlinux
djrscally has joined #armlinux
ardb has quit [Quit: Leaving.]
ardb has joined #armlinux
torez has joined #armlinux
<tlwoerner>
broonie: i've found an issue with my nanopi-m4 board (rockchip rk3399)
<broonie>
tlwoerner: I wouldn't have backported the boot/always change but hey, it's stable :/
jlinton has joined #armlinux
<ajb-linaro>
how do I get the kernel .dts to build? I thought dtc -O dtb -o bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b.dts would be enough but apparently the .dts files have #includes which confuse the compiler
<balrog>
Xogium: ah, that's me confusing it with raspbian :)
<balrog>
but yeah, why do you need an entire distro for embedded anyway
<balrog>
vendor kernels I guess
guillaume_g has joined #armlinux
apritzel has joined #armlinux
<ukleinek>
balrog: because a single distro cannot cover all needs
jlinton has joined #armlinux
Amit_T has quit [Quit: Leaving]
cdaudt has joined #armlinux
<marex>
ukleinek: of course not, you need a metadistro for that ;-)
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
guillaume_g has quit [Quit: Konversation terminated!]
ardb has joined #armlinux
cdaudt has joined #armlinux
headless has quit [Quit: Konversation terminated!]
macromorgan has quit [Quit: Leaving]
amitk_ has joined #armlinux
elastic_dog has quit [Ping timeout: 252 seconds]
amitk has quit [Ping timeout: 245 seconds]
elastic_dog has joined #armlinux
amitk_ has quit [Ping timeout: 265 seconds]
agners has quit [Quit: WeeChat 3.2.1]
ardb has quit [Quit: Leaving.]
Pali has quit [Ping timeout: 264 seconds]
<tlwoerner>
broonie: i'm a bit confused. the problematic patch also appears in linus' tree, so it's not just an issue in stable. i found it in stable because that's what i was bisecting (since that's what i was using when i found it)
<tlwoerner>
broonie: (or am i misunderstanding your comment, or misunderstanding how the trees work?)
<broonie>
tlwoerner: Is there actually a problem in Linus' tree, or just with stable?
<tlwoerner>
broonie: i'll run-time check, but looking at the code, the issue appears in linus' tree too
<broonie>
One source of issues in stable is backports that miss needed context somehow.
<javierm>
tlwoerner: but the fix is also in linus' tree right ?
<javierm>
tlwoerner: IIUC the fix just needs to be backported to stable too
<tlwoerner>
javierm: the fix is only for some omap5 device, i'm seeing the issue with my rockchip device (nanopi-m4)
<tlwoerner>
so far i've only tested stable kernels (5.14.6 for example) since that's where i noticed it
<tlwoerner>
but i'll go ahead and test linus' tree too now (runtime)
<javierm>
tlwoerner: tlwoerner>| interestingly, when i build tag 'regulator-fix-v5.13-rc4' from your tree, it succeeds
<broonie>
You haven't actually said what the problem is BTW.
<javierm>
tlwoerner: it seems I misunderstood that comment then
<tlwoerner>
booting from uSD card, the boot stops, if i wait until i see the "vcca0v9_s3 and vcca1v8_s3 disabling" message then eject and reinsert the uSD card the boot carries on just fine
<tlwoerner>
if i never eject and reinsert the uSD card, the boot will sit there waiting forever and reports mmc errors
<broonie>
Those messages mean the core thinks there's no users.
<tlwoerner>
note: it's not an emmc probing order issue
<tlwoerner>
if i eject and reinsert before i see those regulators being disabled then it keeps waiting
<tlwoerner>
the omap5 fix was to remove some regulator descriptions from the dts file, i assume the same thing will fix my issue too for my specific board
<tlwoerner>
but that feels like a work-around and not an actual "fix"
<tlwoerner>
(but then again, i'm new here)
<broonie>
I'm guessing one is the parent of the other and it was only luck that it's been working at all.
<javierm>
broonie: that's my guessing too
rbutler1728 has joined #armlinux
<javierm>
tlwoerner: by looking at arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi, those regulators are used by the pcie0
<broonie>
The OMAP problem looks completely different, the OMAP problem is that there was a fake regulator that creates circular dependencies.
<broonie>
s/circular/unwanted extra/
<javierm>
tlwoerner: if the MMC needs those regulators too, then there's a bug in the DTS that got exposed by the regulator core commit
<tlwoerner>
javierm: yes, and the nanopi-m4 doesn't have pcie (or at least it doesn't have a connector for it)
<javierm>
tlwoerner: IOW, the regulator core is correctly disabling those due being "unused"
<javierm>
but also if I'm reading it correctly the VCCA0V9_S3 and VCCA1V8_S3 power a lot of other chips and that is not described in the DTS
<broonie>
Yeah, I think the DTS is confused about how this stuff is supplied - there's confusion about input supplies vs things that are wired to the enables of fixed regulators.
<javierm>
tlwoerner: so yeah, as mentioned I believe the problem is in the DTS and it was working by luck with the partial description of the HW
<broonie>
Actually, 0.9 *is* supplied by vcc_1V8 but the reguatlro also has a VDD.
<broonie>
In any case, the kernel log doesn't show the MMC controller claiming any regulators - looks like it wants VCC_3V3_S3 and VCC_1V8_S3
* broonie
should really make the regulator API moan about using boot-on for regulators with readback support :/
<broonie>
(I might've got the wrong MMC there looking at the DTSI, there appear to be several - in any case the log doesn't show any requests.
* broonie
heads off for the day.
<tlwoerner>
the emmc is optional, i don't have one. i'm just using the uSD card
<tlwoerner>
on page 19 of the schematics the microsd is only attached to VCC3V0_SD (?)
<broonie>
yeah, looks like it.
<tlwoerner>
:-D
<broonie>
Like I say the regulator disabling might be a red herring, you should check the working logs to see if the disabling is new.
apritzel has quit [Ping timeout: 245 seconds]
<javierm>
tlwoerner: that's why I mentioned that making them regulator-always-on could tell you if the problem is with the regulator being disabled
<javierm>
or that's just a red herring as broonie said
<tlwoerner>
okay, will do. thank you very much (and javierm too!)
<javierm>
tlwoerner: yw! leaving for today, bye
<tlwoerner>
o/
rbutler1728 has quit [Read error: Connection reset by peer]
rbutlerc1728p has quit [Read error: Connection reset by peer]