On 09/02/2021 18.15, Arnd Bergmann wrote:
Right, these are the same ranges that I found in the adt and that Mark
listed in his code snippet, so it seems we all see the same partitioning
of the address space. I also see them reflected in the
/defaults/pmap-io-ranges property in ADT, which seems to have an entry
for every register range that has some mmio registers, along with what
appears to be a bitmask of some attributes, and it clearly shows
the above ranges as having a distinct set of bits from the others
(in little-endian):
00000000 04000000 00000080 00000000 27000080 65494350
00000080 04000000 00000080 00000000 27000080 65494350
00000080 05000000 00000080 00000000 27000080 65494350
00000000 06000000 00000080 00000000 27000080 65494350
000000a0 06000000 00000020 00000000 27000080 65494350
000000c0 06000000 00000040 00000000 27000080 65494350
^64-bit address ^64-bit length ^ 64-bit flags?
That's ASCII :-)
'PCIe'
As opposed to e.g.
0000f002 05000000 00400000 00000000 07400000 54524144
'DART'
00800021 05000000 00400000 00000000 07400000 44495344
'DSID'
Ok, so if we want this to get encoded in a 'struct resource' flag, the PCI
resources should work just fine as these resources come from the
PCI layer rather than of_address_to_resource(). I think it would be
reasonable here to add something to of_address_to_resource() to
set such a flag if we can find an unused one, and then require the
drivers for this platform to go through devm_ioremap_resource()
or similar.
This sounds reasonable. For setting such a flag, I guess looking for a
property (inherited from parents) would make sense. `mmio-map-mode =
"nonposted"` or something like that?
--
Hector Martin (marcan@xxxxxxxxx)
Public Key: https://mrcn.st/pub
