public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Premi, Sanjeev" <premi@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 2/3v4] Runtime check for OMAP35x
Date: Tue, 20 Jan 2009 12:53:02 -0800	[thread overview]
Message-ID: <871vux66oh.fsf@deeprootsystems.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301C69A054A@dbde02.ent.ti.com> (Sanjeev Premi's message of "Tue\, 20 Jan 2009 22\:11\:40 +0530")

"Premi, Sanjeev" <premi@ti.com> writes:

>> > <snip>--<snip>
>> >
>> >> > +#ifdef CONFIG_ARCH_OMAP35XX
>> >> > +static struct omap_globals omap35xx_globals = {
>> >> > +	.class	= OMAP35XX_CLASS,
>> >> > +	.tap	= OMAP2_IO_ADDRESS(0x4830A000),
>> >> > +	.sdrc	= OMAP2_IO_ADDRESS(OMAP343X_SDRC_BASE),
>> >> > +	.sms	= OMAP2_IO_ADDRESS(OMAP343X_SMS_BASE),
>> >> > +	.ctrl	= OMAP2_IO_ADDRESS(OMAP343X_CTRL_BASE),
>> >> > +	.prm	= OMAP2_IO_ADDRESS(OMAP3430_PRM_BASE),
>> >> > +	.cm	= OMAP2_IO_ADDRESS(OMAP3430_CM_BASE),
>> >> > +};
>> >> 
>> >> This is exactly the same as omap34xx_globals.  Why is this needed?
>> >
>> 
>> > [sp] I have tried to add minimal support for OMAP35x. Since OMAP34x 
>> > and OMAP35x seem to be compatible today, this structure 
>> seems same. As 
>> > more code for specific OMAP35x variants comes in, I expect this to 
>> > change.
>> >
>> > The key difference here (as against OMAP34x) is use of 
>> OMAP35XX_CLASS; 
>> > which helps in identifying the different OMAP variants. We 
>> could have 
>> > 're-used' OMAP35XX_CLASS, it I wouldn't be right as this 
>> definition is 
>> > used to print the CPU name and Si version in id.c.
>> >
>> > With this patch, boot log with show (for example) "OMAP3530 ES2.1"
>> > on the OMAP3530 EVM - which can be considered same as 
>> OMAP3430 ES2.1; 
>> > but with 3503, 3515 and 3525 the print would read 3403, 3415,
>> > 3425 resp; this definitley would not be right.
>> 
>> I was not asking about the patch as a whole, I was commenting 
>> only on the addition of the omap35xx_globals variable.  You 
>> added a new struct which is exactly the same as the 35xx 
>> struct instead of just re-using the old one with a new name 
>> as I suggested.
>> 
>> Kevin
>
> [sp] This would mean adding another #ifdef to get the right
> _CLASS. From earlier discussion, I understood that we wanted to
> remove #ifdefs so that same image can work for OMAP35x and OMAP34x.

Indeed, I hadn't noticed the new class definition.  This looks ok to
me.

Kevin




  reply	other threads:[~2009-01-20 20:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-16 15:46 [PATCH 2/3v4] Runtime check for OMAP35x Sanjeev Premi
2009-01-19 23:37 ` Kevin Hilman
2009-01-20 12:25   ` Premi, Sanjeev
2009-01-20 15:37     ` Kevin Hilman
2009-01-20 16:41       ` Premi, Sanjeev
2009-01-20 20:53         ` Kevin Hilman [this message]
2009-01-27  1:08         ` Tony Lindgren
2009-01-30 18:35           ` Tony Lindgren

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=871vux66oh.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=premi@ti.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