* [PATCH 2/2] Input: nomadik-ske-keypad - start using the apb_pclk
From: Ulf Hansson @ 2012-11-05 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbZB4nhFQtLH-GxBSK99RFk7yhSYMhO5keVjyugrqr7JA@mail.gmail.com>
On 4 November 2012 19:12, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Nov 1, 2012 at 3:20 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Previously this clock was handled internally by the clockdriver,
>> but now this is separate clk. So we need take care of it.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> So this is a silicon block clock and falls into the category of things
> we've been discussing...
>
> If I understand correctly, the only "real" solution is to
> implement the PM domains and have these enable the clocks.
Agree.
Although, since the pm_domain not yet exist, this as a way forward for
now - to fix what is broken.
When the pm_domain is in place and when we decide to fold in the clock
handling in there, we can move it.
>
> An alternative may be to move this driver over to the AMBA bus,
> because I think this device actually has primecell registers.
> Then the bus will take care of the pclk for starters.
You are definitely right, this driver can be converted into using the AMBA bus.
Although, do you think that should be done _instead_ of going ahead
with this patch or do you want that to be handled as a next and a
separate step?
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH 5/8] ARM: zynq: add COMMON_CLK support
From: Michal Simek @ 2012-11-05 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102152826.GQ5190@beefymiracle.amer.corp.natinst.com>
2012/11/2 Josh Cartwright <josh.cartwright@ni.com>:
> On Fri, Nov 02, 2012 at 04:12:21PM +0100, Lars-Peter Clausen wrote:
>> On 11/02/2012 02:38 PM, Josh Cartwright wrote:
>> > On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
>> >> On 10/31/2012 07:58 PM, Josh Cartwright wrote:
> [...]
>> >>> +static void __init zynq_periph_clk_setup(struct device_node *np)
>> >>> +{
>> >>> + struct zynq_periph_clk *periph;
>> >>> + const char *parent_names[3];
>> >>> + struct clk_init_data init;
>> >>> + struct clk *clk;
>> >>> + int err;
>> >>> + u32 reg;
>> >>> + int i;
>> >>> +
>> >>> + err = of_property_read_u32(np, "reg", ®);
>> >>> + WARN_ON(err);
>> >>
>> >> Shouldn't the function abort if a error happens somewhere? Continuing here
>> >> will lead to undefined behavior. Same is probably true for the other WARN_ONs.
>> >
>> > The way I see it is: the kernel is will be left in a bad state in the
>> > case of any failure, regardless of if we bail out or continue. AFAICT,
>> > there is no clean way to recover from a failure this early.
>> >
>> > Given that, it seems simpler (albeit marginally so) just to continue; so
>> > that's what I chose to do. I'm not opposed to bailing out, just not
>> > convinced it does anything for us.
>> >
>> The issue with this approach is that, while you get a warning, unexpected
>> seemingly unrelated side-effects may happen later on. E.g. if no reg
>> property for the clock is specified the reg variable will be uninitialized
>> and contain whatever was on the stack before. The clock will be registered
>> nonetheless and the boot process continues. Now if the clock is enabled a
>> bit in a random register will be modified, which could result in strange and
>> abnormal behavior, which can be very hard to track down.
>
> Okay.....but any reasonable person would start their debugging quest at
> the source of the WARN_ON. If someone sees the WARN_ON message but
> stupidly chooses to ignore it, they deserves to spend the time trying to
> track down abnormal behavior, so I'm still not convinced.
I am with Lars. You would be surprised how many people do no read bootlog.
It should be handled better.
Thanks,
Michal
^ permalink raw reply
* [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Ulf Hansson @ 2012-11-05 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121028225918.GC5411@sortiz-mobl>
On 28 October 2012 23:59, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Hi Ulf,
>
> On Fri, Oct 26, 2012 at 10:19:24AM +0200, Ulf Hansson wrote:
>> On 11 October 2012 17:19, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Thu, 11 Oct 2012, Linus Walleij wrote:
>> >
>> >> On Thu, Oct 11, 2012 at 3:44 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> >>
>> >> >> Patches are based on Linus Torvalds tree with latest commit as of okt 10.
>> >> >
>> >> > Hmm... I get:
>> >> >
>> >> > Applying: clk: ux500: Support for prcmu_scalable_rate clock
>> >> > error: drivers/clk/ux500/clk-prcmu.c: does not exist in index
>> >> > error: drivers/clk/ux500/clk.h: does not exist in index
>> >> > Patch failed at 0001 clk: ux500: Support for prcmu_scalable_rate clock
>> >> >
>> >> > So when did drivers/clk/ux500/* arrive?
>> >>
>> >> Exactly here, 10 days ago on Torvalds' master branch:
>> >
>> > Ah I see. Basing patches on commits half way through the merge
>> > window. Good move! ;)
>> >
>> > --
>> > Lee Jones
>> > Linaro ST-Ericsson Landing Team Lead
>> > Linaro.org ? Open source software for ARM SoCs
>> > Follow Linaro: Facebook | Twitter | Blog
>>
>> Samuel, a kind reminder on this, trying to collect acks to be able to
>> advise Mike to take this series through his clk tree. There are two
>> mfd patches.
>> [PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
>> [PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
> Sorry for the delay:
>
> Acked-by: Samuel Ortiz <sameo@linux.intel.com>
>
> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
A kind ping for this this series for you Mike. I believe all patches
has received acks now as well.
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH 2/2] Input: nomadik-ske-keypad - start using the apb_pclk
From: Linus Walleij @ 2012-11-05 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpjdVMCuBdN-O+xxK=Dko-GTEjF5AYOeEMgWghJfB8EsA@mail.gmail.com>
On Mon, Nov 5, 2012 at 1:25 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 4 November 2012 19:12, Linus Walleij <linus.walleij@linaro.org> wrote:
>> If I understand correctly, the only "real" solution is to
>> implement the PM domains and have these enable the clocks.
>
> Agree.
>
> Although, since the pm_domain not yet exist, this as a way forward for
> now - to fix what is broken.
True. Fixing regressions is more important.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
> When the pm_domain is in place and when we decide to fold in the clock
> handling in there, we can move it.
OK for me.
>> An alternative may be to move this driver over to the AMBA bus,
>> because I think this device actually has primecell registers.
>> Then the bus will take care of the pclk for starters.
>
> You are definitely right, this driver can be converted into using the AMBA bus.
> Although, do you think that should be done _instead_ of going ahead
> with this patch or do you want that to be handled as a next and a
> separate step?
No, just a suggestion of possibilities...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/2] Pinctrl muxing for the Crystalfontz boards
From: Maxime Ripard @ 2012-11-05 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105032057.GC26528@S2100-06.ap.freescale.net>
Le 05/11/2012 04:20, Shawn Guo a ?crit :
> On Sat, Nov 03, 2012 at 04:59:06PM +0100, Maxime Ripard wrote:
>> Hi all,
>>
>> This patch serie add the hogpins to explicitly mux the GPIOs used
>> across the device tree as such for the two Crystalfontz boards, and
>> make the gpio-led driver use pinctrl.
>>
>> This serie goes on top of the i2c-mux-gpios patches I sent on this
>> list.
>
> I do not see that dependency at all, so just applied both patches.
Well, some of the pins muxed are for the muxer, thus the dependency,
but, after all, it will just work.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm/crypto: Make asm SHA-1 and AES code Thumb-2 compatible
From: Dave Martin @ 2012-11-05 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030100742.17910.70241.stgit@localhost6.localdomain6>
This patch fixes aes-armv4.S and sha1-armv4-large.S to work
natively in Thumb. This allows ARM/Thumb interworking workarounds
to be removed.
I also take the opportunity to convert some explicit assembler
directives for exported functions to the standard
ENTRY()/ENDPROC().
For the code itself:
* In sha1_block_data_order, use of TEQ with sp is deprecated in
ARMv7 and not supported in Thumb. For the branches back to
.L_00_15 and .L_40_59, the TEQ is converted to a CMP, under the
assumption that clobbering the C flag here will not cause
incorrect behaviour.
For the first branch back to .L_20_39_or_60_79 the C flag is
important, so sp is moved temporarily into another register so
that TEQ can be used for the comparison.
* In the AES code, most forms of register-indexed addressing with
shifts and rotates are not permitted for loads and stores in
Thumb, so the address calculation is done using a separate
instruction for the Thumb case.
The resulting code is unlikely to be optimally scheduled, but
it should not have a large impact given the overall size of the
code. I haven't run any benchmarks.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
For now, I have built the code but not tested it. I'll consider the
patch an RFC until someone gives me a Tested-by (or failing that, when I
get around to testing it myself...)
Cheers
---Dave
arch/arm/crypto/aes-armv4.S | 64 +++++++++++------------------------
arch/arm/crypto/sha1-armv4-large.S | 24 +++++--------
2 files changed, 29 insertions(+), 59 deletions(-)
diff --git a/arch/arm/crypto/aes-armv4.S b/arch/arm/crypto/aes-armv4.S
index e59b1d5..19d6cd6 100644
--- a/arch/arm/crypto/aes-armv4.S
+++ b/arch/arm/crypto/aes-armv4.S
@@ -34,8 +34,9 @@
@ A little glue here to select the correct code below for the ARM CPU
@ that is being targetted.
+#include <linux/linkage.h>
+
.text
-.code 32
.type AES_Te,%object
.align 5
@@ -145,10 +146,8 @@ AES_Te:
@ void AES_encrypt(const unsigned char *in, unsigned char *out,
@ const AES_KEY *key) {
-.global AES_encrypt
-.type AES_encrypt,%function
.align 5
-AES_encrypt:
+ENTRY(AES_encrypt)
sub r3,pc,#8 @ AES_encrypt
stmdb sp!,{r1,r4-r12,lr}
mov r12,r0 @ inp
@@ -239,15 +238,8 @@ AES_encrypt:
strb r6,[r12,#14]
strb r3,[r12,#15]
#endif
-#if __ARM_ARCH__>=5
ldmia sp!,{r4-r12,pc}
-#else
- ldmia sp!,{r4-r12,lr}
- tst lr,#1
- moveq pc,lr @ be binary compatible with V4, yet
- .word 0xe12fff1e @ interoperable with Thumb ISA:-)
-#endif
-.size AES_encrypt,.-AES_encrypt
+ENDPROC(AES_encrypt)
.type _armv4_AES_encrypt,%function
.align 2
@@ -386,10 +378,8 @@ _armv4_AES_encrypt:
ldr pc,[sp],#4 @ pop and return
.size _armv4_AES_encrypt,.-_armv4_AES_encrypt
-.global private_AES_set_encrypt_key
-.type private_AES_set_encrypt_key,%function
.align 5
-private_AES_set_encrypt_key:
+ENTRY(private_AES_set_encrypt_key)
_armv4_AES_set_encrypt_key:
sub r3,pc,#8 @ AES_set_encrypt_key
teq r0,#0
@@ -658,15 +648,11 @@ _armv4_AES_set_encrypt_key:
.Ldone: mov r0,#0
ldmia sp!,{r4-r12,lr}
-.Labrt: tst lr,#1
- moveq pc,lr @ be binary compatible with V4, yet
- .word 0xe12fff1e @ interoperable with Thumb ISA:-)
-.size private_AES_set_encrypt_key,.-private_AES_set_encrypt_key
+.Labrt: mov pc,lr
+ENDPROC(private_AES_set_encrypt_key)
-.global private_AES_set_decrypt_key
-.type private_AES_set_decrypt_key,%function
.align 5
-private_AES_set_decrypt_key:
+ENTRY(private_AES_set_decrypt_key)
str lr,[sp,#-4]! @ push lr
#if 0
@ kernel does both of these in setkey so optimise this bit out by
@@ -748,15 +734,8 @@ private_AES_set_decrypt_key:
bne .Lmix
mov r0,#0
-#if __ARM_ARCH__>=5
ldmia sp!,{r4-r12,pc}
-#else
- ldmia sp!,{r4-r12,lr}
- tst lr,#1
- moveq pc,lr @ be binary compatible with V4, yet
- .word 0xe12fff1e @ interoperable with Thumb ISA:-)
-#endif
-.size private_AES_set_decrypt_key,.-private_AES_set_decrypt_key
+ENDPROC(private_AES_set_decrypt_key)
.type AES_Td,%object
.align 5
@@ -862,10 +841,8 @@ AES_Td:
@ void AES_decrypt(const unsigned char *in, unsigned char *out,
@ const AES_KEY *key) {
-.global AES_decrypt
-.type AES_decrypt,%function
.align 5
-AES_decrypt:
+ENTRY(AES_decrypt)
sub r3,pc,#8 @ AES_decrypt
stmdb sp!,{r1,r4-r12,lr}
mov r12,r0 @ inp
@@ -956,15 +933,8 @@ AES_decrypt:
strb r6,[r12,#14]
strb r3,[r12,#15]
#endif
-#if __ARM_ARCH__>=5
ldmia sp!,{r4-r12,pc}
-#else
- ldmia sp!,{r4-r12,lr}
- tst lr,#1
- moveq pc,lr @ be binary compatible with V4, yet
- .word 0xe12fff1e @ interoperable with Thumb ISA:-)
-#endif
-.size AES_decrypt,.-AES_decrypt
+ENDPROC(AES_decrypt)
.type _armv4_AES_decrypt,%function
.align 2
@@ -1064,7 +1034,9 @@ _armv4_AES_decrypt:
and r9,lr,r1,lsr#8
ldrb r7,[r10,r7] @ Td4[s1>>0]
- ldrb r1,[r10,r1,lsr#24] @ Td4[s1>>24]
+ ARM( ldrb r1,[r10,r1,lsr#24] ) @ Td4[s1>>24]
+ THUMB( add r1,r10,r1,lsr#24 ) @ Td4[s1>>24]
+ THUMB( ldrb r1,[r1] )
ldrb r8,[r10,r8] @ Td4[s1>>16]
eor r0,r7,r0,lsl#24
ldrb r9,[r10,r9] @ Td4[s1>>8]
@@ -1077,7 +1049,9 @@ _armv4_AES_decrypt:
ldrb r8,[r10,r8] @ Td4[s2>>0]
and r9,lr,r2,lsr#16
- ldrb r2,[r10,r2,lsr#24] @ Td4[s2>>24]
+ ARM( ldrb r2,[r10,r2,lsr#24] ) @ Td4[s2>>24]
+ THUMB( add r2,r10,r2,lsr#24 ) @ Td4[s2>>24]
+ THUMB( ldrb r2,[r2] )
eor r0,r0,r7,lsl#8
ldrb r9,[r10,r9] @ Td4[s2>>16]
eor r1,r8,r1,lsl#16
@@ -1090,7 +1064,9 @@ _armv4_AES_decrypt:
and r9,lr,r3 @ i2
ldrb r9,[r10,r9] @ Td4[s3>>0]
- ldrb r3,[r10,r3,lsr#24] @ Td4[s3>>24]
+ ARM( ldrb r3,[r10,r3,lsr#24] ) @ Td4[s3>>24]
+ THUMB( add r3,r10,r3,lsr#24 ) @ Td4[s3>>24]
+ THUMB( ldrb r3,[r3] )
eor r0,r0,r7,lsl#16
ldr r7,[r11,#0]
eor r1,r1,r8,lsl#8
diff --git a/arch/arm/crypto/sha1-armv4-large.S b/arch/arm/crypto/sha1-armv4-large.S
index 7050ab1..92c6eed 100644
--- a/arch/arm/crypto/sha1-armv4-large.S
+++ b/arch/arm/crypto/sha1-armv4-large.S
@@ -51,13 +51,12 @@
@ Profiler-assisted and platform-specific optimization resulted in 10%
@ improvement on Cortex A8 core and 12.2 cycles per byte.
-.text
+#include <linux/linkage.h>
-.global sha1_block_data_order
-.type sha1_block_data_order,%function
+.text
.align 2
-sha1_block_data_order:
+ENTRY(sha1_block_data_order)
stmdb sp!,{r4-r12,lr}
add r2,r1,r2,lsl#6 @ r2 to point at the end of r1
ldmia r0,{r3,r4,r5,r6,r7}
@@ -194,7 +193,7 @@ sha1_block_data_order:
eor r10,r10,r7,ror#2 @ F_00_19(B,C,D)
str r9,[r14,#-4]!
add r3,r3,r10 @ E+=F_00_19(B,C,D)
- teq r14,sp
+ cmp r14,sp
bne .L_00_15 @ [((11+4)*5+2)*3]
#if __ARM_ARCH__<7
ldrb r10,[r1,#2]
@@ -374,7 +373,9 @@ sha1_block_data_order:
@ F_xx_xx
add r3,r3,r9 @ E+=X[i]
add r3,r3,r10 @ E+=F_20_39(B,C,D)
- teq r14,sp @ preserve carry
+ ARM( teq r14,sp ) @ preserve carry
+ THUMB( mov r11,sp )
+ THUMB( teq r14,r11 ) @ preserve carry
bne .L_20_39_or_60_79 @ [+((12+3)*5+2)*4]
bcs .L_done @ [+((12+3)*5+2)*4], spare 300 bytes
@@ -466,7 +467,7 @@ sha1_block_data_order:
add r3,r3,r9 @ E+=X[i]
add r3,r3,r10 @ E+=F_40_59(B,C,D)
add r3,r3,r11,ror#2
- teq r14,sp
+ cmp r14,sp
bne .L_40_59 @ [+((12+5)*5+2)*4]
ldr r8,.LK_60_79
@@ -485,19 +486,12 @@ sha1_block_data_order:
teq r1,r2
bne .Lloop @ [+18], total 1307
-#if __ARM_ARCH__>=5
ldmia sp!,{r4-r12,pc}
-#else
- ldmia sp!,{r4-r12,lr}
- tst lr,#1
- moveq pc,lr @ be binary compatible with V4, yet
- .word 0xe12fff1e @ interoperable with Thumb ISA:-)
-#endif
.align 2
.LK_00_19: .word 0x5a827999
.LK_20_39: .word 0x6ed9eba1
.LK_40_59: .word 0x8f1bbcdc
.LK_60_79: .word 0xca62c1d6
-.size sha1_block_data_order,.-sha1_block_data_order
+ENDPROC(sha1_block_data_order)
.asciz "SHA1 block transform for ARMv4, CRYPTOGAMS by <appro@openssl.org>"
.align 2
--
1.7.4.1
^ permalink raw reply related
* [PATCH V3 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
From: Lokesh Vutla @ 2012-11-05 12:52 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds Device tree data for the EMIF
sdram controllers in OMAP5 and LPDDR2 memory devices
in OMAP5-evm board.
Testing:
- Boot tested on OMAP5430 evm.
- Built EMIF as a module.
Changes from v2:
* Rebased on top of
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts
* Addressed few other comments from Benoit.
Lokesh Vutla (3):
ARM: dts: omap5-evm: Fix size of memory defined for EVM
ARM: dts: omap5: EMIF device tree data for OMAP5 boards
ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
arch/arm/boot/dts/omap5-evm.dts | 13 +++++-
arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 +++++++++++++++++++++++++++++
3 files changed, 101 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
--
1.7.9.5
^ permalink raw reply
* [PATCH V3 1/3] ARM: dts: omap5-evm: Fix size of memory defined for EVM
From: Lokesh Vutla @ 2012-11-05 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352119972-13710-1-git-send-email-lokeshvutla@ti.com>
Memory present for OMAP5-evm is 2GB. But in dts file
it is specified as 1GB. Correcting the same.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/omap5-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..88d3d9b8 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -15,7 +15,7 @@
memory {
device_type = "memory";
- reg = <0x80000000 0x40000000>; /* 1 GB */
+ reg = <0x80000000 0x80000000>; /* 2 GB */
};
vmmcsd_fixed: fixedregulator-mmcsd {
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
From: Lokesh Vutla @ 2012-11-05 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352119972-13710-1-git-send-email-lokeshvutla@ti.com>
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index ead74c8..790bb2a 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -474,5 +474,27 @@
ti,hwmods = "timer11";
ti,timer-pwm;
};
+
+ emif1: emif at 0x4c000000 {
+ compatible = "ti,emif-4d5";
+ ti,hwmods = "emif1";
+ phy-type = <2>; /* DDR PHY type: Intelli PHY */
+ reg = <0x4c000000 0x400>;
+ interrupts = <0 110 0x4>;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+ emif2: emif at 0x4d000000 {
+ compatible = "ti,emif-4d5";
+ ti,hwmods = "emif2";
+ phy-type = <2>; /* DDR PHY type: Intelli PHY */
+ reg = <0x4d000000 0x400>;
+ interrupts = <0 111 0x4>;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
From: Lokesh Vutla @ 2012-11-05 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352119972-13710-1-git-send-email-lokeshvutla@ti.com>
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/omap5-evm.dts | 11 +++++
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 +++++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 88d3d9b8..8722c15 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ "omap5.dtsi"
+/include/ "samsung_k3pe0e000b.dtsi"
/ {
model = "TI OMAP5 EVM board";
@@ -140,3 +141,13 @@
&mcbsp3 {
status = "disabled";
};
+
+&emif1 {
+ cs1-used;
+ device-handle = <&samsung_K3PE0E000B>;
+};
+
+&emif2 {
+ cs1-used;
+ device-handle = <&samsung_K3PE0E000B>;
+};
diff --git a/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
new file mode 100644
index 0000000..9657a5c
--- /dev/null
+++ b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Timings and Geometry for Samsung K3PE0E000B memory part
+ */
+
+/ {
+ samsung_K3PE0E000B: lpddr2 {
+ compatible = "Samsung,K3PE0E000B","jedec,lpddr2-s4";
+ density = <4096>;
+ io-width = <32>;
+
+ tRPab-min-tck = <3>;
+ tRCD-min-tck = <3>;
+ tWR-min-tck = <3>;
+ tRASmin-min-tck = <3>;
+ tRRD-min-tck = <2>;
+ tWTR-min-tck = <2>;
+ tXP-min-tck = <2>;
+ tRTP-min-tck = <2>;
+ tCKE-min-tck = <3>;
+ tCKESR-min-tck = <3>;
+ tFAW-min-tck = <8>;
+
+ timings_samsung_K3PE0E000B_533MHz: lpddr2-timings at 0 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq = <10000000>;
+ max-freq = <533333333>;
+ tRPab = <21000>;
+ tRCD = <18000>;
+ tWR = <15000>;
+ tRAS-min = <42000>;
+ tRRD = <10000>;
+ tWTR = <7500>;
+ tXP = <7500>;
+ tRTP = <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW = <50000>;
+ tZQCS = <90000>;
+ tZQCL = <360000>;
+ tZQinit = <1000000>;
+ tRAS-max-ns = <70000>;
+ tDQSCK-max-derated = <6000>;
+ };
+
+ timings_samsung_K3PE0E000B_266MHz: lpddr2-timings at 1 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq = <10000000>;
+ max-freq = <266666666>;
+ tRPab = <21000>;
+ tRCD = <18000>;
+ tWR = <15000>;
+ tRAS-min = <42000>;
+ tRRD = <10000>;
+ tWTR = <7500>;
+ tXP = <7500>;
+ tRTP = <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW = <50000>;
+ tZQCS = <90000>;
+ tZQCL = <360000>;
+ tZQinit = <1000000>;
+ tRAS-max-ns = <70000>;
+ tDQSCK-max-derated = <6000>;
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] leds: Add generic support for memory mapped LEDs
From: Pawel Moll @ 2012-11-05 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352108387.3212.12.camel@linaro1.home>
On Mon, 2012-11-05 at 09:39 +0000, Jon Medhurst (Tixy) wrote:
> > +static void mmio_led_brightness_set(struct led_classdev *cdev,
> > + enum led_brightness brightness)
> > +{
> > + struct mmio_led *led = container_of(cdev, struct mmio_led, cdev);
> > + unsigned long uninitialized_var(flags);
>
> uninitialized_var seems to be a bit contentious, Linus Torvalds had a
> recent complaint about it which prompted Ingo to post a patch proposing
> to removing it: https://patchwork.kernel.org/patch/1655621/ So perhaps
> best to avoid using it ;-).
>
> In this case, you could possibly keep gcc quite with something like:
>
> spinlock_t *lock = led->lock;
>
> and then use the local variable 'lock' everywhere instead of led->lock.
> Or just keep it simple an initialise flags to 0 instead.
Yeah, = 0 will do...
> > + if (!pdata)
> > + return -EINVAL;
> > +
> > + if (pdata->reg_size != 8 && pdata->reg_size != 16 &&
> > + pdata->reg_size != 32)
> > + return -EFAULT;
>
> Is EFAULT appropriate here? Why not EINVAL?
Hm. To distinguish it from !pdata case I guess (and a 13 bit wide
transaction sounds like a fault to me ;-), but I can be persuaded
otherwise without much effort...
Thanks!
Pawe?
^ permalink raw reply
* [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-11-05 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9DA81F@DBDE01.ent.ti.com>
On 05.11.2012 12:03, Philip, Avinash wrote:
> On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
>> This patch adds basic DT bindings for OMAP GPMC.
>>
>> The actual peripherals are instanciated from child nodes within the GPMC
>> node, and the only type of device that is currently supported is NAND.
>>
>> Code was added to parse the generic GPMC timing parameters and some
>> documentation with examples on how to use them.
>>
>> Successfully tested on an AM33xx board.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
> [...]
>> +
>> + nand at 0,0 {
>> + reg = <0 0 0>; /* CS0, offset 0 */
>> + nand-bus-width = <16>;
>> + nand-ecc-mode = "none";
>> +
>> + gpmc,sync-clk = <0>;
>> + gpmc,cs-on = <0>;
>> + gpmc,cs-rd-off = <36>;
>> + gpmc,cs-wr-off = <36>;
>> + gpmc,adv-on = <6>;
>> + gpmc,adv-rd-off = <24>;
>> + gpmc,adv-wr-off = <36>;
>> + gpmc,we-off = <30>;
>> + gpmc,oe-off = <48>;
>> + gpmc,access = <54>;
>> + gpmc,rd-cycle = <72>;
>> + gpmc,wr-cycle = <72>;
>> + gpmc,wr-access = <30>;
>> + gpmc,wr-data-mux-bus = <0>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>
> Can you take the timings (for example) from arago tree. The timings is tested in am335x-evm
> So the timings can be directly used to populate GPMC timings. Timings can found at
>
> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
> h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
>
> [...]
>> +static int gpmc_probe_dt(struct platform_device *pdev)
>
> Can you take care of the following section mismatch.
> WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
> from the function gpmc_probe_dt() to the function .init.text:gpmc_nand_init().
Sore, both fixed for v4.
> [...]
>> +
>> + val = of_get_nand_ecc_mode(child);
>> + if (val >= 0)
>> + gpmc_nand_data->ecc_opt = val;
>
> This will fail for BCH. Index of "soft_bch" is 5 & also don't have selection
> option between for BCH4 & BCH8 also.
> Can you use the of_property_read_u32 (as done early) to pass the ecc selection
> from dt file. This will help selection of BCH4 & BCH8 ecc options.
Hmm. Shouldn't we rather teach of_get_nand_ecc_mode() that two modes and
bring the enum in sync?
Daniel
^ permalink raw reply
* [PATCH 8/8] clocksource: xilinx_ttc: add OF_CLK support
From: Michal Simek @ 2012-11-05 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ea1ba71afb3f4551ac27a6dfa41bd97b63cef48.1351721190.git.josh.cartwright@ni.com>
2012/10/31 Josh Cartwright <josh.cartwright@ni.com>:
> Add support for retrieving TTC configuration from device tree. This
> includes the ability to pull information about the driving clocks from
> the of_clk bindings.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> arch/arm/boot/dts/zynq-7000.dtsi | 53 ++++++++
> arch/arm/boot/dts/zynq-zc702.dts | 10 ++
> drivers/clocksource/xilinx_ttc.c | 273 ++++++++++++++++++++++-----------------
> 3 files changed, 218 insertions(+), 118 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
> index 5fb763f..9a2442c 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -109,5 +109,58 @@
> };
> };
> };
> +
> + ttc0: ttc0 at f8001000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "xlnx,ttc";
> + reg = <0xF8001000 0x1000>;
> + clocks = <&cpu_clk 3>;
> + clock-names = "cpu_1x";
> + clock-ranges;
> +
> + ttc0_0: ttc0.0 {
> + status = "disabled";
> + reg = <0>;
> + interrupts = <0 10 4>;
> + };
> + ttc0_1: ttc0.1 {
> + status = "disabled";
> + reg = <1>;
> + interrupts = <0 11 4>;
> + };
> + ttc0_2: ttc0.2 {
> + status = "disabled";
> + reg = <2>;
> + interrupts = <0 12 4>;
> + };
> + };
> +
> + ttc1: ttc0 at f8002000 {
Also this is ttc1: ttc1.
These type of faults can be simple removed by proper dts node generation.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Dave Martin @ 2012-11-05 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105111346.GF28327@n2100.arm.linux.org.uk>
On Mon, Nov 05, 2012 at 11:13:46AM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
> > On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
> > > On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
> > > > On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
> > > > > On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
> > > > >> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
> > > > >>> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
> > > > >>>
> > > > >>>> While v6 can support unaligned accesses, it is optional and current
> > > > >>>> compilers won't emit unaligned accesses. So we don't clear the A bit for
> > > > >>>> v6.
> > > > >>>
> > > > >>> not true according to the gcc changes page
> > > > >>
> > > > >> What are you going to believe: documentation or what the compiler
> > > > >> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
> > > > >> support backported and 4.7.2, unaligned accesses are emitted for v7
> > > > >> only. I guess default here means it is the default unless you change the
> > > > >> default in your build of gcc.
> > > > >
> > > > > Since ARMv6 can handle unaligned access in the same way as ARMv7
> > > > > it seems a clear bug in gcc which might hopefully get fixed.
> > > > > Thus in this case I think it is reasonable to follow the
> > > > > gcc documentation, otherwise the code would break for ARMv6
> > > > > when gcc gets fixed.
> > > >
> > > > But the compiler can't assume the state of the U bit. I think it is
> > > > still legal on v6 to not support unaligned accesses, but on v7 it is
> > > > required. All the standard v6 ARM cores support it, but I'm not sure
> > > > about custom cores or if there are SOCs with buses that don't support
> > > > unaligned accesses properly.
> > >
> > > Well, I read the "...since Linux version 2.6.28" comment
> > > in the gcc changes page in the way that they assume the
> > > U-bit is set. (Although I'm not sure it really is???)
> >
> > Actually, the kernel checks the arch version and the U bit on boot,
> > and chooses the appropriate setting for the A bit depending on the
> > result. (See arch/arm/mm/alignment.c:alignment_init().)
>
> That is in the kernel itself, _after_ the decompressor has run. It is
> not relevant to any discussion about the decompressor.
This was merely meant as an argument that the kernel does not make
assumptions about the U bit, and so the zImage decompressor probably
shouldn't either.
> > Currently, we depend on the CPU reset behaviour or firmware/
> > bootloader to set the U bit for v6, but the behaviour should be
> > correct either way, though unaligned accesses will obviously
> > perform (much) better with U=1.
>
> Will someone _PLEASE_ address my initial comments against this patch
> in light of the fact that it's now been proven _NOT_ to be just a V7
> issue, rather than everyone seemingly buring their heads in the sand
> over this.
>
> The fact is, unaligned accesses in the decompressor are *undefined* at
> present.
Why not allow unaligned accesses in the decompressor, though, both
for v6 and v7?
The decompressors run with the cache on, so we should have fault-free
unaligned access on all CPUs which support it, provided that we set the
SCTLR bits appropriately, and provided that the decompressers are
written in correct C.
The counterargument is that zImage would then just fall over if booted
on a CPU older than the baseline architecture the kernel was built for.
However, that should be detected before executing any C code, giving
the zImage code a chance to bail out with a suitable error message.
A kernel which contains support for v6/v7 platforms cannot work on older
CPUs anyway, because the kernel itself doesn't support such combinations.
> > For v7, we should definitely use -munaligned-access where available
> > (unless it's the default?)
>
> No such option on my compiler - according to the manual I have, the only
> option there is starting -munaligned is on SPARC for -munaligned-doubles.
OK, I guess that's something backported into the Linaro toolchain I'm
currently using then. But it seems a good idea to use this if available,
because it allows the compiler to generate better code in some situations,
especially for packed struct access.
> However, I believe GCC does believe that unaligned accesses are fine on
> V6 and above.
Possibly, but I've never seen it use them deliberately, prior to the
-munaligned-access support.
Cheers
---Dave
^ permalink raw reply
* [PATCH 0/6] OMAPDSS: enable DSS for Panda & SDP with devtree
From: Tomi Valkeinen @ 2012-11-05 13:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
OMAPDSS device tree support is still some way in the future. Tony has requested
to get DSS working for Panda & SDP boards with DT kernel, so that we'll have
fully working boards with DT.
This series makes a few hacks to get a working display on OMAP4 Panda and SDP
boards. The idea is to setup the omapdss with the non-DT method, creating the
omapdss devices and passing platform data to them. This setup code is called
from board-generic for Panda and SDP boards.
There was one problem with this approach: omapdss cannot get regulators using
the omapdss's names fro the regulators. Thus there's a hack patch to get the
regulators using the OMAP4 "native" regulator names, thus circumventing the
problem.
Tony, if these look good, how do you want to merge these? There are three parts
here, and I think they can be merged independently if so wished:
* .dts changes for the pinmuxing (2 patches)
* dss-common.c and board-generic.c changes (3 patches)
* DSS hack for the regulators (1 patch)
If one of those parts is missing, DSS won't start with DT kernel, but otherwise
there shouldn't be any problems. So to avoid conflicts, I suggest that you take
the first two parts, and I'll merge the DSS hack via omapdss tree.
Tomi
Ricardo Neri (2):
ARM/dts: omap4-panda: Add pinmux configuration for HDMI
ARM/dts: omap4-sdp: Add pinmux configuration for HDMI
Tomi Valkeinen (4):
OMAPDSS: HACK: look for regulators with omap4 names
OMAP: panda: move display init from board file to dss-common.c
OMAP: omap4sdp: move display init from board file to dss-common.c
OMAP: board-generic: enable DSS for panda & sdp boards
arch/arm/boot/dts/omap4-panda-a4.dts | 17 ++
arch/arm/boot/dts/omap4-panda.dts | 18 ++
arch/arm/boot/dts/omap4-pandaES.dts | 9 +
arch/arm/boot/dts/omap4-sdp-es23plus.dts | 17 ++
arch/arm/boot/dts/omap4-sdp.dts | 18 ++
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/board-4430sdp.c | 157 +----------------
arch/arm/mach-omap2/board-generic.c | 10 ++
arch/arm/mach-omap2/board-omap4panda.c | 68 +-------
arch/arm/mach-omap2/dss-common.c | 276 ++++++++++++++++++++++++++++++
arch/arm/mach-omap2/dss-common.h | 14 ++
drivers/video/omap2/dss/dsi.c | 8 +
drivers/video/omap2/dss/hdmi.c | 4 +
13 files changed, 394 insertions(+), 224 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
create mode 100644 arch/arm/boot/dts/omap4-sdp-es23plus.dts
create mode 100644 arch/arm/mach-omap2/dss-common.c
create mode 100644 arch/arm/mach-omap2/dss-common.h
--
1.7.10.4
^ permalink raw reply
* [PATCH 1/6] ARM/dts: omap4-panda: Add pinmux configuration for HDMI
From: Tomi Valkeinen @ 2012-11-05 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-1-git-send-email-tomi.valkeinen@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-panda-a4.dts | 17 +++++++++++++++++
arch/arm/boot/dts/omap4-panda.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/omap4-pandaES.dts | 9 +++++++++
3 files changed, 44 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts
new file mode 100644
index 0000000..75466d2
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ "omap4-panda.dts"
+
+/* Pandaboard Rev A4+ have external pullups on SCL & SDA */
+&dss_hdmi_pins {
+ pinctrl-single,pins = <
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ >;
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index e8f927c..8060f5b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -65,6 +65,8 @@
&twl6040_pins
&mcpdm_pins
&mcbsp1_pins
+ &dss_hdmi_pins
+ &tpd12s015_pins
>;
twl6040_pins: pinmux_twl6040_pins {
@@ -92,6 +94,22 @@
0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT | MODE0 */
>;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins = <
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP | MODE 0 */
+ 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP | MODE 0 */
+ >;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins = <
+ 0x22 0x3 /* gpmc_a17.gpio_41 OUTPUT | MODE3 */
+ 0x48 0x3 /* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
+ 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
+ >;
+ };
};
&i2c1 {
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts b/arch/arm/boot/dts/omap4-pandaES.dts
index d4ba43a..73bc1a6 100644
--- a/arch/arm/boot/dts/omap4-pandaES.dts
+++ b/arch/arm/boot/dts/omap4-pandaES.dts
@@ -22,3 +22,12 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* PandaboardES has external pullups on SCL & SDA */
+&dss_hdmi_pins {
+ pinctrl-single,pins = <
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ >;
+};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/6] ARM/dts: omap4-sdp: Add pinmux configuration for HDMI
From: Tomi Valkeinen @ 2012-11-05 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-1-git-send-email-tomi.valkeinen@ti.com>
From: Ricardo Neri <ricardo.neri@ti.com>
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-sdp-es23plus.dts | 17 +++++++++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 18 ++++++++++++++++++
2 files changed, 35 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-sdp-es23plus.dts
diff --git a/arch/arm/boot/dts/omap4-sdp-es23plus.dts b/arch/arm/boot/dts/omap4-sdp-es23plus.dts
new file mode 100644
index 0000000..b4a40ff
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-sdp-es23plus.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ "omap4-sdp.dts"
+
+/* SDP boards with 4430 ES2.3+ or 4460 have external pullups on SCL & SDA */
+&dss_hdmi_pins {
+ pinctrl-single,pins = <
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ >;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5b7e04f..7b14bb3 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -124,6 +124,8 @@
&dmic_pins
&mcbsp1_pins
&mcbsp2_pins
+ &dss_hdmi_pins
+ &tpd12s015_pins
>;
uart2_pins: pinmux_uart2_pins {
@@ -194,6 +196,22 @@
0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT | MODE0 */
>;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins = <
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP | MODE 0 */
+ 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP | MODE 0 */
+ >;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins = <
+ 0x22 0x3 /* gpmc_a17.gpio_41 OUTPUT | MODE3 */
+ 0x48 0x3 /* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
+ 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
+ >;
+ };
};
&i2c1 {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/6] OMAPDSS: HACK: look for regulators with omap4 names
From: Tomi Valkeinen @ 2012-11-05 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-1-git-send-email-tomi.valkeinen@ti.com>
Normally the omapdss driver gets the regulators using the regulator
names assigned for omapdss. However, in an effort to get a minimal DSS
support for DT enabled kernel on selected boards, we will add omapdss
devices and platform data the old way even for DT kernel. This causes
the problem that omapdss cannot find the regulators using omapdss's
regulator names.
This patch creates a temporary workaround for DSI and HDMI by trying to
get the regulators also using native OMAP4 regulator names.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 8 ++++++++
drivers/video/omap2/dss/hdmi.c | 4 ++++
2 files changed, 12 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d64ac38..738f3c4 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1753,6 +1753,10 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
+ /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
+ if (IS_ERR(vdds_dsi))
+ vdds_dsi = regulator_get(&dsi->pdev->dev, "VCXIO");
+
if (IS_ERR(vdds_dsi)) {
DSSERR("can't get VDDS_DSI regulator\n");
return PTR_ERR(vdds_dsi);
@@ -4972,6 +4976,10 @@ static int __init dsi_init_display(struct omap_dss_device *dssdev)
vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
+ /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
+ if (IS_ERR(vdds_dsi))
+ vdds_dsi = regulator_get(&dsi->pdev->dev, "VCXIO");
+
if (IS_ERR(vdds_dsi)) {
DSSERR("can't get VDDS_DSI regulator\n");
return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index a48a7dd..deaeb6c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -340,6 +340,10 @@ static int __init hdmi_init_display(struct omap_dss_device *dssdev)
reg = devm_regulator_get(&hdmi.pdev->dev, "vdda_hdmi_dac");
+ /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
+ if (IS_ERR(reg))
+ reg = devm_regulator_get(&hdmi.pdev->dev, "VDAC");
+
if (IS_ERR(reg)) {
DSSERR("can't get VDDA_HDMI_DAC regulator\n");
return PTR_ERR(reg);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/6] OMAP: panda: move display init from board file to dss-common.c
From: Tomi Valkeinen @ 2012-11-05 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-1-git-send-email-tomi.valkeinen@ti.com>
Device tree support for omapdss is still some way in the future. In an
effort to get a minimal DSS support for DT enabled kernel on selected
OMAP4 boards, we'll go for a temporary solution: We will call the same
non-DT omapdss setup code for OMAP4 SDP and Pandaboards from
board-generic.c, thus enabling DSS for those boards.
This patch moves the display setup code from board-omap4panda.c to
dss-common.c. dss-common.c will be called by the board-omap4panda.c when
running on non-DT kernel, and by board-generic.c when running on DT
enabled kernel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/board-omap4panda.c | 68 +--------------------
arch/arm/mach-omap2/dss-common.c | 104 ++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/dss-common.h | 12 ++++
4 files changed, 118 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/mach-omap2/dss-common.c
create mode 100644 arch/arm/mach-omap2/dss-common.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..fb38a9b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -279,4 +279,4 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
-obj-y += common-board-devices.o twl-common.o
+obj-y += common-board-devices.o twl-common.o dss-common.o
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..ab505a2 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -36,26 +36,22 @@
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
-#include <video/omapdss.h>
#include "common.h"
#include <plat/usb.h>
#include <plat/mmc.h>
-#include <video/omap-panel-tfp410.h>
#include "soc.h"
#include "hsmmc.h"
#include "control.h"
#include "mux.h"
#include "common-board-devices.h"
+#include "dss-common.h"
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET 62
#define GPIO_WIFI_PMENA 43
#define GPIO_WIFI_IRQ 53
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
static struct ti_st_plat_data wilink_platform_data = {
@@ -409,68 +405,6 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
-/* Display DVI */
-#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-
-/* Using generic display panel */
-static struct tfp410_platform_data omap4_dvi_panel = {
- .i2c_bus_num = 3,
- .power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct omap_dss_device omap4_panda_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "dvi",
- .driver_name = "tfp410",
- .data = &omap4_dvi_panel,
- .phy.dpi.data_lines = 24,
- .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
- .channel = OMAP_DSS_CHANNEL_LCD2,
-};
-
-static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct omap_dss_device omap4_panda_hdmi_device = {
- .name = "hdmi",
- .driver_name = "hdmi_panel",
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = &omap4_panda_hdmi_data,
-};
-
-static struct omap_dss_device *omap4_panda_dss_devices[] = {
- &omap4_panda_dvi_device,
- &omap4_panda_hdmi_device,
-};
-
-static struct omap_dss_board_info omap4_panda_dss_data = {
- .num_devices = ARRAY_SIZE(omap4_panda_dss_devices),
- .devices = omap4_panda_dss_devices,
- .default_device = &omap4_panda_dvi_device,
-};
-
-static void __init omap4_panda_display_init(void)
-{
-
- omap_display_init(&omap4_panda_dss_data);
-
- /*
- * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
- * later have external pull up on the HDMI I2C lines
- */
- if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
- omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
- else
- omap_hdmi_init(0);
-
- omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
static void omap4_panda_init_rev(void)
{
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
new file mode 100644
index 0000000..62d7b15
--- /dev/null
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2012 Texas Instruments, Inc..
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+/*
+ * NOTE: this is a transitional file to help with DT adaptation.
+ * This file will be removed when DSS supports DT.
+ */
+
+#include <linux/kernel.h>
+#include <video/omapdss.h>
+#include <video/omap-panel-tfp410.h>
+
+#include <plat/cpu.h>
+
+#include "dss-common.h"
+#include "mux.h"
+
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
+#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
+
+/* Display DVI */
+#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
+
+/* Using generic display panel */
+static struct tfp410_platform_data omap4_dvi_panel = {
+ .i2c_bus_num = 3,
+ .power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
+};
+
+static struct omap_dss_device omap4_panda_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "tfp410",
+ .data = &omap4_dvi_panel,
+ .phy.dpi.data_lines = 24,
+ .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
+ .channel = OMAP_DSS_CHANNEL_LCD2,
+};
+
+static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+ .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+ .ls_oe_gpio = HDMI_GPIO_LS_OE,
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
+static struct omap_dss_device omap4_panda_hdmi_device = {
+ .name = "hdmi",
+ .driver_name = "hdmi_panel",
+ .type = OMAP_DISPLAY_TYPE_HDMI,
+ .channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = &omap4_panda_hdmi_data,
+};
+
+static struct omap_dss_device *omap4_panda_dss_devices[] = {
+ &omap4_panda_dvi_device,
+ &omap4_panda_hdmi_device,
+};
+
+static struct omap_dss_board_info omap4_panda_dss_data = {
+ .num_devices = ARRAY_SIZE(omap4_panda_dss_devices),
+ .devices = omap4_panda_dss_devices,
+ .default_device = &omap4_panda_dvi_device,
+};
+
+void __init omap4_panda_display_init(void)
+{
+ omap_display_init(&omap4_panda_dss_data);
+
+ /*
+ * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
+ * later have external pull up on the HDMI I2C lines
+ */
+ if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
+ omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
+
+ omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
+}
+
+void __init omap4_panda_display_init_of(void)
+{
+ omap_display_init(&omap4_panda_dss_data);
+}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
new file mode 100644
index 0000000..6fac6a8
--- /dev/null
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -0,0 +1,12 @@
+#ifndef __OMAP_DSS_COMMON__
+#define __OMAP_DSS_COMMON__
+
+/*
+ * NOTE: this is a transitional file to help with DT adaptation.
+ * This file will be removed when DSS supports DT.
+ */
+
+void __init omap4_panda_display_init(void);
+void __init omap4_panda_display_init_of(void);
+
+#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/6] OMAP: omap4sdp: move display init from board file to dss-common.c
From: Tomi Valkeinen @ 2012-11-05 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-1-git-send-email-tomi.valkeinen@ti.com>
Device tree support for omapdss is still some way in the future. In an
effort to get a minimal DSS support for DT enabled kernel on selected
OMAP4 boards, we'll go for a temporary solution: We will call the same
non-DT omapdss setup code for OMAP4 SDP and Pandaboards from
board-generic.c, thus enabling DSS for those boards.
This patch moves the display setup code from board-4430sdp.c to
dss-common.c. dss-common.c will be called by the board-4430sdp.c when
running on non-DT kernel, and by board-generic.c when running on DT
enabled kernel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 157 +-------------------------------
arch/arm/mach-omap2/dss-common.c | 172 +++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/dss-common.h | 2 +
3 files changed, 175 insertions(+), 156 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..8ce98ae 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -37,9 +37,6 @@
#include <plat/usb.h>
#include <plat/mmc.h>
#include "omap4-keypad.h"
-#include <video/omapdss.h>
-#include <video/omap-panel-nokia-dsi.h>
-#include <video/omap-panel-picodlp.h>
#include <linux/wl12xx.h>
#include <linux/platform_data/omap-abe-twl6040.h>
@@ -48,17 +45,13 @@
#include "hsmmc.h"
#include "control.h"
#include "common-board-devices.h"
+#include "dss-common.h"
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON 48
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
-#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO 40
#define GPIO_WIFI_PMENA 54
#define GPIO_WIFI_IRQ 53
@@ -607,154 +600,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static struct nokia_dsi_panel_data dsi1_panel = {
- .name = "taal",
- .reset_gpio = 102,
- .use_ext_te = false,
- .ext_te_gpio = 101,
- .esd_interval = 0,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct omap_dss_device sdp4430_lcd_device = {
- .name = "lcd",
- .driver_name = "taal",
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = &dsi1_panel,
- .phy.dsi = {
- .module = 0,
- },
- .channel = OMAP_DSS_CHANNEL_LCD,
-};
-
-static struct nokia_dsi_panel_data dsi2_panel = {
- .name = "taal",
- .reset_gpio = 104,
- .use_ext_te = false,
- .ext_te_gpio = 103,
- .esd_interval = 0,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct omap_dss_device sdp4430_lcd2_device = {
- .name = "lcd2",
- .driver_name = "taal",
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = &dsi2_panel,
- .phy.dsi = {
-
- .module = 1,
- },
- .channel = OMAP_DSS_CHANNEL_LCD2,
-};
-
-static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct omap_dss_device sdp4430_hdmi_device = {
- .name = "hdmi",
- .driver_name = "hdmi_panel",
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = &sdp4430_hdmi_data,
-};
-
-static struct picodlp_panel_data sdp4430_picodlp_pdata = {
- .picodlp_adapter_id = 2,
- .emu_done_gpio = 44,
- .pwrgood_gpio = 45,
-};
-
-static void sdp4430_picodlp_init(void)
-{
- int r;
- const struct gpio picodlp_gpios[] = {
- {DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON"},
- {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
- "DLP EMU DONE"},
- {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
- "DLP PWRGOOD"},
- };
-
- r = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
- if (r)
- pr_err("Cannot request PicoDLP GPIOs, error %d\n", r);
-}
-
-static int sdp4430_panel_enable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DISPLAY_SEL_GPIO, 0);
- gpio_set_value(DLP_POWER_ON_GPIO, 1);
-
- return 0;
-}
-
-static void sdp4430_panel_disable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DLP_POWER_ON_GPIO, 0);
- gpio_set_value(DISPLAY_SEL_GPIO, 1);
-}
-
-static struct omap_dss_device sdp4430_picodlp_device = {
- .name = "picodlp",
- .driver_name = "picodlp_panel",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .phy.dpi.data_lines = 24,
- .channel = OMAP_DSS_CHANNEL_LCD2,
- .platform_enable = sdp4430_panel_enable_picodlp,
- .platform_disable = sdp4430_panel_disable_picodlp,
- .data = &sdp4430_picodlp_pdata,
-};
-
-static struct omap_dss_device *sdp4430_dss_devices[] = {
- &sdp4430_lcd_device,
- &sdp4430_lcd2_device,
- &sdp4430_hdmi_device,
- &sdp4430_picodlp_device,
-};
-
-static struct omap_dss_board_info sdp4430_dss_data = {
- .num_devices = ARRAY_SIZE(sdp4430_dss_devices),
- .devices = sdp4430_dss_devices,
- .default_device = &sdp4430_lcd_device,
-};
-
-static void __init omap_4430sdp_display_init(void)
-{
- int r;
-
- /* Enable LCD2 by default (instead of Pico DLP) */
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- "display_sel");
- if (r)
- pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
- sdp4430_picodlp_init();
- omap_display_init(&sdp4430_dss_data);
- /*
- * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
- * later have external pull up on the HDMI I2C lines
- */
- if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
- omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
- else
- omap_hdmi_init(0);
-
- omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 62d7b15..679a047 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -24,8 +24,12 @@
*/
#include <linux/kernel.h>
+#include <linux/gpio.h>
+
#include <video/omapdss.h>
#include <video/omap-panel-tfp410.h>
+#include <video/omap-panel-nokia-dsi.h>
+#include <video/omap-panel-picodlp.h>
#include <plat/cpu.h>
@@ -102,3 +106,171 @@ void __init omap4_panda_display_init_of(void)
{
omap_display_init(&omap4_panda_dss_data);
}
+
+
+/* OMAP4 Blaze display data */
+
+#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
+#define DLP_POWER_ON_GPIO 40
+
+static struct nokia_dsi_panel_data dsi1_panel = {
+ .name = "taal",
+ .reset_gpio = 102,
+ .use_ext_te = false,
+ .ext_te_gpio = 101,
+ .esd_interval = 0,
+ .pin_config = {
+ .num_pins = 6,
+ .pins = { 0, 1, 2, 3, 4, 5 },
+ },
+};
+
+static struct omap_dss_device sdp4430_lcd_device = {
+ .name = "lcd",
+ .driver_name = "taal",
+ .type = OMAP_DISPLAY_TYPE_DSI,
+ .data = &dsi1_panel,
+ .phy.dsi = {
+ .module = 0,
+ },
+ .channel = OMAP_DSS_CHANNEL_LCD,
+};
+
+static struct nokia_dsi_panel_data dsi2_panel = {
+ .name = "taal",
+ .reset_gpio = 104,
+ .use_ext_te = false,
+ .ext_te_gpio = 103,
+ .esd_interval = 0,
+ .pin_config = {
+ .num_pins = 6,
+ .pins = { 0, 1, 2, 3, 4, 5 },
+ },
+};
+
+static struct omap_dss_device sdp4430_lcd2_device = {
+ .name = "lcd2",
+ .driver_name = "taal",
+ .type = OMAP_DISPLAY_TYPE_DSI,
+ .data = &dsi2_panel,
+ .phy.dsi = {
+
+ .module = 1,
+ },
+ .channel = OMAP_DSS_CHANNEL_LCD2,
+};
+
+static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+ .ls_oe_gpio = HDMI_GPIO_LS_OE,
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
+static struct omap_dss_device sdp4430_hdmi_device = {
+ .name = "hdmi",
+ .driver_name = "hdmi_panel",
+ .type = OMAP_DISPLAY_TYPE_HDMI,
+ .channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = &sdp4430_hdmi_data,
+};
+
+static struct picodlp_panel_data sdp4430_picodlp_pdata = {
+ .picodlp_adapter_id = 2,
+ .emu_done_gpio = 44,
+ .pwrgood_gpio = 45,
+};
+
+static void sdp4430_picodlp_init(void)
+{
+ int r;
+ const struct gpio picodlp_gpios[] = {
+ {DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ "DLP POWER ON"},
+ {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
+ "DLP EMU DONE"},
+ {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
+ "DLP PWRGOOD"},
+ };
+
+ r = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
+ if (r)
+ pr_err("Cannot request PicoDLP GPIOs, error %d\n", r);
+}
+
+static int sdp4430_panel_enable_picodlp(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(DISPLAY_SEL_GPIO, 0);
+ gpio_set_value(DLP_POWER_ON_GPIO, 1);
+
+ return 0;
+}
+
+static void sdp4430_panel_disable_picodlp(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(DLP_POWER_ON_GPIO, 0);
+ gpio_set_value(DISPLAY_SEL_GPIO, 1);
+}
+
+static struct omap_dss_device sdp4430_picodlp_device = {
+ .name = "picodlp",
+ .driver_name = "picodlp_panel",
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .channel = OMAP_DSS_CHANNEL_LCD2,
+ .platform_enable = sdp4430_panel_enable_picodlp,
+ .platform_disable = sdp4430_panel_disable_picodlp,
+ .data = &sdp4430_picodlp_pdata,
+};
+
+static struct omap_dss_device *sdp4430_dss_devices[] = {
+ &sdp4430_lcd_device,
+ &sdp4430_lcd2_device,
+ &sdp4430_hdmi_device,
+ &sdp4430_picodlp_device,
+};
+
+static struct omap_dss_board_info sdp4430_dss_data = {
+ .num_devices = ARRAY_SIZE(sdp4430_dss_devices),
+ .devices = sdp4430_dss_devices,
+ .default_device = &sdp4430_lcd_device,
+};
+
+void __init omap_4430sdp_display_init(void)
+{
+ int r;
+
+ /* Enable LCD2 by default (instead of Pico DLP) */
+ r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
+ "display_sel");
+ if (r)
+ pr_err("%s: Could not get display_sel GPIO\n", __func__);
+
+ sdp4430_picodlp_init();
+ omap_display_init(&sdp4430_dss_data);
+ /*
+ * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
+ * later have external pull up on the HDMI I2C lines
+ */
+ if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
+ omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
+
+ omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
+}
+
+void __init omap_4430sdp_display_init_of(void)
+{
+ int r;
+
+ /* Enable LCD2 by default (instead of Pico DLP) */
+ r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
+ "display_sel");
+ if (r)
+ pr_err("%s: Could not get display_sel GPIO\n", __func__);
+
+ sdp4430_picodlp_init();
+ omap_display_init(&sdp4430_dss_data);
+}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 6fac6a8..915f6ff 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -8,5 +8,7 @@
void __init omap4_panda_display_init(void);
void __init omap4_panda_display_init_of(void);
+void __init omap_4430sdp_display_init(void);
+void __init omap_4430sdp_display_init_of(void);
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/6] OMAP: board-generic: enable DSS for panda & sdp boards
From: Tomi Valkeinen @ 2012-11-05 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-1-git-send-email-tomi.valkeinen@ti.com>
Call the non-DT omapdss setup code from board-generic if the board is
omap4-panda or omap4-sdp. This will give us working omapdss for those
boards when using DT kernel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..8f5f21c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -21,6 +21,7 @@
#include "common.h"
#include "common-board-devices.h"
+#include "dss-common.h"
#if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
#define intc_of_init NULL
@@ -40,6 +41,15 @@ static void __init omap_generic_init(void)
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+
+ /*
+ * HACK: call display setup code for selected boards to enable omapdss.
+ * This will be removed when omapdss supports DT.
+ */
+ if (of_machine_is_compatible("ti,omap4-panda"))
+ omap4_panda_display_init_of();
+ else if (of_machine_is_compatible("ti,omap4-sdp"))
+ omap_4430sdp_display_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/6] ARM/dts: omap4-panda: Add pinmux configuration for HDMI
From: Tomi Valkeinen @ 2012-11-05 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-2-git-send-email-tomi.valkeinen@ti.com>
Hi Ricardo,
On 2012-11-05 15:14, Tomi Valkeinen wrote:
> From: Ricardo Neri <ricardo.neri@ti.com>
>
> Add the pinmux configuration for HDMI and TPD12S015A. Configure the
> gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
>
> Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-panda-a4.dts | 17 +++++++++++++++++
> arch/arm/boot/dts/omap4-panda.dts | 18 ++++++++++++++++++
> arch/arm/boot/dts/omap4-pandaES.dts | 9 +++++++++
> 3 files changed, 44 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
Ricardo, I modified this and the other dts patch to add new .dts files
for the board revisions with external pull on the SCL/SDA lines. Can you
verify that these are correct?
Tomi
> diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts
> new file mode 100644
> index 0000000..75466d2
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-panda-a4.dts
> @@ -0,0 +1,17 @@
> +/*
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/include/ "omap4-panda.dts"
> +
> +/* Pandaboard Rev A4+ have external pullups on SCL & SDA */
> +&dss_hdmi_pins {
> + pinctrl-single,pins = <
> + 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
> + 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
> + 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
> + >;
> +};
> diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
> index e8f927c..8060f5b 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -65,6 +65,8 @@
> &twl6040_pins
> &mcpdm_pins
> &mcbsp1_pins
> + &dss_hdmi_pins
> + &tpd12s015_pins
> >;
>
> twl6040_pins: pinmux_twl6040_pins {
> @@ -92,6 +94,22 @@
> 0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT | MODE0 */
> >;
> };
> +
> + dss_hdmi_pins: pinmux_dss_hdmi_pins {
> + pinctrl-single,pins = <
> + 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
> + 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP | MODE 0 */
> + 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP | MODE 0 */
> + >;
> + };
> +
> + tpd12s015_pins: pinmux_tpd12s015_pins {
> + pinctrl-single,pins = <
> + 0x22 0x3 /* gpmc_a17.gpio_41 OUTPUT | MODE3 */
> + 0x48 0x3 /* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
> + 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
> + >;
> + };
> };
>
> &i2c1 {
> diff --git a/arch/arm/boot/dts/omap4-pandaES.dts b/arch/arm/boot/dts/omap4-pandaES.dts
> index d4ba43a..73bc1a6 100644
> --- a/arch/arm/boot/dts/omap4-pandaES.dts
> +++ b/arch/arm/boot/dts/omap4-pandaES.dts
> @@ -22,3 +22,12 @@
> "AFML", "Line In",
> "AFMR", "Line In";
> };
> +
> +/* PandaboardES has external pullups on SCL & SDA */
> +&dss_hdmi_pins {
> + pinctrl-single,pins = <
> + 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
> + 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
> + 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
> + >;
> +};
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/2b492b2e/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl: at91: Staticize non-exported symbols
From: Axel Lin @ 2012-11-05 13:23 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
drivers/pinctrl/pinctrl-at91.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 65f066c..b9e2cbd 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -566,9 +566,9 @@ static int at91_pmx_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
return 0;
}
-int at91_gpio_request_enable(struct pinctrl_dev *pctldev,
- struct pinctrl_gpio_range *range,
- unsigned offset)
+static int at91_gpio_request_enable(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range,
+ unsigned offset)
{
struct at91_pinctrl *npct = pinctrl_dev_get_drvdata(pctldev);
struct at91_gpio_chip *at91_chip;
@@ -598,9 +598,9 @@ int at91_gpio_request_enable(struct pinctrl_dev *pctldev,
return 0;
}
-void at91_gpio_disable_free(struct pinctrl_dev *pctldev,
- struct pinctrl_gpio_range *range,
- unsigned offset)
+static void at91_gpio_disable_free(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range,
+ unsigned offset)
{
struct at91_pinctrl *npct = pinctrl_dev_get_drvdata(pctldev);
@@ -952,7 +952,7 @@ err:
return ret;
}
-int __devexit at91_pinctrl_remove(struct platform_device *pdev)
+static int __devexit at91_pinctrl_remove(struct platform_device *pdev)
{
struct at91_pinctrl *info = platform_get_drvdata(pdev);
@@ -1249,9 +1249,11 @@ static int at91_gpio_irq_map(struct irq_domain *h, unsigned int virq,
return 0;
}
-int at91_gpio_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
- const u32 *intspec, unsigned int intsize,
- irq_hw_number_t *out_hwirq, unsigned int *out_type)
+static int at91_gpio_irq_domain_xlate(struct irq_domain *d,
+ struct device_node *ctrlr,
+ const u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_type)
{
struct at91_gpio_chip *at91_gpio = d->host_data;
int ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Philip, Avinash @ 2012-11-05 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097B7EE.3000508@gmail.com>
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
> On 05.11.2012 12:03, Philip, Avinash wrote:
> > On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
> >> This patch adds basic DT bindings for OMAP GPMC.
> >>
> >> The actual peripherals are instanciated from child nodes within the GPMC
> >> node, and the only type of device that is currently supported is NAND.
> >>
> >> Code was added to parse the generic GPMC timing parameters and some
> >> documentation with examples on how to use them.
> >>
> >> Successfully tested on an AM33xx board.
> >>
> >> Signed-off-by: Daniel Mack <zonque@gmail.com>
> > [...]
> >> +
> >> + nand at 0,0 {
> >> + reg = <0 0 0>; /* CS0, offset 0 */
> >> + nand-bus-width = <16>;
> >> + nand-ecc-mode = "none";
> >> +
> >> + gpmc,sync-clk = <0>;
> >> + gpmc,cs-on = <0>;
> >> + gpmc,cs-rd-off = <36>;
> >> + gpmc,cs-wr-off = <36>;
> >> + gpmc,adv-on = <6>;
> >> + gpmc,adv-rd-off = <24>;
> >> + gpmc,adv-wr-off = <36>;
> >> + gpmc,we-off = <30>;
> >> + gpmc,oe-off = <48>;
> >> + gpmc,access = <54>;
> >> + gpmc,rd-cycle = <72>;
> >> + gpmc,wr-cycle = <72>;
> >> + gpmc,wr-access = <30>;
> >> + gpmc,wr-data-mux-bus = <0>;
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> +
> >
> > Can you take the timings (for example) from arago tree. The timings is tested in am335x-evm
> > So the timings can be directly used to populate GPMC timings. Timings can found at
> >
> > http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
> > h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
> >
> > [...]
> >> +static int gpmc_probe_dt(struct platform_device *pdev)
> >
> > Can you take care of the following section mismatch.
> > WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
> > from the function gpmc_probe_dt() to the function .init.text:gpmc_nand_init().
>
> Sore, both fixed for v4.
>
> > [...]
> >> +
> >> + val = of_get_nand_ecc_mode(child);
> >> + if (val >= 0)
> >> + gpmc_nand_data->ecc_opt = val;
> >
> > This will fail for BCH. Index of "soft_bch" is 5 & also don't have selection
> > option between for BCH4 & BCH8 also.
> > Can you use the of_property_read_u32 (as done early) to pass the ecc selection
> > from dt file. This will help selection of BCH4 & BCH8 ecc options.
>
> Hmm. Shouldn't we rather teach of_get_nand_ecc_mode() that two modes and
> bring the enum in sync?
ecc_opt is for selecting different ecc layout and not for selecting ecc mode.
In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout
OMAP_ECC_HAMMING_CODE_HW_ROMCODE
OMAP_ECC_BCH4_CODE_HW
OMAP_ECC_BCH8_CODE_HW
So selection of ecc layout data should come from DT not ecc mode.
Thanks
Avinash
>
>
> Daniel
>
>
>
^ permalink raw reply
* [PATCH] pinctrl: at91: Staticize non-exported symbols
From: Linus Walleij @ 2012-11-05 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121830.14769.2.camel@phoenix>
On Mon, Nov 5, 2012 at 2:23 PM, Axel Lin <axel.lin@ingics.com> wrote:
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
Merged to my AT91 branch, unless Jean-Christophe says something...
Thanks!
Linus Walleij
^ 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