Hi, On Thu, Mar 24, 2011 at 8:44 PM, Cousson, Benoit <b-cousson@xxxxxx> wrote: > On 3/24/2011 3:00 PM, Hilman, Kevin wrote: >> >> Hi Shweta, >> >> "Gulati, Shweta"<shweta.gulati@xxxxxx> writes: >> >> [...] >> >>>>> >>>>> And what about vdd_name? It should probably be removed as well. >>>>> >>>> >>>> Yes, but it's currently used by the SR layer (currently the only user.) >>>> >>>> Removing it required cleaning up the SR layer as well, so I decided to >>>> leave the SR cleanups for someone else for the moment while I focus on >>>> the voltage layer(s) >>>> >>> Even if we try to remove 'vdd_name', how should we get 'struct >>> voltagedomain' >>> info corresponding to sr_mpu, sr_core in sr_dev_init API? >>> >>> As functional clock of SR1 and SR2 are from wake up domain, so even if >>> we try to use current Clockdomain and Powerdomain framework APIs, to >>> get 'clkdomain' pointer and then retrieve 'pwrdomain' pointer, finally >>> getting 'voltdomain' pointer we would get 'WKUP' voltage domain ptr >>> not the 'mpu' or 'core' voltdomain pointer. >> >> Correct. >> >> I got this far and realized not only does the voltage layer need a >> cleanup, the SR layer needs a cleanup, but I need to focus on one thing >> at a time. >> >> As you noticed, what we need is the voltage domain of the SR sensor, not >> the voltage domain of the SR IP. >> >> Probably the best way to do this is ad the sensor voltage domain to the >> dev_attr of each SR module. > > Yep, I do agree. SR instances are all inside the CORE, but there is a > dedicated sensor in each scalable voltage domain. > dev_attr is the perfect place for that. In fact I do not understand why it > was not added there initially??? > > Even the kerneldoc is confusing and not accurate: > * @vdd_name: voltage domain name > > Whereas, SR is using that to provide the name of the voltage rail controlled > by it. > > Let's provide a quick patch to get rid of that and replace it by a dev_attr. > > Shweta, are you volunteer? :-) Yes, I would submit Patch adding volt domain info in dev_attr of SR instances. > Thanks, > Benoit > -- Thanks, Regards, Shweta -- 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
