* Re: [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info
From: Scott Wood @ 2013-07-27 0:18 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <1372942454-25191-7-git-send-email-haokexin@gmail.com>
On 07/04/2013 07:54:12 AM, Kevin Hao wrote:
> For a relocatable kernel since it can be loaded at any place, there
> is no any relation between the kernel start addr and the =20
> memstart_addr.
> So we can't calculate the memstart_addr from kernel start addr. And
> also we can't wait to do the relocation after we get the real
> memstart_addr from device tree because it is so late. So introduce
> a new function we can use to get the first memblock address and size
> in a very early stage (before machine_init).
>=20
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> ---
> A new patch in v2.
>=20
> arch/powerpc/kernel/prom.c | 24 ++++++++++++++++++++++++
> include/linux/of_fdt.h | 1 +
> 2 files changed, 25 insertions(+)
>=20
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index eb23ac9..9a69d2d 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -753,6 +753,30 @@ void __init early_init_devtree(void *params)
> DBG(" <- early_init_devtree()\n");
> }
>=20
> +#ifdef CONFIG_RELOCATABLE
> +/*
> + * This function run before early_init_devtree, so we have to init
> + * initial_boot_params. Since early_init_dt_scan_memory_ppc will be
> + * executed again in early_init_devtree, we have to reinitialize the
> + * memblock data before return.
> + */
> +void __init early_get_first_memblock_info(void *params, phys_addr_t =20
> *size)
> +{
> + /* Setup flat device-tree pointer */
> + initial_boot_params =3D params;
> +
> + /* Scan memory nodes and rebuild MEMBLOCKs */
> + of_scan_flat_dt(early_init_dt_scan_root, NULL);
> + of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
> +
> + if (size)
> + *size =3D first_memblock_size;
> +
> + /* Undo what early_init_dt_scan_memory_ppc does to memblock */
> + memblock_reinit();
> +}
> +#endif
Wouldn't it be simpler to set a flag so that =20
early_init_dt_add_memory_arch() doesn't mess with memblocks on the =20
first pass?
-Scott=
^ permalink raw reply
* Re: SIGSTKSZ/MINSIGSTKSZ too small on 64bit
From: Alan Modra @ 2013-07-27 1:19 UTC (permalink / raw)
To: Ryan Arnold; +Cc: Michael Neuling, azanella, linuxppc-dev, Anton Blanchard, rsa
In-Reply-To: <OFE7C3B8EC.F822633B-ON86257BB4.00708A32-86257BB4.00763ECE@us.ibm.com>
On Fri, Jul 26, 2013 at 04:31:34PM -0500, Ryan Arnold wrote:
> Adhemerval and I were just looking at the signal stack frames and I'd
> noticed the increase in size due to the addition of the HTM bits so this is
> great timing.
>
> I tried a sigstack.h patch that increased the values as you indicated and
> it cleaned up the failing tst-cancel21* testcases on POWER8. I didn't try
> it on POWER7 yet.
I've tested on power7 using a copy of
sysdeps/unix/sysv/linux/sparc/bits/sigstack.h
as
sysdeps/unix/sysv/linux/powerpc/bits/sigstack.h
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
From: Daniel Lezcano @ 2013-07-27 5:27 UTC (permalink / raw)
To: Deepthi Dharwar; +Cc: linux-pm, linuxppc-dev, linux-kernel
In-Reply-To: <20130723090137.7291.36657.stgit@deepthi.in.ibm.com>
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
> This patch implements a back-end cpuidle driver for
> powernv calling power7_nap and snooze idle states.
> This can be extended by adding more idle states
> in the future to the existing framework.
>
> Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/Kconfig | 9 +
> arch/powerpc/platforms/powernv/Makefile | 1
> arch/powerpc/platforms/powernv/processor_idle.c | 239 +++++++++++++++++++++++
> 3 files changed, 249 insertions(+)
> create mode 100644 arch/powerpc/platforms/powernv/processor_idle.c
>
> diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
> index c24684c..ace2d22 100644
> --- a/arch/powerpc/platforms/powernv/Kconfig
> +++ b/arch/powerpc/platforms/powernv/Kconfig
> @@ -20,3 +20,12 @@ config PPC_POWERNV_RTAS
> default y
> select PPC_ICS_RTAS
> select PPC_RTAS
> +
> +config POWERNV_IDLE
> + bool "CPUIdle driver for powernv platform"
> + depends on CPU_IDLE
> + depends on PPC_POWERNV
> + default y
> + help
> + Select this option to enable processor idle state management
> + through cpuidle subsystem.
> diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
> index 7fe5951..c0e44eb 100644
> --- a/arch/powerpc/platforms/powernv/Makefile
> +++ b/arch/powerpc/platforms/powernv/Makefile
> @@ -4,3 +4,4 @@ obj-y += opal-rtc.o opal-nvram.o
> obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
> obj-$(CONFIG_EEH) += eeh-ioda.o eeh-powernv.o
> +obj-$(CONFIG_POWERNV_IDLE) += processor_idle.o
> diff --git a/arch/powerpc/platforms/powernv/processor_idle.c b/arch/powerpc/platforms/powernv/processor_idle.c
> new file mode 100644
> index 0000000..f43ad91a
> --- /dev/null
> +++ b/arch/powerpc/platforms/powernv/processor_idle.c
> @@ -0,0 +1,239 @@
> +/*
> + * processor_idle - idle state cpuidle driver.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/moduleparam.h>
> +#include <linux/cpuidle.h>
> +#include <linux/cpu.h>
> +#include <linux/notifier.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/runlatch.h>
> +
> +struct cpuidle_driver powernv_idle_driver = {
> + .name = "powernv_idle",
> + .owner = THIS_MODULE,
> +};
> +
> +#define MAX_IDLE_STATE_COUNT 2
> +
> +static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
> +static struct cpuidle_device __percpu *powernv_cpuidle_devices;
> +static struct cpuidle_state *cpuidle_state_table;
> +
> +static int snooze_loop(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + int cpu = dev->cpu;
> +
> + local_irq_enable();
> + set_thread_flag(TIF_POLLING_NRFLAG);
> +
> + while ((!need_resched()) && cpu_online(cpu)) {
> + ppc64_runlatch_off();
> + HMT_very_low();
> + }
Why are you using the cpu_online test here ?
> +
> + HMT_medium();
> + clear_thread_flag(TIF_POLLING_NRFLAG);
> + smp_mb();
> + return index;
> +}
> +
> +
> +static int nap_loop(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + ppc64_runlatch_off();
> + power7_idle();
> + return index;
> +}
> +
> +/*
> + * States for dedicated partition case.
> + */
> +static struct cpuidle_state powernv_states[MAX_IDLE_STATE_COUNT] = {
> + { /* Snooze */
> + .name = "snooze",
> + .desc = "snooze",
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .exit_latency = 0,
> + .target_residency = 0,
> + .enter = &snooze_loop },
> + { /* Nap */
> + .name = "Nap",
> + .desc = "Nap",
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .exit_latency = 10,
> + .target_residency = 100,
> + .enter = &nap_loop },
> +};
> +
> +static int powernv_cpuidle_add_cpu_notifier(struct notifier_block *n,
> + unsigned long action, void *hcpu)
> +{
> + int hotcpu = (unsigned long)hcpu;
> + struct cpuidle_device *dev =
> + per_cpu_ptr(powernv_cpuidle_devices, hotcpu);
> +
> + if (dev && cpuidle_get_driver()) {
> + switch (action) {
> + case CPU_ONLINE:
> + case CPU_ONLINE_FROZEN:
> + cpuidle_pause_and_lock();
> + cpuidle_enable_device(dev);
> + cpuidle_resume_and_unlock();
> + break;
> +
> + case CPU_DEAD:
> + case CPU_DEAD_FROZEN:
> + cpuidle_pause_and_lock();
> + cpuidle_disable_device(dev);
> + cpuidle_resume_and_unlock();
> + break;
> +
> + default:
> + return NOTIFY_DONE;
> + }
> + }
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block setup_hotplug_notifier = {
> + .notifier_call = powernv_cpuidle_add_cpu_notifier,
> +};
This is duplicated code with the pseries cpuidle driver and IMHO it
should be moved to the cpuidle framework.
> +/*
> + * powernv_cpuidle_driver_init()
> + */
> +static int powernv_cpuidle_driver_init(void)
> +{
> + int idle_state;
> + struct cpuidle_driver *drv = &powernv_idle_driver;
> +
> + drv->state_count = 0;
> +
> + for (idle_state = 0; idle_state < MAX_IDLE_STATE_COUNT; ++idle_state) {
> +
> + if (idle_state > max_idle_state)
> + break;
> +
> + /* is the state not enabled? */
> + if (cpuidle_state_table[idle_state].enter == NULL)
> + continue;
> +
> + drv->states[drv->state_count] = /* structure copy */
> + cpuidle_state_table[idle_state];
> +
> + drv->state_count += 1;
> + }
> +
> + return 0;
> +}
Instead of doing struct copy, why don't you use the state's 'disable'
field of the driver and then enable the state in the routine ?
> +/* powernv_idle_devices_uninit(void)
> + * unregister cpuidle devices and de-allocate memory
> + */
> +static void powernv_idle_devices_uninit(void)
> +{
> + int i;
> + struct cpuidle_device *dev;
> +
> + for_each_possible_cpu(i) {
> + dev = per_cpu_ptr(powernv_cpuidle_devices, i);
> + cpuidle_unregister_device(dev);
> + }
> +
> + free_percpu(powernv_cpuidle_devices);
> + return;
> +}
> +
> +/* powernv_idle_devices_init()
> + * allocate, initialize and register cpuidle device
> + */
> +static int powernv_idle_devices_init(void)
> +{
> + int i;
> + struct cpuidle_driver *drv = &powernv_idle_driver;
> + struct cpuidle_device *dev;
> +
> + powernv_cpuidle_devices = alloc_percpu(struct cpuidle_device);
> + if (powernv_cpuidle_devices == NULL)
> + return -ENOMEM;
> +
> + for_each_possible_cpu(i) {
> + dev = per_cpu_ptr(powernv_cpuidle_devices, i);
> + dev->state_count = drv->state_count;
> + dev->cpu = i;
> + if (cpuidle_register_device(dev)) {
> + printk(KERN_DEBUG \
> + "cpuidle_register_device %d failed!\n", i);
> + return -EIO;
> + }
> + }
> + return 0;
There is now the cpuidle_register(struct cpuidle_driver *, cpumask *);
You can get rid of the cpuidle_device struct and this init routine.
> +}
> +
> +/*
> + * powernv_idle_probe()
> + * Choose state table for shared versus dedicated partition
> + */
> +static int powernv_idle_probe(void)
> +{
> +
> + if (cpuidle_disable != IDLE_NO_OVERRIDE)
> + return -ENODEV;
> +
> + cpuidle_state_table = powernv_states;
> + return 0;
> +}
> +
> +static int __init powernv_processor_idle_init(void)
> +{
> + int retval;
> +
> + retval = powernv_idle_probe();
> + if (retval)
> + return retval;
> +
> + powernv_cpuidle_driver_init();
> + retval = cpuidle_register_driver(&powernv_idle_driver);
> + if (retval) {
> + printk(KERN_DEBUG "Registration of powernv driver failed.\n");
> + return retval;
> + }
> +
> + retval = powernv_idle_devices_init();
> + if (retval) {
> + powernv_idle_devices_uninit();
> + cpuidle_unregister_driver(&powernv_idle_driver);
> + return retval;
> + }
> +
> + register_cpu_notifier(&setup_hotplug_notifier);
> + printk(KERN_DEBUG "powernv_idle_driver registered\n");
> +
> + return 0;
> +}
> +
> +static void __exit powernv_processor_idle_exit(void)
> +{
> +
> + unregister_cpu_notifier(&setup_hotplug_notifier);
> + powernv_idle_devices_uninit();
> + cpuidle_unregister_driver(&powernv_idle_driver);
> +
> + return;
> +}
> +
> +module_init(powernv_processor_idle_init);
> +module_exit(powernv_processor_idle_exit);
> +
> +MODULE_AUTHOR("Deepthi Dharwar <deepthi@linux.vnet.ibm.com>");
> +MODULE_DESCRIPTION("Cpuidle driver for POWERNV");
> +MODULE_LICENSE("GPL");
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
From: Daniel Lezcano @ 2013-07-27 5:29 UTC (permalink / raw)
To: Deepthi Dharwar; +Cc: linux-pm, linuxppc-dev, linux-kernel
In-Reply-To: <20130723090150.7291.89879.stgit@deepthi.in.ibm.com>
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
> This patch enables idle powernv cpu to hook on to the cpuidle
> framework, if available, else call on to default idle platform
> code.
Why do you need to do that ?
> Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/setup.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
> index 84438af..97d0951 100644
> --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -25,6 +25,7 @@
> #include <linux/of.h>
> #include <linux/interrupt.h>
> #include <linux/bug.h>
> +#include <linux/cpuidle.h>
>
> #include <asm/machdep.h>
> #include <asm/firmware.h>
> @@ -196,6 +197,15 @@ static int __init pnv_probe(void)
> return 1;
> }
>
> +void powernv_idle(void)
> +{
> + /* Hook to cpuidle framework if available, else
> + * call on default platform idle code
> + */
> + if (cpuidle_idle_call())
> + power7_idle();
> +}
> +
> define_machine(powernv) {
> .name = "PowerNV",
> .probe = pnv_probe,
> @@ -205,7 +215,7 @@ define_machine(powernv) {
> .show_cpuinfo = pnv_show_cpuinfo,
> .progress = pnv_progress,
> .machine_shutdown = pnv_shutdown,
> - .power_save = power7_idle,
> + .power_save = powernv_idle,
> .calibrate_decr = generic_calibrate_decr,
> #ifdef CONFIG_KEXEC
> .kexec_cpu_down = pnv_kexec_cpu_down,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
From: Benjamin Herrenschmidt @ 2013-07-27 6:30 UTC (permalink / raw)
To: Preeti U Murthy
Cc: deepthi, shangw, arnd, linux-pm, geoff, Frederic Weisbecker,
linux-kernel, rostedt, rjw, paul.gortmaker, paulus, srivatsa.bhat,
schwidefsky, john.stultz, tglx, paulmck, linuxppc-dev,
chenhui.zhao
In-Reply-To: <51F1E15B.3050106@linux.vnet.ibm.com>
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
> *The lapic of a broadcast CPU is active always*. Say CPUX, wants the
> broadcast CPU to wake it up at timeX. Since we cannot program the lapic
> of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
> asking it to program its lapic to fire at timeX so as to wake up CPUX.
> *With multiple CPUs the overhead of sending IPI, could result in
> performance bottlenecks and may not scale well.*
>
> Hence the workaround is that the broadcast CPU on each of its timer
> interrupt checks if any of the next timer event of a CPU in deep idle
> state has expired, which can very well be found from dev->next_event of
> that CPU. For example the timeX that has been mentioned above has
> expired. If so the broadcast handler is called to send an IPI to the
> idling CPU to wake it up.
>
> *If the broadcast CPU, is in tickless idle, its timer interrupt could be
> many ticks away. It could miss waking up a CPU in deep idle*, if its
> wakeup is much before this timer interrupt of the broadcast CPU. But
> without tickless idle, atleast at each period we are assured of a timer
> interrupt. At which time broadcast handling is done as stated in the
> previous paragraph and we will not miss wakeup of CPUs in deep idle states.
But that means a great loss of power saving on the broadcast CPU when the machine
is basically completely idle. We might be able to come up with some thing better.
(Note : I do no know the timer offload code if it exists already, I'm describing
how things could happen "out of the blue" without any knowledge of pre-existing
framework here)
We can know when the broadcast CPU expects to wake up next. When a CPU goes to
a deep sleep state, it can then
- Indicate to the broadcast CPU when it intends to be woken up by queuing
itself into an ordered queue (ordered by target wakeup time). (OPTIMISATION:
Play with the locality of that: have one queue (and one "broadcast CPU") per
chip or per node instead of a global one to limit cache bouncing).
- Check if that happens before the broadcast CPU intended wake time (we
need statistics to see how often that happens), and in that case send an IPI
to wake it up now. When the broadcast CPU goes to sleep, it limits its sleep
time to the min of it's intended sleep time and the new sleeper time.
(OPTIMISATION: Dynamically chose a broadcast CPU based on closest expiry ?)
- We can probably limit spurrious wakeups a *LOT* by aligning that target time
to a global jiffy boundary, meaning that several CPUs going to idle are likely
to be choosing the same. Or maybe better, an adaptative alignment by essentially
getting more coarse grained as we go further in the future
- When the "broadcast" CPU goes to sleep, it can play the same game of alignment.
I don't like the concept of a dedicated broadcast CPU however. I'd rather have a
general queue (or per node) of sleepers needing a wakeup and more/less dynamically
pick a waker to be the last man standing, but it does make things a bit more
tricky with tickless scheduler (non-idle).
Still, I wonder if we could just have some algorithm to actually pick wakers
more dynamically based on who ever has the closest "next wakeup" planned,
that sort of thing. A fixed broadcaster will create an imbalance in
power/thermal within the chip in addition to needing to be moved around on
hotplug etc...
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
From: Preeti U Murthy @ 2013-07-27 7:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: deepthi, shangw, arnd, linux-pm, geoff, Frederic Weisbecker,
linux-kernel, rostedt, rjw, paul.gortmaker, paulus, srivatsa.bhat,
schwidefsky, john.stultz, tglx, paulmck, linuxppc-dev,
chenhui.zhao
In-Reply-To: <1374906605.3795.11.camel@pasglop>
Hi Ben,
On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
>> *The lapic of a broadcast CPU is active always*. Say CPUX, wants the
>> broadcast CPU to wake it up at timeX. Since we cannot program the lapic
>> of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
>> asking it to program its lapic to fire at timeX so as to wake up CPUX.
>> *With multiple CPUs the overhead of sending IPI, could result in
>> performance bottlenecks and may not scale well.*
>>
>> Hence the workaround is that the broadcast CPU on each of its timer
>> interrupt checks if any of the next timer event of a CPU in deep idle
>> state has expired, which can very well be found from dev->next_event of
>> that CPU. For example the timeX that has been mentioned above has
>> expired. If so the broadcast handler is called to send an IPI to the
>> idling CPU to wake it up.
>>
>> *If the broadcast CPU, is in tickless idle, its timer interrupt could be
>> many ticks away. It could miss waking up a CPU in deep idle*, if its
>> wakeup is much before this timer interrupt of the broadcast CPU. But
>> without tickless idle, atleast at each period we are assured of a timer
>> interrupt. At which time broadcast handling is done as stated in the
>> previous paragraph and we will not miss wakeup of CPUs in deep idle states.
>
> But that means a great loss of power saving on the broadcast CPU when the machine
> is basically completely idle. We might be able to come up with some thing better.
>
> (Note : I do no know the timer offload code if it exists already, I'm describing
> how things could happen "out of the blue" without any knowledge of pre-existing
> framework here)
>
> We can know when the broadcast CPU expects to wake up next. When a CPU goes to
> a deep sleep state, it can then
>
> - Indicate to the broadcast CPU when it intends to be woken up by queuing
> itself into an ordered queue (ordered by target wakeup time). (OPTIMISATION:
> Play with the locality of that: have one queue (and one "broadcast CPU") per
> chip or per node instead of a global one to limit cache bouncing).
>
> - Check if that happens before the broadcast CPU intended wake time (we
> need statistics to see how often that happens), and in that case send an IPI
> to wake it up now. When the broadcast CPU goes to sleep, it limits its sleep
> time to the min of it's intended sleep time and the new sleeper time.
> (OPTIMISATION: Dynamically chose a broadcast CPU based on closest expiry ?)
>
> - We can probably limit spurrious wakeups a *LOT* by aligning that target time
> to a global jiffy boundary, meaning that several CPUs going to idle are likely
> to be choosing the same. Or maybe better, an adaptative alignment by essentially
> getting more coarse grained as we go further in the future
>
> - When the "broadcast" CPU goes to sleep, it can play the same game of alignment.
>
> I don't like the concept of a dedicated broadcast CPU however. I'd rather have a
> general queue (or per node) of sleepers needing a wakeup and more/less dynamically
> pick a waker to be the last man standing, but it does make things a bit more
> tricky with tickless scheduler (non-idle).
>
> Still, I wonder if we could just have some algorithm to actually pick wakers
> more dynamically based on who ever has the closest "next wakeup" planned,
> that sort of thing. A fixed broadcaster will create an imbalance in
> power/thermal within the chip in addition to needing to be moved around on
> hotplug etc...
Thank you for having listed out the above suggestions. Below, I will
bring out some ideas about how the concerns that you have raised can be
addressed in the increasing order of priority.
- To begin with, I think we can have the following model to have the
responsibility of the broadcast CPU float around certain CPUs. i.e. Not
have a dedicated broadcast CPU. I will refer to the broadcast CPU as the
bc_cpu henceforth for convenience.
1. The first CPU that intends to enter deep sleep state will be the bc_cpu.
2. Every other CPU that intends to enter deep idle state will enter
themselves into a mask, say the bc_mask, which is already being done
today, after they check that a bc_cpu has been assigned.
3. The bc_cpu should not enter tickless idle, until step 5a holds true.
4. So on every timer interrupt, which is at-least every period, it
checks the bc_mask to see if any CPUs need to be woken up.
5. The bc cpu should not enter tickless idle *until* it is de-nominated
as the bc_cpu. The de-nomination occurs when:
a. In one of its timer interrupts, it does broadcast handling to find
out that there are no CPUs to be woken up.
6. So if 5a holds, then there is no bc_cpu anymore until a CPU decides
to enter deep idle state again, in which case steps 1 to 5 repeat.
- We could optimize this further, to allow the bc_cpu to enter tickless
idle, even while it is nominated as one. This can be the next step, if
we can get the above to work stably.
You have already brought out this point, so I will just reword it. Each
time broadcast handling is done, the bc_cpu needs to check if the wakeup
time of a CPU, that has entered deep idle state, and is yet to be woken
up, is before the bc_cpu's wakeup time, which was programmed to its
local events.
If so, then reprogram the decrementer to the wakeup time of a CPU that
is in deep idle state.
But we need to keep in mind one point. When CPUs go into deep idle, they
cannot program the local timer of the bc_cpu to their wakeup time. This
is because a CPU cannot program the timer of a remote CPU.
Therefore the only time we can check if 'wakeup time of the CPU that
enters deep idle state is before broadcast CPU's intended wake time so
as to reprogram the decrementer', is in the broadcast handler itself,
which is done *on* the bc_cpu alone.
What do you think?
- Coming to your third suggestion of aligning the wakeup time of CPUs, I
will spend some time on this and get back regarding the same.
>
> Cheers,
> Ben.
>
Thank you
Regards
Preeti U Murthy
^ permalink raw reply
* [PATCH] Add device file bindings for MAPLE
From: Shaveta Leekha @ 2013-07-27 13:03 UTC (permalink / raw)
To: devicetree-discuss, linuxppc-dev; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/maple.txt | 50 ++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
new file mode 100644
index 0000000..23b80a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
@@ -0,0 +1,50 @@
+* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
+ (MAPLE-B3)device nodes
+
+Supported chips:
+Example: B4860
+
+Required properties:
+
+- compatible: Should contain "fsl,maple-b3" as the value
+ This identifies Multi Accelerator Platform Engine
+ Baseband 3 block.
+
+- reg: offset and length of the register set for the device
+
+- interrupts
+ Usage: required
+ Value type: <prop_encoded-array>
+ Definition: Specifies the interrupts generated by this device. The
+ value of the interrupts property consists of one interrupt
+ specifier. The format of the specifier is defined by the
+ binding document describing the node's interrupt parent.
+
+ A single IRQ that handles error conditions is specified by
+ this property. (Typically shared with port-write).
+
+Devices that have LIODNs need to specify links to the parent PAMU controller
+(the actual PAMU controller that this device is connected to) and a pointer to
+the LIODN register, if applicable.
+
+- fsl,iommu-parent
+ : <phandle>
+ This property should be present
+
+- status = "disabled"
+ In this example, status is set "disabled",
+ As Maple device wouldn't be used by PPC Linux. This representation is required
+ for doing the PAMU programming on the Linux side.
+
+Example:
+ /* B4860 */
+
+ maple@800000 {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ status = "disabled";
+ compatible = "fsl,maple-b3";
+ reg = <0x8000000 0x10000>;
+ interrupts = <16 2 1 18>;
+ fsl,iommu-parent = <&pamu1>;
+ };
--
1.7.6.GIT
^ permalink raw reply related
* Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
From: Kevin Hao @ 2013-07-28 0:32 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc, Alexander Graf
In-Reply-To: <1374878624.30721.33@snotra>
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
On Fri, Jul 26, 2013 at 05:43:44PM -0500, Scott Wood wrote:
> On 07/25/2013 07:54:53 AM, Kevin Hao wrote:
> >The reason is that the ppc kernel assume that the BARs starting
> >at 0 is unset and will reassign it later. There is a bug in the
> >previous
> >kernel, so the kernel maybe not work well for qemu in this case. But I
> >think this has been fixed by the commit c5df457f (powerpc/pci:
> >Check the
> >bus address instead of resource address in pcibios_fixup_resources).
>
> What ensures that the reassignment will not assign zero?
In function pcibios_resource_survey() we will reserve the low IO area
before reassignment. Please see the following comments and codes in this
function.
/* Before we start assigning unassigned resource, we try to reserve
* the low IO area and the VGA memory area if they intersect the
* bus available resources to avoid allocating things on top of them
*/
if (!pci_has_flag(PCI_PROBE_ONLY)) {
list_for_each_entry(b, &pci_root_buses, node)
pcibios_reserve_legacy_regions(b);
}
Thanks,
Kevin
>
> I'm not doubting the result that it does, but I'm having a hard time
> seeing it in the code.
>
> Or are you saying that the resource assignment code will run twice,
> rather than just saying that we won't trust the firmware when we
> find zero?
>
> -Scott
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] of: Feed entire flattened device tree into the random pool
From: Grant Likely @ 2013-07-28 4:49 UTC (permalink / raw)
To: Anton Blanchard, Michael Ellerman
Cc: Paul Mackerras, linuxppc-dev, Rob Herring, devicetree
In-Reply-To: <20130725143031.16af0a96@kryten>
On Thu, 25 Jul 2013 14:30:31 +1000, Anton Blanchard <anton@samba.org> wrote:
>
> Hi Michael,
>
> > But why not put the initcall in drivers/of/fdt.c, that way it's not
> > early but it's still common ?
>
> Good idea! How does this look? So long as it happens before
> module_init(rand_initialize) we should be good.
>
> Anton
> --
>
> We feed the entire DMI table into the random pool to provide
> better random data during early boot, so do the same with the
> flattened device tree.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> v2: move to drivers/of/fdt.c as suggested by Michael Ellerman
>
> Index: b/drivers/of/fdt.c
> ===================================================================
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -17,6 +17,7 @@
> #include <linux/string.h>
> #include <linux/errno.h>
> #include <linux/slab.h>
> +#include <linux/random.h>
>
> #include <asm/setup.h> /* for COMMAND_LINE_SIZE */
> #ifdef CONFIG_PPC
> @@ -714,3 +715,14 @@ void __init unflatten_device_tree(void)
> }
>
> #endif /* CONFIG_OF_EARLY_FLATTREE */
> +
> +/* Feed entire flattened device tree into the random pool */
> +static int __init add_fdt_randomness(void)
> +{
> + if (initial_boot_params)
> + add_device_randomness(initial_boot_params,
> + initial_boot_params->totalsize);
be32_to_cpu(initial_boot_params->totalsize);
g.
^ permalink raw reply
* Re: [PATCH v6 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Vinod Koul @ 2013-07-28 13:51 UTC (permalink / raw)
To: hongbo.zhang; +Cc: devicetree, linux-kernel, djbw, scottwood, linuxppc-dev
In-Reply-To: <1374834436-7149-4-git-send-email-hongbo.zhang@freescale.com>
On Fri, Jul 26, 2013 at 06:27:16PM +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> This patch adds support to 8-channel DMA engine, thus the driver works for both
> the new 8-channel and the legacy 4-channel DMA engines.
>
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
This looks fine. I need someone to ACK the DT bindings for the series to go in
~Vinod
^ permalink raw reply
* Re: [PATCH 2/2 V2] mmc: esdhc: get voltage from dts file
From: Zhang Haijun @ 2013-07-29 0:40 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linux-mmc, AFLEMING, scottwood, cjb, linuxppc-dev, Haijun Zhang
In-Reply-To: <20130726191858.GB14216@lizard>
On 07/27/2013 03:18 AM, Anton Vorontsov wrote:
> On Thu, Jul 25, 2013 at 08:38:11AM +0800, Haijun Zhang wrote:
>> Add voltage-range support in esdhc of T4, So we can choose
>> to read voltages from dts file as one optional.
>> If we can get a valid voltage-range from device node, we use
>> this voltage as the final voltage support. Else we still read
>> from capacity or from other provider.
>>
>> Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
>> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
> Development process nitpick...
>
> The code originated from me, but I did not sign off this patch...
>
> Per Documentation/SubmittingPatches:
>
> The Signed-off-by: tag indicates that the signer was involved in the
> development of the patch, or that he/she was in the patch's delivery path.
>
> The order of the sign-off lines also has a meaning. Putting my sign off
> below yours means that I was not only involved in the development of the
> patch but also somehow approved the patch (but I did not :).
>
> [..]
>> +void sdhci_get_voltage(struct platform_device *pdev)
> You still duplicate the code... Per my previous email, this should
> probably go into mmc/core (with the function renamed to something more
> generic, of course.)
>
> Thanks,
>
> Anton
>
Thanks Anton.
I'll correct this and resend the patch.
--
Thanks & Regards
Haijun
^ permalink raw reply
* RE: [PATCH v2 1/3] powerpc/85xx: Add SEC6.0 device tree
From: Liu Po-B43644 @ 2013-07-29 2:14 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org, Hu Mingkai-B21284, Fleming Andy-AFLEMING
In-Reply-To: <1374875723.30721.26@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Saturday, July 27, 2013 5:55 AM
> To: Liu Po-B43644
> Cc: linuxppc-dev@ozlabs.org; galak@kernel.crashing.org; Fleming Andy-
> AFLEMING; Hu Mingkai-B21284; Liu Po-B43644
> Subject: Re: [PATCH v2 1/3] powerpc/85xx: Add SEC6.0 device tree
> =20
> On 07/25/2013 09:41:17 PM, Po Liu wrote:
> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > +Job Ring (JR) Node
> > +
> > + Child of the crypto node defines data processing interface to
> > SEC 6
> > + across the peripheral bus for purposes of processing
> > + cryptographic descriptors. The specified address
> > + range can be made visible to one (or more) cores.
> > + The interrupt defined for this node is controlled within
> > + the address range of this node.
> > +
> > + - compatible
> > + Usage: required
> > + Value type: <string>
> > + Definition: Must include "fsl,sec-v6.0-job-ring", if it is
> > + back compatible with old version, better add them all.
> =20
> Please don't use colloquialisms such as "[you'd] better do this" in a
> formal specification.
> =20
> Just say 'Must include "fsl,sec-v6.0-job-ring"' and leave it at that,
> like the other bindings do.
Ok, I'll remove redundant words.
> =20
> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > +Full Example
> > +
> > +Since some chips may embeded with more than one SEC 6, we abstract
> > +all the same properties into one file qoriq-sec6.0-0.dtsi. Each chip
> > +want to binding the node could simply include it in its own device
> > +node tree. Below is full example in C293PCIE:
> =20
> Replace this with:
> =20
> Since some chips may contain more than one SEC, the dtsi contains only
> the node contents, not the node itself. A chip using the SEC should
> include the dtsi inside each SEC node. Example:
> =20
> > +In qoriq-sec6.0-0.dtsi:
> > +
> > + compatible =3D "fsl,sec-v6.0";
> > + fsl,sec-era =3D <6>;
> > + #address-cells =3D <1>;
> > + #size-cells =3D <1>;
> > +
> > + jr@1000 {
> > + compatible =3D "fsl,sec-v6.0-job-ring",
> > + "fsl,sec-v5.2-job-ring",
> > + "fsl,sec-v5.0-job-ring",
> > + "fsl,sec-v4.4-job-ring",
> > + "fsl,sec-v4.0-job-ring";
> > + reg =3D <0x1000 0x1000>;
> > + };
> > +
> > + jr@2000 {
> > + compatible =3D "fsl,sec-v6.0-job-ring",
> > + "fsl,sec-v5.2-job-ring",
> > + "fsl,sec-v5.0-job-ring",
> > + "fsl,sec-v4.4-job-ring",
> > + "fsl,sec-v4.0-job-ring";
> > + reg =3D <0x2000 0x1000>;
> > + };
> > +
> > +In the C293 device tree, we add the include of public property:
> > +
> > +crypto@a0000 {
> > +/include/ "qoriq-sec6.0-0.dtsi"
> > + };
> =20
> Whitespace
> =20
> > +
> > + crypto@a0000 {
> > + reg =3D <0xa0000 0x20000>;
> > + ranges =3D <0x0 0xa0000 0x20000>;
> > +
> > + jr@1000{
> > + interrupts =3D <49 2 0 0>;
> > + };
> > + jr@2000{
> > + interrupts =3D <50 2 0 0>;
> > + };
> > + };
> =20
> You could combine the above like this:
> =20
> crypto@a0000 {
> reg =3D <0xa0000 0x20000>;
> ranges =3D <0 0xa0000 0x20000>;
> =20
> /include/ "qoriq-sec6.0-0.dtsi"
> =20
> jr@1000 {
> interrupts =3D <49 2 0 0>;
> };
> =20
> jr@2000 {
> interrupts =3D <50 2 0 0>;
> };
> };
> =20
> Why is it "qoriq-sec6.0-0.dtsi" and not "qoriq-sec6.0-dtsi"?
Ok, I'll change to qoriq-sec6.0.dtsi
> =20
> -Scott
^ permalink raw reply
* RE: [PATCH v2 3/3] powerpc/85xx: Add C293PCIE board support
From: Liu Po-B43644 @ 2013-07-29 2:20 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org, Hu Mingkai-B21284, Fleming Andy-AFLEMING
In-Reply-To: <1374875956.30721.27@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Saturday, July 27, 2013 5:59 AM
> To: Liu Po-B43644
> Cc: linuxppc-dev@ozlabs.org; galak@kernel.crashing.org; Fleming Andy-
> AFLEMING; Hu Mingkai-B21284; Liu Po-B43644
> Subject: Re: [PATCH v2 3/3] powerpc/85xx: Add C293PCIE board support
> =20
> On 07/25/2013 09:41:19 PM, Po Liu wrote:
> > + partition@1900000 {
> > + /* 7MB for User Area */
> > + reg =3D <0x01900000 0x00700000>;
> > + label =3D "NAND User area";
> > + };
> > +
> > + partition@2000000 {
> > + /* 96MB for Root File System */
> > + reg =3D <0x02000000 0x06000000>;
> > + label =3D "NAND Root File System";
> > + };
> > +
> > + partition@8000000 {
> > + /* 3968MB for Others */
> > + reg =3D <0x08000000 0xF8000000>;
> > + label =3D "NAND Others";
> > + };
> =20
> Again, what is the difference between "user area" and "others"? I'm not
> even sure why it needs to be separate from "root file system", but at
> least the root filesystem should be larger given the size of the overall
> flash.
Do you mean just merge up four partition into one "RFS"? Or merge up four p=
artition into "RFS" and "User area" is better?
> =20
> Also please use lowercase for hex.
> =20
> > + };
> > +
> > + cpld@2,0 {
> > + #address-cells =3D <1>;
> > + #size-cells =3D <1>;
> > + compatible =3D "fsl,c293pcie-cpld";
> > + reg =3D <0x2 0x0 0x20>;
> > + };
> =20
> Remove #address-cells/#size-cells
> =20
> > + partition@580000 {
> > + /* 10.5MB for Compressed RFS Image */
> > + reg =3D <0x00580000 0x00a80000>;
> > + label =3D "SPI Flash Compressed RFSImage";
> > + };
> =20
> Space before "Image". Why specifiy that it's compressed, versus some
> other filesystem type?
> =20
Remove all the "compressed" comments when express the RFS partition?
> -Scott
^ permalink raw reply
* Re: [PATCH] of: Feed entire flattened device tree into the random pool
From: Anton Blanchard @ 2013-07-29 3:11 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree, Rob Herring, Paul Mackerras, linuxppc-dev
In-Reply-To: <20130728044942.A58793E0A24@localhost>
Hi,
> be32_to_cpu(initial_boot_params->totalsize);
Ouch, thanks Grant.
Anton
--
We feed the entire DMI table into the random pool to provide
better random data during early boot, so do the same with the
flattened device tree.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
v3: Fix endian issues as noted by Grant
Index: b/drivers/of/fdt.c
===================================================================
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -17,6 +17,7 @@
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/slab.h>
+#include <linux/random.h>
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#ifdef CONFIG_PPC
@@ -714,3 +715,14 @@ void __init unflatten_device_tree(void)
}
#endif /* CONFIG_OF_EARLY_FLATTREE */
+
+/* Feed entire flattened device tree into the random pool */
+static int __init add_fdt_randomness(void)
+{
+ if (initial_boot_params)
+ add_device_randomness(initial_boot_params,
+ be32_to_cpu(initial_boot_params->totalsize));
+
+ return 0;
+}
+core_initcall(add_fdt_randomness);
^ permalink raw reply
* [PATCH 2/3] mmc:sdhc: get voltage from sdhc host
From: Haijun Zhang @ 2013-07-29 2:56 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev
Cc: scottwood, cjb, AFLEMING, Haijun Zhang, cbouatmailru
In-Reply-To: <1375066595-14968-1-git-send-email-Haijun.Zhang@freescale.com>
We use host->ocr_mask to hold the voltage get from device-tree
node, In case host->ocr_mask was available, we use host->ocr_mask
as the final available voltage can be used by MMC/SD/SDIO card.
Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
---
drivers/mmc/host/sdhci.c | 3 +++
include/linux/mmc/sdhci.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a78bd4f..57541e0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3119,6 +3119,9 @@ int sdhci_add_host(struct sdhci_host *host)
SDHCI_MAX_CURRENT_MULTIPLIER;
}
+ if (host->ocr_mask)
+ ocr_avail = host->ocr_mask;
+
mmc->ocr_avail = ocr_avail;
mmc->ocr_avail_sdio = ocr_avail;
if (host->ocr_avail_sdio)
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index e3c6a74..3e781b8 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -171,6 +171,7 @@ struct sdhci_host {
unsigned int ocr_avail_sdio; /* OCR bit masks */
unsigned int ocr_avail_sd;
unsigned int ocr_avail_mmc;
+ u32 ocr_mask; /* available voltages */
wait_queue_head_t buf_ready_int; /* Waitqueue for Buffer Read Ready interrupt */
unsigned int tuning_done; /* Condition flag set when CMD19 succeeds */
--
1.8.0
^ permalink raw reply related
* [PATCH 1/3] mmc:core: parse voltage from device-tree
From: Haijun Zhang @ 2013-07-29 2:56 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev
Cc: scottwood, cjb, AFLEMING, Haijun Zhang, cbouatmailru
Add function to support get voltage from device-tree.
If there are voltage-range specified in device-tree node, this function
will parse it and return the avail voltage mask.
Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
---
drivers/mmc/core/core.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/mmc/core.h | 1 +
2 files changed, 49 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 49a5bca..217cd42 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -27,6 +27,7 @@
#include <linux/fault-inject.h>
#include <linux/random.h>
#include <linux/slab.h>
+#include <linux/of.h>
#include <linux/mmc/card.h>
#include <linux/mmc/host.h>
@@ -1196,6 +1197,53 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max)
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_OF
+
+/*
+ * mmc_of_parse_voltage - return mask of supported voltages
+ * @host: host whose node should be parsed.
+ *
+ * 1. Return zero: voltage-ranges unspecified in device-tree.
+ * 2. Return negative errno: voltage-range is invalid.
+ * 3. Return ocr_mask: a mask of voltages that parse from device-tree
+ * node can be provided to MMC/SD/SDIO devices.
+ */
+
+u32 mmc_of_parse_voltage(struct mmc_host *host)
+{
+ const u32 *voltage_ranges;
+ int num_ranges, i;
+ struct device_node *np;
+ u32 ocr_mask = 0;
+
+ np = host->parent->of_node;
+ voltage_ranges = of_get_property(np, "voltage-ranges", &num_ranges);
+ num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
+ if (!voltage_ranges || !num_ranges) {
+ dev_info(host->parent, "OF: voltage-ranges unspecified\n");
+ return 0;
+ }
+
+ for (i = 0; i < num_ranges; i++) {
+ const int j = i * 2;
+ u32 mask;
+
+ mask = mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
+ be32_to_cpu(voltage_ranges[j + 1]));
+ if (!mask) {
+ dev_err(host->parent,
+ "OF: voltage-range #%d is invalid\n", i);
+ return -EINVAL;
+ }
+ ocr_mask |= mask;
+ }
+
+ return ocr_mask;
+}
+EXPORT_SYMBOL(mmc_of_parse_voltage);
+
+#endif /* CONFIG_OF */
+
#ifdef CONFIG_REGULATOR
/**
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 443243b..107375c 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -209,5 +209,6 @@ static inline void mmc_claim_host(struct mmc_host *host)
}
extern u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max);
+extern u32 mmc_of_parse_voltage(struct mmc_host *host);
#endif /* LINUX_MMC_CORE_H */
--
1.8.0
^ permalink raw reply related
* [PATCH 3/3] mmc:esdhc: add support to get voltage from device-tree
From: Haijun Zhang @ 2013-07-29 2:56 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev
Cc: scottwood, cjb, AFLEMING, Haijun Zhang, cbouatmailru
In-Reply-To: <1375066595-14968-1-git-send-email-Haijun.Zhang@freescale.com>
Add suppport to get voltage from device-tree node for esdhc host,
if voltage-ranges was specified in device-tree node we can get
ocr_mask instead of read from host capacity register. If not voltages
still can be get from host capacity register.
Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
---
drivers/mmc/host/sdhci-of-esdhc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 15039e2..b1a7f54 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -316,6 +316,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
/* call to generic mmc_of_parse to support additional capabilities */
mmc_of_parse(host->mmc);
+ host->ocr_mask = mmc_of_parse_voltage(host->mmc);
ret = sdhci_add_host(host);
if (ret)
--
1.8.0
^ permalink raw reply related
* Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
From: Vaidyanathan Srinivasan @ 2013-07-29 5:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: deepthi, shangw, arnd, linux-pm, geoff, Frederic Weisbecker,
linux-kernel, rostedt, rjw, paul.gortmaker, paulus, srivatsa.bhat,
Preeti U Murthy, john.stultz, tglx, paulmck, linuxppc-dev,
schwidefsky, chenhui.zhao
In-Reply-To: <1374906605.3795.11.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2013-07-27 16:30:05]:
> On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
> > *The lapic of a broadcast CPU is active always*. Say CPUX, wants the
> > broadcast CPU to wake it up at timeX. Since we cannot program the lapic
> > of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
> > asking it to program its lapic to fire at timeX so as to wake up CPUX.
> > *With multiple CPUs the overhead of sending IPI, could result in
> > performance bottlenecks and may not scale well.*
> >
> > Hence the workaround is that the broadcast CPU on each of its timer
> > interrupt checks if any of the next timer event of a CPU in deep idle
> > state has expired, which can very well be found from dev->next_event of
> > that CPU. For example the timeX that has been mentioned above has
> > expired. If so the broadcast handler is called to send an IPI to the
> > idling CPU to wake it up.
> >
> > *If the broadcast CPU, is in tickless idle, its timer interrupt could be
> > many ticks away. It could miss waking up a CPU in deep idle*, if its
> > wakeup is much before this timer interrupt of the broadcast CPU. But
> > without tickless idle, atleast at each period we are assured of a timer
> > interrupt. At which time broadcast handling is done as stated in the
> > previous paragraph and we will not miss wakeup of CPUs in deep idle states.
>
> But that means a great loss of power saving on the broadcast CPU when the machine
> is basically completely idle. We might be able to come up with some thing better.
Hi Ben,
Yes, we will need to improve on this case in stages. In the current
design, we will have to hold one of the CPU in shallow idle state
(nap) to wakeup other deep idle cpus. The cost of keeping the
periodic tick ON on the broadcast CPU in minimal (but not zero) since
we would not allow that CPU to enter any deep idle states even if
there were no periodic timers queued.
> (Note : I do no know the timer offload code if it exists already, I'm describing
> how things could happen "out of the blue" without any knowledge of pre-existing
> framework here)
>
> We can know when the broadcast CPU expects to wake up next. When a CPU goes to
> a deep sleep state, it can then
>
> - Indicate to the broadcast CPU when it intends to be woken up by queuing
> itself into an ordered queue (ordered by target wakeup time). (OPTIMISATION:
> Play with the locality of that: have one queue (and one "broadcast CPU") per
> chip or per node instead of a global one to limit cache bouncing).
>
> - Check if that happens before the broadcast CPU intended wake time (we
> need statistics to see how often that happens), and in that case send an IPI
> to wake it up now. When the broadcast CPU goes to sleep, it limits its sleep
> time to the min of it's intended sleep time and the new sleeper time.
> (OPTIMISATION: Dynamically chose a broadcast CPU based on closest expiry ?)
This will be an improvement and the idea we have is to have
a hierarchical method of finding a waking CPU within core/socket/node
in order to find a better fit and ultimately send IPI to wakeup
a broadcast CPU only if there is no other fit. This condition would
imply that more CPUs are in deep idle state and the cost of sending an
IPI to reprogram the broadcast cpu's local timer may well payoff.
> - We can probably limit spurrious wakeups a *LOT* by aligning that target time
> to a global jiffy boundary, meaning that several CPUs going to idle are likely
> to be choosing the same. Or maybe better, an adaptative alignment by essentially
> getting more coarse grained as we go further in the future
>
> - When the "broadcast" CPU goes to sleep, it can play the same game of alignment.
CPUs entering deep idle state would need to wakeup only at a jiffy
boundary or the jiffy boundary earlier than the target wakeup time.
Your point is can the broadcast cpu wakeup the sleeping CPU *around*
the designated wakeup time (earlier) so as to avoid reprogramming its
timer.
> I don't like the concept of a dedicated broadcast CPU however. I'd rather have a
> general queue (or per node) of sleepers needing a wakeup and more/less dynamically
> pick a waker to be the last man standing, but it does make things a bit more
> tricky with tickless scheduler (non-idle).
>
> Still, I wonder if we could just have some algorithm to actually pick wakers
> more dynamically based on who ever has the closest "next wakeup" planned,
> that sort of thing. A fixed broadcaster will create an imbalance in
> power/thermal within the chip in addition to needing to be moved around on
> hotplug etc...
Right Ben. The hierarchical way of selecting the waker will help us
have multiple wakers in different sockets/cores. The broadcast
framework allows us to decouple the cpu going to idle and the waker to
be selected independently. This patch series is the start where we
pick one and allow it to move around. The ideal goal to achieve would
be that we can have multiple wakers serving wakeup requests from
a queue (mask) and wakers are generally busy or just idle cpu who need
not prevent itself from going to tickless idle or deep idle states
just to wakeup another one. This optimizations can adapt to the case
where we will need the last cpu to stay in shallow idle mode and in
tickless with the wakeup events queued to target one of the deep idle
cpu.
--Vaidy
^ permalink raw reply
* Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
From: Vaidyanathan Srinivasan @ 2013-07-29 5:28 UTC (permalink / raw)
To: Preeti U Murthy
Cc: deepthi, shangw, arnd, linux-pm, geoff, linux-kernel, rostedt,
rjw, paul.gortmaker, paulus, srivatsa.bhat, Frederic Weisbecker,
schwidefsky, john.stultz, tglx, paulmck, linuxppc-dev,
chenhui.zhao
In-Reply-To: <51F37BCD.706@linux.vnet.ibm.com>
* Preeti U Murthy <preeti@linux.vnet.ibm.com> [2013-07-27 13:20:37]:
> Hi Ben,
>
> On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
> >> *The lapic of a broadcast CPU is active always*. Say CPUX, wants the
> >> broadcast CPU to wake it up at timeX. Since we cannot program the lapic
> >> of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
> >> asking it to program its lapic to fire at timeX so as to wake up CPUX.
> >> *With multiple CPUs the overhead of sending IPI, could result in
> >> performance bottlenecks and may not scale well.*
> >>
> >> Hence the workaround is that the broadcast CPU on each of its timer
> >> interrupt checks if any of the next timer event of a CPU in deep idle
> >> state has expired, which can very well be found from dev->next_event of
> >> that CPU. For example the timeX that has been mentioned above has
> >> expired. If so the broadcast handler is called to send an IPI to the
> >> idling CPU to wake it up.
> >>
> >> *If the broadcast CPU, is in tickless idle, its timer interrupt could be
> >> many ticks away. It could miss waking up a CPU in deep idle*, if its
> >> wakeup is much before this timer interrupt of the broadcast CPU. But
> >> without tickless idle, atleast at each period we are assured of a timer
> >> interrupt. At which time broadcast handling is done as stated in the
> >> previous paragraph and we will not miss wakeup of CPUs in deep idle states.
> >
> > But that means a great loss of power saving on the broadcast CPU when the machine
> > is basically completely idle. We might be able to come up with some thing better.
> >
> > (Note : I do no know the timer offload code if it exists already, I'm describing
> > how things could happen "out of the blue" without any knowledge of pre-existing
> > framework here)
> >
> > We can know when the broadcast CPU expects to wake up next. When a CPU goes to
> > a deep sleep state, it can then
> >
> > - Indicate to the broadcast CPU when it intends to be woken up by queuing
> > itself into an ordered queue (ordered by target wakeup time). (OPTIMISATION:
> > Play with the locality of that: have one queue (and one "broadcast CPU") per
> > chip or per node instead of a global one to limit cache bouncing).
> >
> > - Check if that happens before the broadcast CPU intended wake time (we
> > need statistics to see how often that happens), and in that case send an IPI
> > to wake it up now. When the broadcast CPU goes to sleep, it limits its sleep
> > time to the min of it's intended sleep time and the new sleeper time.
> > (OPTIMISATION: Dynamically chose a broadcast CPU based on closest expiry ?)
> >
> > - We can probably limit spurrious wakeups a *LOT* by aligning that target time
> > to a global jiffy boundary, meaning that several CPUs going to idle are likely
> > to be choosing the same. Or maybe better, an adaptative alignment by essentially
> > getting more coarse grained as we go further in the future
> >
> > - When the "broadcast" CPU goes to sleep, it can play the same game of alignment.
> >
> > I don't like the concept of a dedicated broadcast CPU however. I'd rather have a
> > general queue (or per node) of sleepers needing a wakeup and more/less dynamically
> > pick a waker to be the last man standing, but it does make things a bit more
> > tricky with tickless scheduler (non-idle).
> >
> > Still, I wonder if we could just have some algorithm to actually pick wakers
> > more dynamically based on who ever has the closest "next wakeup" planned,
> > that sort of thing. A fixed broadcaster will create an imbalance in
> > power/thermal within the chip in addition to needing to be moved around on
> > hotplug etc...
>
> Thank you for having listed out the above suggestions. Below, I will
> bring out some ideas about how the concerns that you have raised can be
> addressed in the increasing order of priority.
>
> - To begin with, I think we can have the following model to have the
> responsibility of the broadcast CPU float around certain CPUs. i.e. Not
> have a dedicated broadcast CPU. I will refer to the broadcast CPU as the
> bc_cpu henceforth for convenience.
>
> 1. The first CPU that intends to enter deep sleep state will be the bc_cpu.
>
> 2. Every other CPU that intends to enter deep idle state will enter
> themselves into a mask, say the bc_mask, which is already being done
> today, after they check that a bc_cpu has been assigned.
>
> 3. The bc_cpu should not enter tickless idle, until step 5a holds true.
>
> 4. So on every timer interrupt, which is at-least every period, it
> checks the bc_mask to see if any CPUs need to be woken up.
>
> 5. The bc cpu should not enter tickless idle *until* it is de-nominated
> as the bc_cpu. The de-nomination occurs when:
> a. In one of its timer interrupts, it does broadcast handling to find
> out that there are no CPUs to be woken up.
>
> 6. So if 5a holds, then there is no bc_cpu anymore until a CPU decides
> to enter deep idle state again, in which case steps 1 to 5 repeat.
>
>
> - We could optimize this further, to allow the bc_cpu to enter tickless
> idle, even while it is nominated as one. This can be the next step, if
> we can get the above to work stably.
>
> You have already brought out this point, so I will just reword it. Each
> time broadcast handling is done, the bc_cpu needs to check if the wakeup
> time of a CPU, that has entered deep idle state, and is yet to be woken
> up, is before the bc_cpu's wakeup time, which was programmed to its
> local events.
>
> If so, then reprogram the decrementer to the wakeup time of a CPU that
> is in deep idle state.
>
> But we need to keep in mind one point. When CPUs go into deep idle, they
> cannot program the local timer of the bc_cpu to their wakeup time. This
> is because a CPU cannot program the timer of a remote CPU.
>
> Therefore the only time we can check if 'wakeup time of the CPU that
> enters deep idle state is before broadcast CPU's intended wake time so
> as to reprogram the decrementer', is in the broadcast handler itself,
> which is done *on* the bc_cpu alone.
>
>
>
> What do you think?
>
>
> - Coming to your third suggestion of aligning the wakeup time of CPUs, I
> will spend some time on this and get back regarding the same.
Hi Preeti,
One of Ben's suggestions is to coarse grain the waker's timer event.
The trade off is whether we issue an IPI for each CPU needing a wakeup
or let the bc_cpu wakeup periodically and *see* that there is a new
request. The interval for a wakeup request will be much coarse grain
than a tick. We maybe able to easily reduce the power impact of not
letting bc_cpu go tickless by choosing a right coarse grain period.
For example we can let the bc_cpu look for new wakeup requests once in
every 10 or 20 jiffies rather than every jiffy and align the wakeup
requests at this coarse grain wakeup. We do pay a power penalty by
waking up few jiffies earlier which we can mitigate by reevaluating
the situation and queueing a fine grain timer to the right jiffy on
the bc_cpu if such a situation arises.
The point is a new wakeup request will *ask* for a wakeup later than
the coarse grain period. So the bc_cpu can wakeup at the coarse time
period and reprogram its timer to the right jiffy.
--Vaidy
^ permalink raw reply
* [PATCH 0/3] networking: Use ETH_ALEN where appropriate
From: Joe Perches @ 2013-07-29 5:29 UTC (permalink / raw)
To: netdev
Cc: wimax, linux-usb, linux-kernel, virtualization, linux-acpi,
netfilter-devel, linuxppc-dev, linux-arm-kernel, linux-media
Convert the uses mac addresses to ETH_ALEN so
it's easier to find and verify where mac addresses
need to be __aligned(2)
Joe Perches (3):
uapi: Convert some uses of 6 to ETH_ALEN
include: Convert ethernet mac address declarations to use ETH_ALEN
ethernet: Convert mac address uses of 6 to ETH_ALEN
drivers/net/ethernet/8390/ax88796.c | 4 +-
drivers/net/ethernet/amd/pcnet32.c | 6 +--
drivers/net/ethernet/broadcom/cnic_if.h | 6 +--
drivers/net/ethernet/dec/tulip/tulip_core.c | 8 +--
drivers/net/ethernet/i825xx/sun3_82586.h | 4 +-
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 2 +-
drivers/net/ethernet/nuvoton/w90p910_ether.c | 4 +-
drivers/net/ethernet/pasemi/pasemi_mac.c | 13 ++---
drivers/net/ethernet/pasemi/pasemi_mac.h | 4 +-
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 4 +-
drivers/net/ethernet/qlogic/qlge/qlge.h | 2 +-
include/acpi/actbl2.h | 4 +-
include/linux/dm9000.h | 4 +-
include/linux/fs_enet_pd.h | 3 +-
include/linux/ieee80211.h | 59 +++++++++++-----------
include/linux/mlx4/device.h | 11 ++--
include/linux/mlx4/qp.h | 5 +-
include/linux/mv643xx_eth.h | 3 +-
include/linux/sh_eth.h | 3 +-
include/linux/smsc911x.h | 3 +-
include/linux/uwb/spec.h | 5 +-
include/media/tveeprom.h | 4 +-
include/net/irda/irlan_common.h | 3 +-
include/uapi/linux/dn.h | 3 +-
include/uapi/linux/if_bridge.h | 3 +-
include/uapi/linux/netfilter_bridge/ebt_802_3.h | 5 +-
include/uapi/linux/netfilter_ipv4/ipt_CLUSTERIP.h | 3 +-
include/uapi/linux/virtio_net.h | 2 +-
include/uapi/linux/wimax/i2400m.h | 4 +-
29 files changed, 103 insertions(+), 81 deletions(-)
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply
* [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
From: Joe Perches @ 2013-07-29 5:29 UTC (permalink / raw)
To: netdev
Cc: Steve Glendinning, Samuel Ortiz, linux-media, linux-usb,
linux-kernel, Rafael J. Wysocki, linux-acpi, Vitaly Bordug,
Len Brown, linuxppc-dev, David S. Miller, Mauro Carvalho Chehab
In-Reply-To: <cover.1375075325.git.joe@perches.com>
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also to ensure that the addresses are __aligned(2).
Add #include <linux/if_ether.h> as necessary.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/acpi/actbl2.h | 4 ++-
include/linux/dm9000.h | 4 ++-
include/linux/fs_enet_pd.h | 3 ++-
include/linux/ieee80211.h | 59 +++++++++++++++++++++--------------------
include/linux/mlx4/device.h | 11 ++++----
include/linux/mlx4/qp.h | 5 ++--
include/linux/mv643xx_eth.h | 3 ++-
include/linux/sh_eth.h | 3 ++-
include/linux/smsc911x.h | 3 ++-
include/linux/uwb/spec.h | 5 ++--
include/media/tveeprom.h | 4 ++-
include/net/irda/irlan_common.h | 3 ++-
12 files changed, 61 insertions(+), 46 deletions(-)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index ffaac0e..3f0f11c 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -44,6 +44,8 @@
#ifndef __ACTBL2_H__
#define __ACTBL2_H__
+#include <linux/if_ether.h>
+
/*******************************************************************************
*
* Additional ACPI Tables (2)
@@ -605,7 +607,7 @@ struct acpi_ibft_nic {
u8 secondary_dns[16];
u8 dhcp[16];
u16 vlan;
- u8 mac_address[6];
+ u8 mac_address[ETH_ALEN];
u16 pci_address;
u16 name_length;
u16 name_offset;
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 96e8769..841925f 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -14,6 +14,8 @@
#ifndef __DM9000_PLATFORM_DATA
#define __DM9000_PLATFORM_DATA __FILE__
+#include <linux/if_ether.h>
+
/* IO control flags */
#define DM9000_PLATF_8BITONLY (0x0001)
@@ -27,7 +29,7 @@
struct dm9000_plat_data {
unsigned int flags;
- unsigned char dev_addr[6];
+ unsigned char dev_addr[ETH_ALEN];
/* allow replacement IO routines */
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..343d82a 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -18,6 +18,7 @@
#include <linux/string.h>
#include <linux/of_mdio.h>
+#include <linux/if_ether.h>
#include <asm/types.h>
#define FS_ENET_NAME "fs_enet"
@@ -135,7 +136,7 @@ struct fs_platform_info {
const struct fs_mii_bus_info *bus_info;
int rx_ring, tx_ring; /* number of buffers on rx */
- __u8 macaddr[6]; /* mac address */
+ __u8 macaddr[ETH_ALEN]; /* mac address */
int rx_copybreak; /* limit we copy small frames */
int use_napi; /* use NAPI */
int napi_weight; /* NAPI weight */
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b0dc87a..4e101af 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -16,6 +16,7 @@
#define LINUX_IEEE80211_H
#include <linux/types.h>
+#include <linux/if_ether.h>
#include <asm/byteorder.h>
/*
@@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
- u8 addr4[6];
+ u8 addr4[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_hdr_3addr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
} __packed __aligned(2);
struct ieee80211_qos_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
__le16 qos_ctrl;
} __packed __aligned(2);
@@ -608,8 +609,8 @@ struct ieee80211s_hdr {
u8 flags;
u8 ttl;
__le32 seqnum;
- u8 eaddr1[6];
- u8 eaddr2[6];
+ u8 eaddr1[ETH_ALEN];
+ u8 eaddr2[ETH_ALEN];
} __packed __aligned(2);
/* Mesh flags */
@@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
u8 rann_flags;
u8 rann_hopcount;
u8 rann_ttl;
- u8 rann_addr[6];
+ u8 rann_addr[ETH_ALEN];
__le32 rann_seq;
__le32 rann_interval;
__le32 rann_metric;
@@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
struct ieee80211_mgmt {
__le16 frame_control;
__le16 duration;
- u8 da[6];
- u8 sa[6];
- u8 bssid[6];
+ u8 da[ETH_ALEN];
+ u8 sa[ETH_ALEN];
+ u8 bssid[ETH_ALEN];
__le16 seq_ctrl;
union {
struct {
@@ -833,7 +834,7 @@ struct ieee80211_mgmt {
struct {
__le16 capab_info;
__le16 listen_interval;
- u8 current_ap[6];
+ u8 current_ap[ETH_ALEN];
/* followed by SSID and Supported rates */
u8 variable[0];
} __packed reassoc_req;
@@ -966,21 +967,21 @@ struct ieee80211_vendor_ie {
struct ieee80211_rts {
__le16 frame_control;
__le16 duration;
- u8 ra[6];
- u8 ta[6];
+ u8 ra[ETH_ALEN];
+ u8 ta[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_cts {
__le16 frame_control;
__le16 duration;
- u8 ra[6];
+ u8 ra[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_pspoll {
__le16 frame_control;
__le16 aid;
- u8 bssid[6];
- u8 ta[6];
+ u8 bssid[ETH_ALEN];
+ u8 ta[ETH_ALEN];
} __packed __aligned(2);
/* TDLS */
@@ -989,14 +990,14 @@ struct ieee80211_pspoll {
struct ieee80211_tdls_lnkie {
u8 ie_type; /* Link Identifier IE */
u8 ie_len;
- u8 bssid[6];
- u8 init_sta[6];
- u8 resp_sta[6];
+ u8 bssid[ETH_ALEN];
+ u8 init_sta[ETH_ALEN];
+ u8 resp_sta[ETH_ALEN];
} __packed;
struct ieee80211_tdls_data {
- u8 da[6];
- u8 sa[6];
+ u8 da[ETH_ALEN];
+ u8 sa[ETH_ALEN];
__be16 ether_type;
u8 payload_type;
u8 category;
@@ -1090,8 +1091,8 @@ struct ieee80211_p2p_noa_attr {
struct ieee80211_bar {
__le16 frame_control;
__le16 duration;
- __u8 ra[6];
- __u8 ta[6];
+ __u8 ra[ETH_ALEN];
+ __u8 ta[ETH_ALEN];
__le16 control;
__le16 start_seq_num;
} __packed;
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 52c23a8..e37ac2b 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -33,6 +33,7 @@
#ifndef MLX4_DEVICE_H
#define MLX4_DEVICE_H
+#include <linux/if_ether.h>
#include <linux/pci.h>
#include <linux/completion.h>
#include <linux/radix-tree.h>
@@ -619,7 +620,7 @@ struct mlx4_eth_av {
u8 dgid[16];
u32 reserved4[2];
__be16 vlan;
- u8 mac[6];
+ u8 mac[ETH_ALEN];
};
union mlx4_ext_av {
@@ -913,10 +914,10 @@ enum mlx4_net_trans_promisc_mode {
};
struct mlx4_spec_eth {
- u8 dst_mac[6];
- u8 dst_mac_msk[6];
- u8 src_mac[6];
- u8 src_mac_msk[6];
+ u8 dst_mac[ETH_ALEN];
+ u8 dst_mac_msk[ETH_ALEN];
+ u8 src_mac[ETH_ALEN];
+ u8 src_mac_msk[ETH_ALEN];
u8 ether_type_enable;
__be16 ether_type;
__be16 vlan_id_msk;
diff --git a/include/linux/mlx4/qp.h b/include/linux/mlx4/qp.h
index 262deac..6d35147 100644
--- a/include/linux/mlx4/qp.h
+++ b/include/linux/mlx4/qp.h
@@ -34,6 +34,7 @@
#define MLX4_QP_H
#include <linux/types.h>
+#include <linux/if_ether.h>
#include <linux/mlx4/device.h>
@@ -143,7 +144,7 @@ struct mlx4_qp_path {
u8 feup;
u8 fvl_rx;
u8 reserved4[2];
- u8 dmac[6];
+ u8 dmac[ETH_ALEN];
};
enum { /* fl */
@@ -318,7 +319,7 @@ struct mlx4_wqe_datagram_seg {
__be32 dqpn;
__be32 qkey;
__be16 vlan;
- u8 mac[6];
+ u8 mac[ETH_ALEN];
};
struct mlx4_wqe_lso_seg {
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 6e8215b..61a0da3 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -6,6 +6,7 @@
#define __LINUX_MV643XX_ETH_H
#include <linux/mbus.h>
+#include <linux/if_ether.h>
#define MV643XX_ETH_SHARED_NAME "mv643xx_eth"
#define MV643XX_ETH_NAME "mv643xx_eth_port"
@@ -48,7 +49,7 @@ struct mv643xx_eth_platform_data {
* Use this MAC address if it is valid, overriding the
* address that is already in the hardware.
*/
- u8 mac_addr[6];
+ u8 mac_addr[ETH_ALEN];
/*
* If speed is 0, autonegotiation is enabled.
diff --git a/include/linux/sh_eth.h b/include/linux/sh_eth.h
index fc30571..6205eeb 100644
--- a/include/linux/sh_eth.h
+++ b/include/linux/sh_eth.h
@@ -2,6 +2,7 @@
#define __ASM_SH_ETH_H__
#include <linux/phy.h>
+#include <linux/if_ether.h>
enum {EDMAC_LITTLE_ENDIAN, EDMAC_BIG_ENDIAN};
enum {
@@ -18,7 +19,7 @@ struct sh_eth_plat_data {
phy_interface_t phy_interface;
void (*set_mdio_gate)(void *addr);
- unsigned char mac_addr[6];
+ unsigned char mac_addr[ETH_ALEN];
unsigned no_ether_link:1;
unsigned ether_link_active_low:1;
unsigned needs_init:1;
diff --git a/include/linux/smsc911x.h b/include/linux/smsc911x.h
index 4dde70e..eec3efd 100644
--- a/include/linux/smsc911x.h
+++ b/include/linux/smsc911x.h
@@ -22,6 +22,7 @@
#define __LINUX_SMSC911X_H__
#include <linux/phy.h>
+#include <linux/if_ether.h>
/* platform_device configuration data, should be assigned to
* the platform_device's dev.platform_data */
@@ -31,7 +32,7 @@ struct smsc911x_platform_config {
unsigned int flags;
unsigned int shift;
phy_interface_t phy_interface;
- unsigned char mac[6];
+ unsigned char mac[ETH_ALEN];
};
/* Constants for platform_device irq polarity configuration */
diff --git a/include/linux/uwb/spec.h b/include/linux/uwb/spec.h
index b52e44f..0df24bf 100644
--- a/include/linux/uwb/spec.h
+++ b/include/linux/uwb/spec.h
@@ -32,6 +32,7 @@
#include <linux/types.h>
#include <linux/bitmap.h>
+#include <linux/if_ether.h>
#define i1480_FW 0x00000303
/* #define i1480_FW 0x00000302 */
@@ -130,7 +131,7 @@ enum { UWB_DRP_BACKOFF_WIN_MAX = 16 };
* it is also used to define headers sent down and up the wire/radio).
*/
struct uwb_mac_addr {
- u8 data[6];
+ u8 data[ETH_ALEN];
} __attribute__((packed));
@@ -568,7 +569,7 @@ struct uwb_rc_evt_confirm {
/* Device Address Management event. [WHCI] section 3.1.3.2. */
struct uwb_rc_evt_dev_addr_mgmt {
struct uwb_rceb rceb;
- u8 baAddr[6];
+ u8 baAddr[ETH_ALEN];
u8 bResultCode;
} __attribute__((packed));
diff --git a/include/media/tveeprom.h b/include/media/tveeprom.h
index 4a1191a..f7119ee 100644
--- a/include/media/tveeprom.h
+++ b/include/media/tveeprom.h
@@ -12,6 +12,8 @@ enum tveeprom_audio_processor {
TVEEPROM_AUDPROC_OTHER,
};
+#include <linux/if_ether.h>
+
struct tveeprom {
u32 has_radio;
/* If has_ir == 0, then it is unknown what the IR capabilities are,
@@ -40,7 +42,7 @@ struct tveeprom {
u32 revision;
u32 serial_number;
char rev_str[5];
- u8 MAC_address[6];
+ u8 MAC_address[ETH_ALEN];
};
void tveeprom_hauppauge_analog(struct i2c_client *c, struct tveeprom *tvee,
diff --git a/include/net/irda/irlan_common.h b/include/net/irda/irlan_common.h
index 0af8b8d..550c2d6 100644
--- a/include/net/irda/irlan_common.h
+++ b/include/net/irda/irlan_common.h
@@ -32,6 +32,7 @@
#include <linux/types.h>
#include <linux/skbuff.h>
#include <linux/netdevice.h>
+#include <linux/if_ether.h>
#include <net/irda/irttp.h>
@@ -161,7 +162,7 @@ struct irlan_provider_cb {
int access_type; /* Access type */
__u16 send_arb_val;
- __u8 mac_address[6]; /* Generated MAC address for peer device */
+ __u8 mac_address[ETH_ALEN]; /* Generated MAC address for peer device */
};
/*
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* RE: [PATCH v2] powerpc: Update compilation flags with core specific options
From: Udma Catalin-Dan-B32721 @ 2013-07-29 8:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6CCCB1C2-FA50-476A-B3D0-9F8FCAC404E5@kernel.crashing.org>
> > The assembler option is redundant if the -mcpu=3D flag is set.
> > The patch fixes the kernel compilation problem for e5500/e6500
> > when using gcc option -mcpu=3De5500/e6500.
> >
> > Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
> > ---
> > changes for v2:
> > - update also KBUILD_AFLAGS with -mcpu and -msoft-float flags
> >
> > arch/powerpc/Makefile | 16 +++++++++++++++-
> > 1 files changed, 15 insertions(+), 1 deletions(-)
>=20
> Is the assembler redundant for older toolchains?
>=20
> - k
[CU] gcc defines the mapping from -mcpu to assembler options in file
gcc/config/rs6000/rs6000.h, like this:
%{mcpu=3D8540: -me500} \
%{mcpu=3D8548: -me500} \
%{mcpu=3De300c2: -me300} \
%{mcpu=3De300c3: -me300} \
%{mcpu=3De500mc: -me500mc} \
%{mcpu=3De500mc64: -me500mc64} \
%{mcpu=3De5500: -me5500} \
%{mcpu=3De6500: -me6500} \
I have checked this mapping from gcc 3.3 (where 8540 entry was added) to
3.4, 4.3, 4.4 and 4.8.1...The -Wa option is redundant for all these
older toolchains.
Catalin
^ permalink raw reply
* Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
From: Preeti U Murthy @ 2013-07-29 10:11 UTC (permalink / raw)
To: svaidy
Cc: deepthi, shangw, arnd, linux-pm, geoff, linux-kernel, rostedt,
rjw, paul.gortmaker, paulus, srivatsa.bhat, Frederic Weisbecker,
schwidefsky, john.stultz, tglx, paulmck, linuxppc-dev,
chenhui.zhao
In-Reply-To: <20130729052810.GB8832@dirshya.in.ibm.com>
Hi,
On 07/29/2013 10:58 AM, Vaidyanathan Srinivasan wrote:
> * Preeti U Murthy <preeti@linux.vnet.ibm.com> [2013-07-27 13:20:37]:
>
>> Hi Ben,
>>
>> On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote:
>>> On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
>>>> *The lapic of a broadcast CPU is active always*. Say CPUX, wants the
>>>> broadcast CPU to wake it up at timeX. Since we cannot program the lapic
>>>> of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
>>>> asking it to program its lapic to fire at timeX so as to wake up CPUX.
>>>> *With multiple CPUs the overhead of sending IPI, could result in
>>>> performance bottlenecks and may not scale well.*
>>>>
>>>> Hence the workaround is that the broadcast CPU on each of its timer
>>>> interrupt checks if any of the next timer event of a CPU in deep idle
>>>> state has expired, which can very well be found from dev->next_event of
>>>> that CPU. For example the timeX that has been mentioned above has
>>>> expired. If so the broadcast handler is called to send an IPI to the
>>>> idling CPU to wake it up.
>>>>
>>>> *If the broadcast CPU, is in tickless idle, its timer interrupt could be
>>>> many ticks away. It could miss waking up a CPU in deep idle*, if its
>>>> wakeup is much before this timer interrupt of the broadcast CPU. But
>>>> without tickless idle, atleast at each period we are assured of a timer
>>>> interrupt. At which time broadcast handling is done as stated in the
>>>> previous paragraph and we will not miss wakeup of CPUs in deep idle states.
>>>
>>> But that means a great loss of power saving on the broadcast CPU when the machine
>>> is basically completely idle. We might be able to come up with some thing better.
>>>
>>> (Note : I do no know the timer offload code if it exists already, I'm describing
>>> how things could happen "out of the blue" without any knowledge of pre-existing
>>> framework here)
>>>
>>> We can know when the broadcast CPU expects to wake up next. When a CPU goes to
>>> a deep sleep state, it can then
>>>
>>> - Indicate to the broadcast CPU when it intends to be woken up by queuing
>>> itself into an ordered queue (ordered by target wakeup time). (OPTIMISATION:
>>> Play with the locality of that: have one queue (and one "broadcast CPU") per
>>> chip or per node instead of a global one to limit cache bouncing).
>>>
>>> - Check if that happens before the broadcast CPU intended wake time (we
>>> need statistics to see how often that happens), and in that case send an IPI
>>> to wake it up now. When the broadcast CPU goes to sleep, it limits its sleep
>>> time to the min of it's intended sleep time and the new sleeper time.
>>> (OPTIMISATION: Dynamically chose a broadcast CPU based on closest expiry ?)
>>>
>>> - We can probably limit spurrious wakeups a *LOT* by aligning that target time
>>> to a global jiffy boundary, meaning that several CPUs going to idle are likely
>>> to be choosing the same. Or maybe better, an adaptative alignment by essentially
>>> getting more coarse grained as we go further in the future
>>>
>>> - When the "broadcast" CPU goes to sleep, it can play the same game of alignment.
>>>
>>> I don't like the concept of a dedicated broadcast CPU however. I'd rather have a
>>> general queue (or per node) of sleepers needing a wakeup and more/less dynamically
>>> pick a waker to be the last man standing, but it does make things a bit more
>>> tricky with tickless scheduler (non-idle).
>>>
>>> Still, I wonder if we could just have some algorithm to actually pick wakers
>>> more dynamically based on who ever has the closest "next wakeup" planned,
>>> that sort of thing. A fixed broadcaster will create an imbalance in
>>> power/thermal within the chip in addition to needing to be moved around on
>>> hotplug etc...
>>
>> Thank you for having listed out the above suggestions. Below, I will
>> bring out some ideas about how the concerns that you have raised can be
>> addressed in the increasing order of priority.
>>
>> - To begin with, I think we can have the following model to have the
>> responsibility of the broadcast CPU float around certain CPUs. i.e. Not
>> have a dedicated broadcast CPU. I will refer to the broadcast CPU as the
>> bc_cpu henceforth for convenience.
>>
>> 1. The first CPU that intends to enter deep sleep state will be the bc_cpu.
>>
>> 2. Every other CPU that intends to enter deep idle state will enter
>> themselves into a mask, say the bc_mask, which is already being done
>> today, after they check that a bc_cpu has been assigned.
>>
>> 3. The bc_cpu should not enter tickless idle, until step 5a holds true.
>>
>> 4. So on every timer interrupt, which is at-least every period, it
>> checks the bc_mask to see if any CPUs need to be woken up.
>>
>> 5. The bc cpu should not enter tickless idle *until* it is de-nominated
>> as the bc_cpu. The de-nomination occurs when:
>> a. In one of its timer interrupts, it does broadcast handling to find
>> out that there are no CPUs to be woken up.
>>
>> 6. So if 5a holds, then there is no bc_cpu anymore until a CPU decides
>> to enter deep idle state again, in which case steps 1 to 5 repeat.
>>
>>
>> - We could optimize this further, to allow the bc_cpu to enter tickless
>> idle, even while it is nominated as one. This can be the next step, if
>> we can get the above to work stably.
>>
>> You have already brought out this point, so I will just reword it. Each
>> time broadcast handling is done, the bc_cpu needs to check if the wakeup
>> time of a CPU, that has entered deep idle state, and is yet to be woken
>> up, is before the bc_cpu's wakeup time, which was programmed to its
>> local events.
>>
>> If so, then reprogram the decrementer to the wakeup time of a CPU that
>> is in deep idle state.
>>
>> But we need to keep in mind one point. When CPUs go into deep idle, they
>> cannot program the local timer of the bc_cpu to their wakeup time. This
>> is because a CPU cannot program the timer of a remote CPU.
>>
>> Therefore the only time we can check if 'wakeup time of the CPU that
>> enters deep idle state is before broadcast CPU's intended wake time so
>> as to reprogram the decrementer', is in the broadcast handler itself,
>> which is done *on* the bc_cpu alone.
>>
>>
>>
>> What do you think?
>>
>>
>> - Coming to your third suggestion of aligning the wakeup time of CPUs, I
>> will spend some time on this and get back regarding the same.
>
> Hi Preeti,
>
> One of Ben's suggestions is to coarse grain the waker's timer event.
> The trade off is whether we issue an IPI for each CPU needing a wakeup
> or let the bc_cpu wakeup periodically and *see* that there is a new
> request. The interval for a wakeup request will be much coarse grain
> than a tick. We maybe able to easily reduce the power impact of not
> letting bc_cpu go tickless by choosing a right coarse grain period.
> For example we can let the bc_cpu look for new wakeup requests once in
> every 10 or 20 jiffies rather than every jiffy and align the wakeup
> requests at this coarse grain wakeup. We do pay a power penalty by
> waking up few jiffies earlier which we can mitigate by reevaluating
> the situation and queueing a fine grain timer to the right jiffy on
> the bc_cpu if such a situation arises.
>
> The point is a new wakeup request will *ask* for a wakeup later than
> the coarse grain period. So the bc_cpu can wakeup at the coarse time
> period and reprogram its timer to the right jiffy.
>
> --Vaidy
Thanks Ben, Vaidy for your suggestions.
I will work on the second version of this patchset, which will address
two major issues that are brought out in this thread:
1. Dynamically choosing a broadcast CPU and floating this responsibility
around. This could have a lot of scope for optimization. and can be done
in steps. To begin with we could have the first CPU that sleeps to be
nominated the broadcast CPU. It would be relieved of this duty when
there are no more CPUs in deep idle states to be woken up. The next time
a CPU enters deep idle it will be nominated as the broadcast CPU.
However although the above will address the problems associated with a
dedicated broadcast CPU, it still does not solve the issue with
broadcast CPU having to refrain from entering tickless idle.
Point 2 will address this issue to an extent.
2. Have a timer on the broadcast CPU, that is specifically intended to
wake up CPUs in deep idle states. This timer will have a fixed period
much larger than a jiffy, a period sufficient enough not to miss wakeup
of CPUs in deep idle states. But if the wakeup of a CPU in deep idle is
smaller than this fixed period, it will send an IPI to the broadcast CPU
to reprogram its decrementer for this wakeup. This will allow the
broadcast CPU to enter tickless idle.
This is as opposed to the current approach where we have the broadcast
CPU waking up every periodic tick to check if broadcast is required.
Do let me know if there are points that are missed, which need to be
considered as pressing next steps.
Thank you
Regards
Preeti U Murthy
^ permalink raw reply
* [PATCH v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: hongbo.zhang @ 2013-07-29 10:49 UTC (permalink / raw)
To: vinod.koul, djbw, leoli, scottwood, linuxppc-dev
Cc: Hongbo Zhang, devicetree, linux-kernel
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches.
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.
V6->V7 changes:
- only remove unnecessary "CHIP-dma" explanations in [1/3]
V5->V6 changes:
- minor updates of descriptions in binding document and Kconfig
- remove [4/4], that should be another patch in future
V4->V5 changes:
- update description in the dt binding document, to make it more resonable
- add new patch [4/4] to eliminate a compiling warning which already exists
for a long time
V3->V4 changes:
- introduce new patch [1/3] to revise the legacy dma binding document
- and then add new paragraph to describe new dt node binding in [2/3]
- rebase to latest kernel v3.11-rc1
V2->V3 changes:
- edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt
- edit text string in Kconfig and the driver files, using "elo series" to
mention all the current "elo*"
V1->V2 changes:
- removed the codes handling the register dgsr1, since it isn't used currently
- renamed the DMA DT compatible to "fsl,elo3-dma"
- renamed the new dts files to "elo3-dma-<n>.dtsi"
Hongbo Zhang (3):
DMA: Freescale: revise device tree binding document
DMA: Freescale: Add new 8-channel DMA engine device tree nodes
DMA: Freescale: update driver to support 8-channel DMA engine
.../devicetree/bindings/powerpc/fsl/dma.txt | 114 +++++++++++++++-----
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++++++++++++++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++++++++++++++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
drivers/dma/Kconfig | 9 +-
drivers/dma/fsldma.c | 9 +-
drivers/dma/fsldma.h | 2 +-
8 files changed, 264 insertions(+), 40 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
--
1.7.9.5
^ permalink raw reply
* [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: hongbo.zhang @ 2013-07-29 10:49 UTC (permalink / raw)
To: vinod.koul, djbw, leoli, scottwood, linuxppc-dev
Cc: Hongbo Zhang, devicetree, linux-kernel
In-Reply-To: <1375094944-3343-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/dma.txt | 66 ++++++++++++++++
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 6e9384b..2e66c3d 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible : must include "fsl,elo3-dma"
+- reg : <registers mapping for DMA general status reg>
+- ranges : describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+ - compatible : must include "fsl,eloplus-dma-channel"
+ - reg : <registers mapping for channel>
+ - interrupts : <interrupt mapping for DMA channel IRQ>
+ - interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4 0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = <0xe2000 0x1000>;
};
-/include/ "qoriq-dma-0.dtsi"
+/include/ "elo3-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
};
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-1.dtsi"
dma@101300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 0000000..69a3277
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
@@ -0,0 +1,81 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x100000 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma0: dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4 0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
new file mode 100644
index 0000000..d410948
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
@@ -0,0 +1,81 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x101000 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma1: dma@101300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x101300 0x4 0x101600 0x4>;
+ ranges = <0x0 0x101100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <32 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <33 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <34 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <35 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <80 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <81 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <82 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <83 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index bd611a9..ec95c60 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -387,8 +387,8 @@
reg = <0xea000 0x4000>;
};
-/include/ "qoriq-dma-0.dtsi"
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-0.dtsi"
+/include/ "elo3-dma-1.dtsi"
/include/ "qoriq-espi-0.dtsi"
spi@110000 {
--
1.7.9.5
^ 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