From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Nishanth Menon <nm@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>, Tony <tony@atomide.com>
Subject: Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Date: Tue, 16 Nov 2010 13:42:20 +0100 [thread overview]
Message-ID: <20101116134220.1bb818c0@surf> (raw)
In-Reply-To: <4CE2710A.3010804@ti.com>
Hello,
On Tue, 16 Nov 2010 05:54:50 -0600
Nishanth Menon <nm@ti.com> wrote:
> > Do we really need this ? I personaly don't really like this quite of
> > "Hey, I'm already initialized, let's do nothing silently then". Unless
> > there are strong reasons for which this function could be called twice,
> > I'd rather not have this, or turn this into a BUG_ON(omap_table_init ==
> > 1).
> Yes, it is needed. The intent here is different. See the documentation
> that I put along with this patch - At times, board files may need to do
> customization to opps - like enable 1GHz on that platform alone -> it
> can do it *only if* the defaults are registered, following which it can
> call opp_enable. when device_initcall follows this at a later point, it
> is still valid.
Ah, right, I didn't catch that omapX_init_opp() could be called first
from the board init function, and then later on as a device_initcall()
callback.
But, sorry, I find this even uglier than I thought it was :) What about
adding the obligation to boards file to call the omapX_init_opp()
function and then do their customization (if needed), then no call to
omapX_init_opp() would be needed as a device_initcall() callback. Or,
add a mechanism that allows the board file to register its
customizations, that are later taken into account by the
omapX_init_opp() function.
Maybe it's just a matter of personal taste, but I really don't like
this kind of "let's call this function once, do some stuff, then call
it again, since it'll know that it shouldn't do anything".
> btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok
> fine, system can still survive without cpufreq, no need to stop system
> operations because of that.
I don't see why replacing:
+ if (omap_table_init)
+ return 0;
+ omap_table_init = 1;
by
BUG_ON(omap_table_init == 1);
omap_table_init = 1;
would prevent you from having no OPP table (the case where a NULL OPP
table is passed is tested *before* in omapX_init_opp()).
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2010-11-16 12:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <[PATCH 0/3 v2] omap: opp: Add opp data>
2010-11-15 19:27 ` [PATCH v3 0/3] OMAP: Add opp data Nishanth Menon
2010-11-15 19:27 ` [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init Nishanth Menon
2010-11-15 22:51 ` Thomas Petazzoni
2010-11-16 0:53 ` Nishanth Menon
2010-11-16 20:35 ` Tony Lindgren
2010-11-16 21:11 ` Nishanth Menon
2010-11-16 11:21 ` Thomas Petazzoni
2010-11-16 11:54 ` Nishanth Menon
2010-11-16 12:42 ` Thomas Petazzoni [this message]
2010-11-16 13:10 ` Nishanth Menon
2010-11-16 13:20 ` Thomas Petazzoni
2010-11-16 14:02 ` Nishanth Menon
2010-11-16 15:23 ` Nishanth Menon
2010-11-16 15:50 ` Thomas Petazzoni
2010-11-16 15:56 ` Nishanth Menon
2010-11-16 16:16 ` Kevin Hilman
2010-11-16 20:37 ` Tony Lindgren
2010-11-17 8:19 ` Thomas Petazzoni
2010-11-15 19:27 ` [PATCH v3 2/3] omap4: opp: add OPP table data Nishanth Menon
2010-11-15 19:27 ` [PATCH v3 3/3] OMAP3: remove OPP interfaces from OMAP PM layer Nishanth Menon
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=20101116134220.1bb818c0@surf \
--to=thomas.petazzoni@free-electrons.com \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=tony@atomide.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