All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: "Hiremath, Vaibhav" <hvaibhav@ti.com>, Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>, Ilya Yanok <yanok@emcraft.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"wd@denx.de" <wd@denx.de>, "dzu@denx.de" <dzu@denx.de>,
	"sasha_d@emcraft.com" <sasha_d@emcraft.com>
Subject: Re: [PATCH] AM35xx: disable checking for reserved feature bits
Date: Wed, 04 Jan 2012 17:18:29 -0800	[thread overview]
Message-ID: <87lipn9cbe.fsf@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A8062B59@DBDE01.ent.ti.com> (Vaibhav Hiremath's message of "Tue, 20 Dec 2011 10:55:08 +0000")

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

>> -----Original Message-----
>> From: Hilman, Kevin
>> Sent: Saturday, December 10, 2011 6:51 AM
>> To: Tony Lindgren
>> Cc: Ilya Yanok; linux-omap@vger.kernel.org; wd@denx.de; dzu@denx.de;
>> sasha_d@emcraft.com; Hiremath, Vaibhav
>> Subject: Re: [PATCH] AM35xx: disable checking for reserved feature bits
>> 
>> Tony Lindgren <tony@atomide.com> writes:
>> 
>> [...]
>> 
>> >> This "feature" selection mechanism is clearly not scaling to newer SoCs.
>> >> While this patch works around the problem, IMO, we need a more scalable
>> >> solution.
>> >
>> > Agreed.
>> >
> <snip>
>> >
>> > This should be coordinated with the splitting of feature detection
>> > as posted by Vaibhave in thread "[RFC PATCH] arm:omap: cleanup & split
>> > omap2/3/4_check_revision function" thread.
>> 
>> Vaibhav,
>> 
>> Feel free to take my proposed patch and develop it further and include
>> it in your rework of the SoC/feature detection.
>> 
> Kevin,
>
> I spend some time on this, and I think it is not possible to use HWMOD 
> Entries for feature check. Reason being,
>
> 	- The whole revision story is built upon howkeye and silicon rev.
>         And both remains same for different devices in same family, 
>         For example,
>           omap3430, omap3503 and omap3515 (for that matter all AM37x) all
>           will have same howkeye and silicon revision no.

I see now.

>         Also, in the kernel we have something like.
>
> # define cpu_is_omap3515()              (cpu_is_omap3430() &&           \
>                                                  (!omap3_has_iva()) &&   \
>                                                  (omap3_has_sgx()))
> # define cpu_is_omap3525()              (cpu_is_omap3430() &&           \
>                                                  (!omap3_has_sgx()) &&   \
>                                                  (omap3_has_iva()))
>
>         Which means, you can not do IP detection before check_feature
>         function.
> 	- The current omap_hwmod_xxxx_data.c uses silicon version alone
>         and only differentiate between silicon versions. We do not 
>         differentiate between different family of devices while registering
>         hwmod data.
>
> So the conclusion is, we have to stick to check_feature function.

I don't fully agree.

I still think we need to rework how we're using cpu_is_* checks.

Specifially, we need to start separating the checking for SoC family
(based on die ID) and specific IP blocks.

I spent some time on this today and just posted a series for RFC to
hopefully move in that direction.   Let me know what you think.

Kevin



      reply	other threads:[~2012-01-05  1:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-08 23:51 [PATCH] AM35xx: disable checking for reserved feature bits Ilya Yanok
2011-11-09  0:57 ` Kevin Hilman
2011-12-07 23:58   ` Tony Lindgren
2011-12-10  1:21     ` Kevin Hilman
2011-12-16 11:31       ` Hiremath, Vaibhav
2011-12-20 10:55       ` Hiremath, Vaibhav
2012-01-05  1:18         ` Kevin Hilman [this message]

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=87lipn9cbe.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=dzu@denx.de \
    --cc=hvaibhav@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=sasha_d@emcraft.com \
    --cc=tony@atomide.com \
    --cc=wd@denx.de \
    --cc=yanok@emcraft.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.