From: Paul Walmsley <paul@pwsan.com> To: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: "Peter Ujfalusi" <peter.ujfalusi@ti.com>, "Benoît Cousson" <b-cousson@ti.com> Subject: [PATCH 4/4] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init Date: Wed, 31 Oct 2012 04:43:16 -0600 [thread overview] Message-ID: <20121031104314.6557.36640.stgit@dusk.lan> (raw) In-Reply-To: <20121031103607.6557.64591.stgit@dusk.lan> Resolve this kernel boot message: omap_hwmod: mcpdm: cannot be enabled for reset (3) 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. 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> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 652d028..7bddfa5 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -2125,6 +2125,14 @@ 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. 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. + */ + .flags = HWMOD_EXT_OPT_MAIN_CLK, .mpu_irqs = omap44xx_mcpdm_irqs, .sdma_reqs = omap44xx_mcpdm_sdma_reqs, .main_clk = "mcpdm_fck", -- 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
WARNING: multiple messages have this Message-ID (diff)
From: paul@pwsan.com (Paul Walmsley) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 4/4] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init Date: Wed, 31 Oct 2012 04:43:16 -0600 [thread overview] Message-ID: <20121031104314.6557.36640.stgit@dusk.lan> (raw) In-Reply-To: <20121031103607.6557.64591.stgit@dusk.lan> Resolve this kernel boot message: omap_hwmod: mcpdm: cannot be enabled for reset (3) 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. 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> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 652d028..7bddfa5 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -2125,6 +2125,14 @@ 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. 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. + */ + .flags = HWMOD_EXT_OPT_MAIN_CLK, .mpu_irqs = omap44xx_mcpdm_irqs, .sdma_reqs = omap44xx_mcpdm_sdma_reqs, .main_clk = "mcpdm_fck",
next prev parent reply other threads:[~2012-10-31 10:46 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-31 10:43 [PATCH 0/4] ARM: OMAP: more hwmod/PRCM fixes for 3.7-rc Paul Walmsley 2012-10-31 10:43 ` Paul Walmsley 2012-10-31 10:43 ` [PATCH 1/4] ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP Paul Walmsley 2012-10-31 10:43 ` Paul Walmsley 2012-10-31 10:43 ` [PATCH 2/4] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod Paul Walmsley 2012-10-31 10:43 ` Paul Walmsley 2012-11-01 2:46 ` Paul Walmsley 2012-11-01 2:46 ` Paul Walmsley 2012-10-31 10:43 ` [PATCH 3/4] ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init Paul Walmsley 2012-10-31 10:43 ` Paul Walmsley 2012-10-31 10:43 ` Paul Walmsley [this message] 2012-10-31 10:43 ` [PATCH 4/4] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init Paul Walmsley
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=20121031104314.6557.36640.stgit@dusk.lan \ --to=paul@pwsan.com \ --cc=b-cousson@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=peter.ujfalusi@ti.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.