linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


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