diff mbox

[5/6] ARM: EXYNOS: Enable multi-platform build support

Message ID 1397554134-11827-6-git-send-email-sachin.kamat@linaro.org
State Superseded
Headers show

Commit Message

Sachin Kamat April 15, 2014, 9:28 a.m. UTC 
From: Arnd Bergmann <arnd@arndb.de>

This makes it possible to enable the exynos platform as part of a
multiplatform kernel, in addition to keeping the single-platform
Exynos support.
sparsemem is currently not supported in multiplatform.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
 arch/arm/Kconfig                  |   27 +++------------------------
 arch/arm/configs/exynos_defconfig |    2 +-
 arch/arm/mach-exynos/Kconfig      |   27 +++++++++++++++++++++++++++
 arch/arm/mach-exynos/Makefile     |    2 ++
 arch/arm/plat-samsung/Makefile    |    3 +++
 5 files changed, 36 insertions(+), 25 deletions(-)

Comments

Tomasz Figa April 16, 2014, 1:51 p.m. UTC | #1 
Hi Sachin,

On 15.04.2014 11:28, Sachin Kamat wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This makes it possible to enable the exynos platform as part of a
> multiplatform kernel, in addition to keeping the single-platform
> Exynos support.
> sparsemem is currently not supported in multiplatform.

Is this still true as of today?

Otherwise looks fine.

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann April 16, 2014, 2:31 p.m. UTC | #2 
On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
> On 15.04.2014 11:28, Sachin Kamat wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > This makes it possible to enable the exynos platform as part of a
> > multiplatform kernel, in addition to keeping the single-platform
> > Exynos support.
> > sparsemem is currently not supported in multiplatform.
> 
> Is this still true as of today?
> 
> Otherwise looks fine.

sparsemem is still not supported in multiplatform, but after I looked
at it in more detail, I came to the conclusion that there is no
reason why it couldn't be. It just needs testing so we are confident
that it doesn't break other platforms, and we need to find good
platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS
to put into asm/memory.h, since we can't have them set in mach/memory.h
for multiplatform.

Looking at my patch again now, I would actually prefer to kill off
the single-platform support for exynos right away. I don't see
any reason to keep it now, and it complicates the test matrix.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tomasz Figa April 16, 2014, 2:48 p.m. UTC | #3 
On 16.04.2014 16:31, Arnd Bergmann wrote:
> On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
>> On 15.04.2014 11:28, Sachin Kamat wrote:
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>
>>> This makes it possible to enable the exynos platform as part of a
>>> multiplatform kernel, in addition to keeping the single-platform
>>> Exynos support.
>>> sparsemem is currently not supported in multiplatform.
>>
>> Is this still true as of today?
>>
>> Otherwise looks fine.
>
> sparsemem is still not supported in multiplatform, but after I looked
> at it in more detail, I came to the conclusion that there is no
> reason why it couldn't be. It just needs testing so we are confident
> that it doesn't break other platforms, and we need to find good
> platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS
> to put into asm/memory.h, since we can't have them set in mach/memory.h
> for multiplatform.
>
> Looking at my patch again now, I would actually prefer to kill off
> the single-platform support for exynos right away. I don't see
> any reason to keep it now, and it complicates the test matrix.

That would be the best option, assuming that it wouldn't introduce 
feature regressions. Unfortunately there is still ongoing work on 
cpufreq driver to make it multiplatform-aware, so dropping single 
platform support right now would introduce at least this one regression.

Thomas, is there any progress on new version of Exynos cpufreq rework 
series?

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thomas Abraham April 16, 2014, 2:55 p.m. UTC | #4 
On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> On 16.04.2014 16:31, Arnd Bergmann wrote:
>>
>> On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
>>>
>>> On 15.04.2014 11:28, Sachin Kamat wrote:
>>>>
>>>> From: Arnd Bergmann <arnd@arndb.de>
>>>>
>>>> This makes it possible to enable the exynos platform as part of a
>>>> multiplatform kernel, in addition to keeping the single-platform
>>>> Exynos support.
>>>> sparsemem is currently not supported in multiplatform.
>>>
>>>
>>> Is this still true as of today?
>>>
>>> Otherwise looks fine.
>>
>>
>> sparsemem is still not supported in multiplatform, but after I looked
>> at it in more detail, I came to the conclusion that there is no
>> reason why it couldn't be. It just needs testing so we are confident
>> that it doesn't break other platforms, and we need to find good
>> platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS
>> to put into asm/memory.h, since we can't have them set in mach/memory.h
>> for multiplatform.
>>
>> Looking at my patch again now, I would actually prefer to kill off
>> the single-platform support for exynos right away. I don't see
>> any reason to keep it now, and it complicates the test matrix.
>
>
> That would be the best option, assuming that it wouldn't introduce feature
> regressions. Unfortunately there is still ongoing work on cpufreq driver to
> make it multiplatform-aware, so dropping single platform support right now
> would introduce at least this one regression.
>
> Thomas, is there any progress on new version of Exynos cpufreq rework
> series?

Hi Tomasz,

Yes, I am preparing the fourth version of the cpufreq patches and will
post it next week. Mostly, the changes will be addressing your review
comments.

Thanks,
Thomas.

>
> Best regards,
> Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tomasz Figa April 16, 2014, 2:58 p.m. UTC | #5 
Hi Thomas,

On 16.04.2014 16:55, Thomas Abraham wrote:
> On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa <t.figa@samsung.com> wrote:
>> On 16.04.2014 16:31, Arnd Bergmann wrote:
>>>
>>> On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
>>>>
>>>> On 15.04.2014 11:28, Sachin Kamat wrote:
>>>>>
>>>>> From: Arnd Bergmann <arnd@arndb.de>
>>>>>
>>>>> This makes it possible to enable the exynos platform as part of a
>>>>> multiplatform kernel, in addition to keeping the single-platform
>>>>> Exynos support.
>>>>> sparsemem is currently not supported in multiplatform.
>>>>
>>>>
>>>> Is this still true as of today?
>>>>
>>>> Otherwise looks fine.
>>>
>>>
>>> sparsemem is still not supported in multiplatform, but after I looked
>>> at it in more detail, I came to the conclusion that there is no
>>> reason why it couldn't be. It just needs testing so we are confident
>>> that it doesn't break other platforms, and we need to find good
>>> platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS
>>> to put into asm/memory.h, since we can't have them set in mach/memory.h
>>> for multiplatform.
>>>
>>> Looking at my patch again now, I would actually prefer to kill off
>>> the single-platform support for exynos right away. I don't see
>>> any reason to keep it now, and it complicates the test matrix.
>>
>>
>> That would be the best option, assuming that it wouldn't introduce feature
>> regressions. Unfortunately there is still ongoing work on cpufreq driver to
>> make it multiplatform-aware, so dropping single platform support right now
>> would introduce at least this one regression.
>>
>> Thomas, is there any progress on new version of Exynos cpufreq rework
>> series?
>
> Hi Tomasz,
>
> Yes, I am preparing the fourth version of the cpufreq patches and will
> post it next week. Mostly, the changes will be addressing your review
> comments.

OK. Looking forward to it. Thanks for an update on this.

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown April 16, 2014, 8:50 p.m. UTC | #6 
On Wed, Apr 16, 2014 at 08:14:27PM +0200, Arnd Bergmann wrote:

> This patch does a partial revert of 313367e7bfa by allowing these
> drivers on all samsung platforms except EXYNOS, so we can proceed
> with the multiplatform patches.

> If support for these drivers is actually needed on EXYNOS machines,
> the drivers should first be moved over to use the dmaengine code.

I would be surprised if neither IP is present on any Exynos SoC, they
were added in the s5p range.  Is Sachin's fix for building these
(present in -rc1) not doing the job?
Arnd Bergmann April 16, 2014, 9 p.m. UTC | #7 
On Wednesday 16 April 2014 21:50:01 Mark Brown wrote:
> On Wed, Apr 16, 2014 at 08:14:27PM +0200, Arnd Bergmann wrote:
> 
> > This patch does a partial revert of 313367e7bfa by allowing these
> > drivers on all samsung platforms except EXYNOS, so we can proceed
> > with the multiplatform patches.
> 
> > If support for these drivers is actually needed on EXYNOS machines,
> > the drivers should first be moved over to use the dmaengine code.
> 
> I would be surprised if neither IP is present on any Exynos SoC, they
> were added in the s5p range.  Is Sachin's fix for building these
> (present in -rc1) not doing the job?

I hadn't noticed that patch, it probably does, so nevermind.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Olof Johansson April 22, 2014, 3:06 a.m. UTC | #8 
On Tue, Apr 15, 2014 at 2:28 AM, Sachin Kamat <sachin.kamat@linaro.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This makes it possible to enable the exynos platform as part of a
> multiplatform kernel, in addition to keeping the single-platform
> Exynos support.
> sparsemem is currently not supported in multiplatform.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
>  arch/arm/Kconfig                  |   27 +++------------------------
>  arch/arm/configs/exynos_defconfig |    2 +-
>  arch/arm/mach-exynos/Kconfig      |   27 +++++++++++++++++++++++++++
>  arch/arm/mach-exynos/Makefile     |    2 ++
>  arch/arm/plat-samsung/Makefile    |    3 +++
>  5 files changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 4422601059e8..9d459e9c396b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -828,34 +828,13 @@ config ARCH_S5PV210
>         help
>           Samsung S5PV210/S5PC110 series based systems
>
> -config ARCH_EXYNOS
> +config ARCH_EXYNOS_SINGLE
>         bool "Samsung EXYNOS"
> -       select ARCH_HAS_BANDGAP
> -       select ARCH_HAS_CPUFREQ
> -       select ARCH_HAS_HOLES_MEMORYMODEL
> -       select ARCH_REQUIRE_GPIOLIB
> +       select ARCH_EXYNOS
>         select ARCH_SPARSEMEM_ENABLE
> -       select ARM_AMBA
> -       select ARM_GIC
> -       select CLKSRC_OF
> -       select COMMON_CLK
> -       select CPU_V7
> -       select GENERIC_CLOCKEVENTS
> -       select HAVE_ARM_SCU if SMP
> -       select HAVE_S3C2410_I2C if I2C
> -       select HAVE_S3C2410_WATCHDOG if WATCHDOG
> -       select HAVE_S3C_RTC if RTC_CLASS
> -       select HAVE_SMP
>         select NEED_MACH_MEMORY_H
> -       select PINCTRL
> -       select PINCTRL_EXYNOS
> -       select PM_GENERIC_DOMAINS if PM_RUNTIME
> -       select S5P_DEV_MFC
> -       select SAMSUNG_DMADEV
> -       select SPARSE_IRQ
> -       select USE_OF
>         help
> -         Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
> +         Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)

I don't think there's a point in keeping this around. A
"single-platform" config is just enabling a single platform in the
config, it's not a specific option. I don't think any of the other
platforms use anything like this today.

-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann April 22, 2014, 7:56 p.m. UTC | #9 
On Tuesday 22 April 2014, Olof Johansson wrote:
> I don't think there's a point in keeping this around. A
> "single-platform" config is just enabling a single platform in the
> config, it's not a specific option. I don't think any of the other
> platforms use anything like this today.

The only one doing that is shmobile, but only because they have
some SoCs that are multiplatform capable and some that are not.
This isn't the case for Exynos, so it should no longer be needed.

When I originally created this patch 18 months ago, there were a
number of drivers that broke when multiplatform got enabled.
Now the cpufreq driver is the only one left, but it seems that
it will make it for 3.16, and I wouldn't wait for it if it doesn't.
Let's just do multiplatform-only.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kukjin Kim May 13, 2014, 4:37 a.m. UTC | #10 
Arnd Bergmann wrote:
> 
> On Tuesday 22 April 2014, Olof Johansson wrote:
> > I don't think there's a point in keeping this around. A
> > "single-platform" config is just enabling a single platform in the
> > config, it's not a specific option. I don't think any of the other
> > platforms use anything like this today.
> 
> The only one doing that is shmobile, but only because they have
> some SoCs that are multiplatform capable and some that are not.
> This isn't the case for Exynos, so it should no longer be needed.
> 
> When I originally created this patch 18 months ago, there were a
> number of drivers that broke when multiplatform got enabled.
> Now the cpufreq driver is the only one left, but it seems that
> it will make it for 3.16, and I wouldn't wait for it if it doesn't.
> Let's just do multiplatform-only.
> 
In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and
EXYNOS5 because IMHO selecting each series would be helpful on real product,
multiplatform is available though. Additionally EXYNOS3 is being added.

It's true we can support exynos-multiplatform even though above options are
included...

Thanks,
Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann May 13, 2014, 9:15 a.m. UTC | #11 
On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote:
> Arnd Bergmann wrote:
> > 
> > On Tuesday 22 April 2014, Olof Johansson wrote:
> > > I don't think there's a point in keeping this around. A
> > > "single-platform" config is just enabling a single platform in the
> > > config, it's not a specific option. I don't think any of the other
> > > platforms use anything like this today.
> > 
> > The only one doing that is shmobile, but only because they have
> > some SoCs that are multiplatform capable and some that are not.
> > This isn't the case for Exynos, so it should no longer be needed.
> > 
> > When I originally created this patch 18 months ago, there were a
> > number of drivers that broke when multiplatform got enabled.
> > Now the cpufreq driver is the only one left, but it seems that
> > it will make it for 3.16, and I wouldn't wait for it if it doesn't.
> > Let's just do multiplatform-only.
> > 
> In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and
> EXYNOS5 because IMHO selecting each series would be helpful on real product,
> multiplatform is available though. Additionally EXYNOS3 is being added.
> 
> It's true we can support exynos-multiplatform even though above options are
> included...

I think we are talking about different questions here:

What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option
that is there for building EXYNOS but not allowing any other SoC.

What I think you mean is that you want the individual EXYNOS versions
to be separate Kconfig options, so you can build a kernel that supports
EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far
as I'm concerned, and it's not directly related to the first point.

Note that if you enable LPAE, you will still only be able to build EXYNOS5
after the patch, but then you can have it in the same kernel as e.g.
Tegra4 and Snapdragon 600.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Olof Johansson May 13, 2014, 6:01 p.m. UTC | #12 
On Tue, May 13, 2014 at 2:15 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote:
>> Arnd Bergmann wrote:
>> >
>> > On Tuesday 22 April 2014, Olof Johansson wrote:
>> > > I don't think there's a point in keeping this around. A
>> > > "single-platform" config is just enabling a single platform in the
>> > > config, it's not a specific option. I don't think any of the other
>> > > platforms use anything like this today.
>> >
>> > The only one doing that is shmobile, but only because they have
>> > some SoCs that are multiplatform capable and some that are not.
>> > This isn't the case for Exynos, so it should no longer be needed.
>> >
>> > When I originally created this patch 18 months ago, there were a
>> > number of drivers that broke when multiplatform got enabled.
>> > Now the cpufreq driver is the only one left, but it seems that
>> > it will make it for 3.16, and I wouldn't wait for it if it doesn't.
>> > Let's just do multiplatform-only.
>> >
>> In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and
>> EXYNOS5 because IMHO selecting each series would be helpful on real product,
>> multiplatform is available though. Additionally EXYNOS3 is being added.
>>
>> It's true we can support exynos-multiplatform even though above options are
>> included...
>
> I think we are talking about different questions here:
>
> What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option
> that is there for building EXYNOS but not allowing any other SoC.

Yes. i.e. the only way forward is multiplatform _only_. _BUT_ you can
choose to disable all other platforms in a kernel, and thus turn it
into a single-platform build. That's fine. What we don't want is added
logic like the EXYNOS_SINGLE Kconfig was, just to do that.

> What I think you mean is that you want the individual EXYNOS versions
> to be separate Kconfig options, so you can build a kernel that supports
> EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far
> as I'm concerned, and it's not directly related to the first point.

I'm also OK with that, but please don't make it more granular than per
family if you can avoid it.

> Note that if you enable LPAE, you will still only be able to build EXYNOS5
> after the patch, but then you can have it in the same kernel as e.g.
> Tegra4 and Snapdragon 600.

Yep, and that's as expected.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kukjin Kim May 14, 2014, 4:33 a.m. UTC | #13 
Olof Johansson wrote:
> 
> On Tue, May 13, 2014 at 2:15 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote:
> >> Arnd Bergmann wrote:
> >> >
> >> > On Tuesday 22 April 2014, Olof Johansson wrote:
> >> > > I don't think there's a point in keeping this around. A
> >> > > "single-platform" config is just enabling a single platform in the
> >> > > config, it's not a specific option. I don't think any of the other
> >> > > platforms use anything like this today.
> >> >
> >> > The only one doing that is shmobile, but only because they have
> >> > some SoCs that are multiplatform capable and some that are not.
> >> > This isn't the case for Exynos, so it should no longer be needed.
> >> >
> >> > When I originally created this patch 18 months ago, there were a
> >> > number of drivers that broke when multiplatform got enabled.
> >> > Now the cpufreq driver is the only one left, but it seems that
> >> > it will make it for 3.16, and I wouldn't wait for it if it doesn't.
> >> > Let's just do multiplatform-only.
> >> >
> >> In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and
> >> EXYNOS5 because IMHO selecting each series would be helpful on real product,
> >> multiplatform is available though. Additionally EXYNOS3 is being added.
> >>
> >> It's true we can support exynos-multiplatform even though above options are
> >> included...
> >
> > I think we are talking about different questions here:
> >
Thanks for your clarification.

> > What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option
> > that is there for building EXYNOS but not allowing any other SoC.
> 
Yes and agreed ;-)

> Yes. i.e. the only way forward is multiplatform _only_. _BUT_ you can
> choose to disable all other platforms in a kernel, and thus turn it
> into a single-platform build. That's fine. What we don't want is added
> logic like the EXYNOS_SINGLE Kconfig was, just to do that.
> 
Sure.

> > What I think you mean is that you want the individual EXYNOS versions
> > to be separate Kconfig options, so you can build a kernel that supports
> > EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far
> > as I'm concerned, and it's not directly related to the first point.
> 
OK, thanks :-)

> I'm also OK with that, but please don't make it more granular than per
> family if you can avoid it.
> 
Sure.

> > Note that if you enable LPAE, you will still only be able to build EXYNOS5
> > after the patch, but then you can have it in the same kernel as e.g.
> > Tegra4 and Snapdragon 600.
> 
> Yep, and that's as expected.
> 
OK.

Thanks,
Kukjin

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

Patch

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4422601059e8..9d459e9c396b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -828,34 +828,13 @@  config ARCH_S5PV210
 	help
 	  Samsung S5PV210/S5PC110 series based systems
 
-config ARCH_EXYNOS
+config ARCH_EXYNOS_SINGLE
 	bool "Samsung EXYNOS"
-	select ARCH_HAS_BANDGAP
-	select ARCH_HAS_CPUFREQ
-	select ARCH_HAS_HOLES_MEMORYMODEL
-	select ARCH_REQUIRE_GPIOLIB
+	select ARCH_EXYNOS
 	select ARCH_SPARSEMEM_ENABLE
-	select ARM_AMBA
-	select ARM_GIC
-	select CLKSRC_OF
-	select COMMON_CLK
-	select CPU_V7
-	select GENERIC_CLOCKEVENTS
-	select HAVE_ARM_SCU if SMP
-	select HAVE_S3C2410_I2C if I2C
-	select HAVE_S3C2410_WATCHDOG if WATCHDOG
-	select HAVE_S3C_RTC if RTC_CLASS
-	select HAVE_SMP
 	select NEED_MACH_MEMORY_H
-	select PINCTRL
-	select PINCTRL_EXYNOS
-	select PM_GENERIC_DOMAINS if PM_RUNTIME
-	select S5P_DEV_MFC
-	select SAMSUNG_DMADEV
-	select SPARSE_IRQ
-	select USE_OF
 	help
-	  Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
+	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
 
 config ARCH_DAVINCI
 	bool "TI DaVinci"
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 4ce7b70ea901..103a676256cd 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -7,7 +7,7 @@  CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_PARTITION_ADVANCED=y
-CONFIG_ARCH_EXYNOS=y
+CONFIG_ARCH_EXYNOS_SINGLE=y
 CONFIG_S3C_LOWLEVEL_UART_PORT=3
 CONFIG_S3C24XX_PWM=y
 CONFIG_ARCH_EXYNOS5=y
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 5c34dc26cec6..bc55af76a05f 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -7,6 +7,33 @@ 
 
 # Configuration options for the EXYNOS4
 
+config ARCH_EXYNOS
+	bool "Samsung EXYNOS" if ARCH_MULTI_V7
+	select ARCH_HAS_BANDGAP
+	select ARCH_HAS_CPUFREQ
+	select ARCH_HAS_HOLES_MEMORYMODEL
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_AMBA
+	select ARM_GIC
+	select CLKSRC_OF
+	select COMMON_CLK
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select HAVE_ARM_SCU if SMP
+	select HAVE_S3C2410_I2C if I2C
+	select HAVE_S3C2410_WATCHDOG if WATCHDOG
+	select HAVE_S3C_RTC if RTC_CLASS
+	select HAVE_SMP
+	select PINCTRL
+	select PINCTRL_EXYNOS
+	select PM_GENERIC_DOMAINS if PM_RUNTIME
+	select S5P_DEV_MFC
+	select SAMSUNG_DMADEV
+	select SPARSE_IRQ
+	select USE_OF
+	help
+	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
+
 if ARCH_EXYNOS
 
 menu "SAMSUNG EXYNOS SoCs Support"
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index f6dcc256db56..24a8efe3d4bd 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -5,6 +5,8 @@ 
 #
 # Licensed under GPLv2
 
+ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include
+
 obj-y				:=
 obj-m				:=
 obj-n				:=
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 25c826ed3b65..5e5beaa9ae15 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -4,6 +4,9 @@ 
 #
 # Licensed under GPLv2
 
+ccflags-$(CONFIG_ARCH_MULTI_V7) += -I$(srctree)/$(src)/include
+ccflags-$(CONFIG_ARCH_EXYNOS)	+= -I$(srctree)/arch/arm/mach-exynos/include
+
 obj-y				:=
 obj-m				:=
 obj-n				:= dummy.o