* [RFC 5/6] sched: pack the idle load balance
From: Vincent Guittot @ 2012-10-29 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50880774.5090605@ti.com>
On 24 October 2012 17:21, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
>>
>> Look for an idle CPU close the pack buddy CPU whenever possible.
>
> s/close/close to
yes
>
>> The goal is to prevent the wake up of a CPU which doesn't share the power
>> line of the pack CPU
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> ---
>> kernel/sched/fair.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 6df53b5..f76acdc 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5158,7 +5158,25 @@ static struct {
>>
>> static inline int find_new_ilb(int call_cpu)
>> {
>> + struct sched_domain *sd;
>> int ilb = cpumask_first(nohz.idle_cpus_mask);
>> + int buddy = per_cpu(sd_pack_buddy, call_cpu);
>> +
>> + /*
>> + * If we have a pack buddy CPU, we try to run load balance on a
>> CPU
>> + * that is close to the buddy.
>> + */
>> + if (buddy != -1)
>> + for_each_domain(buddy, sd) {
>> + if (sd->flags & SD_SHARE_CPUPOWER)
>> + continue;
>
> Do you mean SD_SHARE_POWERLINE here ?
No, I just don't want to take hyperthread level for ILB
>
>> +
>> + ilb = cpumask_first_and(sched_domain_span(sd),
>> + nohz.idle_cpus_mask);
>> +
>> + if (ilb < nr_cpu_ids)
>> + break;
>> + }
>>
>> if (ilb < nr_cpu_ids && idle_cpu(ilb))
>> return ilb;
>>
> Can you please expand "idle CPU _close_ the pack buddy CPU" ?
The goal is to packed the tasks on the pack buddy CPU so when the
scheduler needs to start ILB, I try to wake up a CPU that is close to
the buddy and preferably in the same cluster
>
> Regards
> santosh
^ permalink raw reply
* [RFC 4/6] sched: secure access to other CPU statistics
From: Vincent Guittot @ 2012-10-29 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5088076D.6080208@ti.com>
On 24 October 2012 17:21, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> $subject is bit confusing here.
>
>
> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
>>
>> The atomic update of runnable_avg_sum and runnable_avg_period are ensured
>> by their size and the toolchain. But we must ensure to not read an old
>> value
>> for one field and a newly updated value for the other field. As we don't
>> want to lock other CPU while reading these fields, we read twice each
>> fields
>> and check that no change have occured in the middle.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> ---
>> kernel/sched/fair.c | 19 +++++++++++++++++--
>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 8c9d3ed..6df53b5 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -3133,13 +3133,28 @@ static int select_idle_sibling(struct task_struct
>> *p, int target)
>> static inline bool is_buddy_busy(int cpu)
>> {
>> struct rq *rq = cpu_rq(cpu);
>> + volatile u32 *psum = &rq->avg.runnable_avg_sum;
>> + volatile u32 *pperiod = &rq->avg.runnable_avg_period;
>> + u32 sum, new_sum, period, new_period;
>> + int timeout = 10;
>
> So it can be 2 times read or more as well.
>
>> +
>> + while (timeout) {
>> + sum = *psum;
>> + period = *pperiod;
>> + new_sum = *psum;
>> + new_period = *pperiod;
>> +
>> + if ((sum == new_sum) && (period == new_period))
>> + break;
>> +
>> + timeout--;
>> + }
>>
> Seems like you did notice incorrect pair getting read
> for rq runnable_avg_sum and runnable_avg_period. Seems
> like the fix is to update them together under some lock
> to avoid such issues.
My goal is to have a lock free mechanism because I don't want to lock
another CPU while reading its statistic
>
> Regards
> Santosh
>
^ permalink raw reply
* [PATCH] ARM: Exynos5: Remove static io-remapping for gic and combiner
From: Thomas Abraham @ 2012-10-29 13:16 UTC (permalink / raw)
To: linux-arm-kernel
The physical base address of GIC and Interrupt Combiner is obtained from
device tree and then remapped during initialization. So remove the
static io-remapping for GIC and combiner.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos/common.c | 15 ---------------
1 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 5a305f0..5c75815 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -256,25 +256,10 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.length = SZ_64K,
.type = MT_DEVICE,
}, {
- .virtual = (unsigned long)S5P_VA_COMBINER_BASE,
- .pfn = __phys_to_pfn(EXYNOS5_PA_COMBINER),
- .length = SZ_4K,
- .type = MT_DEVICE,
- }, {
.virtual = (unsigned long)S3C_VA_UART,
.pfn = __phys_to_pfn(EXYNOS5_PA_UART),
.length = SZ_512K,
.type = MT_DEVICE,
- }, {
- .virtual = (unsigned long)S5P_VA_GIC_CPU,
- .pfn = __phys_to_pfn(EXYNOS5_PA_GIC_CPU),
- .length = SZ_8K,
- .type = MT_DEVICE,
- }, {
- .virtual = (unsigned long)S5P_VA_GIC_DIST,
- .pfn = __phys_to_pfn(EXYNOS5_PA_GIC_DIST),
- .length = SZ_4K,
- .type = MT_DEVICE,
},
};
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH] ARM: Exynos5: Remove unused static uart resource information
From: Thomas Abraham @ 2012-10-29 13:14 UTC (permalink / raw)
To: linux-arm-kernel
All supported Exynos5 platforms are device tree enabled and hence the
unused static uart resource information is removed.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos/common.c | 6 +-----
arch/arm/mach-exynos/dev-uart.c | 24 ------------------------
arch/arm/mach-exynos/include/mach/irqs.h | 5 -----
arch/arm/mach-exynos/include/mach/map.h | 1 -
4 files changed, 1 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 1947be8..5a305f0 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -96,7 +96,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idmask = EXYNOS5_SOC_MASK,
.map_io = exynos5_map_io,
.init_clocks = exynos5_init_clocks,
- .init_uarts = exynos_init_uarts,
.init = exynos_init,
.name = name_exynos5250,
},
@@ -735,10 +734,7 @@ static void __init exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no)
for (ucnt = 0; ucnt < no; ucnt++, tcfg++)
tcfg->has_fracval = 1;
- if (soc_is_exynos5250())
- s3c24xx_init_uartdevs("exynos4210-uart", exynos5_uart_resources, cfg, no);
- else
- s3c24xx_init_uartdevs("exynos4210-uart", exynos4_uart_resources, cfg, no);
+ s3c24xx_init_uartdevs("exynos4210-uart", exynos4_uart_resources, cfg, no);
}
static void __iomem *exynos_eint_base;
diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c
index 2e85c02..7c42f4b 100644
--- a/arch/arm/mach-exynos/dev-uart.c
+++ b/arch/arm/mach-exynos/dev-uart.c
@@ -52,27 +52,3 @@ struct s3c24xx_uart_resources exynos4_uart_resources[] __initdata = {
.nr_resources = ARRAY_SIZE(exynos4_uart3_resource),
},
};
-
-EXYNOS_UART_RESOURCE(5, 0)
-EXYNOS_UART_RESOURCE(5, 1)
-EXYNOS_UART_RESOURCE(5, 2)
-EXYNOS_UART_RESOURCE(5, 3)
-
-struct s3c24xx_uart_resources exynos5_uart_resources[] __initdata = {
- [0] = {
- .resources = exynos5_uart0_resource,
- .nr_resources = ARRAY_SIZE(exynos5_uart0_resource),
- },
- [1] = {
- .resources = exynos5_uart1_resource,
- .nr_resources = ARRAY_SIZE(exynos5_uart0_resource),
- },
- [2] = {
- .resources = exynos5_uart2_resource,
- .nr_resources = ARRAY_SIZE(exynos5_uart2_resource),
- },
- [3] = {
- .resources = exynos5_uart3_resource,
- .nr_resources = ARRAY_SIZE(exynos5_uart3_resource),
- },
-};
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
index 35bced6..6da3115 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -259,11 +259,6 @@
#define EXYNOS5_IRQ_IEM_IEC IRQ_SPI(48)
#define EXYNOS5_IRQ_IEM_APC IRQ_SPI(49)
#define EXYNOS5_IRQ_GPIO_C2C IRQ_SPI(50)
-#define EXYNOS5_IRQ_UART0 IRQ_SPI(51)
-#define EXYNOS5_IRQ_UART1 IRQ_SPI(52)
-#define EXYNOS5_IRQ_UART2 IRQ_SPI(53)
-#define EXYNOS5_IRQ_UART3 IRQ_SPI(54)
-#define EXYNOS5_IRQ_UART4 IRQ_SPI(55)
#define EXYNOS5_IRQ_IIC IRQ_SPI(56)
#define EXYNOS5_IRQ_IIC1 IRQ_SPI(57)
#define EXYNOS5_IRQ_IIC2 IRQ_SPI(58)
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 8480849..e737331 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -279,7 +279,6 @@
#define EXYNOS5_PA_UART1 0x12C10000
#define EXYNOS5_PA_UART2 0x12C20000
#define EXYNOS5_PA_UART3 0x12C30000
-#define EXYNOS5_SZ_UART SZ_256
#define S3C_VA_UARTx(x) (S3C_VA_UART + ((x) * S3C_UART_OFFSET))
--
1.6.6.rc2
^ permalink raw reply related
* [RFC 3/6] sched: pack small tasks
From: Vincent Guittot @ 2012-10-29 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50880750.4060809@ti.com>
On 24 October 2012 17:20, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> Vincent,
>
> Few comments/questions.
>
>
> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
>>
>> During sched_domain creation, we define a pack buddy CPU if available.
>>
>> On a system that share the powerline at all level, the buddy is set to -1
>>
>> On a dual clusters / dual cores system which can powergate each core and
>> cluster independantly, the buddy configuration will be :
>> | CPU0 | CPU1 | CPU2 | CPU3 |
>> -----------------------------------
>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>
> ^
> Is that a typo ? Should it be CPU2 instead of
> CPU0 ?
No it's not a typo.
The system packs at each scheduling level. It starts to pack in
cluster because each core can power gate independently so CPU1 tries
to pack its tasks in CPU0 and CPU3 in CPU2. Then, it packs at CPU
level so CPU2 tries to pack in the cluster of CPU0 and CPU0 packs in
itself
>
>
>> Small tasks tend to slip out of the periodic load balance.
>> The best place to choose to migrate them is at their wake up.
>>
> I have tried this series since I was looking at some of these packing
> bits. On Mobile workloads like OSIdle with Screen ON, MP3, gallary,
> I did see some additional filtering of threads with this series
> but its not making much difference in power. More on this below.
Can I ask you which configuration you have used ? how many cores and
cluster ? Can they be power gated independently ?
>
>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> ---
>> kernel/sched/core.c | 1 +
>> kernel/sched/fair.c | 109
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>> kernel/sched/sched.h | 1 +
>> 3 files changed, 111 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index dab7908..70cadbe 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
>> root_domain *rd, int cpu)
>> rcu_assign_pointer(rq->sd, sd);
>> destroy_sched_domains(tmp, cpu);
>>
>> + update_packing_domain(cpu);
>> update_top_cache_domain(cpu);
>> }
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 4f4a4f6..8c9d3ed 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -157,6 +157,63 @@ void sched_init_granularity(void)
>> update_sysctl();
>> }
>>
>> +
>> +/*
>> + * Save the id of the optimal CPU that should be used to pack small tasks
>> + * The value -1 is used when no buddy has been found
>> + */
>> +DEFINE_PER_CPU(int, sd_pack_buddy);
>> +
>> +/* Look for the best buddy CPU that can be used to pack small tasks
>> + * We make the assumption that it doesn't wort to pack on CPU that share
>> the
>
> s/wort/worth
yes
>
>> + * same powerline. We looks for the 1st sched_domain without the
>> + * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the
>> lowest
>> + * power per core based on the assumption that their power efficiency is
>> + * better */
>
> Commenting style..
> /*
> *
> */
>
yes
> Can you please expand the why the assumption is right ?
> "it doesn't wort to pack on CPU that share the same powerline"
By "share the same power-line", I mean that the CPUs can't power off
independently. So if some CPUs can't power off independently, it's
worth to try to use most of them to race to idle.
>
> Think about a scenario where you have quad core, ducal cluster system
>
> |Cluster1| |cluster 2|
> | CPU0 | CPU1 | CPU2 | CPU3 | | CPU0 | CPU1 | CPU2 | CPU3 |
>
>
> Both clusters run from same voltage rail and have same PLL
> clocking them. But the cluster have their own power domain
> and all CPU's can power gate them-self to low power states.
> Clusters also have their own level2 caches.
>
> In this case, you will still save power if you try to pack
> load on one cluster. No ?
yes, I need to update the description of SD_SHARE_POWERLINE because
I'm afraid I was not clear enough. SD_SHARE_POWERLINE includes the
power gating capacity of each core. For your example above, the
SD_SHARE_POWERLINE shoud be cleared at both MC and CPU level.
>
>
>> +void update_packing_domain(int cpu)
>> +{
>> + struct sched_domain *sd;
>> + int id = -1;
>> +
>> + sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
>> + if (!sd)
>> + sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
>> + else
>> + sd = sd->parent;
>> +
>> + while (sd) {
>> + struct sched_group *sg = sd->groups;
>> + struct sched_group *pack = sg;
>> + struct sched_group *tmp = sg->next;
>> +
>> + /* 1st CPU of the sched domain is a good candidate */
>> + if (id == -1)
>> + id = cpumask_first(sched_domain_span(sd));
>> +
>> + /* loop the sched groups to find the best one */
>> + while (tmp != sg) {
>> + if (tmp->sgp->power * sg->group_weight <
>> + sg->sgp->power *
>> tmp->group_weight)
>> + pack = tmp;
>> + tmp = tmp->next;
>> + }
>> +
>> + /* we have found a better group */
>> + if (pack != sg)
>> + id = cpumask_first(sched_group_cpus(pack));
>> +
>> + /* Look for another CPU than itself */
>> + if ((id != cpu)
>> + || ((sd->parent) && !(sd->parent->flags &&
>> SD_LOAD_BALANCE)))
>
> Is the condition "!(sd->parent->flags && SD_LOAD_BALANCE)" for
> big.LITTLE kind of system where SD_LOAD_BALANCE may not be used ?
No, packing small tasks is part of the load balance so if the
LOAD_BALANCE flag is cleared, we will not try to pack which is a kind
of load balance. There is no link with big.LITTLE
>
>
>> + break;
>> +
>> + sd = sd->parent;
>> + }
>> +
>> + pr_info(KERN_INFO "CPU%d packing on CPU%d\n", cpu, id);
>> + per_cpu(sd_pack_buddy, cpu) = id;
>> +}
>> +
>> #if BITS_PER_LONG == 32
>> # define WMULT_CONST (~0UL)
>> #else
>> @@ -3073,6 +3130,55 @@ static int select_idle_sibling(struct task_struct
>> *p, int target)
>> return target;
>> }
>>
>> +static inline bool is_buddy_busy(int cpu)
>> +{
>> + struct rq *rq = cpu_rq(cpu);
>> +
>> + /*
>> + * A busy buddy is a CPU with a high load or a small load with a
>> lot of
>> + * running tasks.
>> + */
>> + return ((rq->avg.usage_avg_sum << rq->nr_running) >
>> + rq->avg.runnable_avg_period);
>
> I agree busy CPU is the one with high load, but many small threads may
> not make CPU fully busy, right ? Should we just stick to the load
> parameter alone here ?
IMO, the busy state of a CPU isn't only the load but also how many
threads are waiting for running on it. This formula tries to take into
account both inputs. If you have dozen of small tasks on a CPU, the
latency can be large even if the tasks are small.
>
>
>> +}
>> +
>> +static inline bool is_light_task(struct task_struct *p)
>> +{
>> + /* A light task runs less than 25% in average */
>> + return ((p->se.avg.usage_avg_sum << 2) <
>> p->se.avg.runnable_avg_period);
>> +}
>
> Since the whole packing logic relies on the light threads only, the
> overall effectiveness is not significant. Infact with multiple tries on
> Dual core system, I didn't see any major improvement in power. I think
> we need to be more aggressive here. From the cover letter, I noticed
> that, you were concerned about any performance drop due to packing and
> may be that is the reason you chose the conservative threshold. But the
> fact is, if we want to save meaningful power, there will be slight
> performance drop which is expected.
I think that everybody agrees that packing small tasks will save power
whereas it seems to be not so obvious for heavy task. But I may have
set the threshold a bit too low
Up to which load, you would like to pack on 1 core of your dual core system ?
Can you provide more details of your load ? Have you got a trace that
you can share ?
>
>
>> +static int check_pack_buddy(int cpu, struct task_struct *p)
>> +{
>> + int buddy = per_cpu(sd_pack_buddy, cpu);
>> +
>> + /* No pack buddy for this CPU */
>> + if (buddy == -1)
>> + return false;
>> +
>> + /*
>> + * If a task is waiting for running on the CPU which is its own
>> buddy,
>> + * let the default behavior to look for a better CPU if available
>> + * The threshold has been set to 37.5%
>> + */
>> + if ((buddy == cpu)
>> + && ((p->se.avg.usage_avg_sum << 3) < (p->se.avg.runnable_avg_sum
>> * 5)))
>> + return false;
>
> I lost you here on better CPU , 37.5 % and last two conditions.
> Isn't the first condition 'buddy==cpu' enough to return since nothing really
> needs to be done in that case. Can you please expand this a bit?
If you have a lot of small tasks waking up and running simultaneously,
Some tasks will wait for runnning and we could short the running time
by parallelizing tasks if possible (at MC level for example)
>
>
>> +
>> + /* buddy is not an allowed CPU */
>> + if (!cpumask_test_cpu(buddy, tsk_cpus_allowed(p)))
>> + return false;
>> +
>> + /*
>> + * If the task is a small one and the buddy is not overloaded,
>> + * we use buddy cpu
>> + */
>> + if (!is_light_task(p) || is_buddy_busy(buddy))
>> + return false;
>
> This is right but both the evaluation needs update to be effective.
>
> Regards
> Santosh
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Afzal Mohammed @ 2012-10-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508E7767.40804@gmail.com>
Hi Daniel,
On Monday 29 October 2012 06:02 PM, Daniel Mack wrote:
> On 29.10.2012 12:28, Afzal Mohammed wrote:
>> I was referring to that of child, now in gpmc_nand_init(),
>> gpmc_cs_request() is being done, later on if we want to
>> make it generic and remove gpmc_nand_init(), additional
>> information that would be required from DT at least is the
>> memory size to be reserved in gpmc address space for
>> the connected peripheral (assuming gpmc_cs_request()
>> would be done by gpmc driver generically later)
>>
>> What I had in mind was example for external bus in [1],
>> but I had not looked deep into this aspect yet.
> Ok, now I see what you mean.
>
> I would say we can use the "reg" property in child node for CS numbers
> purely and if we want to get rid of the memory node allocation, we
> should use a property in the gpmc top-node for this, something like:
>
> gpmc: gpmc at 50000000 {
> compatible = "ti,gpmc";
> cs-regs =<0x51000000 0x10000000 ...>;
I think you meant cs-regs = <0x00000000 ..>
0x0 - 0x1fffffff is gpmc external memory address space, while
0x50000000 to plus 16MB is gpmc configuration address space.
You may refer other gpmc peripheral init's that are NOR type.
> Changing the meaning of the reg property of children from "cs number" to
> "memory sub-region" later is something I would like to avoid.
Changing any of the properties later is something we have
to avoid. Let us get feedback from DT maintainers.
Regards
Afzal
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-10-29 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508E6870.7000807@ti.com>
Hi Afzal,
On 29.10.2012 12:28, Afzal Mohammed wrote:
> On Monday 29 October 2012 04:45 PM, Daniel Mack wrote:
>> On 29.10.2012 09:10, Afzal Mohammed wrote:
>
>>> Also perhaps memory size (and offset if
>>> needed) to be mapped for peripherals can go with reg
>>> property of child.
>
>> Which detail are you referring to here? The only "size" property that is
>> effective is the one of the generic GPMC block, and there it's in the
>> "reg"-property.
>
> I was referring to that of child, now in gpmc_nand_init(),
> gpmc_cs_request() is being done, later on if we want to
> make it generic and remove gpmc_nand_init(), additional
> information that would be required from DT at least is the
> memory size to be reserved in gpmc address space for
> the connected peripheral (assuming gpmc_cs_request()
> would be done by gpmc driver generically later)
>
> What I had in mind was example for external bus in [1],
> but I had not looked deep into this aspect yet.
Ok, now I see what you mean.
I would say we can use the "reg" property in child node for CS numbers
purely and if we want to get rid of the memory node allocation, we
should use a property in the gpmc top-node for this, something like:
gpmc: gpmc at 50000000 {
compatible = "ti,gpmc";
cs-regs = <0x51000000 0x10000000 ...>;
};
Changing the meaning of the reg property of children from "cs number" to
"memory sub-region" later is something I would like to avoid.
Daniel
^ permalink raw reply
* [PATCH v2 1/2] ARM: exynos4: Add devicetree node for TMU driver
From: Kukjin Kim @ 2012-10-29 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351243746-4173-2-git-send-email-amit.daniel@samsung.com>
On 10/26/12 18:29, Amit Daniel Kachhap wrote:
> From: Amit Daniel Kachhap<amit.daniel@samsung.com>
>
> This patch adds necessary source definations needed for TMU driver and
> adds devicetree node for exynos4210.
>
> Signed-off-by: Amit Daniel Kachhap<amit.daniel@samsung.com>
> ---
[...]
> + .name = "tmu_apbif",
> + .enable = exynos4_clk_ip_perir_ctrl,
> + .ctrlbit = (1<< 17),
tab instead of white spaces?
I fixed them when I applied.
[...]
> +#define EXYNOS4_IRQ_TMU_TRIG0 COMBINER_IRQ(2, 4)
> +#define EXYNOS4_IRQ_TMU_TRIG1 COMBINER_IRQ(3, 4)
BTW, where are above definitions used?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] MMCI: fetch pinctrl handle and set default state
From: Russell King - ARM Linux @ 2012-10-29 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350892326-5125-1-git-send-email-linus.walleij@stericsson.com>
On Mon, Oct 22, 2012 at 09:52:06AM +0200, Linus Walleij wrote:
> + /* enable pins to be muxed in and configured */
> + if (!IS_ERR(host->pins_default)) {
> + ret = pinctrl_select_state(host->pinctrl, host->pins_default);
> + if (ret)
> + dev_err(&dev->dev, "could not set default pins\n");
> + } else
> + dev_err(&dev->dev, "could not get default pinstate\n");
Umm, are these errors or warnings? Arguably, because we continue,
these seem to me to be warnings.
In my mind, a warning message is one which is reporting a condition which
we can continue from, whereas an error message is a condition which causes
immediate failure. (Think about GCC... with warnings you still get code,
but the code may not be correct, but if you see an error message you don't
get any code.)
^ permalink raw reply
* [PATCH v2 0/2] ARM: exynos: Enable TMU support in exynos platforms
From: Kukjin Kim @ 2012-10-29 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351243746-4173-1-git-send-email-amit.daniel@samsung.com>
On 10/26/12 18:29, Amit Daniel Kachhap wrote:
> From: Amit Daniel Kachhap<amit.daniel@samsung.com>
>
> These TMU enablement patches are needed for exynos4 and exynos5 TMU
> driver already merged(drivers/thermal/exynos_thermal.c).
>
> This patchset is based on Samsung Maintainer's tree,
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next
>
> Amit Daniel Kachhap (2):
> ARM: exynos4: Add devicetree node for TMU driver
> ARM: exynos5: Add devicetree node for TMU driver
>
> arch/arm/boot/dts/exynos4210.dtsi | 7 +++++++
> arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
> arch/arm/mach-exynos/clock-exynos4.c | 4 ++++
> arch/arm/mach-exynos/clock-exynos5.c | 5 +++++
> arch/arm/mach-exynos/include/mach/irqs.h | 3 +++
> arch/arm/mach-exynos/include/mach/map.h | 3 +++
> arch/arm/mach-exynos/mach-exynos4-dt.c | 2 ++
> arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++
> 8 files changed, 32 insertions(+), 0 deletions(-)
Look good to me, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/6] DMA: AT91: Serial: Add parameter for serial dma use
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-29 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351501773-29024-1-git-send-email-elen.song@atmel.com>
On 17:09 Mon 29 Oct , Elen Song wrote:
> Signed-off-by: Elen Song <elen.song@atmel.com>
> ---
> arch/arm/mach-at91/include/mach/board.h | 2 ++
> drivers/tty/serial/atmel_serial.c | 1 +
> include/linux/platform_data/dma-atmel.h | 10 ++++++++++
> 3 files changed, 13 insertions(+)
you will have to rebase this over a clean if the platofrm_data I'll send today
or tomorrow that will move all the platform_data to inclide/linux
btw your patch broke the avr32
Best Regards.
J.
>
> diff --git a/arch/arm/mach-at91/include/mach/board.h b/arch/arm/mach-at91/include/mach/board.h
> index c55a436..a2188a6 100644
> --- a/arch/arm/mach-at91/include/mach/board.h
> +++ b/arch/arm/mach-at91/include/mach/board.h
> @@ -129,6 +129,8 @@ struct atmel_uart_data {
> short use_dma_tx; /* use transmit DMA? */
> short use_dma_rx; /* use receive DMA? */
> void __iomem *regs; /* virt. base address, if any */
> + struct at_dma_slave *dma_tx_slave;
> + struct at_dma_slave *dma_rx_slave;
> struct serial_rs485 rs485; /* rs485 settings */
> };
> extern void __init at91_add_device_serial(void);
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 3d7e1ee..1b1bd4f 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -45,6 +45,7 @@
>
> #include <asm/mach/serial_at91.h>
> #include <mach/board.h>
> +#include <linux/platform_data/dma-atmel.h>
>
> #ifdef CONFIG_ARM
> #include <mach/cpu.h>
> diff --git a/include/linux/platform_data/dma-atmel.h b/include/linux/platform_data/dma-atmel.h
> index cab0997..bb05302 100644
> --- a/include/linux/platform_data/dma-atmel.h
> +++ b/include/linux/platform_data/dma-atmel.h
> @@ -26,11 +26,21 @@ struct at_dma_platform_data {
> /**
> * struct at_dma_slave - Controller-specific information about a slave
> * @dma_dev: required DMA master device
> + * @tx_reg: physical address of data register used for
> + * memory-to-peripheral transfers
> + * @rx_reg: physical address of data register used for
> + * peripheral-to-memory transfers
> + * @reg_width: peripheral register width
> * @cfg: Platform-specific initializer for the CFG register
> + * @ctrla: Platform-specific initializer for the CTRLA register
> */
> struct at_dma_slave {
> struct device *dma_dev;
> + dma_addr_t tx_reg;
> + dma_addr_t rx_reg;
> + u32 reg_width;
> u32 cfg;
> + u32 ctrla;
> };
>
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Afzal Mohammed @ 2012-10-29 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508E654B.5010404@gmail.com>
Hi Daniel,
On Monday 29 October 2012 04:45 PM, Daniel Mack wrote:
> On 29.10.2012 09:10, Afzal Mohammed wrote:
>> Also perhaps memory size (and offset if
>> needed) to be mapped for peripherals can go with reg
>> property of child.
> Which detail are you referring to here? The only "size" property that is
> effective is the one of the generic GPMC block, and there it's in the
> "reg"-property.
I was referring to that of child, now in gpmc_nand_init(),
gpmc_cs_request() is being done, later on if we want to
make it generic and remove gpmc_nand_init(), additional
information that would be required from DT at least is the
memory size to be reserved in gpmc address space for
the connected peripheral (assuming gpmc_cs_request()
would be done by gpmc driver generically later)
What I had in mind was example for external bus in [1],
but I had not looked deep into this aspect yet.
Regards
Afzal
[1] http://devicetree.org/Device_Tree_Usage#Memory_Mapped_Devices
^ permalink raw reply
* [PATCH 3/4] pinctrl: samsung: Add support for Exynos4x12
From: Kukjin Kim @ 2012-10-29 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2350814.8tYbDqrzVz@amdc1227>
On 10/29/12 19:28, Tomasz Figa wrote:
> Hi Linus, Kyungmin,
>
> On Monday 29 of October 2012 09:30:26 Kyungmin Park wrote:
>> On 10/29/12, Linus Walleij<linus.walleij@linaro.org> wrote:
>>> On Wed, Oct 24, 2012 at 4:37 PM, Tomasz Figa<t.figa@samsung.com>
> wrote:
>>>> This patch extends the driver with any necessary SoC-specific
>>>> definitions to support Exynos4x12 SoCs.
>>>>
>>>> Signed-off-by: Tomasz Figa<t.figa@samsung.com>
>>>> Signed-off-by: Kyungmin Park<kyungmin.park@samsung.com>
>>>
>>> Acked-by: Linus Walleij<linus.walleij@linaro.org>
>>>
>>> I guess you need all of this to go into my Samsung branch?
>>> I need and ACK from the Samsung maintainer and preferably
>>> Thomas A as well.
>>
>> Hi,
>>
>> Now we're trying to send the standalone patches to avoid the conflict.
>> and hope to merge patches via proper subsystem. In this case, pinctl.
>
> Since this depends on the patch adding Exynos4x12 dts files
> ([PATCH] ARM: dts: exynos4: Add support for Exynos4x12 SoCs),
> which will be going through Kgene's tree and this patch series contains
> mostly SoC-specific code, maybe this should rather go through Kgene's
> tree? Or this is not a problem?
>
Yeah, I agree with Tomasz's opinion and let me pick this into Samsung
tree with Linus's ack.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: Exynos5: Remove unused static uart resource information
From: Kukjin Kim @ 2012-10-29 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351516455-344-1-git-send-email-thomas.abraham@linaro.org>
On 10/29/12 22:14, Thomas Abraham wrote:
> All supported Exynos5 platforms are device tree enabled and hence the
> unused static uart resource information is removed.
>
> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
> ---
> arch/arm/mach-exynos/common.c | 6 +-----
> arch/arm/mach-exynos/dev-uart.c | 24 ------------------------
> arch/arm/mach-exynos/include/mach/irqs.h | 5 -----
> arch/arm/mach-exynos/include/mach/map.h | 1 -
> 4 files changed, 1 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 1947be8..5a305f0 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -96,7 +96,6 @@ static struct cpu_table cpu_ids[] __initdata = {
> .idmask = EXYNOS5_SOC_MASK,
> .map_io = exynos5_map_io,
> .init_clocks = exynos5_init_clocks,
> - .init_uarts = exynos_init_uarts,
> .init = exynos_init,
> .name = name_exynos5250,
> },
> @@ -735,10 +734,7 @@ static void __init exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no)
> for (ucnt = 0; ucnt< no; ucnt++, tcfg++)
> tcfg->has_fracval = 1;
>
> - if (soc_is_exynos5250())
> - s3c24xx_init_uartdevs("exynos4210-uart", exynos5_uart_resources, cfg, no);
> - else
> - s3c24xx_init_uartdevs("exynos4210-uart", exynos4_uart_resources, cfg, no);
> + s3c24xx_init_uartdevs("exynos4210-uart", exynos4_uart_resources, cfg, no);
> }
>
> static void __iomem *exynos_eint_base;
> diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c
> index 2e85c02..7c42f4b 100644
> --- a/arch/arm/mach-exynos/dev-uart.c
> +++ b/arch/arm/mach-exynos/dev-uart.c
> @@ -52,27 +52,3 @@ struct s3c24xx_uart_resources exynos4_uart_resources[] __initdata = {
> .nr_resources = ARRAY_SIZE(exynos4_uart3_resource),
> },
> };
> -
> -EXYNOS_UART_RESOURCE(5, 0)
> -EXYNOS_UART_RESOURCE(5, 1)
> -EXYNOS_UART_RESOURCE(5, 2)
> -EXYNOS_UART_RESOURCE(5, 3)
> -
> -struct s3c24xx_uart_resources exynos5_uart_resources[] __initdata = {
> - [0] = {
> - .resources = exynos5_uart0_resource,
> - .nr_resources = ARRAY_SIZE(exynos5_uart0_resource),
> - },
> - [1] = {
> - .resources = exynos5_uart1_resource,
> - .nr_resources = ARRAY_SIZE(exynos5_uart0_resource),
> - },
> - [2] = {
> - .resources = exynos5_uart2_resource,
> - .nr_resources = ARRAY_SIZE(exynos5_uart2_resource),
> - },
> - [3] = {
> - .resources = exynos5_uart3_resource,
> - .nr_resources = ARRAY_SIZE(exynos5_uart3_resource),
> - },
> -};
> diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
> index 35bced6..6da3115 100644
> --- a/arch/arm/mach-exynos/include/mach/irqs.h
> +++ b/arch/arm/mach-exynos/include/mach/irqs.h
> @@ -259,11 +259,6 @@
> #define EXYNOS5_IRQ_IEM_IEC IRQ_SPI(48)
> #define EXYNOS5_IRQ_IEM_APC IRQ_SPI(49)
> #define EXYNOS5_IRQ_GPIO_C2C IRQ_SPI(50)
> -#define EXYNOS5_IRQ_UART0 IRQ_SPI(51)
> -#define EXYNOS5_IRQ_UART1 IRQ_SPI(52)
> -#define EXYNOS5_IRQ_UART2 IRQ_SPI(53)
> -#define EXYNOS5_IRQ_UART3 IRQ_SPI(54)
> -#define EXYNOS5_IRQ_UART4 IRQ_SPI(55)
> #define EXYNOS5_IRQ_IIC IRQ_SPI(56)
> #define EXYNOS5_IRQ_IIC1 IRQ_SPI(57)
> #define EXYNOS5_IRQ_IIC2 IRQ_SPI(58)
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
> index 8480849..e737331 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -279,7 +279,6 @@
> #define EXYNOS5_PA_UART1 0x12C10000
> #define EXYNOS5_PA_UART2 0x12C20000
> #define EXYNOS5_PA_UART3 0x12C30000
> -#define EXYNOS5_SZ_UART SZ_256
>
> #define S3C_VA_UARTx(x) (S3C_VA_UART + ((x) * S3C_UART_OFFSET))
>
Yes, right. And I think, the function name, exynos_init_uarts() can be
changed to exynos4_init_uarts() clearly with this...so I did when I
applied this.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: Exynos5: Remove static io-remapping for gic and combiner
From: Kukjin Kim @ 2012-10-29 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351516573-393-1-git-send-email-thomas.abraham@linaro.org>
On 10/29/12 22:16, Thomas Abraham wrote:
> The physical base address of GIC and Interrupt Combiner is obtained from
> device tree and then remapped during initialization. So remove the
> static io-remapping for GIC and combiner.
>
> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
> ---
> arch/arm/mach-exynos/common.c | 15 ---------------
> 1 files changed, 0 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 5a305f0..5c75815 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -256,25 +256,10 @@ static struct map_desc exynos5_iodesc[] __initdata = {
> .length = SZ_64K,
> .type = MT_DEVICE,
> }, {
> - .virtual = (unsigned long)S5P_VA_COMBINER_BASE,
> - .pfn = __phys_to_pfn(EXYNOS5_PA_COMBINER),
> - .length = SZ_4K,
> - .type = MT_DEVICE,
> - }, {
> .virtual = (unsigned long)S3C_VA_UART,
> .pfn = __phys_to_pfn(EXYNOS5_PA_UART),
> .length = SZ_512K,
> .type = MT_DEVICE,
> - }, {
> - .virtual = (unsigned long)S5P_VA_GIC_CPU,
> - .pfn = __phys_to_pfn(EXYNOS5_PA_GIC_CPU),
> - .length = SZ_8K,
> - .type = MT_DEVICE,
> - }, {
> - .virtual = (unsigned long)S5P_VA_GIC_DIST,
> - .pfn = __phys_to_pfn(EXYNOS5_PA_GIC_DIST),
> - .length = SZ_4K,
> - .type = MT_DEVICE,
> },
> };
>
Applied, thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-10-29 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508E3A0F.3040309@ti.com>
Hi Afzal,
On 29.10.2012 09:10, Afzal Mohammed wrote:
> On Thursday 25 October 2012 05:01 AM, Daniel Mack wrote:
>
>> Thanks for the review. I'll wait for feedback from Afzal next week and
>> then repost. Wanted to see first if that goes in the right direction at
>> all before bordering the DT people with binding details :)
>
> I was thinking of a generic approach, where there won't be
> any check for peripheral device type.
>
> But going that path would delay achieving DT, may be let's
> proceed with your approach to start with so that we can
> have a minimal level of DT support for GPMC and probably
> we can make it generic later. While adding new properties,
> it would be better to keep in mind that we need not change
> these later once gpmc DT is made generic.
>
> Regarding the bindings, there are some generic nand
> properties like ecc already available, may be that be made
> use here.
Ah, of_get_nand_ecc_mode() - nice.
> Also perhaps memory size (and offset if
> needed) to be mapped for peripherals can go with reg
> property of child.
Which detail are you referring to here? The only "size" property that is
effective is the one of the generic GPMC block, and there it's in the
"reg"-property.
I'll take the other feedback that I got and quickly do a v2.
Thanks,
Daniel
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Daniel Mack @ 2012-10-29 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVcJ=WLJwS49zgb_=6or7Me3LLGQtBbfzBtS-p+U6Tw-pQ@mail.gmail.com>
On 29.10.2012 12:12, Vasily Khoruzhick wrote:
> On Mon, Oct 29, 2012 at 2:00 PM, Daniel Mack <zonque@gmail.com> wrote:
>
>>> Well, there's an issue - Z2 does not preserve memory contents in deep sleep
>>> (but it does in sleep), so userspace can't be fixed here unfortunatelly.
>>> There's no another possibility to turn Z2 off, and plain sleep is too
>>> power hungry.
>>> So the only way to keep Z2 in low-power mode is fake power off, which just puts
>>> Z2 in deep sleep.
>>
>> Why can't the userspace trigger a deep sleep then instead of powering
>> off? Which details do I lack?
>
> How? echo mem >/sys/power/state puts system into non-deep sleep. Anyway, kernel
> is not ready for fake power off instead of suspend (we can't resume
> from deep sleep,
> memory content is not preserved), so there can be some data loss.
> Adding some sysfs file to control sleep type does not look like a good
> idea to me.
>
> Btw, how other DT-capable boards handle power off?
No idea. I never actually used that kind of power state.
^ permalink raw reply
* imx-sdma.c broken on imx53 for sound
From: Fabio Estevam @ 2012-10-29 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5B1k4r=6ZqQkZghuEqmEY=tOwRUmZAnckqxBM0_kVf6rQ@mail.gmail.com>
Rick,
On Sat, Oct 27, 2012 at 4:33 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> Anyone have any ideas?
>
> Are you providing the mx53 sdma firmware?
Just tried to play audio on my mx53qsb and it works fine if the sdma
firmware is provided.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Vasily Khoruzhick @ 2012-10-29 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508E61E7.7090502@gmail.com>
On Mon, Oct 29, 2012 at 2:00 PM, Daniel Mack <zonque@gmail.com> wrote:
>> Well, there's an issue - Z2 does not preserve memory contents in deep sleep
>> (but it does in sleep), so userspace can't be fixed here unfortunatelly.
>> There's no another possibility to turn Z2 off, and plain sleep is too
>> power hungry.
>> So the only way to keep Z2 in low-power mode is fake power off, which just puts
>> Z2 in deep sleep.
>
> Why can't the userspace trigger a deep sleep then instead of powering
> off? Which details do I lack?
How? echo mem >/sys/power/state puts system into non-deep sleep. Anyway, kernel
is not ready for fake power off instead of suspend (we can't resume
from deep sleep,
memory content is not preserved), so there can be some data loss.
Adding some sysfs file to control sleep type does not look like a good
idea to me.
Btw, how other DT-capable boards handle power off?
Regards
Vasily
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Daniel Mack @ 2012-10-29 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVcRM834_JFZskL7DEJQ10YsYexCeY3CE67fjJk4_WJLUw@mail.gmail.com>
On 29.10.2012 11:52, Vasily Khoruzhick wrote:
> On Mon, Oct 29, 2012 at 1:44 PM, Daniel Mack <zonque@gmail.com> wrote:
>
>> I haven't seen any patches for DT bindings of this yet.
>>
>>> I still don't understand how DT handles platform-specific
>>> callbacks like set_power(). And what about pm_power_off hook?
>>
>> They require consideration.
>>
>> In general, a driver should be aware of everything that affects the
>> peripheral, including all the voltages and clocks it needs and also all
>> extra pins like for example reset GPIOs etc. And all that properties are
>> to be exported via DT as well (things that you would have normally set
>> up using pdata).
>>
>> If drivers lack that kind of full awareness of their environment, they
>> need to be augmented, because - to stick with the example of reset GPIOs
>> - the driver of all parts is the only piece that knows when to driver
>> that pin and how.
>>
>> About the hack to put the z2 to deep-sleep when it should actually power
>> down, I don't know what to do. But I would say that it's the userspace
>> that should be fixed here, if possible.
>
> Well, there's an issue - Z2 does not preserve memory contents in deep sleep
> (but it does in sleep), so userspace can't be fixed here unfortunatelly.
> There's no another possibility to turn Z2 off, and plain sleep is too
> power hungry.
> So the only way to keep Z2 in low-power mode is fake power off, which just puts
> Z2 in deep sleep.
Why can't the userspace trigger a deep sleep then instead of powering
off? Which details do I lack?
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Vasily Khoruzhick @ 2012-10-29 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508E5DFB.3060002@gmail.com>
On Mon, Oct 29, 2012 at 1:44 PM, Daniel Mack <zonque@gmail.com> wrote:
> I haven't seen any patches for DT bindings of this yet.
>
>> I still don't understand how DT handles platform-specific
>> callbacks like set_power(). And what about pm_power_off hook?
>
> They require consideration.
>
> In general, a driver should be aware of everything that affects the
> peripheral, including all the voltages and clocks it needs and also all
> extra pins like for example reset GPIOs etc. And all that properties are
> to be exported via DT as well (things that you would have normally set
> up using pdata).
>
> If drivers lack that kind of full awareness of their environment, they
> need to be augmented, because - to stick with the example of reset GPIOs
> - the driver of all parts is the only piece that knows when to driver
> that pin and how.
>
> About the hack to put the z2 to deep-sleep when it should actually power
> down, I don't know what to do. But I would say that it's the userspace
> that should be fixed here, if possible.
Well, there's an issue - Z2 does not preserve memory contents in deep sleep
(but it does in sleep), so userspace can't be fixed here unfortunatelly.
There's no another possibility to turn Z2 off, and plain sleep is too
power hungry.
So the only way to keep Z2 in low-power mode is fake power off, which just puts
Z2 in deep sleep.
> Daniel
Regards
Vasily
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Daniel Mack @ 2012-10-29 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVcnacT8L5GkqTxdowKt2KkoEWMhd3+XBk6nKsEEDtWecg@mail.gmail.com>
On 29.10.2012 11:07, Vasily Khoruzhick wrote:
> On Mon, Oct 29, 2012 at 12:42 PM, Daniel Mack <zonque@gmail.com> wrote:
>> Please have a quick look at arch/arm/mach-pxa/pxa-dt.c - what it takes
>> for basic 270 support is just copying the logic that is there already
>> for the 3xx models.
>
> Sure, but I need to get DT-capable bootloader working on Z2 in first
> place, right?
No, you don't necessarily. You can also append a dtb blob to the kernel
image (CONFIG_ARM_APPENDED_DTB).
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Daniel Mack @ 2012-10-29 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVcnacT8L5GkqTxdowKt2KkoEWMhd3+XBk6nKsEEDtWecg@mail.gmail.com>
On 29.10.2012 11:07, Vasily Khoruzhick wrote:
> On Mon, Oct 29, 2012 at 12:42 PM, Daniel Mack <zonque@gmail.com> wrote:
>> On 29.10.2012 10:33, Vasily Khoruzhick wrote:
>>> On Mon, Oct 29, 2012 at 1:58 AM, Daniel Mack <zonque@gmail.com> wrote:
>>>>> Any volunteers? :) It requires huge amount of work,
>>>>
>>>> Well, it's actually quite straight forward. With the changes that got merged
>>>> to 3.7, pxa3xx platforms boot, and I also ported some pxa specific
>>>> peripheral drivers that should work for both 2xx and 3xx. Adding CPU support
>>>> for 27x should also just be a matter of some extra lines.
>>>>
>>>> So I would clearly say you should give the DT approach a try first and see
>>>> which bits are missing. And I would vote for not taking any new features for
>>>> the legacy board support files but just bugfixes.
>>>
>>> Fair enough, I'll resend series without USB stuff (so it'll contain
>>> only bugfixes)
>>
>> I rather wanted to encourage you to work on the PXA2xx DT stuff :)
>
> I'm not refusing to work on PXA2xx DT stuff, just want to get bugfixes in place,
> some of them are serious enough (like fixing oops on poweroff)
>
>> Please have a quick look at arch/arm/mach-pxa/pxa-dt.c - what it takes
>> for basic 270 support is just copying the logic that is there already
>> for the 3xx models.
>
> Sure, but I need to get DT-capable bootloader working on Z2 in first
> place, right?
>
>> Some parts like the uart, host-mode usb, mmc, gpio-leds, gpio-keys, i2c
>> etc are already finished and should work instantly. What's missing is
>> the spi controller and the display, but maybe you can help getting these
>> done?
>
> What about libertas?
I haven't seen any patches for DT bindings of this yet.
> I still don't understand how DT handles platform-specific
> callbacks like set_power(). And what about pm_power_off hook?
They require consideration.
In general, a driver should be aware of everything that affects the
peripheral, including all the voltages and clocks it needs and also all
extra pins like for example reset GPIOs etc. And all that properties are
to be exported via DT as well (things that you would have normally set
up using pdata).
If drivers lack that kind of full awareness of their environment, they
need to be augmented, because - to stick with the example of reset GPIOs
- the driver of all parts is the only piece that knows when to driver
that pin and how.
About the hack to put the z2 to deep-sleep when it should actually power
down, I don't know what to do. But I would say that it's the userspace
that should be fixed here, if possible.
Daniel
^ permalink raw reply
* [PATCH 00/13] ARM: OMAP: remove prcm.[ch]
From: Vaibhav Hiremath @ 2012-10-29 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025231818.17558.57884.stgit@dusk.lan>
On 10/26/2012 4:51 AM, Paul Walmsley wrote:
> Remove arch/arm/mach-omap2/prcm.c and
> arch/arm/plat-omap/include/plat/prcm.h. This is in preparation for
> moving the PRM/CM code to drivers/, although to be fair, these files
> should have been removed a long time ago.
>
> Intended for 3.8 cleanup. Applies on top of the existing PRM/CM split
> cleanup series, and the WDTIMER cleanup series.
>
Paul,
By any chance you have branch available with these patches, so that I
can validate them here at my end?
Thanks,
Vaibhav
>
> - Paul
>
> ---
>
> omap2_prcm_cleanup_3.8
> text data bss dec hex filename
> 7521423 696876 5613996 13832295 d31067 vmlinux.omap2plus_defconfig.orig
> 7522239 696612 5613996 13832847 d3128f vmlinux.omap2plus_defconfig
>
> Paul Walmsley (13):
> ARM: OMAP2+: common: remove mach-omap2/common.c and map_common_io code
> ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)
> ARM: OMAP2xxx: clock: remove global 'dclk' variable
> ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c
> ARM: OMAP2+: PRCM: create SoC-specific chip restart functions
> ARM: OMAP2+: board files: use SoC-specific system restart functions
> ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready()
> ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions
> ARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest()
> ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup
> ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros
> ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call
> ARM: OMAP2+: PRCM: remove obsolete prcm.[ch]
>
>
> arch/arm/mach-omap1/reset.c | 2
> arch/arm/mach-omap2/Makefile | 9 +
> arch/arm/mach-omap2/am33xx.h | 1
> arch/arm/mach-omap2/board-2430sdp.c | 2
> arch/arm/mach-omap2/board-3430sdp.c | 2
> arch/arm/mach-omap2/board-3630sdp.c | 2
> arch/arm/mach-omap2/board-4430sdp.c | 2
> arch/arm/mach-omap2/board-am3517crane.c | 2
> arch/arm/mach-omap2/board-am3517evm.c | 2
> arch/arm/mach-omap2/board-apollon.c | 2
> arch/arm/mach-omap2/board-cm-t35.c | 18 +-
> arch/arm/mach-omap2/board-cm-t3517.c | 2
> arch/arm/mach-omap2/board-devkit8000.c | 2
> arch/arm/mach-omap2/board-generic.c | 10 +
> arch/arm/mach-omap2/board-h4.c | 2
> arch/arm/mach-omap2/board-igep0020.c | 4 -
> arch/arm/mach-omap2/board-ldp.c | 2
> arch/arm/mach-omap2/board-n8x0.c | 6 -
> arch/arm/mach-omap2/board-omap3beagle.c | 2
> arch/arm/mach-omap2/board-omap3evm.c | 2
> arch/arm/mach-omap2/board-omap3logic.c | 4 -
> arch/arm/mach-omap2/board-omap3pandora.c | 2
> arch/arm/mach-omap2/board-omap3stalker.c | 2
> arch/arm/mach-omap2/board-omap3touchbook.c | 2
> arch/arm/mach-omap2/board-omap4panda.c | 2
> arch/arm/mach-omap2/board-overo.c | 2
> arch/arm/mach-omap2/board-rm680.c | 4 -
> arch/arm/mach-omap2/board-rx51.c | 2
> arch/arm/mach-omap2/board-ti8168evm.c | 4 -
> arch/arm/mach-omap2/board-zoom.c | 4 -
> arch/arm/mach-omap2/clkt2xxx_apll.c | 57 ++-----
> arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 36 ++++-
> arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 70 ++++++++-
> arch/arm/mach-omap2/clkt_iclk.c | 1
> arch/arm/mach-omap2/clock.c | 15 +-
> arch/arm/mach-omap2/clock.h | 28 ----
> arch/arm/mach-omap2/clock2420_data.c | 26 +--
> arch/arm/mach-omap2/clock2430_data.c | 26 +--
> arch/arm/mach-omap2/clock2xxx.c | 16 --
> arch/arm/mach-omap2/clock2xxx.h | 9 +
> arch/arm/mach-omap2/cm-regbits-24xx.h | 2
> arch/arm/mach-omap2/cm.h | 20 ++-
> arch/arm/mach-omap2/cm2xxx.c | 128 ++++++++++++++++
> arch/arm/mach-omap2/cm2xxx.h | 4 +
> arch/arm/mach-omap2/cm2xxx_3xxx.h | 8 +
> arch/arm/mach-omap2/cm3xxx.c | 66 ++++++++
> arch/arm/mach-omap2/cm3xxx.h | 5 +
> arch/arm/mach-omap2/cm_common.c | 70 +++++++++
> arch/arm/mach-omap2/cminst44xx.h | 2
> arch/arm/mach-omap2/common.c | 202 --------------------------
> arch/arm/mach-omap2/common.h | 111 ++------------
> arch/arm/mach-omap2/control.c | 10 +
> arch/arm/mach-omap2/control.h | 2
> arch/arm/mach-omap2/cpuidle34xx.c | 1
> arch/arm/mach-omap2/display.c | 2
> arch/arm/mach-omap2/hdq1w.c | 4 -
> arch/arm/mach-omap2/i2c.c | 6 -
> arch/arm/mach-omap2/id.c | 7 +
> arch/arm/mach-omap2/io.c | 87 +++++++++--
> arch/arm/mach-omap2/mcbsp.c | 2
> arch/arm/mach-omap2/msdi.c | 4 -
> arch/arm/mach-omap2/omap2-restart.c | 65 ++++++++
> arch/arm/mach-omap2/omap3-restart.c | 36 +++++
> arch/arm/mach-omap2/omap4-common.c | 18 ++
> arch/arm/mach-omap2/omap_hwmod.c | 8 -
> arch/arm/mach-omap2/pm34xx.c | 1
> arch/arm/mach-omap2/powerdomain.c | 2
> arch/arm/mach-omap2/prcm-common.h | 22 ---
> arch/arm/mach-omap2/prcm.c | 176 -----------------------
> arch/arm/mach-omap2/prcm_mpu44xx.c | 17 ++
> arch/arm/mach-omap2/prcm_mpu44xx.h | 9 +
> arch/arm/mach-omap2/prm.h | 24 +++
> arch/arm/mach-omap2/prm2xxx.c | 15 ++
> arch/arm/mach-omap2/prm2xxx.h | 2
> arch/arm/mach-omap2/prm2xxx_3xxx.h | 7 -
> arch/arm/mach-omap2/prm3xxx.c | 16 ++
> arch/arm/mach-omap2/prm3xxx.h | 2
> arch/arm/mach-omap2/prm44xx.c | 1
> arch/arm/mach-omap2/prm_common.c | 16 ++
> arch/arm/mach-omap2/prminst44xx.h | 2
> arch/arm/mach-omap2/sdrc.c | 8 -
> arch/arm/mach-omap2/sdrc.h | 3
> arch/arm/mach-omap2/ti81xx.h | 9 +
> arch/arm/mach-omap2/wd_timer.c | 5 -
> arch/arm/plat-omap/include/plat/prcm.h | 36 -----
> 85 files changed, 827 insertions(+), 804 deletions(-)
> delete mode 100644 arch/arm/mach-omap2/common.c
> create mode 100644 arch/arm/mach-omap2/omap2-restart.c
> create mode 100644 arch/arm/mach-omap2/omap3-restart.c
> delete mode 100644 arch/arm/mach-omap2/prcm.c
> delete mode 100644 arch/arm/plat-omap/include/plat/prcm.h
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 3/4] pinctrl: samsung: Add support for Exynos4x12
From: Tomasz Figa @ 2012-10-29 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2V2UjuvjK2_sjLQsEt21duCqyoQuAi0KsMfB+CjRrh8KQ@mail.gmail.com>
Hi Linus, Kyungmin,
On Monday 29 of October 2012 09:30:26 Kyungmin Park wrote:
> On 10/29/12, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Wed, Oct 24, 2012 at 4:37 PM, Tomasz Figa <t.figa@samsung.com>
wrote:
> >> This patch extends the driver with any necessary SoC-specific
> >> definitions to support Exynos4x12 SoCs.
> >>
> >> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> >> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> >
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > I guess you need all of this to go into my Samsung branch?
> > I need and ACK from the Samsung maintainer and preferably
> > Thomas A as well.
>
> Hi,
>
> Now we're trying to send the standalone patches to avoid the conflict.
> and hope to merge patches via proper subsystem. In this case, pinctl.
Since this depends on the patch adding Exynos4x12 dts files
([PATCH] ARM: dts: exynos4: Add support for Exynos4x12 SoCs),
which will be going through Kgene's tree and this patch series contains
mostly SoC-specific code, maybe this should rather go through Kgene's
tree? Or this is not a problem?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox