t1040 IFC flash driver Extended Chip Select

[Daniel Walker]

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.

Daniel