All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: "Gopinath, Thara" <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"paul@pwsan.com" <paul@pwsan.com>,
	"Cousson, Benoit" <b-cousson@ti.com>,
	"Sripathy, Vishwanath" <vishwanath.bs@ti.com>,
	"Sawant, Anand" <sawant@ti.com>
Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Date: Wed, 08 Dec 2010 10:34:31 -0600	[thread overview]
Message-ID: <4CFFB397.60203@ti.com> (raw)
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB0373831615@dbde02.ent.ti.com>

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

  reply	other threads:[~2010-12-08 16:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-27 16:10 [PATCH v4 0/9] OMAP3: Adding Smartreflex and Voltage driver support Thara Gopinath
2010-10-27 16:10 ` [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3 Thara Gopinath
2010-11-10 18:59   ` Kevin Hilman
2010-11-15 10:47     ` Gopinath, Thara
     [not found]   ` <FCCFB4CDC6E5564B9182F639FC356087034C012076@dbde02.ent.ti.com>
2010-11-15 14:55     ` Gopinath, Thara
     [not found]   ` <87hbfp9gli.fsf@deeprootsystems.com>
     [not found]     ` <5A47E75E594F054BAF48C5E4FC4B92AB035EFF4E51@dbde02.ent.ti.com>
2010-11-15 19:43       ` Kevin Hilman
2010-12-02  6:13     ` Gopinath, Thara
2010-10-27 16:10 ` [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support Thara Gopinath
2010-10-27 16:10 ` [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file Thara Gopinath
2010-10-28  5:38   ` Varadarajan, Charulatha
2010-10-28 15:26     ` Gopinath, Thara
2010-10-29  4:48       ` Varadarajan, Charulatha
2010-10-27 16:10 ` [PATCH v4 4/9] OMAP3: PM: Adding smartreflex hwmod data Thara Gopinath
2010-10-27 16:10 ` [PATCH v4 5/9] OMAP3: PM: Adding smartreflex class3 driver Thara Gopinath
2010-10-27 16:10 ` [PATCH v4 6/9] OMAP3: PM: Adding T2 enabling of smartreflex support Thara Gopinath
2010-10-27 16:10 ` [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Thara Gopinath
2010-11-10 19:12   ` Kevin Hilman
2010-11-15 11:00     ` Gopinath, Thara
2010-11-15 22:12       ` Kevin Hilman
2010-12-08 16:18         ` Gopinath, Thara
2010-12-08 16:34           ` Nishanth Menon [this message]
2010-12-09  9:43             ` Gopinath, Thara
2010-12-09 11:23               ` Nishanth Menon
2010-12-09 14:13                 ` Gopinath, Thara
2010-12-09 17:19               ` Kevin Hilman
2010-12-09 17:22                 ` Nishanth Menon
2010-10-27 16:10 ` [PATCH v4 8/9] OMAP3: PM: Program correct init voltages for VDD1 and VDD2 Thara Gopinath
2010-10-27 16:10 ` [PATCH v4 9/9] OMAP3: PM: Register TWL4030 pmic info with the voltage driver Thara Gopinath
2010-10-27 17:21 ` [PATCH v4 0/9] OMAP3: Adding Smartreflex and Voltage driver support Nishanth Menon
2010-10-28 15:32   ` Gopinath, Thara
2010-11-10 19:03     ` Kevin Hilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CFFB397.60203@ti.com \
    --to=nm@ti.com \
    --cc=b-cousson@ti.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=sawant@ti.com \
    --cc=thara@ti.com \
    --cc=vishwanath.bs@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.