On 8/4/2010 6:31 AM, Gopinath, Thara wrote:
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 25, 2010 11:56 PM
Thara Gopinath<th...@ti.com> writes:
This patch removes the usage of vdd and sr id alltogether.
This is achieved by introducing a separte voltage domain per
VDD and hooking this up with the voltage and smartreflex
internal info structure. Any user of voltage or smartreflex layer
should call into omap_volt_domain_get to get the voltage
domain handle and make use of this to call into the various
exported API's.
Great, I'm glad to see those gone.
Minor comment on naming:
In current code, we currently have
struct clockdomain *clkdm;
struct powerdomain *pwrdm;
so, for consistency, I'd suggest using
struct voltagedomain *voltdm;
instead of this:
struct omap_volt_domain *volt_domain;
Also, it looks like your 'struct omap_vdd_info' is the real struct that
represents a voltage domain.
Maybe you're planning this already, but I suggest you get rid of
omap_vdd_info and just move all that stuff into the voltagedomain.
Again, that will probably create a diff with a ton of renames, so this
should just be part of your V2 series.
Are you sure? Because omap_vdd_info contains all the internal details about the
voltage domains. Do we really want to expose it? IMHO omap_vdd_info should
remain as
internal structure instead of exposing it out.
I think as well that struct voltagedomain should be a soc generic
representation of the voltage domain, whereas omap_vdd_info will contain
all the soc specific details.
The issue with voltage domain, is that the compared to clockdomain and
powerdomain, the details are quite different between OMAP2, 3 and 4.
OMAP2 does not have any VP, VC, SR, so in this case, the voltagedomain
should be almost empty whereas OMAP3 will contain much more stuff. OMAP4
should be pretty similar.
That being said, since we have only 1 scalable voltage domain on OMAP2,
we can still manage the overhead.
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
