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>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [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@vger.kernel.org; linux-arm-kernel@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@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
>>> Kevin
>>>>>> Hilman
>>>>>> Sent: Thursday, September 16, 2010 3:27 AM
>>>>>> To: linux-omap@vger.kernel.org
>>>>>> Cc: linux-arm-kernel@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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2010-09-16 14:06 UTC|newest]

Thread overview: 61+ 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 ` Kevin Hilman
2010-09-15 21:56 ` [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs Kevin Hilman
2010-09-15 21:56   ` Kevin Hilman
2010-09-16 10:25   ` Gopinath, Thara
2010-09-16 10:25     ` Gopinath, Thara
2010-09-16 10:32     ` Menon, Nishanth
2010-09-16 10:32       ` Menon, Nishanth
2010-09-16 10:33       ` Gopinath, Thara
2010-09-16 10:33         ` Gopinath, Thara
2010-09-16 12:19   ` Linus Walleij
2010-09-16 12:19     ` Linus Walleij
2010-09-16 12:40     ` Nishanth Menon
2010-09-16 12:40       ` Nishanth Menon
2010-09-16 13:24       ` Linus Walleij
2010-09-16 13:24         ` Linus Walleij
2010-09-16 15:08     ` Kevin Hilman
2010-09-16 15:08       ` Kevin Hilman
2010-09-16 15:31       ` Nishanth Menon
2010-09-16 15:31         ` Nishanth Menon
2010-09-16 15:48         ` Kevin Hilman
2010-09-16 15:48           ` Kevin Hilman
2010-09-16 17:07           ` Linus Walleij
2010-09-16 17:07             ` Linus Walleij
2010-09-16 17:10             ` Nishanth Menon
2010-09-16 17:10               ` Nishanth Menon
2010-09-16 17:13               ` Shilimkar, Santosh
2010-09-16 17:13                 ` Shilimkar, Santosh
2010-09-16 18:01                 ` Kevin Hilman
2010-09-16 18:01                   ` Kevin Hilman
2010-09-16 13:54   ` Roger Quadros
2010-09-16 13:54     ` Roger Quadros
2010-09-16 14:01     ` Nishanth Menon
2010-09-16 14:01       ` Nishanth Menon
2010-09-16 14:20       ` Roger Quadros
2010-09-16 14:20         ` Roger Quadros
2010-09-16 14:43         ` Nishanth Menon
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-15 21:56   ` Kevin Hilman
2010-09-16 10:40   ` Gopinath, Thara
2010-09-16 10:40     ` Gopinath, Thara
2010-09-16 12:15     ` Nishanth Menon
2010-09-16 12:15       ` Nishanth Menon
2010-09-16 13:51       ` Gopinath, Thara
2010-09-16 13:51         ` Gopinath, Thara
2010-09-16 14:06         ` Nishanth Menon [this message]
2010-09-16 14:06           ` Nishanth Menon
2010-09-17 14:57           ` Gopinath, Thara
2010-09-17 14:57             ` Gopinath, Thara
2010-09-17 15:03             ` Nishanth Menon
2010-09-17 15:03               ` Nishanth Menon
2010-09-16 17:16     ` Kevin Hilman
2010-09-16 17:16       ` Kevin Hilman
2010-09-17 15:11       ` Gopinath, Thara
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   ` Kevin Hilman
2010-09-15 21:56 ` [PATCH 4/4] OMAP3: OPP: add OPP table data and initialization Kevin Hilman
2010-09-15 21:56   ` Kevin Hilman
  -- strict thread matches above, loose matches on Subject: below --
2010-08-11  0:09 [PATCH 0/4] OMAP OPP layer Kevin Hilman
2010-08-11  0:09 ` [PATCH 2/4] omap: opp: twl/tps: Introduce TWL/TPS-specific code 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=khilman@deeprootsystems.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=thara@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.