[PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data

On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:

* Hiremath, Vaibhav [off-list ref] [120815 02:11]:

quoted

On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote:

quoted

Hi,

* Paul Walmsley [off-list ref] [120726 13:07]:

quoted

On Wed, 25 Jul 2012, Paul Walmsley wrote:

quoted

These IP blocks and the ECAP IP blocks have periods in their names.
The rest of the IP block named in the file don't use periods -- which
is also the style used by the rest of the OMAP SoCs.  Is there
some reason that these have periods in their names?

I've changed those to match the rest of the names, and queued the 
following for 3.7.

Thanks again for all the hard work you all put into this.  I realize that 
with all the upstream changes, this was probably a little painful for you. 
But from my perspective you've been a pleasure to work with through the 
process.

As am33xx and omap5 are DT only, we should start moving towards getting
rid of grep -E "irq|pa_start|pa_end|dma" in this patch and get the standard
data from .dtsi files instead.

It may not be so straight, given the fact that hwmod layer 
requires these resources, as hwmod is responsible to configure SYSCONF 
register of the device (happens very early at core_init level).

Somehow we have to have some mechanism to initialize " _mpu_rt_va" before 
core_init call, which will take DT resources and initialize accordingly.

That's for the device reset/idle? We should not do that in hwmod code
except in late_initcall for unclaimed devices as discussed earlier. We
discussed setting up the reset function in the device specific headers
so both device and hwmod code can call them as needed.
 

Tony,

May be I didn't understand your above statement, can you please elaborate 
more on "device specific header file"?


Just to highlight, its not only during late_initcall, the _enable and _idle 
functions are getting executed as part of every runtime_pm_get\put_sync from 
the driver.

Are you saying as part of late_initcall, we should initialize " _mpu_rt_va" 
of "struct omap_hwmod"???

Also, as far unclaimed resources is concerned, somewhere you should have 
base addr of the device maintained, right? Currently, hwmod is maintaining 
this data and the execution goes something like,

Core_initcall()
	-> _setup()
		-> _setup_reset()
		-> _idle()


Another biggest worry is, if I play here, it may break existing omap3/4 
Functionality, especially may impact from PM perspective. So I believe, we 
need to have something which adds/cleans-up things in stages.
May be get rid of resource overwriting for AM33xx and OMAP5 alone as of 
now??

Any thoughts??

Thanks,
Vaibhav

quoted

Another dependency we will have is on system timers, Jon has already done 
some initial work on this, but I believe we did not concluded on the it.
I will re-start the thread again, since in any case DT support in timer is 
required.

Right.. The timers are a pain right now as they need to be initialized
early. Everything else can and should be initialized at the device probe
time, or from a late_initcall for the unclaimed devices.
 

quoted

quoted

Alternatively we could get rid of the names and match the module based on
pa_start and pa_end.

Just FYI, from resource perspective, I have changed omap_device layer for DT 
resources only (still need hwmod resources as explained above) and patch 
looks something like (and it works) -

Cool yeah few more dependencies remain still.

Regards,

Tony