* [PATCH] ARM: dts: sun7i: add pin muxing options for UART2
From: Maxime Ripard @ 2014-01-15 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389710990-16384-1-git-send-email-wens@csie.org>
On Tue, Jan 14, 2014 at 10:49:50PM +0800, Chen-Yu Tsai wrote:
> UART2 is used on CubieTruck to connect to the Bluetooth module.
> Add the pin set used in this case.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Queued for 3.15, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140115/93282b61/attachment.sig>
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Zhangfei Gao @ 2014-01-15 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389770159-21125-1-git-send-email-zhangfei.gao@linaro.org>
Introduced from commit bf626e5550f24aec24975a0e85ad8e572ca76a6b
CDETECT is ignored since negated return value of mmc_gpio_get_cd(mmc)
can not be checked by IS_ERR_VALUE.
Add spin_lock_bh(&host->lock) for atomic accessing DW_MMC_CARD_PRESENT,
otherwise sd detect may occasionally fail.
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reported-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org>
Tested-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/mmc/host/dw_mmc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a776f24f4311..9ded62c8225e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1033,7 +1033,8 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
int present;
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci_board *brd = slot->host->pdata;
- int gpio_cd = !mmc_gpio_get_cd(mmc);
+ struct dw_mci *host = slot->host;
+ int gpio_cd = mmc_gpio_get_cd(mmc);
/* Use platform get_cd function, else try onboard card detect */
if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
@@ -1041,11 +1042,12 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
else if (brd->get_cd)
present = !brd->get_cd(slot->id);
else if (!IS_ERR_VALUE(gpio_cd))
- present = !!gpio_cd;
+ present = !gpio_cd;
else
present = (mci_readl(slot->host, CDETECT) & (1 << slot->id))
== 0 ? 1 : 0;
+ spin_lock_bh(&host->lock);
if (present) {
set_bit(DW_MMC_CARD_PRESENT, &slot->flags);
dev_dbg(&mmc->class_dev, "card is present\n");
@@ -1053,6 +1055,7 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
clear_bit(DW_MMC_CARD_PRESENT, &slot->flags);
dev_dbg(&mmc->class_dev, "card is not present\n");
}
+ spin_unlock_bh(&host->lock);
return present;
}
@@ -2081,7 +2084,7 @@ static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
return gpio;
}
-/* find the cd gpio for a given slot; or -1 if none specified */
+/* find the cd gpio for a given slot */
static void dw_mci_of_get_cd_gpio(struct device *dev, u8 slot,
struct mmc_host *mmc)
{
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 01/12] at91: dt: Add at91sam9261 dt SoC support
From: Jean-Jacques Hiblot @ 2014-01-15 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D56D5B.5000505@atmel.com>
2014/1/14 Nicolas Ferre <nicolas.ferre@atmel.com>:
> On 09/01/2014 13:31, Jean-Jacques Hiblot :
>> This patch adds the basics to support the Device Tree on a sam9261-based platform
>>
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>> ---
>> arch/arm/boot/dts/at91sam9261.dtsi | 476 +++++++++++++++++++++++++++++++++++++
>> arch/arm/mach-at91/at91sam9261.c | 15 ++
>> 2 files changed, 491 insertions(+)
>> create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
>>
>> diff --git a/arch/arm/boot/dts/at91sam9261.dtsi b/arch/arm/boot/dts/at91sam9261.dtsi
>> new file mode 100644
>> index 0000000..773c3d6
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/at91sam9261.dtsi
>> @@ -0,0 +1,476 @@
>> +/*
>> + * at91sam9261.dtsi - Device Tree Include file for AT91SAM9261 SoC
>> + *
>> + * Copyright (C) 2013 Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>> + *
>> + * Licensed under GPLv2 only.
>> + */
>> +
>> +#include "skeleton.dtsi"
>> +#include <dt-bindings/pinctrl/at91.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +
>> +/ {
>> + model = "Atmel AT91SAM9261 family SoC";
>> + compatible = "atmel,at91sam9261";
>> + interrupt-parent = <&aic>;
>> +
>> + aliases {
>> + serial0 = &dbgu;
>> + serial1 = &usart0;
>> + serial2 = &usart1;
>> + serial3 = &usart2;
>> + gpio0 = &pioA;
>> + gpio1 = &pioB;
>> + gpio2 = &pioC;
>> + tcb0 = &tcb0;
>> + i2c0 = &i2c0;
>> + ssc0 = &ssc0;
>> + ssc1 = &ssc1;
>> + };
>> + cpus {
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> +
>> + cpu {
>> + compatible = "arm,arm926ej-s";
>> + device_type = "cpu";
>> + };
>> + };
>> +
>> + memory {
>> + reg = <0x20000000 0x08000000>;
>> + };
>> +
>> + ahb {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + apb {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>
> I know that it is not always done but can you please sort all nodes by
> ascending address order? It is always simple to deal with node additions
> when sorted this way.
just to clarify, ascending order means ascending address order, right ?
>
>> +
>> + aic: interrupt-controller at fffff000 {
>> + #interrupt-cells = <3>;
>> + compatible = "atmel,at91rm9200-aic";
>> + interrupt-controller;
>> + reg = <0xfffff000 0x200>;
>> + atmel,external-irqs = <29 30 31>;
>> + };
>> +
>> + pmc: pmc at fffffc00 {
>> + compatible = "atmel,at91rm9200-pmc";
>> + reg = <0xfffffc00 0x100>;
>> + };
>> +
>> + ramc: ramc at ffffea00 {
>> + compatible = "atmel,at91sam9260-sdramc";
>> + reg = <0xffffea00 0x200>;
>> + };
>> +
>> + pit: timer at fffffd30 {
>> + compatible = "atmel,at91sam9260-pit";
>> + reg = <0xfffffd30 0xf>;
>> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
>> + };
>> +
>> + tcb0: timer at fffa0000 {
>> + compatible = "atmel,at91rm9200-tcb";
>> + reg = <0xfffa0000 0x100>;
>> + interrupts = < 17 IRQ_TYPE_LEVEL_HIGH 0
>> + 18 IRQ_TYPE_LEVEL_HIGH 0
>> + 19 IRQ_TYPE_LEVEL_HIGH 0
>> + >;
>> + status = "disabled";
>> + };
>> +
>> + rstc at fffffd00 {
>> + compatible = "atmel,at91sam9260-rstc";
>> + reg = <0xfffffd00 0x10>;
>> + };
>> +
>> + shdwc at fffffd10 {
>> + compatible = "atmel,at91sam9260-shdwc";
>> + reg = <0xfffffd10 0x10>;
>> + };
>> +
>> + pinctrl at fffff400 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "atmel,at91rm9200-pinctrl", "simple-bus";
>> + ranges = <0xfffff400 0xfffff400 0xa00>;
>> +
>> + atmel,mux-mask = <
>> + /* A B */
>> + 0xffffffff 0xfffffff7 /* pioA */
>> + 0xffffffff 0xfffffff4 /* pioB */
>> + 0xffffffff 0xffffff07 /* pioC */
>> + >;
>> +
>> + /* shared pinctrl settings */
>> + dbgu {
>> + pinctrl_dbgu: dbgu-0 {
>> + atmel,pins =
>> + <AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA9 periph A */
>
> You may have to remove comments for pin descriptions. It is not needed
> anymore with pre-processor macros.
That is a relief
>
>> + AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>; /* PA10 periph A with pullup */
>> + };
>> + };
>> +
>> + usart0 {
>> + pinctrl_usart0: usart0-0 {
>> + atmel,pins =
>> + <AT91_PIOC 8 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC8 periph A with pullup */
>> + AT91_PIOC 9 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC9 periph A */
>> + };
>> +
>> + pinctrl_usart0_rts: usart0_rts-0 {
>> + atmel,pins =
>> + <AT91_PIOC 10 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC10 periph A */
>> + };
>> +
>> + pinctrl_usart0_cts: usart0_cts-0 {
>> + atmel,pins =
>> + <AT91_PIOC 11 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC11 periph A */
>> + };
>> + };
>> +
>> + usart1 {
>> + pinctrl_usart1: usart1-0 {
>> + atmel,pins =
>> + <AT91_PIOC 12 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC12 periph A with pullup */
>> + AT91_PIOC 13 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC13 periph A */
>> + };
>> +
>> + pinctrl_usart1_rts: usart1_rts-0 {
>> + atmel,pins =
>> + <AT91_PIOA 12 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA12 periph B */
>> + };
>> +
>> + pinctrl_usart1_cts: usart1_cts-0 {
>> + atmel,pins =
>> + <AT91_PIOA 13 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA13 periph B */
>> + };
>> + };
>> +
>> + usart2 {
>> + pinctrl_usart2: usart2-0 {
>> + atmel,pins =
>> + <AT91_PIOC 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC14 periph A with pullup */
>> + AT91_PIOC 15 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC15 periph A */
>> + };
>> +
>> + pinctrl_usart2_rts: usart2_rts-0 {
>> + atmel,pins =
>> + <AT91_PIOA 15 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA15 periph B */
>> + };
>> +
>> + pinctrl_usart2_cts: usart2_cts-0 {
>> + atmel,pins =
>> + <AT91_PIOA 16 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA16 periph B */
>> + };
>> + };
>> +
>> + nand {
>> + pinctrl_nand: nand-0 {
>> + atmel,pins =
>> + <AT91_PIOC 15 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP /* PC15 gpio RDY pin pull_up*/
>> + AT91_PIOC 14 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC14 gpio enable pin pull_up */
>> + };
>> + };
>> +
>> + mmc0 {
>> + pinctrl_mmc0_clk: mmc0_clk-0 {
>> + atmel,pins =
>> + <AT91_PIOA 2 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA2 periph B */
>> + };
>> +
>> + pinctrl_mmc0_slot0_cmd_dat0: mmc0_slot0_cmd_dat0-0 {
>> + atmel,pins =
>> + <AT91_PIOA 1 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA1 periph B with pullup */
>> + AT91_PIOA 0 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>; /* PA0 periph B with pullup */
>> + };
>> +
>> + pinctrl_mmc0_slot0_dat1_3: mmc0_slot0_dat1_3-0 {
>> + atmel,pins =
>> + <AT91_PIOA 4 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA4 periph B with pullup */
>> + AT91_PIOA 5 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA5 periph B with pullup */
>> + AT91_PIOA 6 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>; /* PA6 periph B with pullup */
>> + };
>> + };
>> +
>> + ssc0 {
>> + pinctrl_ssc0_tx: ssc0_tx-0 {
>> + atmel,pins =
>> + <AT91_PIOB 21 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB21 periph A */
>> + AT91_PIOB 22 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB22 periph A */
>> + AT91_PIOB 23 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB23 periph A */
>> + };
>> +
>> + pinctrl_ssc0_rx: ssc0_rx-0 {
>> + atmel,pins =
>> + <AT91_PIOB 24 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB24 periph A */
>> + AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB25 periph A */
>> + AT91_PIOB 26 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB26 periph A */
>> + };
>> + };
>> +
>> + ssc1 {
>> + pinctrl_ssc1_tx: ssc1_tx-0 {
>> + atmel,pins =
>> + <AT91_PIOA 17 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA17 periph B */
>> + AT91_PIOA 18 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA18 periph B */
>> + AT91_PIOA 19 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA19 periph B */
>> + };
>> +
>> + pinctrl_ssc1_rx: ssc1_rx-0 {
>> + atmel,pins =
>> + <AT91_PIOA 20 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA20 periph B */
>> + AT91_PIOA 21 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA21 periph B */
>> + AT91_PIOA 22 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA22 periph B */
>> + };
>> + };
>> +
>> + spi0 {
>> + pinctrl_spi0: spi0-0 {
>> + atmel,pins =
>> + <AT91_PIOA 0 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA0 periph A SPI0_MISO pin */
>> + AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA1 periph A SPI0_MOSI pin */
>> + AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PA2 periph A SPI0_SPCK pin */
>> + };
>> + };
>> +
>> + spi1 {
>> + pinctrl_spi1: spi1-0 {
>> + atmel,pins =
>> + <AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB30 periph A SPI1_MISO pin */
>> + AT91_PIOB 31 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB31 periph A SPI1_MOSI pin */
>> + AT91_PIOB 29 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB29 periph A SPI1_SPCK pin */
>> + };
>> + };
>> +
>> + tcb0 {
>> + pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
>> + atmel,pins = <AT91_PIOC 16 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tclk1: tcb0_tclk1-0 {
>> + atmel,pins = <AT91_PIOC 17 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tclk2: tcb0_tclk2-0 {
>> + atmel,pins = <AT91_PIOC 18 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tioa0: tcb0_tioa0-0 {
>> + atmel,pins = <AT91_PIOC 19 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tioa1: tcb0_tioa1-0 {
>> + atmel,pins = <AT91_PIOC 21 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tioa2: tcb0_tioa2-0 {
>> + atmel,pins = <AT91_PIOC 23 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tiob0: tcb0_tiob0-0 {
>> + atmel,pins = <AT91_PIOC 20 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tiob1: tcb0_tiob1-0 {
>> + atmel,pins = <AT91_PIOC 22 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> +
>> + pinctrl_tcb0_tiob2: tcb0_tiob2-0 {
>> + atmel,pins = <AT91_PIOC 24 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>> + };
>> + };
>> +
>> + pioA: gpio at fffff400 {
>> + compatible = "atmel,at91rm9200-gpio";
>> + reg = <0xfffff400 0x200>;
>> + interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>;
>> + #gpio-cells = <2>;
>> + gpio-controller;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + pioB: gpio at fffff600 {
>> + compatible = "atmel,at91rm9200-gpio";
>> + reg = <0xfffff600 0x200>;
>> + interrupts = <3 IRQ_TYPE_LEVEL_HIGH 1>;
>> + #gpio-cells = <2>;
>> + gpio-controller;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + pioC: gpio at fffff800 {
>> + compatible = "atmel,at91rm9200-gpio";
>> + reg = <0xfffff800 0x200>;
>> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH 1>;
>> + #gpio-cells = <2>;
>> + gpio-controller;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> + };
>> +
>> + dbgu: serial at fffff200 {
>> + compatible = "atmel,at91sam9260-usart";
>> + reg = <0xfffff200 0x200>;
>> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_dbgu>;
>> + status = "disabled";
>> + };
>> +
>> + usart0: serial at fffb0000 {
>> + compatible = "atmel,at91sam9260-usart";
>> + reg = <0xfffb0000 0x200>;
>> + interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
>> + atmel,use-dma-rx;
>> + atmel,use-dma-tx;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usart0>;
>> + status = "disabled";
>> + };
>> +
>> + usart1: serial at ffffb400 {
>> + compatible = "atmel,at91sam9260-usart";
>> + reg = <0xfffb4000 0x200>;
>> + interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
>> + atmel,use-dma-rx;
>> + atmel,use-dma-tx;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usart1>;
>> + status = "disabled";
>> + };
>> +
>> + usart2: serial at fff94000 {
>> + compatible = "atmel,at91sam9260-usart";
>> + reg = <0xfffb8000 0x200>;
>> + interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
>> + atmel,use-dma-rx;
>> + atmel,use-dma-tx;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usart2>;
>> + status = "disabled";
>> + };
>> +
>> + ssc0: ssc at fffbc000 {
>> + compatible = "atmel,at91rm9200-ssc";
>> + reg = <0xfffbc000 0x4000>;
>> + interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
>> + status = "disabled";
>> + };
>> +
>> + ssc1: ssc at fffc0000 {
>> + compatible = "atmel,at91rm9200-ssc";
>> + reg = <0xfffc0000 0x4000>;
>> + interrupts = <15 IRQ_TYPE_LEVEL_HIGH 5>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
>> + status = "disabled";
>> + };
>> +
>> + usb1: gadget at fffa4000 {
>> + compatible = "atmel,at91rm9200-udc";
>> + reg = <0xfffa4000 0x4000>;
>> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
>> + status = "disabled";
>> + };
>> +
>> + i2c0: i2c at fffac000 {
>> + compatible = "atmel,at91sam9261-i2c";
>
> isn't it "atmel,at91sam9260-i2c" ?
I don't know. the i2c driver whows a difference between the 9260 and
the 9261 regarding the clk_max_div. But I forgot to add the 9261 in
the dt ids table of the twi driver.
>
>> + reg = <0xfffac000 0x100>;
>> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH 6>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>> + mmc0: mmc at fffa8000 {
>> + compatible = "atmel,hsmci";
>> + reg = <0xfffa8000 0x600>;
>> + interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>> + watchdog at fffffd40 {
>> + compatible = "atmel,at91sam9260-wdt";
>> + reg = <0xfffffd40 0x10>;
>> + status = "disabled";
>> + };
>> +
>> + spi0: spi at fffc8000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "atmel,at91rm9200-spi";
>> + reg = <0xfffc8000 0x200>;
>> + interrupts = <12 IRQ_TYPE_LEVEL_HIGH 3>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_spi0>;
>> + status = "disabled";
>> + };
>> +
>> + spi1: spi at fffcc000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "atmel,at91rm9200-spi";
>> + reg = <0xfffcc000 0x200>;
>> + interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_spi1>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + nand0: nand at 40000000 {
>> + compatible = "atmel,at91rm9200-nand";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0x40000000 0x10000000>;
>> + atmel,nand-addr-offset = <22>;
>> + atmel,nand-cmd-offset = <21>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_nand>;
>> +
>> + gpios = <&pioC 15 GPIO_ACTIVE_HIGH
>> + &pioC 14 GPIO_ACTIVE_HIGH
>> + 0
>> + >;
>> + status = "disabled";
>> + };
>> +
>> + usb0: ohci at 00500000 {
>> + compatible = "atmel,at91rm9200-ohci", "usb-ohci";
>> + reg = <0x00500000 0x100000>;
>> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH 2>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + i2c at 0 {
>> + compatible = "i2c-gpio";
>> + gpios = <&pioA 7 GPIO_ACTIVE_HIGH /* sda */
>> + &pioA 8 GPIO_ACTIVE_HIGH /* scl */
>> + >;
>> + i2c-gpio,sda-open-drain;
>> + i2c-gpio,scl-open-drain;
>> + i2c-gpio,delay-us = <2>; /* ~100 kHz */
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>> +};
>> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
>> index 6276b4c..200d17a 100644
>> --- a/arch/arm/mach-at91/at91sam9261.c
>> +++ b/arch/arm/mach-at91/at91sam9261.c
>> @@ -189,6 +189,21 @@ static struct clk_lookup periph_clocks_lookups[] = {
>> CLKDEV_CON_ID("pioA", &pioA_clk),
>> CLKDEV_CON_ID("pioB", &pioB_clk),
>> CLKDEV_CON_ID("pioC", &pioC_clk),
>> + /* more usart lookup table for DT entries */
>> + CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
>> + CLKDEV_CON_DEV_ID("usart", "fffb0000.serial", &usart0_clk),
>> + CLKDEV_CON_DEV_ID("usart", "ffffb400.serial", &usart1_clk),
>> + CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
>> + /* more tc lookup table for DT entries */
>> + CLKDEV_CON_DEV_ID("t0_clk", "fffa0000.timer", &tc0_clk),
>> + CLKDEV_CON_DEV_ID("hclk", "500000.ohci", &ohci_clk),
>> + CLKDEV_CON_DEV_ID("spi_clk", "fffc8000.spi", &spi0_clk),
>> + CLKDEV_CON_DEV_ID("spi_clk", "fffcc000.spi", &spi1_clk),
>> + CLKDEV_CON_DEV_ID("mci_clk", "fffa8000.mmc", &mmc_clk),
>> + CLKDEV_CON_DEV_ID(NULL, "fffac000.i2c", &twi_clk),
>> + CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioA_clk),
>> + CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioB_clk),
>> + CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioC_clk),
>
> Yes, this is where I would like the CCF to be implemented...
Is it okay it CCF support comes latter or must it be part of this serie?
>
>
>> };
>>
>> static struct clk_lookup usart_clocks_lookups[] = {
>>
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* [PATCH v1 1/5] pinctrl: st: Fix a typo in probe
From: Linus Walleij @ 2014-01-15 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389711125-21007-1-git-send-email-srinivas.kandagatla@st.com>
On Tue, Jan 14, 2014 at 3:52 PM, <srinivas.kandagatla@st.com> wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Probe function had commas instead of semi-colons on some of the lines.
> This patch just fixes those lines. No functional chagnes done in this
> patch.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/1] mmc: sdhci: fix lockdep error on tunning routine
From: Peter Zijlstra @ 2014-01-15 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA+hA=Sb+Ve2xyto9v6YirqcXnePK2aHzJgjGZOhEQJK5Z0jqQ@mail.gmail.com>
On Wed, Jan 15, 2014 at 03:19:27PM +0800, Dong Aisheng wrote:
> On Mon, Jan 13, 2014 at 8:04 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, Dec 26, 2013 at 03:58:20PM +0800, Dong Aisheng wrote:
> >> > It's strange that this issue did not happen on kernel 3.10.17 with the same
> >> > code. And looking at the code, before call spin_lock we already disable the mmc
> >> > controller irq, per on my understanding, the deadlock given by lockdep may not
> >> > be able to happen(pls fix me if wrong).
> >> > May the lockdep not track the specific irq disable?
> >> > Copy lockdep guy to comment.
> >
> > No, lockdep also doesn't know only that one line can take this lock.
> > Lockdep only knows a lock is taken from IRQ context, and disabling one
> > line still allows IRQs to happen and therefore it yells.
>
> Okay, thanks for the information.
> If that, kernel 3.10.17 has the same code, do you know why it does not trigger
> such lockdep error?
No idea; there haven't really been big lockdep changes recently.
^ permalink raw reply
* imx6dl/imx6q fec rmii mode with external ref_clk
From: Fabio Estevam @ 2014-01-15 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115094551.GA26117@frolo.macqel>
On Wed, Jan 15, 2014 at 7:45 AM, Philippe De Muyter <phdm@macq.eu> wrote:
> Here are my patches (I have called my board imx6dl-p6-2094):
> Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK
> by something else ?
hummingboard uses:
MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0xc0000000
Check arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi in linux-next.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v2 01/12] at91: dt: Add at91sam9261 dt SoC support
From: Nicolas Ferre @ 2014-01-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5Nx-EkjZrN-NJ-5W9aC9HKg1P6kr2cN_4Gk4DPJn5RbWQ@mail.gmail.com>
On 15/01/2014 11:08, Jean-Jacques Hiblot :
> 2014/1/14 Nicolas Ferre <nicolas.ferre@atmel.com>:
>> On 09/01/2014 13:31, Jean-Jacques Hiblot :
>>> This patch adds the basics to support the Device Tree on a sam9261-based platform
>>>
>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>>> ---
>>> arch/arm/boot/dts/at91sam9261.dtsi | 476 +++++++++++++++++++++++++++++++++++++
>>> arch/arm/mach-at91/at91sam9261.c | 15 ++
>>> 2 files changed, 491 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/at91sam9261.dtsi b/arch/arm/boot/dts/at91sam9261.dtsi
>>> new file mode 100644
>>> index 0000000..773c3d6
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/at91sam9261.dtsi
>>> @@ -0,0 +1,476 @@
>>> +/*
>>> + * at91sam9261.dtsi - Device Tree Include file for AT91SAM9261 SoC
>>> + *
>>> + * Copyright (C) 2013 Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>>> + *
>>> + * Licensed under GPLv2 only.
>>> + */
>>> +
>>> +#include "skeleton.dtsi"
>>> +#include <dt-bindings/pinctrl/at91.h>
>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +
>>> +/ {
>>> + model = "Atmel AT91SAM9261 family SoC";
>>> + compatible = "atmel,at91sam9261";
>>> + interrupt-parent = <&aic>;
>>> +
>>> + aliases {
>>> + serial0 = &dbgu;
>>> + serial1 = &usart0;
>>> + serial2 = &usart1;
>>> + serial3 = &usart2;
>>> + gpio0 = &pioA;
>>> + gpio1 = &pioB;
>>> + gpio2 = &pioC;
>>> + tcb0 = &tcb0;
>>> + i2c0 = &i2c0;
>>> + ssc0 = &ssc0;
>>> + ssc1 = &ssc1;
>>> + };
>>> + cpus {
>>> + #address-cells = <0>;
>>> + #size-cells = <0>;
>>> +
>>> + cpu {
>>> + compatible = "arm,arm926ej-s";
>>> + device_type = "cpu";
>>> + };
>>> + };
>>> +
>>> + memory {
>>> + reg = <0x20000000 0x08000000>;
>>> + };
>>> +
>>> + ahb {
>>> + compatible = "simple-bus";
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>> + apb {
>>> + compatible = "simple-bus";
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>
>> I know that it is not always done but can you please sort all nodes by
>> ascending address order? It is always simple to deal with node additions
>> when sorted this way.
> just to clarify, ascending order means ascending address order, right ?
>
>>
>>> +
>>> + aic: interrupt-controller at fffff000 {
>>> + #interrupt-cells = <3>;
>>> + compatible = "atmel,at91rm9200-aic";
>>> + interrupt-controller;
>>> + reg = <0xfffff000 0x200>;
>>> + atmel,external-irqs = <29 30 31>;
>>> + };
>>> +
>>> + pmc: pmc at fffffc00 {
>>> + compatible = "atmel,at91rm9200-pmc";
>>> + reg = <0xfffffc00 0x100>;
>>> + };
>>> +
>>> + ramc: ramc at ffffea00 {
>>> + compatible = "atmel,at91sam9260-sdramc";
>>> + reg = <0xffffea00 0x200>;
>>> + };
>>> +
>>> + pit: timer at fffffd30 {
>>> + compatible = "atmel,at91sam9260-pit";
>>> + reg = <0xfffffd30 0xf>;
>>> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
>>> + };
>>> +
>>> + tcb0: timer at fffa0000 {
>>> + compatible = "atmel,at91rm9200-tcb";
>>> + reg = <0xfffa0000 0x100>;
>>> + interrupts = < 17 IRQ_TYPE_LEVEL_HIGH 0
>>> + 18 IRQ_TYPE_LEVEL_HIGH 0
>>> + 19 IRQ_TYPE_LEVEL_HIGH 0
>>> + >;
>>> + status = "disabled";
>>> + };
>>> +
>>> + rstc at fffffd00 {
>>> + compatible = "atmel,at91sam9260-rstc";
>>> + reg = <0xfffffd00 0x10>;
>>> + };
>>> +
>>> + shdwc at fffffd10 {
>>> + compatible = "atmel,at91sam9260-shdwc";
>>> + reg = <0xfffffd10 0x10>;
>>> + };
>>> +
>>> + pinctrl at fffff400 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "atmel,at91rm9200-pinctrl", "simple-bus";
>>> + ranges = <0xfffff400 0xfffff400 0xa00>;
>>> +
>>> + atmel,mux-mask = <
>>> + /* A B */
>>> + 0xffffffff 0xfffffff7 /* pioA */
>>> + 0xffffffff 0xfffffff4 /* pioB */
>>> + 0xffffffff 0xffffff07 /* pioC */
>>> + >;
>>> +
>>> + /* shared pinctrl settings */
>>> + dbgu {
>>> + pinctrl_dbgu: dbgu-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA9 periph A */
>>
>> You may have to remove comments for pin descriptions. It is not needed
>> anymore with pre-processor macros.
> That is a relief
>
>>
>>> + AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>; /* PA10 periph A with pullup */
>>> + };
>>> + };
>>> +
>>> + usart0 {
>>> + pinctrl_usart0: usart0-0 {
>>> + atmel,pins =
>>> + <AT91_PIOC 8 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC8 periph A with pullup */
>>> + AT91_PIOC 9 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC9 periph A */
>>> + };
>>> +
>>> + pinctrl_usart0_rts: usart0_rts-0 {
>>> + atmel,pins =
>>> + <AT91_PIOC 10 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC10 periph A */
>>> + };
>>> +
>>> + pinctrl_usart0_cts: usart0_cts-0 {
>>> + atmel,pins =
>>> + <AT91_PIOC 11 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC11 periph A */
>>> + };
>>> + };
>>> +
>>> + usart1 {
>>> + pinctrl_usart1: usart1-0 {
>>> + atmel,pins =
>>> + <AT91_PIOC 12 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC12 periph A with pullup */
>>> + AT91_PIOC 13 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC13 periph A */
>>> + };
>>> +
>>> + pinctrl_usart1_rts: usart1_rts-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 12 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA12 periph B */
>>> + };
>>> +
>>> + pinctrl_usart1_cts: usart1_cts-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 13 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA13 periph B */
>>> + };
>>> + };
>>> +
>>> + usart2 {
>>> + pinctrl_usart2: usart2-0 {
>>> + atmel,pins =
>>> + <AT91_PIOC 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC14 periph A with pullup */
>>> + AT91_PIOC 15 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC15 periph A */
>>> + };
>>> +
>>> + pinctrl_usart2_rts: usart2_rts-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 15 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA15 periph B */
>>> + };
>>> +
>>> + pinctrl_usart2_cts: usart2_cts-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 16 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA16 periph B */
>>> + };
>>> + };
>>> +
>>> + nand {
>>> + pinctrl_nand: nand-0 {
>>> + atmel,pins =
>>> + <AT91_PIOC 15 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP /* PC15 gpio RDY pin pull_up*/
>>> + AT91_PIOC 14 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC14 gpio enable pin pull_up */
>>> + };
>>> + };
>>> +
>>> + mmc0 {
>>> + pinctrl_mmc0_clk: mmc0_clk-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 2 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA2 periph B */
>>> + };
>>> +
>>> + pinctrl_mmc0_slot0_cmd_dat0: mmc0_slot0_cmd_dat0-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 1 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA1 periph B with pullup */
>>> + AT91_PIOA 0 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>; /* PA0 periph B with pullup */
>>> + };
>>> +
>>> + pinctrl_mmc0_slot0_dat1_3: mmc0_slot0_dat1_3-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 4 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA4 periph B with pullup */
>>> + AT91_PIOA 5 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA5 periph B with pullup */
>>> + AT91_PIOA 6 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>; /* PA6 periph B with pullup */
>>> + };
>>> + };
>>> +
>>> + ssc0 {
>>> + pinctrl_ssc0_tx: ssc0_tx-0 {
>>> + atmel,pins =
>>> + <AT91_PIOB 21 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB21 periph A */
>>> + AT91_PIOB 22 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB22 periph A */
>>> + AT91_PIOB 23 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB23 periph A */
>>> + };
>>> +
>>> + pinctrl_ssc0_rx: ssc0_rx-0 {
>>> + atmel,pins =
>>> + <AT91_PIOB 24 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB24 periph A */
>>> + AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB25 periph A */
>>> + AT91_PIOB 26 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB26 periph A */
>>> + };
>>> + };
>>> +
>>> + ssc1 {
>>> + pinctrl_ssc1_tx: ssc1_tx-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 17 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA17 periph B */
>>> + AT91_PIOA 18 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA18 periph B */
>>> + AT91_PIOA 19 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA19 periph B */
>>> + };
>>> +
>>> + pinctrl_ssc1_rx: ssc1_rx-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 20 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA20 periph B */
>>> + AT91_PIOA 21 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA21 periph B */
>>> + AT91_PIOA 22 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA22 periph B */
>>> + };
>>> + };
>>> +
>>> + spi0 {
>>> + pinctrl_spi0: spi0-0 {
>>> + atmel,pins =
>>> + <AT91_PIOA 0 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA0 periph A SPI0_MISO pin */
>>> + AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA1 periph A SPI0_MOSI pin */
>>> + AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PA2 periph A SPI0_SPCK pin */
>>> + };
>>> + };
>>> +
>>> + spi1 {
>>> + pinctrl_spi1: spi1-0 {
>>> + atmel,pins =
>>> + <AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB30 periph A SPI1_MISO pin */
>>> + AT91_PIOB 31 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB31 periph A SPI1_MOSI pin */
>>> + AT91_PIOB 29 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB29 periph A SPI1_SPCK pin */
>>> + };
>>> + };
>>> +
>>> + tcb0 {
>>> + pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
>>> + atmel,pins = <AT91_PIOC 16 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tclk1: tcb0_tclk1-0 {
>>> + atmel,pins = <AT91_PIOC 17 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tclk2: tcb0_tclk2-0 {
>>> + atmel,pins = <AT91_PIOC 18 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tioa0: tcb0_tioa0-0 {
>>> + atmel,pins = <AT91_PIOC 19 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tioa1: tcb0_tioa1-0 {
>>> + atmel,pins = <AT91_PIOC 21 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tioa2: tcb0_tioa2-0 {
>>> + atmel,pins = <AT91_PIOC 23 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tiob0: tcb0_tiob0-0 {
>>> + atmel,pins = <AT91_PIOC 20 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tiob1: tcb0_tiob1-0 {
>>> + atmel,pins = <AT91_PIOC 22 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> +
>>> + pinctrl_tcb0_tiob2: tcb0_tiob2-0 {
>>> + atmel,pins = <AT91_PIOC 24 AT91_PERIPH_B AT91_PINCTRL_NONE>;
>>> + };
>>> + };
>>> +
>>> + pioA: gpio at fffff400 {
>>> + compatible = "atmel,at91rm9200-gpio";
>>> + reg = <0xfffff400 0x200>;
>>> + interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>;
>>> + #gpio-cells = <2>;
>>> + gpio-controller;
>>> + interrupt-controller;
>>> + #interrupt-cells = <2>;
>>> + };
>>> +
>>> + pioB: gpio at fffff600 {
>>> + compatible = "atmel,at91rm9200-gpio";
>>> + reg = <0xfffff600 0x200>;
>>> + interrupts = <3 IRQ_TYPE_LEVEL_HIGH 1>;
>>> + #gpio-cells = <2>;
>>> + gpio-controller;
>>> + interrupt-controller;
>>> + #interrupt-cells = <2>;
>>> + };
>>> +
>>> + pioC: gpio at fffff800 {
>>> + compatible = "atmel,at91rm9200-gpio";
>>> + reg = <0xfffff800 0x200>;
>>> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH 1>;
>>> + #gpio-cells = <2>;
>>> + gpio-controller;
>>> + interrupt-controller;
>>> + #interrupt-cells = <2>;
>>> + };
>>> + };
>>> +
>>> + dbgu: serial at fffff200 {
>>> + compatible = "atmel,at91sam9260-usart";
>>> + reg = <0xfffff200 0x200>;
>>> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_dbgu>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + usart0: serial at fffb0000 {
>>> + compatible = "atmel,at91sam9260-usart";
>>> + reg = <0xfffb0000 0x200>;
>>> + interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
>>> + atmel,use-dma-rx;
>>> + atmel,use-dma-tx;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_usart0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + usart1: serial at ffffb400 {
>>> + compatible = "atmel,at91sam9260-usart";
>>> + reg = <0xfffb4000 0x200>;
>>> + interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
>>> + atmel,use-dma-rx;
>>> + atmel,use-dma-tx;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_usart1>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + usart2: serial at fff94000 {
>>> + compatible = "atmel,at91sam9260-usart";
>>> + reg = <0xfffb8000 0x200>;
>>> + interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
>>> + atmel,use-dma-rx;
>>> + atmel,use-dma-tx;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_usart2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + ssc0: ssc at fffbc000 {
>>> + compatible = "atmel,at91rm9200-ssc";
>>> + reg = <0xfffbc000 0x4000>;
>>> + interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + ssc1: ssc at fffc0000 {
>>> + compatible = "atmel,at91rm9200-ssc";
>>> + reg = <0xfffc0000 0x4000>;
>>> + interrupts = <15 IRQ_TYPE_LEVEL_HIGH 5>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + usb1: gadget at fffa4000 {
>>> + compatible = "atmel,at91rm9200-udc";
>>> + reg = <0xfffa4000 0x4000>;
>>> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + i2c0: i2c at fffac000 {
>>> + compatible = "atmel,at91sam9261-i2c";
>>
>> isn't it "atmel,at91sam9260-i2c" ?
> I don't know. the i2c driver whows a difference between the 9260 and
> the 9261 regarding the clk_max_div. But I forgot to add the 9261 in
> the dt ids table of the twi driver.
Ok, nice. I am looking forward for reviewing your patch ;-)
>>> + reg = <0xfffac000 0x100>;
>>> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH 6>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + mmc0: mmc at fffa8000 {
>>> + compatible = "atmel,hsmci";
>>> + reg = <0xfffa8000 0x600>;
>>> + interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + watchdog at fffffd40 {
>>> + compatible = "atmel,at91sam9260-wdt";
>>> + reg = <0xfffffd40 0x10>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + spi0: spi at fffc8000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "atmel,at91rm9200-spi";
>>> + reg = <0xfffc8000 0x200>;
>>> + interrupts = <12 IRQ_TYPE_LEVEL_HIGH 3>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_spi0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + spi1: spi at fffcc000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "atmel,at91rm9200-spi";
>>> + reg = <0xfffcc000 0x200>;
>>> + interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_spi1>;
>>> + status = "disabled";
>>> + };
>>> + };
>>> +
>>> + nand0: nand at 40000000 {
>>> + compatible = "atmel,at91rm9200-nand";
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + reg = <0x40000000 0x10000000>;
>>> + atmel,nand-addr-offset = <22>;
>>> + atmel,nand-cmd-offset = <21>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_nand>;
>>> +
>>> + gpios = <&pioC 15 GPIO_ACTIVE_HIGH
>>> + &pioC 14 GPIO_ACTIVE_HIGH
>>> + 0
>>> + >;
>>> + status = "disabled";
>>> + };
>>> +
>>> + usb0: ohci at 00500000 {
>>> + compatible = "atmel,at91rm9200-ohci", "usb-ohci";
>>> + reg = <0x00500000 0x100000>;
>>> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH 2>;
>>> + status = "disabled";
>>> + };
>>> + };
>>> +
>>> + i2c at 0 {
>>> + compatible = "i2c-gpio";
>>> + gpios = <&pioA 7 GPIO_ACTIVE_HIGH /* sda */
>>> + &pioA 8 GPIO_ACTIVE_HIGH /* scl */
>>> + >;
>>> + i2c-gpio,sda-open-drain;
>>> + i2c-gpio,scl-open-drain;
>>> + i2c-gpio,delay-us = <2>; /* ~100 kHz */
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + status = "disabled";
>>> + };
>>> +};
>>> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
>>> index 6276b4c..200d17a 100644
>>> --- a/arch/arm/mach-at91/at91sam9261.c
>>> +++ b/arch/arm/mach-at91/at91sam9261.c
>>> @@ -189,6 +189,21 @@ static struct clk_lookup periph_clocks_lookups[] = {
>>> CLKDEV_CON_ID("pioA", &pioA_clk),
>>> CLKDEV_CON_ID("pioB", &pioB_clk),
>>> CLKDEV_CON_ID("pioC", &pioC_clk),
>>> + /* more usart lookup table for DT entries */
>>> + CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
>>> + CLKDEV_CON_DEV_ID("usart", "fffb0000.serial", &usart0_clk),
>>> + CLKDEV_CON_DEV_ID("usart", "ffffb400.serial", &usart1_clk),
>>> + CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
>>> + /* more tc lookup table for DT entries */
>>> + CLKDEV_CON_DEV_ID("t0_clk", "fffa0000.timer", &tc0_clk),
>>> + CLKDEV_CON_DEV_ID("hclk", "500000.ohci", &ohci_clk),
>>> + CLKDEV_CON_DEV_ID("spi_clk", "fffc8000.spi", &spi0_clk),
>>> + CLKDEV_CON_DEV_ID("spi_clk", "fffcc000.spi", &spi1_clk),
>>> + CLKDEV_CON_DEV_ID("mci_clk", "fffa8000.mmc", &mmc_clk),
>>> + CLKDEV_CON_DEV_ID(NULL, "fffac000.i2c", &twi_clk),
>>> + CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioA_clk),
>>> + CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioB_clk),
>>> + CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioC_clk),
>>
>> Yes, this is where I would like the CCF to be implemented...
> Is it okay it CCF support comes latter or must it be part of this serie?
>
>>
>>
>>> };
>>>
>>> static struct clk_lookup usart_clocks_lookups[] = {
>>>
>>
>>
>> --
>> Nicolas Ferre
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v6 0/3] AArch64: KGDB support
From: Vijay Kilari @ 2014-01-15 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140107121147.GE29456@arm.com>
On Tue, Jan 7, 2014 at 5:41 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Jan 06, 2014 at 06:12:01PM +0000, Will Deacon wrote:
>> On Thu, Dec 19, 2013 at 11:50:48AM +0000, vijay.kilari at gmail.com wrote:
>> > From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>> >
>> > Based on the step-handler and break-handler hooks patch from
>> > Sandeepa, KGDB debugging support is added for EL1
>> > debug in AArch64 mode. Any updates that come for Patch 1 from
>> > Sandeepa will be rebased in next version
>> >
>> > With second patch,register layout is updated to be inline with GDB tool.
>> > Basic GDB connection, break point set/clear and info commands
>> > are supported except step/next debugging
>> >
>> > With third patch, step/next debugging support is added, where in
>> > pc is updated to point to the instruction to be stepped and
>> > stopped.
>> >
>> > With fourth patch, the compile time breakpoint instruction
>> > reordering is fixed by making kgbd_breakpoint() as noinline
>> >
>> > Tested with ARM64 simulator
>> >
>> > v6:
>> > - Change pstate register to 8 bytes to make endian nuetral.
>> > Use GDB below GDB patch to display pstate in Big endian mode.
>> > https://sourceware.org/ml/gdb-patches/2013-12/msg00720.html
>> > Thanks to Andrew.
>>
>> Thanks for getting this new version out. Just a few things before it can be
>> applied:
>>
>> 1. Can you please use "arm64:" instead of "AArch64:" in the patch
>> subjects?
>>
OK.
>> 2. Can you get an ack from somebody like Jason on the final patch please?
>>
I have not received any ack from Jason.
>> 3. Can you rebase onto the for-next/core branch at the arm64 repo:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>>
>> you'll get a trivial conflict against arch/arm64/kernel/Makefile.
>
> Just to be clear here, I would only recommend rebasing on top of this
> branch if there are patches queued for upstream which are required by
> the rebased patches and there isn't a topic branch already elsewhere. I
> do *not* recommend this branch for any kind of development (though
> testing is fine and we can fix the trivial Makefile conflicts
> ourselves).
OK. I will rebased on top of that branch and resend the patches soon.
>
>> 4. Can you make sure that the gdb patch you linked to actually gets
>> merged? There is still some discussion by the looks of it.
>
> I guess the kernel patches will have to wait for the binutils patch to
> go in. BTW, does this mean that kgdb on arm64 will only work with a
> future version of gdb?
>
KGDB works with current gdb version as well, except that it only fails
to display
cpsr reg value if kernel is built in BE mode. In LE it works fine.
> --
> Catalin
^ permalink raw reply
* [PATCH v2 06/12] at91: smc: Adds helper functions to validate and clip the smc timings.
From: Nicolas Ferre @ 2014-01-15 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5Pi-ZF5orDWheX9C3MpUcU56oDio_O8s6sR3Snb9QmTZQ@mail.gmail.com>
On 15/01/2014 10:54, Jean-Jacques Hiblot :
> 2014/1/15 Nicolas Ferre <nicolas.ferre@atmel.com>:
>> On 09/01/2014 13:31, Jean-Jacques Hiblot :
>>> This patchs implememnts 2 functions to help with the configuration of a
>>> chip-select's timing:
>>> * sam9_smc_check_cs_configuration : checks that the values would fit in the
>>> registers.
>>> * sam9_smc_clip_cs_configuration : clip the values to their maximum.
>>>
>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>>> ---
>>> arch/arm/mach-at91/include/mach/at91sam9_smc.h | 2 +
>>> arch/arm/mach-at91/sam9_smc.c | 77 ++++++++++++++++++++++++++
>>> 2 files changed, 79 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-at91/include/mach/at91sam9_smc.h b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
>>> index c3e29311..615ac56 100644
>>> --- a/arch/arm/mach-at91/include/mach/at91sam9_smc.h
>>> +++ b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
>>> @@ -47,6 +47,8 @@ extern void sam9_smc_read_mode(int id, int cs, struct sam9_smc_config *config);
>>> extern void sam9_smc_write_mode(int id, int cs, struct sam9_smc_config *config);
>>> extern void sam9_smc_cs_read(void __iomem *, struct sam9_smc_config *config);
>>> extern void sam9_smc_cs_configure(void __iomem *, struct sam9_smc_config *cfg);
>>> +extern int sam9_smc_check_cs_configuration(struct sam9_smc_config *config);
>>> +extern void sam9_smc_clip_cs_configuration(struct sam9_smc_config *config);
>>> #endif
>>>
>>> #define AT91_SMC_SETUP 0x00 /* Setup Register for CS n */
>>> diff --git a/arch/arm/mach-at91/sam9_smc.c b/arch/arm/mach-at91/sam9_smc.c
>>> index d7a6156..fe3c492 100644
>>> --- a/arch/arm/mach-at91/sam9_smc.c
>>> +++ b/arch/arm/mach-at91/sam9_smc.c
>>> @@ -23,6 +23,83 @@
>>>
>>> static void __iomem *smc_base_addr[2];
>>>
>>> +static int count_trailing_zeroes(u32 x)
>>
>> Don't we have something generic for this?
>>
>> Check include/asm-generic/bitops/count_zeros.h
>
> I wonder how I could have missed this one :o)
>
>>
>>> +{
>>> + int ret = 0;
>>> + if (!(x & 0xFFFF)) {
>>> + ret += 16;
>>> + x = x >> 16;
>>> + }
>>> + if (!(x & 0xFF)) {
>>> + ret += 8;
>>> + x = x >> 8;
>>> + }
>>> + if (!(x & 0xF)) {
>>> + ret += 4;
>>> + x = x >> 4;
>>> + }
>>> + if (!(x & 0x3)) {
>>> + ret += 2;
>>> + x = x >> 2;
>>> + }
>>> + if (!(x & 0x1)) {
>>> + ret += 1;
>>> + x = x >> 1;
>>> + }
>>> + if (!(x & 0x1))
>>> + ret += 1;
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +
>>> +#define __CHECK_CFG(config, x, y) do {\
>>> + if (x##_(config->y) > x) {\
>>> + pr_debug("error: %s (0x%x) is out of range\n", #y,\
>>> + config->y >> count_trailing_zeroes(x));\
>>> + return -EINVAL;\
>>> + } \
>>> + } while (0)
>>
>> I do not like the use of macro for this. You can convert them to
>> functions and it would increase readability. I am pretty confident that
>> gcc will optimize it so that is won't impact performance.
>
> It's not a matter of performance. I wanted to use the stringification
> for the debug message.
I see. It is interesting but anyway, we might keep it simple and just
flag the error with the incriminated value...
Bye,
>>> +int sam9_smc_check_cs_configuration(struct sam9_smc_config *config)
>>> +{
>>> + __CHECK_CFG(config, AT91_SMC_NWESETUP, nwe_setup);
>>> + __CHECK_CFG(config, AT91_SMC_NCS_WRSETUP, ncs_write_setup);
>>> + __CHECK_CFG(config, AT91_SMC_NRDSETUP, nrd_setup);
>>> + __CHECK_CFG(config, AT91_SMC_NCS_RDSETUP, ncs_read_setup);
>>> + __CHECK_CFG(config, AT91_SMC_NWEPULSE, nwe_pulse);
>>> + __CHECK_CFG(config, AT91_SMC_NCS_WRPULSE, ncs_write_pulse);
>>> + __CHECK_CFG(config, AT91_SMC_NRDPULSE, nrd_pulse);
>>> + __CHECK_CFG(config, AT91_SMC_NCS_RDPULSE, ncs_read_pulse);
>>> + __CHECK_CFG(config, AT91_SMC_NWECYCLE, write_cycle);
>>> + __CHECK_CFG(config, AT91_SMC_NRDCYCLE, read_cycle);
>>> + __CHECK_CFG(config, AT91_SMC_TDF, tdf_cycles);
>>> + return 0;
>>> +}
>>> +
>>> +#define __CLIP_CFG(config, x, y) do {\
>>> + if (x##_(config->y) > x) {\
>>> + config->y = x >> count_trailing_zeroes(x);\
>>> + pr_debug("clipping %s to %d\n", #y, config->y);\
>>> + } \
>>> + } while (0)
>>
>> Ditto.
>>
>>> +
>>> +void sam9_smc_clip_cs_configuration(struct sam9_smc_config *config)
>>> +{
>>> + __CLIP_CFG(config, AT91_SMC_NWESETUP, nwe_setup);
>>> + __CLIP_CFG(config, AT91_SMC_NCS_WRSETUP, ncs_write_setup);
>>> + __CLIP_CFG(config, AT91_SMC_NRDSETUP, nrd_setup);
>>> + __CLIP_CFG(config, AT91_SMC_NCS_RDSETUP, ncs_read_setup);
>>> + __CLIP_CFG(config, AT91_SMC_NWEPULSE, nwe_pulse);
>>> + __CLIP_CFG(config, AT91_SMC_NCS_WRPULSE, ncs_write_pulse);
>>> + __CLIP_CFG(config, AT91_SMC_NRDPULSE, nrd_pulse);
>>> + __CLIP_CFG(config, AT91_SMC_NCS_RDPULSE, ncs_read_pulse);
>>> + __CLIP_CFG(config, AT91_SMC_NWECYCLE, write_cycle);
>>> + __CLIP_CFG(config, AT91_SMC_NRDCYCLE, read_cycle);
>>> + __CLIP_CFG(config, AT91_SMC_TDF, tdf_cycles);
>>> +
>>> +}
>>> +
>>> static void sam9_smc_cs_write_mode(void __iomem *base,
>>> struct sam9_smc_config *config)
>>> {
>>>
>>
>>
>> --
>> Nicolas Ferre
>
>
--
Nicolas Ferre
^ permalink raw reply
* [RFC 2/2] arm: Get rid of meminfo
From: Catalin Marinas @ 2014-01-15 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115094957.GL15937@n2100.arm.linux.org.uk>
On 15 January 2014 09:49, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
>> memblock is now fully integrated into the kernel and is the prefered
>> method for tracking memory. Rather than reinvent the wheel with
>> meminfo, migrate to using memblock directly instead of meminfo as
>> an intermediate.
>
> The reason I never killed meminfo was that for some of the functions here
> is that meminfo has a slightly different property to memblock.
>
> With meminfo, each sparsemem section mapping or discontigmem node must be
> specified as a separate bank of memory, even if it is contiguous with the
> previous block. This is so that the functions which walk the page arrays
> can do so efficiently (without having to convert from a PFN to a struct
> page for every page in the system, which is very inefficient.)
pfn_to_page() conversion is indeed expensive with sparsemem (on
32-bit) but does meminfo actually add a noticeable improvement to the
boot time? I don't think so but it's worth testing (something a
thousand cycles maximum would be lost in the noise).
--
Catalin
^ permalink raw reply
* [PATCH] at91: dt: i2c: add a new compatibility string for the at91sam9261
From: Jean-Jacques Hiblot @ 2014-01-15 10:24 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
drivers/i2c/busses/i2c-at91.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 8edba9d..843d012 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -589,6 +589,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
.compatible = "atmel,at91sam9260-i2c",
.data = &at91sam9260_config,
} , {
+ .compatible = "atmel,at91sam9261-i2c",
+ .data = &at91sam9261_config,
+ } , {
.compatible = "atmel,at91sam9g20-i2c",
.data = &at91sam9g20_config,
} , {
--
1.8.5.2
^ permalink raw reply related
* [PATCH] at91: dt: sam9263: fixed compatibility string for the I2C
From: Jean-Jacques Hiblot @ 2014-01-15 10:24 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index c8fa9b9..7d6dd09 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -523,7 +523,7 @@
};
i2c0: i2c at fff88000 {
- compatible = "atmel,at91sam9263-i2c";
+ compatible = "atmel,at91sam9260-i2c";
reg = <0xfff88000 0x100>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH 6>;
#address-cells = <1>;
--
1.8.5.2
^ permalink raw reply related
* [PATCH v5 2/4] devicetree: bindings: Document Krait CPU/L1 EDAC
From: Lorenzo Pieralisi @ 2014-01-15 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389735034-21430-3-git-send-email-sboyd@codeaurora.org>
On Tue, Jan 14, 2014 at 09:30:32PM +0000, Stephen Boyd wrote:
> The Krait CPU/L1 error reporting device is made up a per-CPU
> interrupt. While we're here, document the next-level-cache
> property that's used by the Krait EDAC driver.
>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 52 ++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index 91304353eea4..c332b5168456 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -191,6 +191,16 @@ nodes to be present and contain the properties described below.
> property identifying a 64-bit zero-initialised
> memory location.
>
> + - interrupts
> + Usage: required for cpus with compatible string "qcom,krait".
> + Value type: <prop-encoded-array>
> + Definition: L1/CPU error interrupt
I reckon you want this property to belong in the cpus node (example below),
not in cpu nodes, right ?
Are you relying on a platform device to be created for /cpus node in
order for this series to work ? I guess that's why you want the
interrupts property to be defined in /cpus so that it becomes a platform
device resource (and you also add a compatible property in /cpus that is
missing in these bindings).
> +
> + - next-level-cache
> + Usage: optional
> + Value type: <phandle>
> + Definition: phandle pointing to the next level cache
> +
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {
> @@ -382,3 +392,45 @@ cpus {
> cpu-release-addr = <0 0x20000000>;
> };
> };
> +
> +
> +Example 5 (Krait 32-bit system):
> +
> +cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <1 9 0xf04>;
In patch 4 you also add a compatible property here, and that's not documented,
and honestly I do not think that's acceptable either. I guess you want a
compatible property here to match the platform driver, right ?
Thank you,
Lorenzo
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "qcom,krait";
> + reg = <0>;
> + next-level-cache = <&L2>;
> + };
> +
> + cpu at 1 {
> + device_type = "cpu";
> + compatible = "qcom,krait";
> + reg = <1>;
> + next-level-cache = <&L2>;
> + };
> +
> + cpu at 2 {
> + device_type = "cpu";
> + compatible = "qcom,krait";
> + reg = <2>;
> + next-level-cache = <&L2>;
> + };
> +
> + cpu at 3 {
> + device_type = "cpu";
> + compatible = "qcom,krait";
> + reg = <3>;
> + next-level-cache = <&L2>;
> + };
> +
> + L2: l2-cache {
> + compatible = "cache";
> + interrupts = <0 2 0x4>;
> + };
> +};
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
>
^ permalink raw reply
* [PATCH 1/1] mmc: sdhci: fix lockdep error on tunning routine
From: Dong Aisheng @ 2014-01-15 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115100904.GX31570@twins.programming.kicks-ass.net>
On Wed, Jan 15, 2014 at 6:09 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Jan 15, 2014 at 03:19:27PM +0800, Dong Aisheng wrote:
>> On Mon, Jan 13, 2014 at 8:04 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Thu, Dec 26, 2013 at 03:58:20PM +0800, Dong Aisheng wrote:
>> >> > It's strange that this issue did not happen on kernel 3.10.17 with the same
>> >> > code. And looking at the code, before call spin_lock we already disable the mmc
>> >> > controller irq, per on my understanding, the deadlock given by lockdep may not
>> >> > be able to happen(pls fix me if wrong).
>> >> > May the lockdep not track the specific irq disable?
>> >> > Copy lockdep guy to comment.
>> >
>> > No, lockdep also doesn't know only that one line can take this lock.
>> > Lockdep only knows a lock is taken from IRQ context, and disabling one
>> > line still allows IRQs to happen and therefore it yells.
>>
>> Okay, thanks for the information.
>> If that, kernel 3.10.17 has the same code, do you know why it does not trigger
>> such lockdep error?
>
> No idea; there haven't really been big lockdep changes recently.
Okay, thanks.
Anyway, this patch fix should be needed to avoid the lockdep error.
Chirs,
Can you pick it up?
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH 2/7] ARM: perf_event: Support percpu irqs for the CPU PMU
From: Will Deacon @ 2014-01-15 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D5A4D1.9030403@codeaurora.org>
Hi Stephen,
On Tue, Jan 14, 2014 at 08:57:53PM +0000, Stephen Boyd wrote:
> On 01/13/14 03:52, Will Deacon wrote:
> > I also don't think that's the right solution, based on the above. It's
> > actually pretty hard to work out what's the right thing to do here...
>
> Yes it doesn't seem like the right solution.
>
> >
> > We *could* have a per-cpu pointer to the cpu_pmu_pointer, but then we'd
> > need to update the IRQ handlers, including things like the CCI PMU which
> > really doesn't care about per-cpu stuff. So after all this, the shim we have
> > around the IRQ handler for the U8500 SPI workarounds might be the right
> > thing after all -- it allows us to consolidate the conversion of a pcpu
> > pointer into the relevant instance (actually any instance, since they'd all
> > point at the same thing) for the current CPU.
> >
> > What do you think to having that shim throw away the second level pcpu
> > pointer in the case of a PPI? (probably means we need to revisit that
> > renaming again).
>
> Ok I think I understand what you're getting at. We pass a per-cpu
> pointer to the cpu_pmu pointer as the dev_id argument to the PPI irq
> handler, and then we check to see if the irq is per-cpu inside the
> armpmu_dispatch_irq() function and throw away the second level of
> pointer, i.e.
>
> static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
> {
> struct arm_pmu *armpmu;
> struct platform_device *plat_device;
> struct arm_pmu_platdata *plat;
>
> if (irq_is_percpu(irq))
> dev = *(struct arm_pmu_cpu **)dev;
> armpmu = dev;
> plat_device = armpmu->plat_device;
> plat = dev_get_platdata(&plat_device->dev);
>
> if (plat && plat->handle_irq)
> return plat->handle_irq(irq, dev, armpmu->handle_irq);
> else
> return armpmu->handle_irq(irq, dev);
> }
Yup, that's what I was trying to explain (badly). Thanks.
> We still need to make a per-cpu variable to hold the pointer, and assign
> it during cpu_pmu_init like this patch does. Hopefully that is ok.
I think that's ok. The percpu code in genirq requires a pcpu token (for good
reason) and the irq handler needs to get at the pmu structure. The
alternative is adding pointers from something like the pmu_hw_events to the
arm_pmu, but I think that's more ugly.
Will
^ permalink raw reply
* [PATCH] spi: davinci: fix build warning when printing resource_size_t vars
From: Grygorii Strashko @ 2014-01-15 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D54CAC.1050005@ti.com>
On 01/14/2014 04:41 PM, Santosh Shilimkar wrote:
> On Tuesday 14 January 2014 09:39 AM, Mark Brown wrote:
>> On Tue, Jan 14, 2014 at 03:50:08PM +0200, Grygorii Strashko wrote:
>>> Use %pa format specifier when printing variables of resource_size_t type
>>> to fix build warnings:
>>> drivers/spi/spi-davinci.c:966:3: warning: format '%d' expects argument of type 'int', but argument 3 has type 'resource_size_t'
>>> drivers/spi/spi-davinci.c:966:3: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t'
>>
>> This doesn't apply against current code, it seems the same patch has
>> already been applied.
>>
> Yeah. I did send same patch last merge window time-frame which has been
> applied by you.
Ops. Sorry for the noise.
^ permalink raw reply
* imx6dl/imx6q fec rmii mode with external ref_clk
From: Philippe De Muyter @ 2014-01-15 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AhTLN+aCRH0FOVFO3uoZqe=2DpSiAHO2NCCTd=yJSyHg@mail.gmail.com>
On Wed, Jan 15, 2014 at 08:13:15AM -0200, Fabio Estevam wrote:
> On Wed, Jan 15, 2014 at 7:45 AM, Philippe De Muyter <phdm@macq.eu> wrote:
>
> > Here are my patches (I have called my board imx6dl-p6-2094):
> > Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK
> > by something else ?
>
> hummingboard uses:
>
> MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0xc0000000
I quickly tried that, but that does not solve my problem (still tx timeout)
>
> Check arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi in linux-next.
I will look there now.
Thanks
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
^ permalink raw reply
* [RFC 2/2] arm: Get rid of meminfo
From: Russell King - ARM Linux @ 2014-01-15 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkRjk4rkbLVReY7PQqO6DYB3erf6pRj4c4VoBe3iszkc9B5GA@mail.gmail.com>
On Wed, Jan 15, 2014 at 10:22:02AM +0000, Catalin Marinas wrote:
> On 15 January 2014 09:49, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
> >> memblock is now fully integrated into the kernel and is the prefered
> >> method for tracking memory. Rather than reinvent the wheel with
> >> meminfo, migrate to using memblock directly instead of meminfo as
> >> an intermediate.
> >
> > The reason I never killed meminfo was that for some of the functions here
> > is that meminfo has a slightly different property to memblock.
> >
> > With meminfo, each sparsemem section mapping or discontigmem node must be
> > specified as a separate bank of memory, even if it is contiguous with the
> > previous block. This is so that the functions which walk the page arrays
> > can do so efficiently (without having to convert from a PFN to a struct
> > page for every page in the system, which is very inefficient.)
>
> pfn_to_page() conversion is indeed expensive with sparsemem (on
> 32-bit) but does meminfo actually add a noticeable improvement to the
> boot time? I don't think so but it's worth testing (something a
> thousand cycles maximum would be lost in the noise).
Why do you ask about boot time?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v4 02/15] clk: Allow drivers to pass in a regmap
From: Mark Brown @ 2014-01-15 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115093641.4167.83109@quantum>
On Wed, Jan 15, 2014 at 01:36:41AM -0800, Mike Turquette wrote:
> Providing common functions for the basic case (e.g. read-modify-write on
> a register using a known mask) is reasonable. But that is exactly what
> the existing basic clock types do (sans regmap) and they have all become
> pretty ugly over time. And the clk-composite implementation just makes
> me a sad panda.
What we've tried to do with regulators is just have multiple helper
functions in the core rather than trying to merge their implementation,
the drivers pick the right one for their usage, and in cases where there
aren't many drivers doing the same thing we just have the driver either
copy the bits of the implementation they reuse or call the helper
function from within the implementation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140115/8b75c283/attachment.sig>
^ permalink raw reply
* imx6dl/imx6q fec rmii mode with external ref_clk
From: Philippe De Muyter @ 2014-01-15 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AhTLN+aCRH0FOVFO3uoZqe=2DpSiAHO2NCCTd=yJSyHg@mail.gmail.com>
On Wed, Jan 15, 2014 at 08:13:15AM -0200, Fabio Estevam wrote:
> On Wed, Jan 15, 2014 at 7:45 AM, Philippe De Muyter <phdm@macq.eu> wrote:
>
> > Here are my patches (I have called my board imx6dl-p6-2094):
> > Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK
> > by something else ?
>
> hummingboard uses:
>
> MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0xc0000000
>
> Check arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi in linux-next.
They use RGMII, while I have RMII :(
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
^ permalink raw reply
* [PATCH] at91: dt: i2c: add a new compatibility string for the at91sam9261
From: Nicolas Ferre @ 2014-01-15 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389781467-29626-1-git-send-email-jjhiblot@traphandler.com>
On 15/01/2014 11:24, Jean-Jacques Hiblot :
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks Jean-Jacques.
Side note: do not forget i2c maintainer and ml.
> ---
> drivers/i2c/busses/i2c-at91.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 8edba9d..843d012 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -589,6 +589,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
> .compatible = "atmel,at91sam9260-i2c",
> .data = &at91sam9260_config,
> } , {
> + .compatible = "atmel,at91sam9261-i2c",
> + .data = &at91sam9261_config,
> + } , {
> .compatible = "atmel,at91sam9g20-i2c",
> .data = &at91sam9g20_config,
> } , {
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v3 2/2] serial: fsl_lpuart: add DMA support
From: Mark Rutland @ 2014-01-15 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389763265-27300-3-git-send-email-yao.yuan@freescale.com>
On Wed, Jan 15, 2014 at 05:21:05AM +0000, Yuan Yao wrote:
> Add dma support for lpuart. This function depend on DMA driver.
> You can turn on it by SERIAL_FSL_LPUART_DMA=y. And It works if dts node has dma properties.
>
> Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
> ---
> .../devicetree/bindings/serial/fsl-lpuart.txt | 21 +-
> drivers/tty/serial/Kconfig | 7 +
> drivers/tty/serial/fsl_lpuart.c | 457 ++++++++++++++++++++-
> 3 files changed, 473 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> index 6fd1dd1..7509080 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> @@ -4,11 +4,24 @@ Required properties:
> - compatible : Should be "fsl,<soc>-lpuart"
> - reg : Address and length of the register set for the device
> - interrupts : Should contain uart interrupt
> +- clocks : from common clock binding: handle to uart clock
> +- clock-names : from common clock binding: Shall be "ipg"
Why are these now requried if they weren't previously? That breaks old
dts. I can't see any new code touching clocks. Was this an old but
undocumented requirement?
Could you please reword this so clocks is defined in terms of
clock-names so as to make the relationship between them clear:
- clocks: a list of phandles + clock-specifier pairs, one for each entry
in clock-names
- clock-names: should contain:
* "ipg" - the uart clock
> +
> +Optional properties:
> +- dma-names: Should contain "lpuart-tx" for transmit and "lpuart-rx" for receive channels
> +- dmas: Should contain dma specifiers for transmit and receive channels
Likewise could you please define dmas in terms of dma-names please. Why
not just "tx" and "rx" as other bindings use?
[...]
> +#ifdef CONFIG_SERIAL_FSL_LPUART_DMA
> + struct platform_device *pdev = to_platform_device(port->dev);
> + struct device_node *np = pdev->dev.of_node;
> +
> + if (of_get_property(np, "dmas", NULL)) {
> + sport->lpuart_dma_use = true;
> + lpuart_dma_tx_request(port);
> + lpuart_dma_rx_request(port);
> + temp = readb(port->membase + UARTCR5);
> + writeb(temp | UARTCR5_TDMAS, port->membase + UARTCR5);
Rather than reading the raw dt to find out if you have dmas, can you not
just attempt to request the dmas and if either fail give up on using
them?
> + } else
> + sport->lpuart_dma_use = false;
Nit: if you have brackets on one half of an if-else, they should be on
the other half too (even if i's a single line).
Cheers,
Mark.
^ permalink raw reply
* [PATCH] at91: dt: i2c: add a new compatibility string for the at91sam9261
From: Ludovic Desroches @ 2014-01-15 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389781467-29626-1-git-send-email-jjhiblot@traphandler.com>
On Wed, Jan 15, 2014 at 11:24:27AM +0100, Jean-Jacques Hiblot wrote:
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Thanks
> ---
> drivers/i2c/busses/i2c-at91.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 8edba9d..843d012 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -589,6 +589,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
> .compatible = "atmel,at91sam9260-i2c",
> .data = &at91sam9260_config,
> } , {
> + .compatible = "atmel,at91sam9261-i2c",
> + .data = &at91sam9261_config,
> + } , {
> .compatible = "atmel,at91sam9g20-i2c",
> .data = &at91sam9g20_config,
> } , {
> --
> 1.8.5.2
>
>
> _______________________________________________
> 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 RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
From: Jyri Sarha @ 2014-01-15 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131231131617.GZ31886@sirena.org.uk>
On 12/31/2013 03:16 PM, Mark Brown wrote:
> On Fri, Dec 20, 2013 at 12:38:27PM +0200, Jyri Sarha wrote:
>
>> +static int evm_startup(struct snd_pcm_substream *substream)
>> +{
>> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> + struct snd_soc_card *soc_card = rtd->codec->card;
>> + struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
>> + snd_soc_card_get_drvdata(soc_card))->mclk;
>
> Why do you need to cast away void? Ths indicates something is going
> wrong here though I can't see what.
I'll fix that.
>> + mclk = of_clk_get_by_name(np, "ti,codec-clock");
>> + if (PTR_ERR(mclk) == -EPROBE_DEFER) {
>> + return -EPROBE_DEFER;
>> + } else if (IS_ERR(mclk)) {
>> + dev_dbg(&pdev->dev, "Codec clock not found.\n");
>> + mclk = NULL;
>> + }
>
> The driver will unconditionally enable and disable the clock which I'd
> not expect to work well if we got an error, I'd expect either NULL checks
> on use or a fixed clock to be registered from code in the case where
> we're using the old binding.
>
In the drivers/clk/clk.c the clk == NULL is always checked before using
the pointer. However, adding NULL checks would save couple of
lock-unlock cycles. I'll add them.
> I'd also expect to see devm_clk_get() used here, with the standard
> clock-names based lookup from DT.
>
I'll fix that.
Best regards,
Jyri
^ permalink raw reply
* [GIT PULL] KVM/ARM Updates for 3.14
From: Paolo Bonzini @ 2014-01-15 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389221250-30034-1-git-send-email-christoffer.dall@linaro.org>
Il 08/01/2014 23:47, Christoffer Dall ha scritto:
> git://git.linaro.org/people/christoffer.dall/linux-kvm-arm.git tags/kvm-arm-for-3.14
Pulled, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox