[PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

[Mohammed, Afzal]

Hi Tony,

On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter at ti.com> [120702 10:30]:

> > 2. Provide some sort of "retime" callback that the gpmc driver can call
> > at probe time to calculate the timings.
> 
> Yes how about the gpmc using driver code registers itself with the gpmc code
> and also registers it's retime function with the gpmc? That way the gpmc fck
> stays inside the gpmc code, and the driver specific retime function should
> be able to do the calculation based on driver clocks. The retime function
> needs to have also a pointer to driver private data for it's clocks etc.

Sorry, not sure whether I follow you properly, based on what has been
understood, will try to rephrase,

All the present gpmc timing calculation done in arch/arm/mach-omap2/gpmc-*
to be moved to gpmc driver. And all the peripheral drivers using gpmc, i.e
like smsc911x, tusb6010 needs to register their retime function with gpmc
driver. And gpmc driver will invoke these registered retime function, when
clock frequency changes.

But wouldn't it need changes in the existing drivers like smsc911x that are
used by multiple architectures with gpmc specific registration (put under
a macro ?). We will be having gpmc driver code that contains knowledge
about peripheral timing calculation, seems there is no way out of this.
Peripheral agnostic gpmc code may not happen it seems

In that case gpmc driver probe would have to be relieved of the task of
setting up gpmc timings as we have to wait till peripheral drivers
register their callback, right ?, seems in that case no timing information
needs (or can be) to be passed from DT

> It seems this retime function may need to be called by the gpmc code when
> L3 changes, and the driver code if the driver is switching between runtime
> and idle clocks like tusb6010 for example does.

I believe you are referring to tusb6010_platform_retime(), other than during
initial setup, i.e. in tusb6010_setup_interface(), it is not invoked.
tusb6010_platform_retime() is an exported symbol, unless I am missing
something it is not invoked other than during initial setup. Did find this
function in tusb6010.c, it is commented out, may be this was present earlier ?

Regards
Afzal