Cousson, Benoit had written, on 03/19/2010 05:14 AM, the following:
Hi Nishanth,
From: Menon, Nishanth
Sent: Thursday, March 18, 2010 7:45 PM
Many modules seem to need some sort of flexible storage mechanism
which is corresponds to a specific opp. To cater to this need, we
provide store, restore and removal apis.
Do we really need that level of flexibility for the moment?
The type of information that belong to an OPP are kind of static for a dedicated SoC (i.e. SR gain, Ntarget, ABB).
Cannot a simple pointer to a static struct do the job?
That's just my two cents.
The follow on patch shows why that flexibility is needed. this is
important IMHO from a multiple-OMAP boot perspective -> the data is
static for *each* dedicated SOC, but the nature of the data and the type
of information stored will vary between SOCs themselves. as an example -
There is no need to store NTarget on OMAP2/OMAP1 platform, while OMAP4
or beyond may have additional data to store.
This allows an unified store and retrival capability for OPP specific
data without knowing or constraining the exact type of data stored.
consider(hypothetically) how u'd implement dependency using resource
framework across OMAPs in a uniform way -> we'd need custom apis
get_vdd1_threshold and get_vdd2_threshold etc.. which are pretty much
custom api implementation
in the case of 3630 vs 3430 the nTargets are different. for 3430 ABB
data is probably irrelevant - for that matter nTarget may or maynot be
programmed for a specific OPP (hypothetically again)..
But in short, there is some custom SOC data tied down to a specific OPP
- this data may or maynot be present based on SOC and OPPs - today's OPP
layer lacks this flexibility and with it, we can better optimize the
logic we write. hence this introduction to it.
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
