* [PATCH v2 0/2] Move sdhci-s3c platform helper into driver
From: Thomas Abraham @ 2011-09-14 7:09 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v1:
- Rebased with 'for-next' branch of
http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
(tested with commit id a08b7e19811181309da2306338027fe1d3f8001d at the
tip of the for-next branch, not sure if there have been further
commits after that).
The platform helper that sets up the default sdhci-s3c controller
configuration can be removed and moved into the sdhci-s3c driver.
This platform helper is removed for s3c2416, s3c64xx, s5pc100,
s5pv210 and Exynos4 platforms.
Since the platform helper function pointer was being passed in the
platform data of sdhci-s3c driver, the removal of this pointer from
the platform data is step closer to complete device tree support for
sdhci-s3c driver.
This patchset has been tested on the following platforms.
SMDK2416, SMDK6410, SMDKC100, SMDKV210 and SMDKV310.
^ permalink raw reply
* [PATCH] ARM: mach-mxs/mx28evk: Only register devices if their GPIO requests succeeded
From: Uwe Kleine-König @ 2011-09-14 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315945519-15178-1-git-send-email-festevam@gmail.com>
Hello,
On Tue, Sep 13, 2011 at 05:25:19PM -0300, Fabio Estevam wrote:
> Currently framebuffer and MMC devices are registered even if their associated
> GPIO pins fail to be requested.
Is this a real or only theoretic problem? (For me (or later Sascha) to
judge if it should go in before 3.2.)
> diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> index 3f86e7a..e5c66a2 100644
> --- a/arch/arm/mach-mxs/mach-mx28evk.c
> +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> @@ -353,7 +353,7 @@ static struct mxs_mmc_platform_data mx28evk_mmc_pdata[] __initdata = {
>
> static void __init mx28evk_init(void)
> {
> - int ret;
> + int ret, gpio_lcd_error;
>
> mxs_iomux_setup_multiple_pads(mx28evk_pads, ARRAY_SIZE(mx28evk_pads));
>
> @@ -378,18 +378,23 @@ static void __init mx28evk_init(void)
> }
>
> ret = gpio_request_one(MX28EVK_LCD_ENABLE, GPIOF_DIR_OUT, "lcd-enable");
> - if (ret)
> + if (ret) {
> pr_warn("failed to request gpio lcd-enable: %d\n", ret);
> + gpio_lcd_error = 1;
> + }
> else
> gpio_set_value(MX28EVK_LCD_ENABLE, 1);
>
> ret = gpio_request_one(MX28EVK_BL_ENABLE, GPIOF_DIR_OUT, "bl-enable");
> - if (ret)
> + if (ret) {
> pr_warn("failed to request gpio bl-enable: %d\n", ret);
> + gpio_lcd_error = 1;
> + }
> else
> gpio_set_value(MX28EVK_BL_ENABLE, 1);
If it's not important which gpio failed, you can do:
ret = gpio_request_array(...)
if (ret)
pr_warn("failed to request gpio for lcd\n");
else
mx28_add_mxsfb(&mx28evk_mxsfb_pdata);
(Apart from the different message this differs in semantic when the 2nd
request fails. With my suggestion the first gpio is freed then which
seems cleaner.) I don't care much though.
> - mx28_add_mxsfb(&mx28evk_mxsfb_pdata);
> + if (!gpio_lcd_error)
> + mx28_add_mxsfb(&mx28evk_mxsfb_pdata);
>
> /* power on mmc slot by writing 0 to the gpio */
> ret = gpio_request_one(MX28EVK_MMC0_SLOT_POWER, GPIOF_OUT_INIT_LOW,
> @@ -402,8 +407,9 @@ static void __init mx28evk_init(void)
> "mmc1-slot-power");
> if (ret)
> pr_warn("failed to request gpio mmc1-slot-power: %d\n", ret);
> - mx28_add_mxs_mmc(1, &mx28evk_mmc_pdata[1]);
> -
> + else
> + mx28_add_mxs_mmc(1, &mx28evk_mmc_pdata[1]);
> +
> gpio_led_register_device(0, &mx28evk_led_data);
> }
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [patch] ARM: smpboot: Enable interrupts after marking CPU online/active
From: Vincent Guittot @ 2011-09-14 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E6FFF0E.4070302@am.sony.com>
On 14 September 2011 03:10, Frank Rowand <frank.rowand@am.sony.com> wrote:
> On 09/13/11 10:53, Russell King - ARM Linux wrote:
>> On Tue, Sep 13, 2011 at 07:22:16PM +0200, Vincent Guittot wrote:
>>> The assumption done in the 1st patch that smp_store_cpu_info can be
>>> delayed is no more true. The smp_store_cpu_info is now also used to
>>> store the cpu topology information
>>> (https://lkml.org/lkml/2011/7/5/209). This must be done before calling
>>> sched_init_smp, which will use this information for building
>>> sched_domain.
>>> If we move set_cpu_online before smp_store_cpu_info, sched_init_smp
>>> can be called before having called smp_store_cpu_info on all cpus.
>>
>> Right. ?We hold off returning from cpu_up() by watching for the upcoming
>> CPU setting its online bit.
>>
>> The bug which Thomas' patch introduces is to move the setting of that
>> before we've finished bringing the CPU up - specifically, allowing the
>> requesting CPU to continue while the brought-up CPU is still calibrating
>> loops_per_jiffy, and before it's stored that information and setup the
>> scheduler domain information.
>>
>> The other issue is that moving the marking of the CPU online in the
>> way Thomas has means that we then invite the delivery of IPIs to the
>> CPU which is still in the process of coming up. ?Whether that's an
>> issue depends on what the IPIs are.
>>
>> So, we must have the setting of CPU online _after_ we've setup the
>> scheduler domain information etc - so the following is a strict
>> ordering:
>>
>> 1. calibrate_delay()
>> 2. smp_store_cpu_info()
>> 3. set_cpu_online()
>>
>> Now, the question is do we need interrupts enabled to setup timers
>> via percpu_timer_setup() and calibrate delay. ?Can we move enabling
>> interrupts after smp_store_cpu_info(). ?IOW, instead of moving the
>> setting of cpu online before all this, can we move notify_cpu_starting()
>> and the enabling of _both_ interrupts after smp_store_cpu_info()...
>> No idea at the moment.
>
> Modified the patch from Thomas to move enabling interrupts after
> smp_store_cpu_info(), as suggested by Russell.
>
> Tested on RealView (3.0.1, 3.0.1-rt11), Panda (3.0.0, 3.0.3-rt12).
>
> The calibrate_delay() is platform specific, so be aware that there are
> more platforms that I did not test.
>
> Note that these kernel versions do not have the store_cpu_topology()
> that Vincent pointed out.
>
I have tested your patch on a snowball with a kernel based on 3.1-rc4
and cpu topology patch
> Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
> ---
> ?arch/arm/kernel/smp.c | ? 14 ? 7 + ? ? 7 - ? ? 0 !
> ?1 file changed, 7 insertions(+), 7 deletions(-)
>
> Index: b/arch/arm/kernel/smp.c
> ===================================================================
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -303,13 +303,6 @@ asmlinkage void __cpuinit secondary_star
> ? ? ? ?platform_secondary_init(cpu);
>
> ? ? ? ?/*
> - ? ? ? ?* Enable local interrupts.
> - ? ? ? ?*/
> - ? ? ? notify_cpu_starting(cpu);
> - ? ? ? local_irq_enable();
> - ? ? ? local_fiq_enable();
> -
> - ? ? ? /*
> ? ? ? ? * Setup the percpu timer for this CPU.
> ? ? ? ? */
> ? ? ? ?percpu_timer_setup();
> @@ -328,6 +321,13 @@ asmlinkage void __cpuinit secondary_star
> ? ? ? ? ? ? ? ?cpu_relax();
>
> ? ? ? ?/*
> + ? ? ? ?* Enable local interrupts.
> + ? ? ? ?*/
> + ? ? ? notify_cpu_starting(cpu);
> + ? ? ? local_irq_enable();
> + ? ? ? local_fiq_enable();
> +
> + ? ? ? /*
> ? ? ? ? * OK, it's off to the idle thread for us
> ? ? ? ? */
> ? ? ? ?cpu_idle();
>
>
^ permalink raw reply
* [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver
From: Barry Song @ 2011-09-14 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY3F+DMn2SxeO0chjpiMBkgLvSK5EVYMdhQsfQoZNZ4_7Q@mail.gmail.com>
Hi Jassi,
2011/9/8 Jassi Brar <jassisinghbrar@gmail.com>:
> On Thu, Sep 8, 2011 at 8:47 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>> On Thu, Sep 8, 2011 at 7:42 AM, Barry Song <21cnbao@gmail.com> wrote:
>>
>>>>> it is much different with primacell based DMA like pl080, pl330.
>>>>> prima2 has a self-defined DMAC IP. basically it is a 2D mode dma with
>>>>> two scales X and Y and direct way to start and stop DMA.
>>>>> every channel has fixed function to serve only one perpheral. so you
>>>>> find we have a filter id.
>>>> okay, what do you mean by 2D mode? Is it similar to what TI folks, Linus
>>>> W and Jassi Brar posted RFC's on?
>>>
>>> In SiRFprimaII 2-D DMA, the system memory space is interpreted
>>> as a 2-D layout instead of a linear 1-D layout. More specifically, the
>>> system memory can be considered as
>>> multiple data lines. The length of the data line is determined by the
>>> user-selected DMA_WIDTH register.
>>> The user can specify a data window that the user wants to access using
>>> four parameters:
>>> ? Start address
>>> ? X length
>>> ? Y length
>>> ? Width
>>>
>>> The idea of a 2-D DMA is shown in figure 2d-dma.png attached.
>>>
>>> If you specifies the Y length as 0 or the X length equals to the DMA
>>> width, then this 2-D DMA reduces to
>>> 1-D. If the user configures the X length greater than the DMA width,
>>> then the extra data is wrapped around
>>> to the next data line, this may corrupt the DMA transfer for
>>> multiple-line 2-D DMA. If this is a 1-D DMA, then
>>> there is no issue. The attached diagram 2d-dma2.png shows the
>>> wrap-around of the extra data in case the X length
>>> greater than DMA width.
>>
>> Sorry, the role of DMA_WIDTH is not clear to me yet.
>> In which case the user _must_ set {xlen > width} ?
>>
> Perhaps 2d-dma.PNG is inaccurate - it shouldn't depict any deltaX.
> Doesn't xlen and width always start together ? If no, please don't read ahead.
>
> According to figures, {xlen > width} is to be set _only_ when a transfer
> is divided into _exactly_ two chunks separated by gap _exactly_
> equal to length of the second chunk (an extremely rare case).
>
> Anyways, every case can be easily expressed using the generic api
> I proposed. See 'struct xfer_template' in https://lkml.org/lkml/2011/8/12/128
>
> Roughly speaking, the following should be done...
> Client driver :-
> **************
> For a 'Rectangular' transfer (2d-dma.PNG) :-
> ? ? ?xfer_template.numf = Ylen; ?/* height of rectangle */
> ? ? ?xfer_template.frame_size = 1;
> ? ? ?xfer_template.sgl[0].size = Xlen; /* width of rectangle */
> ? ? ?xfer_template.sgl[0].icg = start_addr_Y(n) - end_addr_Y(n-1);
For prima2:
xfer_template.numf = ylen + 1
xfer_template.frame_size = 1;
xfer_template.sgl[0].size = xlen;
xfer_template.sgl[0].icg = dma_width - xlen;
>
> For the "A Line and some" transfer (2d-dma2.PNG) :-
> ? ? ?xfer_template.numf = 1;
> ? ? ?xfer_template.frame_size = 2;
> ? ? ?xfer_template.sgl[0].size = xlen1; /* a line */
> ? ? ?xfer_template.sgl[1].size = xlen2; ?/* and some */
> ? ? ?xfer_template.sgl[0].icg = start_addr_Y(n) - end_addr_Y(n-1);
> ? ? ?xfer_template.sgl[1].icg = 0; /* doesn't matter */
>
> DMAC driver :-
> ***************
> ? ? ?if (xfer_template.frame_size == 1) {
> ? ? ? ? ? /* rectangle */
> ? ? ? ? ? schan->xlen = xfer_template.sgl[0].size;
> ? ? ? ? ? schan->width = schan->xlen + xfer_template.sgl[0].icg;
> ? ? ?} else if (xfer_template.frame_size == 2 &&
> ? ? ? ? ? ? ? ? ?xfer_template.numf == 1 &&
> ? ? ? ? ? ? ? ? ?xfer_template.sgl[1].size == xfer_template.sgl[0].icg){
> ? ? ? ? ? /* a line and some */
> ? ? ? ? ? schan->xlen = xfer_template.sgl[0].size + ?xfer_template.sgl[1].size.
> ? ? ? ? ? schan->width = xfer_template.sgl[0].size;
> ? ? ?} else {
> ? ? ? ? ? /* _Hardware_ doesn't support the transfer as such. *
> ? ? ? ? ? return -EINVAL;
> ? ? ?}
> ? ? ?schan->ylen = xfer_template.numf /* -1? */;
>
For prima2:
xfer_template.frame_size is always 1, then
schan->xlen = xfer_template.sgl[0].size;
schan->width = schan->xlen + xfer_template.sgl[0].icg;
Thanks
barry
^ permalink raw reply
* Fwd: Re: [PATCH v2 1/5] cpu_pm: Add cpu power management notifiers
From: Santosh @ 2011-09-14 6:45 UTC (permalink / raw)
To: linux-arm-kernel
(CC'ing linux-arch at vger.kernel.org with some explanation
as per Andrew's suggestion. The intention of CC'ing linux-arch
is to check if there is any other architecture apart from ARM
would benefit from these notifiers)
-------- Original Message --------
Subject: Re: [PATCH v2 1/5] cpu_pm: Add cpu power management notifiers
Date: Mon, 12 Sep 2011 10:32:07 +0530
From: Santosh <santosh.shilimkar@ti.com>
To: Andrew Morton <akpm@linux-foundation.org>
CC: linux-arm-kernel at lists.infradead.org, linux-kernel at vger.kernel.org,
linux at arm.linux.org.uk, ccross at android.com, rjw at sisk.pl, khilman at ti.com
On Saturday 10 September 2011 03:01 PM, Santosh wrote:
> Andrew,
>
> On Saturday 10 September 2011 04:26 AM, Andrew Morton wrote:
>> On Sat, 3 Sep 2011 20:09:11 +0530
>> Santosh Shilimkar<santosh.shilimkar@ti.com> wrote:
>
> [...]
>
>>
>> Have you identified which indivudual you hope/expect to merge this into
>> mainline?
>>
>> The code is presumably and hopefully applicable to architectures other
>> than ARM, yes? Can you suggest likely candidate architectures so we
>> can go off and bug the relevant maintainers to review it?
>>
> Sorry I missed above question in last email. Am not too sure but any
> arch which has CPU local timers, interrupt controller, Floating point
> co-processor etc, should be able to make use of it. So it's applicable
> to any architecture, but whether they want to use it, i don't know.
>
> As you noticed most of the ARM machine's are adapting to it.
> Along with generic patch, there are couple ARM drivers adapting
> to make use of it. That was the reason I was pushing this series
> via Russell's tree.
>
Here is an updated patch addressing your comments.
Attaching the same in case mailer eats spaces.
From 6a0ef5d42da459d9eba0a5f396e6d9a95d3f94ff Mon Sep 17 00:00:00 2001
From: Colin Cross <ccross@android.com>
Date: Thu, 10 Feb 2011 02:04:45 -0800
Subject: [PATCH 1/5] cpu_pm: Add cpu power management notifiers
During some CPU power modes entered during idle, hotplug and
suspend, peripherals located in the CPU power domain, such as
the GIC, localtimers, and VFP, may be powered down. Add a
notifier chain that allows drivers for those peripherals to
be notified before and after they may be reset.
Notified drivers can include VFP co-processor, interrupt controller
and it's PM extensions, local CPU timers context save/restore which
shouldn't be interrupted. Hence CPU PM event APIs must be called
with interrupts disabled.
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Kevin Hilman <khilman@ti.com>
---
include/linux/cpu_pm.h | 109 ++++++++++++++++++++++++++
kernel/Makefile | 1 +
kernel/cpu_pm.c | 200
++++++++++++++++++++++++++++++++++++++++++++++++
kernel/power/Kconfig | 4 +
4 files changed, 314 insertions(+), 0 deletions(-)
create mode 100644 include/linux/cpu_pm.h
create mode 100644 kernel/cpu_pm.c
diff --git a/include/linux/cpu_pm.h b/include/linux/cpu_pm.h
new file mode 100644
index 0000000..455b233
--- /dev/null
+++ b/include/linux/cpu_pm.h
@@ -0,0 +1,109 @@
+/*
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * Author:
+ * Colin Cross <ccross@android.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_CPU_PM_H
+#define _LINUX_CPU_PM_H
+
+#include <linux/kernel.h>
+#include <linux/notifier.h>
+
+/*
+ * When a CPU goes to a low power state that turns off power to the CPU's
+ * power domain, the contents of some blocks (floating point coprocessors,
+ * interrupt controllers, caches, timers) in the same power domain can
+ * be lost. The cpm_pm notifiers provide a method for platform idle,
suspend,
+ * and hotplug implementations to notify the drivers for these blocks that
+ * they may be reset.
+ *
+ * All cpu_pm notifications must be called with interrupts disabled.
+ *
+ * The notifications are split into two classes: CPU notifications and CPU
+ * cluster notifications.
+ *
+ * CPU notifications apply to a single CPU and must be called on the
affected
+ * CPU. They are used to save per-cpu context for affected blocks.
+ *
+ * CPU cluster notifications apply to all CPUs in a single power
domain. They
+ * are used to save any global context for affected blocks, and must be
called
+ * after all the CPUs in the power domain have been notified of the low
power
+ * state.
+ */
+
+/*
+ * Event codes passed as unsigned long val to notifier calls
+ */
+enum cpu_pm_event {
+ /* A single cpu is entering a low power state */
+ CPU_PM_ENTER,
+
+ /* A single cpu failed to enter a low power state */
+ CPU_PM_ENTER_FAILED,
+
+ /* A single cpu is exiting a low power state */
+ CPU_PM_EXIT,
+
+ /* A cpu power domain is entering a low power state */
+ CPU_CLUSTER_PM_ENTER,
+
+ /* A cpu power domain failed to enter a low power state */
+ CPU_CLUSTER_PM_ENTER_FAILED,
+
+ /* A cpu power domain is exiting a low power state */
+ CPU_CLUSTER_PM_EXIT,
+};
+
+#ifdef CONFIG_CPU_PM
+int cpu_pm_register_notifier(struct notifier_block *nb);
+int cpu_pm_unregister_notifier(struct notifier_block *nb);
+int cpu_pm_enter(void);
+int cpu_pm_exit(void);
+int cpu_cluster_pm_enter(void);
+int cpu_cluster_pm_exit(void);
+
+#else
+
+static inline int cpu_pm_register_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int cpu_pm_unregister_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int cpu_pm_enter(void)
+{
+ return 0;
+}
+
+static inline int cpu_pm_exit(void)
+{
+ return 0;
+}
+
+static inline int cpu_cluster_pm_enter(void)
+{
+ return 0;
+}
+
+static inline int cpu_cluster_pm_exit(void)
+{
+ return 0;
+}
+#endif
+#endif
diff --git a/kernel/Makefile b/kernel/Makefile
index eca595e..988cb3d 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_RING_BUFFER) += trace/
obj-$(CONFIG_TRACEPOINTS) += trace/
obj-$(CONFIG_SMP) += sched_cpupri.o
obj-$(CONFIG_IRQ_WORK) += irq_work.o
+obj-$(CONFIG_CPU_PM) += cpu_pm.o
obj-$(CONFIG_PERF_EVENTS) += events/
diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c
new file mode 100644
index 0000000..4d1ff4a
--- /dev/null
+++ b/kernel/cpu_pm.c
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * Author:
+ * Colin Cross <ccross@android.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/cpu_pm.h>
+#include <linux/module.h>
+#include <linux/notifier.h>
+#include <linux/spinlock.h>
+
+static DEFINE_RWLOCK(cpu_pm_notifier_lock);
+static RAW_NOTIFIER_HEAD(cpu_pm_notifier_chain);
+
+static int cpu_pm_notify(enum cpu_pm_event event, int nr_to_call, int
*nr_calls)
+{
+ int ret;
+
+ ret = __raw_notifier_call_chain(&cpu_pm_notifier_chain, event, NULL,
+ nr_to_call, nr_calls);
+
+ return notifier_to_errno(ret);
+}
+
+/**
+ * cpu_pm_register_notifier - register a driver with cpu_pm
+ * @nb: notifier block to register
+ *
+ * Add a driver to a list of drivers that are notified about
+ * CPU and CPU cluster low power entry and exit.
+ *
+ * This function may sleep, and has the same return conditions as
+ * raw_notifier_chain_register.
+ */
+int cpu_pm_register_notifier(struct notifier_block *nb)
+{
+ unsigned long flags;
+ int ret;
+
+ write_lock_irqsave(&cpu_pm_notifier_lock, flags);
+ ret = raw_notifier_chain_register(&cpu_pm_notifier_chain, nb);
+ write_unlock_irqrestore(&cpu_pm_notifier_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpu_pm_register_notifier);
+
+/**
+ * cpu_pm_unregister_notifier - unregister a driver with cpu_pm
+ * @nb: notifier block to be unregistered
+ *
+ * Remove a driver from the CPU PM notifier list.
+ *
+ * This function may sleep, and has the same return conditions as
+ * raw_notifier_chain_unregister.
+ */
+int cpu_pm_unregister_notifier(struct notifier_block *nb)
+{
+ unsigned long flags;
+ int ret;
+
+ write_lock_irqsave(&cpu_pm_notifier_lock, flags);
+ ret = raw_notifier_chain_unregister(&cpu_pm_notifier_chain, nb);
+ write_unlock_irqrestore(&cpu_pm_notifier_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpu_pm_unregister_notifier);
+
+/**
+ * cpm_pm_enter - CPU low power entry notifier
+ *
+ * Notifies listeners that a single CPU is entering a low power state
that may
+ * cause some blocks in the same power domain as the cpu to reset.
+ *
+ * Must be called on the affected CPU with interrupts disabled.
Platform is
+ * responsible for ensuring that cpu_pm_enter is not called twice on
the same
+ * CPU before cpu_pm_exit is called. Notified drivers can include VFP
+ * co-processor, interrupt controller and it's PM extensions, local CPU
+ * timers context save/restore which shouldn't be interrupted. Hence it
+ * must be called with interrupts disabled.
+ *
+ * Return conditions are same as __raw_notifier_call_chain.
+ */
+int cpu_pm_enter(void)
+{
+ int nr_calls;
+ int ret = 0;
+
+ read_lock(&cpu_pm_notifier_lock);
+ ret = cpu_pm_notify(CPU_PM_ENTER, -1, &nr_calls);
+ if (ret)
+ /*
+ * Inform listeners (nr_calls - 1) about failure of CPU PM
+ * PM entry who are notified earlier to prepare for it.
+ */
+ cpu_pm_notify(CPU_PM_ENTER_FAILED, nr_calls - 1, NULL);
+ read_unlock(&cpu_pm_notifier_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpu_pm_enter);
+
+/**
+ * cpm_pm_exit - CPU low power exit notifier
+ *
+ * Notifies listeners that a single CPU is exiting a low power state
that may
+ * have caused some blocks in the same power domain as the cpu to reset.
+ *
+ * Notified drivers can include VFP co-processor, interrupt controller
+ * and it's PM extensions, local CPU timers context save/restore which
+ * shouldn't be interrupted. Hence it must be called with interrupts
disabled.
+ *
+ * Return conditions are same as __raw_notifier_call_chain.
+ */
+int cpu_pm_exit(void)
+{
+ int ret;
+
+ read_lock(&cpu_pm_notifier_lock);
+ ret = cpu_pm_notify(CPU_PM_EXIT, -1, NULL);
+ read_unlock(&cpu_pm_notifier_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpu_pm_exit);
+
+/**
+ * cpm_cluster_pm_enter - CPU cluster low power entry notifier
+ *
+ * Notifies listeners that all cpus in a power domain are entering a
low power
+ * state that may cause some blocks in the same power domain to reset.
+ *
+ * Must be called after cpu_pm_enter has been called on all cpus in the
power
+ * domain, and before cpu_pm_exit has been called on any cpu in the power
+ * domain. Notified drivers can include VFP co-processor, interrupt
controller
+ * and it's PM extensions, local CPU timers context save/restore which
+ * shouldn't be interrupted. Hence it must be called with interrupts
disabled.
+ *
+ * Must be called with interrupts disabled.
+ *
+ * Return conditions are same as __raw_notifier_call_chain.
+ */
+int cpu_cluster_pm_enter(void)
+{
+ int nr_calls;
+ int ret = 0;
+
+ read_lock(&cpu_pm_notifier_lock);
+ ret = cpu_pm_notify(CPU_CLUSTER_PM_ENTER, -1, &nr_calls);
+ if (ret)
+ /*
+ * Inform listeners (nr_calls - 1) about failure of CPU cluster
+ * PM entry who are notified earlier to prepare for it.
+ */
+ cpu_pm_notify(CPU_CLUSTER_PM_ENTER_FAILED, nr_calls - 1, NULL);
+ read_unlock(&cpu_pm_notifier_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpu_cluster_pm_enter);
+
+/**
+ * cpm_cluster_pm_exit - CPU cluster low power exit notifier
+ *
+ * Notifies listeners that all cpus in a power domain are exiting form a
+ * low power state that may have caused some blocks in the same power
domain
+ * to reset.
+ *
+ * Must be called after cpu_pm_exit has been called on all cpus in the
power
+ * domain, and before cpu_pm_exit has been called on any cpu in the power
+ * domain. Notified drivers can include VFP co-processor, interrupt
controller
+ * and it's PM extensions, local CPU timers context save/restore which
+ * shouldn't be interrupted. Hence it must be called with interrupts
disabled.
+ *
+ * Return conditions are same as __raw_notifier_call_chain.
+ */
+int cpu_cluster_pm_exit(void)
+{
+ int ret;
+
+ read_lock(&cpu_pm_notifier_lock);
+ ret = cpu_pm_notify(CPU_CLUSTER_PM_EXIT, -1, NULL);
+ read_unlock(&cpu_pm_notifier_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpu_cluster_pm_exit);
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 3744c59..80a8597 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -235,3 +235,7 @@ config PM_GENERIC_DOMAINS
config PM_GENERIC_DOMAINS_RUNTIME
def_bool y
depends on PM_RUNTIME && PM_GENERIC_DOMAINS
+
+config CPU_PM
+ bool
+ depends on SUSPEND || CPU_IDLE
--
1.7.4.1
Regards
Santosh
^ permalink raw reply related
* [PATCH] ARM: CSR: call l2x0_of_init to init L2 cache of SiRFprimaII
From: Arnd Bergmann @ 2011-09-14 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E6F9A95.1010109@gmail.com>
On Tuesday 13 September 2011 13:01:57 Rob Herring wrote:
> On 09/13/2011 11:35 AM, Arnd Bergmann wrote:
> > On Tuesday 13 September 2011, Rob Herring wrote:
> >> I have it in init_irq as I need the outer flush to work for SMP init.
> >> init_machine may be okay as well, but as early as possible is probably
> >> best. It depends if you are turning on the L2 or it is already on when
> >> you boot.
> >>
> >> You could also just check your machine compatible string in this
> >> function, but calling it from a machine specific function is a cleaner
> >> solution.
> >
> > I would suggest checking the specific "compatible" string of the l2x0
> > device node, and making sure that you have something specific to
> > prima2 in it.
> >
> > That would easily let us combine this function with the respective
> > l2x0 init code for other dt based platforms later, by checking
> > multiple compatible values.
> >
> The function does that, but you have a problem when multiple platforms
> have a "arm,pl310-cache" string. Or are you saying we need to have
> "csr,prima2-pl310-cache" and strings for every platform out there with a
> pl310?
That was my suggestion, yes. At least for every platform that needs any
sort of nonstandard setup for l2 cache.
In the end it's a question of how you look at it: Do you set up the pl310
differently on one platform from another because you say it's a different
pl310 when it has different requirements, or do you say that all pl310 are
identical and there is a system-wide policy that requires you to set it
up in a specific way?
Arnd
^ permalink raw reply
* [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
From: Jassi Brar @ 2011-09-14 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315980099.26251.498.camel@vkoul-udesk3>
On Wed, Sep 14, 2011 at 11:31 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Fri, 2011-09-02 at 09:44 +0900, Boojin Kim wrote:
>> This patchset adds support DMA generic APIs for samsung DMA.
>>
>> The changes from V7 is following:
>> - Divides patch file.
>> ? : The 03 patch on V7 patchset is divided into the 03 and 04 patch on V8 patchset.
>> ? ? The O3 patch is only for DMA_SLAVE_CONFIG command.
>> ? ? The 04 patch is only for DMA_TERMINATE_ALL command.
>> - Code clean-up
>> ? : Remove unnecessary code on 05 patch.
>>
>> [PATCH v8 01/16] DMA: PL330: Add support runtime PM for PL330 DMAC
>> [PATCH v8 02/16] DMA: PL330: Update PL330 DMA API driver
>> [PATCH v8 03/16] DMA: PL330: Support DMA_SLAVE_CONFIG command
>> [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling DMA_TERMINATE_ALL command
>> [PATCH v8 05/16] DMA: PL330: Add DMA_CYCLIC capability
>> [PATCH v8 06/16] ARM: SAMSUNG: Update to use PL330-DMA driver
>> [PATCH v8 07/16] ARM: SAMSUNG: Add common DMA operations
>> [PATCH v8 08/16] ARM: EXYNOS4: Use generic DMA PL330 driver
>> [PATCH v8 09/16] ARM: S5PV210: Use generic DMA PL330 driver
>> [PATCH v8 10/16] ARM: S5PC100: Use generic DMA PL330 driver
>> [PATCH v8 11/16] ARM: S5P64X0: Use generic DMA PL330 driver
>> [PATCH v8 12/16] ARM: SAMSUNG: Remove S3C-PL330-DMA driver
>> [PATCH v8 13/16] spi/s3c64xx: Add support DMA engine API
>> [PATCH v8 14/16] spi/s3c64xx: Merge dma control code
>> [PATCH v8 15/16] ASoC: Samsung: Update DMA interface
>> [PATCH v8 16/16] ARM: SAMSUNG: Remove Samsung specific enum type for dma direction
> Thanks,
>
> I have pushed these into my samsung-dma branch, Fixed the typos in the
> changelog of patch 4.
>
> Please check and let me know if all are fine, I will push them to my
> next tomorrow
>
> If anyone has concerns on this series please let me know by tomorrow
>
I have no concern about patches modifying samsung specific code.
Of the patches touching common pl330 code, I had acked Patch-1,2,3 & 5
in previous revisions already. So for them, you may add my
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
The changelog for [PATCH v8 04/16] is misleading - we don't need any
modification for the reason mentioned in changelog. But the modification
has positive side-effect of preventing callbacks during terminate_all which
is no way understood from the changelog. So I would like to changelog
corrected.
thanks,
-jassi
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
From: Santosh @ 2011-09-14 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2VFSwL7hCmGpHXx_UKKwK3dbhNRGQB1bwvcD-YC1Qj-AQ@mail.gmail.com>
On Wednesday 14 September 2011 11:38 AM, Kyungmin Park wrote:
> Hi Siarhei,
>
> Interesting feature, and it's not samsung soc issue, so add the arm
> mailing list.
> It checked and the see the read performance improvement from 868MiB/s
> to 981MiB/s with lmbench.
> It's helpful to test other SoC., e.g., OMAP4, STE and so on.
>
> BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit
> and should be zero (SBZ).
>
That's because not all PL310 versions double line fill.
Regards
santosh
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
From: Kyungmin Park @ 2011-09-14 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315894031-9579-1-git-send-email-siarhei.siamashka@gmail.com>
Hi Siarhei,
Interesting feature, and it's not samsung soc issue, so add the arm
mailing list.
It checked and the see the read performance improvement from 868MiB/s
to 981MiB/s with lmbench.
It's helpful to test other SoC., e.g., OMAP4, STE and so on.
BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit
and should be zero (SBZ).
Thank you,
Kyungmin Park
On Tue, Sep 13, 2011 at 3:07 PM, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> Setting "Double linefill enable" bit improves memcpy performance
> from ~750 MB/s to ~1150 MB/s when working with large buffers and
> also the performance of just anything which may need good memory
> bandwidth (for example, software rendered graphics).
>
> Additionally setting "Double linefill on WRAP read disable" bit
> compensates most of the random access latency increase.
>
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
> ---
> ?arch/arm/mach-exynos4/cpu.c | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
> index ba503c3..1afd25f 100644
> --- a/arch/arm/mach-exynos4/cpu.c
> +++ b/arch/arm/mach-exynos4/cpu.c
> @@ -238,7 +238,7 @@ static int __init exynos4_l2x0_cache_init(void)
> ? ? ? ?__raw_writel(0x110, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
>
> ? ? ? ?/* L2X0 Prefetch Control */
> - ? ? ? __raw_writel(0x30000007, S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
> + ? ? ? __raw_writel(0x78000007, S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
>
> ? ? ? ?/* L2X0 Power Control */
> ? ? ? ?__raw_writel(L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN,
> --
> 1.7.3.4
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
^ permalink raw reply
* [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
From: Vinod Koul @ 2011-09-14 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314924284-25554-1-git-send-email-boojin.kim@samsung.com>
On Fri, 2011-09-02 at 09:44 +0900, Boojin Kim wrote:
> This patchset adds support DMA generic APIs for samsung DMA.
>
> The changes from V7 is following:
> - Divides patch file.
> : The 03 patch on V7 patchset is divided into the 03 and 04 patch on V8 patchset.
> The O3 patch is only for DMA_SLAVE_CONFIG command.
> The 04 patch is only for DMA_TERMINATE_ALL command.
> - Code clean-up
> : Remove unnecessary code on 05 patch.
>
> [PATCH v8 01/16] DMA: PL330: Add support runtime PM for PL330 DMAC
> [PATCH v8 02/16] DMA: PL330: Update PL330 DMA API driver
> [PATCH v8 03/16] DMA: PL330: Support DMA_SLAVE_CONFIG command
> [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling DMA_TERMINATE_ALL command
> [PATCH v8 05/16] DMA: PL330: Add DMA_CYCLIC capability
> [PATCH v8 06/16] ARM: SAMSUNG: Update to use PL330-DMA driver
> [PATCH v8 07/16] ARM: SAMSUNG: Add common DMA operations
> [PATCH v8 08/16] ARM: EXYNOS4: Use generic DMA PL330 driver
> [PATCH v8 09/16] ARM: S5PV210: Use generic DMA PL330 driver
> [PATCH v8 10/16] ARM: S5PC100: Use generic DMA PL330 driver
> [PATCH v8 11/16] ARM: S5P64X0: Use generic DMA PL330 driver
> [PATCH v8 12/16] ARM: SAMSUNG: Remove S3C-PL330-DMA driver
> [PATCH v8 13/16] spi/s3c64xx: Add support DMA engine API
> [PATCH v8 14/16] spi/s3c64xx: Merge dma control code
> [PATCH v8 15/16] ASoC: Samsung: Update DMA interface
> [PATCH v8 16/16] ARM: SAMSUNG: Remove Samsung specific enum type for dma direction
Thanks,
I have pushed these into my samsung-dma branch, Fixed the typos in the
changelog of patch 4.
Please check and let me know if all are fine, I will push them to my
next tomorrow
If anyone has concerns on this series please let me know by tomorrow
--
~Vinod
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Inki Dae @ 2011-09-14 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGtE9fmbZ-_nV5Lr-x+W5hiGbLfk2GdFNzQgHwJ+hNvn-g@mail.gmail.com>
> -----Original Message-----
> From: Rob Clark [mailto:robdclark at gmail.com]
> Sent: Wednesday, September 14, 2011 11:26 AM
> To: Inki Dae
> Cc: Thomas Hellstrom; kyungmin.park at samsung.com; sw0312.kim at samsung.com;
> linux-arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>
> On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae <inki.dae@samsung.com> wrote:
> > Hi Thomas.
> >
> >> -----Original Message-----
> >> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
> >> Sent: Monday, September 12, 2011 3:32 PM
> >> To: Rob Clark
> >> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-
> >> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
> >> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> >>
> >> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
> >> > On 09/10/2011 07:31 PM, Rob Clark wrote:
> >> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
> >> >> Hellstrom<thomas@shipmail.org> ?wrote:
> >> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
> >> >>>> This patch is a DRM Driver for Samsung SoC Exynos4210 and now
> enables
> >> >>>> only FIMD yet but we will add HDMI support also in the future.
> >> >>>>
> >> >>>> from now on, I will remove RFC prefix because I think we have got
> >> >>>> comments
> >> >>>> enough.
> >> >>>>
> >> >>>> this patch is based on git repository below:
> >> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
> >> >>>> branch name: drm-next
> >> >>>> commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> >> >>>>
> >> >>>> you can refer to our working repository below:
> >> >>>> http://git.infradead.org/users/kmpark/linux-2.6-samsung
> >> >>>> branch name: samsung-drm
> >> >>>>
> >> >>>> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
> >> >>>> based on Linux framebuffer) but couldn't so because lowlevel codes
> >> >>>> of s3c-fb.c are included internally and so FIMD module of this
> >> >>>> driver has
> >> >>>> its own lowlevel codes.
> >> >>>>
> >> >>>> We used GEM framework for buffer management and DMA
> APIs(dma_alloc_*)
> >> >>>> for buffer allocation. by using DMA API, we could use CMA later.
> >> >>>>
> >> >>>> Refer to this link for CMA(Continuous Memory Allocator):
> >> >>>> http://lkml.org/lkml/2011/7/20/45
> >> >>>>
> >> >>>> this driver supports only physically continuous memory(non-iommu).
> >> >>>>
> >> >>>> Links to previous versions of the patchset:
> >> >>>> v1:< ? ?https://lwn.net/Articles/454380/>
> >> >>>> v2:< ? ?http://www.spinics.net/lists/kernel/msg1224275.html>
> >> >>>> v3:< ? ?http://www.gossamer-
> threads.com/lists/linux/kernel/1423684>
> >> >>>>
> >> >>>> Changelog v2:
> >> >>>> DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> >> >>>>
> >> >>>> ? ? ?this feature maps user address space to physical memory
> region
> >> >>>> ? ? ?once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP
> ioctl.
> >> >>>>
> >> >>>> DRM: code clean and add exception codes.
> >> >>>>
> >> >>>> Changelog v3:
> >> >>>> DRM: Support multiple irq.
> >> >>>>
> >> >>>> ? ? ?FIMD and HDMI have their own irq handler but DRM Framework
> can
> >> >>>> regiter
> >> >>>> ? ? ?only one irq handler this patch supports mutiple irq for
> >> >>>> Samsung SoC.
> >> >>>>
> >> >>>> DRM: Consider modularization.
> >> >>>>
> >> >>>> ? ? ?each DRM, FIMD could be built as a module.
> >> >>>>
> >> >>>> DRM: Have indenpendent crtc object.
> >> >>>>
> >> >>>> ? ? ?crtc isn't specific to SoC Platform so this patch gets a crtc
> >> >>>> ? ? ?to be used as common object.
> >> >>>> ? ? ?created crtc could be attached to any encoder object.
> >> >>>>
> >> >>>> DRM: code clean and add exception codes.
> >> >>>>
> >> >>>> Changelog v4:
> >> >>>> DRM: remove is_defult from samsung_fb.
> >> >>>>
> >> >>>> ? ? ?is_default isn't used for default framebuffer.
> >> >>>>
> >> >>>> DRM: code refactoring to fimd module.
> >> >>>> ? ? ?this patch is be considered with multiple display objects and
> >> >>>> ? ? ?would use its own request_irq() to register a irq handler
> >> >>>> instead of
> >> >>>> ? ? ?drm framework's one.
> >> >>>>
> >> >>>> DRM: remove find_samsung_drm_gem_object()
> >> >>>>
> >> >>>> DRM: move kernel private data structures and definitions to driver
> >> >>>> folder.
> >> >>>>
> >> >>>> ? ? ?samsung_drm.h would contain only public information for
> > userspace
> >> >>>> ? ? ?ioctl interface.
> >> >>>>
> >> >>>> DRM: code refactoring to gem modules.
> >> >>>> ? ? ?buffer module isn't dependent of gem module anymore.
> >> >>>>
> >> >>>> DRM: fixed security issue.
> >> >>>>
> >> >>>> DRM: remove encoder porinter from specific connector.
> >> >>>>
> >> >>>> ? ? ?samsung connector doesn't need to have generic encoder.
> >> >>>>
> >> >>>> DRM: code clean and add exception codes.
> >> >>>>
> >> >>>> Signed-off-by: Inki Dae<inki.dae@samsung.com>
> >> >>>> Signed-off-by: Joonyoung Shim<jy0922.shim@samsung.com>
> >> >>>> Signed-off-by: SeungWoo Kim<sw0312.kim@samsung.com>
> >> >>>> Signed-off-by: kyungmin.park<kyungmin.park@samsung.com>
> >> >>>> ---
> >> >>>>
> >> >>>> +static struct drm_ioctl_desc samsung_ioctls[] = {
> >> >>>> + ? ? ? DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
> >> >>>> samsung_drm_gem_create_ioctl,
> >> >>>> + ? ? ? ? ? ? ? ? ? ? ? DRM_UNLOCKED | DRM_AUTH),
> >> >>>>
> >> >>> Hi!
> >> >>>
> >> >>> With reference my previous security comment.
> >> >>>
> >> >>> Let's say you have a compromised video player running as a DRM
> >> >>> client, that
> >> >>> tries to repeatedly allocate huge GEM buffers...
> >> >>>
> >> >>> What will happen when all DMA memory is exhausted? Will this cause
> >> >>> other
> >> >>> device drivers to see an OOM, or only DRM?
> >> >>>
> >> >>> The old DRI model basically allowed any authorized DRI client to
> >> >>> exhaust
> >> >>> video ram or AGP memory, but never system memory. Newer DRI drivers
> >> >>> typically only allow DRI masters to do that.
> >> >>> as
> >> >>>
> >> >>> I don't think an authorized DRI client should be able to easily
> >> exhaust
> >> >>> resources (DMA memory) used by other device drivers causing them to
> >> >>> fail.
> >> >> I'm not entirely sure what else can be done, other than have a
> >> >> threshold on max MB allocatable of buffer memory..
> >> >
> >> > Yes, I think that's what needs to be done, and that threshold should
> >> > be low enough to keep other device drivers running in the worst
> >> > allocation case.
> >> >
> >> >> In the samsung driver case, he is only allocating scanout memory
> from
> >> >> CMA, so the limit will be the CMA region size.. beyond that you
> can't
> >> >> get physically contiguous memory. ?So I think this driver is safe.
> >> >
> >> > It's not really what well-behaved user-space drivers do that should
> be
> >> > a concern, but what compromized application *might* do that is a
> > concern.
> >>
> >> Hmm. I might have missed your point here. If the buffer allocation
> ioctl
> >> only allows allocating CMA memory, then I agree the driver fits the old
> >> DRI security model, as long as no other devices on the platform will
> >> ever use CMA.
> >>
> >> But in that case, there really should be a way for the driver to say
> >> "Hey, all CMA memory on this system is mine", in the same way
> >> traditional video drivers can claim the VRAM PCI resource.
> >>
> >
> > CMA could reserve memory region for a specific driver so DRM Client
> could
> > request memory allocation from only the region.
> >
> >> This is to avoid the possibility that future drivers that need CMA will
> >> be vulnerable to DOS-attacks from ill-behaved DRI clients.
> >>
> >
> > Thomas, if any application has root authority for ill-purpose then isn't
> it
> > possible to be vulnerable to DOS-attacks? I think DRM_AUTH means root
> > authority. I know DRM Framework gives any root application DRM_AUTH
> > authority for compatibility.
>
> DRM_AUTH just means that the client has authenticated w/ X11 (meaning
> that it has permission to connect to x server)..
>
Yes, I understood so. but see drm_open_helper() of drm_fops.c file please.
in this function, you can see a line below.
/* for compatibility root is always authenticated */
priv->authenticated = capable(CAP_SYS_ADMIN)
I think the code above says that any application with root permission is
authenticated.
> But I think that since memory allocation is limited to the size of the
> CMA region, that this puts a reasonable cap of the memory that can be
> allocated by the client. If this is a problem, it certainly isn't the
> worst problem. You could still limit via file permissions the users
> that can open the DRM device file, so it is really no worse than other
> devices like v4l2..
>
> BR,
> -R
>
>
> >> /Thomas
> >>
> >
> >
> >
^ permalink raw reply
* [PATCH 6/6] ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
From: Nicolas Pitre @ 2011-09-14 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-1-git-send-email-nico@fluxnic.net>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
The rule to copy this file doesn't have to be forced. However
lib1funcs.[So] have to be listed amongst the targets.
This prevents zImage from being recreated needlessly.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
---
arch/arm/boot/compressed/Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index ce2bef536e..db1fd260ed 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -112,7 +112,7 @@ endif
targets := vmlinux vmlinux.lds \
piggy.$(suffix_y) piggy.$(suffix_y).o \
- font.o font.c head.o misc.o $(OBJS)
+ lib1funcs.o lib1funcs.S font.o font.c head.o misc.o $(OBJS)
# Make sure files are removed during clean
extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)
@@ -147,7 +147,7 @@ LDFLAGS_vmlinux += -T
# For __aeabi_uidivmod
lib1funcs = $(obj)/lib1funcs.o
-$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE
+$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S
$(call cmd,shipped)
# We need to prevent any GOTOFF relocs being used with references
--
1.7.7-rc0
^ permalink raw reply related
* [PATCH 5/6] ARM: zImage: allow supplementing appended DTB with traditional ATAG data
From: Nicolas Pitre @ 2011-09-14 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-1-git-send-email-nico@fluxnic.net>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Some old bootloaders can't be updated to a device tree capable one,
yet they provide ATAGs with memory configuration, the ramdisk address,
the kernel cmdline string, etc. To allow a device tree enabled
kernel to be used with such bootloaders, it is necessary to convert those
ATAGs into FDT properties and fold them into the DTB appended to zImage.
Currently the following ATAGs are converted:
ATAG_CMDLINE
ATAG_MEM
ATAG_INITRD2
If the corresponding information already exists in the appended DTB, it
is replaced, otherwise the required node is created to hold it.
The code looks for ATAGs at the location pointed by the value of r2 upon
entry into the zImage code. If no ATAGs are found there, an attempt at
finding ATAGs at the typical 0x100 offset from start of RAM is made.
Otherwise the DTB is left unchanged.
Thisstarted from an older patch from John Bonesio <bones@secretlab.ca>,
with contributions from David Brown <davidb@codeaurora.org>.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
---
arch/arm/Kconfig | 11 ++++
arch/arm/boot/compressed/.gitignore | 9 +++
arch/arm/boot/compressed/Makefile | 21 ++++++-
arch/arm/boot/compressed/atags_to_fdt.c | 97 +++++++++++++++++++++++++++++++
arch/arm/boot/compressed/head.S | 32 ++++++++++
arch/arm/boot/compressed/libfdt_env.h | 15 +++++
6 files changed, 183 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/compressed/atags_to_fdt.c
create mode 100644 arch/arm/boot/compressed/libfdt_env.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 83323c2b1f..4ea9974bc7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1789,6 +1789,17 @@ config ARM_APPENDED_DTB
(dtb) appended to zImage
(e.g. cat zImage <filename>.dtb > zImage_w_dtb).
+config ARM_ATAG_DTB_COMPAT
+ bool "Supplement the appended DTB with traditional ATAG information"
+ depends on ARM_APPENDED_DTB
+ help
+ Some old bootloaders can't be updated to a DTB capable one, yet
+ they provide ATAGs with memory configuration, the ramdisk address,
+ the kernel cmdline string, etc. To allow a device tree enabled
+ kernel to be used with such bootloaders, this option allows
+ zImage to extract the information from the ATAG list and store it
+ at run time into the appended DTB.
+
config CMDLINE
string "Default kernel command string"
default ""
diff --git a/arch/arm/boot/compressed/.gitignore b/arch/arm/boot/compressed/.gitignore
index c6028967d3..e0936a1485 100644
--- a/arch/arm/boot/compressed/.gitignore
+++ b/arch/arm/boot/compressed/.gitignore
@@ -5,3 +5,12 @@ piggy.lzo
piggy.lzma
vmlinux
vmlinux.lds
+
+# borrowed libfdt files
+fdt.c
+fdt.h
+fdt_ro.c
+fdt_rw.c
+fdt_wip.c
+libfdt.h
+libfdt_internal.h
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index c20ddc69d9..ce2bef536e 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -93,19 +93,36 @@ suffix_$(CONFIG_KERNEL_GZIP) = gzip
suffix_$(CONFIG_KERNEL_LZO) = lzo
suffix_$(CONFIG_KERNEL_LZMA) = lzma
+# Borrowed libfdt files for the ATAG compatibility mode
+
+libfdt := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c
+libfdt_hdrs := fdt.h libfdt.h libfdt_internal.h
+
+libfdt_objs := $(addsuffix .o, $(basename $(libfdt)))
+
+$(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/libfdt/%
+ $(call cmd,shipped)
+
+$(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
+ $(addprefix $(obj)/,$(libfdt_hdrs))
+
+ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
+OBJS += $(libfdt_objs) atags_to_fdt.o
+endif
+
targets := vmlinux vmlinux.lds \
piggy.$(suffix_y) piggy.$(suffix_y).o \
font.o font.c head.o misc.o $(OBJS)
# Make sure files are removed during clean
-extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S
+extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)
ifeq ($(CONFIG_FUNCTION_TRACER),y)
ORIG_CFLAGS := $(KBUILD_CFLAGS)
KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
endif
-ccflags-y := -fpic -fno-builtin
+ccflags-y := -fpic -fno-builtin -I$(obj)
asflags-y := -Wa,-march=all
# Supply kernel BSS size to the decompressor via a linker symbol.
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
new file mode 100644
index 0000000000..e0f637d3e8
--- /dev/null
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -0,0 +1,97 @@
+#include <asm/setup.h>
+#include <libfdt.h>
+
+static int node_offset(void *fdt, const char *node_path)
+{
+ int offset = fdt_path_offset(fdt, node_path);
+ if (offset == -FDT_ERR_NOTFOUND)
+ offset = fdt_add_subnode(fdt, 0, node_path);
+ return offset;
+}
+
+static int setprop(void *fdt, const char *node_path, const char *property,
+ uint32_t *val_array, int size)
+{
+ int offset = node_offset(fdt, node_path);
+ if (offset < 0)
+ return offset;
+ return fdt_setprop(fdt, offset, property, val_array, size);
+}
+
+static int setprop_string(void *fdt, const char *node_path,
+ const char *property, const char *string)
+{
+ int offset = node_offset(fdt, node_path);
+ if (offset < 0)
+ return offset;
+ return fdt_setprop_string(fdt, offset, property, string);
+}
+
+static int setprop_cell(void *fdt, const char *node_path,
+ const char *property, uint32_t val)
+{
+ int offset = node_offset(fdt, node_path);
+ if (offset < 0)
+ return offset;
+ return fdt_setprop_cell(fdt, offset, property, val);
+}
+
+/*
+ * Convert and fold provided ATAGs into the provided FDT.
+ *
+ * REturn values:
+ * = 0 -> pretend success
+ * = 1 -> bad ATAG (may retry with another possible ATAG pointer)
+ * < 0 -> error from libfdt
+ */
+int atags_to_fdt(void *atag_list, void *fdt, int total_space)
+{
+ struct tag *atag = atag_list;
+ uint32_t mem_reg_property[2 * NR_BANKS];
+ int memcount = 0;
+ int ret;
+
+ /* make sure we've got an aligned pointer */
+ if ((u32)atag_list & 0x3)
+ return 1;
+
+ /* if we get a DTB here we're done already */
+ if (*(u32 *)atag_list == fdt32_to_cpu(FDT_MAGIC))
+ return 0;
+
+ /* validate the ATAG */
+ if (atag->hdr.tag != ATAG_CORE ||
+ (atag->hdr.size != tag_size(tag_core) &&
+ atag->hdr.size != 2))
+ return 1;
+
+ /* let's give it all the room it could need */
+ ret = fdt_open_into(fdt, fdt, total_space);
+ if (ret < 0)
+ return ret;
+
+ for_each_tag(atag, atag_list) {
+ if (atag->hdr.tag == ATAG_CMDLINE) {
+ setprop_string(fdt, "/chosen", "bootargs",
+ atag->u.cmdline.cmdline);
+ } else if (atag->hdr.tag == ATAG_MEM) {
+ if (memcount >= sizeof(mem_reg_property)/4)
+ continue;
+ mem_reg_property[memcount++] = cpu_to_fdt32(atag->u.mem.start);
+ mem_reg_property[memcount++] = cpu_to_fdt32(atag->u.mem.size);
+ } else if (atag->hdr.tag == ATAG_INITRD2) {
+ uint32_t initrd_start, initrd_size;
+ initrd_start = atag->u.initrd.start;
+ initrd_size = atag->u.initrd.size;
+ setprop_cell(fdt, "/chosen", "linux,initrd-start",
+ initrd_start);
+ setprop_cell(fdt, "/chosen", "linux,initrd-end",
+ initrd_start + initrd_size);
+ }
+ }
+
+ if (memcount)
+ setprop(fdt, "/memory", "reg", mem_reg_property, 4*memcount);
+
+ return fdt_pack(fdt);
+}
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index ba5c552f8c..d79b83c5bd 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -246,6 +246,38 @@ restart: adr r0, LC0
cmp lr, r1
bne dtb_check_done @ not found
+#ifdef CONFIG_ARM_ATAG_DTB_COMPAT
+ /*
+ * OK... Let's do some funky business here.
+ * If we do have a DTB appended to zImage, and we do have
+ * an ATAG list around, we want the later to be translated
+ * and folded into the former here. To be on the safe side,
+ * let's temporarily move the stack away into the malloc
+ * area. No GOT fixup has occurred yet, but none of the
+ * code we're about to call uses any global variable.
+ */
+ add sp, sp, #0x10000
+ stmfd sp!, {r0-r3, ip, lr}
+ mov r0, r8
+ mov r1, r6
+ sub r2, sp, r6
+ bl atags_to_fdt
+
+ /*
+ * If returned value is 1, there is no ATAG at the location
+ * pointed by r8. Try the typical 0x100 offset from start
+ * of RAM and hope for the best.
+ */
+ cmp r0, #1
+ sub r0, r4, #(TEXT_OFFSET - 0x100)
+ mov r1, r6
+ sub r2, sp, r6
+ blne atags_to_fdt
+
+ ldmfd sp!, {r0-r3, ip, lr}
+ sub sp, sp, #0x10000
+#endif
+
mov r8, r6 @ use the appended device tree
/*
diff --git a/arch/arm/boot/compressed/libfdt_env.h b/arch/arm/boot/compressed/libfdt_env.h
new file mode 100644
index 0000000000..1f4e71876b
--- /dev/null
+++ b/arch/arm/boot/compressed/libfdt_env.h
@@ -0,0 +1,15 @@
+#ifndef _ARM_LIBFDT_ENV_H
+#define _ARM_LIBFDT_ENV_H
+
+#include <linux/types.h>
+#include <linux/string.h>
+#include <asm/byteorder.h>
+
+#define fdt16_to_cpu(x) be16_to_cpu(x)
+#define cpu_to_fdt16(x) cpu_to_be16(x)
+#define fdt32_to_cpu(x) be32_to_cpu(x)
+#define cpu_to_fdt32(x) cpu_to_be32(x)
+#define fdt64_to_cpu(x) be64_to_cpu(x)
+#define cpu_to_fdt64(x) cpu_to_be64(x)
+
+#endif
--
1.7.7-rc0
^ permalink raw reply related
* [PATCH 4/6] ARM: zImage: gather some string functions into string.c
From: Nicolas Pitre @ 2011-09-14 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-1-git-send-email-nico@fluxnic.net>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
This is a small subset of string functions needed by commits to come.
Except for memcpy() which is unchanged from its original location, their
implementation is meant to be small, and -Os is enforced to prevent gcc
from doing pointless loop unrolling.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
---
arch/arm/boot/compressed/Makefile | 4 +
arch/arm/boot/compressed/misc.c | 42 +------------
arch/arm/boot/compressed/string.c | 127 +++++++++++++++++++++++++++++++++++++
3 files changed, 132 insertions(+), 41 deletions(-)
create mode 100644 arch/arm/boot/compressed/string.c
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 4867647b97..c20ddc69d9 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -26,6 +26,10 @@ HEAD = head.o
OBJS += misc.o decompress.o
FONTC = $(srctree)/drivers/video/console/font_acorn_8x8.c
+# string library code (-Os is enforced to keep it much smaller)
+OBJS += string.o
+CFLAGS_string.o := -Os
+
#
# Architecture dependencies
#
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 832d37236c..8e2a8fca5e 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -18,14 +18,9 @@
unsigned int __machine_arch_type;
-#define _LINUX_STRING_H_
-
#include <linux/compiler.h> /* for inline */
-#include <linux/types.h> /* for size_t */
-#include <linux/stddef.h> /* for NULL */
+#include <linux/types.h>
#include <linux/linkage.h>
-#include <asm/string.h>
-
static void putstr(const char *ptr);
extern void error(char *x);
@@ -101,41 +96,6 @@ static void putstr(const char *ptr)
flush();
}
-
-void *memcpy(void *__dest, __const void *__src, size_t __n)
-{
- int i = 0;
- unsigned char *d = (unsigned char *)__dest, *s = (unsigned char *)__src;
-
- for (i = __n >> 3; i > 0; i--) {
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- }
-
- if (__n & 1 << 2) {
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- *d++ = *s++;
- }
-
- if (__n & 1 << 1) {
- *d++ = *s++;
- *d++ = *s++;
- }
-
- if (__n & 1)
- *d++ = *s++;
-
- return __dest;
-}
-
/*
* gzip declarations
*/
diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
new file mode 100644
index 0000000000..36e53ef920
--- /dev/null
+++ b/arch/arm/boot/compressed/string.c
@@ -0,0 +1,127 @@
+/*
+ * arch/arm/boot/compressed/string.c
+ *
+ * Small subset of simple string routines
+ */
+
+#include <linux/string.h>
+
+void *memcpy(void *__dest, __const void *__src, size_t __n)
+{
+ int i = 0;
+ unsigned char *d = (unsigned char *)__dest, *s = (unsigned char *)__src;
+
+ for (i = __n >> 3; i > 0; i--) {
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ }
+
+ if (__n & 1 << 2) {
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ *d++ = *s++;
+ }
+
+ if (__n & 1 << 1) {
+ *d++ = *s++;
+ *d++ = *s++;
+ }
+
+ if (__n & 1)
+ *d++ = *s++;
+
+ return __dest;
+}
+
+void *memmove(void *__dest, __const void *__src, size_t count)
+{
+ unsigned char *d = __dest;
+ const unsigned char *s = __src;
+
+ if (__dest == __src)
+ return __dest;
+
+ if (__dest < __src)
+ return memcpy(__dest, __src, count);
+
+ while (count--)
+ d[count] = s[count];
+ return __dest;
+}
+
+size_t strlen(const char *s)
+{
+ const char *sc = s;
+
+ while (*sc != '\0')
+ sc++;
+ return sc - s;
+}
+
+int memcmp(const void *cs, const void *ct, size_t count)
+{
+ const unsigned char *su1 = cs, *su2 = ct, *end = su1 + count;
+ int res = 0;
+
+ while (su1 < end) {
+ res = *su1++ - *su2++;
+ if (res)
+ break;
+ }
+ return res;
+}
+
+int strcmp(const char *cs, const char *ct)
+{
+ unsigned char c1, c2;
+ int res = 0;
+
+ do {
+ c1 = *cs++;
+ c2 = *ct++;
+ res = c1 - c2;
+ if (res)
+ break;
+ } while (c1);
+ return res;
+}
+
+void *memchr(const void *s, int c, size_t count)
+{
+ const unsigned char *p = s;
+
+ while (count--)
+ if ((unsigned char)c == *p++)
+ return (void *)(p - 1);
+ return NULL;
+}
+
+char *strchr(const char *s, int c)
+{
+ while (*s != (char)c)
+ if (*s++ == '\0')
+ return NULL;
+ return (char *)s;
+}
+
+#undef memset
+
+void *memset(void *s, int c, size_t count)
+{
+ char *xs = s;
+ while (count--)
+ *xs++ = c;
+ return s;
+}
+
+void __memzero(void *s, size_t count)
+{
+ memset(s, 0, count);
+}
--
1.7.7-rc0
^ permalink raw reply related
* [PATCH 3/6] ARM: zImage: make sure appended DTB doesn't get overwritten by kernel .bss
From: Nicolas Pitre @ 2011-09-14 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-1-git-send-email-nico@fluxnic.net>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
The appended DTB gets relocated with the decompressor code to get out
of the way of the decompressed kernel. However the kernel's .bss section
may be larger than the relocated code and data, and then the DTB gets
overwritten. Let's make sure the relocation takes care of moving zImage
far enough so no such conflict with .bss occurs.
Thanks to Tony Lindgren <tony@atomide.com> for figuring out this issue.
While at it, let's clean up the code a bit so that the wont_overwrite
symbol is used while determining if a conflict exists, making the above
change more precise as well as eliminating some ARM/THUMB alternates.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/compressed/Makefile | 3 +++
arch/arm/boot/compressed/head.S | 19 +++++++++++++++----
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 0c74a6fab9..4867647b97 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -104,6 +104,9 @@ endif
ccflags-y := -fpic -fno-builtin
asflags-y := -Wa,-march=all
+# Supply kernel BSS size to the decompressor via a linker symbol.
+KBSS_SZ = $(shell size $(obj)/../../../../vmlinux | awk 'END{print $$3}')
+LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
# Supply ZRELADDR to the decompressor via a linker symbol.
ifneq ($(CONFIG_AUTO_ZRELADDR),y)
LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 3ce5738ddb..ba5c552f8c 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -248,6 +248,18 @@ restart: adr r0, LC0
mov r8, r6 @ use the appended device tree
+ /*
+ * Make sure that the DTB doesn't end up in the final
+ * kernel's .bss area. To do so, we adjust the decompressed
+ * kernel size to compensate if that .bss size is larger
+ * than the relocated code.
+ */
+ ldr r5, =_kernel_bss_size
+ adr r1, wont_overwrite
+ sub r1, r6, r1
+ subs r1, r5, r1
+ addhi r9, r9, r1
+
/* Get the dtb's size */
ldr r5, [r6, #4]
#ifndef __ARMEB__
@@ -276,15 +288,14 @@ dtb_check_done:
* r10 = end of this image, including bss/stack/malloc space if non XIP
* We basically want:
* r4 - 16k page directory >= r10 -> OK
- * r4 + image length <= current position (pc) -> OK
+ * r4 + image length <= address of wont_overwrite -> OK
*/
add r10, r10, #16384
cmp r4, r10
bhs wont_overwrite
add r10, r4, r9
- ARM( cmp r10, pc )
- THUMB( mov lr, pc )
- THUMB( cmp r10, lr )
+ adr r9, wont_overwrite
+ cmp r10, r9
bls wont_overwrite
/*
--
1.7.7-rc0
^ permalink raw reply related
* [PATCH 2/6] ARM: zImage: Allow the appending of a device tree binary
From: Nicolas Pitre @ 2011-09-14 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-1-git-send-email-nico@fluxnic.net>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
This patch provides the ability to boot using a device tree that is appended
to the raw binary zImage (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
Signed-off-by: John Bonesio <bones@secretlab.ca>
[nico: adjusted to latest zImage changes plus additional cleanups]
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/Kconfig | 8 ++++
arch/arm/boot/compressed/head.S | 70 +++++++++++++++++++++++++++++++++++++--
2 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d922e..83323c2b1f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1781,6 +1781,14 @@ config ZBOOT_ROM_SH_MOBILE_SDHI
endchoice
+config ARM_APPENDED_DTB
+ bool "Use appended device tree blob to zImage"
+ depends on OF && !ZBOOT_ROM
+ help
+ With this option, the boot code will look for a device tree binary
+ (dtb) appended to zImage
+ (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
+
config CMDLINE
string "Default kernel command string"
default ""
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index e95a598960..3ce5738ddb 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -216,6 +216,59 @@ restart: adr r0, LC0
mov r10, r6
#endif
+ mov r5, #0 @ init dtb size to 0
+#ifdef CONFIG_ARM_APPENDED_DTB
+/*
+ * r0 = delta
+ * r2 = BSS start
+ * r3 = BSS end
+ * r4 = final kernel address
+ * r5 = appended dtb size (still unknown)
+ * r6 = _edata
+ * r7 = architecture ID
+ * r8 = atags/device tree pointer
+ * r9 = size of decompressed image
+ * r10 = end of this image, including bss/stack/malloc space if non XIP
+ * r11 = GOT start
+ * r12 = GOT end
+ * sp = stack pointer
+ *
+ * if there are device trees (dtb) appended to zImage, advance r10 so that the
+ * dtb data will get relocated along with the kernel if necessary.
+ */
+
+ ldr lr, [r6, #0]
+#ifndef __ARMEB__
+ ldr r1, =0xedfe0dd0 @ sig is 0xd00dfeed big endian
+#else
+ ldr r1, =0xd00dfeed
+#endif
+ cmp lr, r1
+ bne dtb_check_done @ not found
+
+ mov r8, r6 @ use the appended device tree
+
+ /* Get the dtb's size */
+ ldr r5, [r6, #4]
+#ifndef __ARMEB__
+ /* convert r5 (dtb size) to little endian */
+ eor r1, r5, r5, ror #16
+ bic r1, r1, #0x00ff0000
+ mov r5, r5, ror #8
+ eor r5, r5, r1, lsr #8
+#endif
+
+ /* preserve 64-bit alignment */
+ add r5, r5, #7
+ bic r5, r5, #7
+
+ /* relocate some pointers past the appended dtb */
+ add r6, r6, r5
+ add r10, r10, r5
+ add sp, sp, r5
+dtb_check_done:
+#endif
+
/*
* Check to see if we will overwrite ourselves.
* r4 = final kernel address
@@ -285,14 +338,16 @@ wont_overwrite:
* r2 = BSS start
* r3 = BSS end
* r4 = kernel execution address
+ * r5 = appended dtb size (0 if not present)
* r7 = architecture ID
* r8 = atags pointer
* r11 = GOT start
* r12 = GOT end
* sp = stack pointer
*/
- teq r0, #0
+ orrs r1, r0, r5
beq not_relocated
+
add r11, r11, r0
add r12, r12, r0
@@ -307,12 +362,21 @@ wont_overwrite:
/*
* Relocate all entries in the GOT table.
+ * Bump bss entries to _edata + dtb size
*/
1: ldr r1, [r11, #0] @ relocate entries in the GOT
- add r1, r1, r0 @ table. This fixes up the
- str r1, [r11], #4 @ C references.
+ add r1, r1, r0 @ This fixes up C references
+ cmp r1, r2 @ if entry >= bss_start &&
+ cmphs r3, r1 @ bss_end > entry
+ addhi r1, r1, r5 @ entry += dtb size
+ str r1, [r11], #4 @ next entry
cmp r11, r12
blo 1b
+
+ /* bump our bss pointers too */
+ add r2, r2, r5
+ add r3, r3, r5
+
#else
/*
--
1.7.7-rc0
^ permalink raw reply related
* [PATCH 1/6] ARM: zImage: ensure it is always a multiple of 64 bits in size
From: Nicolas Pitre @ 2011-09-14 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-1-git-send-email-nico@fluxnic.net>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
This is needed for proper alignment when the DTB appending feature
is used.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/compressed/vmlinux.lds.in | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/compressed/vmlinux.lds.in b/arch/arm/boot/compressed/vmlinux.lds.in
index 4e728834a1..4919f2ac8b 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.in
+++ b/arch/arm/boot/compressed/vmlinux.lds.in
@@ -51,6 +51,10 @@ SECTIONS
_got_start = .;
.got : { *(.got) }
_got_end = .;
+
+ /* ensure the zImage file size is always a multiple of 64 bits */
+ /* (without a dummy byte, ld just ignores the empty section) */
+ .pad : { BYTE(0); . = ALIGN(8); }
_edata = .;
. = BSS_START;
--
1.7.7-rc0
^ permalink raw reply related
* [PATCH 0/6] zImage improvements with DTB append and ATAG compatibility
From: Nicolas Pitre @ 2011-09-14 5:41 UTC (permalink / raw)
To: linux-arm-kernel
This is the latest incarnation of my patch series allowing a DTB
to be appended to zImage, including the ATAG conversion wrapper and
other minor cleanups.
This can also be pulled from:
git://git.linaro.org/people/nico/linux zImage_DTB_append
This works for me on the test setup I have.
ACKs/Tested-By's would be appreciated.
Nicolas
^ permalink raw reply
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
From: Shilimkar, Santosh @ 2011-09-14 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913202701.GF24252@atomide.com>
On Wed, Sep 14, 2011 at 1:57 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:22]:
>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>> and they can be drained only with stongly ordered accesses.
>
> This is not correct, strongly ordered access does not guarantee
> anything here. If it fixes issues, it's because it makes the writes
> to reach the device faster. Strongly ordered does not affect anything
> outside ARM, so the bus access won't change.
>
> The only real fix here is to do a read back of the device in question
> to guarantee the write got to the device.
>
>> There are two ports as below from MPU and both needs to be drained.
>> ? ? ? - MPU --> L3 T2ASYNC FIFO
>> ? ? ? - MPU --> DDR T2ASYNC FIFO
>>
>> Without the interconnect barriers, many issues have been observed
>> leading to system freeze, CPU deadlocks, random crashes with
>> register accesses, synchronization loss on initiators operating
>> on both interconnect port simultaneously.
>
> We had these issues for omap3 too. Adding a few read backs solved
> those kinds of issues.
>
No. Don't mix things. OMAP3 behaviour is a interconnect level and
it was single interconnect channel.
The issue here is a BUG in the asynchronous bridges and OMAp4 has
two separate channels at interconnect level form MPU side as mentioned
above.
Both of these patches I have passed it through Russell and Caralin before
including them here.
Regards
Santosh
^ permalink raw reply
* [PATCH 01/25] ARM: mm: Add strongly ordered descriptor support.
From: Shilimkar, Santosh @ 2011-09-14 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913202317.GE24252@atomide.com>
On Wed, Sep 14, 2011 at 1:53 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:22]:
>> On certain architectures, there might be a need to mark certain
>> addresses with strongly ordered memory attributes to avoid ordering
>> issues at the interconnect level.
>
> This is something Russell needs to look.
>
> You might want to also read the mailing list archives regarding the
> strongly ordered access.
>
> Basically it still won't guarantee that the write gets to the
> device, only a read back from the device in question guarantees
> that at the bus level.
>
Russell has already seen this. I have sent this patches to Russell
before adding them
in the queue.
This is different. There is a BUG in asynchronous bridges on OMAP44XX
devices and
that's the reason it' s needed.
Regards
Santosh
^ permalink raw reply
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
From: Shilimkar, Santosh @ 2011-09-14 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913203616.GG24252@atomide.com>
Tony,
On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:23]:
>> OMAP WakeupGen is the interrupt controller extension used along
>> with ARM GIC to wake the CPU out from low power states on
>> external interrupts.
>>
>> The WakeupGen unit is responsible for generating wakeup event
>> from the incoming interrupts and enable bits. It is implemented
>> in MPU always ON power domain. During normal operation,
>> WakeupGen delivers external interrupts directly to the GIC.
> ...
>
>> + ? ? /*
>> + ? ? ?* Override GIC architecture specific functions to add
>> + ? ? ?* OMAP WakeupGen interrupt controller along with GIC
>> + ? ? ?*/
>> + ? ? gic_arch_extn.irq_mask = wakeupgen_mask;
>> + ? ? gic_arch_extn.irq_unmask = wakeupgen_unmask;
>> + ? ? gic_arch_extn.irq_set_wake = wakeupgen_set_wake;
>> + ? ? gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
>
> As I've commented before, there should not be any need to tweak
> the wakeupgen registers for each interrupt during the runtime.
>
And I gave you all the reasons why it needs to be done this way.
> AFAIK the wakeupgen registers only need to be armed every time
> before entering idle.
>
No that doesn't work and it completely hacky approach.
This problem is for all SOC's using A9 SMP and GIC and every soc
has an architecture specific interrupt controller extension. And that
was the reason the GIC arch_extn was proposed.
It's just another IRQCHIP and works seamlessly being part of the
framework. And it will also initialized with primary IRQCHIP( GIC).
Regards
Santosh
^ permalink raw reply
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
From: Shilimkar, Santosh @ 2011-09-14 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wrdcbb49.fsf@ti.com>
On Tue, Sep 13, 2011 at 11:03 PM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh <santosh.shilimkar@ti.com> writes:
>
>> On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar<santosh.shilimkar@ti.com> ?writes:
>>>
>>>> This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
>>>> retention (CSWR) is not supported by hardware design.
>>>>
>>>> The CPUx OFF mode isn't supported on OMAP4430 ES1.0
>>>>
>>>> CPUx sleep code is common for hotplug, suspend and CPUilde.
>>>>
>>>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>>> Cc: Kevin Hilman<khilman@ti.com>
>>>
>>> [...]
>>>
>>>> @@ -38,6 +39,11 @@ void __iomem *omap4_get_scu_base(void)
>>>>
>>>> ? void __cpuinit platform_secondary_init(unsigned int cpu)
>>>> ? {
>>>> + ? /* Enable NS access to SMP bit for this CPU on EMU/HS devices */
>>>> + ? if (cpu_is_omap443x()&& ?(omap_type() != OMAP2_DEVICE_TYPE_GP))
>>>
>>> A comment here about why this is 443x specific would be helpful.
>>>
>>> I see a comment in omap4_cpu_resume() that seems to indicate that SMP
>>> bit is accessible on 446x NS devices, but repeating that commen here
>>> would help future readability.
>>>
>> Ok. Will add comments here too. Was just trying to save some lines :)
>
> heh, this is a negative side-effect of people caring primarily about
> diffstat. :(
>
ya.
> One other comment on this patch. ?You need spaces around the '&&' above.
>
The original patch is fine for that. Some replies has eaten that space. My
Thunderbird email client is doing the same. :(
Regards
Santosh
^ permalink raw reply
* [PATCH v2 5/6] iommu/intel: announce supported page sizes
From: Ohad Ben-Cohen @ 2011-09-14 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315949582.2687.204.camel@shinybook.infradead.org>
On Wed, Sep 14, 2011 at 12:32 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2011-09-13 at 22:31 +0300, Ohad Ben-Cohen wrote:
>> + * Traditionally the IOMMU core just handed us the mappings directly,
>> + * after making sure the size is an order of a 4KB page and that the
>> + * mapping has natural alignment.
>> + *
>> + * To retain this behavior, we currently advertise that we support
>> + * all page sizes that are an order of 4KB.
>
> This is wrong. We do not support 4000-byte pages. We only support
> 4096-byte pages. 4KiB, not 4kB.
>
> Please fix.
Sure thing; I'll s/KB/KiB throughout the patch set.
Do I have your ACK otherwise ?
Thanks,
Ohad.
^ permalink raw reply
* [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver
From: Vinod Koul @ 2011-09-14 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJe_ZhdTnRSzfRvnAaCy1M-LpAk0FqjNSXRLnQW2ksOS77A+=w@mail.gmail.com>
On Mon, 2011-09-12 at 12:03 +0530, Jassi Brar wrote:
> On 11 September 2011 21:32, Vinod Koul <vkoul@infradead.org> wrote:
> > On Fri, 2011-09-09 at 16:18 +0800, Barry Song wrote:
>
> >> Jassi prefer to use a transfer type instead of a control command.
> >> though we will not really change the interleaved setting for every
> >> transfer(it is more possible for one device, we will not change the
> >> xlen/ylen/dma_width setting in the whole life period), i do believe
> >> the transfer type is enough flexible for my possible applications to
> >> change xlen, ylen and dma_width in different transfers.
>
> > Is this usually the assumption or yours is a special case, how about
> > your's Jassi?
>
> 1) Having type per transfer is more flexible than having to set the type
> for a channel using a control command. The overhead is negligible
> because the client reuses the same descriptors with only changed
> source/destination addresses.
> 2) DMA_SLAVE_CONFIG is meant for slave (Mem<->Dev) channels,
> whereas it is very likely(for multimedia drives) to have such operations
> Mem->Mem as well.
> 3) Someday if people realize we can fold many, if not all, transfer types into
> one, this api has the potential to be the survivor.
>
> That was where my mind was grazing when I chose to do what I did.
I would agree that it makes sense to have it in API rather than config.
--
~Vinod
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
From: Kyungmin Park @ 2011-09-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1311659456-6659-3-git-send-email-m.szyprowski@samsung.com>
Hi,
It's required for boot universal c210 w/ EVT0 chip.
Can you include it at 3.1 fixed branch?
Thank you,
Kyungmin Park
On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Commit 069d4e743 removed support for local timers and forced to use MCT as
> event source. However MCT is not operating properly on early revision (EVT0)
> of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0, so that
> commit broke support for it. This patch provides a workaround that enables
> UniversalC210 boards to boot again. s5p-timer is used as an event source.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? | ? ?3 +++
> ?arch/arm/mach-exynos4/mach-universal_c210.c | ? ?4 +++-
> ?2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 9d62e13..2aad73f 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
> ?config MACH_UNIVERSAL_C210
> ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
> ? ? ? ?select CPU_EXYNOS4210
> + ? ? ? select S5P_HRT
> + ? ? ? select CLKSRC_MMIO
> + ? ? ? select HAVE_SCHED_CLOCK
> ? ? ? ?select S5P_GPIO_INT
> ? ? ? ?select S5P_DEV_FIMC0
> ? ? ? ?select S5P_DEV_FIMC1
> diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c b/arch/arm/mach-exynos4/mach-universal_c210.c
> index 0e280d1..ca9e7b7 100644
> --- a/arch/arm/mach-exynos4/mach-universal_c210.c
> +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
> @@ -34,6 +34,7 @@
> ?#include <plat/mfc.h>
> ?#include <plat/sdhci.h>
> ?#include <plat/pd.h>
> +#include <plat/s5p-time.h>
>
> ?#include <mach/map.h>
>
> @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
> ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> ? ? ? ?s3c24xx_init_clocks(24000000);
> ? ? ? ?s3c24xx_init_uarts(universal_uartcfgs, ARRAY_SIZE(universal_uartcfgs));
> + ? ? ? s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
> ?}
>
> ?static void __init universal_reserve(void)
> @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
> ? ? ? ?.init_irq ? ? ? = exynos4_init_irq,
> ? ? ? ?.map_io ? ? ? ? = universal_map_io,
> ? ? ? ?.init_machine ? = universal_machine_init,
> - ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
> + ? ? ? .timer ? ? ? ? ?= &s5p_timer,
> ? ? ? ?.reserve ? ? ? ?= &universal_reserve,
> ?MACHINE_END
> --
> 1.7.1.569.g6f426
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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
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