Re: [PATCH v2 3/3] ARM: dts: qcom: Add SDHC nodes for APQ8084 platform
Hi Andreas,
On 01/11/14 15:43, Andreas Färber wrote:
Hi Georgi,
Am 14.10.2014 um 18:17 schrieb Georgi Djakov:
On 10/10/2014 08:14 PM, Bjorn Andersson wrote:
On Tue, Sep 2, 2014 at 8:40 AM, Georgi Djakov gdja...@mm-sol.com wrote:
Enable support for the two SD host controllers on the APQ8084 platform
by adding the required nodes to the DT files.
On the IFC6540 board, the first controller is connected to the onboard
eMMC and the second is connected to a micro-SD card slot.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
[...]
---
arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 11 +++
arch/arm/boot/dts/qcom-apq8084.dtsi| 23 +++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index e41cb8a..c9ff108 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
[..]
+ sdhci@f98a4900 {
+ cd-gpios = tlmm 122 GPIO_ACTIVE_LOW;
+ bus-width = 4;
...why do you add this node and leave it disabled in the dts?
Hi Bjorn,
Currently only the eMMC is functional on this board, so now we
have just the board specific configuration under this node.
More patches are forthcoming.
Any update on this? This still seems to be the latest IFC6540 commit:
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/commit/66c04e30f4a6e6ed998a6c154a6c45b3cd5b3fde
Following the instructions in https://wiki.linaro.org/Boards/IFC6540
I did update the wiki with more instructions to flash rootfs on to eMMC.
I've tried to pass a full rootfs as ramdisk parameter (fastboot boot -c
console=ttyMSM0,115200,n8 rw rootwait -b 0x0 zImage-ifc6540
initrd.cpio.gz), but I then get:
There is a typo here, I fixed it as well.
#sudo fastboot boot -c console=ttyMSM0,115200,n8 root=/dev/mmcblk0p25
rootwait rw -b 0x8020 zImage-dtb
Could you give this a try?
[258660] fastboot: download:12738800
[268150] fastboot: boot
[268150] kernel/ramdisk addresses overlap with aboot addresses.
Booting without ramdisk specified works, but for lack of SD, USB and
network support I then have no root.
Now you can flash the rootfs into the eMMC partition.
So, do you have any new insights on why 'status = okay;' doesn't work
for the above sdhci node? Or do you have a working config you can share
for creating a non-overlapping abootimg?
thanks,
sirni
Regards,
Andreas
--
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] Documentation: devicetree: Add bindings for Wi2Wi w2sg0004 gps
ping (questions for directions at the end of the mail).
Am 24.10.2014 um 11:32 schrieb Dr. H. Nikolaus Schaller h...@goldelico.com:
Am 20.10.2014 um 19:26 schrieb Dr. H. Nikolaus Schaller h...@goldelico.com:
Hi,
Am 20.10.2014 um 11:35 schrieb Mark Rutland mark.rutl...@arm.com:
Hi,
On Fri, Oct 17, 2014 at 08:55:50PM +0100, Dr. H. Nikolaus Schaller wrote:
Am 17.10.2014 um 13:00 schrieb Mark Rutland mark.rutl...@arm.com:
On Fri, Oct 17, 2014 at 11:16:42AM +0100, Dr. H. Nikolaus Schaller wrote:
Am 17.10.2014 um 11:37 schrieb Mark Rutland mark.rutl...@arm.com:
On Thu, Oct 16, 2014 at 09:26:23PM +0100, Marek Belisko wrote:
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 44
++
1 file changed, 44 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
new file mode 100644
index 000..e11
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
@@ -0,0 +1,44 @@
+Wi2Wi GPS module connected through UART
+
+Required properties:
+- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
+- pinctrl: specify two states (default and monitor). One is the
default (UART) mode
+ and the other is for monitoring the RX line by an interrupt
+- on-off-gpio: the GPIO that controls the module's on-off toggle input
+
+Optional properties:
+- lna-suppy: an (optional) LNA regulator that is enabled together
with the GPS receiver
+
+example:
+
+gps_receiver: w2sg0004 {
+compatible = wi2wi,w2sg0004;
I couldn't spot wi2wi in
Documentation/devicetree/bindings/vendor-prefixes.txt (in mainline).
Could you please add it?
+gpio-controller;
+#gpio-cells = 2;
As far as I can see, these properties aren't necessary. This only
consumes a GPIO, it doesn't provide any.
Well, it provides one GPIO. Sort of a virtual“ GPIO. It is needed so
that
it can be wired up to the DTR gpio of the UART driver (unfortunately this
patch was reverted some months ago from mainline and we will reintroduce
it soon).
If this GPIO doesn't really exist, then it's a Linux internal
implementation detail rather than a description of the hardware, and
doesn't really belong in the DT.
Hm.
Let’s describe it differently.
I can see the Linux driver module as a simple software simulation for a
piece of hardware that could have been connected between the UART
and the GPS chip.
Basically it is a pulse-generator and a flip-flop to detect data flow on
the RX
wire. This could be implemented by an external FPGA or uController. Or as
it is done on our board for saving hardware by a mix of the main CPU
hardware
(Pinmux + GPIO + IRQ) and a kernel driver.
The best of course would have been if the w2sg0004 would have a physical
„enable“ GPIO (instead of that on-off control input).
Then we would hook up that enable to some physical GPIO of the CPU
and simply refer to it as e.g. gpio4 12. And would not even need a
driver
for it (unless we want to make rfkill gps work).
Therefore the driver we suggest provides an additional gpio controller
with a
single GPIO so that we can write w2sg 0 to refer to this virtual gpio.
So in fact we try to wrap a non-optimal chip design by the driver and make
it
appear as a standard GPIO interface to the DT and user space and whoever
needs simply to enable/disable the GPS chip.
The fact remains that this does not accurately represent the hardware,
and is unnecessarily strongly tied to a particular UART design (where
the DTR line is a separate UART).
I don’t get that it is tied to a particular UART design (except that our DTR
patch affects to omap-serial only).
Let’s describe the facts:
The chip has this interface:
GPS-TX (output)
GPS-RX (input)
ON/OFF (input) - to toggle the power state of the chip
They are connected to an OMAP3 UART2 as
UART2-TX GPS-RX
UART2-RX - GPS-TX
GPIO145 - ON/OFF
That’s it.
If the chip (or any other serial GPS receiver like a Garmin) were connected
through real RS232 we would have
UART2-TX - level shifter - cable - level shifter - GPS-RX
UART2-RX - level shifter - cable - level shifter - GPS-TX
DTR-GPIO - level shifter (DTR line) - cable - level shifter -
power-management logic - ON/OFF
But because it is connected directly, we need to implement the
power-management
logic between the DTR-GPIO and GPIO145:
DTR-GPIO - driver - GPIO145 - ON/OFF
To correctly determine the state we need to tap the RX signal before
it enters the UART2-RX (it is pinmuxed with GPIO147):
UART2-RX ——+
OMAP3 pinmux - OMAP3 pad - GPS-TX
GPIO147 ——+
So if we describe the
[PATCH v3 1/2] ARM: dts: rockchip: Add EMAC Rockchip for RK3066 SoCs
This patch adds the right pins topology for the MAC and MDIO
found in RK3066 SoCs. Boards based on this SoC have an
initial support for the emac-rockchip dt-binding.
Signed-off-by: Romain Perier romain.per...@gmail.com
---
arch/arm/boot/dts/rk3066a.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index ad9c2db..7bec55f 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -179,6 +179,24 @@
bias-disable;
};
+ emac {
+ emac_xfer: emac-xfer {
+ rockchip,pins = RK_GPIO1 16 RK_FUNC_2
pcfg_pull_none, /* mac_clk */
+ RK_GPIO1 17 RK_FUNC_2
pcfg_pull_none, /* tx_en */
+ RK_GPIO1 18 RK_FUNC_2
pcfg_pull_none, /* txd1 */
+ RK_GPIO1 19 RK_FUNC_2
pcfg_pull_none, /* txd0 */
+ RK_GPIO1 20 RK_FUNC_2
pcfg_pull_none, /* rx_err */
+ RK_GPIO1 21 RK_FUNC_2
pcfg_pull_none, /* crs_dvalid */
+ RK_GPIO1 22 RK_FUNC_2
pcfg_pull_none, /* rxd1 */
+ RK_GPIO1 23 RK_FUNC_2
pcfg_pull_none; /* rxd0 */
+ };
+
+ emac_mdio: emac-mdio {
+ rockchip,pins = RK_GPIO1 24 RK_FUNC_2
pcfg_pull_none, /* mac_md */
+ RK_GPIO1 25 RK_FUNC_2
pcfg_pull_none; /* mac_mdclk */
+ };
+ };
+
emmc {
emmc_clk: emmc-clk {
rockchip,pins = RK_GPIO3 31 RK_FUNC_2
pcfg_pull_default;
@@ -496,3 +514,7 @@
wdt {
compatible = rockchip,rk3066-wdt, snps,dw-wdt;
};
+
+emac {
+ compatible = rockchip,rk3066-emac;
+};
--
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 2/2] ARM: dts: rockchip: Add devicetree source for MarsBoard RK3066
This patch adds initial support for the Marsboard RK3066. It enables
EMAC Rockchip which is the ethernet support on the board and registers
it as a supported rockchip platform.
Signed-off-by: Romain Perier romain.per...@gmail.com
---
Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3066a-marsboard.dts| 197 +
3 files changed, 202 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3066a-marsboard.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 857f126..eaa3d1a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,6 +1,10 @@
Rockchip platforms device tree bindings
---
+- MarsBoard RK3066 board:
+Required root node properties:
+ - compatible = haoyu,marsboard-rk3066, rockchip,rk3066a;
+
- bq Curie 2 tablet:
Required root node properties:
- compatible = mundoreader,bq-curie2, rockchip,rk3066a;
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 472c1c3..513b384 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -365,6 +365,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8960-cdp.dtb \
qcom-msm8974-sony-xperia-honami.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+ rk3066a-marsboard.dtb \
rk3066a-bqcurie2.dtb \
rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
diff --git a/arch/arm/boot/dts/rk3066a-marsboard.dts
b/arch/arm/boot/dts/rk3066a-marsboard.dts
new file mode 100644
index 000..72f498f
--- /dev/null
+++ b/arch/arm/boot/dts/rk3066a-marsboard.dts
@@ -0,0 +1,197 @@
+/*
+ * Copyright (c) 2014 Romain Perier romain.per...@gmail.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include rk3066a.dtsi
+
+/ {
+ model = MarsBoard RK3066;
+ compatible = haoyu,marsboard-rk3066, rockchip,rk3066a;
+
+ memory {
+ reg = 0x6000 0x4000;
+ };
+
+ vcc_sd0: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = sdmmc-supply;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ gpio = gpio3 7 GPIO_ACTIVE_LOW;
+ startup-delay-us = 10;
+ vin-supply = vcc_io;
+ };
+};
+
+i2c1 {
+ status = okay;
+ clock-frequency = 40;
+
+ tps: tps@2d {
+ reg = 0x2d;
+
+ interrupt-parent = gpio6;
+ interrupts = 4 IRQ_TYPE_LEVEL_LOW;
+
+ vcc5-supply = vcc_io;
+ vcc6-supply = vcc_io;
+
+ regulators {
+
[PATCH v3 0/2] ARM: dts: rockchip: EMAC Rockchip for RK3066 SoCs and MarsBoard RK3066
This patches serie adds EMAC Rockchip support for RK3066 SoCs and defines an initial devicetree source for MarsBoard RK3066. changes since v2: - Squashed patch 1,2 and 4 together (this is the the second patch) - Add dual-licensing for rk3066a-marsboard.dts - Renamed regulator vaux33_reg to vcc_rmii as it is written in the schematic changes since v1: - Replaced hoayuelectronics by hoayu as suggested by the vendor-prefix doc in dt-bindings Romain Perier (2): ARM: dts: rockchip: Add EMAC Rockchip for RK3066 SoCs ARM: dts: rockchip: Add devicetree source for MarsBoard RK3066 Documentation/devicetree/bindings/arm/rockchip.txt | 4 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3066a-marsboard.dts| 197 + arch/arm/boot/dts/rk3066a.dtsi | 22 +++ 4 files changed, 224 insertions(+) create mode 100644 arch/arm/boot/dts/rk3066a-marsboard.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] ARM: dts: sbc-t3x: add DVI display data
Add DSS related pinmux and display data nodes required to support
DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
v2: * Make use of OMAP3_WKUP_IOPAD() macro
* Move common DSS pinmux of CM-T3517 and CM-T3530
into omap3-cm-t3x.dtsi.
arch/arm/boot/dts/omap3-cm-t3517.dts | 11 +++
arch/arm/boot/dts/omap3-cm-t3530.dts | 11 +++
arch/arm/boot/dts/omap3-cm-t3730.dts | 24
arch/arm/boot/dts/omap3-cm-t3x.dtsi | 39 ++
arch/arm/boot/dts/omap3-sb-t35.dtsi | 49 +
arch/arm/boot/dts/omap3-sbc-t3517.dts | 14 +
arch/arm/boot/dts/omap3-sbc-t3530.dts | 14 +
arch/arm/boot/dts/omap3-sbc-t3730.dts | 14 +
8 files changed, 176 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-cm-t3517.dts
b/arch/arm/boot/dts/omap3-cm-t3517.dts
index d00502f..0ab748c 100644
--- a/arch/arm/boot/dts/omap3-cm-t3517.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3517.dts
@@ -134,3 +134,14 @@
bus-width = 4;
cap-power-off-card;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins_common
+ dss_dpi_pins_cm_t35x
+ ;
+};
+
diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
b/arch/arm/boot/dts/omap3-cm-t3530.dts
index d145849..8dd14fc 100644
--- a/arch/arm/boot/dts/omap3-cm-t3530.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
@@ -46,3 +46,14 @@
bus-width = 4;
cap-power-off-card;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins_common
+ dss_dpi_pins_cm_t35x
+ ;
+};
+
diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts
b/arch/arm/boot/dts/omap3-cm-t3730.dts
index b3f9a50..46eadb2 100644
--- a/arch/arm/boot/dts/omap3-cm-t3730.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
@@ -31,6 +31,19 @@
};
};
+omap3_pmx_wkup {
+ dss_dpi_pins_cm_t3730: pinmux_dss_dpi_pins_cm_t3730 {
+ pinctrl-single,pins =
+ OMAP3_WKUP_IOPAD(0x2a08, PIN_OUTPUT | MUX_MODE3) /*
sys_boot0.dss_data18 */
+ OMAP3_WKUP_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE3) /*
sys_boot1.dss_data19 */
+ OMAP3_WKUP_IOPAD(0x2a10, PIN_OUTPUT | MUX_MODE3) /*
sys_boot3.dss_data20 */
+ OMAP3_WKUP_IOPAD(0x2a12, PIN_OUTPUT | MUX_MODE3) /*
sys_boot4.dss_data21 */
+ OMAP3_WKUP_IOPAD(0x2a14, PIN_OUTPUT | MUX_MODE3) /*
sys_boot5.dss_data22 */
+ OMAP3_WKUP_IOPAD(0x2a16, PIN_OUTPUT | MUX_MODE3) /*
sys_boot6.dss_data23 */
+ ;
+ };
+};
+
omap3_pmx_core {
mmc2_pins: pinmux_mmc2_pins {
@@ -61,3 +74,14 @@
bus-width = 4;
cap-power-off-card;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins_common
+ dss_dpi_pins_cm_t3730
+ ;
+};
+
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index c671a22..b074673 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -76,6 +76,45 @@
OMAP3_CORE1_IOPAD(0x21e2, PIN_OUTPUT | MUX_MODE4)
/* sys_clkout2.gpio_186 */
;
};
+
+ dss_dpi_pins_common: pinmux_dss_dpi_pins_common {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)
/* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)
/* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)
/* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)
/* dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)
/* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)
/* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)
/* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)
/* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)
/* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)
/* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)
/* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)
/* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)
/* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa,
Re: [PATCH v2] ARM: dts: sbc-t3x: add DVI display data
On 11/02/14 13:19, Dmitry Lifshitz wrote: Add DSS related pinmux and display data nodes required to support DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517. Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. -- 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] ARM: dts: rockchip: add serial aliases for rk3066 and rk3188
Am Donnerstag, 30. Oktober 2014, 16:51:17 schrieb Julien CHAUVEAU: Add aliases for UARTs on rk3066 and rk3188 in order to fix the numbering scheme. This will keep the debug console on ttyS2 when UART 1 is disabled, for example. Signed-off-by: Julien CHAUVEAU julien.chauv...@neo-technologies.fr applied to my dts branch for 3.19 -- 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 0/2] ARM: dts: rockchip: EMAC Rockchip for RK3066 SoCs and MarsBoard RK3066
Am Sonntag, 2. November 2014, 10:19:59 schrieb Romain Perier: This patches serie adds EMAC Rockchip support for RK3066 SoCs and defines an initial devicetree source for MarsBoard RK3066. changes since v2: - Squashed patch 1,2 and 4 together (this is the the second patch) - Add dual-licensing for rk3066a-marsboard.dts - Renamed regulator vaux33_reg to vcc_rmii as it is written in the schematic changes since v1: - Replaced hoayuelectronics by hoayu as suggested by the vendor-prefix doc in dt-bindings Romain Perier (2): ARM: dts: rockchip: Add EMAC Rockchip for RK3066 SoCs ARM: dts: rockchip: Add devicetree source for MarsBoard RK3066 applied to my dts branch for 3.19, with two small changes: - remove FSF address in license header, per checkpatch warning [I guess the sunxi header I copied it from also contained the address] - rename vcc_sd0: fixed-regulator to vcc_sd0: sdmmc-regulator to prevent future naming conflicts with more fixed regulators -- 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 0/6] add basic rk3288 smp support
Am Mittwoch, 15. Oktober 2014, 10:22:59 schrieb Kever Yang: rk3288 is qual-core CPU Soc, we enable the smp in this patch. applied this series with Kevin's test-tag split to dts and soc branches for 3.19. -- 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: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hi, On 10/31/2014 09:47 PM, Rob Herring wrote: On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Hans, Rob, On 28/10/14 13:30, Hans de Goede wrote: Hi, On 10/28/2014 12:11 PM, Rob Herring wrote: Yes, I object to the binding still as it has not changed from what was previously posted. It would be helpful if you could explain why you object. Last time you said: You are mixing in a hardware description that is simply inaccurate. I then explained that this is not hardware description, but runtime state information, as it tells the kernel which clocks were chosen to drive the display (out of typically a list of possible options, depending on which output is used, etc.). Just like which memory address the bootloader has chosen to scan out the video image from. Then you got quiet, so sorry, but this time your objection really is too late. You cannot simply go quiet halfway through a discussion and then pop up again when a new version is posted to say I object yet another time, you've had your chance to make your arguments last time, and chose to stay quiet after I explained in detail that this is not hardware description but state information, so now it is simply too late. These bindings have been discussed at Plumbers with various interested people present, and the conclusion was that this really is the best way to handle this, so this patch is: Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Mike Turquette mturque...@linaro.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Reviewed-by: Maxime Ripard maxime.rip...@free-electrons.com And David Herrman who is working on simpledrm, which will be merged soon, which will also use the simplefb bindings also agrees. So we have the simplefb maintainer, simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all agreeing on a way forward, the time for bikeshedding now really really really is over. Tomi, can you please let us know how you plan to proceed with this ? I won't merge DT bindings via fbdev tree, if a DT maintainer says no. I took Rob's silence to the earlier series as a silent ack for your explanation. Obviously that was not the case. Rob, please advice asap what should be done to the bindings to get your ack. As Hans explained above, this discussion has been going on for a long time, and afaik this series is the best way forward of all the options discussed. I still think for the most part this is a kernel problem. It is a kernel policy to turn off unused clocks. The clock framework could just as easily decide that any clocks enabled at boot and left un-managed (i.e. w/o a driver) are kept on until they are managed. This is not just about being unmanaged, clocks can be shared, and another driver can actively claim the clock and turn it off, we need to protect against this too. I'm not saying this can't be in DT, only that DT is not the only solution here. Basically the problem is that we must keep the clock enabled for the lifetime of the simplefb device. We've been over this in 2 very long threads already, and many alternatives have been evaluated and found wanting. The only 100% safe way to ensure clocks are not turned off is to tie there lifetime to that of the simplefb device, and the only reliable way to do that is through a clocks property. It really is that simple, and I don't understand why people keep insisting there must be another way, while they fail to offer a (reliable, working) other way. This problem is not unique to simplefb. A serial console could stop working if no serial driver is loaded before unused clocks are disabled. CPU core clocks have a similar issue as well (often enabled in platform code). I want to see this solved in a generic way for any clock. As regulators were also mentioned, they already have a regulator-boot-on property defined. Perhaps this is suitable to be mirrored for clocks. If it is not, then I'm wondering why we have it. A key difference here is that the property is part of the provider and can be dealt with in the clock driver rather than requiring a temporary driver. regulator-boot-on tells the regulator framework to enable a regulator at boot, but it does not protect it from getting turned of by another driver later (it does not increase use_count). So this is the same none solution as not turning off unmanaged clocks, what if another driver who shares the clock, enables it during probe, then disables it while done probing (to put things in low power state until userspace uses the device). This is not about not turning the clock off, this is about keeping the clock on for the lifetime of the simplefb device, which is a different problem, cause we must not remove a single calling point of clock_off, put we must block all attempts to turn the clock off, which is done by increasing its use-count, which is done by claiming + enabling it,
[PATCH v2 00/13] Xilinx Video IP Core support
Hello, Here's the second version of the Xilinx FPGA Video IP Cores kernel drivers. I won't detail in great lengths the Xilinx Video IP architecture here, as that would result in dozens of pages of documentation. The interested reader can refer to the Zynq ZC702 Base TRD (Targeted Reference Design) User Guide (http://www.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/2014_2/ug925-zynq-zc702-base-trd.pdf). In a nutshell, the Xilinx Video IP Cores architecture specifies how video-related IP cores need to be designed to interoperate and how to assemble them in pipelines of various complexities. The concepts map neatly to the media controller architecture, which this patch set uses extensively. The series starts with various new V4L2 core features, bug fixes or cleanups, with a small documentation enhancement (01/13), the addition of new media bus formats needed by the new drivers (02/13 to 04/13) and a new V4L2 OF link parsing function (05/13). The next two patches (06/13 and 07/13) fix two race conditions in videobuf2. They could be applied seperately from this series as they're not specific to Xilinx drivers. The next three patches (08/13 to 10/13) fix bugs in the Xilinx Video DMA driver. They are required as a runtime dependency but will not break compilation. I will submit a separate pull request for them through the DMA engine tree. The last three patches are the core of this series. Patch 11/13 adds support for the Xilinx Video IP architecture core in the form of a base object to model video IP cores (xilinx-vip.c - Video IP), a framework that parses a DT representation of a video pipeline and connects the corresponding V4L2 subdevices together (xilinx-vipp.c - Video IP Pipeline) and a glue between the Video DMA engine driver and the V4L2 API (xilinx-dma.c). Patch 12/13 adds a driver for the Video Timing Controller (VTC) IP core. While not strictly a video processing IP core, the VTC is required by other video IP core drivers. Finally, patch 13/13 adds a first video IP core driver for the Test Pattern Generator (TPG). Drivers for other IP cores will be added in the future. Cc: devicetree@vger.kernel.org Hyun Kwon (2): v4l: Sort YUV formats of v4l2_mbus_pixelcode v4l: Add VUY8 24 bits bus format Laurent Pinchart (8): media: entity: Document the media_entity_ops structure v4l: Add RBG and RGB 8:8:8 media bus formats on 24 and 32 bit busses v4l: of: Add v4l2_of_parse_link() function v4l: vb2: Fix race condition in vb2_fop_poll v4l: vb2: Fix race condition in _vb2_fop_release v4l: xilinx: Add Xilinx Video IP core v4l: xilinx: Add Video Timing Controller driver v4l: xilinx: Add Test Pattern Generator driver Srikanth Thokala (3): dma: xilinx: vdma: Check if the segment list is empty in a descriptor dma: xilinx: vdma: Allow only one chunk in a line dma: xilinx: vdma: icg should be difference of stride and hsize Documentation/DocBook/media/v4l/subdev-formats.xml | 719 +--- .../devicetree/bindings/media/xilinx/video.txt | 52 ++ .../devicetree/bindings/media/xilinx/xlnx,v-tc.txt | 33 + .../bindings/media/xilinx/xlnx,v-tpg.txt | 68 ++ .../bindings/media/xilinx/xlnx,video.txt | 55 ++ MAINTAINERS| 10 + drivers/dma/xilinx/xilinx_vdma.c | 13 +- drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/xilinx/Kconfig | 23 + drivers/media/platform/xilinx/Makefile | 5 + drivers/media/platform/xilinx/xilinx-dma.c | 770 + drivers/media/platform/xilinx/xilinx-dma.h | 109 +++ drivers/media/platform/xilinx/xilinx-tpg.c | 921 + drivers/media/platform/xilinx/xilinx-vip.c | 269 ++ drivers/media/platform/xilinx/xilinx-vip.h | 227 + drivers/media/platform/xilinx/xilinx-vipp.c| 669 +++ drivers/media/platform/xilinx/xilinx-vipp.h| 49 ++ drivers/media/platform/xilinx/xilinx-vtc.c | 386 + drivers/media/platform/xilinx/xilinx-vtc.h | 42 + drivers/media/v4l2-core/v4l2-of.c | 61 ++ drivers/media/v4l2-core/videobuf2-core.c | 35 +- include/media/media-entity.h | 9 + include/media/v4l2-of.h| 27 + include/uapi/linux/Kbuild | 1 + include/uapi/linux/v4l2-mediabus.h | 19 +- include/uapi/linux/xilinx-v4l2-controls.h | 73 ++ 27 files changed, 4302 insertions(+), 346 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/xilinx/video.txt create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt create mode 100644
[PATCH v2 12/13] v4l: xilinx: Add Video Timing Controller driver
The Video Timing Controller (VTC) includes a timing detector and/or a
timing generator. Only the generator is currently supported.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Cc: devicetree@vger.kernel.org
.../devicetree/bindings/media/xilinx/xlnx,v-tc.txt | 33 ++
drivers/media/platform/xilinx/Kconfig | 6 +
drivers/media/platform/xilinx/Makefile | 1 +
drivers/media/platform/xilinx/xilinx-vtc.c | 386 +
drivers/media/platform/xilinx/xilinx-vtc.h | 42 +++
5 files changed, 468 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
create mode 100644 drivers/media/platform/xilinx/xilinx-vtc.c
create mode 100644 drivers/media/platform/xilinx/xilinx-vtc.h
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
new file mode 100644
index 000..2aed3b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
@@ -0,0 +1,33 @@
+Xilinx Video Timing Controller (VTC)
+
+
+The Video Timing Controller is a general purpose video timing generator and
+detector.
+
+Required properties:
+
+ - compatible: Must be xlnx,v-tc-6.1.
+
+ - reg: Physical base address and length of the registers set for the device.
+
+ - clocks: Must contain a clock specifier for the VTC core and timing
+interfaces clock.
+
+Optional properties:
+
+ - xlnx,detector: The VTC has a timing detector
+ - xlnx,generator: The VTC has a timing generator
+
+ At least one of the xlnx,detector and xlnx,generator properties must be
+ specified.
+
+
+Example:
+
+ vtc: vtc@43c4 {
+ compatible = xlnx,v-tc-6.1;
+ reg = 0x43c4 0x1;
+
+ clocks = clkc 15;
+ xlnx,generator;
+ };
diff --git a/drivers/media/platform/xilinx/Kconfig
b/drivers/media/platform/xilinx/Kconfig
index f4347e9..19db823 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -7,4 +7,10 @@ config VIDEO_XILINX
if VIDEO_XILINX
+config VIDEO_XILINX_VTC
+ tristate Xilinx Video Timing Controller
+ depends on VIDEO_XILINX
+ ---help---
+ Driver for the Xilinx Video Timing Controller
+
endif #VIDEO_XILINX
diff --git a/drivers/media/platform/xilinx/Makefile
b/drivers/media/platform/xilinx/Makefile
index 3ef9c8e..6611e32 100644
--- a/drivers/media/platform/xilinx/Makefile
+++ b/drivers/media/platform/xilinx/Makefile
@@ -1,3 +1,4 @@
xilinx-video-objs += xilinx-dma.o xilinx-vip.o xilinx-vipp.o
obj-$(CONFIG_VIDEO_XILINX) += xilinx-video.o
+obj-$(CONFIG_VIDEO_XILINX_VTC) += xilinx-vtc.o
diff --git a/drivers/media/platform/xilinx/xilinx-vtc.c
b/drivers/media/platform/xilinx/xilinx-vtc.c
new file mode 100644
index 000..949063a
--- /dev/null
+++ b/drivers/media/platform/xilinx/xilinx-vtc.c
@@ -0,0 +1,386 @@
+/*
+ * Xilinx Video Timing Controller
+ *
+ * Copyright (C) 2013-2014 Ideas on Board
+ * Copyright (C) 2013-2014 Xilinx, Inc.
+ *
+ * Contacts: Hyun Kwon hyun.k...@xilinx.com
+ * Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include xilinx-vip.h
+#include xilinx-vtc.h
+
+#define XVTC_CONTROL_FIELD_ID_POL_SRC (1 26)
+#define XVTC_CONTROL_ACTIVE_CHROMA_POL_SRC (1 25)
+#define XVTC_CONTROL_ACTIVE_VIDEO_POL_SRC (1 24)
+#define XVTC_CONTROL_HSYNC_POL_SRC (1 23)
+#define XVTC_CONTROL_VSYNC_POL_SRC (1 22)
+#define XVTC_CONTROL_HBLANK_POL_SRC(1 21)
+#define XVTC_CONTROL_VBLANK_POL_SRC(1 20)
+#define XVTC_CONTROL_CHROMA_SRC(1 18)
+#define XVTC_CONTROL_VBLANK_HOFF_SRC (1 17)
+#define XVTC_CONTROL_VSYNC_END_SRC (1 16)
+#define XVTC_CONTROL_VSYNC_START_SRC (1 15)
+#define XVTC_CONTROL_ACTIVE_VSIZE_SRC (1 14)
+#define XVTC_CONTROL_FRAME_VSIZE_SRC (1 13)
+#define XVTC_CONTROL_HSYNC_END_SRC (1 11)
+#define XVTC_CONTROL_HSYNC_START_SRC (1 10)
+#define XVTC_CONTROL_ACTIVE_HSIZE_SRC (1 9)
+#define XVTC_CONTROL_FRAME_HSIZE_SRC (1 8)
+#define XVTC_CONTROL_SYNC_ENABLE (1 5)
+#define XVTC_CONTROL_DET_ENABLE(1 3)
+#define XVTC_CONTROL_GEN_ENABLE(1 2)
+
+#define XVTC_STATUS_FSYNC(n) ((n) 16)
+#define XVTC_STATUS_GEN_ACTIVE_VIDEO (1 13)
+#define XVTC_STATUS_GEN_VBLANK (1 12)
+#define
[PATCH v2 13/13] v4l: xilinx: Add Test Pattern Generator driver
The TPG generates multiple static or dynamic test patterns. The driver
currently hardcodes the pattern to the moving box pattern.
Signed-off-by: Christian Kohn christian.k...@xilinx.com
Signed-off-by: Hyun Kwon hyun.k...@xilinx.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Cc: devicetree@vger.kernel.org
I'd appreciate if DT reviewers could have a look at the xlnx,video-format and
xlnx,video-width properties if nothing else.
Changes since v1:
v4l: xilinx: tpg: Fix typo
v1 was made of the following individual patches.
media: xilinx: tpg: Add the version number in DT compatible string
media: xilinx: tpg: Use linux/device.h instead of linux/slab.h
media: xilinx: tpg: Reset in probe()
media: xilinx: tpg: Add controls for TPG
media: xilinx: tpg: Add the default format
media: xilinx: tpg: Fix alignments around __xtpg_get_pad_format()
media: xilinx: tpg: Change 'format' to 'fmt'
media: xilinx: tpg: Fix alignments
media: xilinx: tpg: Fix the structure comment
media: xilinx: tpg: Use xvip_enum_mbus_code()
media: xilinx: tpg: Use xvip_enum_frame_size()
media: xilinx: tpg: Use xvip_set_format_size()
media: xilinx: tpg: Use xvip_start()
media: xilinx: tpg: Use xvip_stop()
media: xilinx: tpg: Use xvip_set_frame_size()
media: xilinx: tpg: Use xvip_print_version()
media: xilinx: tpg: Add power management functions
media: xilinx: tpg: Remove of_match_ptr()
media: xilinx: tpg: Fix devm_ioremap_resource() return value check
media: xilinx: tpg: Make number of pads dynamic
media: xilinx: tpg: Configure the bayer phase
media: xilinx: tpg: Allocate active formats for each pad
media: xilinx: tpg: Include the format infomation in 'port' node
media: xilinx: tpg: Add VTC support
media: xilinx: tpg: Add video timing mux support
media: xilinx: tpg: Default to the color bars test pattern
media: xilinx: tpg: Disallow switching passthrough mode during streaming
media: xilinx: tpg: Move control IDs to xilinx-controls.h
media: xilinx: tpg: Make horizontal and vertical blanking configurable
media: xilinx: tpg: Ignore unconnected input ports
xilinx: Remove .owner field for drivers
v4l: xilinx: tpg: Rename compatible string to xlnx,v-tpg
v4l: xilinx: tpg: Lock the control handler when modifying control range
v4l: xilinx: tpg: Use devm_gpiod_get_optional
v4l: xilinx: tpg: Remove axi- prefix from DT properties
---
.../bindings/media/xilinx/xlnx,v-tpg.txt | 68 ++
MAINTAINERS| 1 +
drivers/media/platform/xilinx/Kconfig | 7 +
drivers/media/platform/xilinx/Makefile | 1 +
drivers/media/platform/xilinx/xilinx-tpg.c | 921 +
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/xilinx-v4l2-controls.h | 73 ++
7 files changed, 1072 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
create mode 100644 drivers/media/platform/xilinx/xilinx-tpg.c
create mode 100644 include/uapi/linux/xilinx-v4l2-controls.h
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
new file mode 100644
index 000..c6de1e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
@@ -0,0 +1,68 @@
+Xilinx Video Test Pattern Generator (TPG)
+-
+
+Required properties:
+
+- compatible: Must contain at least one of
+
+xlnx,v-tpg-5.0 (TPG version 5.0)
+xlnx,v-tpg-6.0 (TPG version 6.0)
+
+ TPG versions backward-compatible with previous versions should list all
+ compatible versions in the newer to older order.
+
+- reg: Physical base address and length of the registers set for the device.
+
+- xlnx,video-format, xlnx,video-width: Video format and width, as defined in
+ video.txt.
+
+- port: Video port, using the DT bindings defined in ../video-interfaces.txt.
+ The TPG has a single output port numbered 0.
+
+Optional properties:
+
+- xlnx,vtc: A phandle referencing the Video Timing Controller that generates
+ video timings for the TPG test patterns.
+
+- timing-gpios: Specifier for a GPIO that controls the timing mux at the TPG
+ input. The GPIO active level corresponds to the selection of VTC-generated
+ video timings.
+
+The xlnx,vtc and timing-gpios properties are mandatory when the TPG is
+synthesized with two ports and forbidden when synthesized with one port.
+
+Example:
+
+ tpg_0: tpg@4005 {
+ compatible = xlnx,v-tpg-6.0, xlnx,v-tpg-5.0;
+ reg = 0x4005 0x1;
+
+ xlnx,vtc = vtc_3;
+ timing-gpios = ps7_gpio_0 55 GPIO_ACTIVE_LOW;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ xlnx,video-format
[PATCH v2 11/13] v4l: xilinx: Add Xilinx Video IP core
Xilinx platforms have no hardwired video capture or video processing interface. Users create capture and memory to memory processing pipelines in the FPGA fabric to suit their particular needs, by instantiating video IP cores from a large library. The Xilinx Video IP core is a framework that models a video pipeline described in the device tree and expose the pipeline to userspace through the media controller and V4L2 APIs. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Hyun Kwon hyun.k...@xilinx.com Signed-off-by: Radhey Shyam Pandey radh...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- Cc: devicetree@vger.kernel.org Changes since v1: - Remove unnecessary fields from struct xvip_dma_buffer - Fix querycap capabilities and bus_info reporting - Refuse to set format when the queue is busy - Return buffers to vb2 when start_streaming fails - Use vb2 fops and ioctl ops v1 was made of the following individual patches. media: xilinx: vip: Add yuv444 and bayer formats media: xilinx: vip: Remove _TIMING_ from register definition media: xilinx: dma: Add vidioc_enum_fmt_vid_cap callback media: xilinx: dma: Fix alignments of xvip_dma_fops definition media: xilinx: dma: Workaround for bytesperline media: xilinx: vip: Add default min/max height/width definitions media: xilinx: vip: Add common sink/source pad IDs media: xilinx: vip: Add xvip_set_format_size() media: xilinx: vip: Add xvip_enum_mbus_code() media: xilinx: vip: Add xvip_enum_frame_size() media: xilinx: vip: Add register clear and set functions media: xilinx: vip: Add xvip_start() media: xilinx: vip: Add xvip_stop() media: xilinx: vip: Add xvip_set_frame_size() media: xilinx: vip: Add enable/disable reg update functions media: xilinx: vip: Add xvip_print_version() media: xilinx: vip: Add xvip_reset() media: xilinx: vip: Add xvip_get_frame_size() media: xilinx: vip: Add suspend/resume helper functions media: xilinx: vip: Change the return value of xvip_get_format_by_code() media: xilinx: vip: Change the return value of xvip_of_get_format() media: xilinx: vip: Change the return value of xvip_get_format_by_fourcc() media: xilinx: vipp: Remove of_match_ptr() media: xilinx: vipp: Add control to inherit subdevice controls media: xilinx: Make disconnected video nodes return -EPIPE at stream on media: xilinx: Make links configurable media: xilinx: Rename xvip_pipeline_entity to xvip_graph_entity media: xilinx: Rename xvip_pipeline to xvip_composite_device media: xilinx: Rename xvipp_pipeline_* functions to xvip_graph_* media: xilinx: Rename xvipp_v4l2_* functions to xvip_composite_v4l2_* media: xilinx: Rename xvipp_* functions to xvip_composite_* media: xilinx: Move pipeline management code to xilinx-dma.c media: xilinx: Add missing mutex_destroy call media: xilinx: Create xvip_pipeline structure media: xilinx: Support more than two VDMAs in DT media: xilinx: dma: Change vdma configuration to cyclic-mode Revert media: xilinx: dma: Workaround for bytesperline media: xilinx: Added DMA error handling media: xilinx: Fix error handling media: xilinx: Reordered mutexes initialization media: xilinx: vipp: Add devicetree bindings documentation media: xilinx: Reordered mutexes initialization media: xilinx: Set format description in enum_fmt media: xilinx: Remove global control handler media: xilinx: dma: Use the interleaved dmaengine API xilinx: Remove .owner field for drivers v4l: xilinx: video: Rename compatible string to xlnx,video v4l: xilinx: Remove axi- prefix from DT properties v4l: xilinx: dma: Give back queued buffers at streamoff time --- .../devicetree/bindings/media/xilinx/video.txt | 52 ++ .../bindings/media/xilinx/xlnx,video.txt | 55 ++ MAINTAINERS| 9 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/xilinx/Kconfig | 10 + drivers/media/platform/xilinx/Makefile | 3 + drivers/media/platform/xilinx/xilinx-dma.c | 770 + drivers/media/platform/xilinx/xilinx-dma.h | 109 +++ drivers/media/platform/xilinx/xilinx-vip.c | 269 +++ drivers/media/platform/xilinx/xilinx-vip.h | 227 ++ drivers/media/platform/xilinx/xilinx-vipp.c| 669 ++ drivers/media/platform/xilinx/xilinx-vipp.h| 49 ++ 13 files changed, 2225 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/xilinx/video.txt create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt create mode 100644 drivers/media/platform/xilinx/Kconfig create mode 100644 drivers/media/platform/xilinx/Makefile create mode 100644 drivers/media/platform/xilinx/xilinx-dma.c create mode 100644 drivers/media/platform/xilinx/xilinx-dma.h create mode 100644 drivers/media/platform/xilinx/xilinx-vip.c create mode 100644
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Fri, Oct 31, 2014 at 4:47 PM, Rob Herring robherri...@gmail.com wrote: On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Hans, Rob, On 28/10/14 13:30, Hans de Goede wrote: Hi, On 10/28/2014 12:11 PM, Rob Herring wrote: Yes, I object to the binding still as it has not changed from what was previously posted. It would be helpful if you could explain why you object. Last time you said: You are mixing in a hardware description that is simply inaccurate. I then explained that this is not hardware description, but runtime state information, as it tells the kernel which clocks were chosen to drive the display (out of typically a list of possible options, depending on which output is used, etc.). Just like which memory address the bootloader has chosen to scan out the video image from. Then you got quiet, so sorry, but this time your objection really is too late. You cannot simply go quiet halfway through a discussion and then pop up again when a new version is posted to say I object yet another time, you've had your chance to make your arguments last time, and chose to stay quiet after I explained in detail that this is not hardware description but state information, so now it is simply too late. These bindings have been discussed at Plumbers with various interested people present, and the conclusion was that this really is the best way to handle this, so this patch is: Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Mike Turquette mturque...@linaro.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Reviewed-by: Maxime Ripard maxime.rip...@free-electrons.com And David Herrman who is working on simpledrm, which will be merged soon, which will also use the simplefb bindings also agrees. So we have the simplefb maintainer, simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all agreeing on a way forward, the time for bikeshedding now really really really is over. Tomi, can you please let us know how you plan to proceed with this ? I won't merge DT bindings via fbdev tree, if a DT maintainer says no. I took Rob's silence to the earlier series as a silent ack for your explanation. Obviously that was not the case. Rob, please advice asap what should be done to the bindings to get your ack. As Hans explained above, this discussion has been going on for a long time, and afaik this series is the best way forward of all the options discussed. I still think for the most part this is a kernel problem. It is a kernel policy to turn off unused clocks. The clock framework could just as easily decide that any clocks enabled at boot and left un-managed (i.e. w/o a driver) are kept on until they are managed. I'm not saying this can't be in DT, only that DT is not the only solution here. This problem is not unique to simplefb. A serial console could stop working if no serial driver is loaded before unused clocks are disabled. CPU core clocks have a similar issue as well (often enabled in platform code). I want to see this solved in a generic way for any clock. I am in agreement this point of view. This is a problem in the Linux kernel. It is not a generic problem. The Linux problem is that during boot device drivers are loaded in two phases - built-in and loadable modules. The clock-regulator clean up is happening too early. It happens after the built-in drivers load and before the loadable modules have a chance to load. That's simply the wrong place for that clean up happen. A simple alternative would be to make a tiny loadable module that triggers the clean up. Then adjust your boot scripts to load this module after the other ones have loaded. But instead of fixing this simple timing flaw in the Linux boot process a complex mechanism is being created to work around it. Simplefb is also being developed as a way of protecting the BIOS setup of the framebuffer past the boot process and out into use as a normal user space console. I in no way support this use. We have experienced decades of problems on the x86 with VGA and BIOSes that I do not wish to repeat in the ARM world. Write a correct, device specific framebuffer driver for this piece of hardware. That device specific driver will load before the clock/regulator cleanup and claim all of the correct resources. As regulators were also mentioned, they already have a regulator-boot-on property defined. Perhaps this is suitable to be mirrored for clocks. If it is not, then I'm wondering why we have it. A key difference here is that the property is part of the provider and can be dealt with in the clock driver rather than requiring a temporary driver. Rob -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to
[PATCH v1 1/3] usb: phy: device-tree documentation for gpio-vbus
Add documentation for device-tree binding of the generic gpio-vbus phy
controller.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/phy/gpio-vbus.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/gpio-vbus.txt
diff --git a/Documentation/devicetree/bindings/phy/gpio-vbus.txt
b/Documentation/devicetree/bindings/phy/gpio-vbus.txt
new file mode 100644
index 000..ffcfd35
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/gpio-vbus.txt
@@ -0,0 +1,23 @@
+GPIO VBus phy
+=
+
+gpio-vbus is a phy controller supporting VBus detection and pullup activation
on
+GPIOs.
+
+Required properties:
+- compatible : should be generic,phy-gpio-vbus
+- #phy-cells : from the generic PHY bindings, must be 1.
+- gpios : set of 2 gpio properties (see gpio.txt for gpio properties
format)
+ first gpio is required, it's the VBus sensing input gpio
+ second gpio is optional, it's the D+ pullup controlling output
+ gpio
+
+Optional properties:
+- wakeup : boolean, if true the VBus gpio will wakeup the platform
+
+Example:
+ usb2phy : gpio-vbus@13 {
+ compatible = generic,phy-gpio-vbus;
+ gpios = gpio 13 GPIO_ACTIVE_LOW;
+ wakeup;
+ };
--
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 0/8] Armada XP pinctrl consolidation and ix4-300d fixes
On 02.11.2014 20:03, Jason Cooper wrote:
On Sat, Nov 01, 2014 at 11:48:33PM +0100, Sebastian Hesselbarth wrote:
On 01.11.2014 23:36, Jason Cooper wrote:
On Fri, Sep 19, 2014 at 10:14:36PM +0200, Sebastian Hesselbarth wrote:
this is a patch set preparing barebox support for ix4-300d. As usual,
I stumbled upon a few nice-to-haves before actually touching ix4-300d
dts. As it is a mach-mvebu thing, I just added the related mailing
lists instead of each of the DT maintainers.
First 5 patches consolidate SoC-specific pinctrl nodes to one common
node in armada-xp.dtsi, compatible overwrites for each SoC, and node
alias usage for each board. Also, ge{0,1} pinctrl settings are moved
to the common node from one board specific node.
Last 3 patches then use that ge{0,1} pinctrl settings on ix4-300d which
is vital for bootloader init. During exploration of ix4-300d, I also
found a i2c eeprom that has not been added to the dts, yet. Finally,
there is only one 74hc595 on ix4 mainboard while dts property is set
for two.
I cannot recall in detail what is on that eeprom, but IIRC it is nothing
important. Some reg,addr pairs for some init stuff that should have
already been done by stock u-boot. Anyway, adding the node will do no
harm.
Patches are based on v3.17-rc1 and intended for v3.18 but I am not in
a hurry. I only compile tested this, so a formal Tested-by from Benoit
for the ix4 and any other Armada XP board would be great.
I lost track of this thread, are you resending? Did Benoit get a
successful test run?
Looks like there was this A0 stepping thing, but basically yes
http://www.spinics.net/lists/devicetree/msg53364.html
I have just rebased it on top of v3.18-rc1, feel free to pick them
up from
git://git.infradead.org/users/hesselba/linux-berlin.git devel/mvebu/ix4-300d
git://git.infradead.org/users/hesselba/linux-berlin.git
Ahh, that's right. Do you still use the github repo? I hadn't added
your infradead as a remote yet.
Usually, I use github for mvebu and infradead for berlin. But this time
I was too lazy to either boot-up the other laptop or clone the github
repo ;)
At any rate, I cherry-picked them and added Benoit's Tested-by's. So if
you had this branch in -next, please remove it before tonight's run.
I _did not_ put it into any -next branch. It's mvebu and that is your
git tree, I only put berlin patches into -next ;)
Applied to mvebu/dt.
Thanks for having an eye on this patches, I almost forgot about them.
Sebastian
--
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 RESEND v2 1/4] ARM: dts: vf610: assign oscillator to clock module
The clock controller module (CCM) has several clock inputs, which
are connected to external crystal oscillators. To reflect this,
assign these fixed clocks to the CCM node directly.
This especially resolves initialization order dependencies we had
with the earlier initialization code: When resolving of the fixed
clocks failed in clk-vf610, the code created fixed clocks with a
rate of 0.
Signed-off-by: Stefan Agner ste...@agner.ch
---
.../devicetree/bindings/clock/vf610-clock.txt | 15 +
arch/arm/boot/dts/vf610-cosmic.dts | 14 ++--
arch/arm/boot/dts/vf610-twr.dts| 25 --
arch/arm/boot/dts/vf610.dtsi | 25 ++
4 files changed, 48 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt
b/Documentation/devicetree/bindings/clock/vf610-clock.txt
index c80863d..63f9f1a 100644
--- a/Documentation/devicetree/bindings/clock/vf610-clock.txt
+++ b/Documentation/devicetree/bindings/clock/vf610-clock.txt
@@ -5,6 +5,19 @@ Required properties:
- reg: Address and length of the register set
- #clock-cells: Should be 1
+Optional properties:
+- clocks: list of clock identifiers which are external input clocks to the
+ given clock controller. Please refer the next section to find
+ the input clocks for a given controller.
+- clock-names: list of names of clocks which are exteral input clocks to the
+ given clock controller.
+
+Input clocks for top clock controller:
+ - sxosc (external crystal oscillator 32KHz, recommended)
+ - fxosc (external crystal oscillator 24MHz, recommended)
+ - audio_ext
+ - enet_ext
+
The clock consumer should specify the desired clock by having the clock
ID in its clocks phandle cell. See include/dt-bindings/clock/vf610-clock.h
for the full list of VF610 clock IDs.
@@ -15,6 +28,8 @@ clks: ccm@4006b000 {
compatible = fsl,vf610-ccm;
reg = 0x4006b000 0x1000;
#clock-cells = 1;
+ clocks = sxosc, fxosc;
+ clock-names = sxosc, fxosc;
};
uart1: serial@40028000 {
diff --git a/arch/arm/boot/dts/vf610-cosmic.dts
b/arch/arm/boot/dts/vf610-cosmic.dts
index 3fd1b74..b0ce8b8 100644
--- a/arch/arm/boot/dts/vf610-cosmic.dts
+++ b/arch/arm/boot/dts/vf610-cosmic.dts
@@ -23,14 +23,16 @@
reg = 0x8000 0x1000;
};
- clocks {
- enet_ext {
- compatible = fixed-clock;
- #clock-cells = 0;
- clock-frequency = 5000;
- };
+ enet_ext: enet_ext {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 5000;
};
+};
+clks {
+ clocks = sxosc, fxosc, enet_ext;
+ clock-names = sxosc, fxosc, enet_ext;
};
fec1 {
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 189b697..7d06d1a 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -22,18 +22,16 @@
reg = 0x8000 0x800;
};
- clocks {
- audio_ext {
- compatible = fixed-clock;
- #clock-cells = 0;
- clock-frequency = 24576000;
- };
+ audio_ext: mclk_osc {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 24576000;
+ };
- enet_ext {
- compatible = fixed-clock;
- #clock-cells = 0;
- clock-frequency = 5000;
- };
+ enet_ext: eth_osc {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 5000;
};
regulators {
@@ -95,6 +93,11 @@
status = okay;
};
+clks {
+ clocks = sxosc, fxosc, enet_ext, audio_ext;
+ clock-names = sxosc, fxosc, enet_ext, audio_ext;
+};
+
dspi0 {
bus-num = 0;
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 699da48..ed12d9a 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -44,21 +44,16 @@
};
};
- clocks {
- #address-cells = 1;
- #size-cells = 0;
-
- sxosc {
- compatible = fixed-clock;
- #clock-cells = 0;
- clock-frequency = 32768;
- };
+ fxosc: fxosc {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 2400;
+ };
- fxosc {
- compatible = fixed-clock;
- #clock-cells = 0;
- clock-frequency = 2400;
- };
+
[PATCH RESEND v2 2/4] ARM: imx: clk-vf610: get input clocks from assigned clocks
With the clock assignment device tree changes, the clocks get
initialized properly but the search for those clocks fails with
errors:
[0.00] i.MX clk 4: register failed with -17
[0.00] i.MX clk 5: register failed with -17
This is because the module can't find those clocks anymore, and
tries to initialize fixed clocks with the same name.
Get the clock modules input clocks from the assigned clocks by
default by using of_clk_get_by_name(). If this function returns
not a valid clock, fall back to the old behaviour and search the
input clock from the device tree's /clocks/$name node.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/mach-imx/clk-vf610.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c
index a178184..1963a44 100644
--- a/arch/arm/mach-imx/clk-vf610.c
+++ b/arch/arm/mach-imx/clk-vf610.c
@@ -105,6 +105,17 @@ static unsigned int const clks_init_on[] __initconst = {
VF610_CLK_DDR_SEL,
};
+static struct clk * __init vf610_get_fixed_clock(
+ struct device_node *ccm_node, const char *name)
+{
+ struct clk *clk = of_clk_get_by_name(ccm_node, name);
+
+ /* Backward compatibility if device tree is missing clks assignments */
+ if (IS_ERR(clk))
+ clk = imx_obtain_fixed_clock(name, 0);
+ return clk;
+};
+
static void __init vf610_clocks_init(struct device_node *ccm_node)
{
struct device_node *np;
@@ -115,11 +126,10 @@ static void __init vf610_clocks_init(struct device_node
*ccm_node)
clk[VF610_CLK_SIRC_32K] = imx_clk_fixed(sirc_32k, 32000);
clk[VF610_CLK_FIRC] = imx_clk_fixed(firc, 2400);
- clk[VF610_CLK_SXOSC] = imx_obtain_fixed_clock(sxosc, 0);
- clk[VF610_CLK_FXOSC] = imx_obtain_fixed_clock(fxosc, 0);
- clk[VF610_CLK_AUDIO_EXT] = imx_obtain_fixed_clock(audio_ext, 0);
- clk[VF610_CLK_ENET_EXT] = imx_obtain_fixed_clock(enet_ext, 0);
-
+ clk[VF610_CLK_SXOSC] = vf610_get_fixed_clock(ccm_node, sxosc);
+ clk[VF610_CLK_FXOSC] = vf610_get_fixed_clock(ccm_node, fxosc);
+ clk[VF610_CLK_AUDIO_EXT] = vf610_get_fixed_clock(ccm_node, audio_ext);
+ clk[VF610_CLK_ENET_EXT] = vf610_get_fixed_clock(ccm_node, enet_ext);
clk[VF610_CLK_FXOSC_HALF] = imx_clk_fixed_factor(fxosc_half, fxosc,
1, 2);
np = of_find_compatible_node(NULL, NULL, fsl,vf610-anatop);
--
2.1.3
--
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 RESEND v2 3/4] ARM: dts: vf610: create generic base device trees
This adds more generic base device trees for Vybrid SoCs. There
are three series of Vybrid SoC commonly available:
- VF3xx series: single core, Cortex-A5 without external memory
- VF5xx series: single core, Cortex-A5
- VF6xx series: dual core, Cortex-A5/Cortex-M4
The second digit represents the presents of a L2 cache (VFx1x).
The VF3xx series are not suitable for Linux especially since the
internal memory is quite small (1.5MiB).
The VF500 is essentially the base SoC, with only one core and
without L1 cache. The VF610 is a superset of the VF500, hence
vf500.dtsi is then included and enhanced by vf610.dtsi. There is
no board using VF510 or VF600 currently, but, if needed, they can
be added easily.
The Linux kernel can also run on the Cortex-M4 CPU of Vybrid
using !MMU support. This patchset creates a device tree structure
which allows to share peripherals nodes for a VF6xx Cortex-M4
device tree too. The two CPU types have different views of the
system: Foremost they are using different interrupt controllers,
but also the memory map is slightly different. The base device
tree vfxxx.dtsi allows to create SoC and board level device trees
supporting the Cortex-M4 while reusing the shared peripherals
nodes.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/vf500.dtsi | 171
arch/arm/boot/dts/vf610-colibri.dtsi | 12 +
arch/arm/boot/dts/vf610-twr.dts | 12 +
arch/arm/boot/dts/vf610.dtsi | 504 +--
arch/arm/boot/dts/vfxxx.dtsi | 436 ++
5 files changed, 643 insertions(+), 492 deletions(-)
create mode 100644 arch/arm/boot/dts/vf500.dtsi
create mode 100644 arch/arm/boot/dts/vfxxx.dtsi
diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
new file mode 100644
index 000..de67005
--- /dev/null
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include skeleton.dtsi
+#include vfxxx.dtsi
+#include dt-bindings/interrupt-controller/arm-gic.h
+
+/ {
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ a5_cpu: cpu@0 {
+ compatible = arm,cortex-a5;
+ device_type = cpu;
+ reg = 0x0;
+ };
+ };
+
+ soc {
+ interrupt-parent = intc;
+
+ aips-bus@4000 {
+
+ intc: interrupt-controller@40002000 {
+ compatible = arm,cortex-a9-gic;
+ #interrupt-cells = 3;
+ interrupt-controller;
+ reg = 0x40003000 0x1000,
+ 0x40002100 0x100;
+ };
+
+ global_timer: timer@40002200 {
+ compatible = arm,cortex-a9-global-timer;
+ reg = 0x40002200 0x20;
+ interrupts = GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_PLATFORM_BUS;
+ };
+ };
+ };
+};
+
+adc0 {
+ interrupts = GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH;
+};
+
+adc1 {
+ interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
+};
+
+can0 {
+ interrupts = GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH;
+};
+
+can1 {
+ interrupts = GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH;
+};
+
+dspi0 {
+ interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
+};
+
+edma0 {
+ interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-names = edma-tx, edma-err;
+};
+
+edma1 {
+ interrupts = GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-names = edma-tx, edma-err;
+};
+
+esdhc1 {
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
+};
+
+fec0 {
+ interrupts = GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH;
+};
+
+fec1 {
+ interrupts = GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH;
+};
+
+ftm {
+ interrupts = GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH;
+};
+
+gpio1 {
+ interrupts = GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH;
+};
+
+gpio2 {
+ interrupts = GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH;
+};
+
+gpio3 {
+ interrupts = GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH;
+};
+
+gpio4 {
+ interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
+};
+
+gpio5 {
+ interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
+};
+
+i2c0 {
+ interrupts = GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH;
+};
+
+pit {
+ interrupts = GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH;
+};
+
+qspi0 {
+ interrupts = GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
+};
+
+sai2 {
+ interrupts
[PATCH RESEND v2 4/4] ARM: dts: vf500-colibri: add Colibri VF50 support
Add Colibri VF50 device tree files vf500-colibri.dtsi and
vf500-colibri-eval-v3.dts, in line with the Colibri VF61 device tree
files. However, to minimize dupplication we also add vf-colibri.dtsi
and vf-colibri-eval-v3.dtsi which contain the common device tree
nodes.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 54 ++
arch/arm/boot/dts/vf-colibri.dtsi | 142 ++
arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 17
arch/arm/boot/dts/vf500-colibri.dtsi| 20
arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 47 +
arch/arm/boot/dts/vf610-colibri.dtsi| 149 +---
7 files changed, 237 insertions(+), 193 deletions(-)
create mode 100644 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
create mode 100644 arch/arm/boot/dts/vf-colibri.dtsi
create mode 100644 arch/arm/boot/dts/vf500-colibri-eval-v3.dts
create mode 100644 arch/arm/boot/dts/vf500-colibri.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b51d485..b13c3d1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx6q-tx6q-1110.dtb \
imx6sl-evk.dtb \
imx6sx-sdb.dtb \
+ vf500-colibri-eval-v3.dtb \
vf610-colibri-eval-v3.dtb \
vf610-cosmic.dtb \
vf610-twr.dtb
diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
new file mode 100644
index 000..80e8fbc
--- /dev/null
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2014 Toradex AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+/ {
+ chosen {
+ bootargs = console=ttyLP0,115200;
+ };
+};
+
+bl {
+ brightness-levels = 0 4 8 16 32 64 128 255;
+ default-brightness-level = 6;
+ status = okay;
+};
+
+esdhc1 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_esdhc1;
+ bus-width = 4;
+ status = okay;
+};
+
+fec1 {
+ phy-mode = rmii;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_fec1;
+ status = okay;
+};
+
+pwm0 {
+ status = okay;
+};
+
+pwm1 {
+ status = okay;
+};
+
+uart0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
+
+uart2 {
+ status = okay;
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
new file mode 100644
index 000..ab40367
--- /dev/null
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -0,0 +1,142 @@
+/*
+ * Copyright 2014 Toradex AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+/ {
+ bl: backlight {
+ compatible = pwm-backlight;
+ pwms = pwm0 0 500 0;
+ status = disabled;
+ };
+};
+
+adc0 {
+ status = okay;
+};
+
+adc1 {
+ status = okay;
+};
+
+edma0 {
+ status = okay;
+};
+
+esdhc1 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_esdhc1;
+ bus-width = 4;
+};
+
+fec1 {
+ phy-mode = rmii;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_fec1;
+};
+
+pwm0 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_pwm0;
+};
+
+pwm1 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_pwm1;
+};
+
+uart0 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_uart0;
+};
+
+uart1 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_uart1;
+};
+
+uart2 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_uart2;
+};
+
+usbdev0 {
+ disable-over-current;
+ status = okay;
+};
+
+usbh1 {
+ disable-over-current;
+ status = okay;
+};
+
+iomuxc {
+ vf610-colibri {
+ pinctrl_esdhc1: esdhc1grp {
+ fsl,pins =
+ VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
+ VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
+ VF610_PAD_PTA26__ESDHC1_DAT00x31ef
+ VF610_PAD_PTA27__ESDHC1_DAT10x31ef
+ VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
+ VF610_PAD_PTA29__ESDHC1_DAT30x31ef
+ VF610_PAD_PTB20__GPIO_420x219d
+ ;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins =
+
[PATCH] ARM: kbuild: Fix forced rebuild after 'make dtbs'
After this patch: f4d4ffc03efc kbuild: dtbs_install: new make target was added the kernel tree, Linus Walleij noticed that 'make dtbs' forced a following 'make zImage' to rebuild the entire tree, even though nothing had changed. His report: After this patch a while back I have observed the following behaviour of the kernel build: make zImage make zImage - incremental build, just relink make zImage make dtbs make zImage - The whole kernel gets rebuilt So now if I happen to recompile my device trees, I suddenly want the entire zImage to be rebuilt to? It's by definition not changes that affect the kernel build :-( I noticed this because my build scripts calls make dtbs make zImage, and started to rebuild absolutely everything all the time. To fix this, we make only the dtbs_install target depend on the prepare target. It's needed to make sure KERNELVERSION is calculated prior to installing. Fixes: f4d4ffc03efc: (kbuild: dtbs_install: new make target) Reported-by: Linus Walleij linus.wall...@linaro.org Tested-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Jason Cooper ja...@lakedaemon.net --- Note: I've no idea if this is a 100% correct solution or not. I know it's definitely better than what we have currently. If there is another way to guarantee KERNELVERSION is set other than depending on 'prepare', I'd love to hear it. thx, Jason. arch/arm/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 034a94904d69..ae1c278128f8 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -312,7 +312,9 @@ $(INSTALL_TARGETS): $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@ PHONY += dtbs dtbs_install -dtbs dtbs_install: prepare scripts +dtbs: scripts + $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $@ +dtbs_install: prepare scripts $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $@ # We use MRPROPER_FILES and CLEAN_FILES now -- 2.1.3 -- 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: Document binding for regulator suspend voltage
On 11/01/2014 04:45 PM, Javier Martinez Canillas wrote: Hello Doug, On 11/01/2014 04:52 AM, Doug Anderson wrote: This patch builds upon (291d761 regulator: Document binding for regulator suspend state for PM state) to allow setting the uV in addition to the state at suspend time. Signed-off-by: Doug Anderson diand...@chromium.org --- Documentation/devicetree/bindings/regulator/regulator.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index aaad615..4e7ed76 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -28,6 +28,8 @@ Optional properties: - regulator-state-[mem/disk] node has following common properties: - regulator-on-in-suspend: regulator should be on in suspend state. - regulator-off-in-suspend: regulator should be off in suspend state. + - regulator-suspend-microvolt: regulator should be set to this voltage + in suspend. The patch looks good to me: Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk On thing I wonder is if the binding should say that the suspend voltage is independent of the runtime one and it may be outside of the runtime range? Best regards, Javier Reviewed-by: Chris Zhong z...@rock-chips.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] mmc: dw_mmc: add support for the other bit of sdio interrupt
On 2014/10/31 18:43, Heiko Stübner wrote:
Am Freitag, 31. Oktober 2014, 11:50:09 schrieb Addy Ke:
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 in RK3288. This patch add sdio_id0 for the number
of slot0 in the SDIO interrupt registers, which can be set in
platform DT table, such as:
- rockchip,sdio-interrupt-slot0 = 8;
I just checked the manuals of rk3066 and rk3188 - and it seems the sdio
interrupt is in bit 24 on all of them.
Addy, could you check this and maybe enable this for all two variants we
currently support?
OK, I will do so in my next patch. thank you!
Thanks
Heiko
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- rebase on http://git.linaro.org/git/people/ulf.hansson/mmc.git, next
branch
drivers/mmc/host/dw_mmc-rockchip.c | 13 +
drivers/mmc/host/dw_mmc.c | 12 +++-
drivers/mmc/host/dw_mmc.h | 2 ++
include/linux/mmc/dw_mmc.h | 3 +++
4 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c index bbb4ec3..1cb3bc6 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -68,6 +68,18 @@ static void dw_mci_rk3288_set_ios(struct dw_mci *host,
struct mmc_ios *ios) }
}
+static int dw_mci_rk3288_parse_dt(struct dw_mci *host)
+{
+struct device_node *np = host-dev-of_node;
+int sdio_id0;
+
+if (!of_property_read_u32(np, rockchip,sdio-interrupt-slot0,
+ sdio_id0))
+host-sdio_id0 = sdio_id0;
+
+return 0;
+}
+
static const struct dw_mci_drv_data rk2928_drv_data = {
.prepare_command= dw_mci_rockchip_prepare_command,
};
@@ -76,6 +88,7 @@ static const struct dw_mci_drv_data rk3288_drv_data = {
.prepare_command= dw_mci_rockchip_prepare_command,
.set_ios= dw_mci_rk3288_set_ios,
.setup_clock= dw_mci_rk3288_setup_clock,
+.parse_dt = dw_mci_rk3288_parse_dt,
};
static const struct of_device_id dw_mci_rockchip_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index bb46b1b..a633b58 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -823,7 +823,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
bool force_clkinit)
/* enable clock; only low power if no SDIO */
clk_en_a = SDMMC_CLKEN_ENABLE slot-id;
-if (!(mci_readl(host, INTMASK) SDMMC_INT_SDIO(slot-id)))
+if (!(mci_readl(host, INTMASK) SDMMC_INT_SDIO(slot-sdio_id)))
clk_en_a |= SDMMC_CLKEN_LOW_PWR slot-id;
mci_writel(host, CLKENA, clk_en_a);
@@ -1184,10 +1184,10 @@ static void dw_mci_enable_sdio_irq(struct mmc_host
*mmc, int enb) dw_mci_disable_low_power(slot);
mci_writel(host, INTMASK,
- (int_mask | SDMMC_INT_SDIO(slot-id)));
+ (int_mask | SDMMC_INT_SDIO(slot-sdio_id)));
} else {
mci_writel(host, INTMASK,
- (int_mask ~SDMMC_INT_SDIO(slot-id)));
+ (int_mask ~SDMMC_INT_SDIO(slot-sdio_id)));
}
}
@@ -2056,8 +2056,9 @@ static irqreturn_t dw_mci_interrupt(int irq, void
*dev_id) /* Handle SDIO Interrupts */
for (i = 0; i host-num_slots; i++) {
struct dw_mci_slot *slot = host-slot[i];
-if (pending SDMMC_INT_SDIO(i)) {
-mci_writel(host, RINTSTS, SDMMC_INT_SDIO(i));
+if (pending SDMMC_INT_SDIO(slot-sdio_id)) {
+mci_writel(host, RINTSTS,
+ SDMMC_INT_SDIO(slot-sdio_id));
mmc_signal_sdio_irq(slot-mmc);
}
}
@@ -2145,6 +2146,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
slot = mmc_priv(mmc);
slot-id = id;
+slot-sdio_id = host-sdio_id0 + id;
slot-mmc = mmc;
slot-host = host;
host-slot[id] = slot;
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 71d4995..0562f10 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -214,6 +214,7 @@ extern int dw_mci_resume(struct dw_mci *host);
* with CONFIG_MMC_CLKGATE.
* @flags: Random state bits associated with the slot.
* @id: Number of this slot.
+ * @sdio_id: Number of this slot in the SDIO interrupt registers.
*/
struct dw_mci_slot {
struct mmc_host *mmc;
@@ -233,6 +234,7 @@ struct dw_mci_slot {
#define DW_MMC_CARD_PRESENT 0
#define DW_MMC_CARD_NEED_INIT 1
int id;
+int sdio_id;
};
struct dw_mci_tuning_data {
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 69d0814..72c319f
[PATCH v3] mmc: dw_mmc: add support for the other bit of sdio interrupt
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- rebase on http://git.linaro.org/git/people/ulf.hansson/mmc.git, next branch
Changes in v3:
- Remove dts for sdio_id0, just replace this with 8, suggested by Doug
- Change to support all Rockchip Socs, suggested by Heiko
drivers/mmc/host/dw_mmc-rockchip.c | 10 ++
drivers/mmc/host/dw_mmc.c | 12 +++-
drivers/mmc/host/dw_mmc.h | 2 ++
include/linux/mmc/dw_mmc.h | 3 +++
4 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index bbb4ec3..b997c8f 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -68,14 +68,24 @@ static void dw_mci_rk3288_set_ios(struct dw_mci *host,
struct mmc_ios *ios)
}
}
+static int dw_mci_rockchip_parse_dt(struct dw_mci *host)
+{
+ /* It is slot 8 on Rockchip SoCs */
+ host-sdio_id0 = 8;
+
+ return 0;
+}
+
static const struct dw_mci_drv_data rk2928_drv_data = {
.prepare_command= dw_mci_rockchip_prepare_command,
+ .parse_dt = dw_mci_rockchip_parse_dt,
};
static const struct dw_mci_drv_data rk3288_drv_data = {
.prepare_command= dw_mci_rockchip_prepare_command,
.set_ios= dw_mci_rk3288_set_ios,
.setup_clock= dw_mci_rk3288_setup_clock,
+ .parse_dt = dw_mci_rockchip_parse_dt,
};
static const struct of_device_id dw_mci_rockchip_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index bb46b1b..a633b58 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -823,7 +823,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool
force_clkinit)
/* enable clock; only low power if no SDIO */
clk_en_a = SDMMC_CLKEN_ENABLE slot-id;
- if (!(mci_readl(host, INTMASK) SDMMC_INT_SDIO(slot-id)))
+ if (!(mci_readl(host, INTMASK) SDMMC_INT_SDIO(slot-sdio_id)))
clk_en_a |= SDMMC_CLKEN_LOW_PWR slot-id;
mci_writel(host, CLKENA, clk_en_a);
@@ -1184,10 +1184,10 @@ static void dw_mci_enable_sdio_irq(struct mmc_host
*mmc, int enb)
dw_mci_disable_low_power(slot);
mci_writel(host, INTMASK,
- (int_mask | SDMMC_INT_SDIO(slot-id)));
+ (int_mask | SDMMC_INT_SDIO(slot-sdio_id)));
} else {
mci_writel(host, INTMASK,
- (int_mask ~SDMMC_INT_SDIO(slot-id)));
+ (int_mask ~SDMMC_INT_SDIO(slot-sdio_id)));
}
}
@@ -2056,8 +2056,9 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
/* Handle SDIO Interrupts */
for (i = 0; i host-num_slots; i++) {
struct dw_mci_slot *slot = host-slot[i];
- if (pending SDMMC_INT_SDIO(i)) {
- mci_writel(host, RINTSTS, SDMMC_INT_SDIO(i));
+ if (pending SDMMC_INT_SDIO(slot-sdio_id)) {
+ mci_writel(host, RINTSTS,
+ SDMMC_INT_SDIO(slot-sdio_id));
mmc_signal_sdio_irq(slot-mmc);
}
}
@@ -2145,6 +2146,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
slot = mmc_priv(mmc);
slot-id = id;
+ slot-sdio_id = host-sdio_id0 + id;
slot-mmc = mmc;
slot-host = host;
host-slot[id] = slot;
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 71d4995..0562f10 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -214,6 +214,7 @@ extern int dw_mci_resume(struct dw_mci *host);
* with CONFIG_MMC_CLKGATE.
* @flags: Random state bits associated with the slot.
* @id: Number of this slot.
+ * @sdio_id: Number of this slot in the SDIO interrupt registers.
*/
struct dw_mci_slot {
struct mmc_host *mmc;
@@ -233,6 +234,7 @@ struct dw_mci_slot {
#define DW_MMC_CARD_PRESENT0
#define DW_MMC_CARD_NEED_INIT 1
int id;
+ int sdio_id;
};
struct dw_mci_tuning_data {
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 69d0814..72c319f 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -96,6 +96,7 @@ struct mmc_data;
* @quirks: Set of quirks that apply to specific versions of the IP.
* @irq_flags: The flags to be passed to request_irq.
* @irq: The irq value to be passed to request_irq.
+ * @sdio_id0: Number of slot0 in the SDIO interrupt registers.
*
*
[PATCH] pinctrl: Fix path error in documentation
Fix pinconfig include file path. Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 98eb94d..47d84b6 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -216,4 +216,4 @@ arguments are described below. or 0 to disable debouncing More in-depth documentation on these parameters can be found in -include/linux/pinctrl/pinconfig-generic.h +include/linux/pinctrl/pinconf-generic.h -- 1.8.1.1.dirty -- 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 v7 1/3] iommu/rockchip: rk3288 iommu driver
The rk3288 has several iommus. Each iommu belongs to a single master device. There is one device (ISP) that has two slave iommus, but that case is not yet supported by this driver. At subsys init, the iommu driver registers itself as the iommu driver for the platform bus. The master devices find their slave iommus using the iommus field in their devicetree description. Since each slave iommu belongs to exactly one master, their is no additional data needed at probe to associate a slave with its master. An iommu device's power domain, clock and irq are all shared with its master device, and the master device must be careful to attach from the iommu only after powering and clocking it (and leave it powered and clocked before detaching). Because their is no guarantee what the status of the iommu is at probe, and since the driver does not even know if the device is powered, we delay requesting its irq until the master device attaches, at which point we have a guarantee that the device is powered and clocked and we can reset it and disable its interrupt mask. An iommu_domain describes a virtual iova address space. Each iommu_domain has a corresponding page table that lists the mappings from iova to physical address. For the rk3288 iommu, the page table has two levels: The Level 1 directory_table has 1024 4-byte dte entries. Each dte points to a level 2 page_table. Each level 2 page_table has 1024 4-byte pte entries. Each pte points to a 4 KiB page of memory. An iommu_domain is created when a dma_iommu_mapping is created via arm_iommu_create_mapping. Master devices can then attach themselves to this mapping (or attach the mapping to themselves?) by calling arm_iommu_attach_device(). This in turn instructs the iommu driver to write the page table's physical address into the slave iommu's Directory Table Entry (DTE) register. In fact multiple master devices, each with their own slave iommu device, can all attach to the same mapping. The iommus for these devices will share the same iommu_domain and therefore point to the same page table. Thus, the iommu domain maintains a list of iommu devices which are attached. This driver relies on the iommu core to ensure that all devices have detached before destroying a domain. v6: - add .add/remove_device() callbacks. - parse platform_device device tree nodes for iommus property - store platform device pointer as group iommudata - Check for existence of iommu group instead of relying on a dev_get_drvdata() to return NULL for a NULL device. v7: - fixup some strings. - In rk_iommu_disable_paging() # and % were reversed. Signed-off-by: Daniel Kurtz djku...@chromium.org Signed-off-by: Simon Xue x...@rock-chips.com Reviewed-by: Grant Grundler grund...@chromium.org Reviewed-by: Stéphane Marchesin marc...@chromium.org Tested-by: Heiko Stuebner he...@sntech.de --- drivers/iommu/Kconfig | 12 + drivers/iommu/Makefile |1 + drivers/iommu/rockchip-iommu.c | 1038 3 files changed, 1051 insertions(+) create mode 100644 drivers/iommu/rockchip-iommu.c diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index dd51122..d0a1261 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -152,6 +152,18 @@ config OMAP_IOMMU_DEBUG Say N unless you know you need this. +config ROCKCHIP_IOMMU + bool Rockchip IOMMU Support + depends on ARCH_ROCKCHIP + select IOMMU_API + select ARM_DMA_USE_IOMMU + help + Support for IOMMUs found on Rockchip rk32xx SOCs. + These IOMMUs allow virtualization of the address space used by most + cores within the multimedia subsystem. + Say Y here if you are using a Rockchip SoC that includes an IOMMU + device. + config TEGRA_IOMMU_GART bool Tegra GART IOMMU Support depends on ARCH_TEGRA_2x_SOC diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 16edef7..3e47ef3 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o +obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c new file mode 100644 index 000..b2023af --- /dev/null +++ b/drivers/iommu/rockchip-iommu.c @@ -0,0 +1,1038 @@ +/* + * 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 asm/cacheflush.h +#include asm/pgtable.h +#include linux/compiler.h +#include linux/delay.h +#include
[PATCH v7 2/3] dt-bindings: iommu: Add documentation for rockchip iommu
Add binding documentation for Rockchip IOMMU.
Signed-off-by: Daniel Kurtz djku...@chromium.org
Signed-off-by: Simon Xue x...@rock-chips.com
Reviewed-by: Heiko Stuebner he...@sntech.de
---
.../devicetree/bindings/iommu/rockchip,iommu.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
new file mode 100644
index 000..9a55ac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
@@ -0,0 +1,26 @@
+Rockchip IOMMU
+==
+
+A Rockchip DRM iommu translates io virtual addresses to physical addresses for
+its master device. Each slave device is bound to a single master device, and
+shares its clocks, power domain and irq.
+
+Required properties:
+- compatible : Should be rockchip,iommu
+- reg : Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- interrupt-names : Interrupt name for the IOMMU instance
+- #iommu-cells: Should be 0. This indicates the iommu is a
+single-master device, and needs no additional information
+to associate with its master device. See:
+Documentation/devicetree/bindings/iommu/iommu.txt
+
+Example:
+
+ vopl_mmu: iommu@ff940300 {
+ compatible = rockchip,iommu;
+ reg = 0xff940300 0x100;
+ interrupts = GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-names = vopl_mmu;
+ #iommu-cells = 0;
+ };
--
2.1.0.rc2.206.gedb03e5
--
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 v7 3/3] ARM: dts: rk3288: add VOP iommu nodes
Add device nodes for the VOP iommus.
Device nodes for other iommus will be added in later patches.
The iommu nodes use the #iommu-cells property as described in:
Documentation/devicetree/bindings/iommu/iommu.txt
Signed-off-by: Daniel Kurtz djku...@chromium.org
Signed-off-by: Simon Xue x...@rock-chips.com
---
arch/arm/boot/dts/rk3288.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..df1170c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -271,6 +271,24 @@
status = disabled;
};
+ vopb_mmu: iommu@ff930300 {
+ compatible = rockchip,iommu;
+ reg = 0xff930300 0x100;
+ interrupts = GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-names = vopb_mmu;
+ #iommu-cells = 0;
+ status = disabled;
+ };
+
+ vopl_mmu: iommu@ff940300 {
+ compatible = rockchip,iommu;
+ reg = 0xff940300 0x100;
+ interrupts = GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-names = vopl_mmu;
+ #iommu-cells = 0;
+ status = disabled;
+ };
+
gic: interrupt-controller@ffc01000 {
compatible = arm,gic-400;
interrupt-controller;
--
2.1.0.rc2.206.gedb03e5
--
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] of/irq: Drop obsolete 'interrupts' vs 'interrupts-extended' text
Le 01/11/2014 16:35, Bjorn Helgaas a écrit : a9ecdc0fdc54 (of/irq: Fix lookup to use 'interrupts-extended' property first) updated the description to say that: - Both 'interrupts' and 'interrupts-extended' may be present - Software should prefer 'interrupts-extended' - Software that doesn't comprehend 'interrupts-extended' may use 'interrupts' But there is still a paragraph at the end that prohibits having both and says 'interrupts' should be preferred. Remove the contradictory text. Fixes: a9ecdc0fdc54 (of/irq: Fix lookup to use 'interrupts-extended' property first) Signed-off-by: Bjorn Helgaas bhelg...@google.com Acked-by: Florian Fainelli f.faine...@gmail.com CC: sta...@vger.kernel.org # v3.13+ --- .../bindings/interrupt-controller/interrupts.txt |4 1 file changed, 4 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index ce6a1a072028..8a3c40829899 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -30,10 +30,6 @@ should only be used when a device has multiple interrupt parents. Example: interrupts-extended = intc1 5 1, intc2 1 0; -A device node may contain either interrupts or interrupts-extended, but not -both. If both properties are present, then the operating system should log an -error and use only the data in interrupts. - 2) Interrupt controller nodes - -- 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] I2C: mediatek: Add driver for MediaTek I2C controller
On Fri, 2014-10-31 at 17:10 +0100, Matthias Brugger wrote:
2014-10-31 15:38 GMT+01:00 Yingjoe Chen yingjoe.c...@mediatek.com:
On Fri, 2014-10-31 at 11:48 +0100, Matthias Brugger wrote:
2014-10-31 7:31 GMT+01:00 xudong chen xudong.c...@mediatek.com:
On Thu, 2014-10-30 at 14:16 +0100, Matthias Brugger wrote:
2014-10-29 6:37 GMT+01:00 Xudong Chen xudong.c...@mediatek.com:
The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.
Signed-off-by: Xudong Chen xudong.c...@mediatek.com
Change-Id: Icc17e326b9df46a226d536956e103f17b0382b6e
---
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-mt65xx.c | 728
3 files changed, 738 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-mt65xx.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 917c358..0d7d0a4 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -564,6 +564,15 @@ config I2C_MPC
This driver can also be built as a module. If so, the
module
will be called i2c-mpc.
+config I2C_MT65XX
+ tristate MediaTek I2C adapter
+ depends on ARCH_MEDIATEK
+ help
+ This selects the MediaTek(R) Integrated Inter Circuit bus
driver
+ for MT65xx and MT81xx.
+ If you want to use MediaTek(R) I2C interface, say Y or M
here.
+ If unsure, say N.
+
config I2C_MV64XXX
tristate Marvell mv64xxx I2C Controller
depends on MV64X60 || PLAT_ORION || ARCH_SUNXI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 78d56c5..7a9f0f3 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o
obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o
+
+static int mt_i2c_do_transfer(struct mt_i2c *i2c)
+{
+ u16 addr_reg;
+ u16 control_reg;
+ int tmo = i2c-adap.timeout;
+
+ i2c-trans_stop = false;
+ i2c-irq_stat = 0;
+
+ /* If use i2c pin from PMIC mt6397 side, need set PATH_DIR
first */
+ if (i2c-have_pmic)
+ i2c_writew(I2C_CONTROL_WRAPPER, i2c, OFFSET_PATH_DIR);
So this is some sort of multiplexer bit, right?
I think in this case we need to build a multi function device (mfd)
where the pmic driver will set this bit.
Hi,
This feature means the chip can use I2C pins from PMIC(mt6397).
In this case,
1. We actually control the register on mt8135 and the DMA/Control Logic
is on mt8135, only use pins from mt6397. If set register OFFSET_PATH_DIR
bit0 to 1, the I2C data will go/from PMIC pins.
Sorry but I'm a bit puzzled. mt6397 is the PMIC, right?
So from the mt6589 datasheet it says:
PATH_DIR Decides transmission direction
If set, the I2C data will go/from PMIC; otherwise, the I2C data will
go/from main die.
From my understanding the I2C bus will be multiplexed depending on
this bit. The bit decides if it the data will be send to the PMIC or
to some other I2C peripheral.
So we need a mfd and the PMIC device driver sets/unsets the PATH_DIR
register.
Yes, mt6397 is the PMIC work with mt8135 or mt8127.
I think the datasheet is a little misleading here. AFAIK, on 8135 even
if your clear the bit for I2C4, there are no corresponding pins for this
i2c port on 8135. So it is not really multiplexed. Base on my
understanding this is more like Set this bit if this a PMIC I2C port.
I had a look at mt6589. The SoC has seven i2c controller. Looking at
the source code all controller with an ID bigger then 3 can be set to
pmic wrapper state.
I have checked the mt8135 and mt6589 GPIO datasheet, there are pins on
mt8135 or mt6589 for i2c4~i2c6, we also can use i2c4~i2c6 modules on
mt8135 or mt6589 after set pinmux. Sorry about the misunderstand before.
I will add i2c4~i2c6 nodes to the mt8135.dtsi in next patch.
So I would say that the PATH_DIR bit is not always bound to i2c4. We
should implement a driver which will work on all possible
configurations. We don't know if apart from mt6589 and mt8135 some
other SoC in the future will use this i2c controller.
Because the mt6397 HW limitation, it's i2c module cannot be used when
apart from mt6589 or mt8135.
Take mt6589 for example:
If we want to use mt6397 i2c pins, it must work together with mt6589,
also we need to set the i2c control register on mt6589(DIR_PATH and the
other registers) and then the HW will
Re: [PATCH v5 2/3] ARM: dts: pbab01: enable I2S audio on phyFLEX-i.MX6 boards
On Wed, Oct 29, 2014 at 04:47:03PM +0300, Dmitry Lavnikevich wrote:
Audio on phyFLEX boards is presented by tlv320aic3007 codec connected
over SSI interface.
Signed-off-by: Dmitry Lavnikevich d.lavnikev...@sam-solutions.com
---
arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi | 100
++-
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 15
2 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
b/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
index f1bdcae5b97d..cb8f1b6ec083 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
@@ -9,10 +9,73 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include dt-bindings/sound/fsl-imx-audmux.h
+
/ {
chosen {
linux,stdout-path = uart4;
};
+
+ regulators {
+ sound_1v8: regulator@2 {
+ compatible = regulator-fixed;
+ reg = 2;
+ regulator-name = i2s-audio-1v8;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ sound_3v3: regulator@3 {
+ compatible = regulator-fixed;
+ reg = 3;
+ regulator-name = i2s-audio-3v3;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+ };
+
+ tlv320_mclk: oscillator {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 1920;
+ clock-output-names = tlv320-mclk;
+ };
+
+ sound {
+ compatible = simple-audio-card;
+ simple-audio-card,name = OnboardTLV320AIC3007;
+ simple-audio-card,format = i2s;
+ simple-audio-card,bitclock-master = dailink_master;
+ simple-audio-card,frame-master = dailink_master;
+ simple-audio-card,widgets =
+ Microphone, Mic Jack,
+ Line, Line In,
+ Line, Line Out,
+ Speaker, Speaker,
+ Headphone, Headphone Jack;
+ simple-audio-card,routing =
+ Line Out, LLOUT,
+ Line Out, RLOUT,
+ Speaker, SPOP,
+ Speaker, SPOM,
+ Headphone Jack, HPLOUT,
+ Headphone Jack, HPROUT,
+ MIC3L, Mic Jack,
+ MIC3R, Mic Jack,
+ Mic Jack, Mic Bias,
+ LINE1L, Line In,
+ LINE1R, Line In;
+
+ simple-audio-card,cpu {
+ sound-dai = ssi2;
+ };
+
+ dailink_master: simple-audio-card,codec {
+ sound-dai = codec;
+ clocks = tlv320_mclk;
+ };
+ };
+
};
fec {
@@ -27,12 +90,45 @@
status = okay;
};
+ssi2 {
+ status = okay;
+};
+
+audmux {
Please sort the nodes alphabetically in label name.
+ status = okay;
+
+ ssi2 {
+ fsl,audmux-port = 1;
+ fsl,port-config =
+ (IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(4) |
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(4))
+ IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ ;
+ };
+ pins5 {
Have a new line between nodes.
+ fsl,audmux-port = 4;
+ fsl,port-config =
+ 0x
+ IMX_AUDMUX_V2_PDCR_RXDSEL(1)
+ ;
+ };
+};
+
i2c2 {
status = okay;
- tlv320@18 {
- compatible = ti,tlv320aic3x;
+ codec: tlv320@18 {
+ compatible = ti,tlv320aic3007;
Both compatible strings are documented in
Documentation/devicetree/bindings/sound/tlv320aic3x.txt. But I hope
this change will not cause any DT compatible issues.
+ #sound-dai-cells = 0;
reg = 0x18;
+ ai3x-micbias-vg = 2;
+
+ AVDD-supply = sound_3v3;
+ IOVDD-supply = sound_3v3;
+ DRVDD-supply = sound_3v3;
+ DVDD-supply = sound_1v8;
};
stmpe@41 {
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index aa2275671d2c..d7f34664e008 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -58,6 +58,12 @@
};
};
+audmux {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_audmux;
+ status = disabled;
+};
+
ecspi3 {
pinctrl-names = default;
pinctrl-0 =
