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
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
apritzel has quit [Ping timeout: 240 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
Nact has joined #armlinux
heat has quit [Ping timeout: 268 seconds]
System_Error has quit [Remote host closed the connection]
Nact has quit [Ping timeout: 255 seconds]
Nact has joined #armlinux
sakman has quit [Quit: Leaving]
mvaittin__ has joined #armlinux
cbeznea_ has joined #armlinux
sicelo_ has joined #armlinux
iokill has quit [Ping timeout: 260 seconds]
sicelo has quit [Read error: Connection reset by peer]
sicelo_ is now known as sicelo
iokill has joined #armlinux
amitk has joined #armlinux
Nact has quit [Remote host closed the connection]
lain6141_ has quit [Read error: Connection reset by peer]
lain6141_ has joined #armlinux
Nact has joined #armlinux
monstr has joined #armlinux
mvaittin_ has joined #armlinux
mvaittin__ has quit [Ping timeout: 268 seconds]
Nact has quit [Ping timeout: 255 seconds]
Nact2 has joined #armlinux
Nact2 has quit [Ping timeout: 255 seconds]
cambrian_invader has quit [Ping timeout: 256 seconds]
apritzel has joined #armlinux
prabhakalad has quit [Ping timeout: 260 seconds]
prabhakalad has joined #armlinux
apritzel has quit [Ping timeout: 246 seconds]
vingu has quit [Ping timeout: 255 seconds]
cambrian_invader has joined #armlinux
iivanov has joined #armlinux
Nact has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
iivanov has quit [Client Quit]
vingu has joined #armlinux
mvaittin_ has quit [Ping timeout: 260 seconds]
System_Error has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Client Quit]
iivanov has joined #armlinux
Nact has quit [Ping timeout: 255 seconds]
nsaenz has joined #armlinux
mvaittin_ has joined #armlinux
headless has joined #armlinux
System_Error has quit [Remote host closed the connection]
iivanov has quit [Remote host closed the connection]
System_Error has joined #armlinux
iivanov has joined #armlinux
frieder has joined #armlinux
headless has quit [Quit: Konversation terminated!]
sszy has joined #armlinux
apritzel has joined #armlinux
abelvesa has joined #armlinux
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
dmart has joined #armlinux
heat has joined #armlinux
vingu has quit [Read error: Connection reset by peer]
headless has joined #armlinux
nsaenz has quit [Remote host closed the connection]
socksinspace has quit [Ping timeout: 268 seconds]
Livio has joined #armlinux
socksinspace has joined #armlinux
vingu has joined #armlinux
headless has quit [Quit: Konversation terminated!]
bjoto` is now known as bjoto
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #armlinux
socksinspace has quit [Quit: WeeChat 3.8]
mripard has joined #armlinux
socksinspace has joined #armlinux
lain6141_ has quit [Read error: Connection reset by peer]
<arnd>
mripard: I'd prefer to merge the arm defconfig patches through the soc tree to avoid dealing with conflicts, but if you think it helps you then add an Ack from me to take them through drm-misc
<mripard>
arnd: I'm fine with both, drm-misc seemed like the fastest option to get it into -next, but if you want to take them because it makes more sense, feel free to do so
<mripard>
I basically don't have an opinion there as long as they are applied and in next :)
Amit_T has joined #armlinux
<arnd>
mripard: this is for 6.10, not 6.9, right?
<arnd>
if you send the arm defconfig ones to soc@kernel.org, I can apply them quickly
<mripard>
yep, it's for 6.10
<mripard>
ack
<mripard>
thanks :)
jclsn has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
psydroid has joined #armlinux
headless has joined #armlinux
mvaittin_ has quit [Ping timeout: 272 seconds]
vingu has quit [Quit: Leaving.]
vingu has joined #armlinux
* broonie
would
<broonie>
Just like his CI to be not so spectacularly red however it happens.
<geertu>
mripard: arnd: So we're really going forward with this the-user-needs-to-know-which-helpers-his-driver-needs mess?
<geertu>
with the user really being the end user, not the user of the helper who writes the driver
<arnd>
I have no idea what started this here, but the commit d674858ff979 ("drm/display: Make all helpers visible and switch to depends on") has a strange statement in it "However, this creates an issue nowadays when helpers depend on each other, and select doesn't transitively select a dependency dependencies." that suggests this started from a misunderstanding
<arnd>
I do think we should remove all kinds of overreaching 'select' statements from drivers/gpu/drm/ that have caused problems in the past and turn those into 'depends on' with defconfig files listing the dependencies individually
<arnd>
but I don't see anyone currently working on that bit. The helpers on the other hand are clearly designed to be selected and should probably just be hidden symbols
<geertu>
arnd: Exactly. The casual user configuring his kernel has no idea which helpers to enable first to make the driver he needs to become visible.
<mripard>
arnd: there's several layers of helpers, each depending on the upper layer. There's no way for us to use select, unless we maintain transitive dependencies
<arnd>
geertu: they might also not know that they need to turn on I2C=y or INPUT, and I think that is ok. The problem here is that the helper code was explicitly designed to be selected
<arnd>
mripard: what are those dependencies?
<mripard>
the alternative being we select all the helpers all the time, but then some will complain that the kernel is getting too big and we select features that are not needed
<mripard>
arnd: HDMI helpers will depend on display helpers for example, but are only relevant if you are an HDMI driver
<arnd>
mripard: I meant which helpers have dependencies that are not just other helpers?
<mripard>
sorry, I'm not sure what you're asking. What do you have in mind?
<arnd>
mripard: everything I see in drivers/gpu/drm/display/Kconfig depends only on DRM, so you should be fine just selecting them as before, I don't see any way this could go wrong
<geertu>
DRM_GEM_SHMEM_HELPER depends on MMU
<arnd>
geertu: those two are still hidden symbols that get selected as before
<arnd>
so anything selecting them needs to depend on the same symbols (KUNIT and MMU)
<geertu>
Yep, that's what I said in my response to the series, too
<arnd>
whereas the ones that mripard changed don't seem to even have dependencies that one would need to be aware of
<mripard>
arnd: helpers are in a module of their own. DRM_HDMI_DISPLAY_HELPERS depends on DRM_DISPLAY_HELPERS which depends on DRM_KMS_HELPERS which depends on DRM
<geertu>
(Kconfig could be taught to not show their selectors if KUNIT resp. MMU is not enabled)
<mripard>
so yeah, I guess it all depends on DRM
<mripard>
but it's a simplification
<arnd>
mripard: sure, so just turn those all back into 'select'
<mripard>
so the drivers would need to select all 4.
<mripard>
(well, 3 if we exclude DRM)
<arnd>
mripard: no, a driver just needs to select the helper it needs, which has the selects for the other ones
<geertu>
mripard: What's the issue with DRM_DISPLAY_DP_HELPER selecting DRM_DISPLAY_HELPER?
<mripard>
but select isn't transitive?
<arnd>
it has always been transitive
<geertu>
It is
<geertu>
Caveat is tristate -> bool -> tristate
<arnd>
right, the 'select' has to be done by the driver module here to avoid that problem, otherwise Kconfig has no way of figuring out if something should be =y or =m
<mripard>
I mean, it's transitive with a big if, and the documentation explicitly suggests it's a bad idea and you shouldn't do that
<arnd>
so e.g. ROCKCHIP_ANALOGIX_DP cannot 'select DRM_DISPLAY_DP_HELPER' since this is just a 'bool' symbol, but instead DRM_ROCKCHIP has to 'select DRM_DISPLAY_DP_HELPER if ROCKCHIP_ANALOGIX_DP'.
<geertu>
mripard: The driver can select all helpers it needs instead
<arnd>
mripard: where does the documentation say that?
<mripard>
"In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies."
<arnd>
that is good advice, but that is what the helpers did before your patch
<arnd>
as the helpers don't have dependencies (aside from DRM)
<mripard>
and between each helpers layer
<mripard>
select is documented as being a "reverse dependency"
<mripard>
so it is a dependency.
<arnd>
that is not what they meant though. What this is trying to discourage is the stuff like in drivers/gpu/drm/xe/Kconfig, which selects BACKLIGHT_CLASS_DEVICE, INPUT,. ACPI_VIDEO, ACPI_BUTTON X86_PLATFORM_DEVICES and ACPI_WMI instead of a simple 'depends on ACPI_VIDEO'
<arnd>
that part is absolutely disgusting and a common source of dependency loops, whereas selecting symbols that select other symbols is absolutely fine as long as none of these depend on anything else
<arnd>
mripard: let's take a step back here and try to solve the original problem you had, as I assume you ran into a bug that you tried to solve with d674858ff979 ("drm/display: Make all helpers visible and switch to depends on")
<arnd>
what was the actual issue you had there?
monstr has quit [Remote host closed the connection]
gclement1 has joined #armlinux
gclement1 has quit [Client Quit]
Livio has joined #armlinux
headless has quit [Quit: Konversation terminated!]
<mripard>
arnd: it's not so much that we had a particular bug to fix, it's more of an accumulation of issues everywhere
<mripard>
this was shown by a series being flagged yet again by the kernel bot
<mripard>
I don't really get what the fuss is all about really. If we had made the helpers use depends on from the beginning, would it have been rejected?
<geertu>
mripard: Probably it would. Helpers and library code are meant to be selected.
<geertu>
Depends is meant for functionality that needs to be present (e.g. hardware dependencies, and the big subsystem enable switch)
<mripard>
or any symbol with dependency, according to the doc
<geertu>
mripard: Note the "in general". There can be exceptions.
<mripard>
that "in general" was completely absent from your definition though
<geertu>
mripard: the "in general"
<geertu>
mripard: the "in general" was present n your quoting of the docs.
<mripard>
what I'm saying is the fact that it's only for hardware and big enable switch is not documented anywhere, and is missing most of the symbols with dependencies
<geertu>
mripard: Always keep usability in mind
<mripard>
I do, it's why I sent those defconfig patches in the first place
<mripard>
and everything else works with olddefconfig
Forty-Bot has quit [Ping timeout: 268 seconds]
Livio has quit [Ping timeout: 260 seconds]
frieder has quit [Ping timeout: 256 seconds]
amitk_ has joined #armlinux
headless has joined #armlinux
balrog has quit [Remote host closed the connection]
balrog has joined #armlinux
<geertu>
mripard: defconfig and oldconfig are only one part of the picture. What about people who want to enable suppot for a new driver?
<geertu>
Imagine e.g. EXT4_FS would depend on BUFFER_HEAD, JBD2, CRC16, CRYPTO, CRYPTO_CRC32C and FS_IOMAP instead of selecting them
System_Error has quit [Remote host closed the connection]
iivanov has quit []
System_Error has joined #armlinux
amitk_ has quit [Ping timeout: 246 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
kristinam has joined #armlinux
Amit_T has quit [Quit: Leaving]
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 252 seconds]
apritzel has joined #armlinux
cbeznea_ has quit [Ping timeout: 255 seconds]
amitk_ has quit [Remote host closed the connection]
amitk has joined #armlinux
<marex>
Hi, can I use writel_relaxed() followed by clk_disable_unprepare() ? I observe sporadic suspend/resume issues and I see this pattern in a driver, so I wonder if this could be it
<marex>
like, the write is posted on the bus, but before it reaches the IP, the clock get disabled
<arnd>
marex: the 'relaxed' bit does not change posting, if you want to be sure it has reached the device you need to read the register after writing
amitk has quit [Remote host closed the connection]
<marex>
arnd: what does the relaxed do ? I was under the impression it does skip a barrier ?
<marex>
ah
<arnd>
regardless of that, you should rarely need to use the relaxed accessor anywhere, and instead just use the default ones consistently unless there is a specific reason to use relaxed in a fast path that does not rely on DMA
<marex>
drivers/char/hw_random/stm32-rng.c is full of the relaxed stuff and it doesnt do DMA
<marex>
this is the driver I currently suspend causes the suspend/resume issues I have
<arnd>
the barrier in writel_relaxed() is before the MMIO access, the purpose here is to ensure that a previous write to coherent memory has made it from the store buffer to physical RAM before the MMIO write triggers a DMA that reads it from DRAM
<marex>
arnd: ahhh, thanks for clarifying
<marex>
arnd: so hum, I dont see the justification for all the _relaxed in that driver
<arnd>
marex: right, I don't think it should use _relaxed(), but I also don't see how that would cause problems with suspend/resume
<marex>
arnd: I will keep digging
<marex>
arnd: thanks for double checking and explanation of the relaxed variant
<headless>
"Relax, don't do it" :-)
<arnd>
mripard: I don't think it's a big deal, the annoying bit with your patch is just that it was done based on an incorrect assumption and it now causes regressions without solving any actual problems.
<arnd>
the new version of the display helper Kconfig logic isn't broken itself, it's just slightly worse than it was before your change
<arnd>
the other 'select' statements in drivers/gpu/drm that are actually wrong are way more annoying though, so I hope that we have a chance to fix those as well now
<marex>
When suspend is called after pm_runtime_suspend, same callback is used and access to rng register is freezing system. By calling the pm_runtime_force_suspend, it first checks that runtime has been already done.
<marex>
clearly ... this did not fix the problem
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
prabhakalad has quit [Ping timeout: 240 seconds]
prabhakalad has joined #armlinux
headless has quit [Quit: Konversation terminated!]
System_Error has quit [Remote host closed the connection]