From: "Menon, Nishanth" <nm@ti.com>
To: "Premi, Sanjeev" <premi@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
Date: Wed, 18 May 2011 04:06:18 -0500 [thread overview]
Message-ID: <BANLkTik5ZQLzyNqS6CRuJrActm9O7r7LEA@mail.gmail.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024CFDC82C@dbde02.ent.ti.com>
On Wed, May 18, 2011 at 04:00, Premi, Sanjeev <premi@ti.com> wrote:
>> While cleaning up voltdm_c set earlier this week, I think your changes
>> apply better there.
>> btw, I could incorporate a bit of your code into my patch, esp the one
>> Tony commented on http://marc.info/?l=linux-omap&m=130570559515977&w=2
ok this part got rejected pending regulator framework for scalable
voltage domains..
>> but, overall, on the topic of SR, either:
>> a) move SR autocomp into sysfs (and dump the rest of the debugfs - it
>> is useful for validation, but does'nt really provide additional info)
>> - given that it used to reside in /sys/power/sr_vddx_autocomp and then
>> moved to debugfs, I am not sure if this is the right path
>> b) move SR autocomp into a board defined configuration.. more
>> intrusive, but folks would really want to enable SR as an option at
>> times from userspace - many distros and devices do this (e.g. N900)..
>
> [sp] I am not sure what you are suggesting. Can't we take in the patch and
> then do the movements? ... the ones that doesn't seem to be implemented
> so far (based on your comments).
depends on what Kevin thinks is the future of voltdm(in terms of which
.4x target) - might be good to focus our attention into a single
branch and cleanit up for upstream.. I am personally not sure what
should autocomp's future should be - I think option of having boards
be able to define it - maybe as part of regulator framework + debugfs
cleanup similar(as voltdm_c has removed I believe all of voltage
debugfs - so your patch can be much smaller and effective there)..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-18 9:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-12 17:36 [PATCH] omap:pm: Fix boot-time errors with debugfs disabled Sanjeev Premi
2011-05-12 18:02 ` Menon, Nishanth
2011-05-12 19:16 ` Premi, Sanjeev
2011-05-12 19:58 ` Todd Poynor
2011-05-12 21:03 ` Nishanth Menon
2011-05-13 12:48 ` Premi, Sanjeev
2011-05-17 14:40 ` Premi, Sanjeev
2011-05-18 8:25 ` Menon, Nishanth
2011-05-18 9:00 ` Premi, Sanjeev
2011-05-18 9:06 ` Menon, Nishanth [this message]
2011-05-18 9:16 ` Premi, Sanjeev
2011-05-18 16:34 ` Kevin Hilman
2011-05-18 18:48 ` Menon, Nishanth
2011-05-19 10:30 ` Premi, Sanjeev
2011-05-19 13:58 ` Menon, Nishanth
2011-05-20 15:21 ` Premi, Sanjeev
2011-05-24 23:57 ` 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=BANLkTik5ZQLzyNqS6CRuJrActm9O7r7LEA@mail.gmail.com \
--to=nm@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=premi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).