On 07/07/2016 02:59 PM, Scott Wood wrote:
On 07/07/2016 04:49 PM, Daniel Walker wrote:
On 07/07/2016 02:23 PM, Scott Wood wrote:
I suspect that add the usage of cspr_ext into the driver would fix the
issue we have. It reads like you would find that acceptable ?
What specifically is the problem you're having? Is it that CSPR_EXT is
not getting written to, and thus the device does not appear at the
address that it should?
Or is the driver matching incorrectly? The only way the driver's lack
of using CSPR_EXT to match would be a problem would be if you have
multiple chipselects with the same address in the lower 32 bits, and
only CSPR_EXT distinguishing them. Since you proposed a device tree
binding that assumes all devices have the same CSPR_EXT, I doubt that's
the case, so I doubt adding CSPR_EXT matching to the driver will solve
your problem.
-Scott
I didn't do the debug on this. From my perspective it's either flash
works, or it doesn't work. We need the code below for it to work,
Adding CSPR_EXT matching to the driver will not accomplish the same
thing as that code.
So from u-boot perspective, the values in the device tree under "ranges"
or parts of it, are place into the cspr and cspr_ext ? Is that how it's
suppose to work ?
Daniel
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
