RE: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-15 Thread Mohammed, Afzal
Hi Jon, On Thu, Jun 14, 2012 at 23:23:48, Hunter, Jon wrote: On 06/14/2012 12:40 AM, Mohammed, Afzal wrote: During gpmc driver probe, it will configure all the connected peripherals, if configuration details are not present at that point of time, gpmc driver will cry out saying that

Re: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-14 Thread Jon Hunter
Hi Afzal, On 06/14/2012 12:40 AM, Mohammed, Afzal wrote: Hi Jon, On Wed, Jun 13, 2012 at 22:08:47, Hunter, Jon wrote: On 06/13/2012 12:03 AM, Mohammed, Afzal wrote: As gpmc_onenand_setup is a callback by onenand driver, we would have lost the opportunity to configure onenand before

Re: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-13 Thread Jon Hunter
Hi Afzal, On 06/13/2012 12:03 AM, Mohammed, Afzal wrote: Hi Jon, On Tue, Jun 12, 2012 at 23:00:48, Hunter, Jon wrote: On 06/12/2012 01:16 AM, Mohammed, Afzal wrote: With the existing code, set_async was done as part of set_sync, hence requiring GPMC to be configured twice after driver

RE: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-13 Thread Mohammed, Afzal
Hi Jon, On Wed, Jun 13, 2012 at 22:08:47, Hunter, Jon wrote: On 06/13/2012 12:03 AM, Mohammed, Afzal wrote: As gpmc_onenand_setup is a callback by onenand driver, we would have lost the opportunity to configure onenand before driver is probed. Is that a problem? Looks like it is called

RE: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-12 Thread Mohammed, Afzal
Hi Jon, On Tue, Jun 12, 2012 at 00:06:30, Hunter, Jon wrote: I agree with getting rid of the first instance at the beginning of _set_async_mode, but why get rid of the above one? Are you assuming that by default it is in async mode? Could be nice to keep it to be explicit. Second one is

Re: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-12 Thread Jon Hunter
On 06/12/2012 01:16 AM, Mohammed, Afzal wrote: Hi Jon, On Tue, Jun 12, 2012 at 00:06:30, Hunter, Jon wrote: I agree with getting rid of the first instance at the beginning of _set_async_mode, but why get rid of the above one? Are you assuming that by default it is in async mode? Could

RE: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-12 Thread Mohammed, Afzal
Hi Jon, On Tue, Jun 12, 2012 at 23:00:48, Hunter, Jon wrote: On 06/12/2012 01:16 AM, Mohammed, Afzal wrote: With the existing code, set_async was done as part of set_sync, hence requiring GPMC to be configured twice after driver takes control, with your suggestion too, GPMC would have to

[PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-11 Thread Afzal Mohammed
Reorganize gpmc-onenand initialization so that changes required for gpmc driver migration can be made smooth. Ensuring sync read/write are disabled in onenand cannot be expect to work properly unless GPMC is setup, this has been removed. Two instances of doing the same has been clubbed into one

Re: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-11 Thread Jon Hunter
Hi Afzal, On 06/11/2012 09:01 AM, Afzal Mohammed wrote: Reorganize gpmc-onenand initialization so that changes required for gpmc driver migration can be made smooth. Ensuring sync read/write are disabled in onenand cannot be expect to work properly unless GPMC is setup, this has been