[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

[Mohammed, Afzal]

Hi Tony,

On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
> * Mohammed, Afzal <afzal at ti.com> [120616 02:19]:
> > On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:

> > By gpmc registration, if you meant registering platform device for
> > gpmc peripherals, for a board that uses the new gpmc driver interface*,
> > it will be done in probe only.
> 
> I was thinking when the gpmc needs to be initialized, and there should
> not be any need to do it earlier than at the gpmc using driver probe
> time. With device tree that is, as there's no need to stuff the gpmc
> timings into a board-*.c file.

I believe by "gpmc needs to be initialized", you meant calculating gpmc
timings, determining configuration, the things that are done in functions
like gpmc_smsc911x_update etc. as in [1] and not initializing gpmc at
hardware level. With the above assumption, I feel we need to have a way
first to generalize gpmc timing calculation for different peripherals as
suggested by Jon as well as have logic to handle timings that depends on
cycles too.

> > > It may require some bus level hooks, or wrapper drivers for the generic
> > > device drivers like smsc911x.
> > 
> > This too, not sure whether I follow you
> 
> Well smsc911x has device tree binding, and is a generic driver. How do
> we trigger the gpmc initialization from a generic driver probe?

Not sure whether device tree have capability to represent something like
child devices, if non bus devices can have child devices, then we
can have peripherals connected to gpmc as childs, but may be this will
remain only as a dream; I need to get into DT to find things out

> > > We should not need to pass clock handles around. It's better to
> > > export some helper functions in the gpmc code for the calculation.
> > 
> > Currently we have helper function in gpmc.c for the same, were you
> > referring those ?
> 
> Yes something that let's the driver call gpmc code to do the calculation.
> The other option would be to just add gpmc clock as a clock fwk node,
> and then the driver could clk_get() it as ick.

For gpmc driver to calculate timings rather than platform code doing it,
we first need to have a generalized way to calculate gpmc timings for
all peripherals as well as have a logic to calculate timings based on
time & cycles, correct ? (to make sure we are talking the same thing)

Regards
Afzal

[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69926.html