On Mon, Dec 7, 2009 at 11:59 AM, Vimal Singh <vimal.neww...@gmail.com> wrote:
> On Sat, Dec 5, 2009 at 3:31 AM, Tony Lindgren <t...@atomide.com> wrote:
>> Hi,
>>
>> Looks good, just one comment below.
>>
>> * Govindraj.R <govindraj.r...@ti.com> [091204 05:37]:
>>> From: Vimal Singh <vimalsi...@ti.com>
>>> Date: Wed, 25 Nov 2009 18:23:15 +0530
>>> Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
>>>
>>> Introducing 'gpmc-nand.c' for GPMC specific NAND init.
>>> For example: GPMC timing parameters and all.
>>> This patch also migrates gpmc related calls from 'nand/omap2.c'
>>> to 'gpmc-nand.c'.
>>>
>>> Signed-off-by: Vimal Singh <vimalsi...@ti.com>
>>> ---
>>>  arch/arm/mach-omap2/Makefile           |    3 +
>>>  arch/arm/mach-omap2/gpmc-nand.c        |  141 
>>> ++++++++++++++++++++++++++++++++
>>>  arch/arm/plat-omap/include/plat/nand.h |    6 ++
>>>  drivers/mtd/nand/omap2.c               |   26 +-----
>>>  4 files changed, 153 insertions(+), 23 deletions(-)
>>>  create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
>>
>> <snip>
>>
>>> --- /dev/null
>>> +++ b/arch/arm/mach-omap2/gpmc-nand.c
>>
>> <snip>
>>
>>> +int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
>>> +{
>>> +     unsigned int val;
>>> +     int err = 0;
>>> +     struct device *dev = &gpmc_nand_device.dev;
>>> +
>>> +     gpmc_nand_data = _nand_data;
>>> +     gpmc_nand_data->nand_setup = gpmc_nand_setup;
>>> +     gpmc_nand_device.dev.platform_data = gpmc_nand_data;
>>> +
>>> +     err = gpmc_nand_setup(gpmc_nand_data->gpmc_cs_baseaddr);
>>> +     if (err < 0) {
>>> +             dev_err(dev, "NAND platform setup failed: %d\n", err);
>>> +             return err;
>>> +     }
>>> +
>>> +     /* Enable RD PIN Monitoring Reg */
>>> +     if (gpmc_nand_data->dev_ready) {
>>> +             val  = gpmc_cs_read_reg(gpmc_nand_data->cs,
>>> +                                              GPMC_CS_CONFIG1);
>>> +             val |= WR_RD_PIN_MONITORING;
>>> +             gpmc_cs_write_reg(gpmc_nand_data->cs,
>>> +                                             GPMC_CS_CONFIG1, val);
>>> +     }
>>
>> Above looks OK..
>>
>>> +     val  = gpmc_cs_read_reg(gpmc_nand_data->cs, GPMC_CS_CONFIG7);
>>> +     val &= ~(0xf << 8);
>>> +     val |=  (0xc & 0xf) << 8;
>>> +     gpmc_cs_write_reg(gpmc_nand_data->cs, GPMC_CS_CONFIG7, val);
>>
>> ..but this looks messy. Maybe use some GPMC defines for the
>> 0xf << 8 mask?
>>
>> Then the 0xc & 0xf part looks a bit redundant, what's the 0xf
>> there for?
>>
>> I know it's all from the old code, but might as well clean it up
>> while at it :)
>
> Ok, I'll drop next version of this patch for this.
>

In fact this peace of code is not required too. This will be taken
care in 'gpmc_cs_request'.
I will remove it.


-- 
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to