* [PATCH 1/5] ARM: Kirkwood: Allow use of pinctrl
From: Thomas Petazzoni @ 2012-10-25 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-2-git-send-email-andrew@lunn.ch>
Dear Andrew Lunn,
On Wed, 24 Oct 2012 16:25:20 +0200, Andrew Lunn wrote:
> index 7bf914d..5682c96 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -188,7 +188,7 @@ config PINCTRL_EXYNOS4
>
> config PINCTRL_MVEBU
> bool
> - depends on ARCH_MVEBU
> + depends on ARCH_MVEBU || ARCH_KIRKWOOD
> select PINMUX
> select PINCONF
Linus Walleij has accepted a patch I have sent yesterday evening that
makes PINCTRL_MVEBU available for all PLAT_ORION platforms, so this
chunk is no longer needed.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Laurent Pinchart @ 2012-10-25 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025002056.2082.45221.stgit@muffinssi.local>
Hi Tony,
Thanks for the patch.
On Wednesday 24 October 2012 17:20:56 Tony Lindgren wrote:
> Looks like the iommu framework does not have generic functions
> exported for all the needs yet. The hardware specific functions
> are defined in files like intel-iommu.h and amd-iommu.h. Follow
> the same standard for omap-iommu.h.
>
> This is needed because we are removing plat and mach includes
> for ARM common zImage support. Further work should continue
> in the iommu framework context as only pure platform data will
> be communicated from arch/arm/*omap*/* code to the iommu
> framework.
>
> Cc: Joerg Roedel <joerg.roedel@amd.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Ido Yariv <ido@wizery.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Omar Ramirez Luna <omar.luna@linaro.org>
> Cc: linux-media at vger.kernel.org
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/iommu2.c | 1
> arch/arm/plat-omap/include/plat/iommu.h | 10 +--
> arch/arm/plat-omap/include/plat/iovmm.h | 89
> ---------------------------- drivers/iommu/omap-iommu-debug.c |
> 2 -
> drivers/iommu/omap-iommu.c | 1
> drivers/iommu/omap-iovmm.c | 46 ++++++++++++++
> drivers/media/platform/omap3isp/isp.c | 1
> drivers/media/platform/omap3isp/isp.h | 4 -
> drivers/media/platform/omap3isp/ispccdc.c | 1
> drivers/media/platform/omap3isp/ispstat.c | 1
> drivers/media/platform/omap3isp/ispvideo.c | 2 -
> include/linux/omap-iommu.h | 52 ++++++++++++++++
> 12 files changed, 107 insertions(+), 103 deletions(-)
> delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
> create mode 100644 include/linux/omap-iommu.h
>
> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
> index eefc379..e8116cf 100644
> --- a/arch/arm/mach-omap2/iommu2.c
> +++ b/arch/arm/mach-omap2/iommu2.c
> @@ -15,6 +15,7 @@
> #include <linux/device.h>
> #include <linux/jiffies.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/slab.h>
> #include <linux/stringify.h>
>
> diff --git a/arch/arm/plat-omap/include/plat/iommu.h
> b/arch/arm/plat-omap/include/plat/iommu.h index 7e8c7b6..a4b71b1 100644
> --- a/arch/arm/plat-omap/include/plat/iommu.h
> +++ b/arch/arm/plat-omap/include/plat/iommu.h
> @@ -216,13 +216,10 @@ static inline struct omap_iommu
> *dev_to_omap_iommu(struct device *dev) #define MMU_RAM_PADDR_SHIFT 12
> #define MMU_RAM_PADDR_MASK \
> ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
> -#define MMU_RAM_ENDIAN_SHIFT 9
> +
> #define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ELSZ_SHIFT 7
> #define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
> -#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
> +
> #define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
> #define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
> #define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
> @@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
> void *priv),
> void *isr_priv);
>
> -extern void omap_iommu_save_ctx(struct device *dev);
> -extern void omap_iommu_restore_ctx(struct device *dev);
> -
> extern int omap_install_iommu_arch(const struct iommu_functions *ops);
> extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
>
> diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
> b/arch/arm/plat-omap/include/plat/iovmm.h deleted file mode 100644
> index 498e57c..0000000
> --- a/arch/arm/plat-omap/include/plat/iovmm.h
> +++ /dev/null
> @@ -1,89 +0,0 @@
> -/*
> - * omap iommu: simple virtual address space management
> - *
> - * Copyright (C) 2008-2009 Nokia Corporation
> - *
> - * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#ifndef __IOMMU_MMAP_H
> -#define __IOMMU_MMAP_H
> -
> -#include <linux/iommu.h>
> -
> -struct iovm_struct {
> - struct omap_iommu *iommu; /* iommu object which this belongs to */
> - u32 da_start; /* area definition */
> - u32 da_end;
> - u32 flags; /* IOVMF_: see below */
> - struct list_head list; /* linked in ascending order */
> - const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
> - void *va; /* mpu side mapped address */
> -};
> -
> -/*
> - * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
> - *
> - * lower 16 bit is used for h/w and upper 16 bit is for s/w.
> - */
> -#define IOVMF_SW_SHIFT 16
> -
> -/*
> - * iovma: h/w flags derived from cam and ram attribute
> - */
> -#define IOVMF_CAM_MASK (~((1 << 10) - 1))
> -#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
> -
> -#define IOVMF_PGSZ_MASK (3 << 0)
> -#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
> -#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
> -#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
> -#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
> -
> -#define IOVMF_ENDIAN_MASK (1 << 9)
> -#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
> -#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
> -
> -#define IOVMF_ELSZ_MASK (3 << 7)
> -#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
> -#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
> -#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
> -#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
> -
> -#define IOVMF_MIXED_MASK (1 << 6)
> -#define IOVMF_MIXED MMU_RAM_MIXED
> -
> -/*
> - * iovma: s/w flags, used for mapping and umapping internally.
> - */
> -#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
> -#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
> -#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
> -
> -/* "superpages" is supported just with physically linear pages */
> -#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
> -#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
> -#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
> -
> -#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
> -
> -
> -extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
> -extern u32
> -omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
> - const struct sg_table *sgt, u32 flags);
> -extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
> - struct device *dev, u32 da);
> -extern u32
> -omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
> - u32 da, size_t bytes, u32 flags);
> -extern void
> -omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
> - const u32 da);
> -extern void *omap_da_to_va(struct device *dev, u32 da);
> -
> -#endif /* __IOMMU_MMAP_H */
> diff --git a/drivers/iommu/omap-iommu-debug.c
> b/drivers/iommu/omap-iommu-debug.c index 0cac372..cf4a0b5 100644
> --- a/drivers/iommu/omap-iommu-debug.c
> +++ b/drivers/iommu/omap-iommu-debug.c
> @@ -18,9 +18,9 @@
> #include <linux/uaccess.h>
> #include <linux/platform_device.h>
> #include <linux/debugfs.h>
> +#include <linux/omap-iommu.h>
>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "omap-iopgtable.h"
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index f2bbfb0..eadcfde 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -19,6 +19,7 @@
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> #include <linux/iommu.h>
> +#include <linux/omap-iommu.h>
> #include <linux/mutex.h>
> #include <linux/spinlock.h>
>
> diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
> index b332392..9852101 100644
> --- a/drivers/iommu/omap-iovmm.c
> +++ b/drivers/iommu/omap-iovmm.c
> @@ -17,15 +17,59 @@
> #include <linux/device.h>
> #include <linux/scatterlist.h>
> #include <linux/iommu.h>
> +#include <linux/omap-iommu.h>
>
> #include <asm/cacheflush.h>
> #include <asm/mach/map.h>
>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "omap-iopgtable.h"
>
> +/*
> + * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
> + *
> + * lower 16 bit is used for h/w and upper 16 bit is for s/w.
> + */
> +#define IOVMF_SW_SHIFT 16
> +
> +/*
> + * iovma: h/w flags derived from cam and ram attribute
> + */
> +#define IOVMF_CAM_MASK (~((1 << 10) - 1))
> +#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
> +
> +#define IOVMF_PGSZ_MASK (3 << 0)
> +#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
> +#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
> +#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
> +#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
> +
> +#define IOVMF_ENDIAN_MASK (1 << 9)
> +#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
> +
> +#define IOVMF_ELSZ_MASK (3 << 7)
> +#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
> +#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
> +#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
> +
> +#define IOVMF_MIXED_MASK (1 << 6)
> +#define IOVMF_MIXED MMU_RAM_MIXED
> +
> +/*
> + * iovma: s/w flags, used for mapping and umapping internally.
> + */
> +#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
> +#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
> +#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
> +
> +/* "superpages" is supported just with physically linear pages */
> +#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
> +#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
> +#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
> +
> +#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
> +
> static struct kmem_cache *iovm_area_cachep;
>
> /* return the offset of the first scatterlist entry in a sg table */
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 99640d8..7f182f0 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -61,6 +61,7 @@
> #include <linux/i2c.h>
> #include <linux/interrupt.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/platform_device.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 8be7487..8d68669 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -31,11 +31,9 @@
> #include <media/v4l2-device.h>
> #include <linux/device.h>
> #include <linux/io.h>
> +#include <linux/iommu.h>
> #include <linux/platform_device.h>
> #include <linux/wait.h>
> -#include <linux/iommu.h>
> -#include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "ispstat.h"
> #include "ispccdc.h"
> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> b/drivers/media/platform/omap3isp/ispccdc.c index 60181ab..6ae1ffb2 100644
> --- a/drivers/media/platform/omap3isp/ispccdc.c
> +++ b/drivers/media/platform/omap3isp/ispccdc.c
> @@ -30,6 +30,7 @@
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> #include <linux/mm.h>
> +#include <linux/omap-iommu.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> #include <media/v4l2-event.h>
> diff --git a/drivers/media/platform/omap3isp/ispstat.c
> b/drivers/media/platform/omap3isp/ispstat.c index d7ac76b..35c3823 100644
> --- a/drivers/media/platform/omap3isp/ispstat.c
> +++ b/drivers/media/platform/omap3isp/ispstat.c
> @@ -26,6 +26,7 @@
> */
>
> #include <linux/dma-mapping.h>
> +#include <linux/omap-iommu.h>
> #include <linux/slab.h>
> #include <linux/uaccess.h>
>
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index a0b737fe..a4b8290 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -27,6 +27,7 @@
> #include <linux/clk.h>
> #include <linux/mm.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/pagemap.h>
> #include <linux/scatterlist.h>
> #include <linux/sched.h>
> @@ -35,7 +36,6 @@
> #include <media/v4l2-dev.h>
> #include <media/v4l2-ioctl.h>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
> #include <plat/omap-pm.h>
>
> #include "ispvideo.h"
> diff --git a/include/linux/omap-iommu.h b/include/linux/omap-iommu.h
> new file mode 100644
> index 0000000..cac78de
> --- /dev/null
> +++ b/include/linux/omap-iommu.h
> @@ -0,0 +1,52 @@
> +/*
> + * omap iommu: simple virtual address space management
> + *
> + * Copyright (C) 2008-2009 Nokia Corporation
> + *
> + * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _INTEL_IOMMU_H_
> +#define _INTEL_IOMMU_H_
> +
> +struct iovm_struct {
> + struct omap_iommu *iommu; /* iommu object which this belongs to */
> + u32 da_start; /* area definition */
> + u32 da_end;
> + u32 flags; /* IOVMF_: see below */
> + struct list_head list; /* linked in ascending order */
> + const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
> + void *va; /* mpu side mapped address */
> +};
> +
> +#define MMU_RAM_ENDIAN_SHIFT 9
> +#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
> +#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
> +#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
> +#define MMU_RAM_ELSZ_SHIFT 7
> +#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
> +
> +struct iommu_domain;
> +
> +extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
> +extern u32
> +omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
> + const struct sg_table *sgt, u32 flags);
> +extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
> + struct device *dev, u32 da);
> +extern u32
> +omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
> + u32 da, size_t bytes, u32 flags);
> +extern void
> +omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
> + const u32 da);
> +extern void *omap_da_to_va(struct device *dev, u32 da);
> +
> +extern void omap_iommu_save_ctx(struct device *dev);
> +extern void omap_iommu_restore_ctx(struct device *dev);
> +
> +#endif
I still think you should split this in two files, omap-iommu.h and omap-
iovmm.h. The later would just be arch/arm/plat-omap/include/plat/iovmm.h moved
to include/linux.h.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 2/2] input: gpio-keys: Add runtime support
From: Dmitry Torokhov @ 2012-10-25 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025082145.GB3348@gmail.com>
On Thu, Oct 25, 2012 at 09:21:45AM +0100, Lee Jones wrote:
> On Thu, 25 Oct 2012, Linus Walleij wrote:
>
> > On Thu, Oct 25, 2012 at 9:57 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > On Fri, 12 Oct 2012, Linus Walleij wrote:
> >
> > >> Yours,
> > >> Linus Walleij
> > >
> > > Friendly poke.
> >
> > This makes it look like you're poking me as I'm in the To: field but I suspect
> > the intent must be to poke Dmitry ... I was just providing background
> > for Shubhrajyoti's question.
> >
> > Maybe this helps:
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yes, that was also the intention of the other poke. Sorry about
> that, I should have moved you into Cc: instead.
>
> Yes, the poke was for Dmitry.
Still do not have the right signoffs: person who sends me the patch needs
to put signed-off-by, not acked-by.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 2/6] pinctrl: Update clock handling for the pinctrl-nomadik GPIO driver
From: Lee Jones @ 2012-10-25 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5088F0EE.8030900@stericsson.com>
On Thu, 25 Oct 2012, Linus Walleij wrote:
> On 10/25/2012 09:31 AM, Lee Jones wrote:
> >
> >This certainly doesn't fix the bug we spoke about. I believe Ulf
> >is still working on that one.
> >
> >So do you want me to remove this patch?
> >
>
> Yeah drop it for now.
Actually, a quick question before I do:
If it's better/faster to prepare the clock and keep it prepared
while you do clk_enable/clk_disable, why don't we do that in all
drivers? Why do we bother to prepare/unprepare each time if all
it does is take up cycles?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] input: gpio-keys: Add runtime support
From: Lee Jones @ 2012-10-25 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYAKpE1oWxHYzOMtdQ9Qj_OrZnnkJpQvrzSv8WFTBFS_Q@mail.gmail.com>
On Thu, 25 Oct 2012, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 9:57 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Fri, 12 Oct 2012, Linus Walleij wrote:
>
> >> Yours,
> >> Linus Walleij
> >
> > Friendly poke.
>
> This makes it look like you're poking me as I'm in the To: field but I suspect
> the intent must be to poke Dmitry ... I was just providing background
> for Shubhrajyoti's question.
>
> Maybe this helps:
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yes, that was also the intention of the other poke. Sorry about
that, I should have moved you into Cc: instead.
Yes, the poke was for Dmitry.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* RFC: tolerate junk after valid initramfs
From: Ben Peddell @ 2012-10-25 8:06 UTC (permalink / raw)
To: linux-arm-kernel
At the moment, the initramfs handling code will reject a valid initramfs
if there is junk between the end of the valid initramfs and the
initramfs size given to the kernel.
For example passing initrd=0x01000000,4M will not work unless the
initramfs is either exactly 4M in size or is padded with zeroes up to 4M.
As those working with ARM processors might know, the initialization code
in the bootloader generally doesn't zero out unused memory, so that
memory will contain garbage.
What downsides are there to patching init/initramfs.c to have the kernel
accept valid initramfs images where the image is shorter than the length
passed to the kernel by the bootloader?
^ permalink raw reply
* [PATCH] RFC: leds-pwm: don't disable pwm when setting brightness to 0
From: Shawn Guo @ 2012-10-25 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351086766-5837-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Wed, Oct 24, 2012 at 03:52:46PM +0200, Uwe Kleine-K?nig wrote:
> This fixes disabling the LED on i.MX28. The PWM hardware delays using
> the newly set pwm-config until the beginning of a new period. It's very
> likely that pwm_disable is called before the current period ends. In
> case the LED was on brightness=max before the LED stays on because in
> the disabled PWM block the period never ends.
>
> It's unclear if the mxs-pwm driver doesn't implement the API as expected
> (i.e. it should block until the newly set config is effective) or if the
> leds-pwm driver makes wrong assumptions. This patch assumes the latter.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> I'm not sure this is correct, but this is the workaround I'm using until
> I get some feed back.
I'm fine with it, since it fixes a real problem. Let's see what
Thierry says.
Shawn
>
> Best regards
> Uwe
>
> drivers/leds/leds-pwm.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index f2e44c7..a909f4f 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -38,13 +38,8 @@ static void led_pwm_set(struct led_classdev *led_cdev,
> unsigned int max = led_dat->cdev.max_brightness;
> unsigned int period = led_dat->period;
>
> - if (brightness == 0) {
> - pwm_config(led_dat->pwm, 0, period);
> - pwm_disable(led_dat->pwm);
> - } else {
> - pwm_config(led_dat->pwm, brightness * period / max, period);
> - pwm_enable(led_dat->pwm);
> - }
> + pwm_config(led_dat->pwm, brightness * period / max, period);
> + pwm_enable(led_dat->pwm);
> }
>
> static int led_pwm_probe(struct platform_device *pdev)
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 2/2] input: gpio-keys: Add runtime support
From: Linus Walleij @ 2012-10-25 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025075709.GE971@gmail.com>
On Thu, Oct 25, 2012 at 9:57 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Fri, 12 Oct 2012, Linus Walleij wrote:
>> Yours,
>> Linus Walleij
>
> Friendly poke.
This makes it look like you're poking me as I'm in the To: field but I suspect
the intent must be to poke Dmitry ... I was just providing background
for Shubhrajyoti's question.
Maybe this helps:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-10-25 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508895D8.5000701@ti.com>
Hi Jon,
many thanks for your time to look at this.
On 25.10.2012 03:28, Jon Hunter wrote:
> On 10/22/2012 02:55 PM, Daniel Mack wrote:
>> diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt b/Documentation/devicetree/bindings/bus/gpmc.txt
>> new file mode 100644
>> index 0000000..ef1c6e1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/gpmc.txt
>> @@ -0,0 +1,59 @@
>> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
>> +
>> +The actual devices are instantiated from the child nodes of a GPMC node.
>> +
>> +Required properties:
>> +
>> + - compatible: Should be set to "ti,gpmc"
>
> Is this the only required property? I think that "reg" and "ti,hwmods"
> are probably also required.
Well yes, but at least "reg" is commonly omitted as it's part of a more
"generic" set of properties. But ok, I can add these.
> Also given that we are describing the hardware, I am wondering if the
> number of chip-selects and wait signals should be defined here too. I
> recall that different devices had different number of wait pins available.
Hmm, that number is currently hard-coded in GPMC_CS_NUM. It would take
some effort to make that dynamic but I agree that this would be a good
thing to have. Afzal?
>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> new file mode 100644
>> index 0000000..6790fcf
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> @@ -0,0 +1,65 @@
>> +Device tree bindings for GPMC connected NANDs
>> +
>> +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
>> +the GPMC controller with a name of "nand".
>> +
>> +All timing relevant properties are explained in a separate documents - please
>> +refer to Documentation/devicetree/bindings/bus/gpmc.txt
>> +
>> +Required properties:
>> +
>> + - reg: The CS line the peripheral is connected to
>
> Is this the only required property? I would have thought that bus-width
> is needed too.
I described bus-with in the nand bindings and stated there that it
defaults to 8 and the only meaningful other value us 16. I did that
because the value is in fact parsed in the NAND code, but I can as well
move this around in the documentation.
> In general, I am wondering if this should be broken into two patches as
> you are creating the binding for the gpmc and nand here.
Yes, I thought so too. The thing is that I wanted to keep documentation
and implementation tightly together, and only the generic parser bits in
the code doesn't make much sense without any users. Also, the two
Documentations reference each other, so I thought having them in one
piece could make reviewing easier. But I can of course also split it if
that helps.
Thanks,
Daniel
^ permalink raw reply
* [GIT PULL] at91: fixes for 3.7-rc3
From: Nicolas Ferre @ 2012-10-25 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
This is the first Atmel AT91 "fixes" update for the 3.7 kernel.
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://github.com/at91linux/linux-at91.git tags/at91-fixes
for you to fetch changes up to 08d04a135a1c2e24c4d4bc7bbafee5e0e58f80c6:
ARM: at91: drop duplicated config SOC_AT91SAM9 entry (2012-10-24 18:08:48 +0200)
----------------------------------------------------------------
A mix of typos and critical fixes.
The most important ones are a duplicated definition of a Kconfig
variable and the handling of external interrupts for non-DT case.
The new at91sam9g10 was suffering a recognition issue due to an ID
mis-interpreted: this was leading to a kernel panic.
----------------------------------------------------------------
Bo Shen (2):
ARM: at91/i2c: change id to let i2c-gpio work
ARM: at91/i2c: change id to let i2c-at91 work
Ivan Shugov (1):
ARM: at91: at91sam9g10: fix SOC type detection
Jean-Christophe PLAGNIOL-VILLARD (1):
ARM: at91: drop duplicated config SOC_AT91SAM9 entry
Josh Wu (1):
ARM: at91/tc: fix typo in the DT document
Marek Belisko (1):
ARM: at91/dts: at91sam9g20ek_common: Fix typos in buttons labels.
Nicolas Ferre (2):
ARM: at91: fix external interrupts in non-DT case
ARM: at91: fix external interrupt specification in board code
Documentation/devicetree/bindings/arm/atmel-at91.txt | 2 +-
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 4 ++--
arch/arm/mach-at91/Kconfig | 10 ++--------
arch/arm/mach-at91/at91rm9200.c | 2 +-
arch/arm/mach-at91/at91rm9200_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9260.c | 4 ++--
arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9261.c | 4 ++--
arch/arm/mach-at91/at91sam9261_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9263.c | 2 +-
arch/arm/mach-at91/at91sam9263_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++--
arch/arm/mach-at91/board-neocore926.c | 2 +-
arch/arm/mach-at91/board-sam9261ek.c | 2 +-
arch/arm/mach-at91/board-sam9263ek.c | 2 +-
arch/arm/mach-at91/generic.h | 3 ++-
arch/arm/mach-at91/irq.c | 9 +++++++--
arch/arm/mach-at91/setup.c | 4 ++--
18 files changed, 35 insertions(+), 35 deletions(-)
Thanks, best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/6] pinctrl: Update clock handling for the pinctrl-nomadik GPIO driver
From: Linus Walleij @ 2012-10-25 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025073127.GB971@gmail.com>
On 10/25/2012 09:31 AM, Lee Jones wrote:
>
> This certainly doesn't fix the bug we spoke about. I believe Ulf
> is still working on that one.
>
> So do you want me to remove this patch?
>
Yeah drop it for now.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] input: gpio-keys: Add runtime support
From: Lee Jones @ 2012-10-25 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb+kWW903VD45i5s_LrZ2BKX=k6enGP2R9v2ptSRkvJ9w@mail.gmail.com>
On Fri, 12 Oct 2012, Linus Walleij wrote:
> On Thu, Oct 11, 2012 at 4:22 PM, Shubhrajyoti Datta
> <omaplinuxkernel@gmail.com> wrote:
>
> >> @@ -526,6 +527,7 @@ static int gpio_keys_open(struct input_dev *input)
> >> {
> >> struct gpio_keys_drvdata *ddata = input_get_drvdata(input);
> >>
> >> + pm_runtime_get_sync(input->dev.parent);
> >
> > I am not an expert of the runtime.
> >
> > However would be grateful if you explain me what it actually do.
>
> This increase the reference count of the runtime status container
> for the device. _sync makes sure it happens now.
>
> Consult:
> Documentation/power/runtime_pm.txt
>
> > Also I did not see any runtime suspend/ resume handlers populated.
>
> It is not necessary to handle the power state at the driver level,
> it can just as well be handled by the voltage/power domain,
> or at the class, type or bus level.
>
> But the individual driver has to notify the system upward if it
> needs to be powered on or when it may or must be relaxed.
>
> Yours,
> Linus Walleij
Friendly poke.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/5] clk: ux500: Add clock lookups for u8500
From: Lee Jones @ 2012-10-25 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350914281-1332-1-git-send-email-ulf.hansson@stericsson.com>
On Mon, 22 Oct 2012, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Step by step, clock lookups for u8500 are being added in this set
> of patches.
>
> These patches will require additional patches for sound/soc/ux500/
> driver as well as drivers/i2c/busses/i2c-nomadik driver to prevent
> the boot for ux500 from break. Those patches are being merged through
> separate trees.
>
> Ulf Hansson (5):
> clk: ux500: Register i2c clock lookups for u8500
> clk: ux500: Register ssp clock lookups for u8500
> clk: ux500: Register msp clock lookups for u8500
> clk: ux500: Update rtc clock lookup for u8500
> clk: ux500: Register slimbus clock lookups for u8500
Acked-by: Lee Jones <lee.jones@linaro.org>
Can I also mention that these need to go into the -rcs at the
earliest opportunity please, as it is preventing ~50% of the
devices from functioning on all of the ST-Ericsson development
boards.
This is a massive blocker for us!
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Thomas Petazzoni @ 2012-10-25 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <77006526a6de40ddb455b25787b08342.squirrel@ssl.serverraum.org>
Dear Michael Walle,
On Thu, 25 Oct 2012 09:39:13 +0200, Michael Walle wrote:
> LSXL_GPIO_USB_POWER and LSXL_GPIO_HDD_POWER switches the power on the USB
> and SATA connector. So they are not needed to be set before the driver
> probes, at least in my case here.
Ok.
> But i can imagine boards where you have to enable some kind of
> buffer/muxer/etc which are controlled by GPIO pins. And I don't think that
> should be part of the actual driver, because that would be highly board
> dependant.
You'd have to provide a more specific example so I can imagine how it
will be solved. But for example, if you have a GPIO-controlled muxer
for an I2C bus, then the I2C devices behind the muxer are described as
sub-devices of the muxer, so the probing order is correct.
Of course, I'm not pretending I have ready-to-use solutions for all
situations, but I think we can solve this problem on a case-by-case
basis.
Regardless of those GPIOs, did you solve the hang that happened even
when you removed the gpio_set_value() calls? Or is it still a problem
currently?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Michael Walle @ 2012-10-25 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025082826.693939b0@skate>
On Thu, October 25, 2012 08:28, Thomas Petazzoni wrote:
> Andrew,
>
> On Thu, 25 Oct 2012 07:46:38 +0200, Andrew Lunn wrote:
>
>> Thanks Thomas, i will play around with this.
>>
>> I'm just wondering if we are going to get into ordering issues. These
>> gpio operations are providing power to subsystems. We probably need
>> that to happen before the driver is loaded. If we call
>> of_platform_populate() too early, do we have the danger the driver
>> probing is going to happen before the init routine can enable the
>> power?
>>
>> It seems like we want pinctrl/gpio working first, with pins hogged as
>> specified in DT, then the board init() function, then the rest of DT
>> setup.
>
> If those GPIO value settings are needed to get a particular driver to
> work, then I'd recommend letting the driver do the GPIO value setting.
> For example, in the lsxl board, I see:
>
> /* usb and sata power on */
> gpio_set_value(LSXL_GPIO_USB_POWER, 1);
> gpio_set_value(LSXL_GPIO_HDD_POWER, 1);
>
> If the LSXL_GPIO_USB_POWER GPIO should be set to one to get the EHCI
> driver to work properly, then I think we should let the EHCI driver set
> this GPIO value in its ->probe() operation. Of course, the GPIO
> reference will be passed in the platform_data (for old-style probing),
> or through specific DT properties (for new-style, DT-based, probing).
>
> Regarding the LSXL_GPIO_HDD_POWER GPIO, I am not sure. Is it required
> to apply power on this GPIO to get the SATA driver to probe properly,
> or is it possible to get the SATA driver to probe properly, then apply
> power and have the HDD still being recognized? I haven't looked at all
> at how SATA drivers were working, so I can't say.
LSXL_GPIO_USB_POWER and LSXL_GPIO_HDD_POWER switches the power on the USB
and SATA connector. So they are not needed to be set before the driver
probes, at least in my case here.
But i can imagine boards where you have to enable some kind of
buffer/muxer/etc which are controlled by GPIO pins. And I don't think that
should be part of the actual driver, because that would be highly board
dependant.
> Also, ultimately, if those GPIOs are providing power, then they should
> probably not be handled as simple GPIOs, but rather as regulator, using
> the gpio-regulator driver. But let's do things steps by steps :-)
--
michael
^ permalink raw reply
* [PATCH 2/6] pinctrl: Update clock handling for the pinctrl-nomadik GPIO driver
From: Lee Jones @ 2012-10-25 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaeBW2ecQZ2fA-hL8o47pYpjZ=5Mn131F87u58rX+dekw@mail.gmail.com>
On Wed, 24 Oct 2012, Linus Walleij wrote:
> On Wed, Oct 24, 2012 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The clock framework has changed somewhat and it's now better to
> > invoke clock_prepare_enable() and clk_disable_unprepare() rather
> > than the legacy clk_enable() and clk_disable() calls. This patch
> > converts the Nomadik Pin Control driver to the new framework.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> (...)
> > - clk_enable(chip->clk);
> > + clk_prepare_enable(chip->clk);
> (...)
> > - clk_disable(chip->clk);
> > + clk_disable_unprepare(chip->clk);
>
> (Repeated for each occurence.)
>
> Is this *really* causing a regression? I mean the driver
> begin like this in nmk_gpio_probe():
>
> clk = devm_clk_get(&dev->dev, NULL);
> if (IS_ERR(clk)) {
> ret = PTR_ERR(clk);
> goto out;
> }
> clk_prepare(clk);
>
> Then it leaves the clock prepared. So the clock is always
> prepared. You would only need to enable/disable it at times.
>
> And the semantics of the clk_enable/clk_disable call pair
> is such that it is fastpath and should be real quick, and that
> is exactly why we're using it repeatedly like that. Inserting
> clk_unprepare() effectively could make the whole driver a
> lot slower, so convince me on this one. ...
>
> I suspect the real bug (if there is one) must be in the clock
> implementation.
This certainly doesn't fix the bug we spoke about. I believe Ulf
is still working on that one.
So do you want me to remove this patch?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [GIT PULL] first set of ux500 for ARM SoC for v3.8
From: Linus Walleij @ 2012-10-25 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdasaP_xVfQtzq29UNJBXetrUUzqpn90T6_Gr0kOsV8GeQ@mail.gmail.com>
On Thu, Oct 18, 2012 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Hi ARM SoC folks,
>
> here are two small commits for v3.8 that I'd like to make sure
> land in ARM SoC before I begin with all the other stuff.
>
> Please pull them in!
Ping on this.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: dts: mxs: add the "clock-names" for gpmi-nand
From: Shawn Guo @ 2012-10-25 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349864829-19565-1-git-send-email-b32955@freescale.com>
Hi Arnd, Olof,
Can you please apply this fix for -rc? Otherwise, please let me know
if you prefer to get a pull request from me.
Shawn
On Wed, Oct 10, 2012 at 06:27:09PM +0800, Huang Shijie wrote:
> The current DT nodes for mx23/mx28 miss the `clocks-names` item for gpmi-nand.
> So the gpmi-nand driver could not find the proper clock.
>
> This patch fixes this issue.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
> arch/arm/boot/dts/imx23.dtsi | 1 +
> arch/arm/boot/dts/imx28.dtsi | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> index 9ca4ca7..6d31aa3 100644
> --- a/arch/arm/boot/dts/imx23.dtsi
> +++ b/arch/arm/boot/dts/imx23.dtsi
> @@ -69,6 +69,7 @@
> interrupts = <13>, <56>;
> interrupt-names = "gpmi-dma", "bch";
> clocks = <&clks 34>;
> + clock-names = "gpmi_io";
> fsl,gpmi-dma-channel = <4>;
> status = "disabled";
> };
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index e16d631..55c57ea 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -85,6 +85,7 @@
> interrupts = <88>, <41>;
> interrupt-names = "gpmi-dma", "bch";
> clocks = <&clks 50>;
> + clock-names = "gpmi_io";
> fsl,gpmi-dma-channel = <4>;
> status = "disabled";
> };
> --
> 1.7.0.4
>
>
^ permalink raw reply
* [PATCH v6] Enable USB peripheral mode on dm365 EVM
From: Felipe Balbi @ 2012-10-25 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349872412-22040-1-git-send-email-const@MakeLinux.com>
Hi,
On Wed, Oct 10, 2012 at 02:33:32PM +0200, Constantine Shulyupin wrote:
> From: Constantine Shulyupin <const@MakeLinux.com>
>
> Sets USB PHY clock source to 24 MHz clock and call USB configuration from board initialization.
>
> Tested with OTG configuration, usb gadget g_zero on DM365 EVM connected to PC.
>
> References:
>
> Definition of USB_PHY_CTRL and PHYCLKFREQ:
> - http://www.makelinux.com/lib/ti/DM36x_ARM/doc-141
>
> Original patch by miguel.aguilar at ridgerun.com three years ago:
> - http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg14741.html
>
> Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
> ---
>
> Note:
>
> Changelog
>
> Changes since v5 http://www.spinics.net/lists/kernel/msg1413120.html
> accordingy feedback of nsekhar at ti.com http://www.spinics.net/lists/kernel/msg1414914.html
> - phy configuration moved to drivers/usb/musb/davinci.c
> - USB_OTG configuration is submitted in separated patch: http://www.spinics.net/lists/kernel/msg1414964.html
> - Setting current limit to 1000 mA. Any way the current is limited to 510 mA in davinci_setup_usb.
>
> Changes since v4 http://www.spinics.net/lists/kernel/msg1412995.html
> - removed fix of dev_info in musb_init_controller
>
> Changes since v3 http://www.spinics.net/lists/kernel/msg1412544.html:
> - removed optional altering of pr_info
>
> Changes since v1 http://marc.info/?l=linux-kernel&m=130894150803661&w=2:
> - removed optional code and reordered
> - removed alternation of GPIO33, which is multiplexed with DRVVBUS, because is not need for peripheral USB
>
> This patch is based on code from projects Arago, Angstom and RidgeRun.
>
> ---
> arch/arm/mach-davinci/board-dm365-evm.c | 2 ++
> drivers/usb/musb/davinci.c | 3 +++
> drivers/usb/musb/davinci.h | 1 +
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index 688a9c5..ba5ffc1 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -38,6 +38,7 @@
> #include <mach/mmc.h>
> #include <mach/nand.h>
> #include <mach/keyscan.h>
> +#include <mach/usb.h>
>
> #include <media/tvp514x.h>
>
> @@ -610,6 +611,7 @@ static __init void dm365_evm_init(void)
>
> dm365_init_spi0(BIT(0), dm365_evm_spi_info,
> ARRAY_SIZE(dm365_evm_spi_info));
> + davinci_setup_usb(1000, 8);
> }
>
> MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
> index 472c8b4..af09ebf 100644
> --- a/drivers/usb/musb/davinci.c
> +++ b/drivers/usb/musb/davinci.c
> @@ -428,6 +428,9 @@ static int davinci_musb_init(struct musb *musb)
> __raw_writel(deepsleep, DM355_DEEPSLEEP);
> }
>
> + if (machine_is_davinci_dm365_evm())
> + writel(readl(USB_PHY_CTRL) | USBPHY_CLKFREQ_24MHZ, USB_PHY_CTRL);
no such checks in drivers. Please find another way to do this.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/bfb7ee0f/attachment.sig>
^ permalink raw reply
* [PATCH 4/5] ARM: Dove: Make use of pinctrl driver
From: Linus Walleij @ 2012-10-25 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-5-git-send-email-andrew@lunn.ch>
On Wed, Oct 24, 2012 at 4:25 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> select PLAT_ORION_LEGACY
> + select PINCTRL
> + select PINCTRL_DOVE
Sort alphanumeric.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/5] pinctrl: dove: fix iomem and pdma clock
From: Linus Walleij @ 2012-10-25 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-4-git-send-email-andrew@lunn.ch>
On Wed, Oct 24, 2012 at 4:25 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> Since 3.7 readl/writel require register addresses to be const void*
> instead of unsigned int. The register addresses are converted using
> IOMEM() and offsets are added instead of OR'ed.
> Also a workaround for the pdma clock is added, that is required as
> there is still no DT clock provider available on Dove.
So essentially two unrelated patches squashed into one, and I
would apply the first one right off but now the clock change makes
me hesitate.
> clk = devm_clk_get(&pdev->dev, NULL);
> +
> + /* Currently there is no DT clock provider for pdma clock,
> + this fallback ensures pdma clock is ticking */
/*
* I prefer comment style like so because it's easier to read.
* Maybe it's a bit pedantic but bear with me.
*/
> + if (IS_ERR(clk))
> + clk = clk_get_sys("dove-pdma", NULL);
> +
This is a horrible hack. But if the Marvell people agree about
it I will live with it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] i2c: omap: re-factor omap_i2c_init function
From: Felipe Balbi @ 2012-10-25 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=Q2cvzQ7fVL1-vUpWZdwhGk3s0GpO3uG3MH9CAzBvyeSftKQ@mail.gmail.com>
Hi,
On Thu, Oct 25, 2012 at 12:23:56PM +0530, Shubhrajyoti Datta wrote:
> >> @@ -1268,23 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
> >> {
> >> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
> >>
> >> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> >> - }
> >> -
> >> - /*
> >> - * Don't write to this register if the IE state is 0 as it can
> >> - * cause deadlock.
> >> - */
> >> - if (_dev->iestate)
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
> >> + if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
> >> + __omap_i2c_init(_dev);
> >>
> >> return 0;
> >> }
> >
> > you continue to miss the changes in omap_i2c_xfer_msg() and your
> > explanation of why not doing it wasn't good enough IMHO.
>
> Will do that . I am preparing a seperate patch for moving the
> calculation to a seperate function.
why do you need yet another function ? omap_i2c_init() does all
calculation and __omap_i2c_init() doesn't do any calculations. What's
the point for yet another function ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/5b6583bd/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/5] ARM: Kirkwood: Allow use of pinctrl
From: Linus Walleij @ 2012-10-25 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-2-git-send-email-andrew@lunn.ch>
On Wed, Oct 24, 2012 at 4:25 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> We now have a pinctrl driver for arch-mvebu. It supports kirkwood out
> of the box. Allow ARCH_KIRKWOOD to select it, and make ARCH_KIRKWOOD
> select it. This then allows the convertion of board-*.c files away
> from MPP to pinctrl in DT, before they get moved over into mach-mvebu.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> arch/arm/Kconfig | 2 ++
> drivers/pinctrl/Kconfig | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 73067ef..160cd40 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -548,6 +548,8 @@ config ARCH_KIRKWOOD
> select GENERIC_CLOCKEVENTS
> select PCI
> select PLAT_ORION_LEGACY
> + select PINCTRL
> + select PINCTRL_KIRKWOOD
Russell just spent the end of the release cycle sorting all of these
in alphanumeric order, so keep to that. (Move above
PLAT*)
Once they look OK I'd like to get ACKs from one of the ARM
SoC maintainers so I can merge this set through the
pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Santosh Shilimkar @ 2012-10-25 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50887197.8010104@ti.com>
On Thursday 25 October 2012 04:24 AM, Jon Hunter wrote:
>
> On 10/24/2012 12:10 PM, Kevin Hilman wrote:
>> From: Kevin Hilman <khilman@ti.com>
>>
>> When a GPIO bank is freed or shutdown, ensure that the banks
>> dbck_enable_mask is cleared also. Otherwise, context restore on
>> subsequent off-mode transition will restore previous value from the
>> shadow copies (bank->context.debounce*) leading to mismatch state
>> between driver state and hardware state.
>>
>> This was discovered when board code was doing
>>
>> gpio_request_one()
>> gpio_set_debounce()
>> gpio_free()
>>
>> which was leaving the GPIO debounce settings in a confused state. If
>> that GPIO bank is subsequently used with off-mode enabled, bogus state
>> would be restored, leaving GPIO debounce enabled which then prevented
>> the CORE powerdomain from transitioning.
>>
>> To fix, ensure that bank->dbck_enable_mask is cleared when the bank
>> is freed/shutdown so debounce state doesn't persist.
>>
The freed part is fine but I don't understand why it needs to be done
on _a_ gpio irq shutdown callback where IRQs related configuration
on that one GPIO needs to be cleared. De-bounce clock is surely not IRQ
related configuration.
>> Special thanks to Grazvydas Ignotas for pointing out a bug in an
>> earlier version that would've disabled debounce on any runtime PM
>> transition.
>>
>> Reported-by: Paul Walmsley <paul@pwsan.com>
>> Cc: Igor Grinberg <grinberg@compulab.co.il>
>> Cc: Grazvydas Ignotas <notasas@gmail.com>
>> Signed-off-by: Kevin Hilman <khilman@ti.com>
>> ---
>> v2: only clear mask in free/shutdown, not in runtime PM paths,
>> clarified changelog
>> Applies on v3.7-rc2.
>>
>> drivers/gpio/gpio-omap.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 94cbc84..113b167 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -539,6 +539,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
>> _set_gpio_irqenable(bank, gpio, 0);
>> _clear_gpio_irqstatus(bank, gpio);
>> _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
>> + bank->dbck_enable_mask = 0;
>> }
>
> Does this need to be ...
>
> + bank->dbck_enable_mask &= ~(GPIO_BIT(bank, gpio));
> + _gpio_dbck_disable(bank);
>
Yes, its a per bank clock. There is an alternate. See below.
> There could be more than one gpio using debounce and so we should only
> clear the appropriate bit. Also after clearing a bit we could see if we
> can disable the debounce clock too.
>
When I mentioned the clearing in gpio_free() path will do trick, I had
something like below in mind.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index dee2856..8574105 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -629,8 +629,10 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
* If this is the last gpio to be freed in the bank,
* disable the bank module.
*/
- if (!bank->mod_usage)
+ if (!bank->mod_usage) {
+ bank->dbck_enable_mask = 0;
pm_runtime_put(bank->dev);
+ }
}
/*
This patch should be enough according to me unless and until I am
missing mask clear need in irq_shutdown path. It will also take
care of disabling of debounce clock as part of runtime suspend callback.
Regards,
Santosh
^ permalink raw reply related
* [PATCH 3/3] pinctrl: mvebu: move to its own directory
From: Linus Walleij @ 2012-10-25 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351114738-26793-3-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Oct 24, 2012 at 11:38 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Like the spear platform, the mvebu platform has multiple files: one
> core file, and then one file per SoC family. More files will be added
> later, as support for mach-orion5x and mach-mv78xx0 SoCs is added to
> pinctrl-mvebu. For those reasons, having a separate subdirectory,
> drivers/pinctrl/mvebu/ makes sense, and it had already been suggested
> by Linus Wallej when the driver was originally submitted.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thanks, patch applied.
Yours,
Linus Walleij
^ 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