Gopinath, Thara wrote, on 12/09/2010 03:43 AM:
-----Original Message-----
From: Nishanth Menon [mailto:nm@xxxxxx]
Sent: Wednesday, December 08, 2010 10:05 PM
To: Gopinath, Thara
Cc: Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx; paul@xxxxxxxxx; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and
Smartreflex drivers
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.
Nishant,
The issue here is most of these parameters are one time setting (during init)
> and need not be changed at all if the user does not wish to over-ride
them for
> debug purpose. Hence the need for the checks (not double-hooks). But
I agree
If they are init time thingy, then why not set it up so that when some
one echo's to the debugfs, it writes to the register as well? That way
you dont need to add runtime check and the debug developer does'nt need
to worry about echo 1> magic_control_sys_fs_file (just kidding).
> with your point that let us get the basic in the kernel.org in some
form. So
>for this first version that we plan to push to kernel.org, I plan to
expose out
> these parameters to user space but not allow a write access to them.
The write
>access part can be added later whenever required.
Sure.. at this point, anything that actually works is welcome :)
--
Regards,
Nishanth Menon
--
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
