* [PATCH 1/8] ARM: zynq: move arm-specific sys_timer out of ttc
From: Michal Simek @ 2012-11-05 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3ec3531d21c247ac3dcc76d91ff6be13ebfc733b.1351721190.git.josh.cartwright@ni.com>
2012/10/31 Josh Cartwright <josh.cartwright@ni.com>:
> Move the sys_timer definition out of ttc driver and make it part of the
> common zynq code. This is preparation for renaming and COMMON_CLK
> support.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> arch/arm/mach-zynq/common.c | 13 +++++++++++++
> arch/arm/mach-zynq/common.h | 4 +---
> arch/arm/mach-zynq/timer.c | 10 +---------
> 3 files changed, 15 insertions(+), 12 deletions(-)
>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Looks good to me. I have added it to my testing branch
and will provide path to mainline through xilinx arm-next branch
Thanks,
Michal
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Russell King - ARM Linux @ 2012-11-05 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105104839.GA2005@linaro.org>
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.
> 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.
> 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.
However, I believe GCC does believe that unaligned accesses are fine on
V6 and above.
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq changes for v3.8
From: Michal Simek @ 2012-11-05 11:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
please add these patches to your arm-soc trees. All these patches are
for xilinx zynq arm platform.
You shouldn't have any problem to merge it there are no conficts with v3.7-rc4.
Please let me know if you find out any problem.
Thanks,
Michal
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linus Torvalds (1):
Linux 3.7-rc3
are available in the git repository at:
git://git.xilinx.com/linux-xlnx.git arm-next
Josh Cartwright (4):
zynq: use GIC device tree bindings
zynq: use pl310 device tree bindings
zynq: remove use of CLKDEV_LOOKUP
zynq: move static peripheral mappings
arch/arm/Kconfig | 1 -
arch/arm/Makefile | 1 -
arch/arm/boot/dts/zynq-ep107.dts | 19 +++++++++++++---
arch/arm/mach-zynq/common.c | 23 ++++++++-----------
arch/arm/mach-zynq/include/mach/clkdev.h | 32 ----------------------------
arch/arm/mach-zynq/include/mach/zynq_soc.h | 31 +++++++++++++--------------
6 files changed, 40 insertions(+), 67 deletions(-)
delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
^ permalink raw reply
* [PATCH] ARM: dts: AM33XX: Add usbss node
From: Benoit Cousson @ 2012-11-05 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352095204-29028-1-git-send-email-afzal@ti.com>
+ Felipe
Hi Afzal,
On 11/05/2012 06:59 AM, Afzal Mohammed wrote:
> From: Ajay Kumar Gupta <ajay.gupta@ti.com>
>
> Device tree node for usbss on AM33XX. There are two musb
> controllers on am33xx platform so have port0-mode and
> port1-mode data.
>
> [afzal at ti.com: reg & interrupt property addition]
>
> Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
> Signed-off-by: Santhapuri, Damodar <damodar.santhapuri@ti.com>
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>
> Hi Benoit,
>
> This is based on your "for_3.8/dts" branch.
>
> This is made on top of "usb: musb: am335x support"
> (http://marc.info/?l=linux-omap&m=135187391904863&w=2)
> and has been tested on Beagle Bone.
That looks good to me, I just like to get an Ack from Felipe for the
accuracy of the data part.
Regards,
Benoit
>
> Regards
> Afzal
>
> arch/arm/boot/dts/am33xx.dtsi | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 5dfd682..78340a5 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -321,5 +321,22 @@
> ti,hwmods = "spi1";
> status = "disabled";
> };
> +
> + usb_otg_hs at 47400000 {
> + compatible = "ti,musb-am33xx";
> + reg = <0x47400000 0x1000 /* usbss */
> + 0x47401000 0x800 /* musb instance 0 */
> + 0x47401800 0x800>; /* musb instance 1 */
> + interrupts = <17 /* usbss */
> + 18 /* musb instance 0 */
> + 19>; /* musb instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port0-mode = <3>;
> + port1-mode = <3>;
> + power = <250>;
> + ti,hwmods = "usb_otg_hs";
> + };
> };
> };
>
^ permalink raw reply
* [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
From: Lokesh Vutla @ 2012-11-05 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50979D10.1070406@ti.com>
Hi Benoit,
On Monday 05 November 2012 04:33 PM, Benoit Cousson wrote:
> On 11/05/2012 11:51 AM, Benoit Cousson wrote:
>> Hi Lokesh,
>>
>> On 11/05/2012 06:58 AM, Lokesh Vutla wrote:
>>> Hi,
>>> On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote:
>>>> 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 v1:
>>>> * Created a seperate dtsi file for Samsung LPDDR2 memory device
>>>> used in OMAP5-evm.
>>>> * Passing reg and interrupt fields from dt for EMIF1 and EMIF2.
>>> Gentle ping on this series.
>>
>> Sorry, I missed it. It might be too late for 3.8, since Tony wanted us
>> to push before -rc4. I'll pull the series anyway just in case.
>>
>> I have a least one comment.
>
> Could you just rebase on top of the for_3.8 branch, fix the minor
> comments and repost ASAP.
OK I ll rebase and repost.
Thanks
Lokesh
>
> Thanks,
> Benoit
>
^ permalink raw reply
* [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Philip, Avinash @ 2012-11-05 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351869956-2787-5-git-send-email-zonque@gmail.com>
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().
[...]
> +
> + 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.
Thanks
Avinash
^ permalink raw reply
* [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
From: Benoit Cousson @ 2012-11-05 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50979A14.1050805@ti.com>
On 11/05/2012 11:51 AM, Benoit Cousson wrote:
> Hi Lokesh,
>
> On 11/05/2012 06:58 AM, Lokesh Vutla wrote:
>> Hi,
>> On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote:
>>> 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 v1:
>>> * Created a seperate dtsi file for Samsung LPDDR2 memory device
>>> used in OMAP5-evm.
>>> * Passing reg and interrupt fields from dt for EMIF1 and EMIF2.
>> Gentle ping on this series.
>
> Sorry, I missed it. It might be too late for 3.8, since Tony wanted us
> to push before -rc4. I'll pull the series anyway just in case.
>
> I have a least one comment.
Could you just rebase on top of the for_3.8 branch, fix the minor
comments and repost ASAP.
Thanks,
Benoit
^ permalink raw reply
* [PATCH V2 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
From: Benoit Cousson @ 2012-11-05 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959669-16366-4-git-send-email-lokeshvutla@ti.com>
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
> 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 6f87e1a..ed1d1b5 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";
> @@ -82,3 +83,13 @@
> 0x020700d9>; /* SEARCH */
> linux,input-no-autorepeat;
> };
> +
> +&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..b352d69
> --- /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 {
Nit, but the official unit is: MHz [1].
Regards,
Benoit
[1] http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf
^ permalink raw reply
* [PATCH RESEND] xen/arm: use the __HVC macro
From: Dave Martin @ 2012-11-05 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210241624400.2689@kaball.uk.xensource.com>
On Wed, Oct 24, 2012 at 04:26:08PM +0100, Stefano Stabellini wrote:
> Use the new __HVC macro in hypercall.S.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This is correct usage of the __HVC() macro, so
Acked-by: Dave Martin <dave.martin@linaro.org>
> ---
> arch/arm/xen/hypercall.S | 14 +++++---------
> 1 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index 074f5ed..71f7239 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -48,20 +48,16 @@
>
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/opcodes-virt.h>
> #include <xen/interface/xen.h>
>
>
> -/* HVC 0xEA1 */
> -#ifdef CONFIG_THUMB2_KERNEL
> -#define xen_hvc .word 0xf7e08ea1
> -#else
> -#define xen_hvc .word 0xe140ea71
> -#endif
> +#define XEN_IMM 0xEA1
>
> #define HYPERCALL_SIMPLE(hypercall) \
> ENTRY(HYPERVISOR_##hypercall) \
> mov r12, #__HYPERVISOR_##hypercall; \
> - xen_hvc; \
> + __HVC(XEN_IMM); \
> mov pc, lr; \
> ENDPROC(HYPERVISOR_##hypercall)
>
> @@ -76,7 +72,7 @@ ENTRY(HYPERVISOR_##hypercall) \
> stmdb sp!, {r4} \
> ldr r4, [sp, #4] \
> mov r12, #__HYPERVISOR_##hypercall; \
> - xen_hvc \
> + __HVC(XEN_IMM); \
> ldm sp!, {r4} \
> mov pc, lr \
> ENDPROC(HYPERVISOR_##hypercall)
> @@ -100,7 +96,7 @@ ENTRY(privcmd_call)
> mov r2, r3
> ldr r3, [sp, #8]
> ldr r4, [sp, #4]
> - xen_hvc
> + __HVC(XEN_IMM)
> ldm sp!, {r4}
> mov pc, lr
> ENDPROC(privcmd_call);
> --
> 1.7.2.5
^ permalink raw reply
* [PATCH v3 2/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
From: Philip, Avinash @ 2012-11-05 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351869956-2787-3-git-send-email-zonque@gmail.com>
On Fri, Nov 02, 2012 at 20:55:54, Daniel Mack wrote:
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> arch/arm/mach-omap2/gpmc-nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index 8607735..c3616c6 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -92,7 +92,7 @@ static int omap2_nand_gpmc_retime(
> static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
> {
> /* support only OMAP3 class */
> - if (!cpu_is_omap34xx()) {
> + if (!cpu_is_omap34xx() && !soc_is_am33xx()) {
> pr_err("BCH ecc is not supported on this CPU\n");
> return 0;
> }
Please add '!soc_is_am33xx()' check for BCH4 failure case also.
BCH4 support tested in AM335x.
https://lkml.org/lkml/2012/10/31/82
Thanks
Avinash
> --
> 1.7.11.7
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH V2 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
From: Benoit Cousson @ 2012-11-05 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959669-16366-3-git-send-email-lokeshvutla@ti.com>
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
> Adding EMIF device tree data for OMAP5 boards.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/boot/dts/omap5.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 5db33f4..445aeea 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -319,5 +319,29 @@
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp3";
> };
> +
> + emif1: emif at 0x4c000000 {
> + compatible = "ti,emif-4d5";
> + ti,hwmods = "emif1";
> + phy-type = <2>;
> + reg = <0x4c000000 0x3ff>;
Should 0x400. This parameter is the size, not the end address.
> + interrupts = <0 110 0x4>;
> + interrupt-parent = <&gic>;
Please remove the interrupt-parent. It is not needed since DT will use
the parent node to get it. It will avoid duplicating the entry for every
nodes.
> + 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>;
Can you just add a comment to give more information. I know this is in
the binding documentation, but some more comment never hurt.
> + reg = <0x4d000000 0x3ff>;
0x400 as well.
> + interrupts = <0 111 0x4>;
> + interrupt-parent = <&gic>;
Ditto.
> + hw-caps-read-idle-ctrl;
> + hw-caps-ll-interface;
> + hw-caps-temp-alert;
> + };
> };
> };
>
Regards,
Benoit
^ permalink raw reply
* [PATCH] ARM: backtrace: avoid crash on large invalid fp value
From: Dave Martin @ 2012-11-05 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRTNULfBjL=x3qFgjqsfR25EJt+2A4hY=qTXcDq8gyCxmA@mail.gmail.com>
On Fri, Nov 02, 2012 at 04:47:38PM -0700, Colin Cross wrote:
> On Wed, Oct 10, 2012 at 4:15 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > On Tue, Oct 09, 2012 at 11:46:12PM -0700, Todd Poynor wrote:
> >> Invalid frame pointer (signed) -4 <= fp <= -1 defeats check for too high
> >> on overflow.
> >>
> >> Signed-off-by: Todd Poynor <toddpoynor@google.com>
> >> ---
> >> arch/arm/kernel/stacktrace.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> >> index 00f79e5..6315162 100644
> >> --- a/arch/arm/kernel/stacktrace.c
> >> +++ b/arch/arm/kernel/stacktrace.c
> >> @@ -31,7 +31,7 @@ int notrace unwind_frame(struct stackframe *frame)
> >> high = ALIGN(low, THREAD_SIZE);
> >>
> >> /* check current frame pointer is within bounds */
> >> - if (fp < (low + 12) || fp + 4 >= high)
> >> + if (fp < (low + 12) || fp >= high - 4)
> >> return -EINVAL;
> >>
> >> /* restore the registers from the stack frame */
> >
> > sp and fp can still be complete garbage in the case of a corrupted frame,
> > so low + 12 can still overflow and cause us to read beyond the stack base.
> >
> > A more robust patch might be as follows. This also checks for misaligned
> > fp and sp values, since those indicate corruption and there can be no
> > sensible way to interpret the resulting frame in that case.
> >
> > Also, according to the definition of current_thread_info(),
> > IS_ALIGNED(sp, THREAD_SIZE) indicates a full stack extending from sp
> > to sp + THREAD_SIZE, and not an empty stack extending from sp -
> > THREAD_SIZE to sp. We cannot backtrace this situation anyway, since
> > that would imply that the frame record extends beyond the stack...
> > but this patch tidies it up in the interest of clarity.
> >
> > Cheers
> > ---Dave
> >
> > (untested)
> >
> > diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> > index 00f79e5..fec82be 100644
> > --- a/arch/arm/kernel/stacktrace.c
> > +++ b/arch/arm/kernel/stacktrace.c
> > @@ -28,10 +28,20 @@ int notrace unwind_frame(struct stackframe *frame)
> >
> > /* only go to a higher address on the stack */
> > low = frame->sp;
> > - high = ALIGN(low, THREAD_SIZE);
> > + if (!IS_ALIGNED(fp, 4))
> > + return -EINVAL;
> > +
> > + /*
> > + * low + 1 here ensures that high > sp, consistent with the
> > + * definition of current_thread_info().
> > + * We subtract 1 to compute the highest allowable byte address.
> > + * Otherwise, we might get high == 0 which would confuse our
> > + * comparisons.
> > + */
> > + high = ALIGN(low + 1, THREAD_SIZE) - 1;
> >
> > /* check current frame pointer is within bounds */
> > - if (fp < (low + 12) || fp + 4 >= high)
> > + if (fp < 12 || fp - 12 < low || fp > high)
> > return -EINVAL;
> >
> > /* restore the registers from the stack frame */
> > @@ -39,6 +49,10 @@ int notrace unwind_frame(struct stackframe *frame)
> > frame->sp = *(unsigned long *)(fp - 8);
> > frame->pc = *(unsigned long *)(fp - 4);
> >
> > + /* Do not claim the frame is valid if if is obviously corrupt: */
> > + if (!IS_ALIGNED(frame->fp, 4))
> > + return -EINVAL;
> > +
> > return 0;
> > }
> > #endif
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> Dave or Todd, mind reposting this, or should I squash it into my
> CONFIG_SMP stacktrace series?
I'm happy for you to fold my patch into your series if you agree
with it. Ideally, please fix my typo in the final comment ("if IT is
obviously corrupt").
Do I assume correctly that you are already testing this stuff?
Cheers
---Dave
^ permalink raw reply
* [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
From: Benoit Cousson @ 2012-11-05 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50975581.7010508@ti.com>
Hi Lokesh,
On 11/05/2012 06:58 AM, Lokesh Vutla wrote:
> Hi,
> On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote:
>> 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 v1:
>> * Created a seperate dtsi file for Samsung LPDDR2 memory device
>> used in OMAP5-evm.
>> * Passing reg and interrupt fields from dt for EMIF1 and EMIF2.
> Gentle ping on this series.
Sorry, I missed it. It might be too late for 3.8, since Tony wanted us
to push before -rc4. I'll pull the series anyway just in case.
I have a least one comment.
Regards,
Benoit
>
> Thanks
> Lokesh
>>
>> 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 | 24 +++++++++++
>> arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67
>> +++++++++++++++++++++++++++++
>> 3 files changed, 103 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
>>
>
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Dave Martin @ 2012-11-05 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025150816.GA3874@sig21.net>
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().)
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.
>From the compiler's point of view we have always implemented the
U=1 behaviour, but it has to be done via the alignment fault
handler prior to v6 or with U=0.
> Looking at it from another side, if using the hw unaligned
> access capability gives a performance benefit then it
> would be useful to support it even if gcc doesn't
> behave as documented. One could still use a special
> unaligned.h for ARMv6 to get the performance benefit.
> (If it doesn't give performance benfit, then why
> bother, let's just use -mno-unaligned-access for v7, too.)
For v7, we should definitely use -munaligned-access where available
(unless it's the default?)
For v6, the question is whether there is any legitimate reason
ever to run the kernel with U=0. If not, could we explicitly
set it early and build with -munaligned-access where the compiler
supports this?
The only counterargument I can think of is that some people might
be running some ancient userspace which actually relies on the U=0
behaviour. I don't know whether anyone is actually doing that on
v6, though.
Cheers
---Dave
> In the ARMv6 ARM unaligned support and the U-bit is
> not optional, so you could use the same SoC bus argument
> for some hypothetical v7 SoCs.
>
>
> Johannes
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/9] Pinctrl: SPEAr: Fixes for 3.7-rc3
From: viresh kumar @ 2012-11-05 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ+KhTQq+vrtoCVH2Y7fV4aT6JNzo+dL1Dg-GM8usb=Lg@mail.gmail.com>
On Mon, Nov 5, 2012 at 4:08 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sat, Oct 27, 2012 at 11:17 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> This patchset fixes many errors/mistakes in current pinctrl configurations for
>> various SPEAr SoCs. Please see if they can be merged in next rc release, if they
>> look fine to you.
>
> First sorry for taking so long...
Delay was expected as you were in connect :)
> Basically I have a hard time believeing these are regressions.
> I have applied patch 1, 2, 3 and 5 to fixes but I want an argument
> of why patch 4 and 6-9 are causing regressions in the current
> mainline kernel.
>
> I suspect they are fixing regressions in a non-mainline kernel
> which is none of our business, but convince me and I'll move
> them to the fixes branch ... I have still merged them, but aimed
> for v3.8.
Frankly speaking i haven't thought from this perspective while sending them.
Just grouped the fixes/mistakes together :)
- 4/9] pinctrl: SPEAr1310: fix clcd high resolution pin group name
- 6/9] pinctrl: SPEAr1310: Separate out pci pins from pcie_sata pin group
- 7/9] pinctrl: SPEAr1310: add register entries for enabling pad direction
This is important and pad multiplexing is incomplete without fixing
pad directions.
- 8/9] pinctrl: SPEAr1340: Make DDR reset & clock pads as gpio
This is important, otherwise DDR may not work.
- 9/9] pinctrl: SPEAr1340: Add clcd sleep mode pin configuration
You can add 4,6 and 9 in your linux-next branch. :)
--
viresh
^ permalink raw reply
* [PATCH 10/10] ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add gpio based push buttons device tree data to am335x-evmsk device
by adding all the necessary parameters like key-code, gpios and etc.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evmsk.dts | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 0f825dd..f5a6162 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -139,6 +139,37 @@
default-state = "off";
};
};
+
+ gpio_buttons: gpio_buttons at 0 {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch at 1 {
+ label = "button0";
+ linux,code = <0x100>;
+ gpios = <&gpio3 3 0>;
+ };
+
+ switch at 2 {
+ label = "button1";
+ linux,code = <0x101>;
+ gpios = <&gpio3 2 0>;
+ };
+
+ switch at 3 {
+ label = "button2";
+ linux,code = <0x102>;
+ gpios = <&gpio1 30 0>;
+ gpio-key,wakeup;
+ };
+
+ switch at 4 {
+ label = "button3";
+ linux,code = <0x103>;
+ gpios = <&gpio3 5 0>;
+ };
+ };
};
/include/ "tps65910.dtsi"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add pinmux configurations for gpio based keys to am335x-evmsk. In
this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evmsk.dts | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 7262fa8..0f825dd 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux at 44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&user_leds_s0>;
+ pinctrl-0 = <&user_leds_s0 &gpio_keys_s0>;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
@@ -42,6 +42,15 @@
0x1c 0x7 /* gpmc_ad7.gpio1_7, OUTPUT | MODE7 */
>;
};
+
+ gpio_keys_s0: gpio_keys_s0 {
+ pinctrl-single,pins = <
+ 0x94 0x27 /* gpmc_oen_ren.gpio2_3, INPUT | MODE7 */
+ 0x90 0x27 /* gpmc_advn_ale.gpio2_2, INPUT | MODE7 */
+ 0x70 0x27 /* gpmc_wait0.gpio0_30, INPUT | MODE7 */
+ 0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT | MODE7 */
+ >;
+ };
};
ocp {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 08/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add gpio-leds device tree data to am335x-evmsk device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on am335x starter
kit.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evmsk.dts | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 659ec5b..7262fa8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -100,6 +100,36 @@
regulator-name = "lis3_reg";
regulator-boot-on;
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ led at 1 {
+ label = "evmsk:green:usr0";
+ gpios = <&gpio2 4 0>;
+ default-state = "off";
+ };
+
+ led at 2 {
+ label = "evmsk:green:usr1";
+ gpios = <&gpio2 5 0>;
+ default-state = "off";
+ };
+
+ led at 3 {
+ label = "evmsk:green:mmc0";
+ gpios = <&gpio2 6 0>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led at 4 {
+ label = "evmsk:green:heartbeat";
+ gpios = <&gpio2 7 0>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+ };
};
/include/ "tps65910.dtsi"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 07/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add pinmux configurations for gpio based volume keys to am335x-evmsk.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evmsk.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 6f53879..659ec5b 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -30,6 +30,20 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ am33xx_pinmux: pinmux at 44e10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins = <
+ 0x10 0x7 /* gpmc_ad4.gpio1_4, OUTPUT | MODE7 */
+ 0x14 0x7 /* gpmc_ad5.gpio1_5, OUTPUT | MODE7 */
+ 0x18 0x7 /* gpmc_ad6.gpio1_6, OUTPUT | MODE7 */
+ 0x1c 0x7 /* gpmc_ad7.gpio1_7, OUTPUT | MODE7 */
+ >;
+ };
+ };
+
ocp {
uart1: serial at 44e09000 {
status = "okay";
--
1.7.9.5
^ permalink raw reply related
* [PATCH 06/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add gpio-leds device tree data to am335x-bone device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
[koen at dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-bone.dts | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 0bd0355..206c3eb 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -57,6 +57,36 @@
ti,system-power-controller;
};
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ led at 2 {
+ label = "beaglebone:green:heartbeat";
+ gpios = <&gpio2 21 0>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led at 3 {
+ label = "beaglebone:green:mmc0";
+ gpios = <&gpio2 22 0>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led at 4 {
+ label = "beaglebone:green:usr2";
+ gpios = <&gpio2 23 0>;
+ default-state = "off";
+ };
+
+ led at 5 {
+ label = "beaglebone:green:usr3";
+ gpios = <&gpio2 24 0>;
+ default-state = "off";
+ };
+ };
};
/include/ "tps65217.dtsi"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 05/10] ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add pinmux configurations for gpio based user-keys to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 6f9c48e..0bd0355 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,6 +24,20 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ am33xx_pinmux: pinmux at 44e10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins = <
+ 0x54 0x7 /* gpmc_a5.gpio1_21, OUTPUT | MODE7 */
+ 0x58 0x17 /* gpmc_a6.gpio1_22, OUTPUT_PULLUP | MODE7 */
+ 0x5c 0x7 /* gpmc_a7.gpio1_23, OUTPUT | MODE7 */
+ 0x60 0x17 /* gpmc_a8.gpio1_24, OUTPUT_PULLUP | MODE7 */
+ >;
+ };
+ };
+
ocp {
uart1: serial at 44e09000 {
status = "okay";
--
1.7.9.5
^ permalink raw reply related
* [PATCH 04/10] ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add gpio based volume keys device tree data to am335x-evm by adding
all the required parameters like keycode, gpios and etc.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e087b87..9f65f17 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -137,6 +137,27 @@
0x0101001c /* ENTER */
0x0201006c>; /* DOWN */
};
+
+ gpio_keys: volume_keys at 0 {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ switch at 9 {
+ label = "volume-up";
+ linux,code = <115>;
+ gpios = <&gpio1 2 1>;
+ gpio-key,wakeup;
+ };
+
+ switch at 10 {
+ label = "volume-down";
+ linux,code = <114>;
+ gpios = <&gpio1 3 1>;
+ gpio-key,wakeup;
+ };
+ };
};
/include/ "tps65910.dtsi"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 03/10] ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add pinmux configurations for gpio volume keys. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 8076e66..e087b87 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux at 44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&matrix_keypad_s0>;
+ pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins = <
@@ -37,6 +37,13 @@
0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT | MODE7 */
>;
};
+
+ volume_keys_s0: volume_keys_s0 {
+ pinctrl-single,pins = <
+ 0x150 0x27 /* spi0_sclk.gpio0_2, INPUT | MODE7 */
+ 0x154 0x27 /* spi0_d0.gpio0_3, INPUT | MODE7 */
+ >;
+ };
};
ocp {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 02/10] ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add matrix keypad device tree data to am335x-evm by adding all
the necessary parameters like keymap, row & column gpios and etc.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9199456..8076e66 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -110,6 +110,26 @@
regulator-name = "lis3_reg";
regulator-boot-on;
};
+
+ matrix_keypad: matrix_keypad at 0 {
+ compatible = "gpio-matrix-keypad";
+ debounce-delay-ms = <5>;
+ col-scan-delay-us = <2>;
+
+ row-gpios = <&gpio2 25 0 /* Bank1, pin25 */
+ &gpio2 26 0 /* Bank1, pin26 */
+ &gpio2 27 0>; /* Bank1, pin27 */
+
+ col-gpios = <&gpio2 21 0 /* Bank1, pin21 */
+ &gpio2 22 0>; /* Bank1, pin22 */
+
+ linux,keymap = <0x0000008b /* MENU */
+ 0x0100009e /* BACK */
+ 0x02000069 /* LEFT */
+ 0x0001006a /* RIGHT */
+ 0x0101001c /* ENTER */
+ 0x0201006c>; /* DOWN */
+ };
};
/include/ "tps65910.dtsi"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 01/10] ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM
From: AnilKumar Ch @ 2012-11-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
Add pinmux configurations for gpio matrix keypad. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 513284f..9199456 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -24,6 +24,21 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ am33xx_pinmux: pinmux at 44e10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&matrix_keypad_s0>;
+
+ matrix_keypad_s0: matrix_keypad_s0 {
+ pinctrl-single,pins = <
+ 0x54 0x7 /* gpmc_a5.gpio1_21, OUTPUT | MODE7 */
+ 0x58 0x7 /* gpmc_a6.gpio1_22, OUTPUT | MODE7 */
+ 0x64 0x27 /* gpmc_a9.gpio1_25, INPUT | MODE7 */
+ 0x68 0x27 /* gpmc_a10.gpio1_26, INPUT | MODE7 */
+ 0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT | MODE7 */
+ >;
+ };
+ };
+
ocp {
uart1: serial at 44e09000 {
status = "okay";
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox