* [PATCH 05/11] ARM: at91: convert timer suspend/resume to clock_event_device
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352408516-21988-7-git-send-email-swarren@wwwdotorg.org>
On 14:01 Thu 08 Nov , Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Move at91's timer suspend/resume functions from struct sys_timer
> at91sam926x_timer into struct clock_event_device pit_clkevt. This
> will allow the sys_timer suspend/resume fields to be removed, and
> eventually lead to a complete removal of struct sys_timer.
>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
look fine
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* [PATCH v2] Add support for generic BCM SoC chipsets
From: Arnd Bergmann @ 2012-11-12 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A01B5F.6040404@wwwdotorg.org>
On Sunday 11 November 2012, Stephen Warren wrote:
> > I'm following the other mobile ARM SoCs which all have a single mach-
> > directory for various families of chips (mach-tegra, mach-omap2,
> > etc...). Plus the intent is to have a single set of mach files that
> > works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
>
> It's quite possible to create one directory now, e.g. mach-bcm281xx, and
> then when consolidation with other mach-bcm* happens, merge all those
> directories into a single mach-bcm. I would tend to prefer (but only
> lightly) using mach-bcm281xx now and then renaming later, unless you
> plan on expanding the SoC support in the pretty near future.
I think the main question is how many files we expect to see in the
platform directories for each of bcm3528, bcm281xx and bcm476x. Right
now, my feeling is that each of them can be a single file, since most
of the stuff that has traditionally been in mach-* directories is
moving out to drivers now.
If that is the case, having one directory for each platform is a little
silly and we should just stick them all in one place, using the
"mach-bcm" name more as a help for people looking for the code than
an indication of being a single soc family or maintained by the same
person. We already have some precedent in shmobile, which contains
some platforms that were completely distinct at the time they were
introduced.
You still have to work out how you want to maintain that directory though,
either just having per-file maintainers, or having multiple people
take responsible for the entire directory.
Arnd
^ permalink raw reply
* [PATCH 01/14] pinctrl: SPEAr: add spi chipselect control driver
From: Arnd Bergmann @ 2012-11-12 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a92290e8a3b1a19c3a5e864edfa7badfc2af5d0.1352608333.git.viresh.kumar@linaro.org>
On Sunday 11 November 2012, Viresh Kumar wrote:
> From: Shiraz Hashim <shiraz.hashim@st.com>
>
> SPEAr platform provides a provision to control chipselects of ARM PL022
> Prime Cell spi controller through its system registers, which otherwise
> remains under PL022 control which some protocols do not want.
>
> This commit intends to provide the spi chipselect control in software
> over gpiolib interface. Since it is tied to pinctrl, we place it under
> 'drivers/pinctrl/spear/' directory.
>
> spi chip drivers can use the exported gpiolib interface to define their
> chipselect through DT or platform data.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
The driver looks ok to me, but I'll wait for Linus to take a look first
and give his ack.
Arnd
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Rob Clark @ 2012-11-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112143846.GI2346@mudshark.cambridge.arm.com>
On Mon, Nov 12, 2012 at 8:38 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Nov 12, 2012 at 01:46:57PM +0000, Rob Clark wrote:
>> On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Nov 09, 2012 at 09:17:33PM +0000, Rob Clark wrote:
>> >> @@ -122,22 +124,35 @@ extern int __get_user_4(void *);
>> >> ({ \
>> >> unsigned long __limit = current_thread_info()->addr_limit - 1; \
>> >> register const typeof(*(p)) __user *__p asm("r0") = (p);\
>> >> - register unsigned long __r2 asm("r2"); \
>> >> register unsigned long __l asm("r1") = __limit; \
>> >> register int __e asm("r0"); \
>> >> switch (sizeof(*(__p))) { \
>> >> - case 1: \
>> >> + case 1: { \
>> >> + register unsigned long __r2 asm("r2"); \
>> >> __get_user_x(__r2, __p, __e, __l, 1); \
>> >> + x = (typeof(*(p))) __r2; \
>> >> break; \
>> >> - case 2: \
>> >> + } \
>> >> + case 2: { \
>> >> + register unsigned long __r2 asm("r2"); \
>> >> __get_user_x(__r2, __p, __e, __l, 2); \
>> >> + x = (typeof(*(p))) __r2; \
>> >> break; \
>> >> - case 4: \
>> >> + } \
>> >> + case 4: { \
>> >> + register unsigned long __r2 asm("r2"); \
>> >> __get_user_x(__r2, __p, __e, __l, 4); \
>> >> + x = (typeof(*(p))) __r2; \
>> >> + break; \
>> >> + } \
>> >> + case 8: { \
>> >> + register unsigned long long __r2 asm("r2"); \
>> >
>> > Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
>> > asm, so the compiler shouldn't care much. For OABI, I think you may have to
>> > do some more work to get the two words where you want them.
>>
>> Is the question whether the compiler is guaranteed to allocate r2 and
>> r3 in all cases? I'm not quite sure, I confess to usually trying to
>> avoid inline asm. But from looking at the disassembly (for little
>> endian EABI build) it seemed to do the right thing.
>
> I can't recall how OABI represents 64-bit values and particularly whether this
> differs between little and big-endian, so I wondered whether you may have to
> do some marshalling when you assign x. However, a few quick experiments with
> GCC suggest that the register representation matches EABI in regards to word
> ordering (it just doesn't require an even base register), although it would
> be good to find this written down somewhere...
yeah, I was kinda hoping that someone a bit closer to the compiler
would speak up here :-)
>> The only other idea I had was to explicitly declare two 'unsigned
>> long's and then shift them into a 64bit x, although I'm open to
>> suggestions if there is a better way.
>
> Can't you just use register unsigned long long for all cases? Even better,
> follow what put_user does and use typeof(*(p))?
typeof(*(p) was my first try but:
register typeof(*(p)) __r2 asm("r2");
gives me the error:
error: read-only variable ?__r2? used as ?asm? output
I guess because 'const' ends up being part of the typeof *p? I
suppose I could do typeof(x) instead
BR,
-R
>> >> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
>> >> index 9b06bb4..d05285c 100644
>> >> --- a/arch/arm/lib/getuser.S
>> >> +++ b/arch/arm/lib/getuser.S
>> >> @@ -18,7 +18,7 @@
>> >> * Inputs: r0 contains the address
>> >> * r1 contains the address limit, which must be preserved
>> >> * Outputs: r0 is the error code
>> >> - * r2 contains the zero-extended value
>> >> + * r2, r3 contains the zero-extended value
>> >> * lr corrupted
>> >> *
>> >> * No other registers must be altered. (see <asm/uaccess.h>
>> >> @@ -66,6 +66,19 @@ ENTRY(__get_user_4)
>> >> mov pc, lr
>> >> ENDPROC(__get_user_4)
>> >>
>> >> +ENTRY(__get_user_8)
>> >> + check_uaccess r0, 4, r1, r2, __get_user_bad
>> >
>> > Shouldn't you be passing 8 here, so that we validate the correct range?
>>
>> yes, sorry, I'll fix that
>>
>> >> +#ifdef CONFIG_THUMB2_KERNEL
>> >> +5: TUSER(ldr) r2, [r0]
>> >> +6: TUSER(ldr) r3, [r0, #4]
>> >> +#else
>> >> +5: TUSER(ldr) r2, [r0], #4
>> >> +6: TUSER(ldr) r3, [r0]
>> >> +#endif
>> >
>> > This doesn't work for EABI big-endian systems.
>>
>> Hmm, is that true? Wouldn't put_user() then have the same problem?
>
> I dug up the PCS and it seems that we arrange the two halves of the
> doubleword to match the ldm/stm memory representation for EABI, so sorry
> for the confusion.
>
>> I guess __ARMEB__ is the flag for big-endian?
>
> That's the thing defined by the compiler, yes.
>
> Will
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 12/14] ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT
From: Arnd Bergmann @ 2012-11-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71bbb1faf3cd048953dcf24ef9ce6d9dd37fe8e1.1352608333.git.viresh.kumar@linaro.org>
On Sunday 11 November 2012, Viresh Kumar wrote:
> From: Shiraz Hashim <shiraz.hashim@st.com>
>
> SPEAr3xx architecture includes shared/multiplexed irqs for certain set
> of devices. The multiplexor provides a single interrupt to parent
> interrupt controller (VIC) on behalf of a group of devices.
>
> There can be multiple groups available on SPEAr3xx variants but not
> exceeding 4. The number of devices in a group can differ, further they
> may share same set of status/mask registers spanning across different
> bit masks. Also in some cases the group may not have enable or other
> registers. This makes software little complex.
>
> Present implementation was non-DT and had few complex data structures to
> decipher banks, number of irqs supported, mask and registers involved.
>
> This patch simplifies the overall design and convert it in to DT. It
> also removes all registration from individual SoC files and bring them
> in to common shirq.c.
>
> Also updated the corresponding documentation for DT binding of shirq.
Looks basically ok, but I have a few comments.
> Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/arm/spear/shirq.txt | 48 ++++
> arch/arm/mach-spear3xx/include/mach/irqs.h | 10 +-
> arch/arm/mach-spear3xx/spear300.c | 103 -------
> arch/arm/mach-spear3xx/spear310.c | 202 --------------
> arch/arm/mach-spear3xx/spear320.c | 204 --------------
> arch/arm/mach-spear3xx/spear3xx.c | 4 +
> arch/arm/plat-spear/include/plat/shirq.h | 35 +--
> arch/arm/plat-spear/shirq.c | 305 +++++++++++++++++----
I guess it would be nice to move this to drivers/irqchip/st-shirq.c now
that we have introduced that directory.
> static const char * const spear320_dt_board_compat[] = {
> diff --git a/arch/arm/mach-spear3xx/spear3xx.c b/arch/arm/mach-spear3xx/spear3xx.c
> index 98144ba..781aec9 100644
> --- a/arch/arm/mach-spear3xx/spear3xx.c
> +++ b/arch/arm/mach-spear3xx/spear3xx.c
> @@ -121,6 +122,9 @@ struct sys_timer spear3xx_timer = {
>
> static const struct of_device_id vic_of_match[] __initconst = {
> { .compatible = "arm,pl190-vic", .data = vic_of_init, },
> + { .compatible = "st,spear300-shirq", .data = spear3xx_shirq_of_init, },
> + { .compatible = "st,spear310-shirq", .data = spear3xx_shirq_of_init, },
> + { .compatible = "st,spear320-shirq", .data = spear3xx_shirq_of_init, },
> { /* Sentinel */ }
> };
You list three "compatible" values here with the same init function, and then
> +int __init spear3xx_shirq_of_init(struct device_node *np,
> + struct device_node *parent)
> +{
> + struct spear_shirq **shirq_blocks;
> + void __iomem *base;
> + int block_nr, ret;
> +
> + base = of_iomap(np, 0);
> + if (!base) {
> + pr_err("%s: failed to map shirq registers\n", __func__);
> + return -ENXIO;
> + }
> +
> + if (of_device_is_compatible(np, "st,spear300-shirq")) {
> + shirq_blocks = spear300_shirq_blocks;
> + block_nr = ARRAY_SIZE(spear300_shirq_blocks);
> + } else if (of_device_is_compatible(np, "st,spear310-shirq")) {
> + shirq_blocks = spear310_shirq_blocks;
> + block_nr = ARRAY_SIZE(spear310_shirq_blocks);
> + } else if (of_device_is_compatible(np, "st,spear320-shirq")) {
> + shirq_blocks = spear320_shirq_blocks;
> + block_nr = ARRAY_SIZE(spear320_shirq_blocks);
> + } else {
> + pr_err("%s: unknown platform\n", __func__);
> + ret = -EINVAL;
> + goto unmap;
> + }
> +
> + ret = shirq_init(shirq_blocks, block_nr, base, np);
> + if (ret) {
> + pr_err("%s: shirq initialization failed\n", __func__);
> + goto unmap;
> + }
> +
> + return ret;
> +
> +unmap:
> + iounmap(base);
> + return ret;
> +}
In that multiplex between thre three again. I think it would be cleaner to have
three separate functions and move the call to of_iomap into shirq_init.
Arnd
^ permalink raw reply
* [PATCH] ARM: EXYNOS: use BUG_ON where possible
From: Maarten Lankhorst @ 2012-11-12 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352406191-14303-5-git-send-email-sasha.levin@oracle.com>
Op 08-11-12 21:23, Sasha Levin schreef:
> Just use BUG_ON() instead of constructions such as:
>
> if (...)
> BUG()
>
> A simplified version of the semantic patch that makes this transformation
> is as follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e;
> @@
> - if (e) BUG();
> + BUG_ON(e);
> // </smpl>
>
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
> ---
> arch/arm/mach-exynos/common.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 4e577f6..6a55a5a 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -465,10 +465,8 @@ static void __init combiner_cascade_irq(unsigned int combiner_nr, unsigned int i
> else
> max_nr = EXYNOS4_MAX_COMBINER_NR;
>
> - if (combiner_nr >= max_nr)
> - BUG();
> - if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
> - BUG();
> + BUG_ON(combiner_nr >= max_nr);
> + BUG_ON(irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0);
Is it really a good idea to put functions that perform work in a BUG_ON?
I don't know, but for some reason it just feels wrong. I'd expect code to
compile fine if BUG_ON was a noop, so doing verification calls only, not
actual work..
~Maarten
^ permalink raw reply
* [PATCH v2 2/5] ARM: kernel: add device tree init map function
From: Dave Martin @ 2012-11-12 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352471654-20207-3-git-send-email-lorenzo.pieralisi@arm.com>
On Fri, Nov 09, 2012 at 02:34:11PM +0000, Lorenzo Pieralisi wrote:
> When booting through a device tree, the kernel cpu logical id map can be
> initialized using device tree data passed by FW or through an embedded blob.
>
> This patch adds a function that parses device tree "cpu" nodes and
> retrieves the corresponding CPUs hardware identifiers (MPIDR).
> It sets the possible cpus and the cpu logical map values according to
> the number of CPUs defined in the device tree and respective properties.
>
> The device tree HW identifiers are considered valid if all CPU nodes contain
> a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0]
> of the boot CPU.
>
> The primary CPU is assigned cpu logical number 0 to keep the current convention
> valid.
>
> Current bindings documentation is included in the patch:
>
> Documentation/devicetree/bindings/arm/cpus.txt
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++
> arch/arm/include/asm/prom.h | 2 +
> arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++
> 3 files changed, 162 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> new file mode 100644
> index 0000000..83cd98a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -0,0 +1,84 @@
> +* ARM CPUs binding description
> +
> +The device tree allows to describe the layout of CPUs in a system through
> +the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> +defining properties for every cpu.
> +
> +Bindings for CPU nodes follow the ePAPR standard, available from:
> +
> +http://devicetree.org
> +
> +For the ARM architecture every CPU node must contain the following properties:
> +
> +- reg : property matching the CPU MPIDR[23:0] register bits
> +- compatible: must be set to "arm, <cpu-model>"
> + where <cpu-model> is the full processor name as used in the
> + processor Technical Reference Manual, eg:
> + - for a Cortex A9 processor
> + compatible = <arm, cortex-a9>;
> + - for a Cortex A15 processor
> + compatible = <arm, cortex-a15>;
> +
> +List of possible "compatible" string ids:
> +
> +<arm, arm1020>
> +<arm, arm1020e>
> +<arm, arm1022>
> +<arm, arm1026>
> +<arm, arm720>
> +<arm, arm740>
> +<arm, arm7tdmi>
> +<arm, arm920>
> +<arm, arm922>
> +<arm, arm925>
> +<arm, arm926>
> +<arm, arm940>
> +<arm, arm946>
> +<arm, arm9tdmi>
> +<arm, fa526>
> +<arm, feroceon>
> +<arm, mohawk>
> +<arm, sa110>
> +<arm, sa1100>
> +<arm, xsc3>
> +<arm, xscale>
> +<arm, cortex-a5>
> +<arm, cortex-a7>
> +<arm, cortex-a8>
> +<arm, cortex-a9>
> +<arm, cortex-a15>
> +<arm, arm1136>
> +<arm, arm11-mpcore>
Any views on how we make sure that this list gets maintained?
This binding feels like it probably is the right place to keep the
exhaustive, "official" list of ARM CPU compatible strings, but I would
not be surprised if it gets stale.
Also, do we worry about the "arm," namespace for compatible strings
becoming overcrowded?
Currently we're shovelling a whole load of things in there, some of
which are not ARM products.
Thiry-party implementations like mohawk, sa11*, xsc*, fa526 and feroceon
are not ARM products, and should be in a different, appropriate vendor
namespace.
Cheers
---Dave
> +
> +Every cpu node is required to set its device_type to "cpu".
> +
> +Example:
> +
> + cpus {
> + #size-cells = <0>;
> + #address-cells = <1>;
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = <arm, cortex-a15>;
> + reg = <0x0>;
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = <arm, cortex-a15>;
> + reg = <0x1>;
> + };
> +
> + CPU2: cpu at 100 {
> + device_type = "cpu";
> + compatible = <arm, cortex-a7>;
> + reg = <0x100>;
> + };
> +
> + CPU3: cpu at 101 {
> + device_type = "cpu";
> + compatible = <arm, cortex-a7>;
> + reg = <0x101>;
> + };
> + };
> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> index aeae9c6..8dd51dc 100644
> --- a/arch/arm/include/asm/prom.h
> +++ b/arch/arm/include/asm/prom.h
> @@ -15,6 +15,7 @@
>
> extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> extern void arm_dt_memblock_reserve(void);
> +extern void __init arm_dt_init_cpu_maps(void);
>
> #else /* CONFIG_OF */
>
> @@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
> }
>
> static inline void arm_dt_memblock_reserve(void) { }
> +static inline void arm_dt_init_cpu_maps(void) { }
>
> #endif /* CONFIG_OF */
> #endif /* ASMARM_PROM_H */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index bee7f9d..d64d222 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -19,8 +19,10 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
>
> +#include <asm/cputype.h>
> #include <asm/setup.h>
> #include <asm/page.h>
> +#include <asm/smp_plat.h>
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
>
> @@ -61,6 +63,80 @@ void __init arm_dt_memblock_reserve(void)
> }
> }
>
> +/*
> + * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
> + * and builds the cpu logical map array containing MPIDR values related to
> + * logical cpus
> + *
> + * Updates the cpu possible mask with the number of parsed cpu nodes
> + */
> +void __init arm_dt_init_cpu_maps(void)
> +{
> + struct device_node *cpu, *cpus;
> + u32 i, cpuidx = 1, mpidr = read_cpuid_mpidr() & 0xffffff;
> + u32 tmp_map[NR_CPUS];
> + bool bootcpu_valid = false;
> +
> + cpus = of_find_node_by_path("/cpus");
> +
> + if (!cpus)
> + return;
> +
> + memset(tmp_map, 0, sizeof(tmp_map));
> +
> + for_each_child_of_node(cpus, cpu) {
> + u32 hwid;
> +
> + pr_debug(" * %s...\n", cpu->full_name);
> + /*
> + * A device tree containing CPU nodes with missing "reg"
> + * properties is considered invalid to build the
> + * cpu_logical_map.
> + */
> + if (of_property_read_u32(cpu, "reg", &hwid)) {
> + pr_debug(" * %s missing reg property\n",
> + cpu->full_name);
> + return;
> + }
> +
> + /*
> + * Build a stashed array of MPIDR values. Numbering scheme
> + * requires that if detected the boot CPU must be assigned
> + * logical id 0. Other CPUs get sequential indexes starting
> + * from 1. If a CPU node with a reg property matching the
> + * boot CPU MPIDR is detected, this is recorded so that the
> + * logical map built from DT is validated and can be used
> + * to override the map created in smp_setup_processor_id().
> + */
> + if (hwid == mpidr) {
> + i = 0;
> + bootcpu_valid = true;
> + } else {
> + i = cpuidx++;
> + }
> +
> + tmp_map[i] = hwid;
> +
> + if (cpuidx > nr_cpu_ids)
> + break;
> + }
> +
> + if (WARN(!bootcpu_valid, "DT CPU bindings are not valid,"
> + "fall back to default cpu_logical_map\n"))
> + return;
> +
> + /*
> + * Since the boot CPU node contains proper data, and all nodes have
> + * a reg property, the DT CPU list can be considered valid and the
> + * logical map created in smp_setup_processor_id() can be overridden
> + */
> + for (i = 0; i < cpuidx; i++) {
> + set_cpu_possible(i, true);
> + cpu_logical_map(i) = tmp_map[i];
> + pr_debug("cpu logical map 0x%x\n", cpu_logical_map(i));
> + }
> +}
> +
> /**
> * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
> * @dt_phys: physical address of dt blob
> --
> 1.7.12
>
>
^ permalink raw reply
* [PATCH linux-next] ARM: OMAP2: Fix compillation error in cm_common
From: Peter Ujfalusi @ 2012-11-12 15:17 UTC (permalink / raw)
To: linux-arm-kernel
Fixes the following error:
CC arch/arm/mach-omap2/cm_common.o
arch/arm/mach-omap2/cm_common.c: In function ?cm_register?:
arch/arm/mach-omap2/cm_common.c:42:11: error: ?EINVAL? undeclared (first use in this function)
arch/arm/mach-omap2/cm_common.c:42:11: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/mach-omap2/cm_common.c:45:11: error: ?EEXIST? undeclared (first use in this function)
arch/arm/mach-omap2/cm_common.c: In function ?cm_unregister?:
arch/arm/mach-omap2/cm_common.c:66:11: error: ?EINVAL? undeclared (first use in this function)
make[1]: *** [arch/arm/mach-omap2/cm_common.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Hi,
with today's linux-next the kernel build failed with the abive error for OMAP.
Regards,
Peter
arch/arm/mach-omap2/cm_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c
index 3246cef..3fafc27 100644
--- a/arch/arm/mach-omap2/cm_common.c
+++ b/arch/arm/mach-omap2/cm_common.c
@@ -13,6 +13,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
+#include <linux/errno.h>
#include "cm2xxx.h"
#include "cm3xxx.h"
--
1.8.0
^ permalink raw reply related
* [PATCH v2] Add support for generic BCM SoC chipsets
From: Russell King - ARM Linux @ 2012-11-12 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352645834-10173-1-git-send-email-csd@broadcom.com>
On Sun, Nov 11, 2012 at 06:57:14AM -0800, Christian Daudt wrote:
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <asm/io.h>
Please use linux/io.h rather than asm/io.h throughout your patch sets.
However, I don't see anything in this file which requires this header,
so it's better off being removed entirely.
^ permalink raw reply
* [PATCH v3 1/3] mtd: sh_flctl: Minor cleanups
From: Artem Bityutskiy @ 2012-11-12 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350641736-18192-2-git-send-email-hechtb@gmail.com>
On Fri, 2012-10-19 at 12:15 +0200, Bastian Hecht wrote:
> Some small fixes to avoid sparse and smatch complain. Other cosmetic fixes
> as well.
>
> - Change of the type of the member index in struct sh_flctl from signed
> to unsigned. We use index by addressing array members, so unsigned is more
> concise here. Adapt functions relying on sh_flctl::index.
> - Remove a blurring cast in write_fiforeg().
> - Apply consistent naming scheme when refering to the data buffer.
> - Shorten some unnecessarily verbose functions.
> - Remove spaces at start of lines.
>
> Signed-off-by: Bastian Hecht <hechtb@gmail.com>
Pushed to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121112/9f95731c/attachment.sig>
^ permalink raw reply
* [PATCH 00/14] ARM: SPEAr: DT updates
From: Arnd Bergmann @ 2012-11-12 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1352608333.git.viresh.kumar@linaro.org>
On Sunday 11 November 2012, Viresh Kumar wrote:
> These are DT updates for SPEAr SoCs. There aren't any fixes that we want to get
> into 3.7-rc* and we are happy with 3.8.
>
> Please apply them from mail, as i wouldn't be hosting them in my repo.
>
> Some of the dtbs which use gpiopinctrl have dependency on Linus's pinctrl tree,
> where an earlier update for adding gpiopinctrl node is present.
Hi Viresh,
I tried pulling in patches 2 to 11, but it no longer builds because of the
dependency you mentioned. Can you be more specific which branch I need
to pull in?
If you have non-obvious dependencies, I would actually prefer getting a pull
request. I know you have access to git.linaro.org, so can't you just use that
to send a branch that is known to work and that has the right dependencies
included?
Arnd
^ permalink raw reply
* [PATCH] i.MX IPU SoC support
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
This series adds the necessary i.MX SoC stuff to make the IPU support
usable. Basically needed are the IPU devices in the devicetrees. This
series also adds display support for the i.MX51 babbage which then is
the first board for which the IPU driver works without out of tree
stuff.
Shawn, I already sent the MIPI setup patch some time ago. From what
I read I think we can agree on the approach on just setting the correct
register values in the SoC code, right?
Sascha
The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7:
Linux 3.7-rc5 (2012-11-11 13:44:33 +0100)
are available in the git repository at:
git://git.pengutronix.de/git/imx/linux-2.6.git ipu
for you to fetch changes up to f774f0f776e282d6e0eb67dbf00703ed79b8bca2:
ARM i.MX51 babbage: Add display support (2012-11-12 16:16:19 +0100)
----------------------------------------------------------------
Sascha Hauer (6):
ARM i.MX51: setup MIPI during startup
ARM i.MX5: switch IPU clk support to devicetree bindings
ARM i.MX53: Add IPU support
ARM i.MX51: Add IPU support
ARM i.MX6: Add IPU support
ARM i.MX51 babbage: Add display support
Steffen Trumtrar (1):
ARM i.MX6: fix ldb_di_sel mux
arch/arm/boot/dts/imx51-babbage.dts | 16 +++++++++
arch/arm/boot/dts/imx51.dtsi | 67 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx53.dtsi | 7 ++++
arch/arm/boot/dts/imx6q.dtsi | 18 ++++++++++
arch/arm/mach-imx/clk-imx51-imx53.c | 19 +++++-----
arch/arm/mach-imx/clk-imx6q.c | 2 +-
arch/arm/mach-imx/mm-imx5.c | 20 +++++++++++
7 files changed, 140 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH 1/7] ARM i.MX51: setup MIPI during startup
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-1-git-send-email-s.hauer@pengutronix.de>
The MIPI interface has to be initialized for proper IPU support.
The MIPI officially is not supported, but still needs initialization.
This patch adds this to the SoC startup as all it does is poking
some magic values into registers for which we do not have documentation.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/mm-imx5.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
index acb0aad..f01e74f 100644
--- a/arch/arm/mach-imx/mm-imx5.c
+++ b/arch/arm/mach-imx/mm-imx5.c
@@ -81,8 +81,28 @@ void __init imx50_init_early(void)
mxc_arch_reset_init(MX50_IO_ADDRESS(MX50_WDOG_BASE_ADDR));
}
+/*
+ * The MIPI HSC unit has been removed from the i.MX51 Reference Manual by
+ * the Freescale marketing division. However this did not remove the
+ * hardware from the chip which still needs to be configured for proper
+ * IPU support.
+ */
+static void __init imx51_ipu_mipi_setup(void)
+{
+ void __iomem *hsc_addr;
+ hsc_addr = MX51_IO_ADDRESS(MX51_MIPI_HSC_BASE_ADDR);
+
+ /* setup MIPI module to legacy mode */
+ __raw_writel(0xf00, hsc_addr);
+
+ /* CSI mode: reserved; DI control mode: legacy (from Freescale BSP) */
+ __raw_writel(__raw_readl(hsc_addr + 0x800) | 0x30ff,
+ hsc_addr + 0x800);
+}
+
void __init imx51_init_early(void)
{
+ imx51_ipu_mipi_setup();
mxc_set_cpu_type(MXC_CPU_MX51);
mxc_iomux_v3_init(MX51_IO_ADDRESS(MX51_IOMUXC_BASE_ADDR));
mxc_arch_reset_init(MX51_IO_ADDRESS(MX51_WDOG1_BASE_ADDR));
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/7] ARM i.MX6: fix ldb_di_sel mux
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-1-git-send-email-s.hauer@pengutronix.de>
From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
This adds the mmdc_ch1 as a possible parent for the ldb_di clk.
According to the datasheet, this clock can be selected at this mux.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
arch/arm/mach-imx/clk-imx6q.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 3ec242f..6b511ba 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -104,7 +104,7 @@ static const char *gpu2d_core_sels[] = { "axi", "pll3_usb_otg", "pll2_pfd0_352m"
static const char *gpu3d_core_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd2_396m", };
static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd9_720m", };
static const char *ipu_sels[] = { "mmdc_ch0_axi", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
-static const char *ldb_di_sels[] = { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
+static const char *ldb_di_sels[] = { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_pfd1_540m", };
static const char *ipu_di_pre_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
static const char *ipu1_di0_sels[] = { "ipu1_di0_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
static const char *ipu1_di1_sels[] = { "ipu1_di1_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/7] ARM i.MX5: switch IPU clk support to devicetree bindings
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-1-git-send-email-s.hauer@pengutronix.de>
The i.MX5 clk support has platform based clock bindings for the
IPU. IPU support is devicetree only, so move them over to devicetree
based bindings. Also, enable MIPI clocks which do not have a device
associated with, but still need to be enabled to do graphics on
i.MX51.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/clk-imx51-imx53.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index a0bf848..02932da 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -306,6 +306,10 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
clk_prepare_enable(clk[spba]);
clk_prepare_enable(clk[emi_fast_gate]); /* fec */
clk_prepare_enable(clk[emi_slow_gate]); /* eim */
+ clk_prepare_enable(clk[mipi_hsc1_gate]);
+ clk_prepare_enable(clk[mipi_hsc2_gate]);
+ clk_prepare_enable(clk[mipi_esc_gate]);
+ clk_prepare_enable(clk[mipi_hsp_gate]);
clk_prepare_enable(clk[tmax1]);
clk_prepare_enable(clk[tmax2]); /* esdhc2, fec */
clk_prepare_enable(clk[tmax3]); /* esdhc1, esdhc4 */
@@ -349,10 +353,9 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
clk_register_clkdev(clk[mx51_mipi], "mipi_hsp", NULL);
clk_register_clkdev(clk[vpu_gate], NULL, "imx51-vpu.0");
clk_register_clkdev(clk[fec_gate], NULL, "imx27-fec.0");
- clk_register_clkdev(clk[ipu_gate], "bus", "imx51-ipu");
- clk_register_clkdev(clk[ipu_di0_gate], "di0", "imx51-ipu");
- clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx51-ipu");
- clk_register_clkdev(clk[ipu_gate], "hsp", "imx51-ipu");
+ clk_register_clkdev(clk[ipu_gate], "bus", "40000000.ipu");
+ clk_register_clkdev(clk[ipu_di0_gate], "di0", "40000000.ipu");
+ clk_register_clkdev(clk[ipu_di1_gate], "di1", "40000000.ipu");
clk_register_clkdev(clk[usb_phy_gate], "phy", "mxc-ehci.0");
clk_register_clkdev(clk[esdhc1_ipg_gate], "ipg", "sdhci-esdhc-imx51.0");
clk_register_clkdev(clk[dummy], "ahb", "sdhci-esdhc-imx51.0");
@@ -442,10 +445,10 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
clk_register_clkdev(clk[vpu_gate], NULL, "imx53-vpu.0");
clk_register_clkdev(clk[i2c3_gate], NULL, "imx-i2c.2");
clk_register_clkdev(clk[fec_gate], NULL, "imx25-fec.0");
- clk_register_clkdev(clk[ipu_gate], "bus", "imx53-ipu");
- clk_register_clkdev(clk[ipu_di0_gate], "di0", "imx53-ipu");
- clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx53-ipu");
- clk_register_clkdev(clk[ipu_gate], "hsp", "imx53-ipu");
+ clk_register_clkdev(clk[ipu_gate], "bus", "18000000.ipu");
+ clk_register_clkdev(clk[ipu_di0_gate], "di0", "18000000.ipu");
+ clk_register_clkdev(clk[ipu_di1_gate], "di1", "18000000.ipu");
+ clk_register_clkdev(clk[ipu_gate], "hsp", "18000000.ipu");
clk_register_clkdev(clk[usb_phy1_gate], "usb_phy1", "mxc-ehci.0");
clk_register_clkdev(clk[esdhc1_ipg_gate], "ipg", "sdhci-esdhc-imx53.0");
clk_register_clkdev(clk[dummy], "ahb", "sdhci-esdhc-imx53.0");
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/7] ARM i.MX53: Add IPU support
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-1-git-send-email-s.hauer@pengutronix.de>
This adds the IPU device to the devicetree.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx53.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 76ebb1a..3387c5d 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -67,6 +67,13 @@
interrupt-parent = <&tzic>;
ranges;
+ ipu: ipu at 18000000 {
+ #crtc-cells = <1>;
+ compatible = "fsl,imx53-ipu";
+ reg = <0x18000000 0x080000000>;
+ interrupts = <11 10>;
+ };
+
aips at 50000000 { /* AIPS1 */
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/7] ARM i.MX51: Add IPU support
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-1-git-send-email-s.hauer@pengutronix.de>
This adds the IPU device to the devicetree along with the necessary pinctrl
settings for the parallel display outputs.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx51.dtsi | 67 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 75d069f..c20e868 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -62,6 +62,13 @@
interrupt-parent = <&tzic>;
ranges;
+ ipu: ipu at 40000000 {
+ #crtc-cells = <1>;
+ compatible = "fsl,imx51-ipu";
+ reg = <0x40000000 0x20000000>;
+ interrupts = <11 10>;
+ };
+
aips at 70000000 { /* AIPS1 */
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
@@ -295,6 +302,66 @@
};
};
+ ipu_disp1 {
+ pinctrl_ipu_disp1_1: ipudisp1grp-1 {
+ fsl,pins = <
+ 528 0x5 /* MX51_PAD_DISP1_DAT0__DISP1_DAT0 */
+ 529 0x5 /* MX51_PAD_DISP1_DAT1__DISP1_DAT1 */
+ 530 0x5 /* MX51_PAD_DISP1_DAT2__DISP1_DAT2 */
+ 531 0x5 /* MX51_PAD_DISP1_DAT3__DISP1_DAT3 */
+ 532 0x5 /* MX51_PAD_DISP1_DAT4__DISP1_DAT4 */
+ 533 0x5 /* MX51_PAD_DISP1_DAT5__DISP1_DAT5 */
+ 535 0x5 /* MX51_PAD_DISP1_DAT6__DISP1_DAT6 */
+ 537 0x5 /* MX51_PAD_DISP1_DAT7__DISP1_DAT7 */
+ 539 0x5 /* MX51_PAD_DISP1_DAT8__DISP1_DAT8 */
+ 541 0x5 /* MX51_PAD_DISP1_DAT9__DISP1_DAT9 */
+ 543 0x5 /* MX51_PAD_DISP1_DAT10__DISP1_DAT10 */
+ 545 0x5 /* MX51_PAD_DISP1_DAT11__DISP1_DAT11 */
+ 547 0x5 /* MX51_PAD_DISP1_DAT12__DISP1_DAT12 */
+ 549 0x5 /* MX51_PAD_DISP1_DAT13__DISP1_DAT13 */
+ 551 0x5 /* MX51_PAD_DISP1_DAT14__DISP1_DAT14 */
+ 553 0x5 /* MX51_PAD_DISP1_DAT15__DISP1_DAT15 */
+ 555 0x5 /* MX51_PAD_DISP1_DAT16__DISP1_DAT16 */
+ 557 0x5 /* MX51_PAD_DISP1_DAT17__DISP1_DAT17 */
+ 559 0x5 /* MX51_PAD_DISP1_DAT18__DISP1_DAT18 */
+ 563 0x5 /* MX51_PAD_DISP1_DAT19__DISP1_DAT19 */
+ 567 0x5 /* MX51_PAD_DISP1_DAT20__DISP1_DAT20 */
+ 571 0x5 /* MX51_PAD_DISP1_DAT21__DISP1_DAT21 */
+ 575 0x5 /* MX51_PAD_DISP1_DAT22__DISP1_DAT22 */
+ 579 0x5 /* MX51_PAD_DISP1_DAT23__DISP1_DAT23 */
+ 584 0x5 /* MX51_PAD_DI1_PIN2__DI1_PIN2 (hsync) */
+ 583 0x5 /* MX51_PAD_DI1_PIN3__DI1_PIN3 (vsync) */
+ >;
+ };
+ };
+
+ ipu_disp2 {
+ pinctrl_ipu_disp2_1: ipudisp2grp-1 {
+ fsl,pins = <
+ 603 0x5 /* MX51_PAD_DISP2_DAT0__DISP2_DAT0 */
+ 608 0x5 /* MX51_PAD_DISP2_DAT1__DISP2_DAT1 */
+ 613 0x5 /* MX51_PAD_DISP2_DAT2__DISP2_DAT2 */
+ 614 0x5 /* MX51_PAD_DISP2_DAT3__DISP2_DAT3 */
+ 615 0x5 /* MX51_PAD_DISP2_DAT4__DISP2_DAT4 */
+ 616 0x5 /* MX51_PAD_DISP2_DAT5__DISP2_DAT5 */
+ 617 0x5 /* MX51_PAD_DISP2_DAT6__DISP2_DAT6 */
+ 622 0x5 /* MX51_PAD_DISP2_DAT7__DISP2_DAT7 */
+ 627 0x5 /* MX51_PAD_DISP2_DAT8__DISP2_DAT8 */
+ 633 0x5 /* MX51_PAD_DISP2_DAT9__DISP2_DAT9 */
+ 637 0x5 /* MX51_PAD_DISP2_DAT10__DISP2_DAT10 */
+ 643 0x5 /* MX51_PAD_DISP2_DAT11__DISP2_DAT11 */
+ 648 0x5 /* MX51_PAD_DISP2_DAT12__DISP2_DAT12 */
+ 652 0x5 /* MX51_PAD_DISP2_DAT13__DISP2_DAT13 */
+ 656 0x5 /* MX51_PAD_DISP2_DAT14__DISP2_DAT14 */
+ 661 0x5 /* MX51_PAD_DISP2_DAT15__DISP2_DAT15 */
+ 593 0x5 /* MX51_PAD_DI2_PIN2__DI2_PIN2 (hsync) */
+ 595 0x5 /* MX51_PAD_DI2_PIN3__DI2_PIN3 (vsync) */
+ 597 0x5 /* MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK */
+ 599 0x5 /* MX51_PAD_DI_GP4__DI2_PIN15 */
+ >;
+ };
+ };
+
uart1 {
pinctrl_uart1_1: uart1grp-1 {
fsl,pins = <
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/7] ARM i.MX6: Add IPU support
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-1-git-send-email-s.hauer@pengutronix.de>
This adds the IPU devices to the devicetree.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx6q.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f3990b0..39d3433 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -1001,5 +1001,23 @@
status = "disabled";
};
};
+
+ ipu1: ipu at 02400000 {
+ #crtc-cells = <1>;
+ compatible = "fsl,imx6q-ipu";
+ reg = <0x02400000 0x400000>;
+ interrupts = <0 6 0x4 0 5 0x4>;
+ clocks = <&clks 130>, <&clks 131>, <&clks 132>;
+ clock-names = "bus", "di0", "di1";
+ };
+
+ ipu2: ipu at 02800000 {
+ #crtc-cells = <1>;
+ compatible = "fsl,imx6q-ipu";
+ reg = <0x02800000 0x400000>;
+ interrupts = <0 8 0x4 0 7 0x4>;
+ clocks = <&clks 133>, <&clks 134>, <&clks 137>;
+ clock-names = "bus", "di0", "di1";
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/7] ARM i.MX51 babbage: Add display support
From: Sascha Hauer @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-1-git-send-email-s.hauer@pengutronix.de>
The babbage board has a DVI-I output which allows to output analog
and digital signals simultaneously. This patch adds support for it
to the devicetree. The DDC signals are not wired up on the board, so
DRM will fall back on default VESA modes.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx51-babbage.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index cbd2b1c..567e7ee 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -22,6 +22,22 @@
};
soc {
+ display at di0 {
+ compatible = "fsl,imx-parallel-display";
+ crtcs = <&ipu 0>;
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu_disp1_1>;
+ };
+
+ display at di1 {
+ compatible = "fsl,imx-parallel-display";
+ crtcs = <&ipu 1>;
+ interface-pix-fmt = "rgb565";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu_disp2_1>;
+ };
+
aips at 70000000 { /* aips-1 */
spba at 70000000 {
esdhc at 70004000 { /* ESDHC1 */
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: use BUG_ON where possible
From: Russell King - ARM Linux @ 2012-11-12 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A111DD.6080504@gmail.com>
On Mon, Nov 12, 2012 at 04:12:29PM +0100, Maarten Lankhorst wrote:
> Op 08-11-12 21:23, Sasha Levin schreef:
> > @@ -465,10 +465,8 @@ static void __init combiner_cascade_irq(unsigned int combiner_nr, unsigned int i
> > else
> > max_nr = EXYNOS4_MAX_COMBINER_NR;
> >
> > - if (combiner_nr >= max_nr)
> > - BUG();
> > - if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
> > - BUG();
> > + BUG_ON(combiner_nr >= max_nr);
> > + BUG_ON(irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0);
>
> Is it really a good idea to put functions that perform work in a BUG_ON?
> I don't know, but for some reason it just feels wrong. I'd expect code to
> compile fine if BUG_ON was a noop, so doing verification calls only, not
> actual work..
Well, it is currently defined as:
include/asm-generic/bug.h:#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
include/asm-generic/bug.h:#define BUG_ON(condition) do { if (condition) ; } while(0)
but as these can be overridden, I don't think relying on those
implementations is a good idea; to do so would be fragile. Eg, what if
the BUG_ON() implementation becomes just:
#define BUG_ON(x)
then the function call itself vanishes. So, only put the actual bug test
inside a BUG_ON(), not the functional part which must always be executed.
^ permalink raw reply
* [PATCH] ARM: EXYNOS: use BUG_ON where possible
From: Sasha Levin @ 2012-11-12 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A111DD.6080504@gmail.com>
On 11/12/2012 10:12 AM, Maarten Lankhorst wrote:
> Op 08-11-12 21:23, Sasha Levin schreef:
>> Just use BUG_ON() instead of constructions such as:
>>
>> if (...)
>> BUG()
>>
>> A simplified version of the semantic patch that makes this transformation
>> is as follows: (http://coccinelle.lip6.fr/)
>>
>> // <smpl>
>> @@
>> expression e;
>> @@
>> - if (e) BUG();
>> + BUG_ON(e);
>> // </smpl>
>>
>> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>> ---
>> arch/arm/mach-exynos/common.c | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
>> index 4e577f6..6a55a5a 100644
>> --- a/arch/arm/mach-exynos/common.c
>> +++ b/arch/arm/mach-exynos/common.c
>> @@ -465,10 +465,8 @@ static void __init combiner_cascade_irq(unsigned int combiner_nr, unsigned int i
>> else
>> max_nr = EXYNOS4_MAX_COMBINER_NR;
>>
>> - if (combiner_nr >= max_nr)
>> - BUG();
>> - if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
>> - BUG();
>> + BUG_ON(combiner_nr >= max_nr);
>> + BUG_ON(irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0);
> Is it really a good idea to put functions that perform work in a BUG_ON?
> I don't know, but for some reason it just feels wrong. I'd expect code to
> compile fine if BUG_ON was a noop, so doing verification calls only, not
> actual work..
You can't modify the side-effects of a macro based on kernel configuration. If
we're evaluating the expression when BUG_ON() is enabled, you must also evaluate
the expression when BUG_ON() is not enabled (HAVE_ARCH_BUG_ON is not set).
The only reason I'd not include function calls in a BUG_ON() call is due to
readability considerations. In this case it looked okay to me, but if someone
thinks that getting the function call into the BUG_ON() complicated things I'm
fine with skipping that.
Thanks,
Sasha
^ permalink raw reply
* [PATCH] staging drm/imx: updates
From: Sascha Hauer @ 2012-11-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
The following contains some assorted updates to the i.MX drm driver
for the next merge window.
Sascha
----------------------------------------------------------------
Michael Olbrich (1):
staging: drm/imx: Fix YUYV support in i.MX IPUv3 base driver
Philipp Zabel (4):
staging: drm/imx: Add YVU420 support to i.MX IPUv3 base driver
staging: drm/imx: silence ipu_crtc_dpms debug message
staging: drm/imx: Add ipu_cpmem_set_yuv_interleaved()
staging: drm/imx: Remove 300ms delay after memory reset
Sascha Hauer (1):
staging: drm/imx: Add pinctrl support to parallel display driver
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 1 +
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 33 +++++++++++++++++++++++----
drivers/staging/imx-drm/ipuv3-crtc.c | 2 +-
drivers/staging/imx-drm/parallel-display.c | 10 ++++++++
4 files changed, 41 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 1/6] staging: drm/imx: Fix YUYV support in i.MX IPUv3 base driver
From: Sascha Hauer @ 2012-11-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352734144-14897-1-git-send-email-s.hauer@pengutronix.de>
From: Michael Olbrich <m.olbrich@pengutronix.de>
YVYU is not supported by the IPU, so remove partial handling
of this format and replace it with YUYV which is supported.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index f381960..04f6aba 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -380,6 +380,7 @@ int ipu_cpmem_set_image(struct ipu_ch_param __iomem *cpmem,
ipu_cpmem_set_buffer(cpmem, 0, image->phys + y_offset);
break;
case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_YUYV:
ipu_cpmem_set_buffer(cpmem, 0, image->phys +
image->rect.left * 2 +
image->rect.top * image->pix.bytesperline);
@@ -414,7 +415,7 @@ enum ipu_color_space ipu_pixelformat_to_colorspace(u32 pixelformat)
switch (pixelformat) {
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_UYVY:
- case V4L2_PIX_FMT_YVYU:
+ case V4L2_PIX_FMT_YUYV:
return IPUV3_COLORSPACE_YUV;
case V4L2_PIX_FMT_RGB32:
case V4L2_PIX_FMT_BGR32:
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/6] staging: drm/imx: Add YVU420 support to i.MX IPUv3 base driver
From: Sascha Hauer @ 2012-11-12 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352734144-14897-1-git-send-email-s.hauer@pengutronix.de>
From: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index 04f6aba..a5cec0e 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -234,6 +234,11 @@ void ipu_cpmem_set_yuv_planar_full(struct ipu_ch_param __iomem *p,
ipu_ch_param_write_field(p, IPU_FIELD_UBO, u_offset / 8);
ipu_ch_param_write_field(p, IPU_FIELD_VBO, v_offset / 8);
break;
+ case V4L2_PIX_FMT_YVU420:
+ ipu_ch_param_write_field(p, IPU_FIELD_SLUV, (stride / 2) - 1);
+ ipu_ch_param_write_field(p, IPU_FIELD_UBO, v_offset / 8);
+ ipu_ch_param_write_field(p, IPU_FIELD_VBO, u_offset / 8);
+ break;
}
}
EXPORT_SYMBOL_GPL(ipu_cpmem_set_yuv_planar_full);
@@ -246,10 +251,11 @@ void ipu_cpmem_set_yuv_planar(struct ipu_ch_param __iomem *p, u32 pixel_format,
switch (pixel_format) {
case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
uv_stride = stride / 2;
u_offset = stride * height;
v_offset = u_offset + (uv_stride * height / 2);
- ipu_cpmem_set_yuv_planar_full(p, V4L2_PIX_FMT_YUV420, stride,
+ ipu_cpmem_set_yuv_planar_full(p, pixel_format, stride,
u_offset, v_offset);
break;
}
@@ -307,6 +313,7 @@ int ipu_cpmem_set_fmt(struct ipu_ch_param __iomem *cpmem, u32 pixelformat)
{
switch (pixelformat) {
case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
/* pix format */
ipu_ch_param_write_field(cpmem, IPU_FIELD_PFS, 2);
/* burst size */
@@ -369,6 +376,7 @@ int ipu_cpmem_set_image(struct ipu_ch_param __iomem *cpmem,
switch (pix->pixelformat) {
case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
y_offset = Y_OFFSET(pix, image->rect.left, image->rect.top);
u_offset = U_OFFSET(pix, image->rect.left,
image->rect.top) - y_offset;
@@ -414,6 +422,7 @@ enum ipu_color_space ipu_pixelformat_to_colorspace(u32 pixelformat)
{
switch (pixelformat) {
case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YUYV:
return IPUV3_COLORSPACE_YUV;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/6] staging: drm/imx: silence ipu_crtc_dpms debug message
From: Sascha Hauer @ 2012-11-12 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352734144-14897-1-git-send-email-s.hauer@pengutronix.de>
From: Philipp Zabel <p.zabel@pengutronix.de>
It's for debugging only, so use dev_dbg.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/staging/imx-drm/ipuv3-crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index 78d3eda..7e85c59 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -116,7 +116,7 @@ static void ipu_crtc_dpms(struct drm_crtc *crtc, int mode)
{
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
- dev_info(ipu_crtc->dev, "%s mode: %d\n", __func__, mode);
+ dev_dbg(ipu_crtc->dev, "%s mode: %d\n", __func__, mode);
switch (mode) {
case DRM_MODE_DPMS_ON:
--
1.7.10.4
^ permalink raw reply related
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