From: Kevin Hilman <khilman@ti.com>
To: "Menon, Nishanth" <nm@ti.com>
Cc: Maximilian Schwerin <mvs@tigris.de>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Steve Sakoman <steve@sakoman.com>
Subject: Re: [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP
Date: Wed, 14 Mar 2012 15:06:37 -0700 [thread overview]
Message-ID: <8762e6et1u.fsf@ti.com> (raw)
In-Reply-To: <CAOMWX4eYQvwHfpci1AgLO8kk1yxzB-zruMQQvLXeLnxbfUHFgw@mail.gmail.com> (Nishanth Menon's message of "Wed, 14 Mar 2012 16:35:17 -0500")
"Menon, Nishanth" <nm@ti.com> writes:
> On Wed, Mar 14, 2012 at 16:15, Kevin Hilman <khilman@ti.com> wrote:
>> Maximilian Schwerin <mvs@tigris.de> writes:
>>
>>> From: Steve Sakoman <steve@sakoman.com>
>>>
>>> Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
>>> subsystem, as this would make omap_init_opp_table fail.
>>>
>>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>>> Signed-off-by: Maximilian Schwerin <mvs@tigris.de>
>>
>> Minor: patch subjects for arch/arm/* core code need to have the ARM:
>> prefix also.
>>
>> Also, please run scripts/checkpatch.pl on your patch and fix the
>> warnings.
>>
>>> ---
>>> arch/arm/mach-omap2/opp.c | 4 ++++
>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
>>> index 9262a6b..414f2ec 100644
>>> --- a/arch/arm/mach-omap2/opp.c
>>> +++ b/arch/arm/mach-omap2/opp.c
>>> @@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
>>> __func__, i);
>>> return -EINVAL;
>>> }
>>> +
>>> + if ((strcmp(opp_def->hwmod_name,"iva") == 0) && !omap3_has_iva())
>>> + continue;
>>> +
>>> oh = omap_hwmod_lookup(opp_def->hwmod_name);
>>> if (!oh || !oh->od) {
>>> pr_warn("%s: no hwmod or odev for %s, [%d] "
>>
>> Wouldn't the one-liner below do the same thing?
>>
>> Actually, your patch makes it less noisy at boot time, avoiding the
>> pr_warn(), so is probably better.
>
> The only issue i have with current patch is that it focusses to solve
> a specific device IVA.
> we could have similar variances if we had SGX/AESS device etc
> registered in the common
> table. a generic solution might be preferable - could we reduce the
> severity of pr_warn to pr_debug and do a continue instead?
I agree, that would be a better generic solution.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP
Date: Wed, 14 Mar 2012 15:06:37 -0700 [thread overview]
Message-ID: <8762e6et1u.fsf@ti.com> (raw)
In-Reply-To: <CAOMWX4eYQvwHfpci1AgLO8kk1yxzB-zruMQQvLXeLnxbfUHFgw@mail.gmail.com> (Nishanth Menon's message of "Wed, 14 Mar 2012 16:35:17 -0500")
"Menon, Nishanth" <nm@ti.com> writes:
> On Wed, Mar 14, 2012 at 16:15, Kevin Hilman <khilman@ti.com> wrote:
>> Maximilian Schwerin <mvs@tigris.de> writes:
>>
>>> From: Steve Sakoman <steve@sakoman.com>
>>>
>>> Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
>>> subsystem, as this would make omap_init_opp_table fail.
>>>
>>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>>> Signed-off-by: Maximilian Schwerin <mvs@tigris.de>
>>
>> Minor: patch subjects for arch/arm/* core code need to have the ARM:
>> prefix also.
>>
>> Also, please run scripts/checkpatch.pl on your patch and fix the
>> warnings.
>>
>>> ---
>>> ?arch/arm/mach-omap2/opp.c | ? ?4 ++++
>>> ?1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
>>> index 9262a6b..414f2ec 100644
>>> --- a/arch/arm/mach-omap2/opp.c
>>> +++ b/arch/arm/mach-omap2/opp.c
>>> @@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, i);
>>> ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
>>> ? ? ? ? ? ? ? }
>>> +
>>> + ? ? ? ? ? ? if ((strcmp(opp_def->hwmod_name,"iva") == 0) && !omap3_has_iva())
>>> + ? ? ? ? ? ? ? ? ? ? continue;
>>> +
>>> ? ? ? ? ? ? ? oh = omap_hwmod_lookup(opp_def->hwmod_name);
>>> ? ? ? ? ? ? ? if (!oh || !oh->od) {
>>> ? ? ? ? ? ? ? ? ? ? ? pr_warn("%s: no hwmod or odev for %s, [%d] "
>>
>> Wouldn't the one-liner below do the same thing?
>>
>> Actually, your patch makes it less noisy at boot time, avoiding the
>> pr_warn(), so is probably better.
>
> The only issue i have with current patch is that it focusses to solve
> a specific device IVA.
> we could have similar variances if we had SGX/AESS device etc
> registered in the common
> table. a generic solution might be preferable - could we reduce the
> severity of pr_warn to pr_debug and do a continue instead?
I agree, that would be a better generic solution.
Kevin
next prev parent reply other threads:[~2012-03-14 22:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-14 17:38 [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP Maximilian Schwerin
2012-03-14 17:38 ` Maximilian Schwerin
2012-03-14 21:15 ` Kevin Hilman
2012-03-14 21:15 ` Kevin Hilman
2012-03-14 21:35 ` Menon, Nishanth
2012-03-14 21:35 ` Menon, Nishanth
2012-03-14 22:06 ` Kevin Hilman [this message]
2012-03-14 22:06 ` Kevin Hilman
2012-03-16 9:26 ` AW: " Maximilian Schwerin
2012-03-16 9:26 ` Maximilian Schwerin
2012-03-16 14:20 ` Nishanth Menon
2012-03-16 14:20 ` Nishanth Menon
2012-03-16 15:47 ` AW: " Maximilian Schwerin
2012-03-16 15:47 ` Maximilian Schwerin
2012-03-16 15:57 ` Menon, Nishanth
2012-03-16 15:57 ` Menon, Nishanth
2012-03-16 16:04 ` Steve Sakoman
2012-03-16 16:04 ` Steve Sakoman
2012-03-19 21:27 ` Kevin Hilman
2012-03-19 21:27 ` Kevin Hilman
2012-03-19 21:29 ` Menon, Nishanth
2012-03-19 21:29 ` Menon, Nishanth
2012-03-20 0:15 ` Kevin Hilman
2012-03-20 0:15 ` Kevin Hilman
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=8762e6et1u.fsf@ti.com \
--to=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=mvs@tigris.de \
--cc=nm@ti.com \
--cc=steve@sakoman.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.