* [RFC PATCH 0/2] sched: Load Balancing using Per-entity-Load-tracking
From: preeti @ 2012-10-19 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018172609.GA14473@e103034-lin>
Hi Morten,
Thank you very much for your review.
>> 1.Consider a scenario,where there are two 10% tasks running on a cpu.The
>> present code will consider the load on this queue to be 2048,while
>> using PJT's metric the load is calculated to be <1000,rarely exceeding this
>> limit.Although the tasks are not contributing much to the cpu load,they are
>> decided to be moved by the scheduler.
>
> I guess that you assume, for now, that all tasks have default (nice 0)
> priority? Both the old load and the PJT metric (tracked load) depends on
> priority.
Thats right.I have assumed default priority of the tasks.
>
>>
>> But one could argue that 'not moving one of these tasks could throttle
>> them.If there was an idle cpu,perhaps we could have moved them'.While the
>> power save mode would have been fine with not moving the task,the
>> performance mode would prefer not to throttle the tasks.We could strive
>> to strike a balance by making this decision tunable with certain parameters.
>> This patchset includes such tunables.This issue is addressed in Patch[1/2].
>>
>
> One could also argue that long as there are spare cpu cycles in each
> schedule period then all tasks have received the cpu time they needed.
> So from that point of view performance isn't affected by not balancing
> the tasks as long as the cpu is not fully utilized. If we look at the
> problem from a latency point of view then packing tasks on a single cpu
> will increase latency but the increase will be bounded by the schedule
> period.
>
Assume that at the end of one scheduling period,there are a few spare
cycles on the cpu.this is fine from both the performance and latency
point of view at *this* point.nobody is waiting for the cpu.
The issue arises if it is detected that these spare cycles are due to
*sleeping tasks* and not due to no tasks.
At this point a decision needs to be made as to: if a scenario arises
where all these tasks wake up at the same time in the future,and wait on
the cpu,then are we ok with them waiting.Both performance and latency
views could be against this,as this also means less throughput.But
performance view could go slightly easy on this to argue,that its ok if
2-3 tasks wait,if more,then there is a need to move them.
>> This patchset therefore has two primary aims.
>> Patch[1/2]: This patch aims at detecting short running tasks and
>> prevent their movement.In update_sg_lb_stats,dismiss a sched group
>> as a candidate for load balancing,if load calculated by PJT's metric
>> says that the average load on the sched_group <= 1024+(.15*1024).
>> This is a tunable,which can be varied after sufficient experiments.
>
> Your current threshold implies that there must be at least two (nice 0)
> tasks running breach the threshold and they need to be quite busy. This
> makes sense to me. When you have more tasks they are more likely to be
> waiting on the runqueue even if it is only 10% tasks. Let's say you have
> five 10% tasks and they all become runnable at the same instant. In that
> case some of the tasks would have a tracked load which is much higher
> than if we only had two 10% tasks running. So if I'm not mistaken, it
> would be possible to breach the threshold even though the overall cpu
> utilization is only 50% and it would have been safe not to load-balance
> that cpu.
>
> Do you think it would make sense to let the threshold depend on the
> number of task on the cpu somehow?
You are right,Morten.In fact I have included this viewpoint in both my
first and second patch enclosed by this. So lets take up the above
scenario.if there are 5 10% tasks running,they will surely cross the
threshold,but the cpu might have spare cycles at the end of a scheduling
period.Now that is your concern.
Again we have two different viewpoints.This threshold is like a tuning
knob.we could increase it if we feel that this threshold gets reached
very quickly with as few tasks as 5, although the cpu utilization is
poor.we prefer not to wake up another cpu unless the present cpu is
aptly loaded.we could call this the power saving view.
Else we could say that,we are not intending to affect the throughput of
tasks,so we prefer the knob be at this value,so that we qualify such a
load as a candidate for load balancing.we could call this the
performance view.
>
> Alternative, the decision could be based on the cpu idle time over the
> last schedule period. A cpu with no or very few spare cycles in the last
> schedule period would be a good candidate for load-balancing. Latency
> would be affected as mentioned earlier.
>
Exactly.idle_time == spare_cpu_cycles == less cpu_utilization.I hope i
am not wrong in drawing this equivalence.if thats the case then the same
explanation as above holds good here too.
>
> Morten
Thank you
Regards
Preeti
^ permalink raw reply
* [RFC PATCH 0/2] sched: Load Balancing using Per-entity-Load-tracking
From: preeti @ 2012-10-19 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5080D451.5090409@linux.vnet.ibm.com>
Sorry guys this mail had problems getting sent.hence the repost.
Hi Morten,
Thank you very much for your review.
>> 1.Consider a scenario,where there are two 10% tasks running on a cpu.The
>> present code will consider the load on this queue to be 2048,while
>> using PJT's metric the load is calculated to be <1000,rarely exceeding this
>> limit.Although the tasks are not contributing much to the cpu load,they are
>> decided to be moved by the scheduler.
>
> I guess that you assume, for now, that all tasks have default (nice 0)
> priority? Both the old load and the PJT metric (tracked load) depends on
> priority.
Thats right.I have assumed default priority of the tasks.
>>
>> But one could argue that 'not moving one of these tasks could throttle
>> them.If there was an idle cpu,perhaps we could have moved them'.While the
>> power save mode would have been fine with not moving the task,the
>> performance mode would prefer not to throttle the tasks.We could strive
>> to strike a balance by making this decision tunable with certain parameters.
>> This patchset includes such tunables.This issue is addressed in Patch[1/2].
>>
>
> One could also argue that long as there are spare cpu cycles in each
> schedule period then all tasks have received the cpu time they needed.
> So from that point of view performance isn't affected by not balancing
> the tasks as long as the cpu is not fully utilized. If we look at the
> problem from a latency point of view then packing tasks on a single cpu
> will increase latency but the increase will be bounded by the schedule
> period.
>
Assume that at the end of one scheduling period,there are a few spare
cycles on the cpu.this is fine from both the performance and latency
point of view at *this* point.nobody is waiting for the cpu.
The issue arises if it is detected that these spare cycles are due to
*sleeping tasks* and not due to no tasks.
At this point a decision needs to be made as to: if a scenario arises
where all these tasks wake up at the same time in the future,and wait on
the cpu,then are we ok with them waiting.Both performance and latency
views could be against this,as this also means less throughput.But
performance view could go slightly easy on this to argue,that its ok if
2-3 tasks wait,if more,then there is a need to move them.
>> This patchset therefore has two primary aims.
>> Patch[1/2]: This patch aims at detecting short running tasks and
>> prevent their movement.In update_sg_lb_stats,dismiss a sched group
>> as a candidate for load balancing,if load calculated by PJT's metric
>> says that the average load on the sched_group <= 1024+(.15*1024).
>> This is a tunable,which can be varied after sufficient experiments.
>
> Your current threshold implies that there must be at least two (nice 0)
> tasks running breach the threshold and they need to be quite busy. This
> makes sense to me. When you have more tasks they are more likely to be
> waiting on the runqueue even if it is only 10% tasks. Let's say you have
> five 10% tasks and they all become runnable at the same instant. In that
> case some of the tasks would have a tracked load which is much higher
> than if we only had two 10% tasks running. So if I'm not mistaken, it
> would be possible to breach the threshold even though the overall cpu
> utilization is only 50% and it would have been safe not to load-balance
> that cpu.
>
> Do you think it would make sense to let the threshold depend on the
> number of task on the cpu somehow?
>
You are right,Morten.In fact I have included this viewpoint in both my
first and second patch enclosed by this. So lets take up the above
scenario.if there are 5 10% tasks running,they will surely cross the
threshold,but the cpu might have spare cycles at the end of a scheduling
period.Now that is your concern.
Again we have two different viewpoints.This threshold is like a tuning
knob.we could increase it if we feel that this threshold gets reached
very quickly with as few tasks as 5, although the cpu utilization is
poor.we prefer not to wake up another cpu unless the present cpu is
aptly loaded.we could call this the power saving view.
Else we could say that,we are not intending to affect the throughput of
tasks,so we prefer the knob be at this value,so that we qualify such a
load as a candidate for load balancing.we could call this the
performance view.
> Alternative, the decision could be based on the cpu idle time over the
> last schedule period. A cpu with no or very few spare cycles in the last
> schedule period would be a good candidate for load-balancing. Latency
> would be affected as mentioned earlier.
>
Exactly.idle_time == spare_cpu_cycles == less cpu_utilization.I hope i
am not wrong in drawing this equivalence.if thats the case then the same
explanation as above holds good here too.
> Morten
Thank you
Regards
Preeti
^ permalink raw reply
* Do we need to fix below dump during cpu hot plug operation?
From: Shawn Guo @ 2012-10-19 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019015621.GA17360@nchen-desktop>
On Fri, Oct 19, 2012 at 09:56:22AM +0800, Peter Chen wrote:
> Hi all,
>
> When doing system suspend/resume or CPU hot plug at SMP platform (like
> Freescale i.mx6Q sabrelite board), if local time is enabled,
> there is a clk_get_rate at twd_timer_setup during the atomic context.
> So, if mutex_lock debug is enabled, there will be below dump message.
> Although it will not affect future system use, it is boring message.
>
Thanks for reporting, Peter.
We should fix the warning. Having not turned on those warning options
in imx defconfig might be the reason that we had not noticed it.
Since the driver is able to update the twd_timer_rate whenever clock
rate changes after system boots up, the clk_get_rate call in
twd_timer_setup should be only needed when we get a valid twd_clk at
the first time. So let's move clk_get_rate call into if (!twd_clk)
block just after twd_get_clock().
Linus, Russell,
Does it seem to be a valid fix?
Shawn
8<---
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index e1f9069..c1f54a1 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -273,13 +273,13 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
{
struct clock_event_device **this_cpu_clk;
- if (!twd_clk)
+ if (!twd_clk) {
twd_clk = twd_get_clock();
-
- if (!IS_ERR_OR_NULL(twd_clk))
- twd_timer_rate = clk_get_rate(twd_clk);
- else
+ if (!IS_ERR_OR_NULL(twd_clk))
+ twd_timer_rate = clk_get_rate(twd_clk);
+ } else {
twd_calibrate_rate();
+ }
__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
> BUG: sleeping function called from invalid context at /home/b29397/work/code/git/linus/linux-2.6/kernel/mutex.c:269
> no locks held by swapper/1/0.
> irq event stamp: 279320
> hardirqs last enabled at (279319): [<80052bd0>] idle_task_exit+0x16c/0x1a0
> hardirqs last disabled at (279320): [<8051a470>] cpu_die+0x28/0x98
> softirqs last enabled at (279304): [<8002ae3c>] _local_bh_enable+0x14/0x18
> softirqs last disabled at (279303): [<8002aea8>] irq_enter+0x68/0x78
> Backtrace:
> [<8001284c>] (dump_backtrace+0x0/0x10c) from [<8052b614>] (dump_stack+0x18/0x1c)
> r7:8062b070 r6:0000010d r5:00000000 r4:bf88c000
> [<8052b5fc>] (dump_stack+0x0/0x1c) from [<80050bb4>] (__might_sleep+0x1ec/0x238)
> [<800509c8>] (__might_sleep+0x0/0x238) from [<8052cf60>] (mutex_lock_nested+0x38/0x3bc)
> r7:00000000 r6:bf88c000 r5:808b19e0 r4:808a5360
> [<8052cf28>] (mutex_lock_nested+0x0/0x3bc) from [<803e2108>] (clk_get_rate+0x1c/0x84)
> [<803e20ec>] (clk_get_rate+0x0/0x84) from [<8052900c>] (twd_timer_setup+0x28c/0x2e0)
> r5:808b19e0 r4:817c0200
> [<80528d80>] (twd_timer_setup+0x0/0x2e0) from [<805288b8>] (percpu_timer_setup+0x6c/0xdc)
> r9:412fc09a r8:1000406a r7:808b19d8 r6:bf88c000 r5:80879c14
> r4:817c0200
> [<8052884c>] (percpu_timer_setup+0x0/0xdc) from [<80528a68>] (secondary_start_kernel+0x140/0x19c)
> r5:80879c14 r4:00000001
> [<80528928>] (secondary_start_kernel+0x0/0x19c) from [<10528248>] (0x10528248)
> r7:808b19d8 r6:10c03c7d r5:0000001f r4:4f87806a
> BUG: scheduling while atomic: swapper/1/0/0x40000002
> no locks held by swapper/1/0.
> Modules linked in:
> irq event stamp: 279320
> hardirqs last enabled at (279319): [<80052bd0>] idle_task_exit+0x16c/0x1a0
> hardirqs last disabled at (279320): [<8051a470>] cpu_die+0x28/0x98
> softirqs last enabled at (279304): [<8002ae3c>] _local_bh_enable+0x14/0x18
> softirqs last disabled at (279303): [<8002aea8>] irq_enter+0x68/0x78
> Backtrace:
> [<8001284c>] (dump_backtrace+0x0/0x10c) from [<8052b614>] (dump_stack+0x18/0x1c)
> r7:00000001 r6:bf88c000 r5:bf890000 r4:bf890000
> [<8052b5fc>] (dump_stack+0x0/0x1c) from [<800539b4>] (__schedule_bug+0x5c/0x7c)
> [<80053958>] (__schedule_bug+0x0/0x7c) from [<8052e1a8>] (__schedule+0x620/0x6e0)
> r5:bf890000 r4:819215c0
> [<8052db88>] (__schedule+0x0/0x6e0) from [<8052e320>] (_cond_resched+0x44/0x58)
> [<8052e2dc>] (_cond_resched+0x0/0x58) from [<8052cf64>] (mutex_lock_nested+0x3c/0x3bc)
> r5:808b19e0 r4:808a5360
> [<8052cf28>] (mutex_lock_nested+0x0/0x3bc) from [<803e2108>] (clk_get_rate+0x1c/0x84)
> [<803e20ec>] (clk_get_rate+0x0/0x84) from [<8052900c>] (twd_timer_setup+0x28c/0x2e0)
> r5:808b19e0 r4:817c0200
> [<80528d80>] (twd_timer_setup+0x0/0x2e0) from [<805288b8>] (percpu_timer_setup+0x6c/0xdc)
> r9:412fc09a r8:1000406a r7:808b19d8 r6:bf88c000 r5:80879c14
> r4:817c0200
> [<8052884c>] (percpu_timer_setup+0x0/0xdc) from [<80528a68>] (secondary_start_kernel+0x140/0x19c)
> r5:80879c14 r4:00000001
> [<80528928>] (secondary_start_kernel+0x0/0x19c) from [<10528248>] (0x10528248)
> r7:808b19d8 r6:10c03c7d r5:0000001f r4:4f87806a
>
> --
>
> Best Regards,
> Peter Chen
>
^ permalink raw reply related
* [PATCH v2 0/2] Add DMA and device tree support to the flash controller FLCTL
From: Artem Bityutskiy @ 2012-10-19 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABYn4szACuH3LQ193VJj6E=J4q4Ye4E4O6cUgjB8jmQK6RRmpA@mail.gmail.com>
On Wed, 2012-10-17 at 15:05 +0200, Bastian Hecht wrote:
> Hi Artem,
>
> > Hi, I used to be able to compile MTD stuff for mackerel board with the
> > defconfig attached, but now it fails with 3.7-rc1 with as error:
> >
> > /tmp/cc2Nr7AN.s: Error: bad immediate value for 8-bit offset (1024)
> >
> > It fails for dogc4.c, but if I disable DOCG4, it fails for other drivers
> > with a similar error.
> >
> > I've tried (arm) gcc 4.6.3 and the latest Linaro 4.7 build.
> >
> > Any idea? I did not dig this, is this a known issue? Could you try to
> > reproduce this in your setup?
> >
>
> I can reproduce the error with the following output:
> /tmp/ccYAbker.s: Assembler messages:
> /tmp/ccYAbker.s: Error: bad immediate value for 8-bit offset (2048)
> make[3]: *** [drivers/mtd/nand/docg4.o] Error 1
>
> The compiler version is: gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> I usually use: gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) and
> can compile things without problems.
Yeah, a bug report would be great. I've switched to 4.4.1 and checked
your patches with aiaiai:
--------------------------------------------------------------------------------
Successfully built configuration "arm-mackerel_defconfig,arm,arm-none-linux-gnueabi-", results:
--- before_patching.log
+++ after_patching.log
@@ @@
+drivers/mtd/nand/sh_flctl.c:1142 flctl_probe() warn: 'irq' was not released on error [smatch]
+drivers/mtd/nand/sh_flctl.c:1142:2-8: ERROR: missing iounmap; ioremap on line 1117 and execution via conditional on line 1140 [coccinelle]
+drivers/mtd/nand/sh_flctl.c:164:25: warning: cast removes address space of expression [sparse]
+drivers/mtd/nand/sh_flctl.c:181:25: warning: cast removes address space of expression [sparse]
-drivers/mtd/nand/sh_flctl.c:311 write_fiforeg() Error invalid range 4096 to -1 [smatch]
-drivers/mtd/nand/sh_flctl.c:317:17: warning: incorrect type in argument 2 (different address spaces) [sparse]
-drivers/mtd/nand/sh_flctl.c:317:17: expected void volatile [noderef] <asn:2>*addr [sparse]
-drivers/mtd/nand/sh_flctl.c:317:17: got void *fifo_addr [sparse]
+drivers/mtd/nand/sh_flctl.c:469 write_fiforeg() Error invalid range 4096 to -1 [smatch]
+drivers/mtd/nand/sh_flctl.c:485:17: warning: incorrect type in argument 2 (different address spaces) [sparse]
+drivers/mtd/nand/sh_flctl.c:485:17: expected void volatile [noderef] <asn:2>*addr [sparse]
+drivers/mtd/nand/sh_flctl.c:485:17: got void *fifo_addr [sparse]
--------------------------------------------------------------------------------
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121019/e8f29d12/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc
From: Mark Zhang @ 2012-10-19 5:58 UTC (permalink / raw)
To: linux-arm-kernel
Define pinmux for DDC. The DDC pinmux in Ventana is 2 pins in I2C2.
Signed-off-by: Mark Zhang <markz@nvidia.com>
---
arch/arm/boot/dts/tegra20-ventana.dts | 70 ++++++++++++++++++++++++++++++---
1 file changed, 65 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index bec8bb2..b6b3af4 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -64,11 +64,6 @@
nvidia,pins = "dap4";
nvidia,function = "dap4";
};
- ddc {
- nvidia,pins = "ddc", "owc", "spdi", "spdo",
- "uac";
- nvidia,function = "rsvd2";
- };
dta {
nvidia,pins = "dta", "dtb", "dtc", "dtd", "dte";
nvidia,function = "vi";
@@ -248,6 +243,39 @@
nvidia,slew-rate-falling = <3>;
};
};
+
+ state_i2cmux_ddc: pinmux_i2cmux_ddc {
+ ddc {
+ nvidia,pins = "ddc";
+ nvidia,function = "i2c2";
+ };
+ pta {
+ nvidia,pins = "pta";
+ nvidia,function = "rsvd4";
+ };
+ };
+
+ state_i2cmux_pta: pinmux_i2cmux_pta {
+ ddc {
+ nvidia,pins = "ddc";
+ nvidia,function = "rsvd4";
+ };
+ pta {
+ nvidia,pins = "pta";
+ nvidia,function = "i2c2";
+ };
+ };
+
+ state_i2cmux_idle: pinmux_i2cmux_idle {
+ ddc {
+ nvidia,pins = "ddc";
+ nvidia,function = "rsvd4";
+ };
+ pta {
+ nvidia,pins = "pta";
+ nvidia,function = "rsvd4";
+ };
+ };
};
i2s at 70002800 {
@@ -291,6 +319,38 @@
clock-frequency = <400000>;
};
+ i2cmux {
+ compatible = "i2c-mux-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-parent = <&{/i2c@7000c400}>;
+
+ pinctrl-names = "ddc", "pta", "idle";
+ pinctrl-0 = <&state_i2cmux_ddc>;
+ pinctrl-1 = <&state_i2cmux_pta>;
+ pinctrl-2 = <&state_i2cmux_idle>;
+
+ i2c at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ smart-battery at b {
+ compatible = "ti,bq24617", "smart-battery-1.1";
+ reg = <0xb>;
+ ti,i2c-retry-count = <2>;
+ ti,poll-retry-count = <10>;
+ };
+ };
+ };
+
i2c at 7000c500 {
status = "okay";
clock-frequency = <400000>;
--
1.7.9.5
^ permalink raw reply related
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Richard Cochran @ 2012-10-19 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210181924490.16473@utopia.booyaka.com>
On Thu, Oct 18, 2012 at 07:27:22PM +0000, Paul Walmsley wrote:
> I wrote that we'll schedule the SoC integration patch for sending upstream
> for 3.8. This does not necessarily mean that our upstreams will take it,
> or that it will result in a working CPSW.
Forgive me for barking up the wrong tree at you, Paul. This is
directed toward the omap people:
Please, PLEASE, make sure that the mainline code is working.
It is easy to verify. Just compile the code and boot it.
Thanks,
Richard
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Richard Cochran @ 2012-10-19 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50806B1D.9040504@ti.com>
On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
>
> Another important point is, this driver is also required and used for
> Davinci family of devices (arch/mach/mach-davinci/).
That is really beside the point. If the code isn't ready yet, then
don't merge it.
When I asked about the beaglebone, I was given the impression that it
will be ready for v3.7-rc1. But, as I know realize, at the current
rate, it might not even be ready for v3.8.
I don't mind waiting, but please make sure that whatever lands into a
release is really, truly working.
Thanks,
Richard
^ permalink raw reply
* [PATCH] ARM: tegra30: clocks: add AHB and APB clocks
From: Joseph Lo @ 2012-10-19 6:38 UTC (permalink / raw)
To: linux-arm-kernel
Adding the AHB and APB bus clock control interface for Tegra30.
Signed-off-by: Joseph Lo <josephl@nvidia.com>
---
arch/arm/mach-tegra/common.c | 4 +
arch/arm/mach-tegra/tegra30_clocks.c | 106 +++++++++++++++++++++++++++++
arch/arm/mach-tegra/tegra30_clocks.h | 1 +
arch/arm/mach-tegra/tegra30_clocks_data.c | 46 +++++++++++++
4 files changed, 157 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 0b0a5f5..177f164 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -104,6 +104,10 @@ static __initdata struct tegra_clk_init_table tegra30_clk_init_table[] = {
{ "clk_m", NULL, 0, true },
{ "pll_p", "clk_m", 408000000, true },
{ "pll_p_out1", "pll_p", 9600000, true },
+ { "pll_p_out4", "pll_p", 102000000, true },
+ { "sclk", "pll_p_out4", 102000000, true },
+ { "hclk", "sclk", 102000000, true },
+ { "pclk", "hclk", 51000000, true },
{ NULL, NULL, 0, 0},
};
#endif
diff --git a/arch/arm/mach-tegra/tegra30_clocks.c b/arch/arm/mach-tegra/tegra30_clocks.c
index e9de5df..875744f 100644
--- a/arch/arm/mach-tegra/tegra30_clocks.c
+++ b/arch/arm/mach-tegra/tegra30_clocks.c
@@ -792,6 +792,112 @@ struct clk_ops tegra30_twd_ops = {
.recalc_rate = tegra30_twd_clk_recalc_rate,
};
+/* bus clock functions */
+static int tegra30_bus_clk_is_enabled(struct clk_hw *hw)
+{
+ struct clk_tegra *c = to_clk_tegra(hw);
+ u32 val = clk_readl(c->reg);
+
+ c->state = ((val >> c->reg_shift) & BUS_CLK_DISABLE) ? OFF : ON;
+ return c->state;
+}
+
+static int tegra30_bus_clk_enable(struct clk_hw *hw)
+{
+ struct clk_tegra *c = to_clk_tegra(hw);
+ u32 val;
+
+ val = clk_readl(c->reg);
+ val &= ~(BUS_CLK_DISABLE << c->reg_shift);
+ clk_writel(val, c->reg);
+
+ return 0;
+}
+
+static void tegra30_bus_clk_disable(struct clk_hw *hw)
+{
+ struct clk_tegra *c = to_clk_tegra(hw);
+ u32 val;
+
+ val = clk_readl(c->reg);
+ val |= BUS_CLK_DISABLE << c->reg_shift;
+ clk_writel(val, c->reg);
+}
+
+static unsigned long tegra30_bus_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long prate)
+{
+ struct clk_tegra *c = to_clk_tegra(hw);
+ u32 val = clk_readl(c->reg);
+ u64 rate = prate;
+
+ c->div = ((val >> c->reg_shift) & BUS_CLK_DIV_MASK) + 1;
+ c->mul = 1;
+
+ if (c->mul != 0 && c->div != 0) {
+ rate *= c->mul;
+ rate += c->div - 1; /* round up */
+ do_div(rate, c->div);
+ }
+ return rate;
+}
+
+static int tegra30_bus_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_tegra *c = to_clk_tegra(hw);
+ int ret = -EINVAL;
+ u32 val;
+ int i;
+
+ val = clk_readl(c->reg);
+ for (i = 1; i <= 4; i++) {
+ if (rate == parent_rate / i) {
+ val &= ~(BUS_CLK_DIV_MASK << c->reg_shift);
+ val |= (i - 1) << c->reg_shift;
+ clk_writel(val, c->reg);
+ c->div = i;
+ c->mul = 1;
+ ret = 0;
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static long tegra30_bus_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ unsigned long parent_rate = *prate;
+ s64 divider;
+
+ if (rate >= parent_rate)
+ return rate;
+
+ divider = parent_rate;
+ divider += rate - 1;
+ do_div(divider, rate);
+
+ if (divider < 0)
+ return divider;
+
+ if (divider > 4)
+ divider = 4;
+ do_div(parent_rate, divider);
+
+ return parent_rate;
+}
+
+struct clk_ops tegra30_bus_ops = {
+ .is_enabled = tegra30_bus_clk_is_enabled,
+ .enable = tegra30_bus_clk_enable,
+ .disable = tegra30_bus_clk_disable,
+ .set_rate = tegra30_bus_clk_set_rate,
+ .round_rate = tegra30_bus_clk_round_rate,
+ .recalc_rate = tegra30_bus_clk_recalc_rate,
+};
+
/* Blink output functions */
static int tegra30_blink_clk_is_enabled(struct clk_hw *hw)
{
diff --git a/arch/arm/mach-tegra/tegra30_clocks.h b/arch/arm/mach-tegra/tegra30_clocks.h
index f2f88fe..7a34adb 100644
--- a/arch/arm/mach-tegra/tegra30_clocks.h
+++ b/arch/arm/mach-tegra/tegra30_clocks.h
@@ -34,6 +34,7 @@ extern struct clk_ops tegra_clk_out_ops;
extern struct clk_ops tegra30_super_ops;
extern struct clk_ops tegra30_blink_clk_ops;
extern struct clk_ops tegra30_twd_ops;
+extern struct clk_ops tegra30_bus_ops;
extern struct clk_ops tegra30_periph_clk_ops;
extern struct clk_ops tegra30_dsib_clk_ops;
extern struct clk_ops tegra_nand_clk_ops;
diff --git a/arch/arm/mach-tegra/tegra30_clocks_data.c b/arch/arm/mach-tegra/tegra30_clocks_data.c
index 3d2e553..7bc8b1d 100644
--- a/arch/arm/mach-tegra/tegra30_clocks_data.c
+++ b/arch/arm/mach-tegra/tegra30_clocks_data.c
@@ -711,6 +711,50 @@ static struct clk tegra_clk_sclk = {
.num_parents = ARRAY_SIZE(mux_sclk),
};
+static const char *tegra_hclk_parent_names[] = {
+ "tegra_sclk",
+};
+
+static struct clk *tegra_hclk_parents[] = {
+ &tegra_clk_sclk,
+};
+
+static struct clk tegra_hclk;
+static struct clk_tegra tegra_hclk_hw = {
+ .hw = {
+ .clk = &tegra_hclk,
+ },
+ .flags = DIV_BUS,
+ .reg = 0x30,
+ .reg_shift = 4,
+ .max_rate = 378000000,
+ .min_rate = 12000000,
+};
+DEFINE_CLK_TEGRA(hclk, 0, &tegra30_bus_ops, 0, tegra_hclk_parent_names,
+ tegra_hclk_parents, &tegra_clk_sclk);
+
+static const char *tegra_pclk_parent_names[] = {
+ "tegra_hclk",
+};
+
+static struct clk *tegra_pclk_parents[] = {
+ &tegra_hclk,
+};
+
+static struct clk tegra_pclk;
+static struct clk_tegra tegra_pclk_hw = {
+ .hw = {
+ .clk = &tegra_pclk,
+ },
+ .flags = DIV_BUS,
+ .reg = 0x30,
+ .reg_shift = 0,
+ .max_rate = 167000000,
+ .min_rate = 12000000,
+};
+DEFINE_CLK_TEGRA(pclk, 0, &tegra30_bus_ops, 0, tegra_pclk_parent_names,
+ tegra_pclk_parents, &tegra_hclk);
+
static const char *mux_blink[] = {
"clk_32k",
};
@@ -1325,6 +1369,8 @@ struct clk *tegra_ptr_clks[] = {
&tegra_cml1,
&tegra_pciex,
&tegra_clk_sclk,
+ &tegra_hclk,
+ &tegra_pclk,
&tegra_clk_blink,
&tegra30_clk_twd,
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2] ARM: pxa: hx4700: Fix backlight PWM device number
From: Haojian Zhuang @ 2012-10-19 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120927182951.GA4639@avionic-0098.mockup.avionic-design.de>
On Fri, Sep 28, 2012 at 2:29 AM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> On Wed, Sep 26, 2012 at 03:59:52PM +0100, Paul Parsons wrote:
>> Recent changes to PXA PWM support changed the PXA27X PWM device
>> numbering scheme.
>>
>> The linux-3.5 PXA PWM driver followed the hardware numbering scheme for
>> the 4 PWMs, while the linux-3.6-rc1 PXA PWM driver has adopted a linear
>> numbering scheme:
>>
>> Address Hardware 3.5 pwm_id 3.6-rc1 pwm_id
>> 0x40b00000 PWM0 0 0
>> 0x40b00010 PWM2 2 1
>> 0x40c00000 PWM1 1 2
>> 0x40c00010 PWM3 3 3
>>
>> The hx4700 backlight uses PWM1 at 0x40c00000. Consequently the pwm_id
>> must be changed from 1 to 2.
>>
>> This patch fixes the backlight PWM device number and at the same time
>> moves from the legacy PWM API (pwm_id) to the new PWM API (pwm_lookup).
>>
>> Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
>> Cc: Thierry Reding <thierry.reding@avionic-design.de>
>> ---
>>
>> V2: Switch from legacy PWM API to new PWM API.
>>
>> arch/arm/mach-pxa/hx4700.c | 8 +++++++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
>> index e631198..d66f9f9 100644
>> --- a/arch/arm/mach-pxa/hx4700.c
>> +++ b/arch/arm/mach-pxa/hx4700.c
>> @@ -28,6 +28,7 @@
>> #include <linux/mfd/asic3.h>
>> #include <linux/mtd/physmap.h>
>> #include <linux/pda_power.h>
>> +#include <linux/pwm.h>
>> #include <linux/pwm_backlight.h>
>> #include <linux/regulator/driver.h>
>> #include <linux/regulator/gpio-regulator.h>
>> @@ -556,7 +557,7 @@ static struct platform_device hx4700_lcd = {
>> */
>>
>> static struct platform_pwm_backlight_data backlight_data = {
>> - .pwm_id = 1,
>> + .pwm_id = -1, /* Superseded by pwm_lookup */
>
> It doesn't actually matter what this is set to, but -1 is probably a
> good marker that the field is invalid.
>
>> .max_brightness = 200,
>> .dft_brightness = 100,
>> .pwm_period_ns = 30923,
>> @@ -571,6 +572,10 @@ static struct platform_device backlight = {
>> },
>> };
>>
>> +static struct pwm_lookup hx4700_pwm_lookup[] = {
>> + PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL),
>> +};
>> +
>> /*
>> * USB "Transceiver"
>> */
>> @@ -872,6 +877,7 @@ static void __init hx4700_init(void)
>> pxa_set_stuart_info(NULL);
>>
>> platform_add_devices(devices, ARRAY_SIZE(devices));
>> + pwm_add_table(hx4700_pwm_lookup, ARRAY_SIZE(hx4700_pwm_lookup));
>>
>> pxa_set_ficp_info(&ficp_info);
>> pxa27x_set_i2c_power_info(NULL);
>
> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Paul,
I failed to apply this patch on v3.7-rc1. Could you help to format the
patch again?
Regards
Haojian
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC fixes for v3.7 #2
From: Simon Horman @ 2012-10-19 6:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Arnd,
please consider the following fix for the r8a7779 SoC for 3.6.
It resolves some more fallout from recent IOMEM() changes.
----------------------------------------------------------------
The following changes since commit 11f93576b0b50bf391ffafa544b85e541f5e59a5:
ARM: shmobile: r8a7779: use __iomem pointers for MMIO (2012-10-16 08:58:56 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes
for you to fetch changes up to ed7d132a634e7e4c3fa657363df5df39e7f768e4:
ARM: shmobile: r8a7779: I/O address abuse cleanup (2012-10-19 15:39:38 +0900)
----------------------------------------------------------------
Kuninori Morimoto (1):
ARM: shmobile: r8a7779: I/O address abuse cleanup
arch/arm/mach-shmobile/setup-r8a7779.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7779: I/O address abuse cleanup
From: Simon Horman @ 2012-10-19 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350629360-27438-1-git-send-email-horms@verge.net.au>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
a2a47ca36642e3995e982957bc42678cf11ca6ac
(ARM: __io abuse cleanup) cleanuped __io() -> IOMEM(),
but setup-r8a7779.c was out of target,
since it directly used (void __iomem __force *) instead of __io().
This patch cleanup it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/setup-r8a7779.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 2917668..ebbffc2 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -247,7 +247,7 @@ void __init r8a7779_add_standard_devices(void)
{
#ifdef CONFIG_CACHE_L2X0
/* Early BRESP enable, Shared attribute override enable, 64K*16way */
- l2x0_init((void __iomem __force *)(0xf0100000), 0x40470000, 0x82000fff);
+ l2x0_init(IOMEM(0xf0100000), 0x40470000, 0x82000fff);
#endif
r8a7779_pm_init();
--
1.7.10.4
^ permalink raw reply related
* [GIT PULL] Renesas ARM-based SoC fixes for v3.7 #2
From: Simon Horman @ 2012-10-19 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350629360-27438-1-git-send-email-horms@verge.net.au>
On Fri, Oct 19, 2012 at 03:49:19PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following fix for the r8a7779 SoC for 3.6.
Same typo as last time: s/3.6/3.7/
> It resolves some more fallout from recent IOMEM() changes.
>
> ----------------------------------------------------------------
> The following changes since commit 11f93576b0b50bf391ffafa544b85e541f5e59a5:
>
> ARM: shmobile: r8a7779: use __iomem pointers for MMIO (2012-10-16 08:58:56 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes
>
> for you to fetch changes up to ed7d132a634e7e4c3fa657363df5df39e7f768e4:
>
> ARM: shmobile: r8a7779: I/O address abuse cleanup (2012-10-19 15:39:38 +0900)
>
> ----------------------------------------------------------------
> Kuninori Morimoto (1):
> ARM: shmobile: r8a7779: I/O address abuse cleanup
>
> arch/arm/mach-shmobile/setup-r8a7779.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2] arm: omap: move OMAP USB platform data to <linux/platform_data/omap-usb.h>
From: Felipe Balbi @ 2012-10-19 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019014917.GL30550@atomide.com>
Hi,
On Thu, Oct 18, 2012 at 06:49:17PM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121017 22:56]:
> > Hi,
> >
> > On Wed, Oct 17, 2012 at 01:34:04PM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi <balbi@ti.com> [121017 08:54]:
> > > > In order to make single zImage work for ARM architecture,
> > > > we need to make sure we don't depend on private headers.
> > > >
> > > > Move USB platform_data to <linux/platform_data/omap-usb.h>
> > > > and keep only internal functions in <plat/usb.h>.
> > >
> > > Thanks, looks like I can't make this apply against v3.7-rc1:
> > >
> > > patching file arch/arm/plat-omap/include/plat/usb.h
> > > Hunk #1 FAILED at 1.
> > > Hunk #2 FAILED at 26.
> > > Hunk #3 FAILED at 44.
> > > Hunk #4 FAILED at 65.
> > > Hunk #5 FAILED at 81.
> > > Hunk #6 succeeded at 28 with fuzz 2 (offset -128 lines).
> > > 5 out of 6 hunks FAILED -- rejects in file arch/arm/plat-omap/include/plat/usb.h
> > >
> > > Can you please check it?
> >
> > Are you sure you have a clean v3.7-rc1 ?
>
> Yes. Figured it out, it fails to apply with quilt, but applies
> with git.
probably because of file rename.
> But it does not compile with all configs though, and does
> not remove plat/usb.h. Thanks anyways. I'll post a proper
> series shortly with your patch fixed up.
ok... I'll check it out. I kept the non-static functions in plat/usb.h
because they didn't belong on platform_data/usb-omap.h. What should be
done with those, then ? move to mach/ ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121019/fc967dd3/attachment.sig>
^ permalink raw reply
* dts: question about how to configure PIO used as i2c irq
From: Bo Shen @ 2012-10-19 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507BC449.6070203@atmel.com>
Hi J,
On 10/15/2012 16:07, Nicolas Ferre wrote:
> On 10/15/2012 07:57 AM, Jean-Christophe PLAGNIOL-VILLARD :
>> On 10:53 Mon 15 Oct , Bo Shen wrote:
>>> Hi All,
>>> When moving atmel qt1070 linux driver with DT support. The atmel
>>> qt1070 is an I2C device. I meet the following questions.
>>>
>>> The qt1070 DT node
>>> --<--------------
>>> qt1070: keyboard at 1b {
>>> compatible = "atmel,qt1070";
>>> reg = <0x1b>;
>>> interrupt-parent = <&pioA>;
>>> interrupts = <7 0x0>;
>>> };
>>> -->--------------
>>>
>>> DT will parse this node and map irq, the i2c_client->irq. This can
>>> be used directly in atmel qt1070 driver. However, the PIO which used
>>> as irq need configure as a PIO input. Now, we can not use
>>> irq_to_gpio() function to convert irq to gpio. So, if we can not
>>> configure this gpio.
>>>
>>> If we configure the pio in board-dt.c, I think this is not a good
>>> place. For example, if the kernel image support multiplatform, while
>>> on these platform, using different pio for qt1070, so this will
>>> cause only one platform can use qt1070.
>>>
>>> So, for this question, how should I solve it? Would you please
>>> give me some advice?
>> I already reply you in private 4 times
>
> Yes, but maybe it is because it was not well explained, or not developed
> to the proper extend... So, please do not make these remarks: if the
> conversation was private, it is not necessary to recall that here. Maybe
> Voice is looking for help from someone else?
>
>> you have only 2 choice pass the gpio and manage in c
>> or configure the gpio as input in the xlate or map of the gpio drivers and the
>> mux via pinctrl
>
> Can you please develop a bit more: which xlate? How to tell the gpio
> driver about the map? Can you provide an example?
Any information for this? Search with google, I don't find any useful
information.
> Bye,
>
^ permalink raw reply
* [PATCH] Documentation: dt: i2c: Update trivial-devices list
From: AnilKumar Ch @ 2012-10-19 6:58 UTC (permalink / raw)
To: linux-arm-kernel
Update i2c trivial-devices list by adding the description for
ti,tmp275 temperature sensor and taos,tsl2550 ambient light
sensor.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
.../devicetree/bindings/i2c/trivial-devices.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 2f5322b..446859f 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -55,5 +55,7 @@ st-micro,24c256 i2c serial eeprom (24cxx)
stm,m41t00 Serial Access TIMEKEEPER
stm,m41t62 Serial real-time clock (RTC) with alarm
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
+taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface
ti,tsc2003 I2C Touch-Screen Controller
ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
+ti,tmp275 Digital Temperature Sensor
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 00/21] treewide: Use consistent api style for address testing
From: Eric Dumazet @ 2012-10-19 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1350618006.git.joe@perches.com>
On Thu, 2012-10-18 at 20:55 -0700, Joe Perches wrote:
> ethernet, ipv4, and ipv6 address testing uses 3 different api naming styles.
>
> ethernet uses: is_<foo>_ether_addr
> ipv4 uses: ipv4_is_<foo>
> ipv6 uses: ipv6_addr_<foo>
>
> Standardize on the ipv6 style of <prefix>_addr_<type> to reduce
> the number of styles to remember.
>
> The new consistent styles are:
>
> eth_addr_<foo>(const u8 *)
> ipv4_addr_<foo>(__be32)
> ipv6_addr_<foo>(const struct in6_addr *)
>
> Add temporary backward compatibility #defines for the old names too.
>
> Joe Perches (21):
> etherdevice: Rename is_<foo>_ether_addr tests to eth_addr_<foo>
> net: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> arch: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> wireless: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> drivers: net: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> staging: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> infiniband: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> scsi: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> of: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> s390: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> usb: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> uwb: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> Documentation: networking: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> llc_if.h: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
> in.h: Rename ipv4_is_<foo> functions to ipv4_addr_<foo>
> net: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
> infiniband: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
> ath6kl: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
> parisc: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
> lockd: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
> sctp: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
Yes they are some names discrepancies, thats a big deal.
And we have alloc_skb() / kfree_skb() / skb_clone()
Why not skb_alloc() / skb_free() / skb_clone() ?
Some people actually know current code by name of functions, they dont
want to change their mind and having to grep include files and git log
to learn the new names of an old function, especially when traveling and
using a laptop.
Sure, when we want to use eth_random_addr(), a grep into include files
to check if its still the right name (old one was random_ether_addr())
is OK because we dont use this one often.
If you think about it, eth_random_addr() was not the perfect name.
Think about all the documentation you can find outside of kernel tree,
RFC and things like that, copy/pasting some linux kernel code.
This kind of changes make our life more difficult, when we have to
backport patches or rebase code, or even perform some searches to find
prior issues/discussions.
Life of a kernel developer is not only dealing with latest Linus (or
-next) tree, and using automatic 'tools'.
Thats a real pain for me at least.
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP2+: Introduce local usb.h
From: Felipe Balbi @ 2012-10-19 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019022005.6693.98660.stgit@muffinssi.local>
On Thu, Oct 18, 2012 at 07:20:05PM -0700, Tony Lindgren wrote:
> Let's move what we can from plat/usb.h to the local usb.h
> for ARM common zImage support.
>
> This is needed so we can remove plat/usb.h for ARM common
> zImage support.
>
> Cc: Felipe Balbi <balbi@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Partha Basak <parthab@india.ti.com>
> Cc: Keshava Munegowda <keshava_mgowda@ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap1/clock.c | 1
> arch/arm/mach-omap2/board-2430sdp.c | 1
> arch/arm/mach-omap2/board-3430sdp.c | 1
> arch/arm/mach-omap2/board-3630sdp.c | 1
> arch/arm/mach-omap2/board-4430sdp.c | 1
> arch/arm/mach-omap2/board-am3517crane.c | 1
> arch/arm/mach-omap2/board-am3517evm.c | 1
> arch/arm/mach-omap2/board-cm-t35.c | 1
> arch/arm/mach-omap2/board-cm-t3517.c | 1
> arch/arm/mach-omap2/board-devkit8000.c | 1
> arch/arm/mach-omap2/board-igep0020.c | 1
> arch/arm/mach-omap2/board-ldp.c | 1
> arch/arm/mach-omap2/board-omap3beagle.c | 1
> arch/arm/mach-omap2/board-omap3evm.c | 1
> arch/arm/mach-omap2/board-omap3logic.c | 1
> arch/arm/mach-omap2/board-omap3pandora.c | 1
> arch/arm/mach-omap2/board-omap3stalker.c | 1
> arch/arm/mach-omap2/board-omap3touchbook.c | 1
> arch/arm/mach-omap2/board-omap4panda.c | 1
> arch/arm/mach-omap2/board-overo.c | 1
> arch/arm/mach-omap2/board-rm680.c | 1
> arch/arm/mach-omap2/board-rx51.c | 1
> arch/arm/mach-omap2/board-ti8168evm.c | 1
> arch/arm/mach-omap2/board-zoom-peripherals.c | 1
> arch/arm/mach-omap2/board-zoom.c | 1
> arch/arm/mach-omap2/common.h | 2
> arch/arm/mach-omap2/omap_phy_internal.c | 4 -
> arch/arm/mach-omap2/twl-common.c | 1
> arch/arm/mach-omap2/usb-host.c | 2
> arch/arm/mach-omap2/usb-musb.c | 2
> arch/arm/mach-omap2/usb.h | 82 ++++++++++++++++++++
> arch/arm/plat-omap/include/plat/usb.h | 106 --------------------------
> 32 files changed, 88 insertions(+), 136 deletions(-)
> create mode 100644 arch/arm/mach-omap2/usb.h
>
> diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
> index 638f407..1e49eda 100644
> --- a/arch/arm/mach-omap1/clock.c
> +++ b/arch/arm/mach-omap1/clock.c
> @@ -22,7 +22,6 @@
> #include <asm/mach-types.h>
>
> #include <plat/cpu.h>
> -#include <plat/usb.h>
> #include <plat/clock.h>
> #include <plat/sram.h>
> #include <plat/clkdev_omap.h>
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
> index 95b384d..df561ad 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -35,7 +35,6 @@
>
> #include "common.h"
> #include <plat/gpmc.h>
> -#include <plat/usb.h>
> #include "gpmc-smc91x.h"
>
> #include <video/omapdss.h>
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
> index 96cd369..14c07ee 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -30,7 +30,6 @@
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
>
> -#include <plat/usb.h>
> #include "common.h"
> #include <plat/dma.h>
> #include <plat/gpmc.h>
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c
> index fc224ad..f8e6288 100644
> --- a/arch/arm/mach-omap2/board-3630sdp.c
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -18,7 +18,6 @@
>
> #include "common.h"
> #include "gpmc-smc91x.h"
> -#include <plat/usb.h>
>
> #include <mach/board-zoom.h>
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index 3669c12..5700fc5 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -34,7 +34,6 @@
> #include <asm/mach/map.h>
>
> #include "common.h"
> -#include <plat/usb.h>
> #include <plat/mmc.h>
> #include "omap4-keypad.h"
> #include <video/omapdss.h>
> diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
> index 318fead..603503c 100644
> --- a/arch/arm/mach-omap2/board-am3517crane.c
> +++ b/arch/arm/mach-omap2/board-am3517crane.c
> @@ -26,7 +26,6 @@
> #include <asm/mach/map.h>
>
> #include "common.h"
> -#include <plat/usb.h>
>
> #include "am35xx-emac.h"
> #include "mux.h"
> diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
> index e162897..0dbeb77 100644
> --- a/arch/arm/mach-omap2/board-am3517evm.c
> +++ b/arch/arm/mach-omap2/board-am3517evm.c
> @@ -33,7 +33,6 @@
> #include <asm/mach/map.h>
>
> #include "common.h"
> -#include <plat/usb.h>
> #include <video/omapdss.h>
> #include <video/omap-panel-generic-dpi.h>
> #include <video/omap-panel-tfp410.h>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index 376d26e..435c7be 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -41,7 +41,6 @@
> #include "common.h"
> #include <linux/platform_data/mtd-nand-omap2.h>
> #include <plat/gpmc.h>
> -#include <plat/usb.h>
> #include <video/omapdss.h>
> #include <video/omap-panel-generic-dpi.h>
> #include <video/omap-panel-tfp410.h>
> diff --git a/arch/arm/mach-omap2/board-cm-t3517.c b/arch/arm/mach-omap2/board-cm-t3517.c
> index 59c0a45..db1e14c 100644
> --- a/arch/arm/mach-omap2/board-cm-t3517.c
> +++ b/arch/arm/mach-omap2/board-cm-t3517.c
> @@ -39,7 +39,6 @@
> #include <asm/mach/map.h>
>
> #include "common.h"
> -#include <plat/usb.h>
> #include <linux/platform_data/mtd-nand-omap2.h>
> #include <plat/gpmc.h>
>
> diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
> index 1fd161e..8df2720 100644
> --- a/arch/arm/mach-omap2/board-devkit8000.c
> +++ b/arch/arm/mach-omap2/board-devkit8000.c
> @@ -41,7 +41,6 @@
> #include "common.h"
> #include <plat/gpmc.h>
> #include <linux/platform_data/mtd-nand-omap2.h>
> -#include <plat/usb.h>
> #include <video/omapdss.h>
> #include <video/omap-panel-generic-dpi.h>
> #include <video/omap-panel-tfp410.h>
> diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
> index 48d5e41..62da89f 100644
> --- a/arch/arm/mach-omap2/board-igep0020.c
> +++ b/arch/arm/mach-omap2/board-igep0020.c
> @@ -31,7 +31,6 @@
>
> #include "common.h"
> #include <plat/gpmc.h>
> -#include <plat/usb.h>
>
> #include <video/omapdss.h>
> #include <video/omap-panel-tfp410.h>
> diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
> index ee8c3cf..8d9406b 100644
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -37,7 +37,6 @@
> #include "common.h"
> #include <plat/gpmc.h>
> #include <mach/board-zoom.h>
> -#include <plat/usb.h>
> #include "gpmc-smsc911x.h"
>
> #include <video/omapdss.h>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 388c431..33a5f58 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -43,7 +43,6 @@
> #include <video/omap-panel-tfp410.h>
> #include <plat/gpmc.h>
> #include <linux/platform_data/mtd-nand-omap2.h>
> -#include <plat/usb.h>
> #include <plat/omap_device.h>
>
> #include "mux.h"
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index b9b776b..6e7e69b 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -45,7 +45,6 @@
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
>
> -#include <plat/usb.h>
> #include <linux/platform_data/mtd-nand-omap2.h>
> #include "common.h"
> #include <linux/platform_data/spi-omap2-mcspi.h>
> diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c
> index 7bd8253..a0d8fe1 100644
> --- a/arch/arm/mach-omap2/board-omap3logic.c
> +++ b/arch/arm/mach-omap2/board-omap3logic.c
> @@ -37,7 +37,6 @@
> #include "gpmc-smsc911x.h"
> #include <plat/gpmc.h>
> #include <plat/sdrc.h>
> -#include <plat/usb.h>
>
> #include "common.h"
> #include "mux.h"
> diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
> index 00a1f4a..f2be51b 100644
> --- a/arch/arm/mach-omap2/board-omap3pandora.c
> +++ b/arch/arm/mach-omap2/board-omap3pandora.c
> @@ -42,7 +42,6 @@
> #include <asm/mach/map.h>
>
> #include "common.h"
> -#include <plat/usb.h>
> #include <video/omapdss.h>
> #include <linux/platform_data/mtd-nand-omap2.h>
>
> diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
> index 731235e..4343fb6 100644
> --- a/arch/arm/mach-omap2/board-omap3stalker.c
> +++ b/arch/arm/mach-omap2/board-omap3stalker.c
> @@ -42,7 +42,6 @@
> #include "common.h"
> #include <plat/gpmc.h>
> #include <linux/platform_data/mtd-nand-omap2.h>
> -#include <plat/usb.h>
> #include <video/omapdss.h>
> #include <video/omap-panel-generic-dpi.h>
> #include <video/omap-panel-tfp410.h>
> diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
> index 944ffc4..c26c958 100644
> --- a/arch/arm/mach-omap2/board-omap3touchbook.c
> +++ b/arch/arm/mach-omap2/board-omap3touchbook.c
> @@ -46,7 +46,6 @@
> #include "common.h"
> #include <plat/gpmc.h>
> #include <linux/platform_data/mtd-nand-omap2.h>
> -#include <plat/usb.h>
>
> #include "mux.h"
> #include "hsmmc.h"
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
> index bfcd397..74e39bb 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -39,7 +39,6 @@
> #include <video/omapdss.h>
>
> #include "common.h"
> -#include <plat/usb.h>
> #include <plat/mmc.h>
> #include <video/omap-panel-tfp410.h>
>
> diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
> index b700685..0eed6da 100644
> --- a/arch/arm/mach-omap2/board-overo.c
> +++ b/arch/arm/mach-omap2/board-overo.c
> @@ -50,7 +50,6 @@
> #include <video/omap-panel-generic-dpi.h>
> #include <video/omap-panel-tfp410.h>
> #include <plat/gpmc.h>
> -#include <plat/usb.h>
>
> #include "mux.h"
> #include "sdram-micron-mt46h32m32lf-6.h"
> diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
> index 45997bf..d55a983 100644
> --- a/arch/arm/mach-omap2/board-rm680.c
> +++ b/arch/arm/mach-omap2/board-rm680.c
> @@ -24,7 +24,6 @@
>
> #include <plat/i2c.h>
> #include <plat/mmc.h>
> -#include <plat/usb.h>
> #include <plat/gpmc.h>
> #include "common.h"
> #include <plat/serial.h>
> diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
> index 7bbb05d..8c4d27e 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -26,7 +26,6 @@
> #include "common.h"
> #include <plat/dma.h>
> #include <plat/gpmc.h>
> -#include <plat/usb.h>
>
> #include "mux.h"
> #include "pm.h"
> diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-omap2/board-ti8168evm.c
> index c4f8833..4977c77 100644
> --- a/arch/arm/mach-omap2/board-ti8168evm.c
> +++ b/arch/arm/mach-omap2/board-ti8168evm.c
> @@ -20,7 +20,6 @@
> #include <asm/mach/map.h>
>
> #include "common.h"
> -#include <plat/usb.h>
>
> static struct omap_musb_board_data musb_board_data = {
> .set_phy_power = ti81xx_musb_phy_power,
> diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
> index c166fe1..ce923b7 100644
> --- a/arch/arm/mach-omap2/board-zoom-peripherals.c
> +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
> @@ -26,7 +26,6 @@
> #include <asm/mach/map.h>
>
> #include "common.h"
> -#include <plat/usb.h>
>
> #include <mach/board-zoom.h>
>
> diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
> index 4994438..6e1afae 100644
> --- a/arch/arm/mach-omap2/board-zoom.c
> +++ b/arch/arm/mach-omap2/board-zoom.c
> @@ -22,7 +22,6 @@
> #include <asm/mach/arch.h>
>
> #include "common.h"
> -#include <plat/usb.h>
>
> #include <mach/board-zoom.h>
>
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 7045e4d..fa2f4c9 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -36,6 +36,8 @@
> #include <plat/serial.h>
> #include <plat/common.h>
>
> +#include "usb.h"
> +
> #define OMAP_INTC_START NR_IRQS
>
> #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
> index d992db8..4d76a3c 100644
> --- a/arch/arm/mach-omap2/omap_phy_internal.c
> +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> @@ -27,11 +27,11 @@
> #include <linux/io.h>
> #include <linux/err.h>
> #include <linux/usb.h>
> -
> -#include <plat/usb.h>
> +#include <linux/usb/musb.h>
>
> #include "soc.h"
> #include "control.h"
> +#include "usb.h"
>
> void am35x_musb_reset(void)
> {
> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> index 635e109..1131d47 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -27,7 +27,6 @@
> #include <linux/regulator/fixed.h>
>
> #include <plat/i2c.h>
> -#include <plat/usb.h>
>
> #include "soc.h"
> #include "twl-common.h"
> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
> index 3c43449..b1cf8c8 100644
> --- a/arch/arm/mach-omap2/usb-host.c
> +++ b/arch/arm/mach-omap2/usb-host.c
> @@ -25,10 +25,10 @@
>
> #include <asm/io.h>
>
> -#include <plat/usb.h>
> #include <plat/omap_device.h>
>
> #include "mux.h"
> +#include "usb.h"
>
> #ifdef CONFIG_MFD_OMAP_USB_HOST
>
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 51da21c..faf473f 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -25,12 +25,12 @@
> #include <linux/io.h>
> #include <linux/usb/musb.h>
>
> -#include <plat/usb.h>
> #include <plat/omap_device.h>
>
> #include "am35xx.h"
>
> #include "mux.h"
> +#include "usb.h"
>
> static struct musb_hdrc_config musb_config = {
> .multipoint = 1,
> diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h
> new file mode 100644
> index 0000000..b2c4ff1
> --- /dev/null
> +++ b/arch/arm/mach-omap2/usb.h
> @@ -0,0 +1,82 @@
> +#include <plat/usb.h>
> +
> +/* AM35x */
> +/* USB 2.0 PHY Control */
> +#define CONF2_PHY_GPIOMODE (1 << 23)
> +#define CONF2_OTGMODE (3 << 14)
> +#define CONF2_NO_OVERRIDE (0 << 14)
> +#define CONF2_FORCE_HOST (1 << 14)
> +#define CONF2_FORCE_DEVICE (2 << 14)
> +#define CONF2_FORCE_HOST_VBUS_LOW (3 << 14)
> +#define CONF2_SESENDEN (1 << 13)
> +#define CONF2_VBDTCTEN (1 << 12)
> +#define CONF2_REFFREQ_24MHZ (2 << 8)
> +#define CONF2_REFFREQ_26MHZ (7 << 8)
> +#define CONF2_REFFREQ_13MHZ (6 << 8)
> +#define CONF2_REFFREQ (0xf << 8)
> +#define CONF2_PHYCLKGD (1 << 7)
> +#define CONF2_VBUSSENSE (1 << 6)
> +#define CONF2_PHY_PLLON (1 << 5)
> +#define CONF2_RESET (1 << 4)
> +#define CONF2_PHYPWRDN (1 << 3)
> +#define CONF2_OTGPWRDN (1 << 2)
> +#define CONF2_DATPOL (1 << 1)
> +
> +/* TI81XX specific definitions */
> +#define USBCTRL0 0x620
> +#define USBSTAT0 0x624
> +
> +/* TI816X PHY controls bits */
> +#define TI816X_USBPHY0_NORMAL_MODE (1 << 0)
> +#define TI816X_USBPHY_REFCLK_OSC (1 << 8)
> +
> +/* TI814X PHY controls bits */
> +#define USBPHY_CM_PWRDN (1 << 0)
> +#define USBPHY_OTG_PWRDN (1 << 1)
> +#define USBPHY_CHGDET_DIS (1 << 2)
> +#define USBPHY_CHGDET_RSTRT (1 << 3)
> +#define USBPHY_SRCONDM (1 << 4)
> +#define USBPHY_SINKONDP (1 << 5)
> +#define USBPHY_CHGISINK_EN (1 << 6)
> +#define USBPHY_CHGVSRC_EN (1 << 7)
> +#define USBPHY_DMPULLUP (1 << 8)
> +#define USBPHY_DPPULLUP (1 << 9)
> +#define USBPHY_CDET_EXTCTL (1 << 10)
> +#define USBPHY_GPIO_MODE (1 << 12)
> +#define USBPHY_DPOPBUFCTL (1 << 13)
> +#define USBPHY_DMOPBUFCTL (1 << 14)
> +#define USBPHY_DPINPUT (1 << 15)
> +#define USBPHY_DMINPUT (1 << 16)
> +#define USBPHY_DPGPIO_PD (1 << 17)
> +#define USBPHY_DMGPIO_PD (1 << 18)
> +#define USBPHY_OTGVDET_EN (1 << 19)
> +#define USBPHY_OTGSESSEND_EN (1 << 20)
> +#define USBPHY_DATA_POLARITY (1 << 23)
> +
> +struct usbhs_omap_board_data {
> + enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
> +
> + /* have to be valid if phy_reset is true and portx is in phy mode */
> + int reset_gpio_port[OMAP3_HS_USB_PORTS];
> +
> + /* Set this to true for ES2.x silicon */
> + unsigned es2_compatibility:1;
> +
> + unsigned phy_reset:1;
> +
> + /*
> + * Regulators for USB PHYs.
> + * Each PHY can have a separate regulator.
> + */
> + struct regulator *regulator[OMAP3_HS_USB_PORTS];
> +};
> +
> +extern void usb_musb_init(struct omap_musb_board_data *board_data);
> +extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
> +
> +extern void am35x_musb_reset(void);
> +extern void am35x_musb_phy_power(u8 on);
> +extern void am35x_musb_clear_irq(void);
> +extern void am35x_set_mode(u8 musb_mode);
> +extern void ti81xx_musb_phy_power(u8 on);
> +
> diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
> index 87ee140..1dd6522 100644
> --- a/arch/arm/plat-omap/include/plat/usb.h
> +++ b/arch/arm/plat-omap/include/plat/usb.h
> @@ -26,24 +26,6 @@ enum usbhs_omap_port_mode {
> OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
> };
>
> -struct usbhs_omap_board_data {
> - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
> -
> - /* have to be valid if phy_reset is true and portx is in phy mode */
> - int reset_gpio_port[OMAP3_HS_USB_PORTS];
> -
> - /* Set this to true for ES2.x silicon */
> - unsigned es2_compatibility:1;
> -
> - unsigned phy_reset:1;
> -
> - /*
> - * Regulators for USB PHYs.
> - * Each PHY can have a separate regulator.
> - */
> - struct regulator *regulator[OMAP3_HS_USB_PORTS];
> -};
> -
> #ifdef CONFIG_ARCH_OMAP2PLUS
>
> struct ehci_hcd_omap_platform_data {
> @@ -83,97 +65,9 @@ struct omap_musb_board_data {
>
> enum musb_interface {MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
>
> -extern void usb_musb_init(struct omap_musb_board_data *board_data);
> -
> -extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
> extern int omap_tll_enable(void);
> extern int omap_tll_disable(void);
>
> -extern int omap4430_phy_power(struct device *dev, int ID, int on);
> -extern int omap4430_phy_set_clk(struct device *dev, int on);
> -extern int omap4430_phy_init(struct device *dev);
> -extern int omap4430_phy_exit(struct device *dev);
> -extern int omap4430_phy_suspend(struct device *dev, int suspend);
> -
> -#endif
> -
> -extern void am35x_musb_reset(void);
> -extern void am35x_musb_phy_power(u8 on);
> -extern void am35x_musb_clear_irq(void);
> -extern void am35x_set_mode(u8 musb_mode);
> -extern void ti81xx_musb_phy_power(u8 on);
> -
> -/* AM35x */
> -/* USB 2.0 PHY Control */
> -#define CONF2_PHY_GPIOMODE (1 << 23)
> -#define CONF2_OTGMODE (3 << 14)
> -#define CONF2_NO_OVERRIDE (0 << 14)
> -#define CONF2_FORCE_HOST (1 << 14)
> -#define CONF2_FORCE_DEVICE (2 << 14)
> -#define CONF2_FORCE_HOST_VBUS_LOW (3 << 14)
> -#define CONF2_SESENDEN (1 << 13)
> -#define CONF2_VBDTCTEN (1 << 12)
> -#define CONF2_REFFREQ_24MHZ (2 << 8)
> -#define CONF2_REFFREQ_26MHZ (7 << 8)
> -#define CONF2_REFFREQ_13MHZ (6 << 8)
> -#define CONF2_REFFREQ (0xf << 8)
> -#define CONF2_PHYCLKGD (1 << 7)
> -#define CONF2_VBUSSENSE (1 << 6)
> -#define CONF2_PHY_PLLON (1 << 5)
> -#define CONF2_RESET (1 << 4)
> -#define CONF2_PHYPWRDN (1 << 3)
> -#define CONF2_OTGPWRDN (1 << 2)
> -#define CONF2_DATPOL (1 << 1)
> -
> -/* TI81XX specific definitions */
> -#define USBCTRL0 0x620
> -#define USBSTAT0 0x624
> -
> -/* TI816X PHY controls bits */
> -#define TI816X_USBPHY0_NORMAL_MODE (1 << 0)
> -#define TI816X_USBPHY_REFCLK_OSC (1 << 8)
> -
> -/* TI814X PHY controls bits */
> -#define USBPHY_CM_PWRDN (1 << 0)
> -#define USBPHY_OTG_PWRDN (1 << 1)
> -#define USBPHY_CHGDET_DIS (1 << 2)
> -#define USBPHY_CHGDET_RSTRT (1 << 3)
> -#define USBPHY_SRCONDM (1 << 4)
> -#define USBPHY_SINKONDP (1 << 5)
> -#define USBPHY_CHGISINK_EN (1 << 6)
> -#define USBPHY_CHGVSRC_EN (1 << 7)
> -#define USBPHY_DMPULLUP (1 << 8)
> -#define USBPHY_DPPULLUP (1 << 9)
> -#define USBPHY_CDET_EXTCTL (1 << 10)
> -#define USBPHY_GPIO_MODE (1 << 12)
> -#define USBPHY_DPOPBUFCTL (1 << 13)
> -#define USBPHY_DMOPBUFCTL (1 << 14)
> -#define USBPHY_DPINPUT (1 << 15)
> -#define USBPHY_DMINPUT (1 << 16)
> -#define USBPHY_DPGPIO_PD (1 << 17)
> -#define USBPHY_DMGPIO_PD (1 << 18)
> -#define USBPHY_OTGVDET_EN (1 << 19)
> -#define USBPHY_OTGSESSEND_EN (1 << 20)
> -#define USBPHY_DATA_POLARITY (1 << 23)
> -
> -#if defined(CONFIG_ARCH_OMAP1) && defined(CONFIG_USB)
> -u32 omap1_usb0_init(unsigned nwires, unsigned is_device);
> -u32 omap1_usb1_init(unsigned nwires);
> -u32 omap1_usb2_init(unsigned nwires, unsigned alt_pingroup);
> -#else
> -static inline u32 omap1_usb0_init(unsigned nwires, unsigned is_device)
> -{
> - return 0;
> -}
> -static inline u32 omap1_usb1_init(unsigned nwires)
> -{
> - return 0;
> -
> -}
> -static inline u32 omap1_usb2_init(unsigned nwires, unsigned alt_pingroup)
> -{
> - return 0;
> -}
> #endif
>
> #endif /* __ASM_ARCH_OMAP_USB_H */
>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121019/8ba85a4b/attachment.sig>
^ permalink raw reply
* [PATCH 0/8] Convert Ux500 to SPARSE_IRQ
From: Arnd Bergmann @ 2012-10-19 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350580695-8303-1-git-send-email-linus.walleij@stericsson.com>
On Thursday 18 October 2012, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This patch series fixes the prerequisites and then converts Ux500
> to SPARSE_IRQ.
Great stuff! In case any patches end up going through other trees,
please add my
Acked-by: Arnd Bergmann <arnd@arndb.de>
> After this series I tried turning on multiplatform for ux500
> but there are still headers in <mach/*> creating problems
> so we are still just halfway.
Which ones are still left? This is the list of inclusions I saw
in the 3.6-rc1 version of my multiplatform branch being included
from outside of the mach-ux500 directory.
I should probably redo that branch to see which ones are gone now,
but you would also catch most of these with a simple defconfig build.
3 include <mach-ux500/board-mop500-msp.h>
2 include <mach-ux500/crypto-ux500.h>
1 include <mach-ux500/db8500-regs.h>
1 include <mach-ux500/gpio.h>
8 include <mach-ux500/hardware.h>
3 include <mach-ux500/id.h>
3 include <mach-ux500/irqs.h>
1 include <mach-ux500/setup.h>
1 include <mach-ux500/usb.h>
Arnd
^ permalink raw reply
* [PATCH] ARM: imx6q: let users input debug uart port number
From: Dirk Behme @ 2012-10-19 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349676394-25704-1-git-send-email-shawn.guo@linaro.org>
On 08.10.2012 08:06, Shawn Guo wrote:
> imx6q gets 5 uart ports in total. Different board design may choose
> different port as debug uart. For example, imx6q-sabresd uses UART1,
> imx6q-sabrelite uses UART2 and imx6q-arm2 uses UART4. Rather than
> bloating DEBUG_LL choice list with all these uart ports, the patch
> introduces DEBUG_IMX6Q_UART_PORT for users to input uart port number
> when DEBUG_IMX6Q_UART is selected inside DEBUG_LL choice.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Sounds like a good idea :)
Thanks
Dirk
> ---
> arch/arm/Kconfig.debug | 26 +++++++++++++-------------
> arch/arm/include/debug/imx.S | 20 ++++++++++++++++----
> arch/arm/mach-imx/lluart.c | 28 ++++++++++++++++++----------
> arch/arm/mach-imx/mx6q.h | 4 ----
> 4 files changed, 47 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 5566520..5dc7109 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -209,20 +209,12 @@ choice
> Say Y here if you want kernel low-level debugging support
> on i.MX50 or i.MX53.
>
> - config DEBUG_IMX6Q_UART2
> - bool "i.MX6Q Debug UART2"
> + config DEBUG_IMX6Q_UART
> + bool "i.MX6Q Debug UART"
> depends on SOC_IMX6Q
> help
> Say Y here if you want kernel low-level debugging support
> - on i.MX6Q UART2. This is correct for e.g. the SabreLite
> - board.
> -
> - config DEBUG_IMX6Q_UART4
> - bool "i.MX6Q Debug UART4"
> - depends on SOC_IMX6Q
> - help
> - Say Y here if you want kernel low-level debugging support
> - on i.MX6Q UART4.
> + on i.MX6Q.
>
> config DEBUG_MMP_UART2
> bool "Kernel low-level debugging message via MMP UART2"
> @@ -409,6 +401,15 @@ choice
>
> endchoice
>
> +config DEBUG_IMX6Q_UART_PORT
> + int "i.MX6Q Debug UART Port (1-5)" if DEBUG_IMX6Q_UART
> + range 1 5
> + default 1
> + depends on SOC_IMX6Q
> + help
> + Choose UART port on which kernel low-level debug messages
> + should be output.
> +
> config DEBUG_LL_INCLUDE
> string
> default "debug/icedcc.S" if DEBUG_ICEDCC
> @@ -418,8 +419,7 @@ config DEBUG_LL_INCLUDE
> DEBUG_IMX31_IMX35_UART || \
> DEBUG_IMX51_UART || \
> DEBUG_IMX50_IMX53_UART ||\
> - DEBUG_IMX6Q_UART2 || \
> - DEBUG_IMX6Q_UART4
> + DEBUG_IMX6Q_UART
> default "debug/highbank.S" if DEBUG_HIGHBANK_UART
> default "debug/mvebu.S" if DEBUG_MVEBU_UART
> default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
> diff --git a/arch/arm/include/debug/imx.S b/arch/arm/include/debug/imx.S
> index 0b65d79..0c4e17d 100644
> --- a/arch/arm/include/debug/imx.S
> +++ b/arch/arm/include/debug/imx.S
> @@ -10,6 +10,20 @@
> * published by the Free Software Foundation.
> *
> */
> +#define IMX6Q_UART1_BASE_ADDR 0x02020000
> +#define IMX6Q_UART2_BASE_ADDR 0x021e8000
> +#define IMX6Q_UART3_BASE_ADDR 0x021ec000
> +#define IMX6Q_UART4_BASE_ADDR 0x021f0000
> +#define IMX6Q_UART5_BASE_ADDR 0x021f4000
> +
> +/*
> + * IMX6Q_UART_BASE_ADDR is put in the middle to force the expansion
> + * of IMX6Q_UART##n##_BASE_ADDR.
> + */
> +#define IMX6Q_UART_BASE_ADDR(n) IMX6Q_UART##n##_BASE_ADDR
> +#define IMX6Q_UART_BASE(n) IMX6Q_UART_BASE_ADDR(n)
> +#define IMX6Q_DEBUG_UART_BASE IMX6Q_UART_BASE(CONFIG_DEBUG_IMX6Q_UART_PORT)
> +
> #ifdef CONFIG_DEBUG_IMX1_UART
> #define UART_PADDR 0x00206000
> #elif defined (CONFIG_DEBUG_IMX25_UART)
> @@ -22,10 +36,8 @@
> #define UART_PADDR 0x73fbc000
> #elif defined (CONFIG_DEBUG_IMX50_IMX53_UART)
> #define UART_PADDR 0x53fbc000
> -#elif defined (CONFIG_DEBUG_IMX6Q_UART2)
> -#define UART_PADDR 0x021e8000
> -#elif defined (CONFIG_DEBUG_IMX6Q_UART4)
> -#define UART_PADDR 0x021f0000
> +#elif defined (CONFIG_DEBUG_IMX6Q_UART)
> +#define UART_PADDR IMX6Q_DEBUG_UART_BASE
> #endif
>
> /*
> diff --git a/arch/arm/mach-imx/lluart.c b/arch/arm/mach-imx/lluart.c
> index 5f15103..2fdc9bf 100644
> --- a/arch/arm/mach-imx/lluart.c
> +++ b/arch/arm/mach-imx/lluart.c
> @@ -17,17 +17,25 @@
>
> #include "hardware.h"
>
> +#define IMX6Q_UART1_BASE_ADDR 0x02020000
> +#define IMX6Q_UART2_BASE_ADDR 0x021e8000
> +#define IMX6Q_UART3_BASE_ADDR 0x021ec000
> +#define IMX6Q_UART4_BASE_ADDR 0x021f0000
> +#define IMX6Q_UART5_BASE_ADDR 0x021f4000
> +
> +/*
> + * IMX6Q_UART_BASE_ADDR is put in the middle to force the expansion
> + * of IMX6Q_UART##n##_BASE_ADDR.
> + */
> +#define IMX6Q_UART_BASE_ADDR(n) IMX6Q_UART##n##_BASE_ADDR
> +#define IMX6Q_UART_BASE(n) IMX6Q_UART_BASE_ADDR(n)
> +#define IMX6Q_DEBUG_UART_BASE IMX6Q_UART_BASE(CONFIG_DEBUG_IMX6Q_UART_PORT)
> +
> static struct map_desc imx_lluart_desc = {
> -#ifdef CONFIG_DEBUG_IMX6Q_UART2
> - .virtual = MX6Q_IO_P2V(MX6Q_UART2_BASE_ADDR),
> - .pfn = __phys_to_pfn(MX6Q_UART2_BASE_ADDR),
> - .length = MX6Q_UART2_SIZE,
> - .type = MT_DEVICE,
> -#endif
> -#ifdef CONFIG_DEBUG_IMX6Q_UART4
> - .virtual = MX6Q_IO_P2V(MX6Q_UART4_BASE_ADDR),
> - .pfn = __phys_to_pfn(MX6Q_UART4_BASE_ADDR),
> - .length = MX6Q_UART4_SIZE,
> +#ifdef CONFIG_DEBUG_IMX6Q_UART
> + .virtual = IMX_IO_P2V(IMX6Q_DEBUG_UART_BASE),
> + .pfn = __phys_to_pfn(IMX6Q_DEBUG_UART_BASE),
> + .length = 0x4000,
> .type = MT_DEVICE,
> #endif
> };
> diff --git a/arch/arm/mach-imx/mx6q.h b/arch/arm/mach-imx/mx6q.h
> index f7e7dba..19d3f54 100644
> --- a/arch/arm/mach-imx/mx6q.h
> +++ b/arch/arm/mach-imx/mx6q.h
> @@ -27,9 +27,5 @@
> #define MX6Q_CCM_SIZE 0x4000
> #define MX6Q_ANATOP_BASE_ADDR 0x020c8000
> #define MX6Q_ANATOP_SIZE 0x1000
> -#define MX6Q_UART2_BASE_ADDR 0x021e8000
> -#define MX6Q_UART2_SIZE 0x4000
> -#define MX6Q_UART4_BASE_ADDR 0x021f0000
> -#define MX6Q_UART4_SIZE 0x4000
>
> #endif /* __MACH_MX6Q_H__ */
^ permalink raw reply
* Changing sd card data bits on the clock falling edge
From: Marco Lazzaroni @ 2012-10-19 8:03 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm using kernel 3.6 on a i.MX23 processor.
I was able to enable and use a second SD Card by using interface SSP2 (I
boot from a SD Card on SSP1).
The short story is, I need to keep BM_SSP_CTRL1_POLARITY bit in
HW_SSP_CTRL1 register to a 1 value, while now it is initialized at 1,
but after that it changes to 0.
How do I accomplish this?
Here I explain why I need this behaviour.
The SD Card is correctly recognised, (kern.log tells that I have a
1.84GB card in it is correct), but then I'm having some communication errors
[...]
Oct 18 19:19:30 debian kernel: [ 527.800000] mmcblk1: error -84
transferring data, sector 0, nr 8, cmd response 0x900, card status 0x800b00
Oct 18 19:19:30 debian kernel: [ 527.810000] mmcblk1: retrying using
single block read
Oct 18 19:19:30 debian kernel: [ 527.820000] mmcblk1: error -84
transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.830000] end_request: I/O error,
dev mmcblk1, sector 0
Oct 18 19:19:30 debian kernel: [ 527.840000] mmcblk1: error -84
transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.840000] end_request: I/O error,
dev mmcblk1, sector 1
Oct 18 19:19:30 debian kernel: [ 527.850000] mmcblk1: error -84
transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.860000] end_request: I/O error,
dev mmcblk1, sector 2
Oct 18 19:19:30 debian kernel: [ 527.870000] mmcblk1: error -84
transferring data, sector 3, nr 5, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.880000] end_request: I/O error,
dev mmcblk1, sector 3
Oct 18 19:19:30 debian kernel: [ 527.900000] mmcblk1: error -84
transferring data, sector 4, nr 4, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.910000] end_request: I/O error,
dev mmcblk1, sector 4
Oct 18 19:19:30 debian kernel: [ 527.940000] mmcblk1: error -84
transferring data, sector 5, nr 3, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.950000] end_request: I/O error,
dev mmcblk1, sector 5
Oct 18 19:19:30 debian kernel: [ 527.960000] mmcblk1: error -84
transferring data, sector 6, nr 2, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.960000] end_request: I/O error,
dev mmcblk1, sector 6
Oct 18 19:19:30 debian kernel: [ 527.980000] mmcblk1: error -84
transferring data, sector 7, nr 1, cmd response 0x900, card status 0x0
Oct 18 19:19:30 debian kernel: [ 527.990000] end_request: I/O error,
dev mmcblk1, sector 7
Oct 18 19:19:30 debian kernel: [ 527.990000] quiet_error: 13 callbacks
suppressed
Oct 18 19:19:30 debian kernel: [ 528.000000] Buffer I/O error on device
mmcblk1, logical block 0
Oct 18 19:19:30 debian kernel: [ 528.020000] mmcblk1: error -110
sending stop command, original cmd response 0x900, card status 0x800b00
[...]
Here is some facts:
- if I'm right, SD standard says that data bits are sampled on the
rising edge of the clock signal, and must be valid for at least 2.5ns
after that.
- in mxs-mmc.c, I see that BM_SSP_CTRL1_POLARITY bit in HW_SSP_CTRL1
register is set in function mxs_mmc_reset -> this means data changes
after falling edge (this information is contained in the imx23 datasheet
p1042 -> http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf
<http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf> )
- with an oscilloscope I see that data bits correctly change after
falling in edge during the first communications (the phase at 400 kHz clock)
- I see also that after this, when clock switches to high speed (default
is 50MHz, but I slowed down because of hardware problems to 1 MHz), data
bits change after rising edge
- in fact if I printk out HW_SSP_CTRL1, I see that BM_SSP_CTRL1_POLARITY
is reset (-> data changes after rising edge).
The outcome is that even if I slow down to 1 MHz, I can't correctly read
the content of the SD card. Looking at the oscilloscope if I measure
signals near the SD Card I see that the clock rising edge is a little
late, so the SD Card sees that bits changing when they're sampled.
I think that doing changes after the rising edge while in high speed is
the correct thing, so there's enough time for data bits to settle.
Anyway, because of my hardware problems (SD Card is 50 cm away from the
CPU), slowing down the card to 1MHz does not improve things because data
are changed so close to the time at which they're sampled. Signals and
good and squared, with no ringings, but that little time shift throws me
in trouble).
I would need to keep the BM_SSP_CTRL1_POLARITY bit to 1 even in high
speed, so data bits change on the falling edge; data bits have all the
time to settle before the arriving of the rising edge since the clock is
as slow as 1MHz.
But I don't know how to keep this bit at 1.
There's only a reference in mxs-mmc.c to BM_SSP_CTRL1_POLARITY, when it
is set to 1, so I can't figure where it gets changed and set to 0.
Any help is appreciated. Thank you very much in advance.
Best regards,
Marco Lazzaroni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121019/136c5ec0/attachment-0001.html>
^ permalink raw reply
* Question about move atmel audio part to DT support
From: Bo Shen @ 2012-10-19 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5080F54F.4000600@atmel.com>
Cc:
linux-arm-kernel mailing list
devicetree-discuss mailing list
alsa-devel mailing list
linux-sound mailing list
On 10/19/2012 14:38, Bo Shen wrote:
> Hi Mark Brown,
> Now, I am trying to move atmel audio part to DT support. I meet the
> following issue.
>
> Atmel audio part has three platform device:
> -> atmel ssc: ssc library (different SOC has different number)
> -> atmel ssc dai: dai for audio
> -> atmel pcm: for pdc or dma transfer (now only support pdc, dma
> support will add soon)
>
> In DT support kernel, I don't find any similar case. So, if I want to
> keep ssc as library, and use dai to register pcm. Then the dts file will
> like:
> ---<8---
> ssc0: ssc at fffbc000 {
> status = "okay";
> };
>
> dai0: dai {
> compatible = "atmel,atmel-ssc-dai";
> };
>
> sound {
> compatible = "atmel,at91sam9g20-audio";
> atmel,model = "wm8731 @ sam9g20ek";
>
> atmel,audio-routing =
> "Ext Spk", "LHPOUT",
> "Int Mic", "MICIN";
>
> atmel,audio-codec = <&wm8731>;
> atmel,dai = <&dai>;
> };
> --->8---
>
> Would this be OK?
> If not, may I add some code for ssc which dedicate for audio into
> sound/soc/atmel (using audio-ssc and ssc to distiguish which dedicate
> for audio, which used for ssc library)? This will broken the exist code
> for audio (only sam9g20-wm8731).
> Any suggestion?
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC defconfig for v3.8
From: Arnd Bergmann @ 2012-10-19 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019030917.GA6644@verge.net.au>
On Friday 19 October 2012, Simon Horman wrote:
> On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> I have made a limited amount of progress on this trying to create a
> defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
>
> * Serial console appears to work, although for the Marzen at
> least enabling earlyprintk seems to require the bootloader to specify
> e.g. console=ttySC2,115200 earlyprintk
>
> This is done by fully specifying bootargs in U-Boot.
> The boodloaders on the Marzen board has an ampty bootargs by default.
>
> I guess I can live without earlyprink by default,
> though it does seem to be a regression in the user experience.
Right. So who is using the defconfig for these boards? Usually most
people using it actually have their own configuration files that are
tuned for their needs, and you often also need to change the command
line in order to configure the root partition etc.
> * A more significant problem seems to be the use of CONFIG_MEMORY_START
> to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
>
> I'm not sure that I see an easy way to get around this one.
ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
Arnd
^ permalink raw reply
* [PATCH v2] arm/dts: AM33XX: Add SPI device tree data
From: Benoit Cousson @ 2012-10-19 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347946228-25874-1-git-send-email-avinashphilip@ti.com>
Hi Avinash,
This look good to me except the: status = "disabled".
The "disabled" should be reserved for variant that does not contain the IP.
Is it the case here?
Regards,
Benoit
On 09/18/2012 07:30 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash <avinashphilip@ti.com>
> Tested-by: Matt Porter <mporter@ti.com>
> ---
> Changes since v1:
> - Corrected reg offset in reg DT entry.
>
> :100644 100644 ff3badb... 065fd54... M arch/arm/boot/dts/am33xx.dtsi
> arch/arm/boot/dts/am33xx.dtsi | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index ff3badb..065fd54 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -219,5 +219,30 @@
> interrupt-parent = <&intc>;
> interrupts = <91>;
> };
> +
> + spi0: spi at 48030000 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x48030000 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <65>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi0";
> + status = "disabled";
> +
> + };
> +
> + spi1: spi at 481a0000 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x481a0000 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <125>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi1";
> + status = "disabled";
> + };
> };
> };
>
^ permalink raw reply
* [PATCH 1/2] spi: spidev: Add device tree bindings
From: Shawn Guo @ 2012-10-19 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350568768-4374-2-git-send-email-maxime.ripard@free-electrons.com>
Mark is maintaining spi subsystem recently as Grant has been off line
for a while.
Shawn
On Thu, Oct 18, 2012 at 03:59:27PM +0200, Maxime Ripard wrote:
> This will allow to probe spidev from device tree
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/spi/spidev.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
> index 830adbe..8ae0660 100644
> --- a/drivers/spi/spidev.c
> +++ b/drivers/spi/spidev.c
> @@ -31,6 +31,8 @@
> #include <linux/mutex.h>
> #include <linux/slab.h>
> #include <linux/compat.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
>
> #include <linux/spi/spi.h>
> #include <linux/spi/spidev.h>
> @@ -642,10 +644,18 @@ static int __devexit spidev_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id spidev_dt_ids[] = {
> + { .compatible = "linux,spidev" },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, spidev_dt_ids);
> +
> static struct spi_driver spidev_spi_driver = {
> .driver = {
> .name = "spidev",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(spidev_dt_ids),
> },
> .probe = spidev_probe,
> .remove = __devexit_p(spidev_remove),
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v3] ARM: mxs: Add support for the Armadeus Systems APF28 module
From: Shawn Guo @ 2012-10-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350553826-28057-1-git-send-email-julien.boibessot@free.fr>
On Thu, Oct 18, 2012 at 11:50:26AM +0200, julien.boibessot at free.fr wrote:
> From: Julien Boibessot <julien.boibessot@armadeus.com>
>
> The APF28 is a small SOM built around an i.MX28 processor with 128MBytes DDR2,
> 256MBytes NAND Flash and an Ethernet PHY.
>
> Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
Applied, thanks.
^ 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