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

[tony@atomide.com (Tony Lindgren)]

* Mohammed, Afzal <afzal@ti.com> [120620 07:57]:
> Hi Tony,
> 
> On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
> > * Mohammed, Afzal <afzal@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.

Yup. We'll be only getting the timings from device tree. Ideally the gpmc
code would just do all the calculations, but it sounds like device timings
may require some calculation on the gpmc consumer driver side 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

Yes the that's there set up automatically. But for the timings we
could have something like this to associate the following invented
gpmc timings with smsc911x:

/* in omap[234].dtsi */
gpmc: gpmc at 480121234 {
	compatible = "ti,gpmc";
	reg = <0x480121234 0x1234>;
	#address-cells = <0>;
	#size-cells = <0>;
};
...

/* in some board *.dts file */
&gpmc {
	gpmc_cs1: gpmc_cs1_timings {
		...
	};
};

net at 48001234 {
	compatible = "smsc,lan91c111";
	reg = <0x48001234 0x10000>;
	interrupts = <12>;
	gpmc_timings = <&gpmc_cs1>;
};

 
> > > > 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)

Yes that might be tricky..

Tony

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