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)
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
SallyAhaj has quit [Remote host closed the connection]
jhovold has joined #aarch64-laptops
flowriser has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
<steev>
oh good, i was JUST looking at seeing rc1
<steev>
that revert is likely important
<bamse>
very
<bamse>
but the revert will likely fail to apply in -rc2, as there's a follow up which breaks it just a tad bit more
<steev>
lol
<bamse>
so hoefully we can get both of those reverted
<steev>
would it not be better to get them fixed instead of reverted?
<bamse>
it was already fixed...
<bamse>
it relates to how one describes a panel under a dsi host...before this release if you have a panel described as a child of your display controller you still need to have a of_graph (ports/port) pointing the controller to its (potentially only) child node
<bamse>
the fix i revert removed the need for the of_graph, so it will just pick up the panel
<bamse>
but in the case of DP we don't have a panel, we have a aux-bus...and perhaps an opp-table, so looking for a node and seeing if that's a probed panel isn't going to work
<bamse>
i.e. the new logic is "find the child which is not named ports or port, check if it's a registered panel, return -EPROBE_DEFER"
<steev>
ah
<bamse>
so on c630 display doesn't come up because aux-bus is not a probed panel
<steev>
makes sense
<bamse>
on flex 5g display doesn't probe because opp-table is not a probed panel
<steev>
ahhh
<steev>
have reverted here, i have just a few more patches on top (audio and cpufreq stuffs)
<steev>
but i believe they're coming down the pipeline
<steev>
and that revert is likely why next has been broke for me lately i just haven't looked at it
<steev>
the TEST-ONLY and fnctl thing can be ignored
<bamse>
okay, the 4 patches from dmitry are good, but are only relevant if you do cpu hotplug
<steev>
and the "fix some battery dependency" is for when you do... i dunno how it's properly called, but the way debian builds their kernels, the some-battery module fails because the dependency on i2c was missing
<bamse>
the two last patches, from validimir, doesn't apply to 845...and in their current state are in fact wrong for 845
<steev>
oh that's good to know, i test things like that to make sure they don't break
<bamse>
nah, the fix throttle...that's ok...but doesn't do anything on 845
<bamse>
the "clear dcvs interrupts" needs a guard to not exectue on 845
<bamse>
the "lmh: fix irq handler return value"...that's one you definitely should have; after hitting thermal mitigation limits enough times the irq framework will decide that you don't handle that irq and stop serving it...so we should push for getting that into v5.18 (if it's not already there)
<bamse>
the smem ones, send a t-b if you prefer, and then you can drop those from your tree
<xnox>
why can we not submit this some battery driver upstream? it's been years now =)
<steev>
because it's not "correct"
<xnox>
can "correct" not be an enemy of "good enough"? or like try to at least push dtb change; with some-battery as dkms module.
<xnox>
or like what needs to happen for it to be "correct"? pick a better name for it?
<xnox>
yoga-c630-battery
<steev>
i believe we actually want the ec driver which until fairly recently wasn't known what ec chip we have
SallyAhaj has quit [Read error: Connection reset by peer]
SallyAhaj has joined #aarch64-laptops
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
<xnox>
also hi krzk ! =) wonder if you get to work on these things more ;-)
<bamse>
xnox: the thing we talk to is apparently not a battery controller, but the EC (embedded controller)...
<bamse>
xnox: in particular, the same EC implements USB Type-C handling
<bamse>
xnox: i have patches under review that adds a few things to the plumbing between a type-c controller, a displayport controller and the type-c mux(es)...once that's landed i was planning to extend the some-battery driver to deal with that stuff as well
<bamse>
xnox: and give it some made up name...as we don't know what it actually is (i.e. is it c630-specific firmware etc)
<xnox>
ack
<bamse>
xnox: but given that it's the only patch that prevents me from running the kernel that arch linux provides me...i think it would be really nice to get it upstream
<steev>
Probably same thing tbh, just different firmware
<steev>
Hell, may be the same firmware just recompiled for arm
<bamse>
krzk: but we're probably looking at a "Lenovo Yoga C630"-specific firmware that provides battery info, usci and type-c altmode information at least
<bamse>
oh and then there seems to be some status bits indicating which touchpad we have :)
<bamse>
or is it which screen we have? one of those comes from a gpio and the other from an EC read
<bamse>
krzk: i've been meaning to clean up our power-supply driver and get it upstream, but i've had the plumbing for displayport on the list for a while now, with that in place it seems plausible to get working usb/displayport going
<derzahl>
do you guys know if the snapdragon suffers the same ~20% performance hit using 4K page granularity as the m1 does?
<bamse>
derzahl: i'm not familiar with any efforts of running > 4k pages on snapdragons
<derzahl>
from what Ive read 4k granularity is purely for x86 compatability, its not a thing for arm64
<derzahl>
and maintaining that compatibility is at a cost
<broonie>
derzahl: Most arm64 implementations expect to be run at 4K since it's the page size most commonly used by the most widely available OSs - RHEL and derivatives do use 64K but they're in the minority.
<derzahl>
perhaps, im guessing android runs at 4k? but does that mean there is no performance penalty for doing so?
SallyAhaj has quit [Remote host closed the connection]
<bamse>
derzahl: the qualcomm ufs driver goes belly up if i try to boot with 16k pages
<bamse>
derzahl: then the qualcomm ipa driver goes boom...
<bamse>
derzahl: but overall it was better than expected ;)
<derzahl>
ah, interesting
<derzahl>
you can change at boot?
<derzahl>
whats the param?
SallyAhaj has joined #aarch64-laptops
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
<bamse>
in menuconfig "Kernel Features" -> "Page Size"
<bamse>
although had it not crashed i wouldn't have known if it actually made any difference...as i said, i'm not aware of any efforts to look into this before
<derzahl>
i meant boot param
<derzahl>
oh, you meant you compiled with 16K previously?
<bamse>
i'm not aware of any boot param for it
<bamse>
i changed it and recompiled the kernel
<xnox>
broonie: ubuntu offers generic and generic-64k; we think that almost nobody uses generic-64k on arm64.....
<bamse>
derzahl: you definitely would be able to find use cases where 4k pages are slower than 16 or 64k pages, if nothing else due to the limited size of the tlb
<bamse>
derzahl: but is there any specific "performance penalty" you're referring to?
<derzahl>
bamse: not sure, just reading through asahi documentation. nothing specific was mentioned for the performance hit
<bamse>
derzahl: would certainly be interesting to get some more insights into the kind of use cases they are looking at
<bamse>
derzahl: as far as i know the kernel is mapped using 2mb pages, so that should be taken care of...
<derzahl>
so what about 64k? should that be even faster? what would be the downsides there?
<broonie>
The larger the page size the more wasted memory you have when you need small allocations, and the more data you have to eg, fault in from disk every time you get a page fault.
<derzahl>
seems like 64k is semi common, but 16k is the outlier?
<derzahl>
broonie: ah, makes sense. so 16k is kind of a happy medium
<bamse>
derzahl: i ran some tests and created some bug reports on our side for the things that broke, but afaict this is low priority until we can show some benefit of going there
<broonie>
That's the theory, yes - what makes sense depends a bit on your expected usage/access patterns.
<bamse>
derzahl: one of the things that doesn't probe is ipa (the lte/5g network driver)...and there's a few places where we lug around a single packet per page
<robclark>
iirc there were some aspects of apples design (cache hierarchy) which preferred 16k page sizes.. I'm not sure I remember the details.. probably from anandtech writeup on the m1
<derzahl>
bamse: when did you test 16k last?
<bamse>
derzahl: so best case you get a full frame of 1500 bytes and only waste ~14.5kb of memory per packet
<robclark>
I think 64k is more targeted towards servers with massive amounts of ram
<bamse>
robclark: that would make sense
<broonie>
Yeah, if you know you're going to be running a particular configuration/application you can optimise for that.
<broonie>
robclark: Databases are the traditional thing, they have access patterns that tend not to notice the costs so much and get some benefits.
<bamse>
derzahl: the drawback of going up is that you might waste memory by having under-utilized pages...the benefit is that you have fewer pages to handle (and cache)
<bamse>
derzahl: of as robclark says, there might be hardware optimizations for a particular case
<bamse>
but in particular the ~20% performance difference tells me that it's not the usual "waste vs caching" balance
<bamse>
derzahl: i've never booted the kernel with >4k before today...so i don't have any comparison, but it's my opinion that the qualcomm drivers should deal with 16 and 64kb pagesize, so i created the bugreports for that
<derzahl>
bamse: oh, so you just recompiled to 16k today and tried? i wont bother then
<bamse>
derzahl: yeah, i had a v5.18-rc1 tree in front of me...so no need to burn electricity on that
<robclark>
so 20% perf impact is more likely about not being able to use entire L1$
<robclark>
which wouldn't really apply on non-m1 SoCs
<derzahl>
robclark: interesting. thanks guys for helping me further understand the implication of different page sizes
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
flowriser has joined #aarch64-laptops
<arnd>
robclark, derzahl: as far as I understand, 64k is targeted mainly at benchmarketing: you get a tiny performance benefit that may just be enough to put RH ahead of Ubuntu in a 1:1 comparison on most low-level benchmarks, at the cost of making it worse for any workload that uses more than half the available RAM
<arnd>
the reason that 16kb is not widely used is that all Cortex-A cores can do 4KB and 64KB, but 16KB only started with Cortex-A73, so A53, A57, A72, and A35 don't support it
<arnd>
Apple in turn doesn't support 64KB any more with the M1, even though some of their earlier phone chips did
<steev>
bamse: 5.18rc1 with that revert working here, will send the t-bs and... at some point figure out sending the patch for removing the turbo-mode
<robclark>
arnd: iirc you also need 64k page sizes for maxing out amount of ram.. which is maybe a thing rhel/etc care about
SallyAhaj has quit [Remote host closed the connection]
<arnd>
robclark: the physical address space is the same (40, 44 or 48 bits) regardless of page size, it only depends on the core type. ARMv8.2 introduced 52 bit phys with 64KB pages, but RH already had that page size before that came, and nothing so far actually uses as much. I think the latest cores can now do 52 bit PA even on other page sizes (but Linux doesn't yet)
<robclark>
ahh
<arnd>
the VA space is a little more interesting, but again when RHEL started using 64K pages, it was 48 bits for any page size, you just need an extra level of page tables
SallyAhaj has joined #aarch64-laptops
<derzahl>
steev: whats new with 5.18rc1? did you just update recently?
<derzahl>
i dont see any recent updates besides the radxa 5.16 kernel
<steev>
derzahl: well bamse just alerted me today to his branch (which is the battery and a revert)
<steev>
i don't push before i test
<steev>
there's a picture above somewhere of the commits i have on top
<steev>
i dropped the botttom 2 based on bamse feedback
<steev>
and the TEST-ONLY should really be dropped, i can't test it anymore, it's for the panel in gwolf's c630
<steev>
but conceivably, it should draw less power
<derzahl>
oh ok, what exactly do they battery fixes do?
<derzahl>
gotcha
<derzahl>
nice
<steev>
the battery math fixes are so that it reports numbers that are more correct
<derzahl>
why would gwolfs c630 have a unique panel?
<steev>
the dependency is just depending on i2c otherwise debian's build system for kernels is unhappy because it tries to use i2c functions without the dependency
<steev>
the c630 has 2 different possible panels
<steev>
his has the boe, mine has the.... i don't remember... n something
<steev>
i only know this because i sold him it :P
<derzahl>
ohh, interesting..maybe I have he same one he does? since i continually have display problems at boot that you dont seem to have
<steev>
possibly
<steev>
but he should be reporting them too then
<derzahl>
currently with your 5.17 I get a blank display at boot
<steev>
all that patch does is change the mahts
<steev>
are you using dtbloader and copying in the dtbs?
<derzahl>
but if i type my unlock password it will boot and come back on
<steev>
ah right, i remember you mentioning that
<derzahl>
not using dtb loader. i modified grub scripts so that it always adds the current dtb to the 'devicetree' line
<robclark>
steev, derzahl: the panel # comes from UEFIDisplayInfo .. and then dtbloader loads a dt overlay based on that #
<robclark>
ie. like \dtb\$SysVendor\$ProductName-$BoardName-panel-$PanelId.dtb
<derzahl>
ok, so no benefit with my panel then compared to loading that standard dtb with grub?
<derzahl>
oh, and just to clear this up. I think dtbloader is doing something that eliminates the need for 1 or 2 of the following options: "efi=novamap clk_ignore_unused pd_ignore_unused"
<derzahl>
right?
<derzahl>
but since im not using dtbloader, I think i still need them. correct?
<derzahl>
IIRC i dont seem to have issues if I remove efi=novamap, but removing clk_ignore_unused and/or pd_ignore_unused gives me boot issues
<robclark>
dtbloader isn't doing anything for *_ignore_unused.. and IIRC kernel defaults to efi=novamap now
<robclark>
and tbh, the panel picking thing is a bit less critical these days if the panel has a valid edid
<robclark>
so main thing dtbloader is doing is figuring out which dtb needs to be loaded and loading it for you
<bamse>
steev: i've not posted the revert anywhere...but i reported it and i think we agreed to revert the (now two) patch(es)
<derzahl>
robclark: ok hmm. I thought steev said that clk_ignore_unused isnt needed anymore. but I get problems without it.
<bamse>
clk_ignore_unused is definitely needed :(
<steev>
pd_ignore_unused is the one that isn't needed
<steev>
clk is definitely needed, but there were some patches that were nacked that helped a bunch there
<steev>
apparently the clk framework needs a lot of work to fix up
<bamse>
in a larger effort of fixing it we concluded that omitting clk_ignore_unused with a kernel that has kernel modules is broken and a different approach is needed
<bamse>
the problem is simply that we're looking to see what clocks looks to be unused before the kernel modules has been loaded and had a chance to tell us that they indeed need some of those clocks
<derzahl>
" <steev> derzahl: i pushed my 5.15 stuff earlier - one thing, you should drop the clk_ignore_unused command line parameter"
<steev>
yes
<steev>
that was back in 5.15 and then... bamse corrected me
<steev>
those patches were dropped in newer kernels
<derzahl>
oh ok
<derzahl>
good to know
<derzahl>
ill try with just clk_ignore_unused
<derzahl>
i noticed asahi is using CONFIG_NO_HZ_FULL=y , can that be used with sdm850?
<steev>
yes
<derzahl>
sweet. does that reduce power consumption alot?
jhovold has quit [Ping timeout: 480 seconds]
<steev>
doubtful
<steev>
the majority of your power consumption is gonna come from the screen
<derzahl>
is there a consensus on timer frequency? I think you are using 250hz right Steev? Im currently using 1000hz just for testing. hard to notice a difference
<steev>
1000 is recommended(?) for desktop, iirc, the deffconfig i use is simply based on debian's and that is why it is what it is
<steev>
i think at one point i moved mine to 1000, but forgot to commit it and lost it
<derzahl>
ah ok
<derzahl>
any opinions on third party schedulers? Ive been using cacULE for awhile not and i feel like I have better responseiveness under load
<steev>
no idea what that even is
<derzahl>
but of course its hard to quantify
<steev>
realistically, if you care *that* much about performance and power usage, you're gonna need to run stuff to monitor it all in the background and see what is what
<derzahl>
oh, youve never played with cacULE, TT, bore, or the PDS schedulers?
<steev>
no
<steev>
again, no idea what those are
<derzahl>
cacULE is pretty basic. its just an add on the the default CFS scheduler
<steev>
i'm too old to be doing arch/gentoo type granularity these days
<derzahl>
based on the freebsd scheduler, which takes into account which application is being used primary and tries to give it more cpu time
<bamse>
derzahl: make idle-states {} in sdm845.dtsi look like e.g. sm8250.dtsi, that will likely blow any efforts your looking at out of the water
<derzahl>
steev: haha, i hear you. ive just been getting back into it recently.
<derzahl>
havent bothered since back when I played games in college on the 2.4/2.5 kernels
<derzahl>
bamse: what does that do exactly? Im still very unfamiliar with dtb stuff
<derzahl>
bamse: also, can you point me to your kernel branch?
<derzahl>
bamse: I think you told me to compile with lto last time right? I got that working
<bamse>
derzahl: when you're idling in psci (firmware based) device you state how hard you want it to idle...on 845/850 we just go to the most shallow state, so we're wasting power by not idling the cores properly
<derzahl>
sm8*50.dtsi also has domain-idle-states {}
<derzahl>
this is way over my head. Unless just copy/paste of idle-states function will do the trick
<steev>
i think the idle-state-name might need to stay the same, but the rest should be okay?
<derzahl>
sm8*50.dtsi has regular idle-states AND domain-idle-states
<steev>
we also sleep the little cores differently than the big it looks like
<steev>
i might poke at that a bit later
<steev>
i need to
<steev>
get some "real" work done
<derzahl>
looks like sdm845 has cluster-sleep-0/1 in the idle-states function, whereas sm8*50 splits cluster-sleep-0/1 into the domain-idle-states{} function
<derzahl>
so maybe i could just copy the cluster ones into the normal idle-states function in sdm845?
<steev>
well
<steev>
tthe big cores already match up
<steev>
it's just the littles that don't, it looks like
<derzahl>
sdm845 also has a LITTLE_CPU_SLEEP_0/1 and BIG_CPU_SLEEP_0/1, which sm8450 has just LITTLE_CPU_SLEEP_0 and BIG_CPU_SLEEP_0
<derzahl>
s/which/while/
<derzahl>
big cores match up? im seeing very different values
<derzahl>
are the parameters were focusing on pretty much entry/exit and min-latency-us ?
<derzahl>
dammit, i should be doing *real* work too...but dat rabbit hole
<derzahl>
i im not really seeing a big difference between the idle strategies of the two dtsis. i think ill leave it to you pros:)
<derzahl>
steev: when do you expect to have the new kernel out?
<steev>
pushing now (without the idle-states stuff)
<steev>
i'll try to look at that tonight after work