From: Aaron Sierra <asierra@xes-inc•com>
To: Prabhakar Kushwaha <prabhakar@freescale•com>,
Scott Wood <scottwood@freescale•com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation•org>,
linuxppc-dev@lists•ozlabs.org, Arnd Bergmann <arnd@arndb•de>
Subject: Re: [PATCH 2/2] fsl_ifc: Support all 8 IFC chip selects
Date: Wed, 20 Aug 2014 10:54:38 -0500 (CDT) [thread overview]
Message-ID: <868471357.33583.1408550078450.JavaMail.zimbra@xes-inc.com> (raw)
In-Reply-To: <53F4179F.1010803@freescale.com>
> >> -#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.
You mean that there is no way to tell from an IFC-specific register how
many chip selects are valid for a given SoC, correct?
> 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
>
> or
>
> 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.
My patch is based on the assumption that it is safe to access the addresses of
the four nonexistent (unconnected?) chip selects in devices with fewer than
eight chip selects.
Also, the full FSL_IFC_BANK_COUNT range of chip selects should only be probed
when no match is not found for a chip select's DTS-defined address base within
any IFC bank. The typical case would be for the device tree to properly define
the address space prepared by the bootloader, which would result in only banks
present in the SoC being probed.
I have tested this patch on P1010 and T1042 processors, which feature four and
eight chip selects respectively with no apparent ill effects.
Our P1010 product has NAND attached to chip selects 0 and 1:
ranges = <0x0 0x0 0x0 0xef800000 0x0010000
0x1 0x0 0x0 0xef840000 0x0010000>;
I mangled chip-select 0 so that the DTS-defined base would not match the
address programmed by firmware, so that all eight chip selects would be
scanned on this four chip-select part:
ranges = <0x0 0x0 0x0 0xefc00000 0x0010000
0x1 0x0 0x0 0xef840000 0x0010000>;
This resulted in the following kernel message:
fsl,ifc-nand efc00000.nand0: fsl_ifc_nand_probe: address did not match any chip selects
The NAND device at chip select 1 was properly detected.
> Regards,
> Prabhakar
next prev parent reply other threads:[~2014-08-20 15:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 21:07 [PATCH 2/2] fsl_ifc: Support all 8 IFC chip selects Aaron Sierra
2014-08-20 0:08 ` Scott Wood
2014-08-20 3:35 ` Prabhakar Kushwaha
2014-08-20 15:54 ` Aaron Sierra [this message]
2014-08-20 23:21 ` Scott Wood
2014-08-22 14:37 ` Prabhakar Kushwaha
2014-08-22 17:51 ` Scott Wood
2014-08-25 6:28 ` Prabhakar Kushwaha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=868471357.33583.1408550078450.JavaMail.zimbra@xes-inc.com \
--to=asierra@xes-inc$(echo .)com \
--cc=arnd@arndb$(echo .)de \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=prabhakar@freescale$(echo .)com \
--cc=scottwood@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox