[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1501052206580.28771@utopia.booyaka.com>
Date: Mon, 5 Jan 2015 22:19:20 +0000 (UTC)
From: Paul Walmsley <paul@...an.com>
To: Lokesh Vutla <lokeshvutla@...com>
cc: Roger Quadros <rogerq@...com>, tony@...mide.com, t-kristo@...com,
nm@...com, nsekhar@...com, bcousson@...libre.com,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, s-anna@...com, ssantosh@...nel.org
Subject: Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods
without sysc
+ Santosh
Hi Lokesh
On Mon, 5 Jan 2015, Lokesh Vutla wrote:
> On Saturday 03 January 2015 02:40 AM, Paul Walmsley wrote:
> > On Thu, 18 Dec 2014, Roger Quadros wrote:
> >
> >> On 18/12/14 17:49, Roger Quadros wrote:
> >>> There are quite a few hwmods that don't have sysconfig register and so
> >>> _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
> >>> on those modules after the module is enabled.
> >
> > Hmm. Any IP block that exposes registers that are accessible by the MPU
> > should have an MPU register target port, even if there's no SYSCONFIG
> > register. And if an IP block doesn't have registers that are accessible
> > from the MPU, then there shouldn't be much point to waiting for the module
> > to become ready.
> >
> > Looks like the real problem is the test for oh->class->sysc before the
> > call to _init_mpu_rt_base(). That was introduced by commit 6423d6df1440
> > ("ARM: OMAP2+: hwmod: check for module address space during init"). It's
> > not clear to me why that test was added, since _init_mpu_rt_base() doesn't
> > do anything with oh->class->sysc or SYSCONFIG registers.
> This was introduced by commit
> 97597b962529 (ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc)
Yes, you're right. I misread commit 6423d6df1440.
> Patch description states that "there are few hwmod which doesn't have sysconfig registers and hence
> no need to ioremap() them in early init code".
The MPU register target port code doesn't only determine whether the
hwmod code should map the IP block's address space. It also determines
whether or not the hwmod code needs to wait for the IP block to become
ready after being enabled, so register accesses by non-hwmod code can
succeed.
> Isn't this correct?
That commit 97597b962529 is bogus. If the goal was to skip the ioremap(),
then the right fix would have been to just skip the ioremap(). The
existing commit also skips the call to _save_mpu_port_index(), which
caused the problem that Roger's patch is trying to fix.
> May be a dumb question: If IP doesn't have sysconfig, is there any case
> that hwmod does access the register address space of that IP? Why do we
> need to enable MPU register target port?
hwmod shouldn't touch the IP block registers if there are no SYSCONFIG,
SYSSTATUS, etc. registers, and there's no IP block-specific reset code.
But other code on the system (like the IP block's device driver) will, and
the system needs to indicate that the IP block is ready before those
accesses occur.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists