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 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.