Re: [PATCH 2/2] fsl_ifc: Support all 8 IFC chip selects

Sorry Scott for late reply,

Please find my reply in-lined


On 8/21/2014 4:51 AM, Scott Wood wrote:

On Wed, 2014-08-20 at 09:05 +0530, Prabhakar Kushwaha wrote:

quoted

On 8/20/2014 5:38 AM, Scott Wood wrote:

quoted

On Fri, 2014-08-15 at 16:07 -0500, Aaron Sierra wrote:

quoted

Freescale's QorIQ T Series processors support 8 IFC chip selects
within a memory map backward compatible with previous P Series
processors which supported only 4 chip selects.

Signed-off-by: Aaron Sierra <redacted>
---
   include/linux/fsl_ifc.h | 10 +++++-----
   1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/fsl_ifc.h b/include/linux/fsl_ifc.h
index 84d60cb..62762ff 100644
--- a/include/linux/fsl_ifc.h
+++ b/include/linux/fsl_ifc.h

@@ -29,7 +29,7 @@
   #include <linux/of_platform.h>
   #include <linux/interrupt.h>
   
-#define FSL_IFC_BANK_COUNT 4
+#define FSL_IFC_BANK_COUNT 8

First please modify fsl_ifc_nand.c to limit itself to the number of
banks it dynamically determines are present based on the IFC version.

Number of available bank/chip select are defined by SoC and it is
independent of SoC.

Do you mean defined by the SoC and independent of the IFC version?

IFC v 1.0.0 supports 4 Chip Select.
IFC v 1.1.0 onwards, IFC supports 8 chip select.

But SoC finally defines number of chip select coming out of SoC. Like 
LS1021A with IFC ver 1.4.0 have only 7 Chip Select.

quoted

It should be fix in following way

Option 1:
u-boot:  fix device tree with number of available chip select. It may
require IFC binding change
Linux: Read device tree and determine the Chip Selects

If we do this then it will need to be an optional property that defaults
to the current assumption being made (4).

Yes, I agree with you.

In the future we really ought to check whether there are integration
parameters when coming up with the initial binding for a hardware
block...

True.

quoted

Option 2:
Make it static because any way IFC NAND driver polls to
FSL_IFC_BANK_COUNT to know NAND flash chip select. This patch is doing same.

I don't understand what you're saying here.  The driver does not know at
compile time how many there are.  What this patch does is assume it's OK
to access non-existent registers in the rare case that there's no match
in the registers that exist.

in case of P1010, If we run loop for 8 times,
      we are accessing reserved memory, that's why it may work. In Ideal 
scenario, we should not access the reserved memory.

Aaron tested this on P1010 and it seemed to work, though I'm not
generally fond of relying on such things.

yes, I agree.

  If I conclude  ==>   We should go with option 1.  Am I correct?


Regards,
Prabhakar