On 07/07/2016 06:48 PM, Daniel Walker wrote: > On 07/07/2016 03:37 PM, Scott Wood wrote: >> On 07/07/2016 05:01 PM, Daniel Walker wrote: >>> 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 ? >> U-Boot writes values that are hardcoded in the board config header. >> These values (as well as the area covered by the IFC LAW) need to match >> the address in the device tree, but U-Boot doesn't get them from the >> device tree. >> > > I was suggesting the values it writes are the same as the ones inside > the device tree. So we could have both csrp and csrp_ext written from > the driver and the values would > come from the ranges property.
There's more to CSPR than just the address. The driver should either be able to assume that all of CSPR/CSOR has been correctly initialized, or it should assume none of that has been initialized -- which again, requires the attribute information to be in the device tree. If you're doing something in between, then that's a board quirk rather than a general solution. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
