From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
Date: Thu, 16 Sep 2010 09:06:36 -0500 [thread overview]
Message-ID: <4C92246C.3010404@ti.com> (raw)
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB032944262A@dbde02.ent.ti.com>
Gopinath, Thara had written, on 09/16/2010 08:51 AM, the following:
>
>>> -----Original Message-----
>>> From: Menon, Nishanth
>>> Sent: Thursday, September 16, 2010 5:45 PM
>>> To: Gopinath, Thara
>>> Cc: Kevin Hilman; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
>>> Subject: Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
>>>
>>> Gopinath, Thara had written, on 09/16/2010 05:40 AM, the following:
>>>>>> -----Original Message-----
>>>>>> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of
>>> Kevin
>>>>>> Hilman
>>>>>> Sent: Thursday, September 16, 2010 3:27 AM
>>>>>> To: linux-omap at vger.kernel.org
>>>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>>>> Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
>>>>>>
>>>>>> From: Paul Walmsley <paul@pwsan.com>
>>>>>>
>>>>>> The OPP layer code should be independent of the PMIC,
>>>>>> introduce the TWL/TPS-specific code out to its own file.
>>>> Hello Kevin,
>>>>
>>>> I have been using this code for a while now. I really do not think wee need a separate
>>>> file for implementing the vsel to voltage in (uV) and vice versa formulas. Today only voltage
>>> This split introduces a PMIC level abstraction already. Do you have a
>>> suggestion which file it should go to? It is definitely not part of
>>> opp.c, not part of other existing twl files as well. the job of this
>>> file was to introduce conversion routines which can be used by any layer
>>> (voltage layer if need be - it used to be srf and smartreflex before)..
>>> in fact one of your voltage layer patches introduces capability for 6030
>>> as well
>>> http://marc.info/?l=linux-omap&m=128213020927919&w=2
>
> Yes one of my patches has introduces this coz I had no other way
> to add OMAP4 support. But I still do not understand why cant these
> APIs be implemented in twl-core.c or twl4030-power.c?
Why there? Twl power does regulator operations not conversion
operations. core is not the place either as it is function independent.
>
>>>> layer is interested in these conversions. Voltage layer has a structure that can be populated with
>>>> the information required from the PMIC. We only need to add two more function pointers to this
>>> structure.
>>>> This info can then be passed from the actual PMIC driver file. This
>>> will make it much
>>>> more simpler for OMAP4 where we have different formulas between different revisions of PMIC. Also
>>>> in the omap voltage code we will no longer have to hard code omap_twl_vsel_to_uv and
>>> omap_twl_uv_to_vsel.
>>> I think the problem is with the voltage layer (which has not been posted
>>> upstream) which is using hard coded function pointer. What the patchset
>>> should have done is to introduce function pointers registration from
>>> twl_tps.c to voltage layer and voltage layer should ideally been using
>>> function pointers by itself.
>>>
>>>> So please consider dropping this patch from this series.
>>> I think I disagree - rationale for having this separated as a pmic
>>> specific file is still sound, only the implementation of the future
>>> framework should have changed (it should be using function pointers
>>> instead of hardcoded function names). in fact I can add additional
>>> suggestion for the voltage layer: the pmic selection should be done from
>>> a board file - This will allow voltage layer to handle numerous PMICs
>>> and combination of PMICs controlling various domains as well.. the only
>>> neat way to handle it is ofcourse using function pointers.
>
> Exactly if voltage layer has to use a func ptr, why not let them be populated
> by the PMIC driver files directly?
Again, we are going into the details of how voltage layer will be
implemented.. What suggestion do you do when on board x vdd1 is driven
by PMIC1, vdd2 by PMIC2? it will have to be somesort of different
registration mechanism. but nothing prevents the framework from
registering the pointers defined in twl_tps.c
>
>>>
>>> PS: Suggestion
>>> - please fix your mailer to round off for 70/80 char.
>
> Will try.
>
>>> - might be good to point folks to rfc patchset for voltage layer to give
>>> context.
>
> https://patchwork.kernel.org/patch/119429/
thanks..
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-09-16 14:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 21:56 [PATCH 0/4] OMAP OPP layer for 2.6.37 Kevin Hilman
2010-09-15 21:56 ` [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs Kevin Hilman
2010-09-16 10:25 ` Gopinath, Thara
2010-09-16 10:32 ` Menon, Nishanth
2010-09-16 10:33 ` Gopinath, Thara
2010-09-16 12:19 ` Linus Walleij
2010-09-16 12:40 ` Nishanth Menon
2010-09-16 13:24 ` Linus Walleij
2010-09-16 15:08 ` Kevin Hilman
2010-09-16 15:31 ` Nishanth Menon
2010-09-16 15:48 ` Kevin Hilman
2010-09-16 17:07 ` Linus Walleij
2010-09-16 17:10 ` Nishanth Menon
2010-09-16 17:13 ` Shilimkar, Santosh
2010-09-16 18:01 ` Kevin Hilman
2010-09-16 13:54 ` Roger Quadros
2010-09-16 14:01 ` Nishanth Menon
2010-09-16 14:20 ` Roger Quadros
2010-09-16 14:43 ` Nishanth Menon
2010-09-15 21:56 ` [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Kevin Hilman
2010-09-16 10:40 ` Gopinath, Thara
2010-09-16 12:15 ` Nishanth Menon
2010-09-16 13:51 ` Gopinath, Thara
2010-09-16 14:06 ` Nishanth Menon [this message]
2010-09-17 14:57 ` Gopinath, Thara
2010-09-17 15:03 ` Nishanth Menon
2010-09-16 17:16 ` Kevin Hilman
2010-09-17 15:11 ` Gopinath, Thara
2010-09-15 21:56 ` [PATCH 3/4] OMAP3: remove OPP interfaces from OMAP PM layer Kevin Hilman
2010-09-15 21:56 ` [PATCH 4/4] OMAP3: OPP: add OPP table data and initialization 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=4C92246C.3010404@ti.com \
--to=nm@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).