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
Turingtoast has quit [Ping timeout: 260 seconds]
bps has quit [Ping timeout: 256 seconds]
Pali has quit [Ping timeout: 256 seconds]
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mraynal has quit [Read error: Connection reset by peer]
mraynal has joined #armlinux
TheCoffeMaker has quit [Ping timeout: 250 seconds]
TheCoffeMaker has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
TheCoffeMaker has quit [Ping timeout: 246 seconds]
TheCoffeMaker has joined #armlinux
Fridtjof_ has joined #armlinux
strudl- has joined #armlinux
aposm has quit [Remote host closed the connection]
Fridtjof has quit [Quit: ZNC - http://znc.in]
strudl has quit [Quit: got milk?]
jamieiles has quit [Ping timeout: 272 seconds]
jamieiles has joined #armlinux
aposm_ has joined #armlinux
wolfshappen has quit [Ping timeout: 272 seconds]
wolfshappen has joined #armlinux
qyousef has quit [Ping timeout: 272 seconds]
rfs613 has quit [Ping timeout: 272 seconds]
rfs613 has joined #armlinux
jamieiles has quit [Remote host closed the connection]
qyousef has joined #armlinux
jamieiles has joined #armlinux
HdkR_ has joined #armlinux
tchebb_ has joined #armlinux
HdkR has quit [Ping timeout: 272 seconds]
tchebb has quit [Ping timeout: 272 seconds]
XV8 has joined #armlinux
XV8 has quit [Client Quit]
qyousef has quit [Ping timeout: 250 seconds]
qyousef has joined #armlinux
amitk has joined #armlinux
Turingtoast has joined #armlinux
Turingtoast has quit [Ping timeout: 240 seconds]
Misotauros has joined #armlinux
cbeznea has joined #armlinux
Misotauros has quit [Ping timeout: 240 seconds]
apritzel has joined #armlinux
iivanov has joined #armlinux
luispm has joined #armlinux
atorgue has joined #armlinux
apritzel has quit [Ping timeout: 246 seconds]
dliviu has quit [Quit: Going away]
djrscally has joined #armlinux
sszy has joined #armlinux
Pali has joined #armlinux
headless has joined #armlinux
cleger has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
nsaenz has joined #armlinux
Pali has quit [Ping timeout: 240 seconds]
Turingtoast has joined #armlinux
alexels has joined #armlinux
Tokamak has quit [Ping timeout: 250 seconds]
Tokamak has joined #armlinux
apritzel has joined #armlinux
sudeepholla has joined #armlinux
sudeepholla_ has quit [Quit: Ex-Chat]
bps has quit [Ping timeout: 276 seconds]
Amit_T has joined #armlinux
dliviu has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Turingtoast has joined #armlinux
prabhakarlad has joined #armlinux
<geertu> ukleinek: Go ahead! ;-)
bps has joined #armlinux
bps has quit [Changing host]
bps has joined #armlinux
wybpip[m] has joined #armlinux
wybpip[m] has left #armlinux [#armlinux]
<ukleinek> geertu: I quickly looked at the code generated on ARM and I think the ilog2 there is more complicated than my two ifs ...
headless_ has joined #armlinux
headless has quit [Ping timeout: 240 seconds]
headless_ is now known as headless
headless has quit [Quit: Konversation terminated!]
monstr has joined #armlinux
elastic_dog has quit [Ping timeout: 260 seconds]
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
elastic_dog has joined #armlinux
sudeepholla has quit [Ping timeout: 276 seconds]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<arnd> ukleinek: did you come across another case where gcc turns ilog2() into a horrible mess, or does it do what one expects and just produce something slightly worse than ideal?
<arnd> we've had cases in the past where gcc __builtin_constant_p() had inconsistent results and it ended up compiling const_ilog2() into awful runtime code
sudeepholla has joined #armlinux
Misotauros has joined #armlinux
sszy has joined #armlinux
macromorgan_ has joined #armlinux
macromorgan has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
macromorgan_ is now known as macromorgan
Misotauros has quit [Ping timeout: 248 seconds]
Turingtoast has joined #armlinux
torez has joined #armlinux
tagr has joined #armlinux
jlinton has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Misotauros has joined #armlinux
Turingtoast has joined #armlinux
HdkR_ is now known as HdkR
HdkR has joined #armlinux
HdkR has quit [Changing host]
monstr has quit [Remote host closed the connection]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sudeepholla_ has joined #armlinux
gpiccoli has quit [Quit: Quit...]
gpiccoli has joined #armlinux
jkridner has joined #armlinux
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #armlinux
<jkridner> oddball question, is there a minimal arm kernel config I can target to run in userspace? Imagine that I wanted to test some drivers out that had only a network driver dependency and I'd like to run them in a container (not a VM). Anyone know of a config that would work (ie., no protected mode, no interrupt controller, STDIO or sockets-based console, sockets-based-networking, etc.)? just a couple of check-boxes to get started would be good.
<jkridner> running qemu seems the obvious work-around, but I'd like to see if I can remove that overhead.
<marex> jkridner: arent you looking for usermode linux ?
<jkridner> yes
<jkridner> it is largely as simple as that, but I'm not finding it.
<jkridner> perfect! I kept searching user *space* linux, rather than user *mode* linux. Thanks marex !
<j`ey> jkridner: UML doesn't work on arm I believe
<jkridner> btw, hope you are doing well. I look forward to making it to another ELC soon. (assuming you are the right marex I've met before)
<jkridner> j`ey: k. I was worried about that. I'll try to look for the issues and hope dragons aren't lurking.
<jkridner> anyway, this is the exact feature I was looking for, so it gives me something clear to debug.
<marex> good
<jkridner> looks like Ubuntu for ARM has some of the utilities. That's a good sign.
<j`ey> jkridner: arch/um/Kconfig includes arch/$(HEADER_ARCH)/um/Kconfig, and only arch/x86/um exists
<jkridner> k
<jkridner> :-( also, "The syscall interception technique used by UML makes it inherently slower for any userspace applications"
luispm has quit [Remote host closed the connection]
<jkridner> ubuntu 'user-mode-linux' has no install candidates. unsure why it was removed.
bps has quit [Ping timeout: 260 seconds]
<maz> jkridner: I don't think it ever worked on arm or arm64.
<marex> maz: oh hey
<marex> maz: do you have a moment, I would like to pick your brain
<maz> I vaguely remember someone looking into it 6 or 7 years ago, but it went nowhere.
<maz> marex: sure.
<marex> (seems like a good opportunity to revisit that)
* maz prepares to run away...
<marex> maz: well, simple question really ... is clk_enable() supposed to work in hardirq context of irq_eoi() callback ?
<marex> maz: or not
<marex> I mean, there is that spinlock, which could be an issue ?
<marex> (it is about the stm32 pinctrl driver splat ... I just didn't get to replying to you via email yet)
sudeepholla has quit [Ping timeout: 240 seconds]
<maz> you can take any lock you want, just something that is 'stronger' than the locks the irq core already takes.
<maz> given that we have raw spinlocks for most things, anything that is weaker (mutex or normal spinlocks) is forbidden.
<maz> (with RT, spinlocks are downgraded to mere mutextes)
<marex> maz: I wonder whether the clk_enable_lock() spin lock should be turned to raw one then ?
<maz> marex: my gut feeling is that this is a bad idea. it would certainly hurt RT performance by creating larger critical sections.
<marex> maz: I have to say, I am out of ideas how to get out of this
<maz> I'm actually pretty dubious about the whole GPIO clocking while in interrupt.
<maz> why isn't that on at all times?
<maz> the moment you have a level interrupt, you need it anyway.
<marex> maz: that's some ST oddity where they try to micro-manage clock I think in some hope to reduce power consumption
<marex> maz: the LEVEL interrupts on that platform were not originally supported at all btw ... they were only added when I ran into this on two occasions via this emulation
<marex> I am surprised that there aren't more platforms which require this kind of emulation and suffer from similar issues
<maz> yes, I remember this pile of crap.
<marex> but I guess those platforms just don't micro-manage clock that way
<maz> sane platforms implement level support, full stop.
<maz> honestly, I would simply increment the clk refcount each time a level interrupt is mapped, and leave it that way.
<maz> no level, no additional cost.
<marex> maz: to be blunt, I would just keep the clock running, neither of the platforms which need these level interrupts are battery powered
<maz> suits me.
<marex> and this clock micro-management seems dubious to me too
<marex> I mean, how much can you save by turning off pincontrol block
<maz> I think there was an email from the ST folks saying they wanted to leave it on.
<marex> compared to this constant overhead of clock off/on back and forth, on a 650 MHz low-end core no less
<marex> maz: yes, there was a follow up, but I didn't see the patches yet
<maz> they'll be great, I'm sure! :D
<marex> maz: maybe I should just send a trivial patch like that for the level IRQs and be done with it , like you suggested ?
<maz> please do.
<marex> maz: I do have a board instrumented for fine SoC power consumption measurement, so I could measure the difference ;-)
<maz> at least that will get the conversation going.
<marex> all right, I'll get the patch out like tomorrow-ish, I need to finish another patch today
<marex> thanks !
<maz> no hurry. it has been broken forever, it can wait another few days!
<marex> maz: should I actually slap Fixes: tag on it ?
<marex> I can't tell here ... is that a bug if the splat only happens with RT patch on and not with mainline ?
<maz> up to you, really. this is really niche, and people using these SoCs rarely care about upgrading their kernel.
<maz> but RT is upstream now, so I'd definitely consider it a bug.
<marex> maz: people using the SoM care about keeping their LTS kernel versions up to date
<marex> the SoM where this is an issue anyway
<maz> well, if you think it is valuable, stick a Fixes: tag on it then.
<marex> it is either 5.10.y or 5.15.y and damn up to date
nsaenz has quit [Remote host closed the connection]
<marex> maz: I just don;t want to annoy greg with pushing stuff which is borderline feature
<maz> Greg picks stuff that I never tagged for stable. and if he shouts, I'll talk to him myself.
nsaenz has joined #armlinux
<broonie> Yeah, no need to worry about stable rules these days.
<marex> broonie: what ?
<maz> broonie: I used to look at what was going in. I gave up.\
<broonie> marex: Like maz says they're getting very enthusiastic about picking stuff for stable these days, there's a bot which automatically tries to identify things that vaugely look like fixes and it's quite enthustiastic.
<marex> broonie: I noticed there are patches which shouldn't be there, that complaint was going on for a while
<broonie> maz: I still scan the bot stuff since that's the main risk (though I have caught Greg picking stuff that I nacked for the bot).
<marex> I just carefully tag patches with Fixes:, but it seems any patch with "fix" in its subject gets sucked in, so I started avoiding those in what are not stable fixes
<marex> grumb
<javierm> yeah, I've noticed many times patches that would actually cause a regression if backported without other patches from the same series
<javierm> when that happens I answer that shouldn't be backported but never check if that was the case
headless has joined #armlinux
<maz> I guess one of the issues is that -stable serves as the foundation for distro kernels, and that they backports a lot of stuff. in a way, this makes these distros more robust. but it makes the -spable kernels more flaky if used standalone.
jlinton has quit [Ping timeout: 250 seconds]
<broonie> It also encourages people to go back to manually picking patches for their production kernels after they get burned :/
<marex> I only found two cases when something went wrong, one was during broonie vacation , oh well
<marex> the other was some etnaviv detail which got backported too soon
<broonie> There's been a few in the Intel audio drivers at least.
<marex> it did indeed encourage certain people to be very vocal about cementing themselves on ancient version, but it was enough to put those issues into perspective -- 2 issues in a year seems OK
<marex> broonie: sigh :(
<javierm> yes, I believe the net benefit is still positive. The Fedora kernel is basically vanilla -stable and I would say is pretty stable
<marex> javierm: the net benefit is absolutelly positive
<marex> stable (LTS) seems like the thing industrial users want
<marex> slow moving, no surprises (much), update once every few years
<ukleinek> javierm: I don't understand your example in https://lore.kernel.org/all/e4f56999-cf58-abff-edf5-ae11d024012b@redhat.com.
<ukleinek> The ; in the FBTFT_REGISTER_DRIVER line isn't used to terminate a MODULE_DEVICE_TABLE
<ukleinek> javierm: because FBTFT_DT_TABLE already has a ; after MODULE_DEVICE_TABLE(...)
<ukleinek> javierm: the ; after FBTFT_REGISTER_DRIVER(...) can go away, but I'm not sure it's worth the effort to improve here.
cleger has quit [Quit: Leaving]
<javierm> ukleinek: right, what I tried to say is that it's building just because there are some macro inception there
<javierm> ukleinek: IOW, I agree with your patch. Just was curious how that person was able to build it without the semicolon
<javierm> ukleinek: my example was after he applied the patch that posted
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Pali has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<javierm> ukleinek: I could had gotten the example wrong though, as said there too many macros in those drivers and is hard for me to read :)
alexels has quit [Quit: WeeChat 3.5]
Turingtoast has joined #armlinux
<ukleinek> javierm: ack for -ETOOMANYMACROS
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Turingtoast has joined #armlinux
<javierm> ukleinek: haha, indeed
<javierm> ukleinek: also, I did try to build with his patch and as expected it doesn't, so I read the code wrongly indeed
apritzel has quit [Ping timeout: 248 seconds]
amitk has quit [Ping timeout: 256 seconds]
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
sudeepholla has joined #armlinux
<geertu> marex: clk_enable() is interrupt-sage, clk_prepare() isn't.
<geertu> s/sage/safe/
<geertu> marex: old thread from 2015 (how many years before -rt was merged?) still valid?
apritzel has joined #armlinux
Amit_T has quit [Ping timeout: 240 seconds]
bps has joined #armlinux
bps has quit [Changing host]
bps has joined #armlinux
<marex> geertu: ask sboyd
bps has quit [Remote host closed the connection]
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
milkylainen has quit [Quit: Ping timeout (120 seconds)]
elastic_dog has quit [Quit: elastic_dog]
Nact has joined #armlinux
djrscally has quit [Quit: Konversation terminated!]
djrscally has joined #armlinux
headless has quit [Quit: Konversation terminated!]
cbeznea has quit [Ping timeout: 276 seconds]
Nact has quit [Quit: Konversation terminated!]
nsaenz has quit [Remote host closed the connection]
jn has quit [Ping timeout: 248 seconds]
jn has joined #armlinux
jn has joined #armlinux
geertu has quit [Ping timeout: 248 seconds]
elastic_dog has joined #armlinux
djrscally has quit [Ping timeout: 250 seconds]
torez has quit [Quit: torez]
Pali has quit [Ping timeout: 276 seconds]
geertu has joined #armlinux