RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-09 Thread Mohammed, Afzal
Hi Jon, On Tue, May 08, 2012 at 20:38:24, Hunter, Jon wrote: Different ways of doing things, this looks cleaner to me as already it is checked, and time of execution in both cases would not differ much. Sure. However, I think that this could be simplified so that it is easier to read. At

RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-08 Thread Mohammed, Afzal
Hi Jon, On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote: + /* no waitpin */ + case 0: + break; + default: + dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs); + return -EINVAL; + break; + } Why not combined case 0 and default?

RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-08 Thread Mohammed, Afzal
Hi Jon, On Mon, May 07, 2012 at 21:53:34, Hunter, Jon wrote: Write protect is a pin and there is only one. Like the waitpins and CS signals this needs to be associated with a device. It would make sense that this is associated with the cs data. As far as platform are concerned, it is

Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-08 Thread Jon Hunter
Hi Afzal, On 05/08/2012 01:18 AM, Mohammed, Afzal wrote: Hi Jon, On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote: + /* no waitpin */ + case 0: + break; + default: + dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs); + return -EINVAL; +

RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-07 Thread Mohammed, Afzal
Hi Jon, On Fri, May 04, 2012 at 21:50:16, Hunter, Jon wrote: As mentioned in the cover letter, Additional features that currently boards in mainline does not make use of like, waitpin interrupt handling, changes to leverage revision 6 IP differences has not been incorporated.

RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-07 Thread Mohammed, Afzal
Hi Jon, On Fri, May 04, 2012 at 21:57:10, Hunter, Jon wrote: - gpmc_write_reg(GPMC_SYSCONFIG, l); - gpmc_mem_init(); + switch (conf GPMC_WAITPIN_MASK) { + case GPMC_WAITPIN_0: + idx = GPMC_WAITPIN_IDX0; + break; + case GPMC_WAITPIN_1: +

Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-07 Thread Jon Hunter
Hi Afzal, On 05/07/2012 06:01 AM, Mohammed, Afzal wrote: Hi Jon, On Fri, May 04, 2012 at 21:57:10, Hunter, Jon wrote: - gpmc_write_reg(GPMC_SYSCONFIG, l); - gpmc_mem_init(); + switch (conf GPMC_WAITPIN_MASK) { + case GPMC_WAITPIN_0: + idx = GPMC_WAITPIN_IDX0; +

Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-07 Thread Jon Hunter
Hi Afzal, On 05/07/2012 05:57 AM, Mohammed, Afzal wrote: Hi Jon, On Fri, May 04, 2012 at 21:50:16, Hunter, Jon wrote: As mentioned in the cover letter, Additional features that currently boards in mainline does not make use of like, waitpin interrupt handling, changes to leverage revision

Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-04 Thread Jon Hunter
Hi Afzal, On 05/03/2012 03:23 AM, Mohammed, Afzal wrote: Hi Jon, On Tue, May 01, 2012 at 23:23:00, Hunter, Jon wrote: Hi Afzal, Looks good! Some minor comments ... Thanks +#defineGPMC_WAITPIN_IDX0 0x0 +#defineGPMC_WAITPIN_IDX1 0x1

Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-04 Thread Jon Hunter
Hi Afzal, On 05/01/2012 07:19 AM, Afzal Mohammed wrote: [...] +static int gpmc_setup_cs_waitpin(struct gpmc *gpmc, struct gpmc_device *gd, + unsigned cs, unsigned conf) +{ + u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1); + unsigned idx =

RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-03 Thread Mohammed, Afzal
Hi Jon, On Tue, May 01, 2012 at 23:23:00, Hunter, Jon wrote: Hi Afzal, Looks good! Some minor comments ... Thanks +#defineGPMC_WAITPIN_IDX0 0x0 +#defineGPMC_WAITPIN_IDX1 0x1 +#defineGPMC_WAITPIN_IDX2 0x2

Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion

2012-05-01 Thread Jon Hunter
Hi Afzal, Looks good! Some minor comments ... On 05/01/2012 07:19 AM, Afzal Mohammed wrote: Convert GPMC code to driver. Boards using GPMC should provide driver with type of configuration, timing, CS. Platform devices would then be created for each connected peripheral (details also to be