Re: t1040 IFC flash driver Extended Chip Select

On 07/07/2016 05:01 PM, Daniel Walker wrote:=0A=

On 07/07/2016 02:59 PM, Scott Wood wrote:=0A=

quoted

On 07/07/2016 04:49 PM, Daniel Walker wrote:=0A=

quoted

On 07/07/2016 02:23 PM, Scott Wood wrote:=0A=

quoted

I suspect that add the usage of cspr_ext into the driver would fix the=

=0A=

quoted

quoted

quoted

issue we have. It reads like you would find that acceptable ?=0A=
What specifically is the problem you're having?  Is it that CSPR_EXT i=

s=0A=

quoted

quoted

quoted

not getting written to, and thus the device does not appear at the=0A=
address that it should?=0A=
=0A=
Or is the driver matching incorrectly?  The only way the driver's lack=

=0A=

quoted

quoted

quoted

of using CSPR_EXT to match would be a problem would be if you have=0A=
multiple chipselects with the same address in the lower 32 bits, and=

=0A=

quoted

quoted

quoted

only CSPR_EXT distinguishing them.  Since you proposed a device tree=

=0A=

quoted

quoted

quoted

binding that assumes all devices have the same CSPR_EXT, I doubt that'=

s=0A=

quoted

quoted

quoted

the case, so I doubt adding CSPR_EXT matching to the driver will solve=

=0A=

quoted

quoted

quoted

your problem.=0A=
=0A=
-Scott=0A=
=0A=

I didn't do the debug on this. From my perspective it's either flash=0A=
works, or it doesn't work. We need the code below for it to work,=0A=

Adding CSPR_EXT matching to the driver will not accomplish the same=0A=
thing as that code.=0A=
=0A=

=0A=
So from u-boot perspective, the values in the device tree under "ranges" =

=0A=

or parts of it, are place into the cspr and cspr_ext ? Is that how it's =

=0A=

suppose to work ?=0A=

=0A=
U-Boot writes values that are hardcoded in the board config header.=0A=
These values (as well as the area covered by the IFC LAW) need to match=0A=
the address in the device tree, but U-Boot doesn't get them from the=0A=
device tree.=0A=
=0A=
-Scott=0A=
=0A=