From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Trilok Soni <tsoni@codeaurora.org>,
Jean Pihet <jean.pihet@newoldbits.com>,
Kevin Hilman <khilman@ti.com>,
"Cousson, Benoit" <b-cousson@ti.com>,
gregkh@linuxfoundation.org, LKML <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-omap@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: Thu, 19 Apr 2012 13:54:38 +0000 [thread overview]
Message-ID: <201204191354.38874.arnd@arndb.de> (raw)
In-Reply-To: <4F7D6746.9020504@codeaurora.org>
On Thursday 05 April 2012, Trilok Soni wrote:
> >> Couple of suggestions:
> >>
> >> drivers/platform/omap/avs?
> >> drivers/misc/omap/avs?
> >>
I would definitely prefer something under drivers/power,
drivers/regulators or a new top-level directory under
drivers.
> >>> 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.
> >
> > Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-)
> > More seriously, the OMAP code for SmartReflex is far from complete in
> > mainline. There is a plan to provide the following features:
> > - OMAP v1 IP,
> > - OMAP v2 IP,
> > - class 1.5,
> > - class 3,
> > - class 3.5,
> > - and more support for the upcoming chipsets.
>
> I don't understand much of these versions right now, but hopefully after
> going through all these docs. My only contention point is to not create
> any directory into the drivers/power, unless it is generic fwk and then
> build up "client" drivers on top of it. Meanwhile we could move this
> driver into above options as I have suggested.
I think creating the directory in the place where we want the files
to stay in the long run is ok, if the plan is to add more drivers and
make the base code more generic. We don't have to wait until it's too
late and we absolutely need a framework ;-)
The part I don't understand is how this relates to the regulator framework.
Is there any overlap between the functionality provided by the
smartreflex framework and the regulator framework? If so, would it be
better to extend the existing framework so it can do smartreflex as well?
Arnd
next prev parent reply other threads:[~2012-04-19 13:54 UTC|newest]
Thread overview: 31+ 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 ` [PATCH 1/9] ARM: OMAP3+: voltage: export functions to plat/voltage.h jean.pihet
2012-04-18 17:27 ` Kevin Hilman
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-04-04 19:10 ` Trilok Soni
2012-04-04 19:41 ` Cousson, Benoit
2012-04-05 6:53 ` Trilok Soni
2012-04-05 8:59 ` Jean Pihet
2012-04-05 9:35 ` Trilok Soni
2012-04-19 13:54 ` Arnd Bergmann [this message]
2012-04-19 16:02 ` Jean Pihet
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 ` [PATCH 4/9] ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of voltage domains jean.pihet
2012-03-19 16:12 ` [PATCH 5/9] ARM: OMAP3: hwmod: rename the smartreflex entries jean.pihet
2012-04-18 17:33 ` Kevin Hilman
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 ` [PATCH 7/9] ARM: OMAP2+: SmartReflex: Use per-OPP data structure jean.pihet
2012-04-18 18:21 ` Kevin Hilman
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 ` [PATCH 9/9] ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/ jean.pihet
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-18 8:04 ` Jean Pihet
2012-04-19 0:08 ` Greg KH
2012-04-18 18:29 ` Kevin Hilman
2012-04-18 18:30 ` Kevin Hilman
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=201204191354.38874.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=b-cousson@ti.com \
--cc=gregkh@linuxfoundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox