robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
nerdboy_p has joined #aarch64-laptops
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
nerdboy_ has quit [Ping timeout: 480 seconds]
mkrawczuk_ has joined #aarch64-laptops
Amber_Harmonia has joined #aarch64-laptops
Amber_Harmonia_ has quit [Read error: Connection reset by peer]
mkrawczuk has quit [Ping timeout: 480 seconds]
mkrawczuk has joined #aarch64-laptops
mkrawczuk_ has quit [Ping timeout: 480 seconds]
leezu has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
CrEddy has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<strongtz[m]> Hi, I don't have an X13s, but I wonder if the pops and clicks sound exists with the headphone jack output?
martin1 has quit [Remote host closed the connection]
martin has joined #aarch64-laptops
martin is now known as Guest9039
jhovold has joined #aarch64-laptops
<jhovold> strongtz[m]: the pops and clicks have only been heard with the speakers
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<jhovold> Here's an updated wip branch for the X13s:
<jhovold> Changes include:
<jhovold> - fix external display regression in 6.7-rc3 wip branch
<jhovold> - make watchdog bark interrupt edge triggered
<sibis> ajhalaney[m]: according to scmi spec we would have the code controlling the clocking on a SCP ( system control processor) and the apps proc sends sends messages to it ...
baozich has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<mani_s> broonie, Is it OK to introduce regulator_bulk_get_all() API as a wrapper around of_regulator_bulk_get_all()?
alpernebbi has quit [Remote host closed the connection]
alpernebbi has joined #aarch64-laptops
xroumegue has quit [Ping timeout: 480 seconds]
baozich has quit [Ping timeout: 480 seconds]
averyfreeman[m] has quit [Quit: Client limit exceeded: 20000]
xroumegue has joined #aarch64-laptops
krzk has quit [Remote host closed the connection]
<broonie> mani_s: Why would you want that?
<strongtz[m]> <jhovold> "strongtz: the pops and clicks..." <- jhovold: got it, thanks
<mani_s> broonie, we already have a similar API for clk and it makes sense to have one without the of_ prefix
<mani_s> for regulator
<mani_s> for the sake for uniformity, it'd be good if we keep APIs somewhat consistent across subsystems
<broonie> Why would it make sense to have one? When would your device ever not know which regulators it needs? The of_ one is *very* specialist for generic bindings, it doesn't make sense outside an OF context.
<mani_s> broonie, If the drivers have no requirement to enable/disable regulators separately (like at some specific times), it makes sense to just rely on firmware to provide enough regulators and the drivers should just use bulk APIs to manage them
<mani_s> that's where *bulk_all() APIs come handy
<broonie> If you're using ACPI the regulators should just not be visible to you.
<broonie> If you're using DT and can actually see them it's useful to try to encourage people to write DT bindings that actually describe the hardware rather than just throwing random stuff at the wall that happens to work right now.
<mani_s> broonie, I'm using DT only, and this API just makes sense for DT. Even though we have the API in place already, I'm just wondering if we can have one without of_ prefix
<broonie> If you're using DT only it does *not* make sense and you should not be using it outside of generic bindings.
<broonie> This is why I push back on adding stuff like this, people just abuse these APIs :(
<broonie> Huh, the consumer didnt' get added - perhaps I should just remove the API after all...
<mani_s> broonie, just to make it clear if there is a misunderstanding. There is no debate on not describing the regulators in DT. Since clk framework has an API like clk_bulk_get_all(), I was wondering if it makes sense to have regulator_bulk_get_all()
<mani_s> since both are used at the same time mostly
<broonie> I don't think those APIs are a good idea, use the regulator_bulk_ APIs if you want to manage regulators en masse.
<mani_s> DT should have the regulators properly described. But the drivers should not care and just rely on DT to provide correct ones. So bulk_all() does the exact job
<broonie> Why should the drivers not care?
<mani_s> broonie, why? Why should a driver care about what regulators it needs? End of the day, drivers need "regulators" and not "x,y regulators". This will end up duplicating hardware info both in DT and drivers
matthias_bgg has quit [Ping timeout: 480 seconds]
<broonie> The driver asks for the regulators it needs, the DT defines where those come from.
<mani_s> DT should describe what regulators the platform needs and drivers should just enable them. Device drivers are not DT validators
<mani_s> broonie, this creates unnecessary clutter in the driver
<broonie> Like all the error checking code...
<mani_s> well, atleast here we can avoid that clutter and that's what I'm hoping for
<broonie> Seriously, it's just a small table - if the driver is doing anything substantial at all it's noithing.
<mani_s> broonie, there will be N number of small tables if the driver supports multiple SoCs
<mani_s> we are already witnessing this in Qcom drivers and I'm trying to clean them up
<broonie> You say clutter, I say useful information that improves robustness.
<mani_s> broonie, well, that useful information is already in DT where it should be. What's the point in duplicating that info in driver?
<broonie> Validating that the DT makes sense before we start doing fun stuff with power and potentially cause physical damage apart from anything els.e
<broonie> Again, why bother with any error checking?
<mani_s> broonie, Error check is needed if you know that the API _may_ fail. But why would the firmware developer not describe his hardware properly in DT.
<broonie> Why would anyone ever write anything that's buggy?
<broonie> I mean, the overall standard we're expecting here is that people just do the minimum that happens to work with whatever test they're currently running.
<mani_s> broonie, DT should describe the hardware properly
<mani_s> that's the standard
<broonie> Sure, and we should have world peace but we don't seem to.
<mani_s> else we can consider that the firmware is buggy and it can cause consequences
<mani_s> No, I'm not asking for perfectness. It is the actual assumption. You are worrying about the incorrect DT that developers come up with (reverse eng, copying from downstream etc..) but even in those, if the developers know what regulator they need, then they should define it in DT and not in driver
<broonie> Seriously, you're not going to get anywhere here. I don't consider listing the supplies for the bulk API to be a substantial barrier to anything and the API is deliberately conservative about what it's doing given the risk of physical damage.
<mani_s> broonie, OK
<mani_s> it's not a big deal for me to have this API, but a nice to have. Anyway, thanks for your time
krzk has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
Kelsar has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Kelsar has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
Kelsar has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Kelsar has joined #aarch64-laptops
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
krzk is now known as Guest9082
Guest9082 has quit [Quit: leaving]
krzk has joined #aarch64-laptops
<steev> speaking of regulators... what happened to the pm8008 patchset? it was on v15 in june of 2022... and.. is there newer?
<steev> luca pinged about it back in july but still nada
iivanov has quit [Read error: No route to host]
<bamse> steev: jhovold is hackinng on a new version...but there's some design decisions we made back in 2015 that doesn't work out so well
<steev> ah okay, i wasn't entirely sure there :)
<steev> i knew he'd had some fixups
minecrell9 has joined #aarch64-laptops
pbsds9 has joined #aarch64-laptops
Erisa0 has joined #aarch64-laptops
bluerise has joined #aarch64-laptops
agl_ has joined #aarch64-laptops
erebion_ has joined #aarch64-laptops
ema_ has joined #aarch64-laptops
xnox has quit [Read error: Connection reset by peer]
agl has quit [Read error: No route to host]
neobrain has quit [Remote host closed the connection]
exeat has quit [Ping timeout: 480 seconds]
ema has quit [Read error: No route to host]
neobrain has joined #aarch64-laptops
bluerise_ has quit [Read error: No route to host]
abelvesa has quit [Remote host closed the connection]
xnox1 has joined #aarch64-laptops
abelvesa has joined #aarch64-laptops
Libre___ has quit [Remote host closed the connection]
abelvesa has quit [charon.oftc.net helix.oftc.net]
sz3m3k[m] has quit [charon.oftc.net helix.oftc.net]
Stirl[m] has quit [charon.oftc.net helix.oftc.net]
malvi[m]1 has quit [charon.oftc.net helix.oftc.net]
aigotchi[m] has quit [charon.oftc.net helix.oftc.net]
quinine has quit [charon.oftc.net helix.oftc.net]
Jasper[m] has quit [charon.oftc.net helix.oftc.net]
pz[m] has quit [charon.oftc.net helix.oftc.net]
harvests[m] has quit [charon.oftc.net helix.oftc.net]
DigitalPirate[m] has quit [charon.oftc.net helix.oftc.net]
Guest8732 has quit [charon.oftc.net helix.oftc.net]
minecrell has quit [charon.oftc.net helix.oftc.net]
erebion has quit [charon.oftc.net helix.oftc.net]
Erisa has quit [charon.oftc.net helix.oftc.net]
pbsds has quit [charon.oftc.net helix.oftc.net]
paddymahoney has quit [charon.oftc.net helix.oftc.net]
Erisa0 is now known as Erisa
DigitalPirate[m] has joined #aarch64-laptops
Libre___ has joined #aarch64-laptops
pz[m] has joined #aarch64-laptops
harvests[m] has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
quinine has joined #aarch64-laptops
aigotchi[m] has joined #aarch64-laptops
Stirl[m] has joined #aarch64-laptops
sz3m3k[m] has joined #aarch64-laptops
malvi[m]1 has joined #aarch64-laptops
paddymahoney has joined #aarch64-laptops
minecrell has joined #aarch64-laptops
abelvesa has joined #aarch64-laptops
pbsds has joined #aarch64-laptops
Guest8732 has joined #aarch64-laptops
malvi[m]1 has quit [Ping timeout: 511 seconds]
Stirl[m] has quit [Ping timeout: 486 seconds]
aigotchi[m] has quit [Ping timeout: 506 seconds]
Jasper[m] has quit [Ping timeout: 481 seconds]
quinine has quit [Ping timeout: 491 seconds]
pz[m] has quit [Ping timeout: 481 seconds]
harvests[m] has quit [Ping timeout: 516 seconds]
Guest8732 has quit [Ping timeout: 516 seconds]
pbsds has quit [Ping timeout: 486 seconds]
sz3m3k[m] has quit [Ping timeout: 483 seconds]
minecrell has quit [Ping timeout: 483 seconds]
erebion_ is now known as erebion
SintayewGashaw[m] has quit [Ping timeout: 480 seconds]
DocGalaxyBlock[m] has quit [Ping timeout: 480 seconds]
lun[m] has quit [Ping timeout: 480 seconds]
sporos11[m] has quit [Ping timeout: 480 seconds]
anarchron has quit [Ping timeout: 480 seconds]
publicdiscourse[m] has quit [Ping timeout: 480 seconds]
nscnt[m] has quit [Ping timeout: 480 seconds]
jenneron[m] has quit [Ping timeout: 480 seconds]
freekurt[m] has quit [Ping timeout: 480 seconds]
AlexMarty[m] has quit [Ping timeout: 480 seconds]
minecrell9 has quit []
minecrell has joined #aarch64-laptops
pz[m] has joined #aarch64-laptops
aigotchi[m] has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
harvests[m] has joined #aarch64-laptops
lun[m] has joined #aarch64-laptops
<Dantheman825[m]> So I have an X13s, I’ve been trying to get Linux on this guy and have been following this guide to achieve it
<Dantheman825[m]> Initially I had Debian on this from the linaro, but I need Ubuntu for what I’m testing.
<Dantheman825[m]> I mostly figured out the tutorial (few things I changed, swapped the image for 23.10 instead of 22.04, and 6.7.0-rc3+ instead of 6.2.0). But booting has been an absolute pain in my neck and I can’t for the life of me figure it out
<Dantheman825[m]> I managed to boot into the EFI shell to change the boot order `FS15:>bcfg boot add 0 efi\debian\Dtbloader.efi “Ubuntu”` but anytime I boot, I’m stuck with unknown filesystem
<Jasper[m]> What about a fresh reinstall?
<Jasper[m]> Ubuntu builds properly bootable livecd's for the x13s these days
<_[m]1> yeah looks like you're too deep down the rabbit hole lol
<_[m]1> I've had ubuntu up and running quite painless
<Dantheman825[m]> Jasper[m]: I tried to be pretty fresh about it, wiped the root clean and replaced it all from the image
<_[m]1> if you like, theoretically you can install debian too https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s
<_[m]1> (good oyu asked I just realised I just went yolo instead of continueing the guide 🙂 )
<_[m]1> these come in handy too in case the doc is too old
<Dantheman825[m]> Well, that’s the thing, I did have Debian on it, and it worked fine for the most part
<Jasper[m]> Dantheman825[m]: I mean wipe the thing clean and install off usb
<Dantheman825[m]> Wish I knew about the live image sooner
<Dantheman825[m]> Thanks for filling me in
<Jasper[m]> Dantheman825[m]: No problem, don't hesitate to ask if you have any more questions
<Dantheman825[m]> So, is it safe to assume I should update my laptop’s UEFI firmware for the Ubuntu image?
<Dantheman825[m]> It’s at 1.25 I believe
<Jasper[m]> Dantheman825[m]: DEFINITELY
<Jasper[m]> at like 1.54 they added a "Linux mode" option that tells Linux to load the dtb automagically assuming it's at a somewhat proper place (plus some other stuff I believe)
<steev> yeah, 1.58 is the latest
<Jasper[m]> https://gitlab.com/TheOneWithTheBraid/x13s-firmware-update here's some instructions to make a bootable UEFI update disk. fwupd is not (yet?) supported afaik
<Dantheman825[m]> So while I was toiling away at getting Linux to work, I broke Windows from booting due to wiping the /boot/efi partition
<Dantheman825[m]> Oops 😬
<Dantheman825[m]> I can’t get Lenovo’s recovery software to play ball with me right now, it fails the download midway through
<Dantheman825[m]> How am I gonna update my UEFI if I can’t even get into Windows?
<Jasper[m]> Dantheman825[m]: I sent you the link to do it up there^
<Jasper[m]> Assuming you have a working Linux install somewhere
<Dantheman825[m]> My main rig runs EndeavourOS 95% of the time
<Jasper[m]> That's fine
<Jasper[m]> You mostly need the uefi updater exe and innoextract from your favourite repo's
<javierm> broonie: in fact, it seems that the rest of the patches in https://lore.kernel.org/netdev/20221115073603.3425396-2-clabbe@baylibre.com/ never landed
<javierm> broonie: only you merged the regulator patch but no of_regulator_bulk_get_all() user ever existed in mainline
<broonie> Yes, I see.
<_[m]1> w000t if you follow the guide it actually works GO FIGURE 😄
* _[m]1 running debian like a b0ss
<_[m]1> still added all modules initramfs-tools 🙂
freekurt[m] has joined #aarch64-laptops
<Dantheman825[m]> Good to go on the update, should I flip this guy on?
<clover[m]> Flip it and never look back
<Jasper[m]> <Dantheman825[m]> "Good to go on the update, should..." <- Definitely
<Jasper[m]> Wipe windows while you're at it :^)
<Dantheman825[m]> I've been told it's good to keep around for the occasional firmware update, but I take it there's other ways of updating that?
<Jasper[m]> <Dantheman825[m]> "I've been told it's good to keep..." <- not for uefi as you can tell :D
<Jasper[m]> Not sure if EC gets firmware upgrades for this model. I know it does for the x86 models
<Dantheman825[m]> well. it doesn't matter much now since I can't boot into Windows on this thing
<Dantheman825[m]> not until I can get a recovery image
<Dantheman825[m]> Wish they didn't hoard it behind a login though
<_[m]1> mm sound dummy and wireless not working mmm
<_[m]1> haha making windows usb installer is also much fun I can assure you
<Jasper[m]> Dantheman825[m]: I _think_ (have not done it myself) the strat is to get a MS Devkit for Windows 2023 recovery image and use that to get the basics running
<Jasper[m]> Then swap out drivers (read: update) with Vantage
<Jasper[m]> Not entirely sure though don't quote me on that
<Dantheman825[m]> so a generic WinARM image exists in the wild?
<Jasper[m]> Dantheman825[m]: Generic yes, workable ootb on anything that isn't a vm no.
<Jasper[m]> The MS Devkit thing is a product with the same soc as the x13s
<Jasper[m]> so most of the drivers will he included
<Jasper[m]> *be
<Jasper[m]> The aforementioned generic images have basically nothing
<Dantheman825[m]> ah
anarchron has joined #aarch64-laptops
<Dantheman825[m]> <Dantheman825[m]> "ima_c9fddbf.jpeg" <- got somewhat close with Lenovo's solution, but it fails halfway through :/
<_[m]1> ```
<_[m]1> Dec 05 00:13:26 saga sh[1075]: /etc/network/if-pre-up.d/wpasupplicant: 120: cannot create /dev/stderr: No such device or address
<_[m]1> <Dantheman825[m]> "so a generic WinARM image..." <- eh I actually requested it to lenovo and they replied fast - now I remember
<Dantheman825[m]> I bought this laptop refurbished on Ebay, hopefully that doesn't bother Lenovo too much, lol
<_[m]1> nah
<Jasper[m]> Dantheman825[m]: Their warranty is generally pretty good
<Jasper[m]> Usual restrictions apply obviously
<Jasper[m]> All they generally need is a serial number
<Dantheman825[m]> good thing the stickers below are in-tact
<_[m]1> wth is this wlP6p1s0
<steev> the weird wifi device name :)
<steev> net.ifnames=0 on the kernel commandline is your friend ;)
<Dantheman825[m]> is there a way to disable the Ubuntu splash screen on the live image?
<Dantheman825[m]> it's been stuck on it for a good minute, and I have no idea what it's doing
<clover[m]> step 1: use arch
<clover[m]> jk
<steev> hit esc
<steev> it should just be plymouth, so you could also edit the boot option to remove splash
<Dantheman825[m]> that could work too
<Dantheman825[m]> it puts me at ease seeing systemd rolling down the screen
<Dantheman825[m]> it tells me it's not just sitting there doing nothing
<Dantheman825[m]> looks like it's the snapd services that are taking their time