* Mohammed, Afzal [off-list ref] [120704 00:05]:

Hi Tony,

On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote:

quoted

* Jon Hunter [off-list ref] [120702 10:30]:

quoted

quoted

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

It depends. For some drivers scaling both gpmc clock and the device clock
can happen, like with tusb6010 for example. But the smsc911x does not know
about the clocks.. So to additional changes to the driver would be required
to if device clocks need scaling. But for now, we should be able to do it
at gpmc level with the retime function, or just disable DFS for those clocks
if not supported.

The ideal solution in the long run would be to have gpmc scaling frequency
as the bus and device scaling frequency using cpufreq/devicefreq whatever
notifiers.
 

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

Well we should pass all the gpmc timing information from DT. And then the
driver also still needs to register it's retime function with gpmc.

quoted

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 ?

Hmm yes looks like it's commented out.. But in theory the retime function
should be called between idle clock and runtime clock. And also for DFS,
so it's something we should be considered for proper gpmc support.

Regards,

Tony