Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc

From: santosh.shilimkar@xxxxxxxxxx
Date: Mon Jan 05 2015 - 17:31:53 EST


On 1/5/15 2:19 PM, Paul Walmsley wrote:
+ 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.

IIRC, Yes the intention was to skip the ioremap o.w there were some crashes seen. I am fine if that check is actually moved closer
to iormap as it should have been first place.

Regards,
Santosh
seen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/