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
Misotauros has quit [Ping timeout: 276 seconds]
apritzel_ has quit [Ping timeout: 240 seconds]
Misotauros has joined #armlinux
jkridner has quit [Read error: Connection reset by peer]
bryanb has quit [Ping timeout: 260 seconds]
tfiga has quit [Ping timeout: 244 seconds]
ccaione has quit [Ping timeout: 260 seconds]
unixsmurf has quit [Ping timeout: 248 seconds]
drewfustini has quit [Read error: Connection reset by peer]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
tre has joined #armlinux
monstr has joined #armlinux
mcoquelin has quit [Ping timeout: 276 seconds]
prabhakarlad has quit [Ping timeout: 252 seconds]
iivanov has joined #armlinux
frieder has joined #armlinux
mcoquelin has joined #armlinux
mcoquelin has quit [Ping timeout: 244 seconds]
djrscally has joined #armlinux
luispm has joined #armlinux
Pali has joined #armlinux
sszy has joined #armlinux
mcoquelin has joined #armlinux
<tmlind>
geertu: i'm seeing omaps stop booting in next with commit 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()"), seems simple-pm-bus fails with deferred probe if power domain is not yet available
<Xogium>
so... I asked over at kernelnewbies yesterday but got no answer... I'll ask here, if anyone knows
<Xogium>
is there any way to debug why, specifically, a kernel driver got unbound from a specific i2c device ? Context here is, I work on a stm32mp157f-dk2 board from st, and the touchscreen, (not display but really the touch handling) has to somehow bind multiple times to the driver
<Xogium>
it binds, unbinds, binds, unbinds, and so on for a while. Sometimes it will bind and stay put, sometimes it will unbind and I have to
<Xogium>
but there's no error at all, just multiple lines like these, with the input device number increasing at every attempt
<Xogium>
input: generic ft5x06 (11) as /devices/platform/soc/40012000.i2c/i2c-0/0-0038/input/input6
Pali has quit [Ping timeout: 246 seconds]
<geertu>
tmlind: I didn't have that issue on the SH-Mobile AG5 and R-Mobile APE6
<Xogium>
I thought it could be the psu but I'm using a rpi 4 psu, 3a@5v and 15w of power. Besides if it was a power issue I reckon I'd have much more trouble than this
<Xogium>
st also recommend a 3a@5v psu
<geertu>
Xogium: Strange, i2c does not have auto-unbind support (USB has)
tre has quit [Remote host closed the connection]
guillaume_g has joined #armlinux
<Xogium>
geertu: I know right
<Xogium>
but you can see it multiple times here, until I forcefully bind it again and it sticks
<javierm>
Xogium: can you share your DTS? As geertu said I2C doesn't have auto-unbind so something weird is going on
<javierm>
Xogium: you are using the same IRQ line for both touchscreen but the driver doesn't seem to support IRQF_SHARED
<Xogium>
mmmh what's weird is I have only one touchscreen
<Xogium>
I'm not sure why they included 2 nodes
<Xogium>
there's definitely just one of them on the board
<javierm>
Xogium: dunno, but your DTS has touchscreen@2a and touchscreen@38
<Xogium>
hmm
<javierm>
Xogium: can you remove the former ?
<Xogium>
yeah I can try that
<javierm>
2~[ 20.960996] edt_ft5x06 0-0038: Unable to request touchscreen IRQ
<javierm>
[ 20.966089] edt_ft5x06: probe of 0-0038 failed with error -22
<Xogium>
ooh good one I had missed that line
<Xogium>
hrmmm
<Xogium>
maybe I should bother st about this, because that's there dt and I did not touch anything
<Xogium>
aside from the IR sensor and beeper
<tmlind>
geertu: replied to the patch with some info and you in cc
<Xogium>
wait a bloody minute
<Xogium>
can someone quickly check if the same dt in mainline has this ?
<Xogium>
I don't have mainline here
<Xogium>
I can clone it but figured sighted eyes would be faster than I am haha
<geertu>
tmlind: Thx. As today is a renesas-drivers release day, I run some tests on all of my boards today anyway.
<tmlind>
geertu: ok seems like other power-domain dependant drivers might be broken too now
* geertu
needs to complete before the Linus vs. Dirk fireside chat at "9:30 AM" (thanks, for putting the subsession times in the descriptions, so they don't auto-adjust to local timezones)
<javierm>
Xogium: arch/arm/boot/dts/stm32mp157c-dk2.dts right? No, they only have one (@38)
<Xogium>
no the f-dk2
<Xogium>
it must be a st kernel bug, in that case, if even the upstream f-dk2 has no 2nd touchscreen
<javierm>
Xogium: there's no upstream DTS for STM32MP157F-DK2
<Xogium>
huh, really ? :O
<Xogium>
interesting
<javierm>
Xogium: well, at least one that uses the same model name than the one you shared
mcoquelin has quit [Remote host closed the connection]
<Xogium>
well then, definitely a st issue
<javierm>
I know nothing about ST boards :)
<Xogium>
the stm32mp157f-dk2 is like the 157c-dk2, the only difference is the cortex a7 is clocked at 800 mhz instead of 650
<Xogium>
well thanks for spotting that, I'll run a git blame and see who the hell did that :p
<javierm>
Xogium: it's a race so whatever is probed first win
<javierm>
and if they tested wit ha chip that has address @2a then it would had worked in their tests
<javierm>
*a
<Xogium>
yep
Lucanis0 has joined #armlinux
Lucanis0 has quit [Changing host]
Lucanis0 has joined #armlinux
nsaenz has joined #armlinux
Lucanis has quit [Ping timeout: 244 seconds]
Lucanis has joined #armlinux
Lucanis0 has quit [Ping timeout: 244 seconds]
mcoquelin has joined #armlinux
<geertu>
Xogium: I guess their idea was that only the touchscreen that responds to i2c communication will be bound?
<Xogium>
geertu: probably
<Xogium>
I guess not, after all
<Xogium>
:D
<Xogium>
but i2c isn't hotpluggable like you guys said
alexels has joined #armlinux
<geertu>
Xogium: can you try adding a WARN() to the touchscreen driver's .remove() callback, so we get a backtrace?
<Xogium>
hmmm not too sure how to do that... I'm not really a coder. I can get by with device tree stuff, but beyond that..
<Xogium>
I removed the one @2a to see if this fixes it, but pretty sure it does
<Xogium>
gonna test rn
<Xogium>
seems to work better... Though, there's still multiple bindings going on, somehow
* Xogium
scratches head
guillaume has joined #armlinux
guillaume_g has quit [Ping timeout: 248 seconds]
guillaume_g has joined #armlinux
<Xogium>
feels like silent probing fails, somehow
<Xogium>
the fact that it binds several times, doesn't that mean multiple probings ?
guillaume has quit [Ping timeout: 276 seconds]
<geertu>
Xogium: yes, during binding, it calls probe.
<Xogium>
right.. Hmm
<Xogium>
I thought that if probing failed it would say why
<geertu>
Do all the probes succeed? Or do they fail, and does your "echo ... > .../bind" just retry?
<Xogium>
I've honestly no idea
<geertu>
It depends on the driver, but drivers/input/touchscreen/edt-ft5x06.c seems to print an error message in all cases.
<Xogium>
I suspect the fact its not fighting for its IRQ anymore helped quite a lot, but I reckon if I try and try again I'll eventually have it missing on boot
<Xogium>
maybe harder, but the fact that it probes several times still seems to indicate something's wrong..
<javierm>
geertu: I wonder why the retry if the probe fails with -EINVAL no -EPROBE_DEFER
<geertu>
A few do lack a printed message, but these are very unlikely to fail
<Xogium>
right now dmesg is like this, and so far I've not gotten it to be unbound and needing a manual binding since I removed the 2a touchscreen
<geertu>
Xogium: the success case only has a debug print, though.
<Xogium>
still, it shouldn't need to bind more than once...
<geertu>
If it binds more than once, it must have been unbound in between.
<Xogium>
hmm
<Xogium>
yeah
<Xogium>
but.. why though ?
<Xogium>
would setting debug on the cmdline show this ?
<javierm>
Xogium: but which one is the one that binds, the 2a or 38 ?
<Xogium>
38, since 2a is now gone
<javierm>
Xogium: ah, I thought you were talking with the old DTS
<Xogium>
I got hold of my st contact and mentioned it to them also, and they say in the 5.15 kernel they work on the 2a has also been removed, since the @38 superceeded it
headless has quit [Quit: Konversation terminated!]
<Xogium>
but they haven't release it yet
<Xogium>
need to check that everything is fine, that OE and friends didn't break, all that
<Xogium>
so its the one @38 that keeps binding over and over and eventually succeeding
<geertu>
Xogium: Can you please add WARN(1, "unbind") to drivers/input/touchscreen/edt-ft5x06.c:edt_ft5x06_ts_remove()?
<Xogium>
I can try
sudeepholla has quit [Ping timeout: 240 seconds]
<javierm>
geertu: but who unbinds it? As to be some user-space program using the sysfs interface?
<javierm>
*has
<geertu>
Xogium: From the log, it looks like the ft5x6 probe is retried each time stm32-cpufreq failed with -EPROBE_DEFER
<geertu>
javierm: that's what the WARN() will tell us, hopefully.
<Xogium>
gah
<geertu>
From the log, it seems that the driver is probed succesfully (the message seen is printed by input_register_device(), which is the last thing that can fail)
<Xogium>
this cpufreq again
apritzel has joined #armlinux
<Xogium>
I don't know why it fails
<javierm>
geertu: ah, I saw that deferral but didn't think was related
<geertu>
Oh, the mutex_lock_interruptible() in input_register_device() could still fail, after printing the message.
<javierm>
Xogium: another thing you could do is to check /sys/kernel/debug/devices_deferred
<javierm>
before trying to manually bind
<Xogium>
if I can make it fail to bind a boot again, sure
<geertu>
javierm: the stm32-cpufreq might be a red herring.
<Xogium>
hmm wait it did bind on its own and I'll check the devic file
<Xogium>
st friend pointed I'm missing this CONFIG_NVMEM_STM32_ROMEM
<Xogium>
not sure this will solve all my issues but, its definitely a problem to solve
<Xogium>
and yeah the cpufreq thing is a red herring
<Xogium>
even with the touchscreen successfully bound at boot, its still in the devices_defered file
<robmur01>
if it's deferred, surely it can't have actually bound though? Is /sys/bus/i2c/devices/<blah>/driver set?
<Xogium>
robmur01: the touchscreen isn't the cpufreq one
<Xogium>
its the touchscreen that keeps probing/binding for a while
<Xogium>
trying to figure why it does this
<robmur01>
ah, ambiguous "it" there, never mind then :)
<Xogium>
sorry :)
<robmur01>
I'd look at the DT for every other device it depends on, see when they probe, iterate as required
<Xogium>
yeah.. I'll add the missing romem stuff, can't hurt to have it enabled :p
<robmur01>
(on which note, from a quick look I'd bet cpufreq is waiting for its SCMI clock)
<Xogium>
see where that goes
<Xogium>
yep I was right; adding that romem stuff made ethernet and cpufreq device probe fine. It warns me only once about the failed to get chip info message
<Xogium>
so those ones are fixed at least hahaha
<Xogium>
back to touchscreen, I reckon
<robmur01>
FWIW often the initial DTB order simply leads to devices being created in pathological reverse order of their dependency chain, and that order tends to carry through to the deferred probe list, so that can end up cycling through several times to get everything done
<Xogium>
yeah that makes sense
<Xogium>
but in this case it still shouldn't bind and unbind crazily seeing as its an i2c device
<javierm>
Xogium: yes, that's a separate issue
<Xogium>
yeah but, I'm glad the romem fixed the 2 others I was having haha
<Xogium>
so I need to put that warning in the function right ?
<robmur01>
does the i2c controller create its children before its own probe is guaranteed not to fail?
<Xogium>
robmur01: I've no idea...
<robmur01>
could be that the whole bus is being set up and torn down multiple times
<robmur01>
I'd stick a WARN() or dump_stack() in edt_ft5x06_ts_remove() as well
<Xogium>
ah
hanetzer has joined #armlinux
<Xogium>
the warn didn't show at all
<Xogium>
I added it there intially
<Xogium>
*initially
snalty_ has joined #armlinux
snalty has quit [Ping timeout: 246 seconds]
<robmur01>
I don't see any obvious way (or reason) for input_device_register() to return -EPROBE_DEFER, so if that was failing I'd expect it to be fatal and prevent any further re-probe attempts, thus the suspicion that whatever's happening is at a higher level beyond this driver
<Xogium>
robmur01: the defer one was cpufreq
<Xogium>
this one doesn't defer, at least that I can see... It just binds and binds and binds again
<javierm>
robmur01: that's my intuition as well, something is doing the unbind/bind in a loop
<Xogium>
which means that somehow the probe is failing, or that it gets unbound and bound again in a short loop
sudeepholla has joined #armlinux
<robmur01>
OK, so like I say if someone *is* tearing it down again, a stacktrace from its .remove should shed some light
<Xogium>
but shouldn't a warn do the trick as well ? Because I tried that first and that gave absolutely nothing
<robmur01>
yes, WARN is one way to give a stacktrace
<Xogium>
righto, and that did nothing
<Xogium>
so... :/
<robmur01>
it's not just that multi-touch devices end up creating separate input devices for each point, is it?
* robmur01
has no experience of the input subsystem
<Xogium>
neither do it to be honest, let alone with touchscreen devices
<Xogium>
*neither do I
luispm has quit [Quit: Leaving]
luispm has joined #armlinux
<Xogium>
but if that was the case then I'd have multiple events and input devices in /dev, right ?
<Xogium>
fwiw with an IR sensor and a remote, it creates only one input device
<Xogium>
so I'd kinda expect touchscreen to be the same
<robmur01>
yeah, if the lower-numbered devices aren't there by the end, then they probably are being torn down and replaced - in that case I'd probably confirm how input_register_device() is being called each time
<Xogium>
oh yeah they are definitely not there in the end, that much I can tell
<Xogium>
but if they were torn down, wouldn't I see it with a warn ? Because I definitely got nothing. That's what weirds me out
<Xogium>
in the boot, it bugged and isn't showing up again
<Xogium>
the current one
<Xogium>
so, there were 2 possible causes for the touchscreen issue, one we didn find and fixed, the fighting over IRQ, but the second one is still here. But the issue has become proportionally harder to hit since it's partly solved
<Xogium>
*one we did find
matthias_bgg has joined #armlinux
sudeepholla has quit [Ping timeout: 246 seconds]
headless has joined #armlinux
gpiccoli has quit [Quit: Quit...]
gpiccoli has joined #armlinux
sszy has joined #armlinux
mcoquelin has quit [Quit: Leaving]
mcoquelin has joined #armlinux
torez has joined #armlinux
headless has quit [Quit: Konversation terminated!]
frieder has quit [Quit: Leaving]
<hanetzer>
question, is there any example of an arm chip with an hdmi controller, but no proper gpu behind it?
<alexels>
,fs
alexels has quit [Quit: WeeChat 3.5]
<broonie>
hanetzer: What do you mean by "behind it"? It's common for the GPU and display controller to be parallel IP blocks so there's no need to interact with the GPU at all in order to use any of the displays.
prabhakarlad has joined #armlinux
<geertu>
hanetzer: And what do you mean by "no proper gpu"? ;-)
XV8 has joined #armlinux
<hanetzer>
I mean there's no mali/etnaviv/etc gpu on the device. just a lot of ip blocks for encoding and decoding video and audio :)
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
<geertu>
hanetzer: Renesas RZ/G2UL has a CRTC but no GPU. It does not have builtin HDMI, but the devboard seems to come with an external Parallel to HDMI Conversion Board.
<hanetzer>
what dts/i does that use?
<robmur01>
many things have *some* kind of display output without any GPU, but HDMI specifically might be rarer
<jn>
even on apple M1 computers (due to *current* software limitations under linux, which are soon to be lifted), you'll get a working display controller but no working 3D GPU
<robmur01>
since including HDMI on the SoC would tend to imply targeting consumer devices, and most of those these days will want to run Android, or at least render a sufficiently fancy UI to warrant some form of GPU acceleration
<hanetzer>
gotcha. my interest here is in the driver structure/dt bindings of such a device.
<geertu>
hanetzer: r9a07g043u11-smarc.dts, but the LCDC is not yet enabled.
<hanetzer>
robmur01: well, the soc family I'm working on are in consumer hardware, yeah, but (generally speaking) they're slapped into cctv dvr/nvr boxes.
<jn>
hanetzer: the crucial point is just that there is often no inherent connection between display controller and GPU, in ARM SoCs, so there's really nothing special about a SoC with HDMI and without GPU
<hanetzer>
gotcha.
<geertu>
hanetzer: If you want something with working HDMI, check out r8a77951-salvator-xs.dts. No GPU, as powervr is not supported.
<broonie>
The GPUs generally just operate as memory to memory devices sharing system RAM with everything else.
<hanetzer>
yeah, that's how panfrost works iirc.
<hanetzer>
jn: I'm still waiting on those hi3536d boards to come in. I think they'll be quite useful, especially since they're so cheap :)
<_jannau_>
jn: there is not even a working display controller (driver) on M1 atm, it's just simpledrm on the firmware provided framebuffer
<robmur01>
in actual end products, the middle ground is more likely to be an external HDMI encoder chip driven by some raw RGB output from the SoC
<robmur01>
(see the Arm Juno board for an example of that off the top of my head)
<robmur01>
((although that does happen to have a GPU as well, but as above it's entirely tangential))
<geertu>
tmlind: No anomalies detected owith simple-pm-bus on SH/R-Mobile
<hanetzer>
robmur01: yeah, I'm aware of that design paradigm :)
<Xogium>
geertu: by the way investigating with st guy about what might be going on with the dmesg output + patch my friend made
<_jannau_>
the hdmi ports on apple silicon machines are driven by 80186 based displayport to hdmi converter
<tmlind>
geertu: ok thanks for checking
Pali has joined #armlinux
monstr has quit [Remote host closed the connection]