* [PATCH 8/8] drm/exynos: don't include plat/gpio-cfg.h
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
Patch 9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM"
allowed building the exynos hdmi driver on non-samsung platforms,
which unfortunately broke compilation in combination with 22c4f42897
"drm: exynos: hdmi: add support for exynos5 hdmi", which added
an inclusion of the samsung-specific plat/gpio-cfg.h header file.
Fortunately, that header file is not required any more here, so
we can simply revert the inclusion in order to build the ARM
allyesconfig again without getting this error:
drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rahul Sharma <rahul.sharma@samsung.com>
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..7f0fc4e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,6 @@
#include <linux/regulator/consumer.h>
#include <linux/io.h>
#include <linux/of_gpio.h>
-#include <plat/gpio-cfg.h>
#include <drm/exynos_drm.h>
--
1.7.10
^ permalink raw reply related
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Santosh Shilimkar @ 2012-11-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061610070.21033@xanadu.home>
On Tuesday 06 November 2012 03:12 PM, Nicolas Pitre wrote:
>
> ... instead of flush_cache_all(). The later unconditionally flushes
> the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
> is costly and unnecessary in some scenarios where setup_mm_for_reboot()
> is used. If L2 has to be flushed as well, it should already be done
> separately on other architectures anyway.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index ab88ed4f8e..2c61085a10 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -104,7 +104,7 @@ early_initcall(init_static_idmap);
> void setup_mm_for_reboot(void)
> {
> /* Clean and invalidate L1. */
> - flush_cache_all();
> + flush_cache_louis();
>
> /* Switch to the identity mapping. */
> cpu_switch_mm(idmap_pgd, &init_mm);
>
Nice. Just one difference is that the I-cache invalidation won't
happen with this change. Not that it is needed here but capturing
that in change-log would be good.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [RFC PATCH 3/4] ARM: kernel: add logical mappings look-up
From: Will Deacon @ 2012-11-06 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-4-git-send-email-lorenzo.pieralisi@arm.com>
On Tue, Oct 16, 2012 at 02:21:47PM +0100, Lorenzo Pieralisi wrote:
> In ARM SMP systems the MPIDR register ([23:0] bits) is used to uniquely
> identify CPUs.
>
> In order to retrieve the logical CPU index corresponding to a given
> MPIDR value and guarantee a consistent translation throughout the kernel,
> this patch adds a look-up based on the MPIDR[23:0] so that kernel subsystems
> can use it whenever the logical cpu index corresponding to a given MPIDR
> value is needed.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> arch/arm/include/asm/smp_plat.h | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
> index 558d6c8..aaa61b6 100644
> --- a/arch/arm/include/asm/smp_plat.h
> +++ b/arch/arm/include/asm/smp_plat.h
> @@ -5,6 +5,9 @@
> #ifndef __ASMARM_SMP_PLAT_H
> #define __ASMARM_SMP_PLAT_H
>
> +#include <linux/cpumask.h>
> +#include <linux/err.h>
> +
> #include <asm/cputype.h>
>
> /*
> @@ -48,5 +51,19 @@ static inline int cache_ops_need_broadcast(void)
> */
> extern int __cpu_logical_map[];
> #define cpu_logical_map(cpu) __cpu_logical_map[cpu]
> +/*
> + * Retrieve logical cpu index corresponding to a given MPIDR[23:0]
> + * - mpidr: MPIDR[23:0] to be used for the look-up
> + *
> + * Returns the cpu logical index or -EINVAL on look-up error
> + */
> +static inline int get_logical_index(u32 mpidr)
> +{
> + int cpu;
> + for (cpu = 0; cpu < nr_cpu_ids; cpu++)
> + if (cpu_logical_map(cpu) == mpidr)
> + return cpu;
> + return -EINVAL;
> +}
>
> #endif
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Russell King - ARM Linux @ 2012-11-06 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061610070.21033@xanadu.home>
On Tue, Nov 06, 2012 at 04:12:27PM -0500, Nicolas Pitre wrote:
>
> ... instead of flush_cache_all(). The later unconditionally flushes
> the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
> is costly and unnecessary in some scenarios where setup_mm_for_reboot()
> is used. If L2 has to be flushed as well, it should already be done
> separately on other architectures anyway.
Why does the cost at reboot count? It's a relatively slow operation as
it is anyway, because you have to wait for the system to shut down, call
the boot loader, etc.
However, the opposite argument is that the state of the L2 _shouldn't_
matter - except for one small little detail. Dirty data, which could
get evicted and overwrite something that matters. Generally there won't
be any dirty data in the L2 cache on normal boot, so this is a situation
which boot loaders probably don't expect.
So all in all, I'm not sure of the wiseness of your change. It's likely
to cause regressions.
^ permalink raw reply
* [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Tony Lindgren @ 2012-11-06 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211011216130.26661@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121101 05:18]:
> Hi Tony
>
> The following changes since commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33:
>
> Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm (2012-10-26 13:32:22 -0700)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b-for-3.8
>
> for you to fetch changes up to f17d60d20eb8e679cdd1e9d507394237e58ce0d8:
Tried pulling but..
> These patches remove the use of omap_prcm_get_reset_sources() from the
> OMAP watchdog driver, and remove mach-omap2/prcm.c and
> plat-omap/include/plat/prcm.h.
>
> Basic test logs for this branch on top of Tony's cleanup-prcm branch
> at commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33 are here:
>
> http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/
>
> However, cleanup-prcm at 7fc54fd3 does not build for several
> Kconfigs here and doesn't include some fixes that are needed for
> a successful test. With several reverts, fixes, and workarounds
> applied, the following test logs were obtained:
..now wondering which configs do not build for you at 7fc54fd3?
It builds at least all my test configs. Well at least the ones
I have recovered after accidentally deleting some files yesterday,
did not have a back up copy of two of them.
However if I pull your branch in, build breaks for me for
with the rmk-omap3430-ldp-noconfig and rmk-omap4430-sdp-noconfig:
arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x48): undefined reference to `omap44xx_restart'
Regards,
Tony
^ permalink raw reply
* [GIT PULL] Calxeda ECX-2000 support
From: Arnd Bergmann @ 2012-11-06 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50996725.2090003@gmail.com>
On Tuesday 06 November 2012, Rob Herring wrote:
> On 11/06/2012 01:18 PM, Olof Johansson wrote:
> > The addition of include of core.h in sysregs.h gives me a build error on
> > multi_v7_defconfig due to missing guard ifdefs. I've added the following
> > patch on top of your branch.
> >
> Thanks, I didn't see that in my tree because I have follow-on patches
> removing this based on the DEBUG_LL clean-up. Now that the dependency
> from Stephen is in your tree, I need to send that to you as well.
>
I've just added another patch on top to get around a build warning:
>From 5bd09fb0336aa4020b85f13e16a4d21e3f5f70c3 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 6 Nov 2012 23:02:27 +0100
Subject: [PATCH] ARM: smp_twd: fix build warning
0336517b38c "ARM: smp_twd: don't warn on no DT node" introduced
a silly build warning by returning an error from a void function.
This keeps the intention of that patch but fixes the warning by
removing the error code
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 6ec73f9..999aa48 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -367,7 +367,7 @@ void __init twd_local_timer_of_register(void)
np = of_find_matching_node(NULL, twd_of_match);
if (!np)
- return -ENODEV;
+ return;
twd_ppi = irq_of_parse_and_map(np, 0);
if (!twd_ppi) {
^ permalink raw reply related
* [PATCH 00/16] mm: use augmented rbtrees for finding unmapped areas
From: Andrew Morton @ 2012-11-06 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-1-git-send-email-walken@google.com>
On Mon, 5 Nov 2012 14:46:57 -0800
Michel Lespinasse <walken@google.com> wrote:
> Earlier this year, Rik proposed using augmented rbtrees to optimize
> our search for a suitable unmapped area during mmap(). This prompted
> my work on improving the augmented rbtree code. Rik doesn't seem to
> have time to follow up on his idea at this time, so I'm sending this
> series to revive the idea.
Well, the key word here is "optimize". Some quantitative testing
results would be nice, please!
People do occasionally see nasty meltdowns in the get_unmapped_area()
vicinity. There was one case 2-3 years ago which was just ghastly, but
I can't find the email (it's on linux-mm somewhere). This one might be
another case:
http://lkml.indiana.edu/hypermail/linux/kernel/1101.1/00896.html
If you can demonstrate that this patchset fixes some of all of the bad
search complexity scenarios then that's quite a win?
> These changes are against v3.7-rc4. I have not converted all applicable
> architectuers yet, but we don't necessarily need to get them all onboard
> at once - the series is fully bisectable and additional architectures
> can be added later on. I am confident enough in my tests for patches 1-8;
> however the second half of the series basically didn't get tested as
> I don't have access to all the relevant architectures.
Yes, I'll try to get these into -next so that the thousand monkeys at
least give us some compilation coverage testing. Hopefully the
relevant arch maintainers will find time to perform a runtime test.
> Patch 1 is the validate_mm() fix from Bob Liu (+ fixed-the-fix from me :)
I grabbed this one separately, as a post-3.6 fix.
^ permalink raw reply
* [PATCH 5/8] mmc: dw_mmc: fix modular build for exynos back-end
From: Chris Ball @ 2012-11-06 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-6-git-send-email-arnd@arndb.de>
Hi Arnd,
On Tue, Nov 06 2012, Arnd Bergmann wrote:
> The MODULE_DEVICE_TABLE entry for dw_mci_exynos_match
> was incorrectly copied from the platform back-end, which
> causes this error when building the driver as a loadable
> module:
>
> drivers/mmc/host/dw_mmc-exynos.c: At top level:
> drivers/mmc/host/dw_mmc-exynos.c:226:34: error: '__mod_of_device_table' aliased to undefined symbol 'dw_mci_pltfm_match'
>
> This patch fixes the problem by just using the correct
> string.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Will Newton <will.newton@imgtec.com>
> Cc: Chris Ball <cjb@laptop.org>
> ---
> drivers/mmc/host/dw_mmc-exynos.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
> index 660bbc5..0147ac3a 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -223,7 +223,7 @@ static const struct of_device_id dw_mci_exynos_match[] = {
> .data = (void *)&exynos5250_drv_data, },
> {},
> };
> -MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
> +MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
>
> int dw_mci_exynos_probe(struct platform_device *pdev)
> {
Thanks, pushed to mmc-next for 3.7.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Russell King - ARM Linux @ 2012-11-06 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211062114.49933.arnd@arndb.de>
On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote:
> The other point is being able to build such a kernel, and this is what Will
> seems to be interested in more. We have made VEXPRESS depend on
> MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel,
> and I think we should fix that. The two options are either to make
> vexpress be single-platform when building for !MMU, or to allow multiplatform
> kernels to be built without MMU support in principle. I think the second
> option is more logical and avoids complex Kconfig constructs.
The other thing here is... why does a platform which _was_ able to be
built in isolation from every other platform suddenly become incapable
of being so when they join the multiplatform conglomerate? This just
sounds totally perverse and wrong.
Surely it should be: platforms _not_ yet converted to multiplatform
can't be selected with multi-platform support enabled?
So, maybe the _proper_ solution here is:
- change the big choice to be: config SINGLE_xxx
- these select config MACH_FOO / PLAT_FOO / ARCH_FOO
eg,
config SINGLE_FOO
bool "Support for foo platforms in single kernel"
select MACH_FOO
- add a final option: config MULTIPLATFORM
- then add:
config MULTI_FOO
bool "Include support for foo platforms"
select MACH_FOO
depends on MULTIPLATFORM || !MMU
...
config MACH_FOO
bool
Now, we don't _have_ to have the single and multi variants if they aren't
appropriate for the platform, but we can cover all the cases: a platform
where it's part of the multi-platform kernel when built for MMU, but is
incapable of being a multi-platform kernel when built without MMU.
And we can do it without _too_ much Kconfig pain, and certainly without
having to delve into anything beyond arch/arm/Kconfig.
I'd suggest at that point we separate out this stuff into a separate
file - arch/arm/Kconfig.mach, which contains all the platform selection
stuff.
^ permalink raw reply
* [PATCH 6/8] mmc: dw_mmc: constify dw_mci_idmac_ops in exynos back-end
From: Chris Ball @ 2012-11-06 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-7-git-send-email-arnd@arndb.de>
Hi Arnd,
On Tue, Nov 06 2012, Arnd Bergmann wrote:
> The of_device_id match data is now marked as const and
> must not be modified. This changes the dw_mmc to mark
> all pointers passing the dw_mci_drv_data or dw_mci_dma_ops
> structures as const, and also marks the static definitions
> as const.
>
> drivers/mmc/host/dw_mmc-exynos.c: In function 'dw_mci_exynos_probe':
> drivers/mmc/host/dw_mmc-exynos.c:234:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Will Newton <will.newton@imgtec.com>
> Cc: Chris Ball <cjb@laptop.org>
Thanks, pushed to mmc-next for 3.7.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [RFC PATCH 4/4] ARM: gic: use a private mapping for CPU target interfaces
From: Will Deacon @ 2012-11-06 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-5-git-send-email-lorenzo.pieralisi@arm.com>
On Tue, Oct 16, 2012 at 02:21:48PM +0100, Lorenzo Pieralisi wrote:
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> The GIC interface numbering does not necessarily follow the logical
> CPU numbering, especially for complex topologies such as multi-cluster
> systems.
>
> Fortunately we can easily probe the GIC to create a mapping as the
> Interrupt Processor Targets Registers for the first 32 interrupts are
> read-only, and each field returns a value that always corresponds to
> the processor reading the register.
>
> Initially all mappings target all CPUs in case an IPI is required to
> boot secondary CPUs. It is refined as those CPUs discover what their
> actual mapping is.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
This is a really neat idea!
> ---
> arch/arm/common/gic.c | 42 ++++++++++++++++++++++++++++++++++--------
> 1 file changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index aa52699..1338a55 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -70,6 +70,13 @@ struct gic_chip_data {
> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>
> /*
> + * The GIC mapping of CPU interfaces does not necessarily match
> + * the logical CPU numbering. Let's use a mapping as returned
> + * by the GIC itself.
> + */
> +static u8 gic_cpu_map[8] __read_mostly;
Can we have a #define for the number CPUs supported by the GIC? It gets
used a fair amount in this patch for loop bounds etc.
> +/*
> * Supported arch specific GIC irq extension.
> * Default make them NULL.
> */
> @@ -242,7 +249,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> return -EINVAL;
>
> mask = 0xff << shift;
> - bit = 1 << (cpu_logical_map(cpu) + shift);
> + bit = gic_cpu_map[cpu] << shift;
>
> raw_spin_lock(&irq_controller_lock);
> val = readl_relaxed(reg) & ~mask;
> @@ -349,11 +356,6 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
> u32 cpumask;
> unsigned int gic_irqs = gic->gic_irqs;
> void __iomem *base = gic_data_dist_base(gic);
> - u32 cpu = cpu_logical_map(smp_processor_id());
> -
> - cpumask = 1 << cpu;
> - cpumask |= cpumask << 8;
> - cpumask |= cpumask << 16;
>
> writel_relaxed(0, base + GIC_DIST_CTRL);
>
> @@ -366,6 +368,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
> /*
> * Set all global interrupts to this CPU only.
> */
> + cpumask = readl_relaxed(base + GIC_DIST_TARGET + 0);
> for (i = 32; i < gic_irqs; i += 4)
> writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
>
> @@ -389,9 +392,25 @@ static void __cpuinit gic_cpu_init(struct gic_chip_data *gic)
> {
> void __iomem *dist_base = gic_data_dist_base(gic);
> void __iomem *base = gic_data_cpu_base(gic);
> + unsigned int cpu_mask, cpu = smp_processor_id();
> int i;
>
> /*
> + * Get what the GIC says our CPU mask is.
> + */
> + BUG_ON(cpu >= 8);
> + cpu_mask = readl_relaxed(dist_base + GIC_DIST_TARGET + 0);
Making the mask a u8 and using readb_relaxed here makes this bit of code
clearer to me (and the GIC apparently allows such an access to this
register).
> + gic_cpu_map[cpu] = cpu_mask;
> +
> + /*
> + * Clear our mask from the other map entries in case they're
> + * still undefined.
> + */
> + for (i = 0; i < 8; i++)
> + if (i != cpu)
> + gic_cpu_map[i] &= ~cpu_mask;
> +
> + /*
> * Deal with the banked PPI and SGI interrupts - disable all
> * PPI interrupts, ensure all SGI interrupts are enabled.
> */
> @@ -646,7 +665,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
> {
> irq_hw_number_t hwirq_base;
> struct gic_chip_data *gic;
> - int gic_irqs, irq_base;
> + int gic_irqs, irq_base, i;
>
> BUG_ON(gic_nr >= MAX_GIC_NR);
>
> @@ -683,6 +702,13 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
> }
>
> /*
> + * Initialize the CPU interface map to all CPUs.
> + * It will be refined as each CPU probes its ID.
> + */
> + for (i = 0; i < 8; i++)
> + gic_cpu_map[i] = 0xff;
> +
> + /*
> * For primary GICs, skip over SGIs.
> * For secondary GICs, skip over PPIs, too.
> */
> @@ -737,7 +763,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>
> /* Convert our logical CPU mask into a physical one. */
> for_each_cpu(cpu, mask)
> - map |= 1 << cpu_logical_map(cpu);
> + map |= gic_cpu_map[cpu];
>
> /*
> * Ensure that stores to Normal memory are visible to the
With those changes:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
From: Samuel Ortiz @ 2012-11-06 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CXtOT7pi6hOOwYxxthTfDZYcYe5QFTnGR=L_S82NM_Lg@mail.gmail.com>
Hi Fabio,
On Sat, Oct 27, 2012 at 05:19:11PM -0200, Fabio Estevam wrote:
> Hi Samuel,
>
> On Thu, Oct 4, 2012 at 10:51 AM, Samuel Ortiz <samuel.ortiz@intel.com> wrote:
>
> >> I want to add mc34708 support to mx53qsb and need this series to be applied.
> > I understand. I'll queue it to my for-next branch as soon as the merge window
> > is closed.
>
> Could you please queue this series? I still do not see it applied in
> your 'for-next-merge' branch.
Patches 6 and 7 were not applied from this serie. I now applied them to my
for-next branch.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* scheduler clock for MXS
From: Stanislav Meduna @ 2012-11-06 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106202038.GB32398@n2100.arm.linux.org.uk>
On 06.11.2012 21:20, Russell King - ARM Linux wrote:
>> With the change, it still wraps at 2 seconds.
>
> And there's no way that such a change could ever go into mainline; it
> can mean that the timer is registered into the timer subsystem before
> the timer subsystem has been initialised. That's why we postpone that
> part to time_init().
Sure, I just wanted to quick-check whether it helps or not, this was
not meant as a solution for anything.
This gets interesting. The same code on slightly different hardware
(but using same source files), just 32-bits so it wraps around after
~1,5 days:
sched_clock: 32 bits at 32kHz, resolution 31250ns,
wraps every 134217727ms
works without problem here:
[134919.008468] PHY: imx28-fec-1:00 - Link is Up - 100/Full
(134919 > 134217).
The only difference is 32 bits instead of 16 and a different
function to read the hardware.
> Well. I just tried an experiment with OMAP4:
> [ 0.000000] sched_clock: 16 bits at 32kHz, resolution 30517ns,
wraps every 1999ms
> ...
> [ 3.070404] Freeing init memory: 192K
OK, so it is not a 16-bit problem either. So where is the
difference? Could it be that HZ / NO_HZ is playing some
tricks here and need to be taken into consideration?
I'll try to artificially limit the counter-reading function
on my hardware to 16 bits and look whether I can also
reproduce this - probably on Thursday or Friday earliest
(busy with other tasks now).
If it works I'll resubmit for only the iMX.28 and someone
who actually has the iMX.23 hardware to experiment with has
to look at it; the best start is probably to start with
comparing it to the working OMAP4. If it does not I'll
try to find the culprit.
Thanks
--
Stano
^ permalink raw reply
* [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Andrew Lunn @ 2012-11-06 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5099810D.9040902@web.de>
On Tue, Nov 06, 2012 at 10:28:45PM +0100, S?ren Moch wrote:
> resent as plain text, sorry.
>
>
> > For Armada 370/XP we have the same problem that for the commit
> > cb01b63, so we applied the same solution: "The default 256 KiB
> > coherent pool may be too small for some of the Kirkwood devices, so
> > increase it to make sure that devices will be able to allocate their
> > buffers with GFP_ATOMIC flag"
>
> I see a regression from linux-3.5 to linux-3.6 and think there might
> be a fundamental problem
> with this patch. On my Kirkwood system (guruplug server plus) with
> linux-3.6.2 I see following
> errors and corresponding malfunction even with further increased
> (2M, 4M) pool size:
>
> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
> pool is too small!
> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
> kernel parameter!
>
> So I had to downgrade to linux-3.5 which is running without problems.
>
> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
I'm guess its the DVB sticks which are causing the problems. We have a
number of kirkwood devices with two SATA devices which had problems
until we extended the coherent_pool. The DVB sticks are probably take
more coherent RAM. There was also an issue found recently:
http://www.spinics.net/lists/arm-kernel/msg203962.html
That conversation has gone quiet, but that could be because the
participants are at ELCE.
Andrew
^ permalink raw reply
* [PATCH 03/16] mm: check rb_subtree_gap correctness
From: Andrew Morton @ 2012-11-06 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-4-git-send-email-walken@google.com>
On Mon, 5 Nov 2012 14:47:00 -0800
Michel Lespinasse <walken@google.com> wrote:
> When CONFIG_DEBUG_VM_RB is enabled, check that rb_subtree_gap is
> correctly set for every vma and that mm->highest_vm_end is also correct.
>
> Also add an explicit 'bug' variable to track if browse_rb() detected any
> invalid condition.
>
> ...
>
> @@ -365,7 +365,7 @@ static void vma_rb_erase(struct vm_area_struct *vma, struct rb_root *root)
> #ifdef CONFIG_DEBUG_VM_RB
> static int browse_rb(struct rb_root *root)
> {
> - int i = 0, j;
> + int i = 0, j, bug = 0;
> struct rb_node *nd, *pn = NULL;
> unsigned long prev = 0, pend = 0;
>
> @@ -373,29 +373,33 @@ static int browse_rb(struct rb_root *root)
> struct vm_area_struct *vma;
> vma = rb_entry(nd, struct vm_area_struct, vm_rb);
> if (vma->vm_start < prev)
> - printk("vm_start %lx prev %lx\n", vma->vm_start, prev), i = -1;
> + printk("vm_start %lx prev %lx\n", vma->vm_start, prev), bug = 1;
> if (vma->vm_start < pend)
> - printk("vm_start %lx pend %lx\n", vma->vm_start, pend);
> + printk("vm_start %lx pend %lx\n", vma->vm_start, pend), bug = 1;
> if (vma->vm_start > vma->vm_end)
> - printk("vm_end %lx < vm_start %lx\n", vma->vm_end, vma->vm_start);
> + printk("vm_end %lx < vm_start %lx\n", vma->vm_end, vma->vm_start), bug = 1;
> + if (vma->rb_subtree_gap != vma_compute_subtree_gap(vma))
> + printk("free gap %lx, correct %lx\n",
> + vma->rb_subtree_gap,
> + vma_compute_subtree_gap(vma)), bug = 1;
OK, now who did that. Whoever it was: stop it or you'll have your
kernel license revoked!
--- a/mm/mmap.c~mm-check-rb_subtree_gap-correctness-fix
+++ a/mm/mmap.c
@@ -372,16 +372,25 @@ static int browse_rb(struct rb_root *roo
for (nd = rb_first(root); nd; nd = rb_next(nd)) {
struct vm_area_struct *vma;
vma = rb_entry(nd, struct vm_area_struct, vm_rb);
- if (vma->vm_start < prev)
- printk("vm_start %lx prev %lx\n", vma->vm_start, prev), bug = 1;
- if (vma->vm_start < pend)
- printk("vm_start %lx pend %lx\n", vma->vm_start, pend), bug = 1;
- if (vma->vm_start > vma->vm_end)
- printk("vm_end %lx < vm_start %lx\n", vma->vm_end, vma->vm_start), bug = 1;
- if (vma->rb_subtree_gap != vma_compute_subtree_gap(vma))
+ if (vma->vm_start < prev) {
+ printk("vm_start %lx prev %lx\n", vma->vm_start, prev);
+ bug = 1;
+ }
+ if (vma->vm_start < pend) {
+ printk("vm_start %lx pend %lx\n", vma->vm_start, pend);
+ bug = 1;
+ }
+ if (vma->vm_start > vma->vm_end) {
+ printk("vm_end %lx < vm_start %lx\n",
+ vma->vm_end, vma->vm_start);
+ bug = 1;
+ }
+ if (vma->rb_subtree_gap != vma_compute_subtree_gap(vma)) {
printk("free gap %lx, correct %lx\n",
vma->rb_subtree_gap,
- vma_compute_subtree_gap(vma)), bug = 1;
+ vma_compute_subtree_gap(vma));
+ bug = 1;
+ }
i++;
pn = nd;
prev = vma->vm_start;
@@ -390,8 +399,10 @@ static int browse_rb(struct rb_root *roo
j = 0;
for (nd = pn; nd; nd = rb_prev(nd))
j++;
- if (i != j)
- printk("backwards %d, forwards %d\n", j, i), bug = 1;
+ if (i != j) {
+ printk("backwards %d, forwards %d\n", j, i);
+ bug = 1;
+ }
return bug ? -1 : i;
}
@@ -411,14 +422,20 @@ void validate_mm(struct mm_struct *mm)
vma = vma->vm_next;
i++;
}
- if (i != mm->map_count)
- printk("map_count %d vm_next %d\n", mm->map_count, i), bug = 1;
- if (highest_address != mm->highest_vm_end)
+ if (i != mm->map_count) {
+ printk("map_count %d vm_next %d\n", mm->map_count, i);
+ bug = 1;
+ }
+ if (highest_address != mm->highest_vm_end) {
printk("mm->highest_vm_end %lx, found %lx\n",
- mm->highest_vm_end, highest_address), bug = 1;
+ mm->highest_vm_end, highest_address);
+ bug = 1;
+ }
i = browse_rb(&mm->mm_rb);
- if (i != mm->map_count)
- printk("map_count %d rb %d\n", mm->map_count, i), bug = 1;
+ if (i != mm->map_count) {
+ printk("map_count %d rb %d\n", mm->map_count, i);
+ bug = 1;
+ }
BUG_ON(bug);
}
#else
^ permalink raw reply
* [PATCH 07/16] mm: fix cache coloring on x86_64 architecture
From: Andrew Morton @ 2012-11-06 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-8-git-send-email-walken@google.com>
On Mon, 5 Nov 2012 14:47:04 -0800
Michel Lespinasse <walken@google.com> wrote:
> Fix the x86-64 cache alignment code to take pgoff into account.
> Use the x86 and MIPS cache alignment code as the basis for a generic
> cache alignment function.
>
> The old x86 code will always align the mmap to aliasing boundaries,
> even if the program mmaps the file with a non-zero pgoff.
>
> If program A mmaps the file with pgoff 0, and program B mmaps the
> file with pgoff 1. The old code would align the mmaps, resulting in
> misaligned pages:
>
> A: 0123
> B: 123
>
> After this patch, they are aligned so the pages line up:
>
> A: 0123
> B: 123
We have a bit of a history of fiddling with coloring and finding that
the changes made at best no improvement. Or at least, that's my
perhaps faulty memory of it.
This one needs pretty careful testing, please.
^ permalink raw reply
* [PATCH 09/16] mm: use vm_unmapped_area() in hugetlbfs on i386 architecture
From: Andrew Morton @ 2012-11-06 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-10-git-send-email-walken@google.com>
On Mon, 5 Nov 2012 14:47:06 -0800
Michel Lespinasse <walken@google.com> wrote:
> Update the i386 hugetlb_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
The x86_64 coloring "fix" wasn't copied into i386?
^ permalink raw reply
* [PATCH 10/16] mm: use vm_unmapped_area() on mips architecture
From: Andrew Morton @ 2012-11-06 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-11-git-send-email-walken@google.com>
On Mon, 5 Nov 2012 14:47:07 -0800
Michel Lespinasse <walken@google.com> wrote:
> Update the mips arch_get_unmapped_area[_topdown] functions to make
> use of vm_unmapped_area() instead of implementing a brute force search.
>
Are the changes to the coloring equivalent to what was there before?
It's unobvious..
COLOUR_ALIGN_DOWN() is now unused and should be removed?
^ permalink raw reply
* [PATCH 11/16] mm: use vm_unmapped_area() on arm architecture
From: Andrew Morton @ 2012-11-06 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-12-git-send-email-walken@google.com>
On Mon, 5 Nov 2012 14:47:08 -0800
Michel Lespinasse <walken@google.com> wrote:
> Update the arm arch_get_unmapped_area[_topdown] functions to make
> use of vm_unmapped_area() instead of implementing a brute force search.
Again,
--- a/arch/arm/mm/mmap.c~mm-use-vm_unmapped_area-on-arm-architecture-fix
+++ a/arch/arm/mm/mmap.c
@@ -11,18 +11,6 @@
#include <linux/random.h>
#include <asm/cachetype.h>
-static inline unsigned long COLOUR_ALIGN_DOWN(unsigned long addr,
- unsigned long pgoff)
-{
- unsigned long base = addr & ~(SHMLBA-1);
- unsigned long off = (pgoff << PAGE_SHIFT) & (SHMLBA-1);
-
- if (base + off <= addr)
- return base + off;
-
- return base - off;
-}
-
#define COLOUR_ALIGN(addr,pgoff) \
((((addr)+SHMLBA-1)&~(SHMLBA-1)) + \
(((pgoff)<<PAGE_SHIFT) & (SHMLBA-1)))
_
^ permalink raw reply
* scheduler clock for MXS
From: Russell King - ARM Linux @ 2012-11-06 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50998F94.8000908@meduna.org>
On Tue, Nov 06, 2012 at 11:30:44PM +0100, Stanislav Meduna wrote:
> On 06.11.2012 21:20, Russell King - ARM Linux wrote:
> > Well. I just tried an experiment with OMAP4:
> > [ 0.000000] sched_clock: 16 bits at 32kHz, resolution 30517ns,
> wraps every 1999ms
> > ...
> > [ 3.070404] Freeing init memory: 192K
>
>
> OK, so it is not a 16-bit problem either. So where is the
> difference? Could it be that HZ / NO_HZ is playing some
> tricks here and need to be taken into consideration?
>
> I'll try to artificially limit the counter-reading function
> on my hardware to 16 bits and look whether I can also
> reproduce this - probably on Thursday or Friday earliest
> (busy with other tasks now).
>
> If it works I'll resubmit for only the iMX.28 and someone
> who actually has the iMX.23 hardware to experiment with has
> to look at it; the best start is probably to start with
> comparing it to the working OMAP4. If it does not I'll
> try to find the culprit.
I wonder if the NO_HZ slack is preventing the sched_clock epoch update
from happening in time. Hmm.
* round_jiffies - function to round jiffies to a full second
This is probably it. With mine, it's a 32.768kHz clock, so limiting
it to 16-bit gives a wrap period of 2 seconds exactly. We take 10%
off, so the timer would be asked to fire every 1.8s, which would be
rounded up to 2 seconds. That's a little too close for comfort...
Yours on the other hand:
sched_clock: 16 bits at 32kHz, resolution 31250ns, wraps every 2047ms
says that this timer runs at _exactly_ 32kHz (are you sure? If this is
generated from a separate 32k crystal oscilator, it's most likely
32.768kHz because that's the standard crystal frequency. In any case,
this would give a wrap period of just over 2 seconds.
But remember, we take of 10%, so this would give 1843ms. Jiffy
conversion would give 185 jiffies, and rounded up to a second gives
200 jiffies, so again 2 seconds.
I suspect that your timer _does_ run at approximately 32768kHz, meaning
that it _does_ roll over at 2 second intervals. But maybe it's trimmed
to be slightly fast or maybe your kernel's idea of time is slightly
slow - either one of which would then give you this effect.
However, either way, rounding 1.8s up to 2s for a 16-bit 32768kHz
counter isn't going to give reliable results.
I think in this case, we need a version of round_jiffies() which _always_
rounds down. Unfortunately, it doesn't exist. Thomas? What are the
options here?
^ permalink raw reply
* [PATCH 09/16] mm: use vm_unmapped_area() in hugetlbfs on i386 architecture
From: Rik van Riel @ 2012-11-06 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106143826.dc3b960c.akpm@linux-foundation.org>
On 11/06/2012 05:38 PM, Andrew Morton wrote:
> On Mon, 5 Nov 2012 14:47:06 -0800
> Michel Lespinasse <walken@google.com> wrote:
>
>> Update the i386 hugetlb_get_unmapped_area function to make use of
>> vm_unmapped_area() instead of implementing a brute force search.
>
> The x86_64 coloring "fix" wasn't copied into i386?
Only certain 64 bit AMD CPUs have that issue at all.
On x86, page coloring is really not much of an issue.
All the x86-64 patch does is make the x86-64 page
coloring code behave the same way page coloring
does on MIPS, SPARC, ARM, PA-RISC and others...
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Jamie Lokier @ 2012-11-06 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061533490.21033@xanadu.home>
Nicolas Pitre wrote:
> I really think that it makes no sense at all to support !MMU kernels in
> a multi-platform kernel build, even if the set of included platforms
> were all !MMU. The kernel has to be linked for the physical address of
> the target and not a common invariant virtual address.
Although there's likely to be approximately zero interest in
multi-platform !MMU, relocating at boot time doesn't sound onerous,
should it be needed. x86 kernels already do that. Maybe ARM kernels
will eventually do that anyway for the same reason as x86.
-- Jamie
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Nicolas Pitre @ 2012-11-06 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106220458.GP28327@n2100.arm.linux.org.uk>
On Tue, 6 Nov 2012, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 04:12:27PM -0500, Nicolas Pitre wrote:
> >
> > ... instead of flush_cache_all(). The later unconditionally flushes
> > the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
> > is costly and unnecessary in some scenarios where setup_mm_for_reboot()
> > is used. If L2 has to be flushed as well, it should already be done
> > separately on other architectures anyway.
>
> Why does the cost at reboot count? It's a relatively slow operation as
> it is anyway, because you have to wait for the system to shut down, call
> the boot loader, etc.
Because I have a use case with the big.LITTLE switcher where the full
boot is bypassed but the kernel must be reintered as if the CPU was
powered up. This is of course something that _could_ happen multiple
times in a second, and therefore minimizing its unneeded costs is a good
thing(tm).
> However, the opposite argument is that the state of the L2 _shouldn't_
> matter - except for one small little detail. Dirty data, which could
> get evicted and overwrite something that matters. Generally there won't
> be any dirty data in the L2 cache on normal boot, so this is a situation
> which boot loaders probably don't expect.
In the use case that concerns me, L2 is retained and I'd well prefer if
it didn't get flushed at all.
> So all in all, I'm not sure of the wiseness of your change. It's likely
> to cause regressions.
Could you please tell me if you have such a regression in mind? Of
course I could carry the few operations performed by
setup_mm_for_reboot() locally, but that looks like useless code
duplication.
Nicolas
^ permalink raw reply
* [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Sebastian Hesselbarth @ 2012-11-06 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106223257.GB30428@lunn.ch>
On 11/06/2012 11:32 PM, Andrew Lunn wrote:
> On Tue, Nov 06, 2012 at 10:28:45PM +0100, S?ren Moch wrote:
>> I see a regression from linux-3.5 to linux-3.6 and think there might
>> be a fundamental problem
>> with this patch. On my Kirkwood system (guruplug server plus) with
>> linux-3.6.2 I see following
>> errors and corresponding malfunction even with further increased
>> (2M, 4M) pool size:
>>
>> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
>> pool is too small!
>> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
>> kernel parameter!
>>
>> So I had to downgrade to linux-3.5 which is running without problems.
>>
>> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
>
> I'm guess its the DVB sticks which are causing the problems. We have a
> number of kirkwood devices with two SATA devices which had problems
> until we extended the coherent_pool. The DVB sticks are probably take
> more coherent RAM. There was also an issue found recently:
>
> http://www.spinics.net/lists/arm-kernel/msg203962.html
>
> That conversation has gone quiet, but that could be because the
> participants are at ELCE.
So what is the call here? Should we just increase the coherent buffer
size back to what it was before? I am not into this too much but just
increasing the buffer will just postpone the actual issue to a later
point in running the kernel?
Sebastian
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Rob Herring @ 2012-11-06 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106221437.GQ28327@n2100.arm.linux.org.uk>
On 11/06/2012 04:14 PM, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote:
>> The other point is being able to build such a kernel, and this is what Will
>> seems to be interested in more. We have made VEXPRESS depend on
>> MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel,
>> and I think we should fix that. The two options are either to make
>> vexpress be single-platform when building for !MMU, or to allow multiplatform
>> kernels to be built without MMU support in principle. I think the second
>> option is more logical and avoids complex Kconfig constructs.
>
> The other thing here is... why does a platform which _was_ able to be
> built in isolation from every other platform suddenly become incapable
> of being so when they join the multiplatform conglomerate? This just
> sounds totally perverse and wrong.
Arnd and I discussed this some at Connect regarding VExpress being
selected. This is only to prevent the warning that no machine is enabled
in a randconfig or user error case. We could simply remove this error or
make it a warning instead. Then selecting a single platform is a matter
of only selecting 1 platform.
> Surely it should be: platforms _not_ yet converted to multiplatform
> can't be selected with multi-platform support enabled?
>
> So, maybe the _proper_ solution here is:
>
> - change the big choice to be: config SINGLE_xxx
> - these select config MACH_FOO / PLAT_FOO / ARCH_FOO
> eg,
> config SINGLE_FOO
> bool "Support for foo platforms in single kernel"
> select MACH_FOO
> - add a final option: config MULTIPLATFORM
> - then add:
>
> config MULTI_FOO
> bool "Include support for foo platforms"
> select MACH_FOO
> depends on MULTIPLATFORM || !MMU
> ...
>
> config MACH_FOO
> bool
>
I'd rather see less xxx_FOO config symbols rather than more.
Wouldn't this break defconfigs?
Rob
> Now, we don't _have_ to have the single and multi variants if they aren't
> appropriate for the platform, but we can cover all the cases: a platform
> where it's part of the multi-platform kernel when built for MMU, but is
> incapable of being a multi-platform kernel when built without MMU.
>
> And we can do it without _too_ much Kconfig pain, and certainly without
> having to delve into anything beyond arch/arm/Kconfig.
>
> I'd suggest at that point we separate out this stuff into a separate
> file - arch/arm/Kconfig.mach, which contains all the platform selection
> stuff.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox