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? :-)
Thanks,
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
