All of lore.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 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.