From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3rlvTR3nV4zDr1l for ; Fri, 8 Jul 2016 09:48:42 +1000 (AEST) Subject: Re: t1040 IFC flash driver Extended Chip Select To: Scott Wood , Raghav Dogra , Brian Norris , Jaiprakash Singh , Scott Wood , Lijun Pan , "linuxppc-dev@lists.ozlabs.org" , "xe-kernel@external.cisco.com" References: <577D68B8.8020305@cisco.com> <577E79D4.1010709@cisco.com> <577EB10B.7010601@cisco.com> <577EC0FC.8020304@cisco.com> <577ECE6C.3000100@cisco.com> <577ED12C.30105@cisco.com> From: Daniel Walker Message-ID: <577EEA56.3070300@cisco.com> Date: Thu, 7 Jul 2016 16:48:38 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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