Re: [PATCH v3] arm64: dts: add all hi6220 i2c nodes
On Wed, Dec 02, 2015 at 02:29:09PM +0800, Xinwei Kong wrote:
> This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
> use this I2C IP of Synopsys Designware for HiKey board.
>
> Signed-off-by: Xinwei Kong
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 31
> +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 82d2488..6eae673 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -208,5 +208,36 @@
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
> +
> + i2c0: i2c@f710 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf710 0x0 0x1000>;
> + interrupts = <0 44 4>;
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
> + status = "disabled";
You got me wrong. I was asking you to drop property 'clock-names' only,
not 'clocks' together. I do not think it works if you drop property
'clocks', because I see that dw_i2c_plat_probe() will fail if
devm_clk_get() fails. Did you test the patch before posting it out?
Shawn
> + };
> +
> + i2c1: i2c@f7101000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7101000 0x0 0x1000>;
> + interrupts = <0 45 4>;
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pmx_func &i2c1_cfg_func>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@f7102000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7102000 0x0 0x1000>;
> + interrupts = <0 46 4>;
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pmx_func &i2c2_cfg_func>;
> + status = "disabled";
> + };
> +
> };
> };
> --
> 1.9.1
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: dts: ls1021a: add sata node to dts
From: Tang Yuantian
Added sata node to ls1021aqds and ls1021atwr board to support
sata function.
Signed-off-by: Tang Yuantian
---
v3:
- refine the title and commit message
- added a status property so that sata can be controlled
by board specific dts.
v2:
- put reg-names right after reg property
arch/arm/boot/dts/ls1021a-qds.dts | 4
arch/arm/boot/dts/ls1021a-twr.dts | 4
arch/arm/boot/dts/ls1021a.dtsi| 11 +++
3 files changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
b/arch/arm/boot/dts/ls1021a-qds.dts
index 0521e68..803cc54 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -327,3 +327,7 @@
&uart1 {
status = "okay";
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
b/arch/arm/boot/dts/ls1021a-twr.dts
index fbb89d1..62dec7c 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -219,3 +219,7 @@
&uart1 {
status = "okay";
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9430a99..da9bd7e 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -143,6 +143,17 @@
status = "disabled";
};
+ sata: sata@320 {
+ compatible = "fsl,ls1021a-ahci";
+ reg = <0x0 0x320 0x0 0x1>,
+ <0x0 0x20220520 0x0 0x4>;
+ reg-names = "ahci", "sata-ecc";
+ interrupts = ;
+ clocks = <&platform_clk 1>;
+ dma-coherent;
+ status = "disabled";
+ };
+
scfg: scfg@157 {
compatible = "fsl,ls1021a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: DTS: LS1021A: add SATA node to DTS
On Mon, Nov 30, 2015 at 11:39:35AM +0800, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian
>
> Added SATA node to LS1021A DTS to support SATA function.
>
> Signed-off-by: Tang Yuantian
I think 'ARM: dts: ls1021a: ...' is a more idiomatic patch prefix for
your patch.
> ---
> v2:
> - put reg-names right after reg property
>
> arch/arm/boot/dts/ls1021a.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 9430a99..33aae8d 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -143,6 +143,16 @@
> status = "disabled";
> };
>
> + sata: sata@320 {
> + compatible = "fsl,ls1021a-ahci";
> + reg = <0x0 0x320 0x0 0x1>,
> + <0x0 0x20220520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = <&platform_clk 1>;
> + dma-coherent;
> + };
Shouldn't it have the line below to get the device disabled in
.dtsi by default, and let .dts that has sata support to
enable it?
status = "disabled";
Shawn
> +
> scfg: scfg@157 {
> compatible = "fsl,ls1021a-scfg", "syscon";
> reg = <0x0 0x157 0x0 0x1>;
> --
> 2.1.0.27.g96db324
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] arm64: dts: add all hi6220 i2c nodes
This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
use this I2C IP of Synopsys Designware for HiKey board.
Signed-off-by: Xinwei Kong
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 82d2488..6eae673 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -208,5 +208,36 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+ i2c0: i2c@f710 {
+ compatible = "snps,designware-i2c";
+ reg = <0x0 0xf710 0x0 0x1000>;
+ interrupts = <0 44 4>;
+ i2c-sda-hold-time-ns = <300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@f7101000 {
+ compatible = "snps,designware-i2c";
+ reg = <0x0 0xf7101000 0x0 0x1000>;
+ interrupts = <0 45 4>;
+ i2c-sda-hold-time-ns = <300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pmx_func &i2c1_cfg_func>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@f7102000 {
+ compatible = "snps,designware-i2c";
+ reg = <0x0 0xf7102000 0x0 0x1000>;
+ interrupts = <0 46 4>;
+ i2c-sda-hold-time-ns = <300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pmx_func &i2c2_cfg_func>;
+ status = "disabled";
+ };
+
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V1] ARM: dts: imx6: Change the clock name for spba clock
On Thu, Nov 26, 2015 at 10:39:30AM +0800, Shengjiu Wang wrote: > Audio IP need the spba clock, but original clock name "dma" is not > accurate, so change it to name "spba". The audio driver has been > using the new name "spba", the binding document has been updated. > > Signed-off-by: Shengjiu Wang Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 net-next 0/2] ravb: More compatibility strings
Hi, this short series adds generic gen2 and gen3, and soc-specific compatibility strings for the missing gen2 SoCs. Key Changes in v2: * Include "rcar-" in generic bindings Simon Horman (2): ravb: add fallback compatibility strings ravb: add device tree support for r8a779[123] Documentation/devicetree/bindings/net/renesas,ravb.txt | 12 +++- drivers/net/ethernet/renesas/ravb_main.c | 2 ++ 2 files changed, 13 insertions(+), 1 deletion(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 net-next 2/2] ravb: add device tree support for r8a779[123]
Simply document new compatibility strings. As a previous patch adds a generic R-Car Gen2 compatibility string there appears to be no need for a driver updates. Signed-off-by: Simon Horman --- v2 * No change --- Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 7555116b5db2..81a9f9e6b45f 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -5,6 +5,9 @@ interface contains. Required properties: - compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC. + "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC. + "renesas,etheravb-r8a7792" if the device is a part of R8A7792 SoC. + "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC. "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC. "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC. "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible interface. -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 net-next 1/2] ravb: add fallback compatibility strings
Add fallback compatibility strings for R-Car Gen 2 & 3 SoC Families.
This is in keeping with the fallback scheme being adopted wherever appropriate
for drivers for Renesas SoCs.
Signed-off-by: Simon Horman
---
v2
* Drop bogus typo non-fix
* include "rcar-" in generic bindings
---
Documentation/devicetree/bindings/net/renesas,ravb.txt | 9 -
drivers/net/ethernet/renesas/ravb_main.c | 2 ++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt
b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index b486f3f5f6a3..7555116b5db2 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -7,6 +7,13 @@ Required properties:
- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790
SoC.
"renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
"renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
+ "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible
interface.
+ "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible
interface.
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+
- reg: offset and length of (1) the register block and (2) the stream buffer.
- interrupts: A list of interrupt-specifiers, one for each entry in
interrupt-names.
@@ -37,7 +44,7 @@ Optional properties:
Example:
ethernet@e680 {
- compatible = "renesas,etheravb-r8a7795";
+ compatible = "renesas,etheravb-r8a7795",
"renesas,etheravb-rcar-gen3";
reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
interrupt-parent = <&gic>;
interrupts = ,
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index 990dc55cdada..c12b163ed7fe 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1656,7 +1656,9 @@ static int ravb_mdio_release(struct ravb_private *priv)
static const struct of_device_id ravb_match_table[] = {
{ .compatible = "renesas,etheravb-r8a7790", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,etheravb-r8a7794", .data = (void *)RCAR_GEN2 },
+ { .compatible = "renesas,etheravb-rcar-gen2", .data = (void *)RCAR_GEN2
},
{ .compatible = "renesas,etheravb-r8a7795", .data = (void *)RCAR_GEN3 },
+ { .compatible = "renesas,etheravb-rcar-gen3", .data = (void *)RCAR_GEN3
},
{ }
};
MODULE_DEVICE_TABLE(of, ravb_match_table);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] dmaengine: usb-dmac: Document SoC specific compatibility strings
In general Renesas hardware is not documented to the extent where the
relationship between IP blocks on different SoCs can be assumed although
they may appear to operate the same way. Furthermore the documentation
typically does not specify a version for individual IP blocks. For these
reasons a convention of using the SoC name in place of a version and
providing SoC-specific compatibility strings has been adopted.
Although not universally liked this convention is used in the bindings for
most drivers for Renesas hardware. The purpose of this patch is to
update the Renesas USB DMA Controller driver to follow this convention.
Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring
Acked-by: Yoshihiro Shimoda
Signed-off-by: Simon Horman
---
Notes:
* r8a7792 (R-Car V2H) is omitted as my reading of the documentation
is that Renesas USB-DMAC does not exist on that SoC.
v2:
* Use ,- rather than ,-
pattern for new compatibility strings
* Added compatibility string for r8a7795 on advice from Shimoda-san
* Added Acks
---
Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
index 040f365954cc..e7780a186a36 100644
--- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
@@ -1,7 +1,13 @@
* Renesas USB DMA Controller Device Tree bindings
Required Properties:
-- compatible: must contain "renesas,usb-dmac"
+-compatible: "renesas,-usb-dmac", "renesas,usb-dmac" as fallback.
+ Examples with soctypes are:
+ - "renesas,r8a7790-usb-dmac" (R-Car H2)
+ - "renesas,r8a7791-usb-dmac" (R-Car M2-W)
+ - "renesas,r8a7793-usb-dmac" (R-Car M2-N)
+ - "renesas,r8a7794-usb-dmac" (R-Car E2)
+ - "renesas,r8a7795-usb-dmac" (R-Car H3)
- reg: base address and length of the registers block for the DMAC
- interrupts: interrupt specifiers for the DMAC, one for each entry in
interrupt-names.
@@ -15,7 +21,7 @@ Required Properties:
Example: R8A7790 (R-Car H2) USB-DMACs
usb_dmac0: dma-controller@e65a {
- compatible = "renesas,usb-dmac";
+ compatible = "renesas,r8a7790-usb-dmac", "renesas,usb-dmac";
reg = <0 0xe65a 0 0x100>;
interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH
0 109 IRQ_TYPE_LEVEL_HIGH>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: ls1021a: Add a TFT LCD panel.
On Wed, Nov 25, 2015 at 02:46:07PM +0800, Meng Yi wrote:
> Signed-off-by: Alison Wang
> Signed-off-by: Xiubo Li
> Signed-off-by: Jianwei Wang
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> b/arch/arm/boot/dts/ls1021a-twr.dts
> index fbb89d1..fad2e3b 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -105,6 +105,17 @@
> bitclock-master;
> };
> };
> +
> + panel: panel {
> + compatible = "nec,nl4827hc19-05b";
> + };
> +
This new line shouldn't be needed.
> +};
> +
> +&dcu {
> + fsl,panel = <&panel>;
> + status = "okay";
> +
Ditto
I fixed them up and applied the both patches.
Shawn
> };
>
> &dspi1 {
> --
> 2.1.0.27.g96db324
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: imx: Add a virtual arm clk on i.mx7d
On Tue, Nov 24, 2015 at 06:25:14PM +0800, Bai Ping wrote: > Add a virtual arm clk to abstract the actual steps > when changing the ARM core frequency.So we can using > the 'cpufreq-dt' driver on i.MX7D/Solo. > > Signed-off-by: Bai Ping Applied all, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: imx: clk-vf610: fix SAI clock tree
On Sat, Oct 17, 2015 at 09:05:20PM -0700, Stefan Agner wrote: > The Synchronous Audio Interface (SAI) instances are clocked by > independent clocks: The bus clock and the audio clock (as shown in > Figure 51-1 in the Vybrid Reference Manual). The clock gates in > CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access > tests to the registers with/without gating those clocks have shown. > The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1, > followed by a clock divider (SAIx_DIV). Currently, the parent of > the bus clock gates has been assigned to SAIx_DIV, which is not > involved in the bus clock path for the SAI instances (see chapter > 9.10.12, SAI clocking in the Vybrid Reference Manual). > > Fix this by define the parent clock of VF610_CLK_SAIx to be the bus > clock. > > If the driver needs the audio clock (when used in master mode), a > fixed device tree is required which assign the audio clock properly > to VF610_CLK_SAIx_DIV. > > Signed-off-by: Stefan Agner > --- > Hi all, > > Patch 1 and 2 are actual fixes and should be applied toghether. If > the clock tree changes are applied only, master mode won't work > anymore. With only the device tree changes applied, it probably > will still work but the VF610_CLK_SAIx_DIV will be enabled twice. > > Since Patch 3 also uses the fixed clock layout, it should be > applied after the clock tree fix too... Applied all 3, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] ARM: exynos: select POWER_RESET_SYSCON and POWER_RESET_SYSCON_POWEROFF
On 01.12.2015 18:03, Pavel Fedin wrote: > Hello! > > Tested it on top of 4.4-rc3. > >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig >> index 3a10f1a8317a..d279edf9b10d 100644 >> --- a/arch/arm/mach-exynos/Kconfig >> +++ b/arch/arm/mach-exynos/Kconfig >> @@ -27,6 +27,9 @@ menuconfig ARCH_EXYNOS >> select SRAM >> select THERMAL >> select MFD_SYSCON >> +select POWER_RESET >> +select POWER_RESET_SYSCON >> +select POWER_RESET_SYSCON_POWEROFF > > "select POWER_SUPPLY" is missing here. Without is we get: > --- cut --- > warning: (ARCH_HISI && ARCH_INTEGRATOR && ARCH_EXYNOS && ARCH_VEXPRESS && > REALVIEW_DT) selects POWER_RESET which has unmet direct > dependencies (POWER_SUPPLY) > warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON which has unmet direct > dependencies (POWER_SUPPLY && POWER_RESET && OF) > warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON_POWEROFF which has unmet > direct dependencies (POWER_SUPPLY && POWER_RESET && OF) > --- cut --- > >> help >>Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) > > Otherwise works fine. > > Tested-by: Pavel Fedin Testing was a little bit too late (late not only looking at date of v1 and v2 but even for v3)... I appreciate it but I applied it already and in fact I sent a pull request with it. Actually the proper fix I think is to remove the dependency between POWER_RESET and POWER_SUPPLY. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Brian, On 02/12/15 08:56, Brian Norris wrote: > Hi Roger, > > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: >> On 30/11/15 21:54, Brian Norris wrote: >>> On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: On 26/10/15 23:23, Brian Norris wrote: > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >> This causes performance increase when using prefetch-irq mode. >> 30% increase in read, 17% increase in write in prefetch-irq mode. > > Have you pinpointed the exact causes for the performance increase, or > can you give an educated guess? AIUI, you're reducing the number of > interrupts needed for NAND prefetch mode, but you're also removing a bit > of abstraction and implementing hooks that look awfully like the > existing abstractions: > > + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > + u32 (*nand_irq_status)(void); > > That's not really a problem if there's a good reason for them (brcmnand > implements similar hooks because of quirks in the implementation of > interrupts across various BRCM SoCs, and it's not worth writing irqchip > drivers for those cases). I'm mainly curious for an explanation. I have both implementations with me. My guess is that the 20% performance gain is due to absence of irqchip/irqdomain translation code. I haven't investigated further though. >>> >>> I don't have much context for whether this makes sense or not. According >>> to your tests, you're getting ~800K interrupts over ~15 seconds. So >>> should you start noticing performance hits due to abstraction at 53K >>> interrupts per second? >> >> Yes, this was my understanding. > > Am I computing wrong, or is that a pretty insane rate of interrupts? I don't have the test board with me right now and so can't tell you for sure if the mtd tests took 15 seconds or more. I can try it out on a different board that I have and let you know for sure about how many interrupts we get per second. > >>> But anyway, I'm not sure that completely answered my question. My >>> question was whether you were removing the irqchip code solely for >>> performance reasons, or are there others? >> >> Yes. Only for performance reasons. > > Hmm, that's not my favorite answer. I'd prefer that more analysis was > done here before scrapping irqchip... I agree. We could retain the irqchip model till we have more satisfying analysis. > > But maybe that's not too bad. It seems like your patch set overall is a > net positive for disentangling some of arch/ and drivers/. :) > > I'll take another pass over your patch set, but if things are looking > better, how do you expect to merge this? There are significant portions > that touch at least 2 or 3 different subsystem trees, AFAICT. Tony could create an immutable branch with all the dts and memory changes. You could base the mtd changes on top of that? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: enable GPIO-a for Broadcom NSP
This enables the GPIO-a support for Broadcom NSP SoC
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
---
arch/arm/boot/dts/bcm-nsp.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..16e3c2b 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -116,4 +116,16 @@
status = "disabled";
};
};
+
+ gpioa: gpio-a@1820 {
+ compatible = "brcm,nsp-gpio-a";
+ reg = <0x1820 0x70>,
+ <0x1803f1c4 0x1c>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <32>;
+ interrupt-controller;
+ interrupts = ;
+ gpio-ranges = <&pinctrl 0 0 32>;
+ };
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] pinctrl: Broadcom NSP GPIO-a device tree bindings
Device tree binding documentation for Broadcom NSP GPIO-a driver
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
---
.../devicetree/bindings/pinctrl/brcm,nsp-gpio.txt | 80 ++
1 file changed, 80 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
new file mode 100644
index 000..bea4211
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
@@ -0,0 +1,80 @@
+Broadcom Northstar plus (NSP) GPIO/PINCONF Controller
+
+Required properties:
+- compatible:
+Must be "brcm,nsp-gpio-a"
+
+- reg:
+Should contain the register physical address and length for each of
+GPIO base, IO control registers
+
+- #gpio-cells:
+Must be two. The first cell is the GPIO pin number (within the
+controller's pin space) and the second cell is used for the following:
+bit[0]: polarity (0 for active high and 1 for active low)
+
+- gpio-controller:
+Specifies that the node is a GPIO controller
+
+- ngpios:
+Number of gpios supported (58x25 supports 32 and 58x23 supports 24)
+
+Optional properties:
+- interrupts:
+Interrupt ID
+
+- interrupt-controller:
+Specifies that the node is an interrupt controller
+
+- gpio-ranges:
+Specifies the mapping between gpio controller and pin-controllers pins.
+This requires 4 fields in cells defined as -
+1. Phandle of pin-controller.
+2. GPIO base pin offset.
+3 Pin-control base pin offset.
+4. number of gpio pins which are linearly mapped from pin base.
+
+Supported generic PINCONF properties in child nodes:
+- pins:
+The list of pins (within the controller's own pin space) that properties
+in the node apply to. Pin names are "gpio-"
+
+- bias-disable:
+Disable pin bias
+
+- bias-pull-up:
+Enable internal pull up resistor
+
+- bias-pull-down:
+Enable internal pull down resistor
+
+- drive-strength:
+Valid drive strength values include 2, 4, 6, 8, 10, 12, 14, 16 (mA)
+
+Example:
+
+ gpioa: gpio-a@1820 {
+ compatible = "brcm,nsp-gpio-a";
+ reg = <0x1820 0x100>,
+ <0x1803f1c4 0x1c>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <32>;
+ gpio-ranges = <&pinctrl 0 0 31>;
+ interrupt-controller;
+ interrupts = ;
+
+ /* Hog a few default settings */
+ pinctrl-names = "default";
+ pinctrl-0 = <&led>;
+ led: led {
+ pins = "gpio-1";
+ bias-pull-up;
+ };
+
+ pwr: pwr {
+ gpio-hog;
+ gpios = <3 1>;
+ output-high;
+ };
+ };
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/4] ARM: bcm2835: specify card detect pin for RPi B
On 11/19/2015 09:06 AM, Stefan Wahren wrote: > Only the Raspberry Pi B has a card detect pin. Specify it > on board level because it's not free to use. This seems fine, but it should have no effect in practice; when the SD controller driver gpio_get()s the GPIO, the same setting will be programmed into HW. There's a requirement to use the pinctrl bindings to configure pins to non-GPIO mux settings, but no actual requirement to do so for GPIOs. However, the new node sdhci_cd should be added to some pinctrl-0 property or it won't be used. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/4] ARM: bcm2835: rename sdhci pin group
On 11/19/2015 09:06 AM, Stefan Wahren wrote: > The node name of the sdhci pin group doesn't explain it's > real function. So rename it. The real function of this node is not to configure SDHCI pins, but to set pins to alt3, as the current name states. Admittedly it's possible that currently the only pins that need to be set to ALT3 are SDHCI related, but that's incidental. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/4] ARM: bcm2835: remove sdhci pins from GPIO pinctrl
On 11/19/2015 09:06 AM, Stefan Wahren wrote:
> Currently the pins alt3 (sdhci) are assigned to GPIO pinctrl.
> This is bad because a user could export it to sysfs and break
> sdhci. In order to avoid that remove those pins from GPIO pintrl.
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> &gpio {
> - pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
> + pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
This doesn't make sense. The current DT content is configuring those
pins as SDHCI, not as GPIO. Admitedly this is redundant since the
firmware and/or bootloader already did this in order to boot the system,
but irrespective, the current DT causes no issues. Removing the pinctrl
setting should not influence whether the pins can be exported via GPIO
sysfs either.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Roger, On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: > On 30/11/15 21:54, Brian Norris wrote: > > On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: > >> On 26/10/15 23:23, Brian Norris wrote: > >>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > This causes performance increase when using prefetch-irq mode. > 30% increase in read, 17% increase in write in prefetch-irq mode. > >>> > >>> Have you pinpointed the exact causes for the performance increase, or > >>> can you give an educated guess? AIUI, you're reducing the number of > >>> interrupts needed for NAND prefetch mode, but you're also removing a bit > >>> of abstraction and implementing hooks that look awfully like the > >>> existing abstractions: > >>> > >>> + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > >>> + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > >>> + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > >>> + u32 (*nand_irq_status)(void); > >>> > >>> That's not really a problem if there's a good reason for them (brcmnand > >>> implements similar hooks because of quirks in the implementation of > >>> interrupts across various BRCM SoCs, and it's not worth writing irqchip > >>> drivers for those cases). I'm mainly curious for an explanation. > >> > >> I have both implementations with me. My guess is that the 20% performance > >> gain is due to absence of irqchip/irqdomain translation code. > >> I haven't investigated further though. > > > > I don't have much context for whether this makes sense or not. According > > to your tests, you're getting ~800K interrupts over ~15 seconds. So > > should you start noticing performance hits due to abstraction at 53K > > interrupts per second? > > Yes, this was my understanding. Am I computing wrong, or is that a pretty insane rate of interrupts? > > But anyway, I'm not sure that completely answered my question. My > > question was whether you were removing the irqchip code solely for > > performance reasons, or are there others? > > Yes. Only for performance reasons. Hmm, that's not my favorite answer. I'd prefer that more analysis was done here before scrapping irqchip... But maybe that's not too bad. It seems like your patch set overall is a net positive for disentangling some of arch/ and drivers/. I'll take another pass over your patch set, but if things are looking better, how do you expect to merge this? There are significant portions that touch at least 2 or 3 different subsystem trees, AFAICT. Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] support the efuse for rk3188/rk3066a SoCs and cleanup driver on nvmem.
Hi Srinivas, What's the think of this series patches? Let me know if you have any suggestions or ideas.:-) Thanks! 在 2015年11月11日 15:34, Caesar Wang 写道: This patchset to support reading the efuse info for more SoCs. (Note: support 32 bits SoCs). Meanwhile, cleanup sunxi/rockchip drivers for more readability. You can easy to test for following: cd /sys/bus/nvmem/devices/rockchip-efuse0 localhost rockchip-efuse0 # busybox hexdump -C nvmem Caesar Wang (4): nvmem: sunxi: trivial: fix code style nvmem: rockchip: trivial: Make the driver more readability ARM: dts: rockchip: add eFuse node for rk3066a SoCs ARM: dts: rockchip: add eFuse node for rk3188 SoCs arch/arm/boot/dts/rk3066a.dtsi | 13 ++ arch/arm/boot/dts/rk3188.dtsi | 13 ++ drivers/nvmem/rockchip-efuse.c | 90 -- drivers/nvmem/sunxi_sid.c | 9 ++--- 4 files changed, 71 insertions(+), 54 deletions(-) -- caesar wang | software engineer | w...@rock-chip.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm64: dts: add all hi6220 i2c nodes
hi Shawn
On 2015/12/2 10:05, Shawn Guo wrote:
> On Thu, Nov 26, 2015 at 03:57:03PM +0800, Xinwei Kong wrote:
>> This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
>> use this I2C IP of Synopsys Designware for HiKey board.
>>
>> Signed-off-by: Xinwei Kong
>> ---
>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 37
>> +++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> index 82d2488..85d4a8b 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> @@ -208,5 +208,42 @@
>> clock-names = "uartclk", "apb_pclk";
>> status = "disabled";
>> };
>> +
>> +i2c0: i2c@f710 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf710 0x0 0x1000>;
>> +interrupts = <0 44 4>;
>> +clocks = <&sys_ctrl HI6220_I2C0_CLK>;
>> +clock-names = "clk_i2c0";
>
> Neither bindings doc i2c-designware.txt defines this property, nor
> kernel i2c-designware driver uses this property. So I think this
> clock-names property can just be dropped.
>
This property should been delete it. I will debug it in HiKey board then
send v3 patch.
Thank you
xinwei
> Otherwise, the patch looks good to me.
>
> Shawn
>
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
>> +status = "disabled";
>> +};
>> +
>> +i2c1: i2c@f7101000 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf7101000 0x0 0x1000>;
>> +interrupts = <0 45 4>;
>> +clocks = <&sys_ctrl HI6220_I2C1_CLK>;
>> +clock-names = "clk_i2c1";
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&i2c1_pmx_func &i2c1_cfg_func>;
>> +status = "disabled";
>> +};
>> +
>> +i2c2: i2c@f7102000 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf7102000 0x0 0x1000>;
>> +interrupts = <0 46 4>;
>> +clocks = <&sys_ctrl HI6220_I2C2_CLK>;
>> +clock-names = "clk_i2c2";
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&i2c2_pmx_func &i2c2_cfg_func>;
>> +status = "disabled";
>> +};
>> +
>> };
>> };
>> --
>> 1.9.1
>>
>>
>>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm64: dts: qcom: Add apq8096 dragonboard dts skeletons
On 12/02/2015 02:59 AM, Bryan Huntsman wrote: > On 12/01/2015 08:11 AM, Rajendra Nayak wrote: >> Add new dtsi and dts files for the apq8096 dragonboards with just >> a serial device used as debug console >> >> While at it, also rearrange the Makefile so we have one dtb per line >> so as to be consistent with whats done on other platforms. >> >> Signed-off-by: Rajendra Nayak >> --- >> arch/arm64/boot/dts/qcom/Makefile | 4 ++- >> arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts | 21 >> arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 >> +++ >> 3 files changed, 54 insertions(+), 1 deletion(-) >> create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts >> create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi > > One problem. The board you have is not called a dragonboard. Let's > check with the marketing folks on what they're calling it now. We need > to explicitly avoid using dragonboard here as that name applies to a > different class of products. Thanks. Thanks Bryan, I'll update with the new board name. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] ASoC: cygnus: Add Cygnus audio DAI driver
On 11/22/2015 5:44 AM, Mark Brown wrote:
On Mon, Nov 09, 2015 at 04:17:43PM -0800, Simran Rai wrote:
+#ifdef CONFIG_PM_SLEEP
+static int cygnus_ssp_suspend(struct snd_soc_dai *cpu_dai)
+{
+ struct cygnus_aio_port *aio = cygnus_dai_get_portinfo(cpu_dai);
+ struct cygnus_audio *cygaud = snd_soc_dai_get_drvdata(cpu_dai);
+
+ audio_ssp_out_disable(aio);
+ audio_ssp_in_disable(aio);
+ if (cygaud->active_ports > 0)
+ cygaud->active_ports--;
+
+ return 0;
+}
+
+static int cygnus_ssp_resume(struct snd_soc_dai *cpu_dai)
+{
+ return 0;
+}
I'm a bit confused here - why do we need to disable things on suspend
but not reenable them on resume? I'd expect that the core would have
quiesced any streams that need to be suspended before we get as far as
suspending the drivers.
Please also remove empty functions.
Now I check I see that I'm repeating the questions I had on my previous
review:
| Blank line between functions and remove empty functions. Though I'm not
| clear why the result doesn't undo what the suspend did...
Please don't ignore review comments.
Let me investigate this further and debug why the core did not
quiescence the streams.
+ parent = clk_get_parent(cygaud->audio_clk[0]);
+ if (IS_ERR(parent)) {
+ error = PTR_ERR(parent);
+ goto err_get_parent;
+ }
+
+ /* Set PLL VCO Frequency (Hz) to default */
+ error = clk_set_rate(parent, DEFAULT_VCO);
+ if (error) {
+ dev_err(&pdev->dev,
+ "%s Set PLL VCO rate failed: %d\n", __func__, error);
+ goto err_get_parent;
+ }
I would expect any initialisationn of clocks beyond the ones that the
device directly interacts with to be handled within the clock API
configuration rather than in a specific driver, this avoids the driver
being dependent on a particular system integration.
I will have to figure out a way to propagate the frequency from leaf clocks to
the parent
clock. Will send out another patch with the fix.
Thanks,
Simran
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: dts: imx6q-icore-rqs: Add Engicam IMX6 Q7 initial support
On Wed, Nov 25, 2015 at 07:14:13PM +0100, Michael Trimarchi wrote:
> Hi Shawn
>
> On Wed, Nov 18, 2015 at 4:10 PM, Michael Trimarchi
> wrote:
> > www.engicam.com/en/products/embedded/som/standard/i-core-rqs-m6s-dl-d-q
> >
> > Signed-off-by: Michael Trimarchi
> > ---
> > I'm not quite sure how ethernet tuning parameter
> > are working in other setup and this seems the
> > correct way to use it
> >
>
> As you can see my way to connect the ethernet phy is different. I have
> seen that most of the boards put all the tuning under fec but unfortunately
> this does not work. I don't know if people check if their value are correctly
> written to the phy.
Hmm, I'm not sure what example you are looking at. But here is what I
see from arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
phy-reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
<&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
status = "okay";
};
Shawn
>
> > +
> > +&fec {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_enet_3>;
> > + phy-handle = <ð_phy>;
> > + phy-mode = "rgmii";
> > + status = "okay";
> > + mdio {
> > + eth_phy: ethernet-phy {
> > + rxc-skew-ps = <1140>;
> > + txc-skew-ps = <1140>;
> > + txen-skew-ps = <600>;
> > + rxdv-skew-ps = <240>;
> > + rxd0-skew-ps = <420>;
> > + rxd1-skew-ps = <600>;
> > + rxd2-skew-ps = <420>;
> > + rxd3-skew-ps = <240>;
> > + txd0-skew-ps = <60>;
> > + txd1-skew-ps = <60>;
> > + txd2-skew-ps = <60>;
> > + txd3-skew-ps = <240>;
> > + };
> > + };
> > +};
> > +
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm64: dts: add all hi6220 i2c nodes
On Thu, Nov 26, 2015 at 03:57:03PM +0800, Xinwei Kong wrote:
> This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
> use this I2C IP of Synopsys Designware for HiKey board.
>
> Signed-off-by: Xinwei Kong
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 37
> +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 82d2488..85d4a8b 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -208,5 +208,42 @@
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
> +
> + i2c0: i2c@f710 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf710 0x0 0x1000>;
> + interrupts = <0 44 4>;
> + clocks = <&sys_ctrl HI6220_I2C0_CLK>;
> + clock-names = "clk_i2c0";
Neither bindings doc i2c-designware.txt defines this property, nor
kernel i2c-designware driver uses this property. So I think this
clock-names property can just be dropped.
Otherwise, the patch looks good to me.
Shawn
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@f7101000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7101000 0x0 0x1000>;
> + interrupts = <0 45 4>;
> + clocks = <&sys_ctrl HI6220_I2C1_CLK>;
> + clock-names = "clk_i2c1";
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pmx_func &i2c1_cfg_func>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@f7102000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7102000 0x0 0x1000>;
> + interrupts = <0 46 4>;
> + clocks = <&sys_ctrl HI6220_I2C2_CLK>;
> + clock-names = "clk_i2c2";
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pmx_func &i2c2_cfg_func>;
> + status = "disabled";
> + };
> +
> };
> };
> --
> 1.9.1
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] ARM: BCM: Clean up SMP support for Broadcom Kona
On 01/12/15 08:24, Kapil Hali wrote: > These changes cleans up SMP implementaion for Broadcom's > Kona SoC which are required for handling SMP for iProc > family of SoCs at a single place for BCM NSP and BCM Kona. FWIW, I gave this patch a try on a Capri board, and this still brings-up the two CPUs successfully: MMC read: dev # 0, block # 114688, count 32768 ... 100% (32768/32768 blocks) 32768 blocks read: OK ## Starting application at 0x80008000 ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.4.0-rc1-5-ge49c96ed573e (fainelli@fainelli-desktop) (gcc version 4. 8.5 (Broadcom stbgcc-4.8-1.4) ) #605 SMP Tue Dec 1 17:53:02 PST 2015 [0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: BCM28155 AP board [0.00] cma: Reserved 16 MiB at 0xbf00 [0.00] Memory policy: Data cache writealloc [0.00] PERCPU: Embedded 12 pages/cpu @ef7d3000 s18752 r8192 d22208 u49152 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260608 [0.00] Kernel command line: console=ttyS0,115200n8 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1009696K/1048576K available (6384K kernel code, 279K rwdata, 2268K rodata, 4152 K init, 218K bss, 22496K reserved, 16384K cma-reserved, 245760K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc087b694 (8654 kB) [0.00] .init : 0xc087c000 - 0xc0c8a000 (4152 kB) [0.00] .data : 0xc0c8a000 - 0xc0ccfdf8 ( 280 kB) [0.00].bss : 0xc0cd2000 - 0xc0d08bac ( 219 kB) [0.00] Hierarchical RCU implementation. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] __ccu_wait_bit: slave_ccu/0x0484 bit 18 was never set [0.00] __peri_clk_init: error initializing gate for bsc3 [0.00] Broadcom slave_ccu initialization had errors [0.00] sched_clock: 32 bits at 1kHz, resolution 100ns, wraps every 214748364750ns [0.00] Console: colour dummy device 80x30 [0.006000] Calibrating delay loop... 2383.87 BogoMIPS (lpj=1191936) [0.006000] pid_max: default: 32768 minimum: 301 [0.006000] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.006000] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.006000] CPU: Testing write buffer coherency: ok [0.006000] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.006000] Setting up static identity map for 0x800082c0 - 0x80008318 [0.015000] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.015000] Brought up 2 CPUs [0.015000] SMP: Total of 2 processors activated (7200.76 BogoMIPS). [0.015000] CPU: All CPU(s) started in SVC mode. [0.015000] devtmpfs: initialized [0.016000] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [0.016000] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 19112604462 75000 ns [0.016000] pinctrl core: initialized pinctrl subsystem [0.017000] NET: Registered protocol family 16 [0.017000] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.023000] cpuidle: using governor ladder [0.025000] cpuidle: using governor menu [0.026000] Kona Secure API initialized [0.026000] BCM-L2C-310 cache controller enabled, 16 ways, 512 kB [0.026000] BCM-L2C-310: CACHE_ID 0x41c8, AUX_CTRL 0x1e05 [0.026000] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [0.026000] hw-breakpoint: maximum watchpoint size is 4 bytes. [0.033000] SCSI subsystem initialized [0.033000] usbcore: registered new interface driver usbfs [0.033000] usbcore: registered new interface driver hub [0.033000] usbcore: registered new device driver usb [0.033000] Linux video capture interface: v2.00 [0.033000] pps_core: LinuxPPS API ver. 1 registered [0.033000] pps_core: Software ver. 5.3.6 - Copyright 2005-2
Re: [PATCH 11/19] ARM: dts: imx: replace legacy *,wakeup property with wakeup-source
On Thu, Nov 26, 2015 at 11:33:50AM +, Sudeep Holla wrote: > > > On 23/11/15 05:37, Shawn Guo wrote: > >On Wed, Oct 21, 2015 at 11:10:08AM +0100, Sudeep Holla wrote: > >>Though the keyboard and other driver will continue to support the legacy > >>"gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup > >>source, "wakeup-source" is the new standard binding. > >> > >>This patch replaces all the legacy wakeup properties with the unified > >>"wakeup-source" property in order to avoid any futher copy-paste > >>duplication. > >> > >>Cc: Shawn Guo > >>Cc: Sascha Hauer > >>Signed-off-by: Sudeep Holla > > > > > > > >>diff --git a/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi > >>b/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi > >>index 321662f53e33..16fc69c69ab2 100644 > >>--- a/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi > >>+++ b/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi > >>@@ -156,7 +156,7 @@ > >>pinctrl-names = "default"; > >>pinctrl-0 = <&pinctrl_esdhc2>; > >>cap-sdio-irq; > >>- enable-sdio-wakeup; > >>+ wakeup-source; > > > >I do not see this be mentioned in commit log. I do not see relevant > >kernel changes in v4.4-rc1 to support that. Am I missing anything? > > > > Sorry for that, you weren't copied on that patch[1], Ulf has queued it > now [2] My branch is based on v4.4-rc1 which doesn't have that patch. That said, I can not apply it for now. Shawn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 2/9] ARM: EXYNOS: Exynos SoC/mach specific code for v4.5
Hi Kukjin,
SoC/mach specific code.
Best regards,
Krzysztof
The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
tags/samsung-soc-4.5
for you to fetch changes up to 8438aef01d3560549b3a95d247b3a69311fa6f2d:
ARM: EXYNOS: Remove redundant code from regs-pmu.h (2015-11-20 16:00:47 +0900)
Samsung Exynos improvements for 4.5:
1. Switch from Exynos-specific restart/poweroff handler
(mach-exynos/pmu.c) to generic syscon-reboot and syscon-poweroff
drivers.
This depends on adding syscon nodes to DTS to preserve
bisectability.
2. Minor improvements.
Alim Akhtar (5):
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos3250
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos4
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos5
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos5410
ARM: EXYNOS: Switch to syscon reboot and poweroff
Krzysztof Kozlowski (2):
Merge tag 'samsung-dt-syscon-restart-4.5' into next/soc
ARM: EXYNOS: Constify local exynos_pmu_data structure
Pankaj Dubey (1):
ARM: EXYNOS: Remove redundant code from regs-pmu.h
arch/arm/boot/dts/exynos3250.dtsi | 14
arch/arm/boot/dts/exynos4.dtsi| 14
arch/arm/boot/dts/exynos5.dtsi| 14
arch/arm/boot/dts/exynos5410.dtsi | 14
arch/arm/mach-exynos/Kconfig | 3 +++
arch/arm/mach-exynos/pmu.c| 45 ++-
arch/arm/mach-exynos/regs-pmu.h | 9
7 files changed, 61 insertions(+), 52 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 09/15] PM / devfreq: exynos: Update documentation for bus devices using passive governor
Hi Rob, I'm sorry for delay reply due to the problem of email system on the company. On 2015년 12월 01일 06:14, Rob Herring wrote: > On Thu, Nov 26, 2015 at 10:47:33PM +0900, Chanwoo Choi wrote: >> This patch updates the documentation for passive bus devices and adds the >> detailed example of Exynos3250. >> >> Signed-off-by: Chanwoo Choi >> --- >> .../devicetree/bindings/devfreq/exynos-bus.txt | 226 >> - >> 1 file changed, 223 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> index 5d90623bd173..c4a6fe30075e 100644 >> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> @@ -12,18 +12,23 @@ SoC has the different sub-blocks. So, this difference >> should be specified >> in devicetree file instead of each device driver. In result, this driver >> is able to support the bus frequency for all Exynos SoCs. >> >> -Required properties for bus device: >> +Required properties for all bus devices: >> - compatible: Should be "samsung,exynos-bus". >> - clock-names : the name of clock used by the bus, "bus". >> - clocks : phandles for clock specified in "clock-names" property. >> - #clock-cells: should be 1. >> - operating-points-v2: the OPP table including frequency/voltage information >>to support DVFS (Dynamic Voltage/Frequency Scaling) feature. >> + >> +Required properties for only parent bus device: >> - vdd-supply: the regulator to provide the buses with the voltage. >> - devfreq-events: the devfreq-event device to monitor the curret utilization >>of buses. >> >> -Optional properties for bus device: >> +Required properties for only passive bus device: >> +- devfreq: the parent bus device. >> + >> +Optional properties for only parent bus device: >> - exynos,saturation-ratio: the percentage value which is used to calibrate >> the performance count againt total cycle count. >> >> @@ -32,7 +37,19 @@ Example1: >> power line (regulator). The MIF (Memory Interface) AXI bus is used to >> transfer data between DRAM and CPU and uses the VDD_MIF regualtor. >> >> -- power line(VDD_MIF) --> bus for DMC block (dmc clock) >> +- MIF (Memory Interface) block >> +: VDD_MIF |--- DMC >> + >> +- INT (Internal) block >> +: VDD_INT |--- LEFTBUS |--- PERIL >> + |(parent) |--- MFC >> + | |--- G3D >> + | >> + |--- RIGHTBUS |--- FSYS >> +|--- LCD0 >> +|--- PERIR >> +|--- ISP >> +|--- CAM > > I would expect the DT to mirror this topology which doesn't seem to be > the case in the example. You're right. The above topology is not appropriate to show the correlation between power line and sub blocks. I'll modify it as following. The all blocks which are included in the INT (internal) block share the one power line (VDD_INT). VDD_MIF |--- DMC VDD_INT |--- LEFTBUS |--- PERIL |--- MFC |--- G3D |--- RIGHTBUS |--- FSYS |--- LCD0 |--- PERIR |--- ISP |--- CAM > > >> - MIF bus's frequency/voltage table >> --- >> @@ -45,6 +62,20 @@ Example1: >> |L5| 40 |875000 | >> --- >> >> +- INT bus's frequency/voltage table >> +--- >> +|Lv| Freq | Voltage | >> +--- >> +| |LEFTBUS|RIGHTBUS|LCD0 |FSYS |MCUISP |ISP|PERIL |VDD_INT | >> +| |*parent|passive |passive|passive|passive|passive|passive| | >> +--- >> +|L1|5 |5 |5 |5 |5 |5 |5 |90 | >> +|L2|8 |8 |8 |8 |8 |8 |8 |90 | >> +|L3|10 |10 |10 |10 |10 |10 |10 |100 | >> +|L4|133000 |133000 |133000 |133000 |20 |20 | |100 | >> +|L5|20 |20 |20 |20 |40 |30 | |100 | >> +--- > > Do you really have 5 states? It look like there are 2 to me because the > OPP tables only really need to have the max freq at each voltage point. I'm sure. The OPP allow OPP table to add the same voltage for each OPP entry. Instead, OPP don't permit adding the duplicate frequency. If OPP table includes the different frequency as OPP entry, there is no problem. It is tested. Regards,
[GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5
Hi Kukjin, Pinctrl for v4.5. Best regards, Krzysztof The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-4.5 for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36: pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 +0900) Exynos-specific drivers for 4.5: 1. Add a pinctrl driver for Exynos5410. Hakjoo Kim (1): pinctrl: exynos: add exynos5410 SoC specific data .../bindings/pinctrl/samsung-pinctrl.txt | 1 + drivers/pinctrl/samsung/pinctrl-exynos.c | 103 + drivers/pinctrl/samsung/pinctrl-samsung.c | 2 + drivers/pinctrl/samsung/pinctrl-samsung.h | 1 + 4 files changed, 107 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 6/9] ARM: EXYNOS: clk: Another clock dependency, ARMv7, for v4.5
Hi Kukjin, This is also clock dependency. I put it in separate tag in case clock folks want to pull it also. Best regards, Krzysztof The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-exynos4-4.5 for you to fetch changes up to 94af7a3c310f5877dc6f756179b92f24f89a9b08: clk: samsung: exynos4: Add SSS gate clock (2015-11-18 22:02:02 +0900) Add a Security SubSystem (SSS) clock for Exynos4, needed by exynos-rng driver (Pseudo Random Number Generator). Krzysztof Kozlowski (1): clk: samsung: exynos4: Add SSS gate clock drivers/clk/samsung/clk-exynos4.c | 1 + include/dt-bindings/clock/exynos4.h | 1 + 2 files changed, 2 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 3/9] ARM64: EXYNOS: clk: Clock dependency for ARM64 for v4.5
Hi Kukjin, Dependency for soc64 changes. Best regards, Krzysztof The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-arm64-symbols-4.5 for you to fetch changes up to 8c2a90ed18a74e8b9cdbba679403faa44d6024fc: clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2015-11-22 19:25:29 +0900) Remove CONFIG_ARCH_EXYNOS7 symbol from Samsung clocks and instead build all drivers for ARM64 SoCs under CONFIG_EXYNOS_ARM64_COMMON_CLK. After the commit there will be no more users of CONFIG_ARCH_EXYNOS7 except ARM64 mach code. Krzysztof Kozlowski (1): clk: samsung: Don't build ARMv8 clock drivers on ARMv7 drivers/clk/samsung/Kconfig | 6 ++ drivers/clk/samsung/Makefile | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 1/9] ARM: EXYNOS: dts: Syscon dependency for v4.5
Hi Kukjin,
The DT changes are needed before switching to syscon-based reboot
and power off method.
Best regards,
Krzysztof
The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
tags/samsung-dt-syscon-restart-4.5
for you to fetch changes up to 35135f4b95f03be7ebbf31221ce738f1ec0faa02:
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos5410 (2015-11-20
15:58:44 +0900)
Device Tree changes adding necessary nodes for syscon reboot/poweroff
handlers on Exynos boards. The mach-exynos changes must base on top
of this to retain the bisectability of not loosing reboot/poweroff
features.
Alim Akhtar (4):
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos3250
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos4
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos5
ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos5410
arch/arm/boot/dts/exynos3250.dtsi | 14 ++
arch/arm/boot/dts/exynos4.dtsi| 14 ++
arch/arm/boot/dts/exynos5.dtsi| 14 ++
arch/arm/boot/dts/exynos5410.dtsi | 14 ++
4 files changed, 56 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 4/9] ARM64: EXYNOS: Soc specific code for v4.5
Hi Kukjin, ARM64 change touch also defconfig. Best regards, Krzysztof The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc64-4.5 for you to fetch changes up to db44c07a3f0b32815bd1f3e731db9e043e57cf9c: arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS (2015-11-22 19:31:30 +0900) Samsung Exynos ARM64 improvements: 1. Use just one Kconfig symbol for Exynos SoC: ARCH_EXYNOS. This depends on change in drivers/clk where the old ARCH_EXYNOS7 was used. Krzysztof Kozlowski (3): clk: samsung: Don't build ARMv8 clock drivers on ARMv7 Merge tag 'samsung-clk-arm64-symbols-4.5' into next/soc64 arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS arch/arm64/Kconfig.platforms| 11 ++- arch/arm64/boot/dts/exynos/Makefile | 2 +- arch/arm64/configs/defconfig| 2 +- drivers/clk/samsung/Kconfig | 6 ++ drivers/clk/samsung/Makefile| 4 ++-- 5 files changed, 12 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 9/9] ARM: EXYNOS: Defconfig for v4.5
Hi Kukjin, This may conflict with other arm-soc updates... Best regards, Krzysztof The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.5 for you to fetch changes up to 00a5e81fff2d81c3b1bf45712d3a12c905bc7c66: ARM: exynos_defconfig: Set recommended options for systemd (2015-12-01 08:28:44 +0900) Defconfig (exynos and multi_v7) changes for Exynos based boards for 4.5: 1. Enable Maxim 8997 and 77693 family drivers (charger, extcon, LED, RTC, haptic/motor, regulator). 2. Build ChromeOS EC drivers as modules on multi_v7. 3. Enable drivers important for Exynos4210-based Universal C210 board. 4. Enable NFSv4 client. 5. On exynos_defconfig set some options to a value recommended by systemd. This also makes it more consistent with multi_v7. Javier Martinez Canillas (1): ARM: multi_v7_defconfig: Build ChromeOS EC drivers as modules Krzysztof Kozlowski (6): ARM: exynos_defconfig: Enable Maxim 8997 family drivers ARM: exynos_defconfig: Enable Maxim 77693 LED and haptic drivers ARM: multi_v7_defconfig: Enable Maxim 8997 family drivers ARM: multi_v7_defconfig: Enable Maxim 77693 LED and haptic drivers ARM: exynos_defconfig: Enable NFSv4 client ARM: exynos_defconfig: Set recommended options for systemd Marek Szyprowski (1): ARM: exynos_defconfig: Add drivers for Exynos4210 Universal C210 board arch/arm/configs/exynos_defconfig | 18 -- arch/arm/configs/multi_v7_defconfig | 15 --- 2 files changed, 28 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 8/9] ARM64: EXYNOS: dts: DeviceTree for ARM64 for v4.5
Hi Kukjin, Few changes for Espresso board. Best regards, Krzysztof The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.5 for you to fetch changes up to fb026cb6524744c8bd0f133f4b0d8e2595d04e15: arm64: dts: Add reboot node for exynos7 (2015-11-18 22:47:16 +0900) Samsung DeviceTree ARM64 updates and improvements for 4.5: 1. Add S2MPS15 PMIC node to Espresso board. This gives proper control over regulators, provides 32KHz clocks and RTC driver. 2. Enable HS200 mode operation on Espresso board for MMC0. 3. Add reboot capability (generic syscon-reboot). Alim Akhtar (3): arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso arm64: dts: Enable HS200 mode operation on exynos7-espresso arm64: dts: Add reboot node for exynos7 arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 282 +++- arch/arm64/boot/dts/exynos/exynos7.dtsi | 7 + 2 files changed, 288 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 7/9] ARM: EXYNOS: dts: DeviceTree for v4.5
Hi Kukjin, A lot of stuff here, mostly cleanups. Description in tag. Best regards, Krzysztof The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.5 for you to fetch changes up to 2cf107f1033e0343d45b59d06f16487c8362702f: ARM: dts: Unify G2D device node with other devices on exynos4 (2015-11-30 17:00:43 +0900) Samsung DeviceTree updates and improvements for 4.5: 1. Pinctrl for Exynos5410. 2. eMMC/SDIO minor fixes usage of bindings on Snow and Peach Chromebooks. 3. Remove FIMD from Odroid XU3-family because on XU3 it cannot be used yet and on XU3-Lite and XU4 it is not supported. 4. Remove deprecated since June 2013 samsung,exynos5-hdmi. 5. Add support for Pseudo Random Generator on Exynos4 (Trats2 for now). This depends on new SSS clock. 6. Add rotator nodes for Exynos4 and Exynos5. 7. Switch DWC3_1 on Odroid XU3 and XU3-Lite to peripheral mode because now it cannot be used as OTG. 8. Cleanup the G2D usage on Exynos4 and add it to a proper domain in case of Exynos4210. 9. Put MDMA1 in proper domain on Exynos4210 as well. 10. Minor cleanups. Andrzej Hajda (1): dt-bindings: remove deprecated compatible string from exynos-hdmi Hakjoo Kim (1): ARM: dts: Add pinctrl support to exynos5410 Javier Martinez Canillas (7): ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common ARM: dts: Remove unneeded GPIO include in exynos4412-odroidu3 Krzysztof Kozlowski (4): clk: samsung: exynos4: Add SSS gate clock Merge tag 'samsung-clk-exynos4-4.5' into next/dt ARM: dts: Add PRNG module for exynos4 ARM: dts: Enable PRNG module on exynos4412-trats2 Marek Szyprowski (10): ARM: dts: Remove fimd node from exynos5422-odroidxu3-common ARM: dts: Add rotator nodes on exynos4 ARM: dts: Fix power domain for sysmmu-rotator device on exynos4 ARM: dts: Add rotator node on exynos5250 ARM: dts: Add rotator node on exynos5420 ARM: dts: Use peripheral mode for dwc3_1 on exynos5422-odroidxu3 ARM: dts: exynos4210-universal_c210: Disable DMA for UARTs ARM: dts: MDMA1 device belongs to LCD0 power domain on exynos4210 ARM: dts: Add power domain to G2D device on exynos4210 ARM: dts: Unify G2D device node with other devices on exynos4 .../bindings/display/exynos/exynos_hdmi.txt| 7 +- arch/arm/boot/dts/exynos4.dtsi | 18 +- arch/arm/boot/dts/exynos4210-origen.dts| 4 - arch/arm/boot/dts/exynos4210-smdkv310.dts | 4 - arch/arm/boot/dts/exynos4210-universal_c210.dts| 8 + arch/arm/boot/dts/exynos4210.dtsi | 14 +- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 4 - arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 - arch/arm/boot/dts/exynos4412-origen.dts| 4 - arch/arm/boot/dts/exynos4412-smdk4412.dts | 4 - arch/arm/boot/dts/exynos4412-trats2.dts| 4 + arch/arm/boot/dts/exynos4x12.dtsi | 5 +- arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 +- arch/arm/boot/dts/exynos5250.dtsi | 9 + arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 406 + arch/arm/boot/dts/exynos5410.dtsi | 36 ++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 +- arch/arm/boot/dts/exynos5420.dtsi | 19 + arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 5 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts| 2 +- arch/arm/boot/dts/exynos5422-odroidxu3.dts | 2 +- arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +- drivers/clk/samsung/clk-exynos4.c | 1 + include/dt-bindings/clock/exynos4.h| 1 + 24 files changed, 527 insertions(+), 47 deletions(-) create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 0/9] ARM: EXYNOS: Pull request for v4.5
Hi Kukjin, A lot of stuff for v4.5 with 3 dependencies split into separate tags. The need for dependency is explained both in merge-commit and in description of a tag which is using the dependency. The order goes like (but of course dependencies could be pulled all at once at beginning): 1. tags/samsung-dt-syscon-restart-4.5 2. tags/samsung-soc-4.5 3. tags/samsung-clk-arm64-symbols-4.5 4. tags/samsung-soc64-4.5 5. tags/samsung-drivers-4.5 6. tags/samsung-clk-exynos4-4.5 7. tags/samsung-dt-4.5 8. tags/samsung-dt64-4.5 9. tags/samsung-defconfig-4.5 I split dependencies to three tags so clock or other folks could easily grab them if needed. Please share your comments or pull as early as possible as we have here some more dependencies than usual. Kind regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dmaengine: usb-dmac: Document SoC specific bindings
On Tue, Dec 01, 2015 at 09:33:09AM +0100, Geert Uytterhoeven wrote: > On Tue, Dec 1, 2015 at 7:47 AM, Simon Horman wrote: > > On Wed, Nov 25, 2015 at 09:20:32AM +0900, Simon Horman wrote: > >> On Tue, Nov 24, 2015 at 02:16:55PM -0600, Rob Herring wrote: > >> > On Tue, Nov 24, 2015 at 11:20:41AM +0900, Simon Horman wrote: > >> > > In general Renesas hardware is not documented to the extent where the > >> > > relationship between IP blocks on different SoCs can be assumed > >> > > although > >> > > they may appear to operate the same way. Furthermore the documentation > >> > > typically does not specify a version for individual IP blocks. For > >> > > these > >> > > reasons a convention of using the SoC name in place of a version and > >> > > providing SoC-specific compat strings has been adopted. > >> > > > >> > > Although not universally liked this convention is used in the bindings > >> > > for > >> > > most drivers for Renesas hardware. The purpose of this patch is to > >> > > update the Renesas USB DMA Controller driver to follow this convention. > >> > > > >> > > Cc: devicetree@vger.kernel.org > >> > > Cc: Yoshihiro Shimoda > >> > > Signed-off-by: Simon Horman > >> > > > >> > > --- > >> > > * r8a7792 (R-Car V2H) is omitted as my reading of the documentation > >> > > is that Renesas USB-DMAC does not exist on that SoC > >> > > * r8a7795 (R-Car H2) is omitted as its unclear to me on the > >> > > compatibility > >> > > of USB-DMAC that SoC > >> > > > >> > > * Once this has been merged I intend to provide follow-up patches > >> > > to use these new compat strings in the relevant dtsi files. > >> > > --- > >> > > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 9 > >> > > +++-- > >> > > 1 file changed, 7 insertions(+), 2 deletions(-) > >> > > > >> > > diff --git > >> > > a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > >> > > b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > >> > > index 040f365954cc..3bb624e10615 100644 > >> > > --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > >> > > +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > >> > > @@ -1,7 +1,12 @@ > >> > > * Renesas USB DMA Controller Device Tree bindings > >> > > > >> > > Required Properties: > >> > > -- compatible: must contain "renesas,usb-dmac" > >> > > +- compatible: "renesas,usb-dmac-", "renesas,usb-dmac" as > >> > > fallback. > >> > > + Examples with soctypes are: > >> > > + - "renesas,usb-dmac-r8a7790" (R-Car H2) > >> > > + - "renesas,usb-dmac-r8a7791" (R-Car M2-W) > >> > > + - "renesas,usb-dmac-r8a7793" (R-Car M2-N) > >> > > + - "renesas,usb-dmac-r8a7794" (R-Car E2) > >> > > >> > Weren't you changing the order of SoC and block names on new bindings? > >> > >> Could you clarify what the desired order is? > >> My intention is for these bindings to use the preferred order. > > > > ping > > Not speaking for Rob, but I think he means e.g. "renesas,r8a7790-usb-dmac". Thanks. Reviewing previous emails I see that now. I will see about making it so. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 net-next] ravb: Add fallback compatibility strings
On Tue, Dec 01, 2015 at 09:42:52AM +0100, Geert Uytterhoeven wrote: > On Tue, Dec 1, 2015 at 8:43 AM, Simon Horman > wrote: > > Add fallback compatibility strings for R-Car Gen 2 & 3 SoC Families. > > This is in keeping with the fallback scheme being adopted wherever > > appropriate for drivers for Renesas SoCs. > > > > Also correct typo. > > > > Signed-off-by: Simon Horman > > --- > > Documentation/devicetree/bindings/net/renesas,ravb.txt | 11 +-- > > drivers/net/ethernet/renesas/ravb_main.c | 2 ++ > > 2 files changed, 11 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt > > b/Documentation/devicetree/bindings/net/renesas,ravb.txt > > index b486f3f5f6a3..115006325bff 100644 > > --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt > > +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt > > @@ -1,12 +1,19 @@ > > * Renesas Electronics Ethernet AVB > > > > This file provides information on what the device node for the Ethernet AVB > > -interface contains. > > +interface. > > > > Required properties: > > - compatible: "renesas,etheravb-r8a7790" if the device is a part of > > R8A7790 SoC. > > "renesas,etheravb-r8a7794" if the device is a part of R8A7794 > > SoC. > > "renesas,etheravb-r8a7795" if the device is a part of R8A7795 > > SoC. > > + "renesas,etheravb-gen2" for generic R-Car Gen 2 compatible > > interface. > > + "renesas,etheravb-gen3" for generic R-Car Gen 3 compatible > > interface. > > + > > (Same comment, different audience) > > Shouldn't that be "renesas,etheravb-rcar-gen" or "renesas,etheravb-rcar2"? > > Else you'll be in trouble when Renesas starts focussing on airplanes > (R-Plane Gen2), rockets (R-Rocket Gen2), or IoT (R-IoT Gen2). Sure, lets go with: renesas,etheravb-rcar-gen2 and renesas,etheravb-rcar-gen3. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string
On Tue, Dec 01, 2015 at 09:41:49AM +0100, Geert Uytterhoeven wrote: > On Tue, Dec 1, 2015 at 8:24 AM, Simon Horman > wrote: > > Add fallback compatibility string for R-Car Gen 2 Family. > > This is in keeping with the fallback scheme being adopted wherever > > appropriate for drivers for Renesas SoCs. > > > > Signed-off-by: Simon Horman > > --- > > Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +-- > > drivers/pci/host/pci-rcar-gen2.c| 1 + > > 2 files changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > > b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > > index 891463cb09c2..b19be08a8113 100644 > > --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > > +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > > @@ -8,7 +8,14 @@ OHCI and EHCI controllers. > > Required properties: > > - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC; > > "renesas,pci-r8a7791" for the R8A7791 SoC; > > - "renesas,pci-r8a7794" for the R8A7794 SoC. > > + "renesas,pci-r8a7794" for the R8A7794 SoC; > > + "renesas,pci-gen2" for a generic R-Car Gen2 compatible device. > > Shouldn't that be "renesas,pci-rcar-gen" or "renesas,pci-rcar2"? > > Else you'll be in trouble when Renesas starts focussing on airplanes > (R-Plane Gen2), rockets (R-Rocket Gen2), or IoT (R-IoT Gen2). Point taken. I think renesas,pci-rcar-gen2 should work well enough. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 net-next] ravb: Add fallback compatibility strings
On Tue, Dec 01, 2015 at 01:26:08PM +0300, Sergei Shtylyov wrote: > Hello. > > On 12/1/2015 10:43 AM, Simon Horman wrote: > > >Add fallback compatibility strings for R-Car Gen 2 & 3 SoC Families. > >This is in keeping with the fallback scheme being adopted wherever > >appropriate for drivers for Renesas SoCs. > > > >Also correct typo. > > > >Signed-off-by: Simon Horman > >--- > > Documentation/devicetree/bindings/net/renesas,ravb.txt | 11 +-- > > drivers/net/ethernet/renesas/ravb_main.c | 2 ++ > > 2 files changed, 11 insertions(+), 2 deletions(-) > > > >diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt > >b/Documentation/devicetree/bindings/net/renesas,ravb.txt > >index b486f3f5f6a3..115006325bff 100644 > >--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt > >+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt > >@@ -1,12 +1,19 @@ > > * Renesas Electronics Ethernet AVB > > > > This file provides information on what the device node for the Ethernet AVB > >-interface contains. > >+interface. > >Why? Because I miss read it (multiple times). I'll drop this change. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Addition of binding for firmware signals on peach-pi
On 02.12.2015 04:12, Martyn Welch wrote:
> The peach pi has a GPIO connected to the firmware write protect, developer
> mode and recovery mode lines. This patch adds the required nodes to the
> device tree to configure the pinmuxing and allow these to be read from
> user space.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Russell King
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Martyn Welch
> ---
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 40
> +++
> 1 file changed, 40 insertions(+)
Hi,
Thanks for the patch.
Few points from my side:
1. Please add a prefix to the subject: "ARM: dts:".
2. There is no need of such huge CC-list in the body of commit. This
CC-list comes from get_maintainer so there is no benefit of duplicating
it here. The CC is usually used to notify other people who might be
interested but get_maintainer does not point them.
3. I received only this third patch. I did not receive cover letter
explaining possible dependencies so I am not sure how to deal with the
patch. It looks like there are no dependencies... but maybe there are?
Is this is a new binding or no? Please provide a cover letter (if it
exists already be sure to send it to all interested parties) or send
entire patchset so the big picture could be seen.
The patch itself looks good but I'll wait with a review tag for #3.
Best regards,
Krzysztof
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 49a4f43..485c18f 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -53,6 +53,25 @@
> };
> };
>
> + chromeos-firmware {
> + compatible = "google,gpio-firmware";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
> +
> + write-protect {
> + gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + developer-switch {
> + gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
> + };
> +
> + recovery-switch {
> + gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
>
> @@ -731,6 +750,13 @@
> samsung,pin-val = <0>;
> };
>
> + rec_mode: rec-mode {
> + samsung,pins = "gpx0-7";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
> +
> tpm_irq: tpm-irq {
> samsung,pins = "gpx1-0";
> samsung,pin-function = <0>;
> @@ -752,6 +778,13 @@
> samsung,pin-drv = <0>;
> };
>
> + dev_mode: dev-mode {
> + samsung,pins = "gpx1-3";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <3>;
> + samsung,pin-drv = <0>;
> + };
> +
> ec_irq: ec-irq {
> samsung,pins = "gpx1-5";
> samsung,pin-function = <0>;
> @@ -773,6 +806,13 @@
> samsung,pin-drv = <0>;
> };
>
> + wp_gpio: wp_gpio {
> + samsung,pins = "gpx3-0";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
> +
> max77802_irq: max77802-irq {
> samsung,pins = "gpx3-1";
> samsung,pin-function = <0>;
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Add the rk3368 evb board with the act8846 pmic
Hi Caesar, Am Dienstag, 1. Dezember 2015, 17:13:23 schrieb Caesar Wang: > This series pacthes try to add the evb dts for rk3368 SoCs, > This's similar with the rj3288 evb board. > > On the moment, pwm/backlight/usb/thermal/emmc stuff can work for this > board, I add the base version for the future firstly. applied all 3 to relevant branches for 4.5, with some small changes: > PATCH [1/3]: Force rk3368 PWM clock (and its parents) On > That's similar HACK way to work. shortened the comment in the code a bit > PATCH [2/3]: Add the RK3368 EVB board for with the act8846 pmic for dtsi Moved some minor stuff around a bit (ordering, etc) > PATCH [3/3]: Add the PWM node info for rk3368 core. this now comes before the addition of the evb files Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: bcm2835: add rpi power domain driver
Alexander Aring writes:
> Hi,
>
> On Mon, Nov 30, 2015 at 03:51:56PM -0800, Kevin Hilman wrote:
>> Alexander Aring writes:
>>
>> > This patch adds support for RPi several Power Domains and enable support
>> > to enable the USB Power Domain when it's not enabled before.
>> >
>> > This patch based on Eric Anholt's patch to support Power Domains. He had
>> > an issue about -EPROBE_DEFER inside the power domain subsystem, this
>> > issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
>> > if we fail to init or turn-on domain").
>>
>> [...]
>>
>> > +#define RPI_POWER_DOMAIN(_domain, _name) \
>> > + [_domain] = { \
>>
>> Using _domain as the array index is going to create a sparsely filled
>> array here, wasting memory. I'm not sure what the other domain numbers
>> are for other domains to know if this is a big waste or not, but it's
>> still a bit wasteful.
>>
>> In any case, AFAICT, it doesn't look like you need to have the array
>> index match the domain number anyways since you're using container_of().
>>
>> So I suggest just removing this array index part, and just creating them
>> in arrary order. Then your _probe function isn't going to try to setup
>> 3 non-enabled domains before it finally hits the USB domain.
>>
>
> The idea is here to keeping the _same_ power domains indexes for
> device-tree power domain API like the RPi firmware provides it.
>
> If somebody dumps the devicetree and see the power domain index, if
> he/she does then a firmware API power domain index mapping it is wrong.
> Because we need then a separate mapping:
>
> $ARRAY_DEFINED_INDEX <-> $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX
>
> With the current solution to make a 1:1 mapping it there is no
> confusing anymore, because:
>
> $ARRAY_DEFINED_INDEX == $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX
I'm not proposing to change the DT numbers or the firmware numbers. All
I'm proposing is that those numbers don't need to be mapped to the array
index. IOW, in your structure definition macro:
+#define RPI_POWER_DOMAIN(_domain, _name) \
+ [_domain] = { \
+ .domain = _domain, \
[...]
just drop the " [_domain] = { " line.
> Also there exists power domains 1-10 (so far I know), 1-2 are currently
> not used (and dummy-calls inside the rpi firmware implementation). So
> later they should be provided anyway.
They could then be added in any order in the struture.
> There exists a little improvement to let the for (i = 0; i < num_domains
> ...) start at "i = 1", the entry with index "0" will be a waste of memory
> then and it's not provided by the firmware API as a power domain.
Even index 0 will not be wasted with the above approach.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable PCIe PHY support in Cygnus
On 01/12/15 15:18, Arnd Bergmann wrote: > On Tuesday 01 December 2015 15:12:41 Florian Fainelli wrote: >> CC lib/bitmap.o >> >> I added an #address-cells = <0> and #size-cells = <1> to fix this, since >> your reg property is a single digit. > > Did you mean #address-cells = <1> and #size-cells = <0>? Ermm, yes, thanks for catching this.. -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable PCIe PHY support in Cygnus
On Tuesday 01 December 2015 15:12:41 Florian Fainelli wrote: > CC lib/bitmap.o > > I added an #address-cells = <0> and #size-cells = <1> to fix this, since > your reg property is a single digit. Did you mean #address-cells = <1> and #size-cells = <0>? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: enable pinctrl for Broadcom NSP
On 20/11/15 09:58, Yendapally Reddy Dhananjaya Reddy wrote: > This enables the pinctrl support for Broadcom NSP SoC > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy Applied to devicetree/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable PCIe PHY support in Cygnus
On 12/1/2015 3:12 PM, Florian Fainelli wrote: On 24/11/15 16:12, Florian Fainelli wrote: On 18/11/15 10:16, Ray Jui wrote: This patch enales PCIe PHY in device tree for Broadcom Cygnus based platforms This patch is developed based on v4.4-rc1 and available here: https://github.com/Broadcom/cygnus-linux/tree/cygnus-pcie-phy-dt-v1 Ray Jui (1): ARM: dts: enable PCIe PHY support for Cygnus Applied to devicetree/next with Scott's Acked-by, thanks! This caused the DTC compiler to warn: Warning (reg_format): "reg" property in /axi/phy@0301d0a0/phy@0 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): "reg" property in /axi/phy@0301d0a0/phy@1 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /axi/phy@0301d0a0/phy@0 Warning (avoid_default_addr_size): Relying on default #size-cells value for /axi/phy@0301d0a0/phy@0 Warning (avoid_default_addr_size): Relying on default #address-cells value for /axi/phy@0301d0a0/phy@1 Warning (avoid_default_addr_size): Relying on default #size-cells value for /axi/phy@0301d0a0/phy@1 CC drivers/base/power/runtime.o DTC arch/arm/boot/dts/bcm911360k.dtb CC lib/bitmap.o I added an #address-cells = <0> and #size-cells = <1> to fix this, since your reg property is a single digit. Sorry I missed that. Both are required properties. Thanks! Ray -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable PCIe PHY support in Cygnus
On 24/11/15 16:12, Florian Fainelli wrote: > On 18/11/15 10:16, Ray Jui wrote: >> This patch enales PCIe PHY in device tree for Broadcom Cygnus based platforms >> >> This patch is developed based on v4.4-rc1 and available here: >> https://github.com/Broadcom/cygnus-linux/tree/cygnus-pcie-phy-dt-v1 >> >> Ray Jui (1): >> ARM: dts: enable PCIe PHY support for Cygnus > > Applied to devicetree/next with Scott's Acked-by, thanks! This caused the DTC compiler to warn: Warning (reg_format): "reg" property in /axi/phy@0301d0a0/phy@0 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): "reg" property in /axi/phy@0301d0a0/phy@1 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /axi/phy@0301d0a0/phy@0 Warning (avoid_default_addr_size): Relying on default #size-cells value for /axi/phy@0301d0a0/phy@0 Warning (avoid_default_addr_size): Relying on default #address-cells value for /axi/phy@0301d0a0/phy@1 Warning (avoid_default_addr_size): Relying on default #size-cells value for /axi/phy@0301d0a0/phy@1 CC drivers/base/power/runtime.o DTC arch/arm/boot/dts/bcm911360k.dtb CC lib/bitmap.o I added an #address-cells = <0> and #size-cells = <1> to fix this, since your reg property is a single digit. -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] ARM: BCM: Add SMP support for Broadcom NSP
On 01/12/15 08:24, Kapil Hali wrote: > Add SMP support for Broadcom's Northstar Plus SoC > cpu enable method. This changes also consolidates > iProc family's - BCM NSP and BCM Kona, platform > SMP handling in a common file. > > Northstar Plus SoC is based on ARM Cortex-A9 > revision r3p0 which requires configuration for ARM > Errata 764369 for SMP. This change adds the needed > configuration option. > > Signed-off-by: Kapil Hali Applied to soc/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] ARM: BCM: Add SMP support for Broadcom 4708
On 01/12/15 08:24, Kapil Hali wrote: > From: Jon Mason > > Add SMP support for Broadcom's 4708 SoCs. > > Signed-off-by: Jon Mason > Acked-by: Hauke Mehrtens > Tested-by: Hauke Mehrtens > Signed-off-by: Kapil Hali Applied to soc/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] ARM: dts: Add SMP support for Broadcom NSP
On 01/12/15 08:24, Kapil Hali wrote: > Add device tree changes required for providing SMP support > for Broadcom Northstar Plus SoC. > > Signed-off-by: Kapil Hali Applied to devicetree/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] ARM: BCM: Clean up SMP support for Broadcom Kona
On 01/12/15 08:24, Kapil Hali wrote: > These changes cleans up SMP implementaion for Broadcom's > Kona SoC which are required for handling SMP for iProc > family of SoCs at a single place for BCM NSP and BCM Kona. > > Signed-off-by: Kapil Hali Applied to soc/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/5] dt-bindings: add SMP enable-method for Broadcom NSP
On 01/12/15 08:24, Kapil Hali wrote: > Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's > Northstar Plus CPU to the 32-bit ARM CPU device tree binding > documentation file and create a new binding documentation for > Northstar Plus CPU. > > Signed-off-by: Kapil Hali Applied to devicetree/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 4/4] ARM: bcm2835: assign pins to sdhci pinctrl
Stefan Wahren writes:
> Finally this patch assign all relevant pins to the sdhci pinctrl.
>
> Signed-off-by: Stefan Wahren
> ---
> arch/arm/boot/dts/bcm2835-rpi-a-plus.dts |4
> arch/arm/boot/dts/bcm2835-rpi-b-plus.dts |4
> arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts |4
> arch/arm/boot/dts/bcm2835-rpi-b.dts |4
> 4 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> index 50be11d..4d562d9 100644
> --- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> +++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> @@ -28,3 +28,7 @@
> brcm,function = ;
> };
> };
> +
> +&sdhci {
> + pinctrl-0 = <&sdhci_alt3>;
> +};
[...]
What effect does this have? Does this change any pinmuxing at boot? If
so, is it just resetting things from what the firmware has set to what
we expect it to be? Does it enable card detection on the Pi B?
As far as the whole series, I really like the improved description in
patch 2, and patch 3 seems like a good idea, too.
signature.asc
Description: PGP signature
Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding
On Mon, Nov 30, 2015 at 08:30:07PM +, Simon Arlott wrote: > +- offset: register offset > +- mask: register enable mask > +- startup-delay-us: startup time in microseconds Why are these in the DT, I would expect that if this is a driver for a specific SoC all these properties would be known as a result of that. signature.asc Description: PGP signature
Re: [PATCH 1/2] regulator: Add coupled regulator
Hi Javier,
On Mon, Nov 30, 2015 at 04:06:14PM -0300, Javier Martinez Canillas wrote:
> Hello Maxime,
>
> On Mon, Nov 30, 2015 at 12:29 PM, Maxime Ripard
> wrote:
>
> [snip]
>
> >
> > +config REGULATOR_COUPLED_VOLTAGE
>
> Shouldn't this depend on OF?
>
> > + tristate "Coupled voltage regulator support"
>
> the Kconfig symbol is tristate so the driver can be built as a module...
>
> > +
> > +static struct of_device_id coupled_regulator_of_match[] = {
> > + { .compatible = "coupled-voltage-regulator" },
> > + { /* Sentinel */ },
> > +};
> > +
>
> ...but the driver is missing a MODULE_DEVICE_TABLE(of, ...) so module
> autoloading won't work.
You're right, it will be in the v2.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v2] arm64: dts: qcom: Add apq8096 dragonboard dts skeletons
On 12/01/2015 08:11 AM, Rajendra Nayak wrote: > Add new dtsi and dts files for the apq8096 dragonboards with just > a serial device used as debug console > > While at it, also rearrange the Makefile so we have one dtb per line > so as to be consistent with whats done on other platforms. > > Signed-off-by: Rajendra Nayak > --- > arch/arm64/boot/dts/qcom/Makefile | 4 ++- > arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts | 21 > arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 > +++ > 3 files changed, 54 insertions(+), 1 deletion(-) > create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts > create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi One problem. The board you have is not called a dragonboard. Let's check with the marketing folks on what they're calling it now. We need to explicitly avoid using dragonboard here as that name applies to a different class of products. Thanks. - Bryan -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] touchscreen: pixcir_i2c: Add support for wake and enable gpios
On Sun, Nov 22, 2015 at 04:19:50PM -0600, Rob Herring wrote:
> On Sun, Nov 22, 2015 at 04:57:33PM +0100, Hans de Goede wrote:
> > From: Sander Vermin
> >
> > On some devices the wake and enable pins of the pixcir touchscreen
> > controller are connected to gpios and these must be controlled by the
> > driver for the device to operate properly.
> >
> > Signed-off-by: Sander Vermin
> > Signed-off-by: Hans de Goede
> > ---
> > Changes in v2 (Hans de Goede):
> > -Split the changes for dealing with inverted / swapped axis out into a
> > separate patch
> > -Remove a bunch of dev_info calls to make the driver less chatty
> > -Use devm_gpiod_get_optional as these new gpios are optional
> > -Only msleep after setting enable high if we have an enable pin
> > Changes in v3 (Hans de Goede):
> > -Use "if (ts->gpio_foo)" instead of "if (!IS_ERR_OR_NULL(ts->foo))"
> > -No need to set gpio-s to 1 after requesting them with GPIOD_OUT_HIGH
> > ---
> > .../bindings/input/touchscreen/pixcir_i2c_ts.txt | 2 ++
>
> For the binding:
>
> Acked-by: Rob Herring
Applied, thank you.
>
> > drivers/input/touchscreen/pixcir_i2c_ts.c | 40
> > ++
> > 2 files changed, 42 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
> > b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
> > index 8eb240a..72ca5ec 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
> > @@ -10,6 +10,8 @@ Required properties:
> >
> > Optional properties:
> > - reset-gpio: GPIO connected to the RESET line of the chip
> > +- enable-gpios: GPIO connected to the ENABLE line of the chip
> > +- wake-gpios: GPIO connected to the WAKE line of the chip
> >
> > Example:
> >
> > diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
> > b/drivers/input/touchscreen/pixcir_i2c_ts.c
> > index 211408c..22a67c6 100644
> > --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
> > +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
> > @@ -38,6 +38,8 @@ struct pixcir_i2c_ts_data {
> > struct input_dev *input;
> > struct gpio_desc *gpio_attb;
> > struct gpio_desc *gpio_reset;
> > + struct gpio_desc *gpio_enable;
> > + struct gpio_desc *gpio_wake;
> > const struct pixcir_i2c_chip_data *chip;
> > int max_fingers;/* Max fingers supported in this instance */
> > bool running;
> > @@ -208,6 +210,11 @@ static int pixcir_set_power_mode(struct
> > pixcir_i2c_ts_data *ts,
> > struct device *dev = &ts->client->dev;
> > int ret;
> >
> > + if (mode == PIXCIR_POWER_ACTIVE || mode == PIXCIR_POWER_IDLE) {
> > + if (ts->gpio_wake)
> > + gpiod_set_value_cansleep(ts->gpio_wake, 1);
> > + }
> > +
> > ret = i2c_smbus_read_byte_data(ts->client, PIXCIR_REG_POWER_MODE);
> > if (ret < 0) {
> > dev_err(dev, "%s: can't read reg 0x%x : %d\n",
> > @@ -228,6 +235,11 @@ static int pixcir_set_power_mode(struct
> > pixcir_i2c_ts_data *ts,
> > return ret;
> > }
> >
> > + if (mode == PIXCIR_POWER_HALT) {
> > + if (ts->gpio_wake)
> > + gpiod_set_value_cansleep(ts->gpio_wake, 0);
> > + }
> > +
> > return 0;
> > }
> >
> > @@ -302,6 +314,11 @@ static int pixcir_start(struct pixcir_i2c_ts_data *ts)
> > struct device *dev = &ts->client->dev;
> > int error;
> >
> > + if (ts->gpio_enable) {
> > + gpiod_set_value_cansleep(ts->gpio_enable, 1);
> > + msleep(100);
> > + }
> > +
> > /* LEVEL_TOUCH interrupt with active low polarity */
> > error = pixcir_set_int_mode(ts, PIXCIR_INT_LEVEL_TOUCH, 0);
> > if (error) {
> > @@ -343,6 +360,9 @@ static int pixcir_stop(struct pixcir_i2c_ts_data *ts)
> > /* Wait till running ISR is complete */
> > synchronize_irq(ts->client->irq);
> >
> > + if (ts->gpio_enable)
> > + gpiod_set_value_cansleep(ts->gpio_enable, 0);
> > +
> > return 0;
> > }
> >
> > @@ -534,6 +554,26 @@ static int pixcir_i2c_ts_probe(struct i2c_client
> > *client,
> > return error;
> > }
> >
> > + tsdata->gpio_wake = devm_gpiod_get_optional(dev, "wake",
> > + GPIOD_OUT_HIGH);
> > + if (IS_ERR(tsdata->gpio_wake)) {
> > + error = PTR_ERR(tsdata->gpio_wake);
> > + if (error != -EPROBE_DEFER)
> > + dev_err(dev, "Failed to get wake gpio: %d\n", error);
> > + return error;
> > + }
> > +
> > + tsdata->gpio_enable = devm_gpiod_get_optional(dev, "enable",
> > + GPIOD_OUT_HIGH);
> > + if (IS_ERR(tsdata->gpio_enable)) {
> > + error = PTR_ERR(tsdata->gpio_enable);
> > + if (error != -EPROBE_DEFER)
> > + dev_err(dev, "Failed to get enable gpio: %d\n", error);
> > +
Re: [PATCH 2/3] ARM: bcm2835: add rpi power domain driver
Hi,
On Mon, Nov 30, 2015 at 03:51:56PM -0800, Kevin Hilman wrote:
> Alexander Aring writes:
>
> > This patch adds support for RPi several Power Domains and enable support
> > to enable the USB Power Domain when it's not enabled before.
> >
> > This patch based on Eric Anholt's patch to support Power Domains. He had
> > an issue about -EPROBE_DEFER inside the power domain subsystem, this
> > issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
> > if we fail to init or turn-on domain").
>
> [...]
>
> > +#define RPI_POWER_DOMAIN(_domain, _name) \
> > + [_domain] = { \
>
> Using _domain as the array index is going to create a sparsely filled
> array here, wasting memory. I'm not sure what the other domain numbers
> are for other domains to know if this is a big waste or not, but it's
> still a bit wasteful.
>
> In any case, AFAICT, it doesn't look like you need to have the array
> index match the domain number anyways since you're using container_of().
>
> So I suggest just removing this array index part, and just creating them
> in arrary order. Then your _probe function isn't going to try to setup
> 3 non-enabled domains before it finally hits the USB domain.
>
The idea is here to keeping the _same_ power domains indexes for
device-tree power domain API like the RPi firmware provides it.
If somebody dumps the devicetree and see the power domain index, if
he/she does then a firmware API power domain index mapping it is wrong.
Because we need then a separate mapping:
$ARRAY_DEFINED_INDEX <-> $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX
With the current solution to make a 1:1 mapping it there is no
confusing anymore, because:
$ARRAY_DEFINED_INDEX == $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX
Also there exists power domains 1-10 (so far I know), 1-2 are currently
not used (and dummy-calls inside the rpi firmware implementation). So
later they should be provided anyway.
There exists a little improvement to let the for (i = 0; i < num_domains
...) start at "i = 1", the entry with index "0" will be a waste of memory
then and it's not provided by the firmware API as a power domain.
These are my arguments to keeping the current way of registering power
domains, if you still want that I should change it then I will do it or
maybe I show here some "good" arguments here to keeping this behaviour.
Please let me know. Thanks.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3,1/2] Add binding documentation for Zodiac Watchdog Timer
On Tue, Dec 01, 2015 at 03:38:38PM +, Martyn Welch wrote: > > > On 01/12/15 15:15, Guenter Roeck wrote: > >On Wed, Nov 25, 2015 at 12:03:34PM +, Martyn Welch wrote: > >>This patchs adds documentation for the binding of the Zodiac RAVE > >>Switch Watchdog Processor. This is an i2c based watchdog. > >> > >>Cc: Rob Herring > >>Cc: Pawel Moll > >>Cc: Mark Rutland > >>Cc: Ian Campbell > >>Cc: Kumar Gala > >>Cc: devicetree@vger.kernel.org > >>Signed-off-by: Martyn Welch > >>Acked-by: Rob Herring > > > >Reviewed-by: Guenter Roeck > > > > Would I be right in thinking this will be going via the watchdog tree as > well? > I would think so. I'll queue it in my tree and send it to Wim in my next pull request. Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size
On Tuesday 01 December 2015 11:25:35 Andy Gross wrote: > On Tue, Dec 01, 2015 at 11:28:32AM +0100, Arnd Bergmann wrote: > > On Tuesday 01 December 2015 11:14:58 Stanimir Varbanov wrote: > > > > > > diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c > > > index 0f06f3b7a72b..6d290de9ab2b 100644 > > > --- a/drivers/dma/qcom_bam_dma.c > > > +++ b/drivers/dma/qcom_bam_dma.c > > > @@ -458,7 +458,7 @@ static void bam_chan_init_hw(struct bam_chan *bchan, > > > */ > > > writel_relaxed(ALIGN(bchan->fifo_phys, sizeof(struct > > > bam_desc_hw)), > > > bam_addr(bdev, bchan->id, BAM_P_DESC_FIFO_ADDR)); > > > - writel_relaxed(BAM_DESC_FIFO_SIZE, > > > + writel_relaxed(BAM_MAX_DATA_SIZE, > > > bam_addr(bdev, bchan->id, BAM_P_FIFO_SIZES)); > > > > > > /* enable the per pipe interrupts, enable EOT, ERR, and INT irqs > > > */ > > > > I'm looking at that now and fail to see why these have to use > > writel_relaxed(). > > At some point I believe I got a comment about using (readl/writel)_relaxed > instead of readl/writel. So I used these instead. Has the wind direction > changed? =) Yes. > Using the readl/writel is nice w.r.t. having the implicit barriers, especially > with the funky 1K boundary on reordering of operations that can occur on > Kraits. > This can hit you on accesses even within the same IP block. We had a couple of bugs that we should not have had when drivers were mindlessly converted, so generally speaking at least I try to get people to only use the relaxed functions for the hot path when they can show an advantage as well as the fact that it's safe to use. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/4] gpio: tps65086: Add GPO driver for the TPS65086 PMIC
Hi Andrew,
[auto build test ERROR on next-20151127]
[cannot apply to ljones-mfd/for-mfd-next gpio/for-next v4.4-rc3 v4.4-rc2
v4.4-rc1 v4.4-rc3]
url:
https://github.com/0day-ci/linux/commits/Andrew-F-Davis/Documentation-tps65086-Add-DT-bindings-for-the-TPS65086-PMIC/20151202-024903
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpio/gpio-tps65086.c: In function 'tps65086_gpio_probe':
>> drivers/gpio/gpio-tps65086.c:106:12: error: 'struct gpio_chip' has no member
>> named 'parent'
gpio->chip.parent = gpio->tps->dev;
^
vim +106 drivers/gpio/gpio-tps65086.c
100 return -ENOMEM;
101
102 platform_set_drvdata(pdev, gpio);
103
104 gpio->tps = dev_get_drvdata(pdev->dev.parent);
105 gpio->chip = template_chip;
> 106 gpio->chip.parent = gpio->tps->dev;
107
108 ret = gpiochip_add(&gpio->chip);
109 if (ret < 0) {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v2 2/2] rtc: add driver for RX6110SA real time clock
Hello Alexandre,
Cc += Arnd
On Tue, Dec 01, 2015 at 03:42:18PM +0100, Alexandre Belloni wrote:
> > +/**
> > + * rx6110_set_time - set the current time in the rx6110 registers
> > + *
> > + * @dev: the rtc device in use
> > + * @tm: holds date and time
> > + *
> > + * BUG: The HW assumes every year that is a multiple of 4 to be a leap
> > + * year. Next time this is wrong is 2100, which will not be a leap year
> > + *
> > + * Note: If STOP is not set/cleared, the clock will start when the seconds
> > + * register is written
> > + *
> > + */
> > +static int rx6110_set_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + struct rx6110_data *rx6110 = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + if (tm->tm_year > 137)
> > + return -EINVAL;
> > +
>
> Seeing the comment comment above, this should probably be if
> (tm->tm_year < 100 || tm->tm_year >= 200)
> I don't think this particular part has any issue
> handling 2038. However, on 32bit platform, your userspace is probably
> not ready to handle those date. hwclock should return the correct date.
userspace is not ready because it cannot. Before this can be addressed,
quite some things need fixing first. If I understood correctly timerfd
for example is broken which completely locks up systemd.
Note this doesn't justify to not write a date later than 2037 in the rtc
driver however. Still thinking about how to handle this for the machines
we work on, we thought about letting the RTC_RD_TIME ioctl fail for
dates later than 2038 to work around this issue.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/6] pinctrl: meson: Enable GPIO IRQs
On Tue, Dec 1, 2015 at 8:16 PM, Marc Zyngier wrote:
> On 01/12/15 16:24, Carlo Caione wrote:
>> From: Carlo Caione
>> +static int meson_irq_domain_alloc(struct irq_domain *domain, unsigned int
>> irq,
>> + unsigned int nr_irqs, void *arg)
>> +{
>> + struct meson_pinctrl *pc = domain->host_data;
>> + struct irq_fwspec *irq_data = arg;
>> + struct irq_fwspec gic_data;
>> + irq_hw_number_t hwirq;
>> + int index, ret, i;
>> +
>> + if (irq_data->param_count != 2)
>> + return -EINVAL;
>> +
>> + hwirq = irq_data->param[0];
>> + dev_dbg(pc->dev, "%s irq %d, nr %d, hwirq %lu\n",
>> + __func__, irq, nr_irqs, hwirq);
>> +
>> + for (i = 0; i < nr_irqs; i++) {
>> + index = meson_map_gic_irq(domain, hwirq + i);
>> + if (index < 0)
>> + return index;
>> +
>> + irq_domain_set_hwirq_and_chip(domain, irq + i,
>> + hwirq + i,
>> + &meson_irq_chip,
>> + pc);
>> +
>> + gic_data.param_count = 3;
>> + gic_data.fwnode = domain->parent->fwnode;
>> + gic_data.param[0] = 0; /* SPI */
>> + gic_data.param[1] = pc->gic_irqs[index];
>> + gic_data.param[1] = IRQ_TYPE_EDGE_RISING;
Oh, this should be gic_data.param[2]. Just noticed.
> That feels quite wrong. Hardcoding the trigger like this and hoping for
> a set_type to set it right at a later time is just asking for trouble.
> Why can't you use the trigger type that has been provided by the
> interrupt descriptor?
In v2 I had the set of fwspec to track number and trigger type of the
IRQ, so it was straightforward. With this patch I have moved away from
that solution (as you suggested) and I'm using the 'amlogic,irqs-gpio'
parameter to track down the IRQ numbers (but not the trigger type).
It's the same solution we have in drivers/irqchip/irq-crossbar.c where
the trigger type is hardcoded in allocate_gic_irq().
If I need to save both the IRQ and the trigger type at this point I
wonder if it's better to go back to the set of fwspec or convert the
fwspec to of_phandle_args and save that.
>> +static int meson_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
>> +{
>> + struct meson_domain *domain = to_meson_domain(chip);
>> + struct meson_pinctrl *pc = domain->pinctrl;
>> + struct meson_bank *bank;
>> + struct irq_fwspec irq_data;
>> + unsigned int hwirq, irq;
>> +
>> + hwirq = domain->data->pin_base + offset;
>> +
>> + if (meson_get_bank(domain, hwirq, &bank))
>> + return -ENXIO;
>> +
>> + irq_data.param_count = 2;
>> + irq_data.param[0] = hwirq;
>> +
>> + /* dummy. It will be changed later in meson_irq_set_type */
>> + irq_data.param[1] = IRQ_TYPE_EDGE_RISING;
>
> Blah. Worse than I though... How do you end-up here? Why can't you
> obtain the corresponding of_phandle_args instead of making things up?
because I do not have a of_phandle. This is basically the .to_irq hook
of the gpio_chip. This code is being called programmatically from the
gpiolib. No DTS/OF involved here.
> This looks mad. Do you really need this?
Well, I'm open to any suggestion on how improve this mess.
--
Carlo Caione
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC
On 11/30/2015 02:26 AM, Linus Walleij wrote: On Wed, Nov 18, 2015 at 6:59 PM, Andrew F. Davis wrote: This patch adds support for the TPS65912 PMIC GPIOs. TPS65912 has five configurable GPIOs that can be used for several purposes. Signed-off-by: Andrew F. Davis Reviewed-by: Linus Walleij (...) + gpio->tps = dev_get_drvdata(pdev->dev.parent); + gpio->gpio_chip = template_chip; + gpio->gpio_chip.dev = tps->dev; This is now renamed .parent in linux-next. It needs to be changed if the code should compile after merge. Are you able to make this change when you pick this up or would you like me to resend this? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/6] pinctrl: meson: Enable GPIO IRQs
On 01/12/15 16:24, Carlo Caione wrote:
> From: Carlo Caione
>
> On Meson8 and Meson8b SoCs there are 8 independent filtered GPIO
> interrupt modules that can be programmed to use any of the GPIOs in the
> chip as an interrupt source.
>
> For each GPIO IRQ we have:
>
> GPIOs --> [mux]--> [polarity]--> [filter]--> [edge select]--> GIC
>
> The eight GPIO interrupts respond to mask/unmask/clear/etc.. just like
> any other interrupt in the chip. The difference for the GPIO interrupts
> is that they can be filtered and conditioned.
>
> This patch adds support for the external GPIOs interrupts and enables
> them for Meson8 and Meson8b SoCs.
>
> Signed-off-by: Carlo Caione
> Signed-off-by: Beniamino Galvani
> ---
> drivers/pinctrl/Kconfig| 1 +
> drivers/pinctrl/meson/Makefile | 2 +-
> drivers/pinctrl/meson/irqchip-gpio-meson.c | 321
> +
> drivers/pinctrl/meson/pinctrl-meson.c | 30 +++
> drivers/pinctrl/meson/pinctrl-meson.h | 15 ++
> 5 files changed, 368 insertions(+), 1 deletion(-)
> create mode 100644 drivers/pinctrl/meson/irqchip-gpio-meson.c
>
[...]
> +static int meson_irq_domain_alloc(struct irq_domain *domain, unsigned int
> irq,
> + unsigned int nr_irqs, void *arg)
> +{
> + struct meson_pinctrl *pc = domain->host_data;
> + struct irq_fwspec *irq_data = arg;
> + struct irq_fwspec gic_data;
> + irq_hw_number_t hwirq;
> + int index, ret, i;
> +
> + if (irq_data->param_count != 2)
> + return -EINVAL;
> +
> + hwirq = irq_data->param[0];
> + dev_dbg(pc->dev, "%s irq %d, nr %d, hwirq %lu\n",
> + __func__, irq, nr_irqs, hwirq);
> +
> + for (i = 0; i < nr_irqs; i++) {
> + index = meson_map_gic_irq(domain, hwirq + i);
> + if (index < 0)
> + return index;
> +
> + irq_domain_set_hwirq_and_chip(domain, irq + i,
> + hwirq + i,
> + &meson_irq_chip,
> + pc);
> +
> + gic_data.param_count = 3;
> + gic_data.fwnode = domain->parent->fwnode;
> + gic_data.param[0] = 0; /* SPI */
> + gic_data.param[1] = pc->gic_irqs[index];
> + gic_data.param[1] = IRQ_TYPE_EDGE_RISING;
That feels quite wrong. Hardcoding the trigger like this and hoping for
a set_type to set it right at a later time is just asking for trouble.
Why can't you use the trigger type that has been provided by the
interrupt descriptor?
> +
> + ret = irq_domain_alloc_irqs_parent(domain, irq + i, nr_irqs,
> +&gic_data);
> + }
> +
> + return 0;
> +}
> +
> +static void meson_irq_domain_free(struct irq_domain *domain, unsigned int
> irq,
> + unsigned int nr_irqs)
> +{
> + struct meson_pinctrl *pc = domain->host_data;
> + struct irq_data *irq_data;
> + int index, i;
> +
> + spin_lock(&pc->lock);
> + for (i = 0; i < nr_irqs; i++) {
> + irq_data = irq_domain_get_irq_data(domain, irq + i);
> + index = meson_get_gic_irq(pc, irq_data->hwirq);
> + if (index < 0)
> + continue;
> + pc->irq_map[index] = IRQ_FREE;
> + }
> + spin_unlock(&pc->lock);
> +
> + irq_domain_free_irqs_parent(domain, irq, nr_irqs);
> +}
> +
> +static int meson_irq_domain_translate(struct irq_domain *d,
> + struct irq_fwspec *fwspec,
> + unsigned long *hwirq,
> + unsigned int *type)
> +{
> + if (is_of_node(fwspec->fwnode)) {
> + if (fwspec->param_count != 2)
> + return -EINVAL;
> +
> + *hwirq = fwspec->param[0];
> + *type = fwspec->param[1];
> +
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static struct irq_domain_ops meson_irq_domain_ops = {
> + .alloc = meson_irq_domain_alloc,
> + .free = meson_irq_domain_free,
> + .translate = meson_irq_domain_translate,
> +};
> +
> +int meson_gpio_irq_init(struct meson_pinctrl *pc)
> +{
> + struct device_node *node = pc->dev->of_node;
> + struct device_node *parent_node;
> + struct irq_domain *parent_domain;
> + const __be32 *irqs;
> + int i, size;
> +
> + parent_node = of_irq_find_parent(node);
> + if (!parent_node) {
> + dev_err(pc->dev, "can't find parent interrupt controller\n");
> + return -EINVAL;
> + }
> +
> + parent_domain = irq_find_host(parent_node);
> + if (!parent_domain) {
> + dev_err(pc->dev, "can't find parent IRQ domain\n");
> + return -EINVAL;
> + }
> +
> + pc->reg_irq = meson_map_resource(pc, node, "irq");
> +
[PATCH 3/3] Addition of binding for firmware signals on peach-pi
The peach pi has a GPIO connected to the firmware write protect, developer
mode and recovery mode lines. This patch adds the required nodes to the
device tree to configure the pinmuxing and allow these to be read from
user space.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: devicetree@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Martyn Welch
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..485c18f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -53,6 +53,25 @@
};
};
+ chromeos-firmware {
+ compatible = "google,gpio-firmware";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
+
+ write-protect {
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ };
+
+ developer-switch {
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ recovery-switch {
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -731,6 +750,13 @@
samsung,pin-val = <0>;
};
+ rec_mode: rec-mode {
+ samsung,pins = "gpx0-7";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
tpm_irq: tpm-irq {
samsung,pins = "gpx1-0";
samsung,pin-function = <0>;
@@ -752,6 +778,13 @@
samsung,pin-drv = <0>;
};
+ dev_mode: dev-mode {
+ samsung,pins = "gpx1-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
ec_irq: ec-irq {
samsung,pins = "gpx1-5";
samsung,pin-function = <0>;
@@ -773,6 +806,13 @@
samsung,pin-drv = <0>;
};
+ wp_gpio: wp_gpio {
+ samsung,pins = "gpx3-0";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
max77802_irq: max77802-irq {
samsung,pins = "gpx3-1";
samsung,pin-function = <0>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Device tree binding documentation for chromeos-firmware
This patch adds documentation for the chromeos-firmware binding.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicetree@vger.kernel.org
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/chromeos-firmware.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/chromeos-firmware.txt
diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
new file mode 100644
index 000..8240611
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
@@ -0,0 +1,27 @@
+Device-Tree bindings for chromeos-firmware.c.
+
+Required properties:
+ - compatible = "google,gpio-firmware";
+
+Each signal is represented as a sub-node of "chromeos_firmware":
+Subnode properties:
+
+ - gpios: OF device-tree gpio specification.
+
+Example nodes:
+
+ chromeos_firmware {
+ compatible = "google,gpio-firmware";
+
+ write-protect {
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ };
+
+ developer-switch {
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ recovery-switch {
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: Add coupled regulator
On Tue, Dec 01, 2015 at 03:04:36PM +0100, Maxime Ripard wrote:
> On Mon, Nov 30, 2015 at 10:17:45AM -0700, Mathieu Poirier wrote:
> > On 30 November 2015 at 08:29, Maxime Ripard
> > > + for (i = 0; i < creg->n_regulators; i++) {
> > > + ret = regulator_disable(creg->regulators[i]);
> > > + if (ret)
> > > + break;
> > > + }
> > What happens to the other regulators when an element of the chain
> > fails to disable? Should they be powered on again?
> That's actually a very good question, and I don't have a good answer
> to it. I guess the safest approach would be to roll back and do the
> opposite operation on the one we previously enabled / disabled.
> I wonder whether it might damage the hardware or not though.
> Mark?
Yeah, I'd expect us to try to unwind everything - presumably if the
supplies are partially enabled we'll not be able to satisfy the power
demands of whatever is connected (otherwise why would you create such an
innovative hardware design?) and it'll also mean that the refcounting
will be off if we ever try to do anything with the supply again.
signature.asc
Description: PGP signature
[PATCH v5 1/4] Documentation: tps65086: Add DT bindings for the TPS65086 PMIC
The TPS65086 PMIC contains several regulators and a GPO controller.
Add bindings for the TPS65086 PMIC.
Signed-off-by: Andrew F. Davis
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/mfd/tps65086.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65086.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65086.txt
b/Documentation/devicetree/bindings/mfd/tps65086.txt
new file mode 100644
index 000..d370561
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65086.txt
@@ -0,0 +1,55 @@
+* TPS65086 Power Management Integrated Circuit (PMIC) bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65086".
+ - reg : I2C slave address.
+ - interrupt-parent: Phandle to the parent interrupt controller.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller: Marks the device node as an interrupt
controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as trigger
+ masks from ../interrupt-controller/interrupts.txt.
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two. The first cell is the pin number and
+the second cell is used to specify flags.
+See ../gpio/gpio.txt for more information.
+ - regulators: : List of child nodes that specify the regulator
+initialization data. Child nodes must be named
+after their hardware counterparts: buck[1-6],
+ldoa[1-3], swa1, swb[1-2], and vtt. Each child
+node is defined using the standard binding for
+regulators and the optional regulator properties
+defined below.
+
+Optional regulator properties:
+ - ti,regulator-step-size-25mv : This is applicable for buck[1,2,6], set this
+ if the regulator is factory set with a 25mv
+ step voltage mapping.
+ - ti,regulator-decay : This is applicable for buck[1-6], set this if
+ the output needs to decay, default is for
+ the output to slew down.
+
+Example:
+
+ pmic: tps65086@5e {
+ compatible = "ti,tps65086";
+ reg = <0x5e>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ regulators {
+ buck1 {
+ regulator-name = "vcc1";
+ regulator-min-microvolt = <160>;
+ regulator-max-microvolt = <160>;
+ regulator-boot-on;
+ ti,regulator-decay;
+ ti,regulator-step-size-25mv;
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] gpio: tps65086: Add GPO driver for the TPS65086 PMIC
Add support for the TPS65086 PMIC GPOs.
TPS65086 has four configurable GPOs that can be used for several
purposes. These are output only.
Signed-off-by: Andrew F. Davis
---
drivers/gpio/Kconfig | 6 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-tps65086.c | 144 +++
3 files changed, 151 insertions(+)
create mode 100644 drivers/gpio/gpio-tps65086.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b18bea0..f357a2e 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,6 +838,12 @@ config GPIO_TIMBERDALE
---help---
Add support for the GPIO IP in the timberdale FPGA.
+config GPIO_TPS65086
+ tristate "TI TPS65086 GPO"
+ depends on MFD_TPS65086
+ help
+ This driver supports the GPO on TI TPS65086x PMICs.
+
config GPIO_TPS6586X
bool "TPS6586X GPIO"
depends on MFD_TPS6586X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 986dbd8..fd98126 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_GPIO_TC3589X)+= gpio-tc3589x.o
obj-$(CONFIG_ARCH_TEGRA) += gpio-tegra.o
obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
+obj-$(CONFIG_GPIO_TPS65086)+= gpio-tps65086.o
obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
diff --git a/drivers/gpio/gpio-tps65086.c b/drivers/gpio/gpio-tps65086.c
new file mode 100644
index 000..e3d85bf
--- /dev/null
+++ b/drivers/gpio/gpio-tps65086.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include
+#include
+#include
+
+#include
+
+struct tps65086_gpio {
+ struct gpio_chip chip;
+ struct tps65086 *tps;
+};
+
+static inline struct tps65086_gpio *to_tps65086_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct tps65086_gpio, chip);
+}
+
+static int tps65086_gpio_get_direction(struct gpio_chip *chip,
+ unsigned offset)
+{
+ return GPIOF_DIR_OUT;
+}
+
+static int tps65086_gpio_direction_input(struct gpio_chip *chip,
+unsigned offset)
+{
+ /* This device is output only */
+ return -EINVAL;
+}
+
+static int tps65086_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ struct tps65086_gpio *gpio = to_tps65086_gpio(chip);
+
+ /* Set the initial value */
+ regmap_update_bits(gpio->tps->regmap, TPS65086_GPOCTRL,
+ BIT(4 + offset), value ? BIT(4 + offset) : 0);
+
+ return 0;
+}
+
+static int tps65086_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct tps65086_gpio *gpio = to_tps65086_gpio(chip);
+ int ret, val;
+
+ ret = regmap_read(gpio->tps->regmap, TPS65086_GPOCTRL, &val);
+ if (ret < 0)
+ return ret;
+
+ return val & BIT(4 + offset);
+}
+
+static void tps65086_gpio_set(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ struct tps65086_gpio *gpio = to_tps65086_gpio(chip);
+
+ regmap_update_bits(gpio->tps->regmap, TPS65086_GPOCTRL,
+ BIT(4 + offset), value ? BIT(4 + offset) : 0);
+}
+
+static struct gpio_chip template_chip = {
+ .label = "tps65086-gpio",
+ .owner = THIS_MODULE,
+ .get_direction = tps65086_gpio_get_direction,
+ .direction_input= tps65086_gpio_direction_input,
+ .direction_output = tps65086_gpio_direction_output,
+ .get= tps65086_gpio_get,
+ .set= tps65086_gpio_set,
+ .base = -1,
+ .ngpio = 4,
+ .can_sleep = true,
+};
+
+static int tps65086_gpio_probe(struct platform_device *pdev)
+{
+ struct tps65086_gpio *gpio;
+ int ret;
+
+ gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
+ if (!gpio)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, gpio);
+
+ gpio->tps = dev_get_drvdata(pdev->dev.parent);
+ gpio->chip = template_chip;
+ gpio->chip.parent = gpio->tps->dev;
+
+ ret = gpio
[PATCH v5 2/4] mfd: tps65086: Add driver for the TPS65086 PMIC
Add support for the TPS65912 device. It provides communication
through I2C and contains the following components:
- Regulators
- Load switches
- GPO controller
Signed-off-by: Andrew F. Davis
Acked-by: Lee Jones
---
drivers/mfd/Kconfig | 13
drivers/mfd/Makefile | 1 +
drivers/mfd/tps65086.c | 150 +++
include/linux/mfd/tps65086.h | 118 ++
4 files changed, 282 insertions(+)
create mode 100644 drivers/mfd/tps65086.c
create mode 100644 include/linux/mfd/tps65086.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6..232a911 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1106,6 +1106,19 @@ config TPS6507X
This driver can also be built as a module. If so, the module
will be called tps6507x.
+config MFD_TPS65086
+ tristate "TI TPS65086 Power Management Integrated Chips (PMICs)"
+ select REGMAP
+ select REGMAP_IRQ
+ select REGMAP_I2C
+ depends on I2C
+ help
+ If you say yes here you get support for the TPS65086 series of
+ Power Management chips.
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the
+ functionality of the device.
+
config TPS65911_COMPARATOR
tristate
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 99f93ab..3347b43 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_MFD_WM8994) += wm8994.o
obj-$(CONFIG_TPS6105X) += tps6105x.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_TPS6507X) += tps6507x.o
+obj-$(CONFIG_MFD_TPS65086) += tps65086.o
obj-$(CONFIG_MFD_TPS65217) += tps65217.o
obj-$(CONFIG_MFD_TPS65218) += tps65218.o
obj-$(CONFIG_MFD_TPS65910) += tps65910.o
diff --git a/drivers/mfd/tps65086.c b/drivers/mfd/tps65086.c
new file mode 100644
index 000..e1edfc0
--- /dev/null
+++ b/drivers/mfd/tps65086.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+static const struct mfd_cell tps65086_cells[] = {
+ { .name = "tps65086-regulator", },
+ { .name = "tps65086-gpio", },
+};
+
+static const struct regmap_range tps65086_yes_ranges[] = {
+ regmap_reg_range(TPS65086_IRQ, TPS65086_IRQ),
+ regmap_reg_range(TPS65086_PMICSTAT, TPS65086_SHUTDNSRC),
+ regmap_reg_range(TPS65086_GPOCTRL, TPS65086_GPOCTRL),
+ regmap_reg_range(TPS65086_PG_STATUS1, TPS65086_OC_STATUS),
+};
+
+static const struct regmap_access_table tps65086_volatile_table = {
+ .yes_ranges = tps65086_yes_ranges,
+ .n_yes_ranges = ARRAY_SIZE(tps65086_yes_ranges),
+};
+
+static const struct regmap_config tps65086_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .cache_type = REGCACHE_RBTREE,
+ .volatile_table = &tps65086_volatile_table,
+};
+
+static const struct regmap_irq tps65086_irqs[] = {
+ REGMAP_IRQ_REG(TPS65086_IRQ_DIETEMP, 0, TPS65086_IRQ_DIETEMP_MASK),
+ REGMAP_IRQ_REG(TPS65086_IRQ_SHUTDN, 0, TPS65086_IRQ_SHUTDN_MASK),
+ REGMAP_IRQ_REG(TPS65086_IRQ_FAULT, 0, TPS65086_IRQ_FAULT_MASK),
+};
+
+static struct regmap_irq_chip tps65086_irq_chip = {
+ .name = "tps65086",
+ .status_base = TPS65086_IRQ,
+ .mask_base = TPS65086_IRQ_MASK,
+ .ack_base = TPS65086_IRQ,
+ .init_ack_masked = true,
+ .num_regs = 1,
+ .irqs = tps65086_irqs,
+ .num_irqs = ARRAY_SIZE(tps65086_irqs),
+};
+
+static const struct of_device_id tps65086_of_match_table[] = {
+ { .compatible = "ti,tps65086", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tps65086_of_match_table);
+
+static int tps65086_probe(struct i2c_client *client,
+ const struct i2c_device_id *ids)
+{
+ struct tps65086 *tps;
+ unsigned int version;
+ int ret;
+
+ tps = devm_kzalloc(&client->dev, sizeof(*tps), GFP_KERNEL);
+ if (!tps)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, tps);
+ tps->dev = &client->dev;
+ tps->irq = client->irq;
+
+ tps->regmap = devm_regmap_init_i2c(client, &tps65086_regmap_config);
+ if (IS_ERR(tps->regmap)) {
+ dev_err(tps->dev, "Failed to initialize
[PATCH v5 0/4] Add support for the TI TPS65086 PMIC
This series adds support for the TPS65086 PMIC. It is a MFD with an I2C interface, several regulators and load switches, and a GPO controller. v1 can be found here: [1] v2: [2] v3: [3] v4: [4] Changes from v4: - Typo fixes in bindings - Regulator driver is now just an update stub - Use .parent in GPIO driver Changes from v3: - Removed compatible strings from DT sub-nodes - Rearranged DT bindings - Small fixes Changes from v2: - Use DT match callback in regulator - Typo fixes Changes from v1: - Split up DT Docs into separate patches - Use mfd core to instantiate sub-devices - Several small fixes as discussed in v1 thread [1] http://www.spinics.net/lists/devicetree/msg98403.html [2] http://www.spinics.net/lists/kernel/msg2111345.html [3] https://lkml.org/lkml/2015/11/4/393 [4] http://www.spinics.net/lists/devicetree/msg103186.html Andrew F. Davis (4): Documentation: tps65086: Add DT bindings for the TPS65086 PMIC mfd: tps65086: Add driver for the TPS65086 PMIC regulator: tps65086: Update regulator driver for the TPS65086 PMIC gpio: tps65086: Add GPO driver for the TPS65086 PMIC Documentation/devicetree/bindings/mfd/tps65086.txt | 55 drivers/gpio/Kconfig | 6 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-tps65086.c | 144 drivers/mfd/Kconfig| 13 ++ drivers/mfd/Makefile | 1 + drivers/mfd/tps65086.c | 150 + drivers/regulator/tps65086-regulator.c | 7 +- include/linux/mfd/tps65086.h | 118 9 files changed, 492 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/tps65086.txt create mode 100644 drivers/gpio/gpio-tps65086.c create mode 100644 drivers/mfd/tps65086.c create mode 100644 include/linux/mfd/tps65086.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/4] regulator: tps65086: Update regulator driver for the TPS65086 PMIC
Make changes to allow this driver to work with the updated TPS65086 core
driver and bindings.
Signed-off-by: Andrew F. Davis
---
drivers/regulator/tps65086-regulator.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/tps65086-regulator.c
b/drivers/regulator/tps65086-regulator.c
index c26fc7e..33f389d 100644
--- a/drivers/regulator/tps65086-regulator.c
+++ b/drivers/regulator/tps65086-regulator.c
@@ -16,10 +16,9 @@
*/
#include
-#include
+#include
#include
#include
-#include
#include
@@ -31,6 +30,7 @@ enum tps65086_regulators { BUCK1, BUCK2, BUCK3, BUCK4, BUCK5,
BUCK6, LDOA1,
.desc = { \
.name = _name,\
.of_match = of_match_ptr(_of),\
+ .regulators_node= "regulators", \
.of_parse_cb= tps65086_of_parse_cb, \
.id = _id, \
.ops= ®_ops, \
@@ -54,6 +54,7 @@ enum tps65086_regulators { BUCK1, BUCK2, BUCK3, BUCK4, BUCK5,
BUCK6, LDOA1,
.desc = { \
.name = _name,\
.of_match = of_match_ptr(_of),\
+ .regulators_node= "regulators", \
.of_parse_cb= tps65086_of_parse_cb, \
.id = _id, \
.ops= &switch_ops, \
@@ -213,8 +214,8 @@ static int tps65086_regulator_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, tps);
config.dev = &pdev->dev;
+ config.dev->of_node = tps->dev->of_node;
config.driver_data = tps;
- config.of_node = pdev->dev.of_node;
config.regmap = tps->regmap;
for (i = 0; i < ARRAY_SIZE(regulators); i++) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 05/19] ARM: dts: am57xx: cl-som-am57x: add eMMC support
CM-SOM-AM57X has two options of main storage devices - eMMC or NAND.
Add eMMC chip support (over MMC2 bus).
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 1badfa9..ef94845 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -36,6 +36,13 @@
default-state = "off";
};
};
+
+ vdd_3v3: fixedregulator-vdd_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
};
&dra7_pmx_core {
@@ -71,6 +78,21 @@
DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP |
MUX_MODE14) /* wakeup0.gpio1_0 */
>;
};
+
+ mmc2_pins_default: mmc2_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a23.mmc2_clk */
+ DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_cs1.mmc2_cmd */
+ DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a24.mmc2_dat0 */
+ DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a25.mmc2_dat1 */
+ DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a26.mmc2_dat2 */
+ DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a27.mmc2_dat3 */
+ DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a19.mmc2_dat4 */
+ DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a20.mmc2_dat5 */
+ DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a21.mmc2_dat6 */
+ DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a22.mmc2_dat7 */
+ >;
+ };
};
&i2c1 {
@@ -297,3 +319,15 @@
status = "okay";
};
};
+
+&mmc2 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins_default>;
+
+ vmmc-supply = <&vdd_3v3>;
+ bus-width = <8>;
+ ti,non-removable;
+ cap-mmc-dual-data-rate;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 08/19] ARM: dts: am57xx: cl-som-am57x: add USB support
Add USB support.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index fe4baba..c603136 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -478,3 +478,19 @@
pinctrl-0 = <&davinci_mdio_pins_default>;
pinctrl-1 = <&davinci_mdio_pins_sleep>;
};
+
+&usb2_phy1 {
+ phy-supply = <&ldousb_reg>;
+};
+
+&usb2_phy2 {
+ phy-supply = <&ldousb_reg>;
+};
+
+&usb1 {
+ dr_mode = "host";
+};
+
+&usb2 {
+ dr_mode = "peripheral";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 06/19] ARM: dts: am57xx: cl-som-am57x: add spi-flash support
On-board spi-flash chip is used as a main boot device.
Add spi-flash chip support (over QSPI bus).
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v3:
* Modify "compatible" property to match a proper flash driver
* Drop RX/TX bus with properties
* Reformat subject
v2:
* Add "spi-max-frequency" property for &qspi node.
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 42 +++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index ef94845..f7e163a 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -93,6 +93,17 @@
DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_a22.mmc2_dat7 */
>;
};
+
+ qspi1_pins: pinmux_qspi1_pins {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3474, PIN_INPUT | MUX_MODE1)
/* gpmc_a13.qspi1_rtclk */
+ DRA7XX_CORE_IOPAD(0x3480, PIN_INPUT | MUX_MODE1)
/* gpmc_a16.qspi1_d0 */
+ DRA7XX_CORE_IOPAD(0x3484, PIN_INPUT | MUX_MODE1)
/* gpmc_a17.qspi1_d1 */
+ DRA7XX_CORE_IOPAD(0x3488, PIN_INPUT | MUX_MODE1)
/* qpmc_a18.qspi1_sclk */
+ DRA7XX_CORE_IOPAD(0x34b8, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_cs2.qspi1_cs0 */
+ DRA7XX_CORE_IOPAD(0x34bc, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_cs3.qspi1_cs1 */
+ >;
+ };
};
&i2c1 {
@@ -331,3 +342,34 @@
ti,non-removable;
cap-mmc-dual-data-rate;
};
+
+&qspi {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&qspi1_pins>;
+
+ spi-max-frequency = <2000>;
+
+ spi_flash: spi_flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,m25p80", "jedec,spi-nor";
+ reg = <0>; /* CS0 */
+ spi-max-frequency = <2000>;
+
+ partition@0 {
+ label = "uboot";
+ reg = <0x0 0xc>;
+ };
+
+ partition@c {
+ label = "uboot environment";
+ reg = <0xc 0x4>;
+ };
+
+ partition@10 {
+ label = "reserved";
+ reg = <0x10 0x0>;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 00/19] Add support for CL-SOM-AM57X and SBC-AM57X
SBC-AM57X boards.
CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
SBC-AM57x is a single board computer, implemented with the
CL-SOM-AM57x computer-on-module providing most of the functions,
and SB-SOM-AM57x carrier board providing additional peripheral
functions and connectors.
The SBC-AM57x has the following features:
CPU:Texas Instruments Sitara AM5728 dual-core ARM Cortex-A15,
1.5GHz or
Texas Instruments Sitara AM5718 single-core ARM Cortex-A15,
1.5GHz
RAM:DDR3, 512MB – 4GB
Storage:NAND flash, 512MB - 1GB or eMMC flash, 4GB - 32GB
SPI-flash 2MB
Ethernet: Up to 2x 10/100/1000Mbps Ethernet ports (MAC+PHY)
WiFi/BT:802.11b/g/n WiFi interface (TI WiLink 8 WL1801 chipset) or
Dual-band 2x2 802.11a/b/g/n WiFi interface (TI WiLink 8 WL1837
chipset)
Analog Audio: Audio codec with stereo output, stereo input and microphone
support
More details can be found here:
https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/
This series is based on the following patch set ("Add support for sbc-t43"
Nikita Kiryanov):
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg121905.html
Changes in V2:
- Removed unnecessary line breaks in end of file and elsewhere
- Changed subject lines to start with "ARM: dts:"
- PMIC moved from I2C1 to I2C4
- Fixed SPI flash compatible string
- Skipped resetting ETH PHYs
- Fixed HDMI lanes polarity
Dmitry Lifshitz (19):
ARM: dts: am57xx: cl-som-am57x: add basic module support
ARM: dts: am57xx: cl-som-am57x: dts: add RTC support
ARM: dts: am57xx: cl-som-am57x: add I2C3 support
ARM: dts: am57xx: cl-som-am57x: add EEPROM support
ARM: dts: am57xx: cl-som-am57x: add eMMC support
ARM: dts: am57xx: cl-som-am57x: add spi-flash support
ARM: dts: am57xx: cl-som-am57x: add dual EMAC support
ARM: dts: am57xx: cl-som-am57x: add USB support
ARM: dts: am57xx: cl-som-am57x: add touchscreen support
ARM: dts: am57xx: cl-som-am57x: add analog audio support
ARM: dts: am57xx: sbc-am57x: add basic board support
ARM: dts: am57xx: cl-som-am57x: add MMC1 support
ARM: dts: am57xx: sbc-am57x: add usb vbus pinmux
ARM: dts: am57xx: sbc-am57x: add EEPROM support
ARM: dts: am57xx: sbc-am57x: add GPIO expander support
ARM: dts: am57xx: sbc-am57x: add LCD support
ARM: dts: am57xx: compulab-sb-som: add HDMI connector
ARM: dts: am57xx: sbc-am57x: add HDMI support
ARM: dts: am57xx: cl-som-am57x: skip resetting ETH PHYs
.../devicetree/bindings/arm/omap/omap.txt | 6 +
arch/arm/boot/dts/Makefile | 4 +-
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 617 +
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 179 ++
arch/arm/boot/dts/compulab-sb-som.dtsi | 7 +
5 files changed, 812 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts
create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 10/19] ARM: dts: am57xx: cl-som-am57x: add analog audio support
Add analog audio DT nodes:
1. simple-audio-card node
2. wm8731 codec node
3. MCASP3 pinmux
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 67 +++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index a75c382..b2c4451 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -50,6 +50,33 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+ sound0: sound@0 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "CL-SOM-AM57x-Sound-Card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&dailink0_master>;
+ simple-audio-card,frame-master = <&dailink0_master>;
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Microphone", "Microphone Jack",
+ "Line", "Line Jack";
+ simple-audio-card,routing =
+ "Headphone Jack", "RHPOUT",
+ "Headphone Jack", "LHPOUT",
+ "LLINEIN", "Line Jack",
+ "MICIN", "Mic Bias",
+ "Mic Bias", "Microphone Jack";
+
+ dailink0_master: simple-audio-card,cpu {
+ sound-dai = <&mcasp3>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&wm8731>;
+ system-clock-frequency = <1200>;
+ };
+ };
};
&dra7_pmx_core {
@@ -196,6 +223,24 @@
DRA7XX_CORE_IOPAD(0x3464, PIN_INPUT_PULLDOWN |
MUX_MODE14) /* gpmc_a9.gpio1_31 */
>;
};
+
+ mcasp3_pins_default: mcasp3_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3724, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* mcasp3_aclkx.mcasp3_aclkx */
+ DRA7XX_CORE_IOPAD(0x3728, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* mcasp3_fsx.mcasp3_fsx */
+ DRA7XX_CORE_IOPAD(0x372c, PIN_OUTPUT_PULLDOWN |
MUX_MODE0) /* mcasp3_axr0.mcasp3_axr0 */
+ DRA7XX_CORE_IOPAD(0x3730, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* mcasp3_axr1.mcasp3_axr1 */
+ >;
+ };
+
+ mcasp3_pins_sleep: mcasp3_pins_sleep {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3724, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3728, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x372c, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3730, PIN_INPUT | MUX_MODE15)
+ >;
+ };
};
&i2c1 {
@@ -392,6 +437,13 @@
reg = <0x50>;
pagesize = <16>;
};
+
+ wm8731: wm8731@1a {
+ #sound-dai-cells = <0>;
+ compatible = "wlf,wm8731";
+ reg = <0x1a>;
+ status = "okay";
+ };
};
&cpu0 {
@@ -538,3 +590,18 @@
&usb2 {
dr_mode = "peripheral";
};
+
+&mcasp3 {
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&mcasp3_pins_default>;
+ pinctrl-1 = <&mcasp3_pins_sleep>;
+ status = "okay";
+
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ /* 4 serializers */
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 1 2 0 0
+ >;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 16/19] ARM: dts: am57xx: sbc-am57x: add LCD support
Startek-kd050c 800x480 LCD panel timings are described in
compulab-sb-som.dtsi.
Add appropriate DT endpoints to connect DPI output and LCD.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index edce6c6..8e4c0fd 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -15,6 +15,10 @@
/ {
model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x",
"ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
+
+ aliases {
+ display0 = &lcd0;
+ };
};
&dra7_pmx_core {
@@ -50,6 +54,12 @@
DRA7XX_CORE_IOPAD(0x36b8, PIN_INPUT| MUX_MODE10)
/* mcasp1_axr1.i2c5_scl */
>;
};
+
+ lcd_pins_default: lcd_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3564, PIN_OUTPUT | MUX_MODE14)
/* vin2a_vsync0.gpio4_0 */
+ >;
+ };
};
&uart3 {
@@ -97,3 +107,31 @@
#gpio-cells = <2>;
};
};
+
+&dss {
+ status = "ok";
+
+ vdda_video-supply = <&ldoln_reg>;
+
+ port {
+ dpi_lcd_out: endpoint@0 {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <24>;
+ };
+ };
+};
+
+&lcd0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins_default>;
+
+ enable-gpios = <&pca9555 14 GPIO_ACTIVE_HIGH
+ &gpio4 0 GPIO_ACTIVE_HIGH>;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_lcd_out>;
+ data-lines = <24>;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 12/19] ARM: dts: am57xx: cl-som-am57x: add MMC1 support
Add MMC1 support, used for SD/MMC card.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v3:
* No fuctional changes
* Reformat subject
v2:
* Fix duplicate SD Card Detect pinmux
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 804ad72..93852e2 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -24,6 +24,19 @@
DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)
/* uart2_rtsn.uart3_txd */
>;
};
+
+ mmc1_pins_default: mmc1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat3.dat3 */
+ DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14)
/* mmc1_sdcd.gpio6_27 */
+ DRA7XX_CORE_IOPAD(0x377c, PIN_INPUT | MUX_MODE14)
/* mmc1_sdwp.gpio6_28 */
+ >;
+ };
};
&uart3 {
@@ -34,3 +47,15 @@
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins_default>;
};
+
+&mmc1 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_default>;
+
+ vmmc-supply = <&ldo1_reg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio6 27 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio6 28 GPIO_ACTIVE_HIGH>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/19] ARM: dts: am57xx: cl-som-am57x: skip resetting ETH PHYs
ETH PHYs setup on CL-SOM-AM57X is established in U-Boot along with
bringing them out of reset. This is done by toggling GPIOs belonging
to GPIO2/3 controllers on AM57xx.
Skip resetting ETH PHYs, by adding "ti,no-reset-on-init" to GPIO2/3
controllers DT nodes.
Signed-off-by: Dmitry Lifshitz
---
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index b2c4451..c538826 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -605,3 +605,13 @@
1 2 0 0
>;
};
+
+&gpio3 {
+ status = "okay";
+ ti,no-reset-on-init;
+};
+
+&gpio2 {
+ status = "okay";
+ ti,no-reset-on-init;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 07/19] ARM: dts: am57xx: cl-som-am57x: add dual EMAC support
Add dual EMAC support.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v3:
* No fuctional changes
* Reformat subject
v2:
* Fix pinmux comments for RGMII0/1 clock/data lines
* Fix pinmux for MDIO bus clock/data lines
* Fix PHYs addresses
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 105 ++
1 file changed, 105 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index f7e163a..fe4baba 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -104,6 +104,85 @@
DRA7XX_CORE_IOPAD(0x34bc, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_cs3.qspi1_cs1 */
>;
};
+
+ cpsw_pins_default: cpsw_pins_default {
+ pinctrl-single,pins = <
+ /* Slave at addr 0x0 */
+ DRA7XX_CORE_IOPAD(0x3650, PIN_OUTPUT | MUX_MODE0)
/* rgmii0_tclk */
+ DRA7XX_CORE_IOPAD(0x3654, PIN_OUTPUT | MUX_MODE0)
/* rgmii0_tctl */
+ DRA7XX_CORE_IOPAD(0x3658, PIN_OUTPUT | MUX_MODE0)
/* rgmii0_td3 */
+ DRA7XX_CORE_IOPAD(0x365c, PIN_OUTPUT | MUX_MODE0)
/* rgmii0_td2 */
+ DRA7XX_CORE_IOPAD(0x3660, PIN_OUTPUT | MUX_MODE0)
/* rgmii0_td1 */
+ DRA7XX_CORE_IOPAD(0x3664, PIN_OUTPUT | MUX_MODE0)
/* rgmii0_td0 */
+ DRA7XX_CORE_IOPAD(0x3668, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* rgmii0_rclk */
+ DRA7XX_CORE_IOPAD(0x366c, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* rgmii0_rctl */
+ DRA7XX_CORE_IOPAD(0x3670, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* rgmii0_rd3 */
+ DRA7XX_CORE_IOPAD(0x3674, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* rgmii0_rd2 */
+ DRA7XX_CORE_IOPAD(0x3678, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* rgmii0_rd1 */
+ DRA7XX_CORE_IOPAD(0x367c, PIN_INPUT_PULLDOWN |
MUX_MODE0) /* rgmii0_rd0 */
+
+ /* Slave at addr 0x1 */
+ DRA7XX_CORE_IOPAD(0x3598, PIN_OUTPUT | MUX_MODE3)
/* vin2a_d12.rgmii1_tclk */
+ DRA7XX_CORE_IOPAD(0x359c, PIN_OUTPUT | MUX_MODE3)
/* vin2a_d13.rgmii1_tctl */
+ DRA7XX_CORE_IOPAD(0x35a0, PIN_OUTPUT | MUX_MODE3)
/* vin2a_d14.rgmii1_td3 */
+ DRA7XX_CORE_IOPAD(0x35a4, PIN_OUTPUT | MUX_MODE3)
/* vin2a_d15.rgmii1_td2 */
+ DRA7XX_CORE_IOPAD(0x35a8, PIN_OUTPUT | MUX_MODE3)
/* vin2a_d16.rgmii1_td1 */
+ DRA7XX_CORE_IOPAD(0x35ac, PIN_OUTPUT | MUX_MODE3)
/* vin2a_d17.rgmii1_td0 */
+ DRA7XX_CORE_IOPAD(0x35b0, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* vin2a_d18.rgmii1_rclk */
+ DRA7XX_CORE_IOPAD(0x35b4, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* vin2a_d19.rgmii1_rctl */
+ DRA7XX_CORE_IOPAD(0x35b8, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* vin2a_d20.rgmii1_rd3 */
+ DRA7XX_CORE_IOPAD(0x35bc, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* vin2a_d21.rgmii1_rd2 */
+ DRA7XX_CORE_IOPAD(0x35c0, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* vin2a_d22.rgmii1_rd1 */
+ DRA7XX_CORE_IOPAD(0x35c4, PIN_INPUT_PULLUP | MUX_MODE3)
/* vin2a_d23.rgmii1_rd0 */
+ >;
+ };
+
+ cpsw_pins_sleep: cpsw_pins_sleep {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ DRA7XX_CORE_IOPAD(0x3650, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3654, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3658, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x365c, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3660, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3664, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3668, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x366c, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3670, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3674, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x3678, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x367c, PIN_INPUT | MUX_MODE15)
+
+ /* Slave 2 */
+ DRA7XX_CORE_IOPAD(0x3598, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x359c, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x35a0, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x35a4, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x35a8, PIN_INPUT | MUX_MODE15)
+ DRA7XX_CORE_IOPAD(0x35ac, PIN_INPUT | MUX_MODE15)
+
[PATCH V2 13/19] ARM: dts: am57xx: sbc-am57x: add usb vbus pinmux
usb1_drvvbus pin is used to Drive-VBUS enable to external charge
pump/power switch.
Add a pinmux for that pin.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 93852e2..17a1972 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -37,6 +37,12 @@
DRA7XX_CORE_IOPAD(0x377c, PIN_INPUT | MUX_MODE14)
/* mmc1_sdwp.gpio6_28 */
>;
};
+
+ usb1_pins: pinmux_usb1_pins {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3680, PIN_INPUT_SLEW | MUX_MODE0)
/* usb1_drvvbus */
+ >;
+ };
};
&uart3 {
@@ -59,3 +65,8 @@
cd-gpios = <&gpio6 27 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 28 GPIO_ACTIVE_HIGH>;
};
+
+&usb1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_pins>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 04/19] ARM: dts: am57xx: cl-som-am57x: add EEPROM support
On-board EEPROM chip is used for storing a board production
info.
Add module EEPROM support (over I2C4 bus).
Signed-off-by: Dmitry Lifshitz
---
v3:
* No fuctional changes
* Reformat subject
v2:
* Fix EEPROM chip model
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 2074fd4..1badfa9 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -261,6 +261,12 @@
compatible = "emmicro,em3027";
reg = <0x56>;
};
+
+ eeprom_module: atmel@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
};
&cpu0 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 09/19] ARM: dts: am57xx: cl-som-am57x: add touchscreen support
Add ADS7846 touchscreen support.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 44 +++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index c603136..a75c382 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -43,6 +43,13 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+ ads7846reg: fixedregulator-ads7846-reg {
+ compatible = "regulator-fixed";
+ regulator-name = "ads7846-reg";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
};
&dra7_pmx_core {
@@ -183,6 +190,12 @@
DRA7XX_CORE_IOPAD(0x3594, PIN_INPUT | MUX_MODE15)
>;
};
+
+ ads7846_pins: pinmux_ads7846_pins {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3464, PIN_INPUT_PULLDOWN |
MUX_MODE14) /* gpmc_a9.gpio1_31 */
+ >;
+ };
};
&i2c1 {
@@ -451,6 +464,37 @@
reg = <0x10 0x0>;
};
};
+
+ /* touch controller */
+ ads7846@0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ads7846_pins>;
+
+ compatible = "ti,ads7846";
+ vcc-supply = <&ads7846reg>;
+
+ reg = <1>; /* CS1 */
+ spi-max-frequency = <150>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <31 0>;
+ pendown-gpio = <&gpio1 31 0>;
+
+
+ ti,x-min = /bits/ 16 <0x0>;
+ ti,x-max = /bits/ 16 <0x0fff>;
+ ti,y-min = /bits/ 16 <0x0>;
+ ti,y-max = /bits/ 16 <0x0fff>;
+
+ ti,x-plate-ohms = /bits/ 16 <180>;
+ ti,pressure-max = /bits/ 16 <255>;
+
+ ti,debounce-max = /bits/ 16 <30>;
+ ti,debounce-tol = /bits/ 16 <10>;
+ ti,debounce-rep = /bits/ 16 <1>;
+
+ linux,wakeup;
+ };
};
&mac {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 18/19] ARM: dts: am57xx: sbc-am57x: add HDMI support
Add HDMI video output support.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* Fix HDMI lanes polarity
* Reformat subject
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 8e4c0fd..77bb8e1 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -18,6 +18,7 @@
aliases {
display0 = &lcd0;
+ display1 = &hdmi;
};
};
@@ -60,6 +61,19 @@
DRA7XX_CORE_IOPAD(0x3564, PIN_OUTPUT | MUX_MODE14)
/* vin2a_vsync0.gpio4_0 */
>;
};
+
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3808, PIN_INPUT | MUX_MODE1)
/* i2c2_sda.hdmi1_ddc_scl */
+ DRA7XX_CORE_IOPAD(0x380c, PIN_INPUT | MUX_MODE1)
/* i2c2_scl.hdmi1_ddc_sda */
+ >;
+ };
+
+ hdmi_conn_pins: pinmux_hdmi_conn_pins {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x37b8, PIN_INPUT | MUX_MODE14)
/* spi1_cs2.gpio7_12 */
+ >;
+ };
};
&uart3 {
@@ -135,3 +149,31 @@
};
};
};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&ldo4_reg>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pins>;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ lanes = <1 0 3 2 5 4 7 6>;
+ };
+ };
+};
+
+&hdmi_conn {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_conn_pins>;
+
+ hpd-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 03/19] ARM: dts: am57xx: cl-som-am57x: add I2C3 support
Enable I2C3 bus and add appropriate pinmux.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Refactor patch with respect to the previous changes in I2C4 node structure
* Reformat subject
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 58156a9..2074fd4 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -52,6 +52,13 @@
>;
};
+ i2c3_pins_default: i2c3_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x36a4, PIN_INPUT| MUX_MODE10)
/* mcasp1_aclkx.i2c3_sda */
+ DRA7XX_CORE_IOPAD(0x36a8, PIN_INPUT| MUX_MODE10)
/* mcasp1_fsx.i2c3_scl */
+ >;
+ };
+
i2c4_pins_default: i2c4_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x36ac, PIN_INPUT| MUX_MODE10)
/* mcasp1_acl.i2c4_sda */
@@ -73,6 +80,13 @@
clock-frequency = <40>;
};
+&i2c3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins_default>;
+ clock-frequency = <40>;
+};
+
&i2c4 {
status = "okay";
pinctrl-names = "default";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 14/19] ARM: dts: am57xx: sbc-am57x: add EEPROM support
On-board EEPROM chip is used for storing a board production info.
Add carrier board EEPROM support (over I2C5 bus).
Signed-off-by: Dmitry Lifshitz
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 17a1972..a3588ba 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -43,6 +43,13 @@
DRA7XX_CORE_IOPAD(0x3680, PIN_INPUT_SLEW | MUX_MODE0)
/* usb1_drvvbus */
>;
};
+
+ i2c5_pins_default: i2c5_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x36b4, PIN_INPUT| MUX_MODE10)
/* mcasp1_axr0.i2c5_sda */
+ DRA7XX_CORE_IOPAD(0x36b8, PIN_INPUT| MUX_MODE10)
/* mcasp1_axr1.i2c5_scl */
+ >;
+ };
};
&uart3 {
@@ -70,3 +77,16 @@
pinctrl-names = "default";
pinctrl-0 = <&usb1_pins>;
};
+
+&i2c5 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5_pins_default>;
+ clock-frequency = <40>;
+
+ eeprom_base: atmel@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 02/19] ARM: dts: am57xx: cl-som-am57x: dts: add RTC support
Add EM3027 RTC chip support (over I2C4 bus).
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes.
* Refactor patch with respect to the previous changes in I2C4 node structure.
* Reformat subject
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 087d62e..58156a9 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -242,6 +242,11 @@
#gpio-cells = <2>;
};
};
+
+ rtc0: rtc@56 {
+ compatible = "emmicro,em3027";
+ reg = <0x56>;
+ };
};
&cpu0 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 15/19] ARM: dts: am57xx: sbc-am57x: add GPIO expander support
Add PCA9555 GPIO expander support (over I2C5 bus).
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v3:
* No fuctional changes
* Reformat subject
v2:
* Fixed patch subject/description
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index a3588ba..edce6c6 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -89,4 +89,11 @@
reg = <0x50>;
pagesize = <16>;
};
+
+ pca9555: pca9555@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 01/19] ARM: dts: am57xx: cl-som-am57x: add basic module support
Add support for CompuLab CM-SOM-AM57X board.
CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
Add basic DT support for standalone module (without a carrier board):
* Memory configuration
* Heartbeat led
* I2C1 and I2C4
* PMIC
* SATA
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v3:
* Move PMIC to I2C4
* Reformat subject
v2:
* Fixed voltages (for OPP_HIGH) for VDD_GPU, VDD_IVA, VDD_DSPEVE
* Added comments for VDDA_1V8_PHYA/B
* Add "regulator-always-on" property for ldousb_reg
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 274 +
3 files changed, 279 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index da84372..dd53c90 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -156,6 +156,9 @@ Boards:
- AM437x SK EVM: AM437x StarterKit Evaluation Module
compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
+- AM57XX CL-SOM-AM57x
+ compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74",
"ti,dra7"
+
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5492a24..803a020 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -477,8 +477,9 @@ dtb-$(CONFIG_SOC_OMAP5) += \
omap5-sbc-t54.dtb \
omap5-uevm.dtb
dtb-$(CONFIG_SOC_DRA7XX) += \
- dra7-evm.dtb \
am57xx-beagle-x15.dtb \
+ am57xx-cl-som-am57x.dtb \
+ dra7-evm.dtb \
dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += \
orion5x-lacie-d2-network.dtb \
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
new file mode 100644
index 000..087d62e
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -0,0 +1,274 @@
+/*
+ * Support for CompuLab CL-SOM-AM57x System-on-Module
+ *
+ * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Dmitry Lifshitz
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "dra74x.dtsi"
+
+/ {
+ model = "CompuLab CL-SOM-AM57x";
+ compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742",
"ti,dra74", "ti,dra7";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x2000>; /* 512 MB - minimal
configuration */
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins_default>;
+
+ led@0 {
+ label = "cl-som-am57x:green";
+ gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+ };
+};
+
+&dra7_pmx_core {
+ leds_pins_default: leds_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)
/* gpmc_a15.gpio2_5 */
+ >;
+ };
+
+ i2c1_pins_default: i2c1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c1_sda.sda */
+ DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c1_scl.scl */
+ >;
+ };
+
+ i2c4_pins_default: i2c4_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x36ac, PIN_INPUT| MUX_MODE10)
/* mcasp1_acl.i2c4_sda */
+ DRA7XX_CORE_IOPAD(0x36b0, PIN_INPUT| MUX_MODE10)
/* mcasp1_fsr.i2c4_scl */
+ >;
+ };
+
+ tps659038_pins_default: tps659038_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP |
MUX_MODE14) /* wakeup0.gpio1_0 */
+ >;
+ };
+};
+
+&i2c1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_default>;
+ clock-frequency = <40>;
+};
+
+&i2c4 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins_default>;
+ clock-frequency = <40>;
+
+ tps659038: tps659038@58
[PATCH V2 11/19] ARM: dts: am57xx: sbc-am57x: add basic board support
SBC-AM57x is a single board computer designed for industrial and
embedded applications. It is based on the Texas Instruments Sitara AM57x
system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
computer-on-module providing most of the functions, and SB-SOM-AM57x
carrier board providing additional peripheral functions and connectors.
https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/
https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
Add basic board support, including UART3, used as a serial console.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
.../devicetree/bindings/arm/omap/omap.txt | 3 ++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am57xx-sbc-am57x.dts | 36 ++
3 files changed, 40 insertions(+)
create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dd53c90..42cdad1 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -159,6 +159,9 @@ Boards:
- AM57XX CL-SOM-AM57x
compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74",
"ti,dra7"
+- AM57XX SBC-AM57x
+ compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728",
"ti,dra742", "ti,dra74", "ti,dra7"
+
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 803a020..4c73ab9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
dtb-$(CONFIG_SOC_DRA7XX) += \
am57xx-beagle-x15.dtb \
am57xx-cl-som-am57x.dtb \
+ am57xx-sbc-am57x.dtb \
dra7-evm.dtb \
dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += \
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
new file mode 100644
index 000..804ad72
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -0,0 +1,36 @@
+/*
+ * Support for CompuLab SBC-AM57x single board computer
+ *
+ * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Dmitry Lifshitz
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include "am57xx-cl-som-am57x.dts"
+#include "compulab-sb-som.dtsi"
+
+/ {
+ model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
+ compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x",
"ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
+};
+
+&dra7_pmx_core {
+ uart3_pins_default: uart3_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)
/* uart2_ctsn.uart3_rxd */
+ DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)
/* uart2_rtsn.uart3_txd */
+ >;
+ };
+};
+
+&uart3 {
+ status = "okay";
+ interrupts-extended = <&crossbar_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ <&dra7_pmx_core 0x3f8>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins_default>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 17/19] ARM: dts: am57xx: compulab-sb-som: add HDMI connector
Add HDMI connector node without a valid input endpoint.
CompuLab SB-SOM is a carrier board, hence the endpoint
should be added in the board DT with a valid HDMI output.
Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
---
v2:
* No fuctional changes
* Reformat subject
arch/arm/boot/dts/compulab-sb-som.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi
b/arch/arm/boot/dts/compulab-sb-som.dtsi
index 402a143..93d7e23 100644
--- a/arch/arm/boot/dts/compulab-sb-som.dtsi
+++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
@@ -39,4 +39,11 @@
pixelclk-active = <1>;
};
};
+
+ hdmi_conn: connector@0 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ type = "a";
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 2/2] ASoC: pcm3168a: Add driver for pcm3168a codec
On Mon, Nov 30, 2015 at 04:49:30PM +, Damien Horsley wrote: > On 27/11/15 12:54, Mark Brown wrote: > > Please try to keep your CC lists reasonable - only CC people who have an > > interest in the patch you're posting. The CC list you have here is far > > too broad, I can't figure out why a lot of the people there ended up > > there. If you've got 10 people that's generally a warning sign. > The list was generated by scripts/get_maintainer.pl when used on the > patches. I will remove some that look like they don't need to be there. You should not be using get_maintainer unfiltered, you need to think about why everyone is there. People often end up getting included due to just random cleanups and getting lots of mail about drivers they have no lasting interest in may be demotivating. > > Being in right justified mode *does* have an effect - it changes where > > the audio data starts relative to LRCLK. It is true that if the frame > > has exactly the right number of clocks left and right justified are > > identical but extra clocks are in general permitted so it looks like > > your right justified case above just isn't something the device really > > supports. > Should the value returned by snd_soc_params_to_frame_size be treated as > the minimum frame size? Yes, in general most hardware is perfectly happy with extra clocks. signature.asc Description: PGP signature
Re: [PATCH 4/4] dmaengine: qcom_bam_dma: add controlled remotely dt property
On Tue, Dec 01, 2015 at 11:14:59AM +0200, Stanimir Varbanov wrote:
> Some of the peripherals has bam which is controlled by remote
> processor, thus the bam dma driver must avoid register writes
> which initialise bam hw block. Those registers are protected
> from xPU block and any writes to them will lead to secure
> violation and system reboot.
>
> Adding the contolled_remotely flag in bam driver to avoid
> not permitted register writes in bam_init function.
>
> Signed-off-by: Stanimir Varbanov
> ---
> .../devicetree/bindings/dma/qcom_bam_dma.txt |2 ++
> drivers/dma/qcom_bam_dma.c |7 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
> b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
> index 1c9d48ea4914..87b6b2bf5e1e 100644
> --- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
> @@ -13,6 +13,8 @@ Required properties:
> - clock-names: must contain "bam_clk" entry
> - qcom,ee : indicates the active Execution Environment identifier (0-7) used
> in
>the secure world.
> +- qcom,controlled-remotely : optional, indicates that the bam is controled by
> + remote proccessor i.e. execution enviroment.
Please fix the spelling. controlled, environment. Otherwise looks ok.
>
> Example:
>
> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
> index 6d290de9ab2b..5dedab77180a 100644
> --- a/drivers/dma/qcom_bam_dma.c
> +++ b/drivers/dma/qcom_bam_dma.c
> @@ -387,6 +387,7 @@ struct bam_device {
>
> /* execution environment ID, from DT */
> u32 ee;
> + bool controlled_remotely;
>
> const struct reg_offset_data *layout;
>
> @@ -1039,6 +1040,9 @@ static int bam_init(struct bam_device *bdev)
> val = readl_relaxed(bam_addr(bdev, 0, BAM_NUM_PIPES));
> bdev->num_channels = val & BAM_NUM_PIPES_MASK;
>
> + if (bdev->controlled_remotely)
> + return 0;
> +
> /* s/w reset bam */
> /* after reset all pipes are disabled and idle */
> val = readl_relaxed(bam_addr(bdev, 0, BAM_CTRL));
> @@ -1126,6 +1130,9 @@ static int bam_dma_probe(struct platform_device *pdev)
> return ret;
> }
>
> + bdev->controlled_remotely = of_property_read_bool(pdev->dev.of_node,
> + "qcom,controlled-remotely");
> +
> bdev->bamclk = devm_clk_get(bdev->dev, "bam_clk");
> if (IS_ERR(bdev->bamclk))
> return PTR_ERR(bdev->bamclk);
Reviewed-by: Andy Gross
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] dmaengine: qcom_bam_dma: clear BAM interrupt only if it is rised
On Tue, Dec 01, 2015 at 11:14:57AM +0200, Stanimir Varbanov wrote:
> Currently we write BAM_IRQ_CLR register with zero even when no
> BAM_IRQ occured. This write has some bad side effects when the
> BAM instance is for the crypto engine. In case of crypto engine
> some of the BAM registers are xPU protected and they cannot be
> controlled by the driver.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/dma/qcom_bam_dma.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
> index dc9da477eb69..0f06f3b7a72b 100644
> --- a/drivers/dma/qcom_bam_dma.c
> +++ b/drivers/dma/qcom_bam_dma.c
> @@ -800,13 +800,17 @@ static irqreturn_t bam_dma_irq(int irq, void *data)
> if (srcs & P_IRQ)
> tasklet_schedule(&bdev->task);
>
> - if (srcs & BAM_IRQ)
> + if (srcs & BAM_IRQ) {
> clr_mask = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_STTS));
>
> - /* don't allow reorder of the various accesses to the BAM registers */
> - mb();
> + /*
> + * don't allow reorder of the various accesses to the BAM
> + * registers
> + */
> + mb();
>
> - writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
> + writel_relaxed(clr_mask, bam_addr(bdev, 0, BAM_IRQ_CLR));
> + }
Looks good. We shouldn't be accessing this unless there is actually an irq
shown in the srcs.
Thanks for catching this.
Reviewed-by: Andy Gross
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
