ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] |
apritzel has quit [Ping timeout: 268 seconds]
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #armlinux
Xogium has quit [Quit: Leaving.]
Xogium has joined #armlinux
Xogium has quit [Quit: Leaving.]
Xogium has joined #armlinux
Nact has quit [Quit: Konversation terminated!]
alpernebbi has joined #armlinux
apritzel has joined #armlinux
<wens_> just realized that arm-soc repo was changed to soc
frieder has joined #armlinux
audgirka has joined #armlinux
<geertu> wens_: They're still kept in sync, aren't they?
<ukleinek> geertu: I wrote to you in reply to your regression report of d7bff84fe7ed8c3b that you can contact me via irc. In case you're not aware who to contact: That's /me :-)
<geertu> ukleinek: thanks!
<geertu> Will debug later today
apritzel has quit [Ping timeout: 256 seconds]
<ukleinek> geertu: I look forward to your report and wonder if my change is broken or if it "only" uncovers a problem in the driver.
matthias_bgg has joined #armlinux
<mort> Does anyone know whatever happened to It doesn't seem to ever have gotten merged
sszy has joined #armlinux
sszy has quit [Remote host closed the connection]
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
Pali has joined #armlinux
sszy has joined #armlinux
nsaenz has quit [Quit: Leaving]
nsaenz has joined #armlinux
<mort> javierm: regarding yesterday: the reeeeally fun thing is that if Linux still warned about setting unused config values, this would've just been a compile-time error the very first time I tried to compile the new kernel and debugging would've started at "why did the old kernel have the LEDS_QCOM_LPG driver but the new kernel doesn't"
<mort> not 100% sure removing that error was a good idea
<wens_> geertu: arm-soc no longer appears on the listing on, so I was a bit confused when I wanted to add the url in another repo
wens_ is now known as wens
<geertu> wens: Indeed. The repo is still there though.
<geertu> git ls-remote git://
<arnd> not sure if this was intended, but I wouldn't change it now. I think the asm-soc.git there is a symlink on the server that we left after the migration. It's possible that the web gui stopped showing symlinks
<arnd> We don't actively update arm-soc.git, so it's always the same as soc.git
<geertu> arnd: OK, I thought it was a manual process :-)
<geertu> Will drop the remote
nsaenz has quit [Remote host closed the connection]
<geertu> No need to keep on checking if they are identical ;-)
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<javierm> mort: ah, I didn't even notice that there wasn't a warning anymore
apritzel has joined #armlinux
Pali has quit [Ping timeout: 265 seconds]
Crassus has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 256 seconds]
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 240 seconds]
wwilly has quit [Ping timeout: 265 seconds]
atorgue has quit [Read error: Connection reset by peer]
atorgue has joined #armlinux
Crassus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mort> I don't understand. I have a driver which is enabled by CONFIG_LEDS_QCOM_LPG, defined in a Kconfig file and with code in a Makefile which uses that option. The LEDS_QCOM_LPG option shows up when searching the menuconfig. I set `CONFIG_LEDS_QCOM_LPG=y` in a kernel config fragment (.cfg) file and compile linux with that .cfg file. The kernel compiles
<mort> successfully. But when I boot into that kernel and zcat /proc/config.gz, it doesn't mention anything about QCOM_LPG
<javierm> mort: what's your resulting .config ?
<javierm> because maybe the config fragment is not picked ? That is, config fragments are just a convention but you need to use ./scripts/kconfig/ to merge those bits
<broonie> Also check that there's no dependencies for it missing, the config is checked during build and things that can't be enabled will be dropped.
<javierm> indeed
<mort> wait it doesn't error if you enable something with unmet dependencies? It just silently ignores your config?
<mort> anyways, missing deps shouldn't be an issue, all the dependencies are =y according to the menuconfig
<javierm> mort: I believe ./scripts/kconfig/ will complain but make prepare modules_prepare won't AFAIK
<mort> here's the .config file (I assume it's after merge? idk):
<mort> I don't think that's after the configs, there are config options I set but which are commented as not set in that .config
<javierm> mort: you are using a bitbake recipe right? can you share the relevant snippet ?
<broonie> There's no error on missing deps, just warnings, in order to handle upgrades gracefully.
wwilly has joined #armlinux
scosu_ has quit [Ping timeout: 250 seconds]
<javierm> yeah, kconfig symbols are not considered and ABI an can change between releases
<javierm> *an
<mort> the recipe is here: - that pm8916-pwm.cfg file just contains "CONFIG_LEDS_QCOM_LPG=y"
<javierm> mort: hmm, seems correct. Are the symbols from the other fragments present in your final .config ?
<mort> There's a bunch of options I'm setting to =n in .cfg files but which are marked as not set in the .config I linked, for example I have CONFIG_REMOTEPROC=n but the .config contains "# CONFIG_REMOTEPROC is not set"
<j`ey> mort: thats the same as =n
<mort> I haven't found anything I'm setting to =m or =y which isn't in the .config
<mort> I'm relatively certain that CONFIG_MWIFIEX_USB is =n by default, but one of my .cfg files is setting it to =m and it's =m in the .config
<javierm> mort: so I would take your config and try to do just do ./scripts/config --enable CONFIG_LEDS_QCOM_LPG
<javierm> I think broonie is correct and should be some missing dependency that prevents that option to be enabled
<javierm> although that only depends on LEDS_CLASS that you already have enabled...
<javierm> mort: anyways, trying to enable manually would be easier to troubleshoot
<mort> `./scripts/config --enable CONFIG_LEDS_QCOM_LPG` just works
<mort> and the .config is updated to contain CONFIG_LEDS_QCOM_LPG=y
wwilly has quit [Ping timeout: 256 seconds]
wwilly has joined #armlinux
wwilly has quit [Remote host closed the connection]
wwilly has joined #armlinux
<javierm> mort: Ok, then it's something in your bitbake recipe or the bitbake cache I guess
<mort> building with -v, the one line which looks relevant is: "Value of CONFIG_LEDS_QCOM_LPG is redundant by fragment /mnt/yocto-ev2/build/tmp/work/ev2-poky-linux/linux-linaro-qcomlt/17.06-r0/pm8916-pwm.cfg:"
Nact has joined #armlinux
<javierm> mort: interesting... but I wouldn't expect it to disable due that
<mort> seems to just basically be printed when the fragment didn't have any effect
<mort> when $PREV_VAL == $NEW_VAL
<mort> and assuming NEW_VAL=y, that just means it's enabled by default which makes enabling it in the fragment unnecessary
<mort> actually, let me patch to print the value when it shows that message
<mort> just to verify it's actually =y
<mort> indeed, it thinks the previous value is =y
<mort> I don't understand this at all
<mort> javierm: do you know if config options have to be specified anywhere else than in the one relevant Kconfig file?
<javierm> mort: no, just in the Kconfigs (and Makefiles or course so kbuild can build and include the object files if enabled)
scosu has joined #armlinux
<mort> so there's nothing missing here, it adds the config option to a Kconfig and uses it in a Makefile
<javierm> mort: ah, but that has more dependencies than the patch posted to the mailing list that you shared
<javierm> mort: you are missing LEDS_CLASS_MULTICOLOR for example in your .cofing
<mort> hmm, shouldn't *something* have printed something at this point about that though? I did compile with -v and grepped through the output
<mort> well, I removed that dependency, and now the leds-qcom-lpg.c file gets compiled at least
<mort> (which I know because it errors because led-class-multicolor.h doesn't exist, but that's another issue)
<mort> I would've assumed that "the user requests a config option, that config option exists, but it depends on something which isn't enabled" would be an error or at least a warning :(
<javierm> mort: which makes sense since you removed the dependency. You need to either add another config fragment enabling the LEDS_CLASS_MULTICOLOR or add that to your pwm config fragment
<javierm> mort: and yeah, I can't remember now when it complains but for sure we are lacking on debug messages to catch these
<mort> I don't think this kernel has LEDS_CLASS_MULTICOLOR, it's probably a patch targeting a newer kernel
<mort> it feels stupid, this seems to be a combined PWM+LED driver but we just need the PWM part to drive a backlight yet we can't use the newest version because our kernel doesn't have a concept of multicolor LEDs
<mort> people here are talking about the need to have a separate PWM driver rather than a PWM+LED driver too
<javierm> mort: I see. That's a bummer
<mort> it's kinda odd that this patch has been floating around since 2017 with a few attempts at upstreaming it but it just never reached mainline
paulg has quit [Remote host closed the connection]
<mort> I wonder if it's easier to forward-port the 2017 patch to 5.7 or remove multicolor support from the 2020 patch
<mort> ..and they say upgrading linux is easy
<javierm> mort: who said that :)
<mort> every other talk I've seen from greg complains that people aren't just taking his changes on a regular basis and that everyone is too slow at upgrading their kernels and that it's easy
<mort> this is the latest patch in this series, it's from june 23 and with a comment from june 25, so it's probably going to be mainlined *eventually*
<mort> maybe it'll even be there for linux 6 and I can get rid of this patch in 2035
audgirka has quit [Remote host closed the connection]
<mort> I got the new patch to compile by commenting out everything related to RGB and copy/pasting from the led-class-multicolor header, so that's nice
<ukleinek> geertu: the log snippet in your mail corresponds to some debug printks with the patch reverted, right?
<ukleinek> geertu: ah, this is a diff
sszy has quit [Ping timeout: 265 seconds]
<geertu> ukleinek: yep, it's a diff
<ukleinek> geertu: that the first pwm_config goes away is expected, the second however should stay
* ukleinek sees a bug but I think this one doesn't trigger for you.
<ukleinek> (i.e. if you have .duty_cycle = A, .period = B configured and then call pwm_apply(pwm, { .duty_cycle = C, .period = D, .enabled = false}) and then pwm_apply(pwm, {.duty_cycle = C, .period = D, .enabled = true }) .pwm_config isn't called but it should.
<ukleinek> (with A != C || B != D)
torez has quit [Quit: torez]
<ukleinek> geertu: can you test please?
headless has joined #armlinux
torez has joined #armlinux
<ukleinek> geertu: or better:
<ukleinek> tagr: ^
unmanbearpig has quit [Quit: unmanbearpig]
Pali has joined #armlinux
<geertu> ukleinek: thx, fixes the issue
alpernebbi has quit [Quit: alpernebbi]
<ukleinek> geertu: thanks for confirming
wwilly has quit [Remote host closed the connection]
<geertu> ukleinek: so both patches from your email work
frieder has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 272 seconds]
wwilly has joined #armlinux
<ukleinek> geertu: great
rbutler1728 has joined #armlinux
rbutlerc1728 has joined #armlinux
rbutler1728 has quit [Ping timeout: 268 seconds]
rbutler1728 has joined #armlinux
headless has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
shoragan[m] has quit [Remote host closed the connection]
sha has quit [Remote host closed the connection]
psydroid has quit [Write error: Connection reset by peer]
mvaittin has quit [Remote host closed the connection]
psydroid has joined #armlinux
mvaittin has joined #armlinux
shoragan[m] has joined #armlinux
sha has joined #armlinux
jlinton has quit [Quit: Client closed]
rbutlerc1728 has quit [Read error: Connection reset by peer]
rbutler1728 has quit [Read error: Connection reset by peer]
Pali has quit [Ping timeout: 265 seconds]