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
brandas has joined #asahi
tomtastic has quit [Ping timeout: 256 seconds]
tomtastic has joined #asahi
inglor has quit [Remote host closed the connection]
inglor has joined #asahi
amw has joined #asahi
crabbedhaloablut has quit [Ping timeout: 272 seconds]
Guest69869 has quit [Killed (tepper.freenode.net (Nickname regained by services))]
Necrosporus has joined #asahi
klaus has joined #asahi
<marcan>
arnd: how did the draft go over with the other folks?
<arnd>
marcan: I didn't really get any replies
<marcan>
that must clearly mean it's perfect :)
<arnd>
I wonder if the ioremap_np() description should be rephrased to explain under which conditions it is safe to rely on writes being non-posted, rather than just warning that it might not be
<marcan>
it's basically platform-specific, since even on arm64 platforms where nGnRnE is used I bet there are fabrics and buses that break it..
<marcan>
do you want specific examples, or what do you have in mind?
<arnd>
right, but if we document it along the lines of the new IORESOURCE flag, it could be phrased to explain that the flag can be set by platforms to indicate that it is safe to rely on them being nonposted
<arnd>
that would even make it portable to architectures on which all on-chip I/O is nonposted by definition, so a portable driver can simply check the flag and either fall back to inserting dummy reads or refuse the probe when it is absent
<marcan>
I'm not even sure how true that is... in principle, we don't know for a fact that some sub-bus on the M1 doesn't break this, and thus requires nGnRnE due to the top-level fabric but then doesn't *actually* implemented non-posted semantics
<marcan>
I mean, I hope not, but if that were the case the flag would not mean that any more
<marcan>
conversely, platforms which *support* but do not *require* nE semantics need not set that flag, but drivers may still want to use _np if it is known to work
<arnd>
marcan: About other platforms, my thinking was that the DT flag could be used to make the behavior portable. Clearly a driver can just ask for a NP mapping regardless of the resource type and still work correctly, but that would be a non-portable driver if it relies it the stores being non-posted
<arnd>
For the apple platform, I would expect that none of the internal I/O is posted, and this is likely true for many other SoCs. I can try to find what the AXI and AHB specs say about it
<arnd>
marcan: the AXI3 and AXI4 buses have a 'bufferable' flag in a write transaction that determines whether it's posted or not
<marcan>
arnd: ah, it gets carried around with the transaction?
<marcan>
so the thing is, the DT flag asks the standard APIs to always use nonposted mode
<marcan>
but most drivers don't *need* nonposted mode, and using it could decrease performance on platforms that have posted mode
<marcan>
so we kind of have two situations to signal; "nonposted mode available and works", and "nonposted mode required"
<marcan>
right now the flag means the latter
bisko has joined #asahi
ephe_meral has quit [Ping timeout: 240 seconds]
mndza has joined #asahi
plainbits has joined #asahi
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
robinp has joined #asahi
robinp_ has quit [Ping timeout: 268 seconds]
klaus has joined #asahi
mndza has quit []
mndza has joined #asahi
<arnd>
marcan: indeed, the two are incompatible, if we treat the dt property as "required" as it has to be on the mac, then it wouldn't be an opt-out for drivers
<marcan>
exactly
<marcan>
which is why I push people towards the abstractions that do the right thing
ephe_meral has joined #asahi
<marcan>
arnd: this makes me wonder if we shouldn't make the default ioremap_np not an alias for ioremap, but rather return NULL a la ioremap_uc
<marcan>
that could even be the "ioremap_np exists" signal; drivers can just try that, and fall back to ioremap
<marcan>
then every arm64 driver is allowed to use it (and if we have problems with SoCs where nE accesses are not truly nE, that's broken-SoC-needs-a-quirk territory and we can worry about it when we get there, if anyone ever does this)
<arnd>
that would probably be architecture specific again, depending on how the default ioremap areas behave
<marcan>
what do you mean?
<arnd>
I mean an architecture on which every MMIO write is non-posted can implement ioremap_np() as an alias for ioremap(), while another architecture on which MMIO writes are posted would return NULL
<marcan>
right
<marcan>
but that makes sense, no?
<arnd>
I think it makes sense, but it's still a bit unclear what should happen on PCIe, where every mmio write is posted regardless of the flag
<marcan>
I was going to mention adding a sentence to that effect ("don't use this for PCIe drivers, ever")
<arnd>
right
odmir has joined #asahi
<marcan>
if you think this approach works I can give a shot at editing it in the doc
<arnd>
yes, please do
<arnd>
it's unfortunate how the rules for both ioremap_wc and ioremap_np() depend on the resource flags and on the bus type (pci vs local), but in different ways
<marcan>
yeah...
<marcan>
arnd: doc updated
odmir has quit [Remote host closed the connection]
<arnd>
marcan: I clarified the ioremap_np() PCI portion to say that this is about memory space (as I/O space is also non-posted), and rephrased last paragraph for ioremap_wc
<marcan>
yup, sounds good
plainbits has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
arnd: think it's good enough to throw into a patch and discuss it on the lists?
<arnd>
two more things: I'm trying to fit the IORESOURCE_MEM_NONPOSTED flag into the ioremap_np() description, and I'd want to make sure that it compiles into html/pdf form from rst
<marcan>
yeah, I'll do the rst check
<marcan>
don't worry too much about formatting, I'll double check that
<arnd>
ok
zkrx has quit [Ping timeout: 272 seconds]
<arnd>
In Documentation/core-api/timekeeping.rst, I used "c:function::" annotations for the function prototypes, which may be good here as well, but is a lot to type for the dozens of mmio accessors
<marcan>
I can do that if you want, but I kind of worry about readability of the .rst version
<jn__>
now that there's automatic detection for function() syntax in rst, is there still a reason for c:function::?
<jn__>
(it was added not too many kernel releases ago, AFAIK)
<arnd>
ah, that is probably easier then, it must have come after I last looked at it
snalty has quit [Read error: Connection reset by peer]
<marcan>
oh hah
zkrx has joined #asahi
snalty has joined #asahi
<marcan>
turns out this was all done before, but never merged that way