From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3rls5b0lQ8zDr2j for ; Fri, 8 Jul 2016 08:01:22 +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> From: Daniel Walker Message-ID: <577ED12C.30105@cisco.com> Date: Thu, 7 Jul 2016 15:01:16 -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 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 ? Daniel