public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: "Premi, Sanjeev" <premi@ti.com>
Cc: "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 18:16:10 +0530	[thread overview]
Message-ID: <4D762512.6060503@ti.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024C0E6349@dbde02.ent.ti.com>

Premi, Sanjeev wrote, on 03/08/2011 05:56 PM:
[...]
>>>>>
>>>>> Add glue logic to hook-up AM35x processors
>>>>> with TPS65023.
>>>> It seems that you are not really using Voltage layer for any
>> interaction
>>>> with TPS65023 as you are not using VP and VC. Then what is the
>>> purpose of
>>>> registering this PMIC with Voltage layer. I fail to understand the
>>> purpose
>>>> of this patch series.
>>>
>>> [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given
>>> the
>>>       current limitation of all voltage related data being "extracted"
>> from
>>>       the voltage layer - which expects only TWLx0y0 PMICs.
>> Pls use regulator framework for setting the voltage for your PMIC.
>
> [sp] If you follow the current framework, voltage.c is ingrained with
> OMAP3 initialization and same holds good for opp[_3xxx_data].c.
>
> It would have been great if current implementation allowed pluggable
> interface to a PMIC. As it stands today, it isn't.
Partly true - there are PMIC abstractions that have been attempted in 
current voltage layer - but only TWL is used - so yep, implementation 
probably needs evolution and yes again that TPS here is a perfect choice 
to make the implementation generic and scalable.

>
> Until implemented, workarounds have to be put in place to get platform(s)
> working. Though patch series is being done for AM35x with TPS65023. The
> similar workaround would be required for OMAP3 with TPS65023 (for example).
>
> ...and I expect workaround to be simple and unobtrusive.
>
> See:
> core_initcall(omap_voltage_early_init);
> device_initcall(omap3_opp_init);
> late_initcall(omap2_common_pm_late_init);

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

-- 
Regards,
Nishanth Menon

  parent reply	other threads:[~2011-03-08 12:46 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 [this message]
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

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=4D762512.6060503@ti.com \
    --to=nm@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --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