All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cousson, Benoit" <b-cousson@ti.com>
To: Trilok Soni <tsoni@codeaurora.org>
Cc: jean.pihet@newoldbits.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Kevin Hilman <khilman@ti.com>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	LKML <linux-kernel@vger.kernel.org>, Jean Pihet <j-pihet@ti.com>
Subject: Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Date: Wed, 4 Apr 2012 21:41:21 +0200	[thread overview]
Message-ID: <4F7CA3E1.2050809@ti.com> (raw)
In-Reply-To: <4F7C9C89.9080605@codeaurora.org>

On 4/4/2012 9:10 PM, Trilok Soni wrote:
> Hi Jean,
>
> On 3/19/2012 9:42 PM, jean.pihet@newoldbits.com wrote:
>> From: Jean Pihet<j-pihet@ti.com>
>>
>> Move the driver specific macros from the smartreflex header file
>> (arch/arm/mach-omap2/smartreflex.h) in a new header file
>> include/linux/power/smartreflex.h.
>>
>> This change makes the SmartReflex implementation ready for the move
>> to drivers/.
>
> I wonder why someone would need a new directory under drivers/power
> where the code is not about introducing new and generic AVS framework
> but it is all about OMAP specific code.

The main motivation is that it's a driver and thus does not have 
anything to do inside mach-omap2.

Where will you put that otherwise?

> What if tomorrow new generic
> AVS framework comes from different chip vendor? I am sure this kind
> of technology would be common in newer embedded chips.

Probably, but this is hard to know with only one implementation so far 
in the kernel.
I guess when someone else will start pushing some new AVS driver inside 
the AVS directory, we might realize that there is enough common part to 
create a frwmk.

IIRC, David Brownell was referring to the rule of three for such case. 
Meaning that it worth having a generic fmwk when at least three 
different drivers are doing the same kind of things.

Regards,
Benoit

WARNING: multiple messages have this Message-ID (diff)
From: b-cousson@ti.com (Cousson, Benoit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Date: Wed, 4 Apr 2012 21:41:21 +0200	[thread overview]
Message-ID: <4F7CA3E1.2050809@ti.com> (raw)
In-Reply-To: <4F7C9C89.9080605@codeaurora.org>

On 4/4/2012 9:10 PM, Trilok Soni wrote:
> Hi Jean,
>
> On 3/19/2012 9:42 PM, jean.pihet at newoldbits.com wrote:
>> From: Jean Pihet<j-pihet@ti.com>
>>
>> Move the driver specific macros from the smartreflex header file
>> (arch/arm/mach-omap2/smartreflex.h) in a new header file
>> include/linux/power/smartreflex.h.
>>
>> This change makes the SmartReflex implementation ready for the move
>> to drivers/.
>
> I wonder why someone would need a new directory under drivers/power
> where the code is not about introducing new and generic AVS framework
> but it is all about OMAP specific code.

The main motivation is that it's a driver and thus does not have 
anything to do inside mach-omap2.

Where will you put that otherwise?

> What if tomorrow new generic
> AVS framework comes from different chip vendor? I am sure this kind
> of technology would be common in newer embedded chips.

Probably, but this is hard to know with only one implementation so far 
in the kernel.
I guess when someone else will start pushing some new AVS driver inside 
the AVS directory, we might realize that there is enough common part to 
create a frwmk.

IIRC, David Brownell was referring to the rule of three for such case. 
Meaning that it worth having a generic fmwk when at least three 
different drivers are doing the same kind of things.

Regards,
Benoit

WARNING: multiple messages have this Message-ID (diff)
From: "Cousson, Benoit" <b-cousson@ti.com>
To: Trilok Soni <tsoni@codeaurora.org>
Cc: <jean.pihet@newoldbits.com>, <linux-omap@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	Kevin Hilman <khilman@ti.com>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	LKML <linux-kernel@vger.kernel.org>, Jean Pihet <j-pihet@ti.com>
Subject: Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Date: Wed, 4 Apr 2012 21:41:21 +0200	[thread overview]
Message-ID: <4F7CA3E1.2050809@ti.com> (raw)
In-Reply-To: <4F7C9C89.9080605@codeaurora.org>

On 4/4/2012 9:10 PM, Trilok Soni wrote:
> Hi Jean,
>
> On 3/19/2012 9:42 PM, jean.pihet@newoldbits.com wrote:
>> From: Jean Pihet<j-pihet@ti.com>
>>
>> Move the driver specific macros from the smartreflex header file
>> (arch/arm/mach-omap2/smartreflex.h) in a new header file
>> include/linux/power/smartreflex.h.
>>
>> This change makes the SmartReflex implementation ready for the move
>> to drivers/.
>
> I wonder why someone would need a new directory under drivers/power
> where the code is not about introducing new and generic AVS framework
> but it is all about OMAP specific code.

The main motivation is that it's a driver and thus does not have 
anything to do inside mach-omap2.

Where will you put that otherwise?

> What if tomorrow new generic
> AVS framework comes from different chip vendor? I am sure this kind
> of technology would be common in newer embedded chips.

Probably, but this is hard to know with only one implementation so far 
in the kernel.
I guess when someone else will start pushing some new AVS driver inside 
the AVS directory, we might realize that there is enough common part to 
create a frwmk.

IIRC, David Brownell was referring to the rule of three for such case. 
Meaning that it worth having a generic fmwk when at least three 
different drivers are doing the same kind of things.

Regards,
Benoit

  reply	other threads:[~2012-04-04 19:41 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19 16:12 [PATCH v2 0/9] PM: Create the AVS class of drivers jean.pihet
2012-03-19 16:12 ` jean.pihet at newoldbits.com
2012-03-19 16:12 ` [PATCH 1/9] ARM: OMAP3+: voltage: export functions to plat/voltage.h jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-04-18 17:27   ` Kevin Hilman
2012-04-18 17:27     ` Kevin Hilman
2012-04-18 20:36     ` Jean Pihet
2012-04-18 20:36       ` Jean Pihet
2012-04-18 20:36       ` Jean Pihet
2012-03-19 16:12 ` [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-04-04 19:10   ` Trilok Soni
2012-04-04 19:10     ` Trilok Soni
2012-04-04 19:41     ` Cousson, Benoit [this message]
2012-04-04 19:41       ` Cousson, Benoit
2012-04-04 19:41       ` Cousson, Benoit
2012-04-05  6:53       ` Trilok Soni
2012-04-05  6:53         ` Trilok Soni
2012-04-05  8:59         ` Jean Pihet
2012-04-05  8:59           ` Jean Pihet
2012-04-05  9:35           ` Trilok Soni
2012-04-05  9:35             ` Trilok Soni
2012-04-19 13:54             ` Arnd Bergmann
2012-04-19 13:54               ` Arnd Bergmann
2012-04-19 16:02               ` Jean Pihet
2012-04-19 16:02                 ` Jean Pihet
2012-04-19 16:02                 ` Jean Pihet
2012-04-19 17:06               ` Kevin Hilman
2012-04-19 17:06                 ` Kevin Hilman
2012-04-19 17:06                 ` Kevin Hilman
2012-03-19 16:12 ` [PATCH 3/9] ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr * jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-03-19 16:12 ` [PATCH 4/9] ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of voltage domains jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-03-19 16:12 ` [PATCH 5/9] ARM: OMAP3: hwmod: rename the smartreflex entries jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-04-18 17:33   ` Kevin Hilman
2012-04-18 17:33     ` Kevin Hilman
2012-04-18 20:41     ` Jean Pihet
2012-04-18 20:41       ` Jean Pihet
2012-04-18 20:41       ` Jean Pihet
2012-03-19 16:12 ` [PATCH 6/9] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-03-19 16:12 ` [PATCH 7/9] ARM: OMAP2+: SmartReflex: Use per-OPP data structure jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-04-18 18:21   ` Kevin Hilman
2012-04-18 18:21     ` Kevin Hilman
2012-04-18 20:52     ` Jean Pihet
2012-04-18 20:52       ` Jean Pihet
2012-04-18 20:52       ` Jean Pihet
2012-03-19 16:12 ` [PATCH 8/9] ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-03-19 16:12 ` [PATCH 9/9] ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/ jean.pihet
2012-03-19 16:12   ` jean.pihet at newoldbits.com
2012-04-18 18:17   ` Kevin Hilman
2012-04-18 18:17     ` Kevin Hilman
2012-04-03 11:14 ` [PATCH v2 0/9] PM: Create the AVS class of drivers Jean Pihet
2012-04-03 11:14   ` Jean Pihet
2012-04-03 11:14   ` Jean Pihet
2012-04-18  8:04 ` Jean Pihet
2012-04-18  8:04   ` Jean Pihet
2012-04-19  0:08   ` Greg KH
2012-04-19  0:08     ` Greg KH
2012-04-18 18:29 ` Kevin Hilman
2012-04-18 18:29   ` Kevin Hilman
2012-04-18 18:30 ` Kevin Hilman
2012-04-18 18:30   ` Kevin Hilman
2012-04-18 18:30   ` Kevin Hilman
2012-04-18 18:49   ` Rafael J. Wysocki
2012-04-18 18:49     ` Rafael J. Wysocki
2012-04-18 18:49     ` Rafael J. Wysocki

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=4F7CA3E1.2050809@ti.com \
    --to=b-cousson@ti.com \
    --cc=j-pihet@ti.com \
    --cc=jean.pihet@newoldbits.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=tsoni@codeaurora.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 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.