ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
alpernebbi has quit [Quit: alpernebbi]
alpernebbi has joined #aarch64-laptops
<akaWolf0>
what is for «Qualcomm remote filesystem» using in x13s? just a modem?
<akaWolf0>
the same question about «Qualcomm IPC router»
<bamse>
akaWolf0: the rmtfs service provide disk access for the modem in socs with builtin modem, x13s has (optional) pcie modem, so that's not needed
<bamse>
akaWolf0: ipc router is used for communicating between software services on various coprocessors in the soc...in linux this is implemented in net/qrtr/
<akaWolf0>
bamse: I've look a bit into pd-mapper, looks like it's read info from /sys/class/remoteproc and write into qrtr
<akaWolf0>
what kind of info does it read?
<bamse>
akaWolf0: it looks in /sys/class/remoteproc/*/firmware to find the path of the firmware files, it then searches for json files in this/these directories, and when requests arrives for that information it replies
<akaWolf0>
bamse: yeah, okay. but what kind of firmware can it find at x13s platform?
<bamse>
akaWolf0: in remoteproc specifically we so far have firmware for the audio and compute DSPs
<akaWolf0>
and why we need to through info over userspace?
<akaWolf0>
why doesnt that happens in kernel?
<bamse>
because as it was introduced we had qrtr-ns, rmtfs and tqftpserv (iirc) that already ran in usserspace
<bamse>
qrtr-ns was migrated to kernel...rmtfs and tqftpserv are not used on x13s
<akaWolf0>
so it is a legacy?
<bamse>
yeah
<bamse>
it would make sense to move it into kernel now (but we probably need to drop the json formatting)...
<bamse>
but that said, i'm hesitant of moving the kitchen sink into the kernel...
<akaWolf0>
yeah I understand
<steev>
i'd say do it anyway... but i'd rather see GPU on the x13s first ;)
<steev>
bamse: do you happen to have the lore link for your patches that vastly improved the memory bandwidth?
<bamse>
we should....but i consider it lower priority...
<bamse>
steev: i don't have that infront of me
<steev>
i don't either, but i can dig through the kernel to find it :)
<steev>
i wanna see what the hell you did because the radxa rock 5b's memory speed is like... exactly how we were pre-those patches
<bamse>
akaWolf0: ahh "server" is a qrtr client that implements some sort of service
<bamse>
akaWolf0: which service it implements is identified by the service and instance fields
<bamse>
akaWolf0: so that snippet handles the message from some other node in the "network" where it informs us about what services it implements (or when a new service was created there)
<bamse>
akaWolf0: note though, that src/ns.c is no longer running...net/qrtr/ns.c in your kernel does this book keeping today
<steev>
oh, good point
<akaWolf0>
bamse: but if I install those package (qrtr in arch) I guess it will starts?
<bamse>
akaWolf0: not by installing it, but iirc pd-mapper depends on it...so that will start qrtr-ns
<bamse>
akaWolf0: i mean the pd-mapper systemd service will cause the qrtr-ns service to start
<akaWolf0>
bamse: yeah that's right. so it should be fixed to not run?
<bamse>
akaWolf0: but qrtr-ns will determine that we already have a ns running in the kernel...and do nothing
<akaWolf0>
bamse: ah I see
<bamse>
akaWolf0: yeah, but i don't know how to write that systemd unit file...
<bamse>
akaWolf0: something like "if qrtr-ns.service is enabled, launch it before pd-mapper, otherwise allow pd-mapper to run without qrtr-ns service"
<akaWolf0>
bamse: what kind of services there can be? I'm about Qualcomm one's.
<bamse>
the first bunch implements the "api" to control the modem, which is where this protocol originates from
<akaWolf0>
bamse: well thanks for explanations :)
<akaWolf0>
so for the case w/o modem there are needed just pd-mapper and qrtr packages which will be moved into kernel in the future
<steev>
qrtr already is
<bamse>
only pd-mapper...as the only thing the qrtr package provides, that's actually used (or could be used) is qrtr-lookup
<bamse>
akaWolf0: but i believe that is the case, yes...
<akaWolf0>
bamse: I guess qrtr is needed because of user-space qrtr library which is used in pd-mapper
<bamse>
akaWolf0: ahh, yeah that's right
<bamse>
akaWolf0: but there's already an in-kernel version of those helper functions
<akaWolf0>
okay I got it. I agree that functional like GPU is at the top proirity before refactoring like so.
<akaWolf0>
I dont think I can help to you guys having datasheets when I have no experience in those subsystem and w/o DSs :)
<bamse>
akaWolf0: most of us started doing this work with the downstream source as reference...
<bamse>
akaWolf0: and for many that's still the only source of information
<bamse>
akaWolf0: and the datasheet would only describe the last layer, there's plenty of software on top of that ;)
<akaWolf0>
bamse: yeah sure I know what describes DS, but IIUC the problems with GPU is more related to lower layer like HW
<bamse>
akaWolf0: there's plenty of other things missing or semi-broken
<bamse>
akaWolf0: one thing i suspect is fairly straight foward is venus, but no one has looked into that yet
<akaWolf0>
bamse: why do you think it's straight forward?
<bamse>
akaWolf0: there's a downstream driver for the platform...and there's an upstream driver for similar platforms...transplant the details, add firmware and it should work :)
<akaWolf0>
bamse: sounds interesting, maybe I can look into this if noone will not do that before
<HdkR>
"should"
<bamse>
has almost never failed before ;)
<bamse>
well, the gpu is the exception.. :P
<akaWolf0>
HdkR: well even hello world is often easy to write with errors :)
<akaWolf0>
bamse: can you send me a links for downstream and upstream implementations of venus driver? well I guess I can find upstream at my own :)
<bamse>
akaWolf0: i've only glanced over the git log for the downstream kernel...so it's not completely unlikely that HdkR is right and i've missed something cruzial...but it's worth giving it a go
<bamse>
akaWolf0: comparing the properties in dt with what you find in upstream sm8250.dtsi the only difference i can see is iommus is 0x2e00 on sc8280xp and 0x2100 on sm8250...
<bamse>
akaWolf0: ahh and the sc8280xp node doesn't have the video_cc_mvs0c_clk_ares reset
<bamse>
sorry, that's the upstream driver in the downstream tree...not the actual downstream driver...
kettenis has quit [Remote host closed the connection]
kettenis has joined #aarch64-laptops
<jhovold>
javierm: yes, we use a dtb. I used simplefb before we had support for the MSM DRM driver, but I never thought about describing the resources in DT. I'll take a look, thanks!
matthias_bgg has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
SSJ_GZ has quit [Ping timeout: 480 seconds]
xypron has quit [Quit: xypron]
xypron has joined #aarch64-laptops
xypron has quit []
xypron has joined #aarch64-laptops
xypron has quit []
xypron has joined #aarch64-laptops
xypron has quit []
xypron has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
Guest52 has quit []
<bamse>
jhovold: i think it becomes a little bit excessive to have efifb hand over to simplefb (if that's even possible) and then that hand over to msm drm...
<bamse>
jhovold: and it would be more elegant to move the regulator framework off the 30 second timeout onto sync_state...just like all the other subsystems
<javierm>
bamse: I thought more about using a simple-frambuffer instead of the EFI-GOP
<jhovold>
bamse: simplefb would replace efifb
<javierm>
bamse: I once tried to propose a regulator_ignore_unused like we have for clocks and power-domains but IIRC broonie didn't like the idea
<jhovold>
bamse: javierm: I've been playing with it today, and it sort of works. There's a conflict currently as sysfb registers a simple-framebuffer even when one is defined in DT
<javierm>
jhovold: right, you need to disable CONFIG_SYSFB_SIMPLEFB I believe
<broonie>
sync_state() needs to be fixed so that it can cope with treating each regulator individually.
<javierm>
jhovold: because that's already handled by the OF core
<broonie>
Otherwise that's the general idea.
<jhovold>
bamse: javierm: it works for regulators, but for clocks we'd still be relying on clk_ignore_unused as trying to define them messes up the frequencies
<javierm>
jhovold: yeah, I knew you were booting with "clk_ignore_unused pd_ignore_unused" so I was thinking only about definining regulators
<broonie>
Though the timeout seems only tangential to sync_state()?
<javierm>
what's the timeout ?
<broonie>
The 30 second delay before we turn off unused stuff.
<javierm>
ah, I didn't remember that was a timeout but thought was in late init call or something like that
<broonie>
There's a late initcall that starts a timer.
<javierm>
broonie: right, I was looking now at the code and commit 55576cf18537 ("regulator: Defer init completion for a while after late_initcall")
<javierm>
so I wasn't misremembering, just didn't look at the regulator core for some time :)
<javierm>
broonie: there's a driver_deferred_probe_timeout now, I wonder if those two can be tied together
<javierm>
so then deferred_probe_timeout=60 could also increase the regulator unused power off
<broonie>
IIRC John Stultz sent some patches for that which went badly.
<javierm>
broonie: he tried to change the default to 30 secs (currently is 10 sec) but you can still change using a kernel cmdline param
<javierm>
but I think that makes sense to make the regulator core aware of the probe deferral timeout, since those two are kind of related
<javierm>
you have a 30 secs to make sure that things won't get unused too early
<javierm>
broonie: hmm... that's no longer accurate, driver_deferred_probe_timeout was revereted to 0 but then set to 10 again
<javierm>
broonie: f516d01b9df2
<javierm>
so I think that makes sense to revert that revert now
<javierm>
revert 2a15483b401c I mean
<javierm>
jhovold, bamse ^ ?
<javierm>
I think that would make sense to have a single place where the timeout for "we have finished loading drivers" should be defined
<bamse>
jhovold: we're running on an EFI system, which gives us an efi framebuffer...we should use that
<bamse>
broonie: i would like to have the timer start at sync_state, rather than late_initcall...
<broonie>
bamse: Well, get on to Saravana about implementing sync state....
<bamse>
broonie: the problem we're having is that if we fail to mount the root filesystem we end up in the ramdisk console, but after 30 seconds the regulator timer turns off the display power
<bamse>
jfyi...
<bamse>
broonie: we could ask Saravanna to fix it...or just hack something up ourselves...if the itch is great enough ;)
<broonie>
I guess convincing whatever makes the ramdisk to include the display modules would also avoid the issues.
<javierm>
bamse: honestly, it would had been better to have a way for user-space to notify that no drivers would be registered anymore instead of a timeout for probe deferral
<broonie>
Yes, that would be the ideal thing.
<bamse>
broonie: it comes with a massive amount of dependencies
<broonie>
A boot complete handover from userspace.
<javierm>
broonie: yeah
<bamse>
javierm: that would be a wonderful idea...Linus answer to my suggestion of that ended up on the front page of theregister
<javierm>
bamse: I see...
<bamse>
i have a similar problem in remoteproc, where i don't want o pack 200mb of firmware files into the ramdisk...so i would like to know when /lib/firmware (and friends) can be considered populated
<javierm>
bamse: btw, I thought that the EFI spec said that one could use the EFI-GOP without worrying that some of the required resources (clock,regulators,power domains) would go away
<javierm>
but I guess the EFI firmware on these machines isn't really standard EFI
<bamse>
broonie: but you don't have any objection against the notion of pushing the timer to sync_state? (or selectively replacing it with sync_state)
<broonie>
The issue with sync_state() at present is that it operates over the entire MFD for MFDs which means that it breaks things like using the enable/disable to control a SD card enable if any other device didn't probe.
<bamse>
javierm: i don't see how EFI could provide that guarantee, given that the regulators are driven from Linux
<bamse>
broonie: you mean if we don't allow disable until sync_state?
<javierm>
bamse: right. I guess that's only true for SystemReady-{ES,SR} then but not SystemReady-IR
<broonie>
So sync_state() is fine but needs to be per resource .
<broonie>
Yes.
<bamse>
broonie: okay, what we're discussing in the clock drivers is that those are different things; i.e. turning off unused resources and ensuring that resources are kept alive until sync_state
<bamse>
broonie: i was think of only the disablement of unused resources here
<bamse>
thinking*
<bamse>
and i can certainly see how avoiding disable will cause issues for hardware that needs to loose power as part of some reset sequence etc
<jhovold>
bamse: regarding efifb, I tend to agree, especially as we won't be able to describe all resources to simplefb anyway (i.e. clocks)
<bamse>
jhovold: and we're aiming to introduce Abel's changes to not disable unused clocks until sync_state (per clock provider)...so that won't happen until you have loaded a sufficent amount of modules
<jhovold>
bamse: sounds good, is anyone looking at doing the same for genpd?
<javierm>
bamse: but that would still happen at late_initcall_sync() right?
<javierm>
I don't understand how it would work with your case of not being able to mount the rootfs
<bamse>
jhovold: i started, but not that i'm aware of...
<bamse>
javierm: because sync_state for a provider is called when all the devices with incoming references has probed...and when we sit there in the ramdisk we either have a fully probed display driver...or it's yet to be loaded/probed and hence sync_state has not yet been called
<bamse>
jhovold: in 6.2 rpmhpd will keep its poewr-domains on until sync_state...and then disable the unused ones
<bamse>
jhovold: but we don't do the same for gdscs...and when genpd tells us to disable unused pds during late initcall i just say "yes yes" and ignore it...so that's not entirely pretty
<bamse>
jhovold: but the difference is that rpmhpd power-domains are mostly shared resources...so keeping them on does not seem to be an issue
<jhovold>
bamse: ah, ok, so not quite there yet
<bamse>
jhovold: do you work on friday?
<jhovold>
bamse: yeah, probably
<bamse>
let's touch on this topic (disable unused resources) then
<javierm>
so I thought that it would be called anyways at late_initcall_sync()
<javierm>
ah, but it's postponed. I see
<bamse>
javierm: the list of consumers is built from devicetree, so we know that we expect more consumers and hence sync_state isn't yet called
<javierm>
bamse: got it. Makes sense
<javierm>
bamse: so it will never be disabled because it's needed by the adreno GPU as described in the DTB, even when no msm DRM driver is registered and the device bound
<bamse>
javierm: yes, but DPU (display processing unit)...as the GPU is more or less completely separate
<javierm>
bamse: right, I wanted to say the display controller indeed :)
<javierm>
bamse: thanks for the explanation
laine has quit [Ping timeout: 480 seconds]
laine has joined #aarch64-laptops
laine has quit [Ping timeout: 480 seconds]
systwi_ has quit [Ping timeout: 480 seconds]
systwi has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
<clover[m]>
im back from travelling, steev anything you want me to test
matthias_bgg has joined #aarch64-laptops
<steev>
clover[m]: at the moment... nothing i can think of, unless you didn't do the audio testings
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<clover[m]>
did you get audio fixed? last i saw it worked a bit but it was buggy
SSJ_GZ has quit [Ping timeout: 480 seconds]
<steev>
no, still not working and it's far above my paygrade
<steev>
we seem to hit an underflow and that fucks it
<steev>
edac/llcc base address fixes are inc, but waiting on mani to incorporate a local patch and push out v4 before i'm willing to push it for people to test
<akaWolf0>
clover[m]: let's update the wiki status of working things :)
<clover[m]>
maybe if i update the wiki to say sound will work, it will start working