t1040 IFC flash driver Extended Chip Select

[Scott Wood]

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.

-Scott