public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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

  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