From: Alex Courbot <acourbot@nvidia.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>,
Stephen Warren <swarren@nvidia.com>,
Simon Glass <sjg@chromium.org>,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Anton Vorontsov <cbou@mail.ru>,
David Woodhouse <dwmw2@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
Leela Krishna Amudala <leelakrishna.a@gmail.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
Date: Fri, 24 Aug 2012 18:24:54 +0900 [thread overview]
Message-ID: <6044581.2jEzZBWCu1@percival> (raw)
In-Reply-To: <1345542860.4085.40.camel@deskari>
On Tuesday 21 August 2012 17:54:20 Tomi Valkeinen wrote:
> > However this also means we'll essentially just be moving the board code.
>
>
> What do you mean "just"? Wasn't the point of the whole "arm board file
> mess" to get rid of the code from the board files? If the code in the
> board file is device specific code, not board specific, then the driver
> of the device is a logical place to place it.
I think Tomi has a point here - these sequences were not belonging to the
board code in the first place. They are definitely tied to the device, hence
should have been handled by the driver all along, with the board code
assigning the correct resources to the device (like the vast majority of
device drivers do).
> And as I said, I don't have any problems with some kind of generic power
> sequences. So the code in the board file could be moved and converted to
> use the power sequences, if that is better than just plain c code.
My concern now is, provided that all drivers to their job and handle how their
devices are switched on and off, when (if at all) are encoded power sequences
better than their equivalent C code? There is the matching database size issue
that you mentionned, is it a sufficient concern to justify a new kernel feature?
On the other hand some devices like panels are typically not used in many
different appliances, so maybe it is not worth to separate them from their
board definition. As Mark mentionned, having .dtsi files for the DT (and their
equivalent .h for kernels that use platform data) might be a good middle
ground.
But the line is really tight between what is code and what is data here.
Alex.
next prev parent reply other threads:[~2012-08-24 9:23 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 6:08 [PATCH v4 0/3] Runtime Interpreted Power Sequences Alexandre Courbot
2012-08-16 6:08 ` [PATCH v4 1/3] " Alexandre Courbot
2012-08-16 7:42 ` Thierry Reding
2012-08-16 9:19 ` Alex Courbot
2012-08-16 9:52 ` Thierry Reding
2012-08-16 10:33 ` Alex Courbot
2012-08-16 10:52 ` Thierry Reding
2012-08-16 14:14 ` Mark Brown
2012-08-16 18:38 ` Stephen Warren
2012-08-16 18:47 ` Mark Brown
2012-08-16 18:57 ` Stephen Warren
2012-08-16 19:35 ` Stephen Warren
2012-08-16 19:49 ` Thierry Reding
2012-08-16 21:10 ` Mitch Bradley
2012-08-17 23:04 ` Mark Brown
2012-08-17 8:52 ` Alex Courbot
2012-08-21 7:44 ` Tomi Valkeinen
2012-08-21 8:22 ` Alex Courbot
2012-08-21 8:33 ` Thierry Reding
2012-08-21 8:53 ` Alex Courbot
2012-08-21 8:57 ` Tomi Valkeinen
2012-08-21 9:13 ` Thierry Reding
2012-08-21 9:54 ` Tomi Valkeinen
2012-08-21 16:57 ` Mark Brown
2012-08-22 5:42 ` Thierry Reding
2012-08-24 9:24 ` Alex Courbot [this message]
2012-08-24 10:34 ` Tomi Valkeinen
2012-08-16 6:08 ` [PATCH v4 2/3] pwm_backlight: use power sequences Alexandre Courbot
2012-08-16 18:42 ` Stephen Warren
2012-08-16 6:08 ` [PATCH v4 3/3] tegra: add pwm backlight device tree nodes Alexandre Courbot
2012-08-16 18:45 ` Stephen Warren
2012-08-16 21:47 ` [PATCH v4 0/3] Runtime Interpreted Power Sequences Rafael J. Wysocki
2012-08-17 8:54 ` Alex Courbot
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=6044581.2jEzZBWCu1@percival \
--to=acourbot@nvidia.com \
--cc=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=cbou@mail.ru \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dwmw2@infradead.org \
--cc=grant.likely@secretlab.ca \
--cc=leelakrishna.a@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
--cc=thierry.reding@avionic-design.de \
--cc=tomi.valkeinen@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;
as well as URLs for NNTP newsgroup(s).