00:06 <hail_eris> Also when testing, it looks like you're using the chromium .config file, when testing if you haven't already just in case make sure to add to your kernel cmdline so that modules can load: loadpin.enforce=0 lsm.module_locking=""

09:11 <macc24> Dylanger: try asking on the mailing list

11:38 <steev> qzed: i've been seeing the 1 core constant usage here but bamse does not

11:55 <qzed> steev: have you been able to pin that down to something? i'd guess it's some kernel thread but that doesn't show up in htop

11:56 <steev> i havent' pinned down what, but at least on my flex5g, it was one of the LITTLE cores, because the time_in_state stats listed the little cores always at max freq

11:57 <qzed> same for me, always core 0 in htop which is one of the little ones

12:58 <bamse> steev: not just CPU0?

12:59 <bamse> or rather, not in particular CPU0...

13:06 <steev> bamse: i'm not sure if mine was CPU0, i just recall that the little cores time_in_state stats said they were always at 1.7GHz and none of the other freqencies had any time in them

13:07 <steev> pretty sure it was happening with 5.18rc too, because that's what the previous branch i was using was based on

13:07 <qzed> fwiw, I don't see many variations in frequency on the other cores either... except if I change to the powersave governor

13:07 <steev> i was always on schedutil, i didn't change governors

13:08 <steev> policy4 had lots of time in state across the freqs, policy0 only ever listed time at 1.7ghz

13:09 <steev> sc8180x-next-20220301-take2

13:09 <steev> is the next branch i was using

13:09 <steev> https://github.com/andersson/kernel/commits/wip/sc8180x-next-20220301-take2

13:11 <steev> i stupidly cleared out my local branches recently, so i don't recall what branch i was using prior to take2 (but i know the issue existed there)

13:13 <qzed> so with cpufreq-stats I also see a lot of lower-frequency time on the big cores... contrary to what htop would want me to believe

13:14 <qzed> so I guess don't trust htop on cpu frequencies...

13:14 <qzed> little cores are pretty much exclusively in the top 3 states though...

13:14 <steev> i was just looking in sys

13:15 <qzed> yeah sys/devices/system/cpu/cpufreq/policyN/stats is what I mean with cpufreq-stats

13:15 <qzed> before that I was mostly gauging things with htop... somehow I assumed that was mostly reliable

13:17 <steev> it mostly is

13:18 <steev> iirc, there's a setting somewhere in htop to show kernel threads

13:18 <qzed> yeah, I have that on

13:19 <steev> armbian has a patch for htop to make it show the actual cpufreqs too

13:19 <steev> wish it would get upstreamed

13:20 <qzed> oh nice

13:21 <qzed> it does show some frequencies for me... but they don't really seem to match up to the time_in_state entries

13:25 <steev> i don't think there's a lot that does, but maybe with intel doing the big.LITTLE thing soon, that will change

13:54 <xnox> mani_s: steev: i do have patches for grub on ubuntu to "detect and persist dtb" so if one boots with dtb, it keeps on trying to copy it to /boot and continue to generate grub.cfg with it.

13:55 <xnox> and multiple versions of it got applied/submitted into rhboot/debian/upstream, but i think nobody has yet agreed to ship devicetree automatic support in upstream vanilla grub and elsewhere.

13:55 <xnox> btw - i noticed that thinkpad x13s started to be available for shipping in the USA

13:55 <mani_s> xnox, interesting

13:56 <xnox> mani_s: so i keep on hoping to build live-desktop image that detects hardware and picks the right dtb on boot; and then if one installs from said image; it persists ongoing.

13:56 <mani_s> steev, xnox But after going back and forth, I decided to use dtbloader in the installer itself. So it will be the first efi application to run and it will chain load grub

13:56 <mani_s> this way, the installer kernel gets full functionality as like the boot kernel by making use of dtb

13:56 <xnox> sure, and there are benefits and disadvantages of that too

13:57 <xnox> i keep on hoping to add signing support to dtbs such that we can boot with secureboot and allow kernel to load the dtb.

13:57 <mani_s> xnox, right but this seems to be the quick solution for me instead of adding the partial ACPI support to many drivers

13:58 <mani_s> plus this gives the opportunity to use wifi during the installation that many would fancy

13:58 <mani_s> xnox, that would be really cool!

13:58 <xnox> yeap yeap

13:59 <xnox> i keep on dreaming to find time to start adding more and more partial acpi support

14:01 <mani_s> :)

14:11 <steev> mani_s: oh that's cool too

14:11 <steev> xnox: yes, x13s are shipping... except lenovo shipped me a t14 instead of the x13s i ordered so....

14:12 <steev> they did mail and say a replacement order has been made and gave me the order number to enter on some website of theirs but it still doesn't show shipped yet :(

14:13 <mani_s> steev, that's a bummer

14:14 <steev> yeah, definitely disappointed, but not really upset

16:34 <qzed> bamse: how does the "normal" usb-c display-port glink notification stuff work?

16:34 <qzed> it looks like the SPX does some special stuff via its EC: https://github.com/linux-surface/surface-pro-x/issues/35

16:55 <xnox> steev: do you get to keep both?

17:44 <steev> xnox: if i want to pay for the t14, yes, but i don't want the t14 (it's a gen 1 anyway)

18:02 <steev> i didn't even check the specs on it, i just put it back in the boxes and taped it up. but that reminds me that i need to send the label to the office and have them print it for me

18:06 <bamse> qzed: on what transport do you see that struct usbc_event?

18:07 <qzed> it's an event sent by SAM (the EC on Surface devices)

18:08 <bamse> i see, it's looking similar to the message i get from the usb-c/charging firmware in the qualcomm case...

18:08 <bamse> but it's not the same...and different transport

18:08 <qzed> AFAIK there are some redriver ICs in-between SoC and USB-C ports on the SPX

18:08 <qzed> so probably something that SAM captures via those

18:09 <bamse> so what's needed is for me to figure out the remaining bug(s?) in my displayport hot-plug patches and post that

18:09 <qzed> the whole PD stuff is also handled by SAM, probably because the battery controller is also under it's supervision

18:09 <bamse> i was happy with the last iteration, but then continued to use them...and noticed that sometimes when i switch resolution, i get a low hpd-signal momentarily...which results to the display driver shutting things down

18:10 <bamse> so working on that...and the dp driver is moving underneath my feet...

18:10 <bamse> with that side in place, you'll have to implement a struct drm_bridge on the SAM side

18:10 <qzed> hmm, yeah that doesn't sound particularly fun xD

18:10 <qzed> okay

18:10 <bamse> then we use a dt graph to connect the two and will magically work

18:10 <qzed> sounds like a plan

18:12 <bamse> but i want to post the base dtsi+dts and land the edp-patches for sc8280xp first...so expect that it'll take another 1-2 weeks before i'm back on that horse

18:13 <bamse> as soon as i have something that doesn't crash and burn i'll post a branch for you to take a look at

18:13 <qzed> dealing with the SAM side should be fairly flexible, as far as I can tell a basic SAM client driver that grabs some phandle from DT should do it, or alternatively link the controller as phandle to some DRM client driver/device thing

18:13 <qzed> no worries

18:13 <bamse> right, the first approach was for the sam-side to have a reference to the dp instance and just call a function on that handle

18:13 <bamse> but the more i look at it the more i certain i get that it's a hack...

18:14 <bamse> so if we instead make the sam-side look like drivers/gpu/drm/bridge/display-connector.c things should work nicely

18:15 <qzed> that should be possible

18:16 <qzed> what I meant with the alternative: we can also add some other driver at some other place and pick up the SAM controller device via a phandle

18:17 <qzed> might need some more work though and might not be as clean as a "pure" SAM client driver as we'd need to deal with SAM controller lifetime stuff

18:17 <qzed> but that's been done before with other platform drivers (before MS decided to not place them in ACPI any more)

18:17 <qzed> so whatever works better, I guess

18:18 <qzed> or actually a phandle to the SAM controller isn't necessary, because there's a function to get a handle to it (that's used by the ACPI/platform driver clients)

18:20 <qzed> but I have plenty of other things still to do, so no need to hurry

18:31 <bamse> qzed: my motivation is to get this setup functional upstream https://photos.app.goo.gl/CDTJ7NCBnxQVpyag7

18:32 <bamse> steev: did i show you ^^ (my flex 5g)?

18:32 <qzed> damn, that looks nice

18:33 <qzed> two 4k displays?

18:33 <macc24> that is solid 10x cleaner than my current one.. wow

18:34 <steev> dang

18:35 <steev> i refuse to take a picture of my area

18:37 <macc24> kinda funny how this setup came to be, https://i.imgur.com/9CtQmZU.jpg

18:57 <robclark> bamse: there was a recent dp fix for resolution change, fwiw..

18:58 <robclark> https://gitlab.freedesktop.org/drm/msm/-/commit/a6e2af64a79afa7f1b29375b5231e840a84bb845

18:58 <steev> sadly, i only have 3 (4 if i buy another LCD, already have controller board) 2K displays :(

23:27 <bamse> robclark: it's been a few weeks, but i think my problem was that the connector status reported by the dp driver suddenly falls, and that is fed back in as a hpd state change ("external" hpd interrupt), so i tell the state machine to shut down the link

23:27 <bamse> robclark: in other words, i screwed something up in the migration from internal to external hpd handling

23:49 <bamse> qzed: yeah, unfortunately we need dual sspp to do 4k@60...so i'm currently limited to 4k@30, while dmitry is working on that