Re: [PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init

["Cousson, Benoit" <b-cousson@ti.com>]

On 6/11/2012 2:46 AM, Paul Walmsley wrote:
> Resolve this kernel boot message:
>
> omap_hwmod: mcpdm: cannot be enabled for reset (3)
>
> It appears that the McPDM on OMAP4 can only receive its functional
> clock from an off-chip source.  This source is not guaranteed to be
> present on the board, and when present, it is controlled by I2C.  This
> would introduce a board dependency to the early hwmod code which it
> was not designed to handle.  Also, neither the driver for this
> off-chip clock provider nor the I2C code is available early in boot
> when the hwmod code is attempting to enable and reset IP blocks.  This
> effectively makes it impossible to enable and reset this device during
> hwmod init.
>
> At its core, this patch is a workaround for an OMAP hardware problem.
> It should be possible to configure the OMAP to provide any IP block's
> functional clock from an on-chip source.  (This is true for almost
> every IP block on the chip.  As far as I know, McPDM is the only
> exception.)  If the kernel cannot reset and configure IP blocks, it
> cannot guarantee a sane SoC state.  Relying on an optional off-chip
> clock also creates a board dependency which is beyond the scope of the
> early hwmod code.

And I guess, that's a good reason as well to let the driver managing the 
reset during the probe for such IPs.

> This patch works around the issue by marking the McPDM hwmod record
> with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
> code from touching the device early during boot.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Benoît Cousson <b-cousson@ti.com>
> ---
>   arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 3613054..86fc513 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -2091,6 +2091,18 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
>   	.name		= "mcpdm",
>   	.class		= &omap44xx_mcpdm_hwmod_class,
>   	.clkdm_name	= "abe_clkdm",
> +	/*
> +	 * It's suspected that the McPDM requires an off-chip main
> +	 * functional clock, controlled via I2C.

Nit: Is it not suspected, it is a fact. The clock tree clearly indicate 
that the mcpdm fclk is generated from the pad_clks.
The IP is a custom link for the Audio IC control / data. using the Audio 
IC as a source clock is standard. Since that IP is done only for that 
purpose, there is no optional clock path from the PRCM like it is the 
case for the McASP / McBSP.

>  This IP block is
> +	 * currently reset very early during boot, before I2C is
> +	 * available, so it doesn't seem that we have any choice in
> +	 * the kernel other than to avoid resetting it.  XXX This is
> +	 * really a hardware issue workaround: every IP block should
> +	 * be able to source its main functional clock from either
> +	 * on-chip or off-chip sources.  McPDM seems to be the only
> +	 * current exception.

I do not think this is the right place to put some complaint about the 
HW :-).
I guess we should just describe the facts.

> +	 */
> +	.flags		= HWMOD_EXT_OPT_MAIN_CLK,

Could you please update the hints for this IP in the autogen scripts?
I added a comment attribute to add a custom comment on top of the flags 
entry.
The latest branch is "omap5430_for_3.6".

Thanks,
Benoit


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html