From: Prabhakar Kushwaha <prabhakar@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH][v2] driver/nand: Update SRAM initialize logic for IFC.
Date: Sat, 14 Jun 2014 08:11:16 +0530 [thread overview]
Message-ID: <539BB64C.3030707@freescale.com> (raw)
In-Reply-To: <1402692045.6603.594.camel@snotra.buserror.net>
Hi Scott,
On 6/14/2014 2:10 AM, Scott Wood wrote:
> On Thu, 2014-06-12 at 12:14 +0530, Prabhakar Kushwaha wrote:
>> IFC controller v1.1.0 requires internal SRAM initialize by reading
>> NAND flash. Higher controller versions have provided "SRAM init" bit in
>> NCFGR register space.
>>
>> update SRAM initialize logic to reflect the same.
>>
>> Also print error message in case of Page read error.
>>
>> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
>> ---
>> Changes for v2:
>> - Updated error handling
>>
>> drivers/mtd/nand/fsl_ifc_nand.c | 35 +++++++++++++++++++++++++++++++----
>> include/fsl_ifc.h | 2 ++
>> 2 files changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
>> index 27f5177..280e14e 100644
>> --- a/drivers/mtd/nand/fsl_ifc_nand.c
>> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
>> @@ -806,12 +806,30 @@ static void fsl_ifc_select_chip(struct mtd_info *mtd, int chip)
>> {
>> }
>>
>> -static void fsl_ifc_sram_init(void)
>> +static int fsl_ifc_sram_init(uint32_t ver)
>> {
>> struct fsl_ifc *ifc = ifc_ctrl->regs;
>> uint32_t cs = 0, csor = 0, csor_8k = 0, csor_ext = 0;
>> + uint32_t ncfgr = 0;
>> long long end_tick;
>>
>> + if (ver > FSL_IFC_V1_1_0) {
> It would be better to check that ver >= the first version that supports
> this, rather than > the last version that doesn't.
here only 2 type of code is present i.e. (ver == FSL_IFC_V1_1_0) and
(ver > FSL_IFC_V1_1_0).
if i put (ver == FSL_IFC_V1_1_0) earlier a lots of code go in "if ". I
am trying to avoid it to make code more cleaner.
> How much benefit is there in doing this versus continuing with the
> current code?
Existing code is perfect for 8KB internal SRAM as we are reading 8KB Page.
As IFC 2.0 has 16KB SRAM, either I have to read 16KB page or I have to
read 2 8KB page to fill complete SRAM.
in future, there may be possibility of > 16KB internal SRAM. So I
decided to use SRAM init bit.
> Should we determine the IFC version at compile time instead, so that we
> don't need to carry around both versions of the code in the binary?
>
Compile time option can be used. But in Linux driver it may not be
possible.
I am trying to have same code base in u-boot and Linux for maintainability.
--prabhakar
prev parent reply other threads:[~2014-06-14 2:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 6:44 [U-Boot] [PATCH][v2] driver/nand: Update SRAM initialize logic for IFC Prabhakar Kushwaha
2014-06-13 20:40 ` Scott Wood
2014-06-14 2:41 ` Prabhakar Kushwaha [this message]
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=539BB64C.3030707@freescale.com \
--to=prabhakar@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.