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>
- 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
<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
<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)
<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