On 07/06/2016 05:57 PM, Scott Wood wrote:
On 07/06/2016 03:23 PM, Daniel Walker wrote:
Hi,
We are using the t1040 platform, and we have found that we need to
populate this register. In the Technical Reference Manual it's
description is section 24.3.2. This option appears in the driver, but it
doesn't appears to be used anyplace.
I'm not sure what you mean by "in the driver". U-boot sets these registers.
My hardware doesn't use u-boot , and it doesn't set these values.
However, there are other reasons to have this. For example, you use
u-boot but it's got a defect which sets the values incorrectly. You may
not be able to update your bootloader on a shipped product.
We we're considered adding something to the device tree to allow
populating this value, but I'm wondering if any of you have specific
considerations on how this is done. Or maybe it's not needed at all, and
we're just missing something.
(not a good patch, just an example.)
diff --git
a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
index 89427b0..b506001 100644
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
@@ -24,6 +24,8 @@ Properties:
- ranges : Each range corresponds to a single chipselect, and covers
the entire access window as configured.
+- cspr_ext : This value sets the extended chip select for all banks.
I see no reason to put this here. Boot software should be setting the
chipselect registers, and if for some reason you don't want to do that,
you could just translate the address through ranges to find the value to
write. Why would you have the binding assume it's the same for all banks?
It was only an example, to start the conversation. I don't understand
what you mean by translating the address thru ranges?
The information that is missing from the device tree, that currently
must come from boot software programming the registers, is the various
attributes that get programmed in CSPR/CSOR.
Like I said mine doesn't do this, so it's required that it be set in an
alternative way. The only alternative we have currently is adding some
code to manually set the values but it's not ideal (and not upstreamable).
Daniel
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
