Bug#774896: linux: The armmp kernel config doesn't support exynos4 / odroid hardware
Control: tag -1 -newcomer
Control: severity -1 wishlist
On Thu, 2015-01-08 at 19:58 +0100, Sten Spans wrote:
> Currently there is no working debian kernel for exynos4 / odroid
> platforms.
Thanks for taking the time to submit a patch. I'm afraid I've now
remembered why I didn't enable exynos4 originally (apart from not having
the h/w myself) which is this from arch/arm/Kconfig:
config HZ_FIXED
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
ARCH_S5PV210 || ARCH_EXYNOS4
default AT91_TIMER_HZ if ARCH_AT91
default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
default 0
which forces the clock to run at 200MHZ on EXYNOS4, deviating from our
current global selection and generally being incompatible with the
multiplatform kernel idiom (what if the next platform requires some
other rate?).
Unfortunately this is still the case in v3.18 and in v3.19-rc3.
Looking through the upstream git history it seems this was in place when
the platform was introduced, with no comment on why.
Searching around a bit I don't see any rationale anywhere else either
and I haven't found any patches which suggest removing the limitation on
exynos4, the closest was [0] which is a thread containing [1] "I think
we could all be fairly confident that Exynos4 or S5P does not
require HZ=200", but nothing seems to have happened based on this (the
rest of the thread seemed to digress into talking about other
platforms).
I did find some (chromeos) patches suggesting that exynos5 should use
HZ=200 too[2], but the claim isn't really substantiated, at least not in
the stuff I can see without a gerrit login. Nothing like that has been
proposed upstream AFAICT (and I suspect they aren't needed in general,
perhaps it's some chomeos special case).
I'm afraid what this means is that I'm not currently willing to enable
Exynos4 support in the Debian kernel.
The next step would be for you to approach the upstream ML and exynos
maintainers and to try and figure out where this HZ=200 requirement
comes from and what, if anything, needs to be done for the restriction
to be removed, please do CC this bugreport. Given [1] it may even be
that a tested patch removing the restriction would just be accepted.
BTW CONFIG_REGULATOR_MAX77686=y isn't a problem, for things needed by
the core functionality we are in general tolerating that for now, at
least until auto-inclusion in initramfs etc is figured out.
Ian.
[0] http://lkml.iu.edu/hypermail/linux/kernel/1301.2/03361.html
[1] http://lkml.iu.edu/hypermail/linux/kernel/1301.2/03558.html
[2] https://gerrit.chromium.org/gerrit/#/c/26446/
Reply to: