>>-----Original Message----- >>From: Nishanth Menon [mailto:n...@ti.com] >>Sent: Wednesday, December 08, 2010 10:05 PM >>To: Gopinath, Thara >>Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; 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 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. Regards Thara >> >>--- >>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
