From: Kevin Hilman <khilman@ti.com>
To: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: linux-omap@vger.kernel.org, paul@pwsan.com, b-cousson@ti.com,
tony@atomide.com, rnayak@ti.com, Afzal Mohammed <afzal@ti.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support
Date: Thu, 26 Apr 2012 17:49:02 -0700 [thread overview]
Message-ID: <87bome579d.fsf@ti.com> (raw)
In-Reply-To: <1333123435-27186-5-git-send-email-hvaibhav@ti.com> (Vaibhav Hiremath's message of "Fri, 30 Mar 2012 21:33:55 +0530")
Vaibhav Hiremath <hvaibhav@ti.com> writes:
> As far as PRM/CM/PRCM modules are concerned, AM33XX device is
> different than OMAP3 and OMAP4 architectures; so we need to
> handle it separately.
> This patch adds support for, Powerdomain, Powerdomain data,
> PRM api's required for AM33XX device.
>
> And also, hooks up AM33XX powerdomain to existing OMAP framework.
[...]
> @@ -1288,7 +1289,15 @@ static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
> if (IS_ERR_VALUE(ret))
> return ret;
>
> - if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + /*
> + * cpu_is_omap34xx() is true for am33xx device as well, so
> + * fist check for cpu_is_am33xx().
> + */
> + if (cpu_is_am33xx())
> + return am33xx_prm_assert_hardreset(ohri.rst_shift,
> + oh->clkdm->pwrdm.ptr->prcm_offs,
> + oh->prcm.omap4.rstctrl_offs);
This still troubles me. I *really* don't like that we have a dependence
on cpu_is* call ordering. This is very fragile and error prone.
I also don't like all the cpu_is* checking currently in omap_hwmod.c
(which is here before you added this) and have an idea on how to clean
it up, I should have a patch by tomorrow for this. That should help
adding am33xx support here without needing all the cpu_is* checking.
That being said, I just did a simple experiment[1] to see why
cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based
on my quick experiment, it does not appear to be needed. I think our
lives will be much simpler if cpu_is_omap34xx() is not true for the
AM335x family.
Can you have a look at my test branch[1] and see what you think? I
changed the omap_revision for AM335x so that cpu_is_omap34xx() is no
longer true on this platform. Then, I only needed to fixup the SRAM
init, and it boots just fine on my BeagleBone.
I really think we need to go this route, because having
cpu_is_omap34xx() true on AM335x is causing more headaches than it is
solving problems. This will require you to rework a little bit these
clock/power/voltage domain patches, but I belive it will greatly
simplify the maintainability of the end result.
Kevin
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tmp/am335x-cpu-is-hacking
next prev parent reply other threads:[~2012-04-27 0:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 16:03 [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device Vaibhav Hiremath
2012-03-30 16:03 ` [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data Vaibhav Hiremath
2012-04-28 0:39 ` Paul Walmsley
2012-04-30 20:41 ` Kevin Hilman
2012-03-30 16:03 ` [PATCH-V4 2/4] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm Vaibhav Hiremath
2012-05-29 6:31 ` Hiremath, Vaibhav
2012-03-30 16:03 ` [PATCH-V4 3/4] ARM: OMAP2+: powerdomain: Add offset & mask fields to struct powerdomain Vaibhav Hiremath
2012-03-30 16:03 ` [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support Vaibhav Hiremath
2012-04-27 0:49 ` Kevin Hilman [this message]
2012-04-27 6:37 ` Hiremath, Vaibhav
2012-05-04 18:43 ` Tony Lindgren
2012-04-27 20:44 ` Kevin Hilman
2012-03-30 16:22 ` [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device Hiremath, Vaibhav
2012-04-12 8:26 ` Paul Walmsley
2012-04-13 10:36 ` Hiremath, Vaibhav
2012-04-13 10:43 ` Paul Walmsley
2012-04-16 7:18 ` Hiremath, Vaibhav
2012-04-18 23:21 ` Tony Lindgren
2012-04-18 23:18 ` Tony Lindgren
2012-04-23 18:28 ` Hiremath, Vaibhav
2012-04-26 18:43 ` Tony Lindgren
2012-04-26 18:49 ` Hiremath, Vaibhav
2012-04-26 19:05 ` Tony Lindgren
2012-04-27 8:53 ` Hiremath, Vaibhav
2012-05-02 9:09 ` Paul Walmsley
2012-05-07 10:32 ` Cousson, Benoit
2012-05-07 10:44 ` Shilimkar, Santosh
2012-05-07 13:59 ` Hiremath, Vaibhav
2012-05-02 9:30 ` Paul Walmsley
2012-05-02 9:37 ` Hiremath, Vaibhav
2012-05-03 14:44 ` Hiremath, Vaibhav
2012-04-25 13:44 ` Hiremath, Vaibhav
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=87bome579d.fsf@ti.com \
--to=khilman@ti.com \
--cc=afzal@ti.com \
--cc=b-cousson@ti.com \
--cc=hvaibhav@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=rnayak@ti.com \
--cc=tony@atomide.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;
as well as URLs for NNTP newsgroup(s).