From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
Date: Fri, 30 Sep 2011 10:09:03 -0700 [thread overview]
Message-ID: <87ehyyj6ts.fsf@ti.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930257840691@dbde02.ent.ti.com> (Sanjeev Premi's message of "Fri, 30 Sep 2011 17:39:27 +0530")
"Premi, Sanjeev" <premi@ti•com> writes:
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org
>> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Hilman, Kevin
>> Sent: Tuesday, September 27, 2011 12:16 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap at vger.kernel.org; paul at pwsan.com;
>> tony at atomide.com; linux-arm-kernel at lists.infradead.org;
>> Mohammed, Afzal
>> Subject: Re: [PATCH-V3 2/4] arm:omap:am33xx: Update common
>> OMAP machine specific sources
>>
>> <hvaibhav@ti•com> writes:
>>
>> > From: Afzal Mohammed <afzal@ti•com>
>> >
>> > This patch updates the common machine specific source files for
>> > support for AM33XX/AM335x with cpu type, macros for
>> identification of
>> > AM33XX/AM335X device.
>> >
>> > Signed-off-by: Afzal Mohammed <afzal@ti•com>
>> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti•com>
>>
>> [...]
>>
>> > @@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void)
>> > * Lock DPLL5 -- here only until other device init code can
>> > * handle this
>> > */
>> > - if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
>> > + if (!cpu_is_ti816x() && !cpu_is_am33xx() &&
>> > + (omap_rev() >= OMAP3430_REV_ES2_0))
>> > omap3_clk_lock_dpll5();
>>
>> This is getting ugly.
>>
>> Instead of continuing to expand this if-list, I think it's time for a
>> new feature-flag for whether or not an SoC has DPLL5 instead.
>
> I agree that the code is really getting ugly here. But, isn't
> feature-flag going to be over-used with this and similar features?
>
> Just thinking ahead, for these possible cases:
> 1) An soc adds DPLL6.
> 2) An soc uses DPLL5, but mechanism to lock is different.
You're right.
> Wouldn't it be better to have a scheme like this:
> 1) Define a simple structure for DPLLs.
> 2) Initialize the unused DPLLs to be null/ -1 early
> in arch/soc specific init.
> 3) The DPLL functions check for corresponding flag on
> entry.
Actually, looking at this closer, I think the infrastructure is already
there to handle this cleanly.
Basically, dpll5 should not even be registered for SoCs where it doesn't
exist. Then, any attempts to use DPLL5 would know it doesn't exist
because the call to clk_get() in omap3_clk_lock_dpll5() would fail.
I think the clock3xxx_data.c needs a bit more cleanup so that only
clocks that exist for a given SoC are registered.
Paul already did a similar cleanup for the powerdomain data files by
creating separate lists for common ones and unique ones. Looks like we
need the same for the clock data.
Patches welcome.
Kevin
next prev parent reply other threads:[~2011-09-30 17:09 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <hvaibhav@ti.com>
2011-08-29 12:46 ` [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM hvaibhav at ti.com
2011-09-15 0:32 ` Tony Lindgren
2011-09-15 7:13 ` Hiremath, Vaibhav
2011-09-20 14:32 ` [PATCH-V3 1/4] arm:omap:am33xx: Update common omap platform files hvaibhav at ti.com
2011-10-06 23:03 ` Tony Lindgren
2011-09-20 14:32 ` [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources hvaibhav at ti.com
2011-09-26 18:45 ` Kevin Hilman
2011-09-30 12:09 ` Premi, Sanjeev
2011-09-30 17:09 ` Kevin Hilman [this message]
2011-10-06 23:03 ` Tony Lindgren
2011-11-03 13:48 ` Hiremath, Vaibhav
2011-11-05 9:41 ` Hiremath, Vaibhav
2011-11-05 10:29 ` Hiremath, Vaibhav
2011-09-20 14:32 ` [PATCH-V3 3/4] arm:omap:am33xx: Create board support and enable build for AM335XEVM hvaibhav at ti.com
2011-10-06 23:07 ` Tony Lindgren
2011-09-20 14:32 ` [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support hvaibhav at ti.com
2011-10-06 23:09 ` Tony Lindgren
2011-11-07 15:17 ` Hiremath, Vaibhav
2011-11-07 18:16 ` Tony Lindgren
2011-12-02 6:43 ` [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM hvaibhav at ti.com
2011-12-07 0:24 ` Kevin Hilman
2011-12-07 21:10 ` Tony Lindgren
2011-12-08 13:45 ` Hiremath, Vaibhav
2011-12-08 17:18 ` Tony Lindgren
2012-02-01 6:53 ` Hiremath, Vaibhav
2012-01-18 8:47 ` Hiremath, Vaibhav
2011-12-02 6:43 ` [PATCH-V5 1/3] arm:omap:am33xx: Update common OMAP machine specific sources hvaibhav at ti.com
2011-12-07 21:09 ` Tony Lindgren
2011-12-02 6:43 ` [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support hvaibhav at ti.com
2012-05-02 9:23 ` Paul Walmsley
2012-05-02 9:34 ` Hiremath, Vaibhav
2012-05-03 15:57 ` Tony Lindgren
2012-05-03 16:41 ` Hiremath, Vaibhav
2012-05-03 19:37 ` Tony Lindgren
2012-05-04 6:14 ` Hiremath, Vaibhav
2012-05-03 21:17 ` Kevin Hilman
2012-05-04 6:00 ` Hiremath, Vaibhav
2012-05-04 20:05 ` Tony Lindgren
2012-05-07 14:38 ` Hiremath, Vaibhav
2012-05-07 17:32 ` Tony Lindgren
2012-05-07 18:55 ` Hiremath, Vaibhav
2012-05-08 19:06 ` Tony Lindgren
2012-05-08 19:57 ` Hiremath, Vaibhav
2012-05-04 6:28 ` Hiremath, Vaibhav
2012-05-04 20:00 ` Tony Lindgren
2013-03-04 11:35 ` [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control hvaibhav at ti.com
2013-03-14 11:29 ` Hiremath, Vaibhav
2013-04-08 17:30 ` Tony Lindgren
2013-04-09 8:11 ` Hiremath, Vaibhav
2013-03-04 11:35 ` [RFC PATCH 1/3] ARM: AM33XX: clock: Add debugSS clock nodes to clock tree hvaibhav at ti.com
2013-05-29 19:07 ` Paul Walmsley
2013-03-04 11:35 ` [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control hvaibhav at ti.com
2013-04-08 17:29 ` Tony Lindgren
2013-04-09 8:07 ` Hiremath, Vaibhav
2013-04-09 16:34 ` Tony Lindgren
2013-04-10 5:11 ` Hiremath, Vaibhav
2013-04-10 17:07 ` 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=87ehyyj6ts.fsf@ti.com \
--to=khilman@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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