Exynos regressions w.r.t. config and debuggability due to multiplatform

Exynos regressions w.r.t. config and debuggability due to multiplatform

[Olof Johansson]

Arnd,

I think we should hold off on multiplatform for exynos until it works
better, i.e. 3.11.

First, the defconfig we have in our out-of-tree build system now
builds a broken kernel since it doesn't set ARCH_EXYNOS_SINGLE. As a
result, exynos gets turned off. It's quite awkward to switch between
pre- and post-multiplatform configs, which makes bisecting and other
error finding hard. I'm sure this will hit other downstream users too.

What's even more frustrating is that I can't turn on DEBUG_LL, since
serial drivers depend on PLAT_SAMSUNG, and that is no longer set.

Seems like we'll have a really broken 3.10 if we merge what we have
now. More bake time is definitely needed. :(


-Olof

Exynos regressions w.r.t. config and debuggability due to multiplatform

[Olof Johansson]

Arnd,

I think we should hold off on multiplatform for exynos until it works
better, i.e. 3.11.

First, the defconfig we have in our out-of-tree build system now
builds a broken kernel since it doesn't set ARCH_EXYNOS_SINGLE. As a
result, exynos gets turned off. It's quite awkward to switch between
pre- and post-multiplatform configs, which makes bisecting and other
error finding hard. I'm sure this will hit other downstream users too.

What's even more frustrating is that I can't turn on DEBUG_LL, since
serial drivers depend on PLAT_SAMSUNG, and that is no longer set.

Seems like we'll have a really broken 3.10 if we merge what we have
now. More bake time is definitely needed. :(


-Olof

Re: Exynos regressions w.r.t. config and debuggability due to multiplatform

[Arnd Bergmann]

On Wednesday 24 April 2013, Olof Johansson wrote:
> I think we should hold off on multiplatform for exynos until it works
> better, i.e. 3.11.
> 
> First, the defconfig we have in our out-of-tree build system now
> builds a broken kernel since it doesn't set ARCH_EXYNOS_SINGLE. As a
> result, exynos gets turned off. It's quite awkward to switch between
> pre- and post-multiplatform configs, which makes bisecting and other
> error finding hard. I'm sure this will hit other downstream users too.

Hmm, good. point. The idea of the naming was that you actually
/can/ go back and forth across that commit since ARCH_EXYNOS exists
at all times, either as a standalone symbol or as part of multiplatform.

Unfortunately, I did not consider that this stops working for
bisection if we do the change and only make ARCH_EXYNOS_SINGLE
work correctly but leave ARCH_EXYNOS as "depends on BROKEN"
initially. I think you are right that we need to revert bd51de53e1b
"ARM: exynos: enable multiplatform support" in the next/multiplatform
branch, although I don't see a problem with the other commits there.

> What's even more frustrating is that I can't turn on DEBUG_LL, since
> serial drivers depend on PLAT_SAMSUNG, and that is no longer set.

Are you sure? I don't see that problem. PLAT_SAMSUNG should still
get set in both single- and multiplatform configurations, along with
PLAT_SAMSUNG_SINGLE in the case of single-platform exynos.
I've testing DEBUG_LL both in single and multi configurations on
linux-next.

> Seems like we'll have a really broken 3.10 if we merge what we have
> now. More bake time is definitely needed. :(

I think the problems with exynos are elsewhere at the moment, and
Kukjin, Thomas, Tomasz and others have worked hard on getting those
problems fixed. I would suggest we leave the "samsung/exynos-multiplatform"
preparation series scheduled for the first set of pull requests in
next/multiplatform but revert the bd51de53e1b commit in it.

Once the dust settles in the merge window and the exynos multiplatform
patches that are queued up in other trees (serial, spi, video, ...)
have made it upstream, we can decide if the late/multiplatform
series still looks scary or not. If you feel strongly about it and know
that you don't want to merge it then, we can also drop the first part now.

	Arnd

Exynos regressions w.r.t. config and debuggability due to multiplatform

[Arnd Bergmann]

On Wednesday 24 April 2013, Olof Johansson wrote:
> I think we should hold off on multiplatform for exynos until it works
> better, i.e. 3.11.
> 
> First, the defconfig we have in our out-of-tree build system now
> builds a broken kernel since it doesn't set ARCH_EXYNOS_SINGLE. As a
> result, exynos gets turned off. It's quite awkward to switch between
> pre- and post-multiplatform configs, which makes bisecting and other
> error finding hard. I'm sure this will hit other downstream users too.

Hmm, good. point. The idea of the naming was that you actually
/can/ go back and forth across that commit since ARCH_EXYNOS exists
at all times, either as a standalone symbol or as part of multiplatform.

Unfortunately, I did not consider that this stops working for
bisection if we do the change and only make ARCH_EXYNOS_SINGLE
work correctly but leave ARCH_EXYNOS as "depends on BROKEN"
initially. I think you are right that we need to revert bd51de53e1b
"ARM: exynos: enable multiplatform support" in the next/multiplatform
branch, although I don't see a problem with the other commits there.

> What's even more frustrating is that I can't turn on DEBUG_LL, since
> serial drivers depend on PLAT_SAMSUNG, and that is no longer set.

Are you sure? I don't see that problem. PLAT_SAMSUNG should still
get set in both single- and multiplatform configurations, along with
PLAT_SAMSUNG_SINGLE in the case of single-platform exynos.
I've testing DEBUG_LL both in single and multi configurations on
linux-next.

> Seems like we'll have a really broken 3.10 if we merge what we have
> now. More bake time is definitely needed. :(

I think the problems with exynos are elsewhere at the moment, and
Kukjin, Thomas, Tomasz and others have worked hard on getting those
problems fixed. I would suggest we leave the "samsung/exynos-multiplatform"
preparation series scheduled for the first set of pull requests in
next/multiplatform but revert the bd51de53e1b commit in it.

Once the dust settles in the merge window and the exynos multiplatform
patches that are queued up in other trees (serial, spi, video, ...)
have made it upstream, we can decide if the late/multiplatform
series still looks scary or not. If you feel strongly about it and know
that you don't want to merge it then, we can also drop the first part now.

	Arnd

Re: Exynos regressions w.r.t. config and debuggability due to multiplatform

[Kukjin Kim]

On 04/25/13 00:03, Arnd Bergmann wrote:
> On Wednesday 24 April 2013, Olof Johansson wrote:
>> I think we should hold off on multiplatform for exynos until it works
>> better, i.e. 3.11.
>>
I think, this would be better choice for now if it's not urgent...

- Kukjin

Exynos regressions w.r.t. config and debuggability due to multiplatform

[Kukjin Kim]

On 04/25/13 00:03, Arnd Bergmann wrote:
> On Wednesday 24 April 2013, Olof Johansson wrote:
>> I think we should hold off on multiplatform for exynos until it works
>> better, i.e. 3.11.
>>
I think, this would be better choice for now if it's not urgent...

- Kukjin

Re: Exynos regressions w.r.t. config and debuggability due to multiplatform

[Arnd Bergmann]

On Thursday 25 April 2013, Kukjin Kim wrote:
> 
> On 04/25/13 00:03, Arnd Bergmann wrote:
> > On Wednesday 24 April 2013, Olof Johansson wrote:
> >> I think we should hold off on multiplatform for exynos until it works
> >> better, i.e. 3.11.
> >>
> I think, this would be better choice for now if it's not urgent...
> 

I spent a lot of time on it because it's a priority for Linaro, but
that means I'm biased in the question of whether to merge it or not.
It should only get in if you and Olof think it's a good idea.

	Arnd

Exynos regressions w.r.t. config and debuggability due to multiplatform

[Arnd Bergmann]

On Thursday 25 April 2013, Kukjin Kim wrote:
> 
> On 04/25/13 00:03, Arnd Bergmann wrote:
> > On Wednesday 24 April 2013, Olof Johansson wrote:
> >> I think we should hold off on multiplatform for exynos until it works
> >> better, i.e. 3.11.
> >>
> I think, this would be better choice for now if it's not urgent...
> 

I spent a lot of time on it because it's a priority for Linaro, but
that means I'm biased in the question of whether to merge it or not.
It should only get in if you and Olof think it's a good idea.

	Arnd

Re: Exynos regressions w.r.t. config and debuggability due to multiplatform

[Olof Johansson]

On Thu, Apr 25, 2013 at 07:31:24PM +0200, Arnd Bergmann wrote:
> On Thursday 25 April 2013, Kukjin Kim wrote:
> > 
> > On 04/25/13 00:03, Arnd Bergmann wrote:
> > > On Wednesday 24 April 2013, Olof Johansson wrote:
> > >> I think we should hold off on multiplatform for exynos until it works
> > >> better, i.e. 3.11.
> > >>
> > I think, this would be better choice for now if it's not urgent...
> > 
> 
> I spent a lot of time on it because it's a priority for Linaro, but
> that means I'm biased in the question of whether to merge it or not.
> It should only get in if you and Olof think it's a good idea.

I've reverted the commit you pointed out as the problematic one now,
and with that I get a working setup. That means most of the base patches are
in, just not the final Kconfig shuffling. 3.11 seems more realistic for that.


-Olof

Exynos regressions w.r.t. config and debuggability due to multiplatform

[Olof Johansson]

On Thu, Apr 25, 2013 at 07:31:24PM +0200, Arnd Bergmann wrote:
> On Thursday 25 April 2013, Kukjin Kim wrote:
> > 
> > On 04/25/13 00:03, Arnd Bergmann wrote:
> > > On Wednesday 24 April 2013, Olof Johansson wrote:
> > >> I think we should hold off on multiplatform for exynos until it works
> > >> better, i.e. 3.11.
> > >>
> > I think, this would be better choice for now if it's not urgent...
> > 
> 
> I spent a lot of time on it because it's a priority for Linaro, but
> that means I'm biased in the question of whether to merge it or not.
> It should only get in if you and Olof think it's a good idea.

I've reverted the commit you pointed out as the problematic one now,
and with that I get a working setup. That means most of the base patches are
in, just not the final Kconfig shuffling. 3.11 seems more realistic for that.


-Olof