Thread (137 messages) 137 messages, 11 authors, 2021-04-06

Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted

From: Arnd Bergmann <arnd@kernel.org>
Date: 2021-03-11 13:36:18
Also in: linux-arch, linux-devicetree, linux-doc, linux-samsung-soc, linux-serial, lkml

On Thu, Mar 11, 2021 at 1:11 PM Hector Martin [off-list ref] wrote:
On 11/03/2021 18.12, Arnd Bergmann wrote:
quoted
On Wed, Mar 10, 2021 at 6:01 PM Rob Herring [off-list ref] wrote:
quoted
On Wed, Mar 10, 2021 at 1:27 AM Hector Martin [off-list ref] wrote:
quoted
Works for me; then let's just make it non-recursive.

Do you think we can get rid of the Apple-only optimization if we do
this? It would mean only looking at the parent during address
resolution, not recursing all the way to the top, so presumably the
performance impact would be quite minimal.
Works for me.
Incidentally, even though it would now be unused, I'd like to keep the
apple,arm-platform compatible at this point; we've already been pretty
close to a use case for it, and I don't want to have to fall back to a
list of SoC compatibles if we ever need another quirk for all Apple ARM
SoCs (or break backwards compat). It doesn't really hurt to have it in
the binding and devicetrees, right?
Yes, keeping the compatible string is a good idea regardless.
quoted
quoted
Yeah, that should be fine. I'd keep an IS_ENABLED() config check
though. Then I'll also know if anyone else needs this.
Ok, makes sense.

Conceptually, I'd like to then see a check that verifies that the
property is only set for nodes whose parent also has it set, since
that is how AXI defines it: A bus can wait for the ack from its
child node, or it can acknowledge the write to its parent early.
However, this breaks down as soon as a bus does the early ack:
all its children by definition use posted writes (as seen by the
CPU), even if they wait for stores that come from other masters.

Does this make sense to you?
Makes sense. This shouldn't really be something the kernel concerns
itself with at runtime, just something for the dts linting, right?

I assume this isn't representable in json-schema, so it would presumably
need some ad-hoc validation code.
Agreed, having a check in either dtc or expressed in the json scheme
is better than a runtime check. I assume Rob would know how to best
add such a check.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help