public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: "Menon, Nishanth" <nm@ti.com>
Cc: "Premi, Sanjeev" <premi@ti.com>,
	"Sripathy, Vishwanath" <vishwanath.bs@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
Date: Tue, 08 Mar 2011 08:08:57 -0800	[thread overview]
Message-ID: <87tyfdvbl2.fsf@ti.com> (raw)
In-Reply-To: <AANLkTikaY5kjbFJtUcnwTOoZJjn6BL8oqXN+B6x_fxav@mail.gmail.com> (Nishanth Menon's message of "Tue, 8 Mar 2011 18:57:36 +0530")

"Menon, Nishanth" <nm@ti.com> writes:

> On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev <premi@ti.com> wrote:
> [...]
>>> Thinking from a generic soln perspective, lets try and split this into
>>> multiple issues:
>>> a) OPP and Voltage layer voltages - these need to be PMIC aware as well.
>>> See my comment on http://marc.info/?l=linux-omap&m=129955003611548&w=2
>>> -> essentially means that pmic_voltage information should be registered
>>> earlier to opp init
>>>
>>> b) split up structure information for voltage layer - this should be
>>> done in a manner to make PMIC, Board and OMAP SoC information independent.
>>>
>>> c) Ability to plug in multiple PMICs in two manners:
>>>     i) use PMIC with VC/VP/SR combinations.
>>>     ii) use PMIC which is plugged on regulator frameworks.
>>>
>>> If anyone is attempting cleanups, it might be a good idea to base on the
>>> accepted cleanups from pm-core branch which is planned for 39-rc1 to
>>> prevent any surprises ;)
>>
>> [sp] Without trying to understand much internal details on the proposed
>>     solution, workaround is necessary to get AM35x platforms to even boot
>>     on current baselines.
>>
>>     Using regulator framework etc. are long poles; that can easily be
>>     avoided; and this RFC was meant for that.
>>
>>     Knowing that there is already a clean-up effort; simple workaround
>>     makes even better proposition.
> Personally speaking, it is better we do the cleanup and integrate to
> mainline. since we are in the process of cleaning up, it might be a
> good idea for contributions from you and all interested folks to
> ensure that the final code will support the configurations we all need

We have kwown for a long time that we have hard-coded PMIC assumptions
in the current code.  We have slowly added some minimal ways to make
PMIC-variable things pluggable, but indeed it has only ever been tested
with TWL* PMICs.

The best way to fix this going forward is for those who are adding
support for other PMICs to propose solutions that will make this scale
to other PMICs.

If that involves short-term hacks/workarounds to get things
building/booting on non-TWL4030 platforms, that is OK with me.  But I
would also like to be sure that efforts are underway to do it the right
way in parallel.

Kevin



--
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

      parent reply	other threads:[~2011-03-08 16:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-23 17:58 [RFC 0/3] Support TPS65023 with AM35xx Sanjeev Premi
2011-02-23 17:58 ` [RFC 1/3] omap: voltage: Allow custom vp_init() implementation Sanjeev Premi
2011-02-23 18:36   ` Menon, Nishanth
2011-02-23 20:45     ` Premi, Sanjeev
2011-02-24  1:11       ` Nishanth Menon
2011-02-23 17:58 ` [RFC 2/3] am35xx: voltage: Add basic initialization Sanjeev Premi
2011-02-23 18:40   ` Menon, Nishanth
2011-02-23 17:58 ` [RFC 3/3] am35xx: pm: Hook-up with TPS65023 Sanjeev Premi
2011-02-23 18:43   ` Menon, Nishanth
2011-02-24 13:20     ` Premi, Sanjeev
2011-02-24 10:04   ` Vishwanath Sripathy
2011-03-07 15:20     ` Premi, Sanjeev
2011-03-07 16:31       ` Vishwanath Sripathy
2011-03-08 12:26         ` Premi, Sanjeev
2011-03-08 12:45           ` Vishwanath Sripathy
2011-03-08 13:25             ` Premi, Sanjeev
2011-03-08 12:46           ` Nishanth Menon
2011-03-08 13:18             ` Premi, Sanjeev
2011-03-08 13:27               ` Menon, Nishanth
2011-03-08 13:37                 ` Premi, Sanjeev
2011-03-08 16:08                 ` Kevin Hilman [this message]

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=87tyfdvbl2.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=premi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox