Gopinath, Thara had written, on 12/08/2010 10:18 AM, the following:
[..]
And, AFAICT, it wasn't clear from the current code or docs whether this
could work or was expected to work either, e.g., if you set
override_volt_params back to zero, to the original values all get reused?

If you want to provide this feature, then it should be documented and
made clear that this is an intended goal.

Thinking about this more, the main thing I don't like about this
approach is that the active code paths (enable & disable) have to check
each time if any of these values have been overidden.

Rather than have several places in the active code paths where this
override value is checked, there the sysfs methods should simply update
the values that are used by the core code.  This way, the core would
not need to know about where the values came from (defalts, volt_data,
user override, etc.)

If you want to provide a way to revert this, then maybe writing -1 will
should switch that value back to the HW default, or volt_data default.
Kevin, Benoit, Nishant et al,

Without this override flag today there is no direct way of
allowing user to write into these parameters. My question is,
Glancing at the debug entries being overidden, as developer (debug users) working for tweaking parameters for their platform - yes - we will need some mechanism to runtime tweak and see the behavior without needing to rebuild the kernel everytime.

On production system (OS users): they should'nt be using this.


is there a need for the parameters to be over-written
from the user-space? If yes, I need ideas on how to
implement it with using override_volt_params !

Lets get the basics in kernel.org in some form! IMHO, all this double knobs are un-necessary overheads in codeflow for development only code- just provide the debugfs entries that reflect the data in their original structures, use the original structures everytime we go to a new transition (aka if you change the params in debugfs, they dont take effect till you do another transition).. but that is just my 2cents.

---
Regards,
Nishanth Menon
--
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

Reply via email to