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
next prev parent 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