marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
TheJollyRoger has quit [Read error: Connection reset by peer]
DarthCloud has quit [Remote host closed the connection]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
marvin24 has quit [Ping timeout: 260 seconds]
marvin24 has joined #asahi
_whitelogger has joined #asahi
ransom has joined #asahi
ransom_ has joined #asahi
ransom has quit [Ping timeout: 240 seconds]
_whitelogger has joined #asahi
ransom_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
maor26 has joined #asahi
<marcan>
yeah, all good here, thanks for checking :)
amw has quit [Ping timeout: 256 seconds]
Tokamak has quit [Ping timeout: 240 seconds]
hir0 has joined #asahi
Tokamak has joined #asahi
amw has joined #asahi
TellowKrinkle[m] has quit [Quit: Idle for 30+ days]
raster has joined #asahi
amw has quit [Ping timeout: 240 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hir0 has quit [Quit: hir0]
mps has quit [Ping timeout: 256 seconds]
mps has joined #asahi
VinDuv has joined #asahi
maor26 has quit [Remote host closed the connection]
amw has joined #asahi
maor26 has joined #asahi
leah2 has quit [Ping timeout: 272 seconds]
leah2 has joined #asahi
<marcan>
robher: I'm not sure where the [non]posted-mmio property should be documented in the DT bindings. the simple-bus definition is part of the spec, not the bindings in the kernel tree... the property is really part of the common address resolution code
amw has quit [Ping timeout: 256 seconds]
vimal has quit [Ping timeout: 240 seconds]
DarthCloud has quit [Remote host closed the connection]
DarthCloud has joined #asahi
<kettenis>
maybe a separate file in bindings/bus/ is the way to go?
<kettenis>
the idea is that it is a proprty of the bus isn't it? not of the devices themselves
<arnd>
marcan, robher: if we assume the new property could show up in any node, it makes sense to document it there, OTOH it's likely that no other platform will need it any time soon
raster has quit [Quit: Gettin' stinky!]
<marcan>
kettenis, arnd: yeah, it's a property of the bus, though potentially any bus
<marcan>
running the dt bindings check now and going to grab some dinner :) I'll probably send it a bit later today and defer the nonposted-mmio binding for v3
grumble has quit [Quit: ACCORDING TO ALL KNOWN LAWS OF AVIATION THERE IS NO WAY A BEE SHOULD BE ABLE TO FLY ITS WINGS ARE TOO SMALL TO GET ITS FAT LITTLE BODY OFF THE GROUND THE BEE OF COURSE FLIES ANYWAY BECAUSE BEES DON'T CARE WHAT HUMANS THINK IS IMPOSSIBLE]
Tokamak has joined #asahi
grumble has joined #asahi
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jeffb has joined #asahi
Necrosporus has quit [Read error: Connection reset by peer]
Necrosporus has joined #asahi
riker77 has quit [Ping timeout: 264 seconds]
plainbits has joined #asahi
riker77 has joined #asahi
plainbits has quit [Ping timeout: 264 seconds]
<arnd>
marcan: just to clarify the timeline: I expect linux-5.11 to be released later today, which means it's too late for 5.12 now. I won't queue anything up until v5.12-rc1 is out, but I'm happy to take anything that has been reviewed at that point into soc.git for v5.13, which means it can be part of linux-next two to three weeks from now
<marcan>
yup, no problem; I wasn't really expecting to make 5.12
<arnd>
there are generally two options for merging a new platform: either everything goes into the soc tree, with an ack from the other subsystem maintainers, or everything goes into separate trees, and only the dts+Kconfig+MAINTAINERS file updates go through soc.git
plainbits has joined #asahi
<arnd>
after the initial merge, the second method is normally used for everything
<marcan>
given there are some dependencies involved, the first method might make more sense here? though it could be broken up into at least a few semi-independent pieces
<marcan>
the samsung_tty stuff basically stands alone, other than the Kconfig test; but the AIC driver depends on sysreg_apple.h at least
<marcan>
I don't really expect any major dependencies after this; I think the vast majority of drivers that will go in after this point will communicate through existing kernel abstractions
<arnd>
marcan: yes, we specifically allow this for the initial merge to avoid having platform maintainers go through multiple release cycles to get everything merged in the right order
<arnd>
the main problem later on is when you have a .dts file in the kernel and intentionally break compatibility with older versions. Which is something that we try to avoid as soon as there are users anyway, but it might happen with the iommu or something unexpected
<marcan>
I need to look into how the iommu stuff works for socs... that's going to be coming up pretty soon anyway
<marcan>
hm, looks like it's mostly just referencing the iommu from peripherals
<marcan>
arnd: do you have an example of how this can end up breaking compat?
<arnd>
marcan: I think if the dtb lists an iommu, the kernel will not try to use devices until a driver for the iommu has been loaded, but older kernels would then fail because they don't have a driver for it
<arnd>
it's possible that is no longer the case, it's been a while since I looked at iommus
<arnd>
there are lots of other things that could go wrong though
<marcan>
ah, but that'd be for using older kernels with newer devicetrees
<marcan>
so as long as the iommu support goes in first, then the dts update in the kernel, the kernel itself would be consistent
<arnd>
even if only one way is broken, it can still be a pain for users to upgrade when they want to use a newer dtb to use new features that a later kernel enables, but after updating the dtb they can no longer go back to a known working kernel
<marcan>
yeah, of course, especially in the longer term
<marcan>
but I don't think we can really avoid breaking compat with older kernels and newer devicetrees until all those core drivers have stabilized for a bit anyway
<marcan>
clocks/power/iommu especially
<marcan>
e.g. obviously current kernels *have* to break with future devicetrees once I introduce real clock/power drivers and make the UART use those
<kettenis>
not necessarily
<arnd>
right. For the opposite case (new kernel, old dtb), there is usually an easier way to avoid breaking things, but it may require doing the update over multiple merge windows, to first change the driver and then dte dts files
<marcan>
yeah
<marcan>
I'm not *that* worried about that case, because once we have a solid footing I expect all the early adopters to be using my tree anyway, and as long as I keep the upstreaming pipeline flowing we won't fall behind while also not being blocked on that too much
<marcan>
for the same reason only the initial merge has all those dependency issues
<marcan>
it's just going to require getting used to the planning :)
<marcan>
I'm going to have to come up with some kind of system
<marcan>
kettenis: what are you thinking of?
<marcan>
(re: compat)
<kettenis>
if fimrware (e.g. m1n1) sets up clocks and power a kernel without proper clock/power support might still work
<kettenis>
and a uart drive could be implemented in a way such that it simply skips setting the baudrate if it can't determine the clock frequency of the clock feeding it
<marcan>
yeah, the problem is the samsung uart driver refuses to work without clocks defined
<marcan>
and, well... I'm not sure I'd call not being able to change baud rates a "working device" :-)
<kettenis>
good enough for a serial console ;)
hwatwasthat[m] has quit [Quit: Idle for 30+ days]
<marcan>
yeah but... if you're the kind of person with a serial console, you probably won't mind dt compat breakage at this stage :-)
plainbits has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Necrosporus has quit [Ping timeout: 256 seconds]
VinDuv has joined #asahi
raster has joined #asahi
<marcan>
anyway, I should get some sleep; I'll fire off v2 for review tomorrow
<marcan>
I'll split off `arm64: samsung: Add missing Kconfig dependencies` too and send that separately, that has nothing to do with this series anyway, I just happened to stumble upon it during testing
<arnd>
marcan: right, I actually had found the same Kconfig bugs independently but never got around to sending out the fixes (I had two patches instead of one, but it makes sense to combine them as you did)
Tokamak has joined #asahi
<marcan>
right :)
<marcan>
also I should fire off the DT things which we don't care about anyway but I think are clearly broken; I just need to find a PPC tester... or dig up that old G4 Mac Mini I have lying around...
<arnd>
marcan: before you send out v2, can you add a patch to 'defconfig' to enable the platform and any driver you need?
<marcan>
ah yes, defconfig!
<marcan>
thanks for reminding me about tha
<marcan>
I'll do it tomorrow then *makes a note*
djb has joined #asahi
Necrosporus has joined #asahi
<davidrysk[m]>
so I see that never_released_ commented on SSD wear
<davidrysk[m]>
I'm looking at mine (2TB SSD) and I see 149 TBW and 3% "Percentage Used"
<davidrysk[m]>
those are... not great stats
<davidrysk[m]>
"Percentage Used" is defined to be a vendor specified estimate though
KindOne has quit [Ping timeout: 272 seconds]
KindOne has joined #asahi
<Glanzmann>
davidrysk[m]: HOw to get these numbers?
plainbits has joined #asahi
<arnd>
davidrysk[m], Glanzmann: looking at https://www.heise.de/preisvergleich/?cat=hdssd&xf=18284_2000~4832_3&asuch=&bpmin=&bpmax=&v=e&hloc=at&hloc=de&hloc=pl&hloc=uk&hloc=eu&plz=&dist=&fcols=4930&bl1_id=300&sort=-filter4930#productlist, the best 2TB drives are advertised as with a lifetime 4.4PBW, the cheapest ones only 320TBW
leah2 has quit [Ping timeout: 272 seconds]
<davidrysk[m]>
Glanzmann: smartctl from smartmontools
<arnd>
or "nvme smart-log /dev/nvme0n1"
<davidrysk[m]>
I meant from macOS
ransom has joined #asahi
ransom has quit [Client Quit]
<davidrysk[m]>
arnd: I think it's more a complaint about macOS being too swap-happy
<davidrysk[m]>
149 TBW * (100/3)% is roughly 5PBW
<arnd>
davidrysk[m]: it's also really RAM-limited
<arnd>
I wonder if they used MLC flash then, most drives today use either TLC or QLC, which ends up with a much shorter life
<arnd>
My four year old Samsung 960 Pro using MLC is at 23% with 295529554 "data units written"
<davidrysk[m]>
does it say the size of a "data unit"?
<davidrysk[m]>
I have "291,819,868 [149 TB]"
<arnd>
IIRC it's vendor specific, I should check the datasheet
<tpw_rules>
davidrysk[m]: how old is this drive?
<davidrysk[m]>
2TB in an M1 MBP that was received about 2 months ago
<tpw_rules>
weird. my 2016 touch bar MBP has a 1TB that reports 1% used and 55.4TBW. but i'm still on 10.14
<tpw_rules>
but it's been my daily driver for that whole time
<davidrysk[m]>
I've been "up 4 days, 20:22" and kernel_task has written 15.68 TB in that time
<arnd>
smartctl says "Data Units Written: 295,530,779 [151 TB]"
<never_released>
arnd: on which machine?
<tpw_rules>
mine has written 837GB over 47 days
<tpw_rules>
is there a bug in the newer OSes?
<never_released>
had macOS write 1.8TB in a day
<never_released>
on Big Sur
<arnd>
never_released: this my threadripper workstation that has pretty much been building kernels for the past 3.5 years
<davidrysk[m]>
never_released: have you filed a feedback about this?
<davidrysk[m]>
I'm wondering if I should
<never_released>
Threadripper is so expensive nowadays that Epyc is a better choice
<davidrysk[m]>
never_released: what's the best way to ask you offtopic stuff (since you're not in #asahi-offtopic)?
<never_released>
Twitter maybe? I don't know
plainbits has quit [Ping timeout: 264 seconds]
<davidrysk[m]>
so yeah -- worth filing a feedback?
plainbits has joined #asahi
leah2 has joined #asahi
VinDuv has quit [Read error: Connection reset by peer]
VinDuv has joined #asahi
zkrx has quit [Ping timeout: 240 seconds]
zkrx has joined #asahi
plainbits has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
plainbits has joined #asahi
plainbits has quit [Client Quit]
vup has quit [Ping timeout: 246 seconds]
anuejn has quit [Ping timeout: 272 seconds]
leah2 has quit [Ping timeout: 264 seconds]
anuejn has joined #asahi
vup has joined #asahi
raster has quit [Quit: Gettin' stinky!]
VinDuv has quit [Quit: Leaving.]
eta has quit [Quit: we're here, we're queer, connection reset by peer]
eta has joined #asahi
TheJollyRoger has quit [Remote host closed the connection]