From: Tony Lindgren <tony@atomide.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Olof Johansson <olof@lixom.net>,
linux-arm-kernel@lists.infradead.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: linux-next: build failure after merge of the final tree (arm-soc tree related)
Date: Mon, 17 Sep 2012 13:32:33 -0700 [thread overview]
Message-ID: <20120917203233.GW4521@atomide.com> (raw)
In-Reply-To: <20120917172208.GN4521@atomide.com>
* Tony Lindgren <tony@atomide.com> [120917 10:25]:
> * Arnd Bergmann <arnd@arndb.de> [120917 07:30]:
> >
> > If it requires plat/cpu.h, it should actually be limited to CONFIG_ARCH_OMAP,
> > otherwise we will get the same problem on non-OMAP ARM builds. From what
> > I can tell, the problem is the clocks_init function, which is the only
> > part that is not completely generic.
> >
> > The trivial workaround would be to enclose the "#include <plat/cpu.h>"
> > statement in #ifdef CONFIG_ARCH_OMAP, but with the common clock code
> > in place, we should probably be able to come up with a better solution
> > that works independent of the omap platform.
>
> There are patches coming to remove cpu_is_omap usage from drivers,
> and until then we should just ifdef the plat/cpu.h include.
>
> It is possible to use these kind of external PM chips with other
> SoCs, they're just not omap related and that's why there drivers
> have not had the Kconfig dependency. I'll post a patch for that.
Looks like we can just remove the cpu_is_omap code with clock
aliases, patch posted with Subject:
[PATCH] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-next: build failure after merge of the final tree (arm-soc tree related)
Date: Mon, 17 Sep 2012 13:32:33 -0700 [thread overview]
Message-ID: <20120917203233.GW4521@atomide.com> (raw)
In-Reply-To: <20120917172208.GN4521@atomide.com>
* Tony Lindgren <tony@atomide.com> [120917 10:25]:
> * Arnd Bergmann <arnd@arndb.de> [120917 07:30]:
> >
> > If it requires plat/cpu.h, it should actually be limited to CONFIG_ARCH_OMAP,
> > otherwise we will get the same problem on non-OMAP ARM builds. From what
> > I can tell, the problem is the clocks_init function, which is the only
> > part that is not completely generic.
> >
> > The trivial workaround would be to enclose the "#include <plat/cpu.h>"
> > statement in #ifdef CONFIG_ARCH_OMAP, but with the common clock code
> > in place, we should probably be able to come up with a better solution
> > that works independent of the omap platform.
>
> There are patches coming to remove cpu_is_omap usage from drivers,
> and until then we should just ifdef the plat/cpu.h include.
>
> It is possible to use these kind of external PM chips with other
> SoCs, they're just not omap related and that's why there drivers
> have not had the Kconfig dependency. I'll post a patch for that.
Looks like we can just remove the cpu_is_omap code with clock
aliases, patch posted with Subject:
[PATCH] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
Regards,
Tony
next prev parent reply other threads:[~2012-09-17 20:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 11:26 linux-next: build failure after merge of the final tree (arm-soc tree related) Stephen Rothwell
2012-09-17 11:26 ` Stephen Rothwell
2012-09-17 11:26 ` Stephen Rothwell
2012-09-17 14:11 ` Olof Johansson
2012-09-17 14:11 ` Olof Johansson
2012-09-17 17:23 ` Tony Lindgren
2012-09-17 17:23 ` Tony Lindgren
2012-09-17 14:29 ` Arnd Bergmann
2012-09-17 14:29 ` Arnd Bergmann
2012-09-17 17:22 ` Tony Lindgren
2012-09-17 17:22 ` Tony Lindgren
2012-09-17 20:32 ` Tony Lindgren [this message]
2012-09-17 20:32 ` Tony Lindgren
-- strict thread matches above, loose matches on Subject: below --
2012-03-14 23:59 Stephen Rothwell
2012-03-14 23:59 ` Stephen Rothwell
2012-03-14 23:59 ` Stephen Rothwell
2012-03-15 0:20 ` Jason Cooper
2012-03-15 0:20 ` Jason Cooper
2012-03-15 2:08 ` Stephen Rothwell
2012-03-15 2:08 ` Stephen Rothwell
2012-03-15 16:39 ` Arnd Bergmann
2012-03-15 16:39 ` Arnd Bergmann
2012-03-15 17:22 ` Jason Cooper
2012-03-15 17:22 ` Jason Cooper
2012-03-15 17:32 ` Arnd Bergmann
2012-03-15 17:32 ` Arnd Bergmann
2012-03-15 1:53 ` Paul Gortmaker
2012-03-15 1:53 ` Paul Gortmaker
2012-03-15 2:05 ` Stephen Rothwell
2012-03-15 2:05 ` Stephen Rothwell
2011-07-22 6:42 Stephen Rothwell
2011-07-23 12:36 ` Arnd Bergmann
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=20120917203233.GW4521@atomide.com \
--to=tony@atomide.com \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=olof@lixom.net \
--cc=sfr@canb.auug.org.au \
/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 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.