Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: OMAP3530 with no TWL4030 power controller
Date: Tue, 07 Feb 2012 14:55:52 -0800	[thread overview]
Message-ID: <874nv2gsnb.fsf@ti.com> (raw)
In-Reply-To: <4F301177.4020008@mlbassoc.com> (Gary Thomas's message of "Mon, 06 Feb 2012 10:44:23 -0700")

Gary Thomas <gary@mlbassoc.com> writes:

> I have an OMAP3530 (DM3730) board which uses a very simple
> power controller (TPS65910A1).  This controller does not
> support many of the power supplies, etc, that are common
> on the TWL4030 and similar devices.
>
> I'm using Linux 3.0.  

Can you try what you want with current linux-omap master?  I think I
have fixed any assumptions about the presence of the TWL PMICs, at least
from the voltage layer init.

> How can I remove the reliance on the
> TWL devices?  Simply disabling PM in my configuration isn't
> enough - that generates a bunch of undefined references.

CONFIG_PM is about lots more stuff than PMICs.  All the SoC-internal
power management (power domains, clocks, CPUidle, etc.) are controlled
by that as well.

> Also, there are many places where power supply stuff is
> accessed, outside of PM, in particular DSS2 which has a
> terrible time.  

Does CONFIG_REGULATOR_DUMMY help here? I believe that is for cases like
this where you don't want the regulator request to fail.

> Here's what I get when I disabled PM and
> REGULATOR support:
>
> arch/arm/mach-omap2/built-in.o: In function `omap_set_pwrdm_state':
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:122: undefined reference to `pwrdm_read_next_pwrst'
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:126: undefined reference to `pwrdm_read_pwrst'
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:127: undefined reference to `pwrdm_read_pwrst'
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:133: undefined reference to `pwrdm_wait_transition'
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:138: undefined reference to `pwrdm_set_next_pwrst'
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:153: undefined reference to `pwrdm_set_lowpwrstchange'
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:159: undefined reference to `pwrdm_wait_transition'
> /local/linux-3.0/arch/arm/mach-omap2/pm.c:160: undefined reference to
> `pwrdm_state_switch'

> arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count':
> /local/linux-3.0/arch/arm/mach-omap2/omap_hwmod.c:2638: undefined reference to `pwrdm_get_context_loss_count'
> arch/arm/mach-omap2/built-in.o: In function `_clkdm_clk_hwmod_disable':
> /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:895: undefined reference to `pwrdm_clkdm_state_switch'
> arch/arm/mach-omap2/built-in.o: In function `clkdm_allow_idle':
> /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:786: undefined reference to `pwrdm_clkdm_state_switch'
> arch/arm/mach-omap2/built-in.o: In function `_clkdm_clk_hwmod_enable':
> /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:869: undefined reference to `pwrdm_wait_transition'
> /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:870: undefined reference to `pwrdm_clkdm_state_switch'
> arch/arm/mach-omap2/built-in.o: In function `_clkdm_register':
> /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:79: undefined reference to `pwrdm_lookup'
> /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:93: undefined reference to `pwrdm_add_clkdm'
> arch/arm/mach-omap2/built-in.o: In function `omap2_clk_disable_unused':
> /local/linux-3.0/arch/arm/mach-omap2/clock.c:442: undefined reference to `pwrdm_clkdm_state_switch'
> arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_infrastructure':
> /local/linux-3.0/arch/arm/mach-omap2/io.c:355: undefined reference to `omap3xxx_voltagedomains_init'
> /local/linux-3.0/arch/arm/mach-omap2/io.c:356: undefined reference to `omap3xxx_powerdomains_init'

Can you be specific about what .config changes (compared to
omap2plus_defconfig) result in these warnings?

I thought we fixed these a while ago too.  Does this happen on newer kernels?

Kevin

      parent reply	other threads:[~2012-02-07 22:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-06 17:44 OMAP3530 with no TWL4030 power controller Gary Thomas
2012-02-06 23:45 ` Tony Lindgren
2012-02-06 23:54   ` Gary Thomas
2012-02-07 10:53     ` Grazvydas Ignotas
2012-02-07 22:55 ` Kevin Hilman [this message]

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=874nv2gsnb.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=gary@mlbassoc.com \
    --cc=linux-omap@vger.kernel.org \
    /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