"Cousson, Benoit" <b-cousson@xxxxxx> writes: > On 8/4/2010 6:31 AM, Gopinath, Thara wrote: >>>> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>>> Sent: Friday, June 25, 2010 11:56 PM >>>> >>>> Thara Gopinath<thara@xxxxxx> 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. OK. Kevin > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
