[PATCH v3 3/3] Documentation: update samsung pmu binding information
This patch updates samsung pmu (power management unit) binding information. CC: Leela Krishna Amudala CC: Tomasz Figa CC: Guenter Roeck CC: Rob Landley Signed-off-by: Pankaj Dubey --- Documentation/devicetree/bindings/arm/samsung/pmu.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index f1f1552..b562634 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -2,6 +2,9 @@ SAMSUNG Exynos SoC series PMU Registers Properties: - compatible : should contain two values. First value must be one from following list: + - "samsung,exynos4210-pmu" - for Exynos4210 SoC, + - "samsung,exynos4212-pmu" - for Exynos4212 SoC, + - "samsung,exynos4412-pmu" - for Exynos4412 SoC, - "samsung,exynos5250-pmu" - for Exynos5250 SoC, - "samsung,exynos5420-pmu" - for Exynos5420 SoC. second value must be always "syscon". -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] ARM: dts: Add PMU node to exynos4210
This patch adds pmu regnode to exynos4210 dtsi to handle
PMU register access via DT.
Signed-off-by: Pankaj Dubey
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index d3d727b..d23d3f0 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -99,6 +99,11 @@
interrupts = <2 2>, <3 2>;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = "samsung,exynos4210-pmu", "syscon";
+ reg = <0x1002 0x5000>;
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4210-pinctrl";
reg = <0x1140 0x1000>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] ARM: dts: Add PMU node to exynos4212 and exynos4412
This patch adds pmu regnode to exynos4212 and exynos4412 dtsi to
handle PMU register access via DT.
Signed-off-by: Pankaj Dubey
---
arch/arm/boot/dts/exynos4212.dtsi |5 +
arch/arm/boot/dts/exynos4412.dtsi |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 3c00e6e..4661ffa 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -29,4 +29,9 @@
gic: interrupt-controller@1049 {
cpu-offset = <0x8000>;
};
+
+ pmu_system_controller: system-controller@1002 {
+ compatible = "samsung,exynos4212-pmu", "syscon";
+ reg = <0x1002 0x5000>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 15d3c0a..6f4cb22 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -29,4 +29,9 @@
gic: interrupt-controller@1049 {
cpu-offset = <0x4000>;
};
+
+ pmu_system_controller: system-controller@1002 {
+ compatible = "samsung,exynos4412-pmu", "syscon";
+ reg = <0x1002 0x5000>;
+ };
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] Add PMU node for Exynos4 SoCs
This patch updates Exynos4210, Exynos4412 and Exynos4212 dtsi files for adding PMU (Power Management Unit) reg node. Updated binding document for the same. These patches are required for converting PMU implementation free from static mapping of PMU registers as well as it's dependency from machine header files, thus allowing us to converting it into DT based. Revision 2 was posted here - https://lkml.org/lkml/2014/4/25/216 Changes since v2: - Dropped addition of new property followed by one simple fix in syscon driver posted here [1]. - Addressed review comments [2] by Tomasz Figa about property pointing back to self device node. - Updated binding doc with example. Changes since v1: - Added new property "samsung,syscon-phandle" to get access to PMU regmap handle. - Updated Exynos5250, Exynos5420, Exynos4210/4412/4212 dtsi files. - Rebased on Kukjin Kim's for-next branch. [1]: Allow NULL property in syscon_early_regmap_lookup_by_phandle https://lkml.org/lkml/2014/5/10/10 and https://lkml.org/lkml/2014/4/29/661 [2]: https://lkml.org/lkml/2014/4/25/762 Pankaj Dubey (3): ARM: dts: Add PMU node to exynos4210 ARM: dts: Add PMU node to exynos4212 and exynos4412 Documentation: update samsung pmu binding information Documentation/devicetree/bindings/arm/samsung/pmu.txt |3 +++ arch/arm/boot/dts/exynos4210.dtsi |5 + arch/arm/boot/dts/exynos4212.dtsi |5 + arch/arm/boot/dts/exynos4412.dtsi |5 + 4 files changed, 18 insertions(+) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] printk/of_serial: fix serial console cessation part way through boot.
Commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
"serial_core: Unregister console in uart_remove_one_port()"
fixed a crash where a serial port was removed but
not deregistered as a console.
There is a side effect of that commit for platforms having serial consoles
and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
is disabled midway through the boot process.
This cessation of the serial console affects PowerPC computers
such as the MVME5100 and SAM440EP.
The sequence is:
bootconsole [udbg0] enabled
serial8250/16550 driver initialises and registers its UARTS,
one of these is the serial console.
console [ttyS0] enabled
of_serial probes "platform" devices, registering them as it goes.
One of these is the serial console.
console [ttyS0] disabled.
The disabling of the serial console is due to:
a. unregister_console in printk not clearing the
CONS_ENABLED bit in the console flags,
even though it has announced that the console is disabled; and
b. of_platform_serial_probe in of_serial not setting the port type
before it registers with serial8250_register_8250_port.
This patch ensures that the serial console is re-enabled when of_serial
registers a serial port that corresponds to the designated console.
Signed-off-by: Stephen Chivers
Tested-by: Stephen Chivers
===
The above failure was identified in Linux-3.15-rc2.
Tested using MVME5100 and SAM440EP PowerPC computers with
kernels built from Linux-3.15-rc5 and tty-next.
The continued operation of the serial console is vital for computers
such as the MVME5100 as that Single Board Computer does not
have any grapical/display hardware.
---
drivers/tty/serial/of_serial.c |1 +
kernel/printk/printk.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 9924660..27981e2 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -173,6 +173,7 @@ static int of_platform_serial_probe(struct platform_device
*ofdev)
{
struct uart_8250_port port8250;
memset(&port8250, 0, sizeof(port8250));
+ port.type = port_type;
port8250.port = port;
if (port.fifosize)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 7228258..221229c 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2413,6 +2413,7 @@ int unregister_console(struct console *console)
if (console_drivers != NULL && console->flags & CON_CONSDEV)
console_drivers->flags |= CON_CONSDEV;
+ console->flags &= ~CON_ENABLED;
console_unlock();
console_sysfs_notify();
return res;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] clk: samsung: out: Add infrastructure to register CLKOUT
On 05/09/2014 10:00 PM, Tushar Behera wrote:
All SoC in Exynos-series have a clock with name XCLKOUT to provide
debug information about various clocks available in the SoC. The register
controlling the MUX and GATE of this clock is provided within PMU domain.
Since PMU domain can't be dedicatedly mapped by every driver, the register
needs to be handled through a regmap handle provided by PMU syscon
controller. Right now, CCF doesn't allow regmap based MUX and GATE clocks,
hence a dedicated clock provider for XCLKOUT is added here.
Signed-off-by: Tushar Behera
CC: Tomasz Figa
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-out.c | 181 +
drivers/clk/samsung/clk.h | 33
3 files changed, 215 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-out.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..d23ad4f 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-out.o
obj-$(CONFIG_ARCH_EXYNOS4)+= clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-out.c b/drivers/clk/samsung/clk-out.c
new file mode 100644
index 000..76489b6
--- /dev/null
+++ b/drivers/clk/samsung/clk-out.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the clkout clocks.
+*/
+
+/**
+ * All SoC in Exynos-series have a clock with name XCLKOUT to provide
+ * debug information about various clocks available in the SoC. The register
+ * controlling the MUX and GATE of this clock is provided within PMU domain.
+ * Since PMU domain can't be dedicatedly mapped every driver, the register
+ * needs to be handled through a regmap handle provided by PMU syscon
+ * controller. Right now, CCF doesn't allow regmap based MUX and GATE clocks,
+ * hence a dedicated clock provider for XCLKOUT is added here.
+ */
+
+#include
+#include
+#include
+
+#include "clk.h"
+
+/**
+ * struct samsung_clkout_soc_data: SoC specific register details
+ * @reg: Offset of CLKOUT register from PMU base
how about naming this variable as "offset" instead of "reg".
+ * @mux_shift: Start-bit of MUX bit-field
+ * @mux_width: Width of MUX bit-field
+ * @enable_bit: The bit corresponding to gating of this clock
+ */
+struct samsung_clkout_soc_data {
+ unsigned int reg;
+ u8 mux_shift;
+ u8 mux_width;
+ u8 enable_bit;
+};
+
+/**
+ * struct samsung_clkout: Structure to store driver specific clock context
+ * @hw: Handle to CCF clock
+ * @soc_data: SoC specific register details
+ * @regmap: Regmap handle of the PMU
+ */
+struct samsung_clkout {
+ struct clk_hw hw;
+ const struct samsung_clkout_soc_data *soc_data;
+ struct regmap *regmap;
+};
+
+#define to_clk_out(_hw) container_of(_hw, struct samsung_clkout, hw)
+
+int samsung_clkout_enable(struct clk_hw *hw)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int enable_mask = BIT(soc_data->enable_bit);
+
+ /* clkout is enabled if enable bit is low */
+ regmap_update_bits(clkout->regmap, soc_data->reg, enable_mask, 0);
+
+ return 0;
+}
+
+void samsung_clkout_disable(struct clk_hw *hw)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int enable_mask = BIT(soc_data->enable_bit);
+
+ /* clkout is gated if enable bit is high */
+ regmap_update_bits(clkout->regmap, soc_data->reg,
+ enable_mask, enable_mask);
+
+ return;
+}
+
+int samsung_clkout_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int parent_mask = BIT(soc_data->mux_width) - 1;
+
+ regmap_update_bits(clkout->regmap, soc_data->reg,
+ parent_mask << soc_data->mux_shift,
+ index << soc_data->mux_shift);
+
+ return 0;
+}
+
+u8 samsung_clkout_get_parent(struct clk_hw *hw)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int parent_mask = BIT(soc_data->mux_width) - 1;
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clkout->regmap, soc_data->reg, &val);
Do we
Re: [PATCH 0/4] Add framework to support clkout
Hi Tushar,
On 05/09/2014 10:00 PM, Tushar Behera wrote:
The MUX/GATE register for XCLKOUT doesn't resides within PMU domain,
this can be accessed through a regmap provided by syscon driver. Adding
another clock provider to handle regmap based handing of XCLKOUT.
Dependency:
1. [PATCH v3] mfd: syscon: Support early initialization
http://article.gmane.org/gmane.linux.kernel/1679446
Also we need to find a suitable place to call early_syscon_init(), after
the device tree has been unflattened and before clock initialization.
While testing, I called this before of_clk_init() in arch/arm/kernel/time.c,
but that place is too generic. Calling anywhere from exynos.c is not
working ATM.
IMO we do not need to, or if I am not wrong we should not change time.c.
It's possible if we have exynos specific init_time with following changes.
FYI, In my patch series for Exynos PMU [1], currently I am handling this in
exynos_dt_machine_init. But definitely it can be handled as below and it works
without any side effect and I have tested it. Only reason I do not adopted this
as for Exynos PMU patch support I had other options. But if required and if
following change is acceptable I can include this in my next version of Exynos
PMU patch series.
[1]: https://lkml.org/lkml/2014/4/30/18
+static void __init exynos_init_time(void)
+{
+/* Nothing to do timer specific
+ * as early_syscon_init requires DT to be unflattened and
+ * system should be able to allocate memory we need to
+ * postpone until init_time, but it should be done before
+ * init_machine. Because before init_machine, secondary
+ * core boot starts and it uses PMU registers.
+ */
+
+exynos_map_pmu();
+
+of_clk_init(NULL);
+clocksource_of_init();
+
+}
+
DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
/* Maintainer: Thomas Abraham */
/* Maintainer: Kukjin Kim */
.smp= smp_ops(exynos_smp_ops),
.map_io= exynos_init_io,
.init_early= exynos_firmware_init,
+.init_time= exynos_init_time,
Tushar Behera (4):
clk: samsung: out: Add infrastructure to register CLKOUT
clk: samsung: exynos5420: Add xclkout debug clock
clk: samsung: exynos5250: Add xclkout debug clock
ARM: dts: Add pmu-syscon handle for Exynos5420/Exynos5250 clock
arch/arm/boot/dts/exynos5250.dtsi |1 +
arch/arm/boot/dts/exynos5420.dtsi |1 +
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-exynos5250.c | 14 +++
drivers/clk/samsung/clk-exynos5420.c | 14 +++
drivers/clk/samsung/clk-out.c | 181
drivers/clk/samsung/clk.h | 33 ++
include/dt-bindings/clock/exynos5250.h |3 +
include/dt-bindings/clock/exynos5420.h |5 +-
9 files changed, 252 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/samsung/clk-out.c
--
Best Regards,
Pankaj Dubey
--
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: am335x-bone-common: Add i2c2 definition
Add missing i2c2 bus define to access various cape and
prototype/breakout board devices.
Signed-off-by: Matt Ranostay
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..5fdae2e 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -84,6 +84,13 @@
>;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
uart1_rtsn.i2c2_scl */
+ >;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
+ status = "okay";
+ clock-frequency = <10>;
+};
+
/include/ "tps65217.dtsi"
&tps {
--
1.8.3.2
--
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 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
On Fri, May 09, 2014 at 06:56:10PM +0200, Boris BREZILLON wrote: > The P2WI looks like an SMBus controller which only supports byte data > transfers. But, it differs from standard SMBus protocol on several > aspects: > - it supports only one slave device, and thus drop the address field > - it adds a parity bit every 8bits of data > - only one read access is required to read a byte (instead of a read > followed by a write access in standard SMBus protocol) > - there's no Ack bit after each byte transfer > > This means this bus cannot be used to interface with standard SMBus > devices (the only known device to support this interface is the AXP221 > PMIC). > > Signed-off-by: Boris BREZILLON > --- > Changes since v2: > - drop the initialization (switch from I2C to P2WI mode) part > - print devm_ioremap_resource err code You'll also need to update the documentation of the DT bindings. > > drivers/i2c/busses/Kconfig | 12 ++ > drivers/i2c/busses/Makefile | 1 + > drivers/i2c/busses/i2c-sun6i-p2wi.c | 352 > > 3 files changed, 365 insertions(+) > create mode 100644 drivers/i2c/busses/i2c-sun6i-p2wi.c > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index c94db1c..09bce1c 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -771,6 +771,18 @@ config I2C_STU300 > This driver can also be built as a module. If so, the module > will be called i2c-stu300. > > +config I2C_SUN6I_P2WI > + tristate "Allwinner sun6i internal P2WI controller" > + depends on ARCH_SUNXI > + help > + If you say yes to this option, support will be included for the > + P2WI (Push/Pull 2 Wire Interface) controller embedded in some sunxi > + SOCs. > + The P2WI looks like an SMBus controller (which supports only byte > + accesses), except that it only supports one slave device. > + This interface is used to connect to specific PMIC devices (like the > + AXP221). > + > config I2C_TEGRA > tristate "NVIDIA Tegra internal I2C controller" > depends on ARCH_TEGRA > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile > index 18d18ff..58feeb9 100644 > --- a/drivers/i2c/busses/Makefile > +++ b/drivers/i2c/busses/Makefile > @@ -75,6 +75,7 @@ obj-$(CONFIG_I2C_SIMTEC)+= i2c-simtec.o > obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o > obj-$(CONFIG_I2C_ST) += i2c-st.o > obj-$(CONFIG_I2C_STU300) += i2c-stu300.o > +obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o > obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o > obj-$(CONFIG_I2C_VERSATILE) += i2c-versatile.o > obj-$(CONFIG_I2C_WMT)+= i2c-wmt.o > diff --git a/drivers/i2c/busses/i2c-sun6i-p2wi.c > b/drivers/i2c/busses/i2c-sun6i-p2wi.c > new file mode 100644 > index 000..7c859ee > --- /dev/null > +++ b/drivers/i2c/busses/i2c-sun6i-p2wi.c > @@ -0,0 +1,352 @@ > +/* > + * P2WI (Push-Pull Two Wire Interface) bus driver. > + * > + * Author: Boris BREZILLON > + * > + * This file is licensed under the terms of the GNU General Public License > + * version 2. This program is licensed "as is" without any warranty of any > + * kind, whether express or implied. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > + > +/* P2WI registers */ > +#define P2WI_CTRL0x0 > +#define P2WI_CCR 0x4 > +#define P2WI_INTE0x8 > +#define P2WI_INTS0xc > +#define P2WI_DADDR0 0x10 > +#define P2WI_DADDR1 0x14 > +#define P2WI_DLEN0x18 > +#define P2WI_DATA0 0x1c > +#define P2WI_DATA1 0x20 > +#define P2WI_LCR 0x24 > +#define P2WI_PMCR0x28 > + > +/* CTRL fields */ > +#define P2WI_CTRL_START_TRANSBIT(7) > +#define P2WI_CTRL_ABORT_TRANSBIT(6) > +#define P2WI_CTRL_GLOBAL_INT_ENB BIT(1) > +#define P2WI_CTRL_SOFT_RST BIT(0) > + > +/* CLK CTRL fields */ > +#define P2WI_CCR_SDA_OUT_DELAY(v)(((v) & 0x7) << 8) > +#define P2WI_CCR_MAX_CLK_DIV 0xff > +#define P2WI_CCR_CLK_DIV(v) ((v) & P2WI_CCR_MAX_CLK_DIV) > + > +/* STATUS fields */ > +#define P2WI_INTS_TRANS_ERR_ID(v)(((v) >> 8) & 0xff) > +#define P2WI_INTS_LOAD_BSY BIT(2) > +#define P2WI_INTS_TRANS_ERR BIT(1) > +#define P2WI_INTS_TRANS_OVER BIT(0) > + > +/* DATA LENGTH fields*/ > +#define P2WI_DLEN_READ BIT(4) > +#define P2WI_DLEN_DATA_LENGTH(v) ((v - 1) & 0x7) > + > +/* LINE CTRL fields*/ > +#define P2WI_LCR_SCL_STATE BIT(5) > +#define P2WI_LCR_SDA_STATE BIT(4) > +#define P2WI_LCR_SCL_CTL BIT(3) > +#define P2WI_LCR_SCL_CTL_EN BIT(2) > +#define P2WI_LCR_SDA_CTL BIT(1) > +#defin
Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
Hi Josh,
On 05/05/2014 04:54 PM, Josh Cartwright wrote:
> On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
>> Hi Rob,
>>
>> On 04/30/2014 07:34 PM, Suman Anna wrote:
>>> The property 'hwlock-reserved-locks' will be used to represent
>>> the number of locks to be reserved for clients that would need
>>> to request/operate on specific locks. A new OF helper function,
>>> of_hwspin_lock_get_num_reserved_locks(), is added to minimize
>>> duplication in different platform implementations.
>>>
>>> The function will return a value of 0 if the property is not
>>> defined, so as to support a default behavior of marking all
>>> locks as unused and open for anonymous allocations.
>>>
>>> Signed-off-by: Suman Anna
>>> ---
>>> .../devicetree/bindings/hwlock/hwlock.txt | 3 +++
>>> drivers/hwspinlock/hwspinlock_core.c | 25
>>> ++
>>> include/linux/hwspinlock.h | 1 +
>>> 3 files changed, 29 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> index d538a9b..88d16d2 100644
>>> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> @@ -18,6 +18,9 @@ Common properties:
>>> property is needed on hwlock devices, where the number
>>> of supported locks within a hwlock device cannot be
>>> read from a register.
>>> +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
>>> + specific locks. This value cannot exceed the value of
>>> + hwlock-num-locks.
>>
>> Any suggestions here on the approach? This property falls into a gray
>> area as well, as the current approach is somewhat limiting (it doesn't
>> support sparse reserved locks, and expects them at the beginning of the
>> lock range).
>
> Is it possible to implement a pinctrl-like hogging approach, whereby the
> specific locks that need to be reserved are consumed by the controller
> itself?
>
Thanks for the suggestion. I did take a look at pinctrl and while it is
possible to implement something similar, I feel it is a bit heavy for
hwspinlock framework with no added advantages. It requires that the
controller and clients always need to be updated together. Ohad had
already brought this up [1]. Here's an alternate approach that does not
require any additional property to the controller itself, while the
client node usage is as before. The logic is based on parsing through
the DT blob and marking only those that are used by any clients. The RFC
patch below is a replacement for Patches 11 to 15, and do not require
any changes to platform implementations or additional DT properties.
It currently marks locks as reserved even for disabled client nodes
(very easy to change that behavior). It will also impose a standard
property name "hwlocks" on the client nodes. What do you think of this
approach?
regards
Suman
[1] http://marc.info/?l=linux-omap&m=139514977622964&w=2
>From 4f4cbe91e56c1be8faa6a3ee863add4df6e6714b Mon Sep 17 00:00:00 2001
From: Suman Anna
Date: Fri, 9 May 2014 14:26:54 -0500
Subject: [RFC PATCH] hwspinlock/core: add support for reserved locks
The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.
The HwSpinlock core has been enhanced to mark certain locks as 'reserved'
by parsing through the DT blob. Thes
The HwSpinlock core has been enhanced to:
1. mark certain locks as 'reserved' by parsing the DT blob for any
locks used by client nodes.
2. restrict the anonymous hwspin_lock_request() API to allocate only
from non-reserved locks for DT boots.
3. limit these reserved locks to be allocated only using the
_request_specific() API variants for DT boots.
Signed-off-by: Suman Anna
---
drivers/hwspinlock/hwspinlock_core.c | 50
++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..0c924c9 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -425,6 +425,42 @@ static int hwspinlock_device_add(struct
hwspinlock_device *bank)
return ret;
}
+static void hwspin_mark_reserved_locks(struct hwspinlock_device *bank)
+{
+ struct device_node *np = bank->dev->of_node;
+ const char *prop_name = "hwlocks";
+ const char *cells_name = "#hwlock-cells";
+ struct device_node *node = NULL;
+ struct of_phandle_args args;
+ struct hwspinlock *hwlock;
+ int i, id, count, ret;
+
+ for_each_node_with_property(node, prop_name) {
+ count = of_count_phandle_with_args(node, prop_name
Re: [PATCH RFC v3 4/6] arm64: add PSCI CPU_SUSPEND based cpu_suspend support
Quoting Lorenzo Pieralisi (2014-05-06 11:04:41) > This patch implements the cpu_suspend cpu operations method through > the PSCI CPU_SUSPEND API. The PSCI implementation translates the idle state > index passed by the cpu_suspend core call into a valid PSCI state according to > the PSCI states initialized at boot by the PSCI suspend backend. > > Entry point is set to cpu_resume physical address, that represents the > default kernel execution address following a CPU reset. > > Idle state indices missing a DT node description are initialized to power > state standby WFI so that if called by the idle driver they provide the > default behaviour. > > Signed-off-by: Lorenzo Pieralisi Reviewed-by: Sebastian Capella Thanks! 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
Re: [PATCH V2 2/2] ARM: shmobile: r8a7791: add i2c2 bus to koelsch dt
Hello.
On 05/09/2014 09:06 AM, Wolfram Sang wrote:
+ eeprom@50 {
+ compatible = "renesas,24c02";
This is not quite right: Renesas' part is called differently, and
you're carrying the other vendor's naming onto Renesas parts. I'd
just say "24c02" (which I'll do in the Henninger board patch).
What about "generic"?
I don't know, really. However, you're right in that there should be some
vendor prefix -- I've just seen Documentation/devicetree/bindings/eeprom.txt.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen wrote:
> On 30/04/14 02:52, Tony Lindgren wrote:
>> Otherwise we can get often errors like the following and the
>> display won't come on:
>>
>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>> the output with video overlays disabled
>>
>> There are some earlier references to this issue:
>>
>> http://www.spinics.net/lists/linux-omap/msg59511.html
>> http://www.spinics.net/lists/linux-omap/msg59724.html
>
resend - my client had HTML enabled...
FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
still the reboot problem on old 600MHz OMAP 3530. Applying this patch
solved the issues. For other versions I had no chance to reproduce the
original wakup issue mentioned in old thread
[1] http://marc.info/?l=linux-omap&m=136250904607413&w=2
Andreas
> Those don't sound like the same issue, but it's hard to say. What kind
> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
> without this patch?
>
> What resolution do you have? If it's a very high resolution (say, DVI
> output to a monitor), it could just be an issue of
> not-enough-memory-bandwidth.
>
>> It seems that it's safe to set the lower values even for 3630.
>> If we can confirm that 3630 works with the higher values
>> reliably we can add further detection.
>>
>> Signed-off-by: Tony Lindgren
>> ---
>> drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/dss.c
>> b/drivers/video/fbdev/omap2/dss/dss.c
>> index d55266c..ad6561f 100644
>> --- a/drivers/video/fbdev/omap2/dss/dss.c
>> +++ b/drivers/video/fbdev/omap2/dss/dss.c
>> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats
>> __initconst = {
>> .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
>> };
>>
>> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
>> static const struct dss_features omap3630_dss_feats __initconst = {
>> - .fck_div_max= 32,
>> - .dss_fck_multiplier = 1,
>> + .fck_div_max= 16,
>> + .dss_fck_multiplier = 2,
>
> These values tell about the clock hardware, they are not settings that
> can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> and a divider with maximum value of 16.
>
> Tomi
>
>
--
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: [PATCHv3 3/3] edac: altera: Add EDAC support for Altera SDRAM
On Fri, May 09, 2014 at 03:31:53PM -0500, Thor Thayer wrote: > Yes, good point. Our hardware can't recover from Double Bit Errors so > I'll go back to the panic() in that path. I like the flexibility of > the command line parameter though... Like to panic by default when the machine is booted normally but to be able to turn off the panicking with a module parameter? If so, then you could probably implement a trivial setter called edac_mc_set_panic_on_ue() in a separate patch. Then, you call it at the end of altr_sdram_probe(). If you want to turn it off again, you do echo "0" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue Something like that... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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: [PATCHv3 3/3] edac: altera: Add EDAC support for Altera SDRAM
On Fri, May 9, 2014 at 8:52 AM, Borislav Petkov wrote: > On Thu, May 08, 2014 at 03:37:19PM -0500, Thor Thayer wrote: >> Yes. Their reasoning is that they want to retain the rights and >> warranty language with the file (just in case the COPYING file >> changes). > > Ok, thanks for checking up on this. > >> Yes. I tested using edac_core.edac_mc_panic_on_ue=1 from the command >> line and it worked fine. I'll add a comment to clarify. BTW, thanks >> for your help on that. > > Sure, but the question still remains: do you want to panic on > uncorrectable errors by default or want the user to decide? I guess this > is something you can answer for your hardware... Yes, good point. Our hardware can't recover from Double Bit Errors so I'll go back to the panic() in that path. I like the flexibility of the command line parameter though... > >> I considered using "volatile" variables, but decided against it after >> I read Documentation/volatile-considered-harmful.txt and my situation >> doesn't fit into the exemptions. Is there a better way to handle this? > > Off the top of my head, I'd first look at compiler asm output to > check what my compiler does with those writes and then take a look at > employing the ACCESS_ONCE macro or something similar where we use the > asm volatile() as an optimization stop for the compiler, among others. > > And then I'll look at asm again to make sure it does what it is supposed > to do. Something to that effect, in any case... > > HTH. The reads aren't optimized out now but I'd like to protect against future optimization changes. I implemented ACCESS_ONCE and checked the resulting asm output - it looks clean. Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- 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] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
On Fri, May 09, 2014 at 02:45:30PM +0200, Ivan T. Ivanov wrote:
[...]
> > > >
> > > > I'm thinking we should probably have a generic compatible entry as well,
> > > > "qcom,pmic-qpnp" or similar. We should still specify in the binding
> > > > that PMIC slaves specify a version-specific string as well as the
> > > > generic string. That is, a slave should have:
> > > >
> > > > compatible = "qcom,pm8841", "qcom,pmic-qpnp";
> > > >
> > > > ...in case we would ever need to differentiate in the future.
> > > >
> > > > (I recall that in a previous version I had done this, but I don't
> > > > remember why I had changed it..)
> > >
> > > I gave this some thought but came to the conclusion that there is no
> > > benefit of adding a generic compatible to a new binding. Please clarify
> > > a use-case where this would be ... useful.
> >
> > Having a generic compatible entry allows for easily supporting new PMICs
> > without having to add yet another vacuous entry in the ID table. In
> > this case I think it's perfectly acceptable given that this driver isn't
> > really defining a programming model for a specific device, but rather
> > acting much more like a bus.
> >
> > Requiring a specific PMIC listed before a generic one allows us an
> > escape hatch in the future if for some reason we need to add a quirk for
> > a specific PMIC.
>
> Is there a conclusion on this issue? I am voting for generic name :-)
> "qcom,pm-qpnp".
Josh and I have discussed this offline, and I think we have come to the
conclusion that this should be a generic driver with only a generic
binding. The current proposed name is "spmi-ext", as there is specific
functional relation to Qualcomm, PMICs or QPNP.
Further, the binding documentation should be specific to pm8[89]41 as
'mfd/pm8x41.txt', and should contain the compatibles:
- "qcom,pm8941", "spmi-ext"
- "qcom,pm8841", "spmi-ext"
This naming has been discussed to death, so a few more shed color
suggestions can't possibly hurt.
> Further complication is that several sub function drivers expect to
> runtime detect the exact version of the controller ("qcom, qpnp-iadc",
> "qcom, qpnp-vadc", "qcom, qpnp-linear-charger"). This is realized by the
> exported function of the driver "qcom, qpnp-revid". Would it be good
> idea to merge qpnp-revid and "qcom,pm-qpnp" driver?
Each block within the PMICs have--undocumented--version registers, so a
global version number is not particularly useful. A good example of
this is the ADC code [1], as you mentioned.
-Courtney
[1]
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/thermal/qpnp-adc-tm.c#n469
--
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: [PATCHv3 3/3] edac: altera: Add EDAC support for Altera SDRAM
On Thu, May 8, 2014 at 5:44 PM, Dinh Nguyen wrote:
>
> On 5/5/14 5:52 PM, ttha...@altera.com wrote:
>> From: Thor Thayer
>>
>> ---
>> v2: Use the SDRAM controller registers to calculate memory size
>> instead of the Device Tree. Update To & Cc list. Add maintainer
>> information.
>> +
>> +err2er altr_sdram_edac_driver = {
>> + .probe = altr_sdram_probe,
>> + .remove = altr_sdram_remove,
>> + .driver = {
>> + .name = "altr_sdram_edac",
>> + .of_match_table = of_match_ptr(altr_sdram_ctrl_of_match),
> I don't think you need of_match_ptr here for this platform as SOCFPGA is
> only a DT platform. All that of_match_ptr() does for a CONFIG_OF platform
> is just return the pointer.
>
> Dinh
Thanks Dinh. I'll remove it in my next submission.
>> + },
>> +};
>> +
>> +module_platform_driver(altr_sdram_edac_driver);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_AUTHOR("Altera Corporation");
>> +MODULE_DESCRIPTION("EDAC Driver for Altera SDRAM Controller");
>
--
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 RESEND 0/5] net: cpsw and mdio-gpio fixes for v3.15-final
From: Johan Hovold Date: Thu, 8 May 2014 10:09:19 +0200 > These patches against v3.15-rc4 fix a few issues in the cpsw and > mdio-gpio drivers. > > Resend with proper stable CC (git send-email still fails to parse the > #-part of the tag unless address is enclosed in <> it seems). > > Sorry about the noise. Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm/dts: am335x-evmsk enable display and lcd panel support
On Fri, May 09, 2014 at 01:49:14PM -0500, Darren Etheridge wrote:
> Add the necessary nodes to enable the LCD controller and the
> LCD panel that is attached to the Texas Instruments AM335x
> EVMSK platform. Also setup the necessary pin mux within the
> DT file to drive the LCD connector and add the correct
> pinmux settings for the lcd pins to be configured to when
> the SoC goes into sleep state for the minimum power
> consumption.
>
> For the sleep mode LCD pin settings, MUX_MODE7 is chosen as
> this corresponds to switching the pins into input GPIO's with
> an internal pulldown. Which has been determined to offer the
> lowest power solution vs leaving the pins configured in LCD
> mode.
>
> Signed-off-by: Darren Etheridge
In general:
Acked-by: Wolfram Sang
> + lcd_pins_sleep: lcd_pins_sleep {
> + pinctrl-single,pins = <
> + 0x20 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad8.lcd_data23 */
> + 0x24 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad9.lcd_data22 */
> + 0x28 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad10.lcd_data21 */
> + 0x2c (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad11.lcd_data20 */
> + 0x30 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad12.lcd_data19 */
> + 0x34 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad13.lcd_data18 */
> + 0x38 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad14.lcd_data17 */
> + 0x3c (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_ad15.lcd_data16 */
> + 0xa0 (PULL_DISABLE | MUX_MODE7) /* lcd_data0.lcd_data0
> */
> + 0xa4 (PULL_DISABLE | MUX_MODE7) /* lcd_data1.lcd_data1
> */
> + 0xa8 (PULL_DISABLE | MUX_MODE7) /* lcd_data2.lcd_data2
> */
> + 0xac (PULL_DISABLE | MUX_MODE7) /* lcd_data3.lcd_data3
> */
> + 0xb0 (PULL_DISABLE | MUX_MODE7) /* lcd_data4.lcd_data4
> */
> + 0xb4 (PULL_DISABLE | MUX_MODE7) /* lcd_data5.lcd_data5
> */
> + 0xb8 (PULL_DISABLE | MUX_MODE7) /* lcd_data6.lcd_data6
> */
> + 0xbc (PULL_DISABLE | MUX_MODE7) /* lcd_data7.lcd_data7
> */
> + 0xc0 (PULL_DISABLE | MUX_MODE7) /* lcd_data8.lcd_data8
> */
> + 0xc4 (PULL_DISABLE | MUX_MODE7) /* lcd_data9.lcd_data9
> */
> + 0xc8 (PULL_DISABLE | MUX_MODE7) /*
> lcd_data10.lcd_data10 */
> + 0xcc (PULL_DISABLE | MUX_MODE7) /*
> lcd_data11.lcd_data11 */
> + 0xd0 (PULL_DISABLE | MUX_MODE7) /*
> lcd_data12.lcd_data12 */
> + 0xd4 (PULL_DISABLE | MUX_MODE7) /*
> lcd_data13.lcd_data13 */
> + 0xd8 (PULL_DISABLE | MUX_MODE7) /*
> lcd_data14.lcd_data14 */
> + 0xdc (PULL_DISABLE | MUX_MODE7) /*
> lcd_data15.lcd_data15 */
> + 0xe0 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> lcd_vsync.lcd_vsync */
> + 0xe4 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> lcd_hsync.lcd_hsync */
> + 0xe8 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> lcd_pclk.lcd_pclk */
> + 0xec (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
> lcd_ac_bias_en.lcd_ac_bias_en */
Maybe a comment why LCD0-15 are handled differently?
signature.asc
Description: Digital signature
[PATCH] ARM: DT: apq8064: Add sdcc support via mcci driver.
From: Srinivas Kandagatla
This patch adds support to SD card controller using generic pl180 mmci driver.
This patch also adds temporary fixed regulator to get it going till the actual
regulator is mainlined.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 16 ++
arch/arm/boot/dts/qcom-apq8064.dtsi| 50 ++
2 files changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index c5fda40..ea386bd 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -4,9 +4,25 @@
model = "Qualcomm APQ8064/IFC6410";
compatible = "qcom,apq8064-ifc6410", "qcom,apq8064";
+ aliases {
+ sdcc1 = &sdcc1;
+ sdcc3 = &sdcc3;
+ };
+
soc {
serial@1664 {
status = "ok";
};
+ amba {
+ /* eMMC */
+ sdcc1: sdcc@1240 {
+ status = "okay";
+ };
+
+ /* External micro SD card */
+ sdcc3: sdcc@1218 {
+ status = "okay";
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 60b89e5..640fb1d 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -2,6 +2,7 @@
/include/ "skeleton.dtsi"
+#include
#include
/ {
@@ -147,5 +148,54 @@
#clock-cells = <1>;
#reset-cells = <1>;
};
+
+ /* Temporary fixed regulator */
+ vsdcc_fixed: vsdcc-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "SDCC Power";
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <270>;
+ regulator-always-on;
+ };
+
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ sdcc1: sdcc@1240 {
+ status = "disabled";
+ compatible = "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00051180>;
+ reg = <0x1240 0x8000>;
+ interrupts = ;
+ interrupt-names = "cmd_irq";
+ clocks = <&gcc SDC1_CLK>, <&gcc
SDC1_H_CLK>;
+ clock-names = "mclk", "apb_pclk";
+ bus-width = <8>;
+ max-frequency = <9600>;
+ non-removable;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ vmmc-supply = <&vsdcc_fixed>;
+ };
+
+ sdcc3: sdcc@1218 {
+ compatible = "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00051180>;
+ status = "disabled";
+ reg = <0x1218 0x8000>;
+ interrupts = ;
+ interrupt-names = "cmd_irq";
+ clocks = <&gcc SDC3_CLK>, <&gcc
SDC3_H_CLK>;
+ clock-names = "mclk", "apb_pclk";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <19200>;
+ no-1-8-v;
+ vmmc-supply = <&vsdcc_fixed>;
+ };
+ };
};
};
--
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: am335x-evmsk enable display and lcd panel support
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform. Also setup the necessary pin mux within the
DT file to drive the LCD connector and add the correct
pinmux settings for the lcd pins to be configured to when
the SoC goes into sleep state for the minimum power
consumption.
For the sleep mode LCD pin settings, MUX_MODE7 is chosen as
this corresponds to switching the pins into input GPIO's with
an internal pulldown. Which has been determined to offer the
lowest power solution vs leaving the pins configured in LCD
mode.
Signed-off-by: Darren Etheridge
---
v2:
Fixed up the incorrect label ordering in the pinmux comments for LCD pins
16 through 23 as reported by Wolfram Sang
arch/arm/boot/dts/am335x-evmsk.dts | 105 +
1 file changed, 105 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab23885..d99c1b1 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -138,12 +138,113 @@
"Headphone Jack", "HPLOUT",
"Headphone Jack", "HPROUT";
};
+
+ panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&lcd_pins_default>;
+ pinctrl-1 = <&lcd_pins_sleep>;
+ status = "okay";
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt= <0>;
+ dma-burst-sz = <16>;
+ bpp = <32>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+ display-timings {
+ 480x272 {
+ hactive = <480>;
+ vactive = <272>;
+ hback-porch = <43>;
+ hfront-porch= <8>;
+ hsync-len = <4>;
+ vback-porch = <12>;
+ vfront-porch= <4>;
+ vsync-len = <10>;
+ clock-frequency = <900>;
+ hsync-active= <0>;
+ vsync-active= <0>;
+ };
+ };
+ };
};
&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&gpio_keys_s0 &clkout2_pin>;
+ lcd_pins_default: lcd_pins_default {
+ pinctrl-single,pins = <
+ 0x20 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad8.lcd_data23
*/
+ 0x24 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad9.lcd_data22
*/
+ 0x28 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad10.lcd_data21
*/
+ 0x2c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad11.lcd_data20
*/
+ 0x30 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad12.lcd_data19
*/
+ 0x34 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad13.lcd_data18
*/
+ 0x38 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad14.lcd_data17
*/
+ 0x3c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad15.lcd_data16
*/
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0
*/
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1
*/
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2
*/
+ 0xac (PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3
*/
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4
*/
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5
*/
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6
*/
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7
*/
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8
*/
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9
*/
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data10.lcd_data10 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data11.lcd_data11 */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data12.lcd_data12 */
+ 0xd4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data13.lcd_data13 */
+ 0xd8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data14.lcd_data14 */
+ 0xdc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data15.lcd_data15 */
+ 0xe0 (PIN_OUTPUT | MUX_MODE0) /* lcd_vsync.lcd
Re: [PATCHv4 1/2] dt/bindings: Add the DT binding documentation for endianness
On Fri, May 09, 2014 at 06:02:55PM +0100, Mark Brown wrote:
> On Fri, May 09, 2014 at 05:32:43PM +0100, Mark Rutland wrote:
> > On Fri, May 09, 2014 at 03:04:32AM +0100, Xiubo Li wrote:
>
> > > {big,little}-endian{,-*}: these are boolean properties, if absent
> > > meaning that the CPU and the Device are in the same endianness mode.
>
> > That's not really true though. A device might usually be little-endian,
> > regardless of the endianness of a CPU. Some vendors may integrate it as
> > big-endian after a binding is added, and in the absence of a specified
> > endianness a driver is likely to assume LE.
>
> The default should be device specific rather than binding specific.
I'm taking binding here to mean the binding for a praticular device
rather than a class binding, so there's only a subtle distinction
between the two.
It's entirely possible that two developers independently come up with
bindings for something that is later realised to be the same device
(just integrated differently), for which they choose opposite defaults.
In that case the default is binding-specific rather than device
specific, though I would hope that in the vast majority of cases there
is only one binding per device, at which point the distinction is
meaningless.
Cheers,
Mark.
--
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] ARM: dts: sun6i-a31-app4-evb1.dts: Use sunxi-common-regulators.dtsi
On Fri, May 09, 2014 at 02:39:17PM +0200, Hans de Goede wrote:
> Hi,
>
> On 05/09/2014 11:32 AM, Boris BREZILLON wrote:
> >
> > On 09/05/2014 11:05, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 05/09/2014 10:55 AM, Boris BREZILLON wrote:
> >>> On 09/05/2014 10:43, Hans de Goede wrote:
> Signed-off-by: Hans de Goede
> ---
> arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
> b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
> index 270ab97..2bbf886 100644
> --- a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
> +++ b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
> @@ -13,6 +13,7 @@
>
> /dts-v1/;
> /include/ "sun6i-a31.dtsi"
> +/include/ "sunxi-common-regulators.dtsi"
>
> / {
> model = "Allwinner A31 APP4 EVB1 Evaluation Board";
> @@ -49,15 +50,8 @@
> };
>
> reg_usb1_vbus: usb1-vbus {
> -compatible = "regulator-fixed";
> -pinctrl-names = "default";
> pinctrl-0 = <&usb1_vbus_pin_a>;
> -regulator-name = "usb1-vbus";
> -regulator-min-microvolt = <500>;
> -regulator-max-microvolt = <500>;
> -enable-active-high;
> gpio = <&pio 7 27 0>;
> status = "okay";
> };
> >>> I guess we could do the same for usb1_vbus_pin_a (keep the common
> >>> definition and change the allwinner,pins property).
> >> Hmm, what we do with other boards when the pin does not match the
> >> default is change the node name to something baord specific, ie
> >> usb1_vbus_pin_app4_evb1
> >
> > Okay.
> > How did you decide which pins should be put in the default definitions
> > (the most used ones among available boards ?) ?
>
> The pins used there are used on all-most all A10 and A20 boards,
> the sun5i (A10s / A13) boards seem to not really have any standard gpio
> they use, and I have not seen enough A31 boards yet to say anything sensible.
>
> We may need to rename the standard pins to include the platform name if
> A31 also uses the same pin everywhere (but a different one from A10).
>
> > I'm not sure defining new pin states for each board is a good solution,
> > because you'll embed unneeded pin states in your DTB.
> > Anyway, this is your call :-).
> >
> >> Which is why I did not remove the common bits from the pin,
> >> I did not notice you did not use a board specific name here.
> >
> > Then I guess it should be fixed in the same series.
> > BTW, AFAIK the original patch adding support for the APP4 EVB1 board has
> > not been applied yet, so I think we can fix it send a v2 of this patch.
>
> It is already in Maxime's dt-for-3.16 tree, so it is probably better to fix
> this with a followup patch.
Actually, it's not (yet). I'll squash it into my serie.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH v3 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
The P2WI looks like an SMBus controller which only supports byte data transfers. But, it differs from standard SMBus protocol on several aspects: - it supports only one slave device, and thus drop the address field - it adds a parity bit every 8bits of data - only one read access is required to read a byte (instead of a read followed by a write access in standard SMBus protocol) - there's no Ack bit after each byte transfer This means this bus cannot be used to interface with standard SMBus devices (the only known device to support this interface is the AXP221 PMIC). Signed-off-by: Boris BREZILLON --- Changes since v2: - drop the initialization (switch from I2C to P2WI mode) part - print devm_ioremap_resource err code drivers/i2c/busses/Kconfig | 12 ++ drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-sun6i-p2wi.c | 352 3 files changed, 365 insertions(+) create mode 100644 drivers/i2c/busses/i2c-sun6i-p2wi.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index c94db1c..09bce1c 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -771,6 +771,18 @@ config I2C_STU300 This driver can also be built as a module. If so, the module will be called i2c-stu300. +config I2C_SUN6I_P2WI + tristate "Allwinner sun6i internal P2WI controller" + depends on ARCH_SUNXI + help + If you say yes to this option, support will be included for the + P2WI (Push/Pull 2 Wire Interface) controller embedded in some sunxi + SOCs. + The P2WI looks like an SMBus controller (which supports only byte + accesses), except that it only supports one slave device. + This interface is used to connect to specific PMIC devices (like the + AXP221). + config I2C_TEGRA tristate "NVIDIA Tegra internal I2C controller" depends on ARCH_TEGRA diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 18d18ff..58feeb9 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -75,6 +75,7 @@ obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o obj-$(CONFIG_I2C_ST) += i2c-st.o obj-$(CONFIG_I2C_STU300) += i2c-stu300.o +obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o obj-$(CONFIG_I2C_WMT) += i2c-wmt.o diff --git a/drivers/i2c/busses/i2c-sun6i-p2wi.c b/drivers/i2c/busses/i2c-sun6i-p2wi.c new file mode 100644 index 000..7c859ee --- /dev/null +++ b/drivers/i2c/busses/i2c-sun6i-p2wi.c @@ -0,0 +1,352 @@ +/* + * P2WI (Push-Pull Two Wire Interface) bus driver. + * + * Author: Boris BREZILLON + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +/* P2WI registers */ +#define P2WI_CTRL 0x0 +#define P2WI_CCR 0x4 +#define P2WI_INTE 0x8 +#define P2WI_INTS 0xc +#define P2WI_DADDR00x10 +#define P2WI_DADDR10x14 +#define P2WI_DLEN 0x18 +#define P2WI_DATA0 0x1c +#define P2WI_DATA1 0x20 +#define P2WI_LCR 0x24 +#define P2WI_PMCR 0x28 + +/* CTRL fields */ +#define P2WI_CTRL_START_TRANS BIT(7) +#define P2WI_CTRL_ABORT_TRANS BIT(6) +#define P2WI_CTRL_GLOBAL_INT_ENB BIT(1) +#define P2WI_CTRL_SOFT_RST BIT(0) + +/* CLK CTRL fields */ +#define P2WI_CCR_SDA_OUT_DELAY(v) (((v) & 0x7) << 8) +#define P2WI_CCR_MAX_CLK_DIV 0xff +#define P2WI_CCR_CLK_DIV(v)((v) & P2WI_CCR_MAX_CLK_DIV) + +/* STATUS fields */ +#define P2WI_INTS_TRANS_ERR_ID(v) (((v) >> 8) & 0xff) +#define P2WI_INTS_LOAD_BSY BIT(2) +#define P2WI_INTS_TRANS_ERRBIT(1) +#define P2WI_INTS_TRANS_OVER BIT(0) + +/* DATA LENGTH fields*/ +#define P2WI_DLEN_READ BIT(4) +#define P2WI_DLEN_DATA_LENGTH(v) ((v - 1) & 0x7) + +/* LINE CTRL fields*/ +#define P2WI_LCR_SCL_STATE BIT(5) +#define P2WI_LCR_SDA_STATE BIT(4) +#define P2WI_LCR_SCL_CTL BIT(3) +#define P2WI_LCR_SCL_CTL_ENBIT(2) +#define P2WI_LCR_SDA_CTL BIT(1) +#define P2WI_LCR_SDA_CTL_ENBIT(0) + +/* PMU MODE CTRL fields */ +#define P2WI_PMCR_PMU_INIT_SENDBIT(31) +#define P2WI_PMCR_PMU_INIT_DATA(v) (((v) & 0xff) << 16) +#define P2WI_PMCR_PMU_MODE_REG(v) (((v) & 0xff) << 8) +#define P2WI_PMCR_PMU_DEV_ADDR(v) ((v) & 0xff) + +#define P2WI_MAX_FREQ 6
Re: [RFC] Describing arbitrary bus mastering relationships in DT
On Fri, May 09, 2014 at 03:16:33PM +0100, Dave Martin wrote: > On Fri, May 02, 2014 at 12:17:50PM -0600, Jason Gunthorpe wrote: > > I wonder if this might be a better naming scheme, I actually don't > > really like 'slave' for this, it really only applies well to AXI style > > unidirectional busses, and any sort of message-based bus architectures > > (HT, PCI, QPI, etc) just have the concept of an initiator and target. > > > > Since initiator/target applies equally well to master/slave buses, > > that seems like better, clearer, naming. > > Sure, I wouldn't have a problem with such a suggestion. A more neutral > naming is less likely to cause confusion. > > > Using a nomenclature where > > 'reg' describes a target reachable from the CPU initiator via the > > natural DT hierarchy > > I would say, reachable from the parent device node (which implies your > statement). This is consistent with the way ePAPR describes device-to- > device DMA (even if Linux doesn't usually make a lot of use of that). Trying to simplify, but yes, that is right.. > > 'initiator' describes a non-CPU (eg 'DMA') source of ops, and > > travels via the path described to memory (which is the > > target). > > CPUs are initiators only; non-mastering devices are targets only. > > We might want some terminology to distinguish between mastering > devices and bridges, both of which act as initiators and targets. I was hoping to simplify a bit. What the kernel needs, really, is the node that initates a transaction, the node that is the ultimate completing target of that transaction and the path through all intervening (transformative or not) components. The fact a bridge is bus-level slave on one side and a bus-level master on another is not relevant to the above - a bridge is not an initiator and it is not a completing target. > We could have a concept of a "forwarder" or "gateway". But a bus > may still be a target as well as forwarder: if the bus contains some > control registers for example. There is nothing to stop "reg" and > "ranges" being present on the same node. Then the node is a 'target', and a 'bridge'. The key is to carefully define how the DT properties are used for each view-point. > > 'upstream' path direction toward the target, typically memory. > > I'm not keen on that, because we would describe the hop between / > and /memory as downstream or upstream depending on who initiates the > transaction. (I appreciate you weren't including CPUs in your > discussion, but if the termology works for the whole system it > would be a bonus). I'm just using the word 'upstream' as meaning 'moving closer to the completing target'. It isn't a great word, 'forward path' would do better to borrow a networking term. Then we have the 'return path' which, on message based busses is the path a completion message from 'completing target' travels to reach the 'initiator'. They actually can be asymmetric in some situations, but I'm not sure that is worth considering in DT, we can just assume completions travel a reverse path that hits every transformative bridge. > > 'upstream-bridge' The next hop on a path between an initiator/target > > Maybe. I'm still not sure quite why this is considered different > from the downward path through the DT, except that you consider > the cross-links in the DT to be "upward", but I considered them > "downward" (which I think are mostly equivalent approaches). > > Can you elaborate? Let us not worry about upstream/downstream and just talk about the next bridge on the 'forward path' toward the 'completing target'. > > But I would encourage you to think about the various limitations this > > still has > > - NUMA systems. How does one describe the path from each > >CPU to a target regs, and target memory? This is important for > >automatically setting affinities. > > This is a good point. > > Currently I had only been considering visibility, not affinity. > We actually have a similar problem with GIC, where there may > be multiple MSI mailboxes visible to a device, but one that is > preferred (due to being fewer hops away in the silicon, even though > the routing may be transparent). Really, the MSI affinity isn't handled by the architecture like x86? Funky. > We could describe a whole separate bus for each CPU, with links > to common interconnect subtrees downstream. But that might involve > a lot of duplication. Your example below doesn't look too bad > though. Unfortunately my example ignores the ePAPR scheme of having a /cpu node, I didn't think too hard to fix that though. > > - Peer-to-Peer DMA, this is where a non-CPU initiator speaks to a > >non-memory target, possibly through IOMMUs and what not. ie > >a graphics card in a PCI-E slot DMA'ing through a QPI bus to > >a graphics card in a PCI-E slot attached to a different socket. > > Actually, I do intend to describe that and I think I achieved it :) > > To try to keep th
Re: [PATCH v3 5/9] mtd: nand: add sunxi NAND flash controller support
On 09 May 06:47 PM, Boris BREZILLON wrote: > > Can you add some documentation about this read-back stuff? > > This has nothing to do with read-back, RB means ready/busy :-). > Hehe... right... I guess I was thinking in read/busy. See? That's why you need to document it: so it's fool-proof. -- Ezequiel GarcÃa, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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: [PATCHv4 1/2] dt/bindings: Add the DT binding documentation for endianness
On Fri, May 09, 2014 at 05:32:43PM +0100, Mark Rutland wrote:
> On Fri, May 09, 2014 at 03:04:32AM +0100, Xiubo Li wrote:
> > {big,little}-endian{,-*}: these are boolean properties, if absent
> > meaning that the CPU and the Device are in the same endianness mode.
> That's not really true though. A device might usually be little-endian,
> regardless of the endianness of a CPU. Some vendors may integrate it as
> big-endian after a binding is added, and in the absence of a specified
> endianness a driver is likely to assume LE.
The default should be device specific rather than binding specific.
signature.asc
Description: Digital signature
Re: [PATCHv4 2/2] regmap: add DT endianness binding support.
On Fri, May 09, 2014 at 03:04:33AM +0100, Xiubo Li wrote:
> For many drivers which will support rich endianness of CPU<-->Dev
> need define DT properties by itself without the binding support.
>
> The endianness using regmap:
> IndexCPU Device Endianess flag for DT bool property
>
> 1LELE -
> 2LEBE 'big-endian-{val,reg}'
> 3BEBE -
> 4BELE 'little-endian-{val,reg}'
Get rid of the CPU column. It has precisely _nothing_ to do with the
device.
If you happen to have a device that can be integrated with varying
endianness, the endianness should be described regardless of whether
this happens to be the same as the CPU endianness. The kernel can then
choose to do the right thing regardless.
Assuming LE or BE by default is sane if most implementations are one
rather than the other. Probing and figuring it out dynamically is also
fine. Assuming that it's the same as the kernel is broken in general,
and should be avoided -- those cases _require_ a *-endian property to
work if the CPU can function in either endianness.
> Please see the following documetation for detail:
> Documentation/devicetree/bindings/endianness/endianness.txt
I don't think this is sufficient. That document describes the preferred
idiom, not the meaning w.r.t. a specific binding.
[...]
> + case REGMAP_ENDIAN_REG:
> + if (of_property_read_bool(np, "big-endian-reg"))
> + *endian = REGMAP_ENDIAN_BIG;
> + else if (of_property_read_bool(np, "little-endian-reg"))
> + *endian = REGMAP_ENDIAN_LITTLE;
While this follows the guidelines you've added, context is still
required to understand precisely what this means. We need a binding
document describing what *-endian-reg means for this binding (i.e. what
does -reg cover? All registers? some? buffers?).
Imagine I added a little-endian-foo property. You'd be able to reason
that something is little endian, but you'd have no idea of precisely
what without reading documentation or code. As not everyone wants to
read several thousand lines of Linux kernel code to write a dts we
require documentation.
> + case REGMAP_ENDIAN_VAL:
> + if (of_property_read_bool(np, "big-endian-val"))
> + *endian = REGMAP_ENDIAN_BIG;
> + else if (of_property_read_bool(np, "little-endian-val"))
> + *endian = REGMAP_ENDIAN_LITTLE;
Likewise.
Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/9] mtd: nand: add sunxi NAND flash controller support
On 09/05/2014 18:03, Ezequiel Garcia wrote: > Hello Boris, > > Sorry for the review delay. > > Emilio, if you have hardware to test this, it would be nice to give > Boris some Tested-by? > > On 12 Mar 07:07 PM, Boris BREZILLON wrote: >> Add support for the sunxi NAND Flash Controller (NFC). >> >> Signed-off-by: Boris BREZILLON >> --- >> drivers/mtd/nand/Kconfig |6 + >> drivers/mtd/nand/Makefile |1 + >> drivers/mtd/nand/sunxi_nand.c | 1276 >> + >> 3 files changed, 1283 insertions(+) >> create mode 100644 drivers/mtd/nand/sunxi_nand.c >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index 90ff447..8a28c06 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -510,4 +510,10 @@ config MTD_NAND_XWAY >>Enables support for NAND Flash chips on Lantiq XWAY SoCs. NAND is >> attached >>to the External Bus Unit (EBU). >> >> +config MTD_NAND_SUNXI >> +tristate "Support for NAND on Allwinner SoCs" >> +depends on ARCH_SUNXI >> +help >> + Enables support for NAND Flash chips on Allwinner SoCs. >> + >> endif # MTD_NAND >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index 0b8a822..34f45d8 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o >> obj-$(CONFIG_MTD_NAND_GPMI_NAND)+= gpmi-nand/ >> obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o >> obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)+= bcm47xxnflash/ >> +obj-$(CONFIG_MTD_NAND_SUNXI)+= sunxi_nand.o >> >> nand-objs := nand_base.o nand_bbt.o >> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c >> new file mode 100644 >> index 000..e93cc44 >> --- /dev/null >> +++ b/drivers/mtd/nand/sunxi_nand.c >> @@ -0,0 +1,1276 @@ >> +/* >> + * Copyright (C) 2013 Boris BREZILLON >> + * >> + * Derived from: >> + * https://github.com/yuq/sunxi-nfc-mtd >> + * Copyright (C) 2013 Qiang Yu >> + * >> + * https://github.com/hno/Allwinner-Info >> + * Copyright (C) 2013 Henrik Nordström >> + * >> + * Copyright (C) 2013 Dmitriy B. >> + * Copyright (C) 2013 Sergey Lapin >> + * >> + * 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. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define NFC_REG_CTL 0x >> +#define NFC_REG_ST 0x0004 >> +#define NFC_REG_INT 0x0008 >> +#define NFC_REG_TIMING_CTL 0x000C >> +#define NFC_REG_TIMING_CFG 0x0010 >> +#define NFC_REG_ADDR_LOW0x0014 >> +#define NFC_REG_ADDR_HIGH 0x0018 >> +#define NFC_REG_SECTOR_NUM 0x001C >> +#define NFC_REG_CNT 0x0020 >> +#define NFC_REG_CMD 0x0024 >> +#define NFC_REG_RCMD_SET0x0028 >> +#define NFC_REG_WCMD_SET0x002C >> +#define NFC_REG_IO_DATA 0x0030 >> +#define NFC_REG_ECC_CTL 0x0034 >> +#define NFC_REG_ECC_ST 0x0038 >> +#define NFC_REG_DEBUG 0x003C >> +#define NFC_REG_ECC_CNT00x0040 >> +#define NFC_REG_ECC_CNT10x0044 >> +#define NFC_REG_ECC_CNT20x0048 >> +#define NFC_REG_ECC_CNT30x004c >> +#define NFC_REG_USER_DATA_BASE 0x0050 >> +#define NFC_REG_SPARE_AREA 0x00A0 >> +#define NFC_RAM0_BASE 0x0400 >> +#define NFC_RAM1_BASE 0x0800 >> + >> +/*define bit use in NFC_CTL*/ > nit: Use BIT() for these? Okay. > >> +#define NFC_EN (1 << 0) >> +#define NFC_RESET (1 << 1) >> +#define NFC_BUS_WIDYH (1 << 2) >> +#define NFC_RB_SEL (1 << 3) >> +#define NFC_CE_SEL (7 << 24) >> +#define NFC_CE_CTL (1 << 6) >> +#define NFC_CE_CTL1 (1 << 7) >> +#define NFC_PAGE_SIZE (0xf << 8) >> +#define NFC_SAM (1 << 12) >> +#define NFC_RAM_METHOD (1 << 14) >> +#define NFC_DEBUG_CTL (1 << 31) >> + >> +/*define bit use in NFC_ST*/ >> +#define NFC_RB_B2R (1 << 0) >> +#define NFC_CMD_INT_FLAG(1 << 1) >> +#define NFC_DMA_INT_FLAG(1 << 2) >> +#define NFC_CMD_FIFO_STATUS (1 << 3) >> +#define NFC_STA
Re: [PATCHv4 1/2] dt/bindings: Add the DT binding documentation for endianness
On Fri, May 09, 2014 at 03:04:32AM +0100, Xiubo Li wrote:
> Device-Tree binding for device endianness
>
> The endianness mode of CPU & Device scenarios:
> IndexCPU Device Endianness properties
>
> 1LELE -
> 2LEBE 'big-endian{,-*}'
> 3BEBE -
> 4BELE 'little-endian{,-*}'
>
> {big,little}-endian{,-*}: these are boolean properties, if absent
> meaning that the CPU and the Device are in the same endianness mode.
That's not really true though. A device might usually be little-endian,
regardless of the endianness of a CPU. Some vendors may integrate it as
big-endian after a binding is added, and in the absence of a specified
endianness a driver is likely to assume LE.
I am not keen on stating in such a generic document that the device is
the same endianness as the CPU. As some CPUs can change endianness
dynamically it's meaningless to say so.
>
> Signed-off-by: Xiubo Li
> ---
> .../devicetree/bindings/endianness/endianness.txt | 48
> ++
> 1 file changed, 48 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/endianness/endianness.txt
>
> diff --git a/Documentation/devicetree/bindings/endianness/endianness.txt
> b/Documentation/devicetree/bindings/endianness/endianness.txt
> new file mode 100644
> index 000..cc5f7f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/endianness/endianness.txt
> @@ -0,0 +1,48 @@
> +Device-Tree binding for device endianness
> +
> +The endianness mode of CPU & Device scenarios:
> +IndexCPU Device Endianness properties
> +
> +1LELE -
> +2LEBE 'big-endian{,-*}'
> +3BEBE -
> +4BELE 'little-endian{,-*}'
> +
> +For one device driver, which will run in different scenarios above
> +on different SoCs using the devicetree, we need one way to simplify
> +this.
> +
> +Required properties:
> +- {big,little}-endian{,-*}: these are boolean properties, if absent
> + meaning that the CPU and the Device are in the same endianness mode.
As stated above, I disagree with this statement.
The endianness of the CPU should have nothing to do with the device
description. The DT should not consider the endianness of the CPU at all
because this can be a dynamic property of the system. The kernel knows
which endianness the CPU is in, and in some cases the kernel will have
explicitly changed the endianness of the CPU.
All this document needs to say is that if a device may be integrated
with little-endian or big-endian registers, the preferred way to
distinguish between these cases is with a boolean big-endian or
little-endian property. Whether this is required and what the default
happens to be is entirely binding specific.
For those cases where the endianness of sub-componenets may vary (i.e. a
single regsiter may vary endianness, or a whole sub-block), then
big-endian-* and little-endian-* properties are the preferred way to
describe this.
This definitely cannot be required in general. We already have bindings
which optionally use this style of property.
Cheers,
Mark.
> +
> +Examples:
> +Scenario 1 : CPU in LE mode & device in LE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> +};
> +
> +Scenario 2 : CPU in LE mode & device in BE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> + big-endian{,-*};
> +};
> +
> +Scenario 3 : CPU in BE mode & device in BE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> +};
> +
> +Scenario 4 : CPU in BE mode & device in LE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> + little-endian{,-*};
> +};
> --
> 1.8.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: am335x-evmsk enable display and lcd panel support
Darren Etheridge wrote on Fri [2014-May-09 09:47:49 -0500]: > Tomi Valkeinen wrote on Fri [2014-May-09 14:29:02 > +0300]: > > On 06/05/14 19:10, Tony Lindgren wrote: > > > * Darren Etheridge [140422 13:39]: > > >> Add the necessary nodes to enable the LCD controller and the > > >> LCD panel that is attached to the Texas Instruments AM335x > > >> EVMSK platform. Also setup the necessary pin mux within the > > >> DT file to drive the LCD connector and add the correct > > >> pinmux settings for the lcd pins to be configured to when > > >> the SoC goes into sleep state for the minimum power > > >> consumption. > > >> > > >> For the sleep mode LCD pin settings, MUX_MODE7 is chosen as > > >> this corresponds to switching the pins into input GPIO's with > > >> an internal pulldown. Which has been determined to offer the > > >> lowest power solution vs leaving the pins configured in LCD > > >> mode. > > > > > > Probably best that Tomi queues all the panel .dts changes into > > > a separate immutable branch that I can merge too. > > > > This is not for OMAP DSS, but for the LCDC used in beaglebone, so there > > are no dependencies to any of my work. > > > > Benoit had always queued these LCDC dts patches in the past. This is > exactly the same as what had been done for AM335x-EVM and > AM335x-BeagleBone both of which are already in the mainline kernel. I > had just missed the EVMSK previously. > > Darren > There is a labeling mistake in this patch with the comments for LCD pins 16 through 23. I will correct it and send a V2. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: am335x-bone-common: Add i2c2 definition
On Fri, May 9, 2014 at 5:57 AM, Nishanth Menon wrote:
> On Fri 09 May 2014 12:56:23 AM CDT, Matt Ranostay wrote:
>> Add missing i2c2 bus define to access various cape and
>> prototype/breakout board devices.
>>
>> Signed-off-by: Matt Ranostay
>> ---
>> arch/arm/boot/dts/am335x-bone-common.dtsi | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
>> b/arch/arm/boot/dts/am335x-bone-common.dtsi
>> index 2e7d932..2aedfee 100644
>> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
>> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
>> @@ -84,6 +84,13 @@
>> >;
>> };
>>
>> + i2c2_pins: pinmux_i2c2_pins {
>> + pinctrl-single,pins = <
>> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
>> i2c2_sda.uart1_ctsn */
>> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
>> i2c2_scl.uart1_rtsn */
>
> I dont understand the comment -> i2c2_sda is being muxed to uart1_cstsn?
>
Good catch I mixed up the ordering of the comment.
>> + >;
>> + };
>> +
>> uart0_pins: pinmux_uart0_pins {
>> pinctrl-single,pins = <
>> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
>> uart0_rxd.uart0_rxd */
>> @@ -222,6 +229,15 @@
>>
>> };
>>
>> +
>> +&i2c2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c2_pins>;
>> +
>> + status = "okay";
>> + clock-frequency = <40>;
>
> How did we decide on 400KHz -> do all all i2c2 devices on ALL capes
> work in full speed? OR should we consider a conservative 100KHz?
>
Probably a better plan.
Will submit v2 this weekend.
>> +};
>> +
>> /include/ "tps65217.dtsi"
>>
>> &tps {
>
>
> --
> Regards,
> Nishanth Menon
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] edac: Fix MC scrub mode comparsion bug for correctable error
Hi, >> This patch fixes the MC scrub mode comparsion bug by replacing >> '&' with '=='. The MC structure field scrub_mode is integer >> type - not bit field. >> >> Signed-off-by: Loc Ho > > Applied, thanks. If I should need to submit future version of the X-Gene EDAC driver, I will not include this patch. -Loc -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/9] mtd: nand: add sunxi NAND flash controller support
Hello Boris, Sorry for the review delay. Emilio, if you have hardware to test this, it would be nice to give Boris some Tested-by? On 12 Mar 07:07 PM, Boris BREZILLON wrote: > Add support for the sunxi NAND Flash Controller (NFC). > > Signed-off-by: Boris BREZILLON > --- > drivers/mtd/nand/Kconfig |6 + > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/sunxi_nand.c | 1276 > + > 3 files changed, 1283 insertions(+) > create mode 100644 drivers/mtd/nand/sunxi_nand.c > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 90ff447..8a28c06 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -510,4 +510,10 @@ config MTD_NAND_XWAY > Enables support for NAND Flash chips on Lantiq XWAY SoCs. NAND is > attached > to the External Bus Unit (EBU). > > +config MTD_NAND_SUNXI > + tristate "Support for NAND on Allwinner SoCs" > + depends on ARCH_SUNXI > + help > + Enables support for NAND Flash chips on Allwinner SoCs. > + > endif # MTD_NAND > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index 0b8a822..34f45d8 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o > obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ > obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o > obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ > +obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o > > nand-objs := nand_base.o nand_bbt.o > diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c > new file mode 100644 > index 000..e93cc44 > --- /dev/null > +++ b/drivers/mtd/nand/sunxi_nand.c > @@ -0,0 +1,1276 @@ > +/* > + * Copyright (C) 2013 Boris BREZILLON > + * > + * Derived from: > + * https://github.com/yuq/sunxi-nfc-mtd > + * Copyright (C) 2013 Qiang Yu > + * > + * https://github.com/hno/Allwinner-Info > + * Copyright (C) 2013 Henrik Nordström > + * > + * Copyright (C) 2013 Dmitriy B. > + * Copyright (C) 2013 Sergey Lapin > + * > + * 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. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define NFC_REG_CTL 0x > +#define NFC_REG_ST 0x0004 > +#define NFC_REG_INT 0x0008 > +#define NFC_REG_TIMING_CTL 0x000C > +#define NFC_REG_TIMING_CFG 0x0010 > +#define NFC_REG_ADDR_LOW 0x0014 > +#define NFC_REG_ADDR_HIGH0x0018 > +#define NFC_REG_SECTOR_NUM 0x001C > +#define NFC_REG_CNT 0x0020 > +#define NFC_REG_CMD 0x0024 > +#define NFC_REG_RCMD_SET 0x0028 > +#define NFC_REG_WCMD_SET 0x002C > +#define NFC_REG_IO_DATA 0x0030 > +#define NFC_REG_ECC_CTL 0x0034 > +#define NFC_REG_ECC_ST 0x0038 > +#define NFC_REG_DEBUG0x003C > +#define NFC_REG_ECC_CNT0 0x0040 > +#define NFC_REG_ECC_CNT1 0x0044 > +#define NFC_REG_ECC_CNT2 0x0048 > +#define NFC_REG_ECC_CNT3 0x004c > +#define NFC_REG_USER_DATA_BASE 0x0050 > +#define NFC_REG_SPARE_AREA 0x00A0 > +#define NFC_RAM0_BASE0x0400 > +#define NFC_RAM1_BASE0x0800 > + > +/*define bit use in NFC_CTL*/ nit: Use BIT() for these? > +#define NFC_EN (1 << 0) > +#define NFC_RESET(1 << 1) > +#define NFC_BUS_WIDYH(1 << 2) > +#define NFC_RB_SEL (1 << 3) > +#define NFC_CE_SEL (7 << 24) > +#define NFC_CE_CTL (1 << 6) > +#define NFC_CE_CTL1 (1 << 7) > +#define NFC_PAGE_SIZE(0xf << 8) > +#define NFC_SAM (1 << 12) > +#define NFC_RAM_METHOD (1 << 14) > +#define NFC_DEBUG_CTL(1 << 31) > + > +/*define bit use in NFC_ST*/ > +#define NFC_RB_B2R (1 << 0) > +#define NFC_CMD_INT_FLAG (1 << 1) > +#define NFC_DMA_INT_FLAG (1 << 2) > +#define NFC_CMD_FIFO_STATUS (1 << 3) > +#define NFC_STA (1 << 4) > +#define NFC_NATCH_INT_FLAG (1 << 5) > +#define NFC_RB_STATE0(1 << 8) > +#define NFC_RB_STA
Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
* Tomi Valkeinen [140509 02:34]: > On 05/05/14 21:41, Tony Lindgren wrote: > > * Tony Lindgren [140429 16:53]: > >> Hi all, > >> > >> Here are few patches to add devicetree support for panel ls037v7dw01 > >> that's found on many omap3 boards. They seem to be often mis-configured > >> as various panel dpi entries, but really should be move to use panel > >> ls037v7dw01 instead. This panel is found at least on the omap3 sdp, > >> ldp, omap3 evm and few other development boards. > > > > Tomi, assuming no more comments, do you want to pick up the first > > three patches of this series? I can queue the .dts changes or you > > can also set up a separate .dts changes branch for DSS that I can > > merge in too. > > If it's all the same to you, I'd like to collect all display related > arch/arm/ patches into my tree, and I'll send you a merge request when > it's stable. > > I already have OMAP5 and AM43xx stuff there. Yes that works well for me. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: sdhci: add a driver for Berlin SoCs
On 16/04/14 13:40, Antoine Ténart wrote:
Add a Driver to support the SDHCI controller of the Marvell Berlin SoCs.
This controller supports 3 sockets.
[snip]
+
+static struct sdhci_ops sdhci_berlin_ops = {
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+};
+
+static struct sdhci_pltfm_data sdhci_berlin2_pdata = {
+ .quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
+ SDHCI_QUIRK_BROKEN_ADMA |
+ SDHCI_QUIRK_BROKEN_TIMEOUT_VAL,
+ .ops = &sdhci_berlin_ops,
+};
+
+static struct sdhci_pltfm_data sdhci_berlin2q_pdata = {
+ .quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
+ SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
+ SDHCI_QUIRK_BROKEN_TIMEOUT_VAL,
+ .ops = &sdhci_berlin_ops,
+};
+
+static const struct of_device_id sdhci_berlin_of_match_table[] = {
+ {
+ .compatible = "marvell,berlin2-sdhci",
+ .data = &sdhci_berlin2_pdata,
+ },
+ {
+ .compatible = "marvell,berlin2cd-sdhci",
+ .data = &sdhci_berlin2_pdata,
+ },
+ {
+ .compatible = "marvell,berlin2q-sdhci",
+ .data = &sdhci_berlin2q_pdata,
+ },
+ {}
I think the hardware names should be used instead of the
quirks the hardware has (broken wp / broken adma)
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen [140509 00:24]:
> On 09/05/14 02:33, Tony Lindgren wrote:
> > +Example when connected to a omap2+ based device:
> > +
> > + lcd0: display {
> > + compatible = "sharp,ls037v7dw01";
> > + power-supply = <&lcd_3v3>;
> > + enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;/* gpio152, lcd
> > INI */
> > + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd
> > RESB */
> > + mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH/* gpio154, lcd
> > MO */
> > + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd
> > LR */
> > + &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd
> > UD */
> > +
> > + panel-timing {
> > + clock-frequency = <1920>;
> > + hback-porch = <28>;
> > + hactive = <480>;
> > + hfront-porch = <1>;
> > + hsync-len = <2>;
> > + vback-porch = <1>;
> > + vactive = <640>;
> > + vfront-porch = <1>;
> > + vsync-len = <1>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
> > + de-active = <1>;
> > + pixelclk-active = <1>;
> > + };
>
> I don't think we should define panel-timing here. We know it's
> sharp,ls037v7dw01, so the driver knows the video timings. Also, if we
> would extend the driver to support both resolution modes, it needs to
> support two different timings, so the above doesn't work in that case
> either.
OK. It seems we can have at least two different timings for this panel,
the VGA timing above and the QVGA timings that LDP uses that are listed
in the .dts changes.
> Although if the MO gpio is not controlled by the driver, we should tell
> the driver whether that gpio is high or low.
What do you have in mind for telling that? We should also tell the
orientation of the panel:
EVM VGA omapfb.rotate=3
LDP QVGAomapfb.rotate=0
Do you have something in mind for that?
> At the moment our display drivers are OMAP specific, and for that reason
> we should prefix the compatible strings with "omapdss,". For example,
> drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
>
> { .compatible = "omapdss,panel-dsi-cm", },
>
> But we should still have the right compatible string in the .dts, so we
> convert the compatible name in arch/arm/mach-omap2/display.c, with
> 'dss_compat_conv_list' array, to which this panel's name should be added.
Oh so what do you want to have in the .dts file then?
Regards,
Tony
--
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/5] arm64: dts: APM X-Gene SoC Ethernet device tree nodes
Iyappan Subramanian writes: > Hi Mark, > > Thanks for the review comment and I apologize for not replying sooner. > > We are completely redesigning the ethernet driver to make it simple > and cleaner and will be posted shortly. Hi Iyappan, Did this ever get posted? I'm trying to get a close-to-HEAD kernel up and running on our APM hardware but have run afoul of the differences between the latest XGENE_MBOX patch set and the older NET_XGENE patch set. If it's not long away then I shall wait a bit otherwise I'll see if the missing bits can be forward ported from our working 3.8.0-mustang_sw_1.08.12-beta_rc.jcm15 kernel (purely for testing purposes). Do you have a public tree where your latest kernels are visible? Cheers, -- Alex Bennée QEMU/KVM Hacker for Linaro -- 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 1/9] mtd: nand: define struct nand_timings
On 08/05/2014 16:29, Lee Jones wrote:
>>> Define a struct containing the standard NAND timings as described in NAND
>>> datasheets.
>>>
>>> Signed-off-by: Boris BREZILLON
>>> ---
>>> include/linux/mtd/nand.h | 49
>>> ++
>>> 1 file changed, 49 insertions(+)
>>>
>>> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
>>> index 389b3c5..f3ff3a3 100644
>>> --- a/include/linux/mtd/nand.h
>>> +++ b/include/linux/mtd/nand.h
> [...]
>
>>> + * Parameters)
>> Please document the units for these fields here. It looks like you're
>> using picoseconds.
> Can't we leave this open to interpretation? For instance, it's more
> convenient for our driver to handle these as nano second values.
>
>>> + *
>>> + */
>>> +
>> Extra blank line.
>>
>>> +struct nand_sdr_timings {
>>> + u32 tALH_min;
>>> + u32 tADL_min;
>>> + u32 tALS_min;
>>> + u32 tAR_min;
>>> + u32 tCEA_max;
>>> + u32 tCEH_min;
>>> + u32 tCH_min;
>>> + u32 tCHZ_max;
>>> + u32 tCLH_min;
>>> + u32 tCLR_min;
>>> + u32 tCLS_min;
>>> + u32 tCOH_min;
>>> + u32 tCS_min;
> u32 tCSD_min;
This is related to ddr2 timings, and this structure only define sdr
related timings.
>>> + u32 tDH_min;
>>> + u32 tDS_min;
>>> + u32 tFEAT_max;
>>> + u32 tIR_min;
>>> + u32 tITC_max;
> u32 tR_max;
Actually this one cannot be retrieved from the ONFI timing mode, you'll
have to read bytes 137 and 138 in the parameter page.
Hence I got rid of it in the first place. Then I considered adding all
those missing timings in another structure (see [1]).
I noticed you posted something similar on the MTD mailing list (and
Lucas was waiting for the feature too).
Could we work together to propose something that fulfills all our needs ?
Here's what I need:
- get detailled timings to be able to configure the sunxi NAND
controller appropriately
- a way to get these timings on non-ONFi NANDs (the proposed solution is
exposing the closest supported ONFI timing mode in the NAND chip DT
node, but I'm open to any new proposal).
Best Regards,
Boris
[1] http://lists.infradead.org/pipermail/linux-mtd/2014-March/052525.html
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
* Tomi Valkeinen [140509 00:08]:
> On 09/05/14 02:36, Tony Lindgren wrote:
>
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> > @@ -0,0 +1,82 @@
> > +/*
> > + * Common file for omap dpi panels with QVGA and reset pins
> > + *
> > + * Note that the board specifc DTS file needs to specify
> > + * at minimum the GPIO enable-gpios for display, and
> > + * gpios for gpio-backlight.
> > + */
>
> This looks very board specific to me... The regulator and the use of
> mcspi1 depend on the board, so this file can't be used on just any omap
> board with the same panel. And this can (probably) only be used on
> boards with a single display. Do those boards have tv-out?
Yes there's also TV out and DVI on omap3-evm, LDP just has DVI.
It seems that all omap3 boards using this are pretty much wired
the same way.
> So I have nothing against having common files, but shouldn't this be
> named something more specific? If the boards involved are TI's OMAP3
> development boards, maybe this should be something like...
> omap3-ti-dev-panel-sharp-ls037v7dw01.dtsi. Well, that's a quite long one.
Yeah let's use omap3-panel-sharp-ls037v7dw01.dtsi. Looking at the
legacy board files that should cover quite a few of them.
I guess it might also work on 2430sdp, but let's assume omap3
for now.
> > +/ {
> > + aliases {
> > + display0 = &lcd0;
> > + };
> > +
> > + backlight0: backlight {
> > + compatible = "gpio-backlight";
> > + };
> > +
> > + /* 3.3V GPIO controlled regulator for LCD_ENVDD */
> > + lcd_3v3: regulator-lcd-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "lcd_3v3";
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> > + startup-delay-us = <7>;
> > + regulator-always-on;
>
> Why always-on?
Oops, yeah that should not be there. The GPIO is board specific.
Regards,
Tony
--
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] mmc: core: Add DT bindings for card detect debounce time
Provide an option to get CD debounce time from DT
Signed-off-by: Balaji T K
---
Documentation/devicetree/bindings/mmc/mmc.txt |1 +
drivers/mmc/core/host.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 9dce540..fae590b 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -17,6 +17,7 @@ Optional properties:
- bus-width: Number of data lines, can be <1>, <4>, or <8>. The default
will be <1> if the property is absent.
- wp-gpios: Specify GPIOs for write protection, see gpio binding
+- cd-debounce-us: debounce time in microseconds for card detect gpio.
- cd-inverted: when present, polarity on the CD line is inverted. See the note
below for the case, when a GPIO is used for the CD line
- wp-inverted: when present, polarity on the WP line is inverted. See the note
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index fdea825..59cd3a0 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -313,6 +313,7 @@ int mmc_of_parse(struct mmc_host *host)
bool explicit_inv_wp, gpio_inv_wp = false;
enum of_gpio_flags flags;
int len, ret, gpio;
+ unsigned int debounce;
if (!host->parent || !host->parent->of_node)
return 0;
@@ -367,6 +368,9 @@ int mmc_of_parse(struct mmc_host *host)
if (of_find_property(np, "broken-cd", &len))
host->caps |= MMC_CAP_NEEDS_POLL;
+ if (of_property_read_u32(np, "cd-debounce-us", &debounce) < 0)
+ debounce = 0;
+
gpio = of_get_named_gpio_flags(np, "cd-gpios", 0, &flags);
if (gpio == -EPROBE_DEFER)
return gpio;
@@ -374,7 +378,7 @@ int mmc_of_parse(struct mmc_host *host)
if (!(flags & OF_GPIO_ACTIVE_LOW))
gpio_inv_cd = true;
- ret = mmc_gpio_request_cd(host, gpio, 0);
+ ret = mmc_gpio_request_cd(host, gpio, debounce);
if (ret < 0) {
dev_err(host->parent,
"Failed to request CD GPIO #%d: %d!\n",
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen [140509 01:31]: > On 09/05/14 02:33, Tony Lindgren wrote: > > * Tony Lindgren [140507 11:00]: > >> * Tomi Valkeinen [140507 09:03]: > >>> On 07/05/14 18:03, Tony Lindgren wrote: > > BTW, I'm also personally fine with all five gpios showing in a single > gpios property, I'm not too exited about naming anything in DT.. > >>> > >>> I don't have a strong opinion here. I don't have much experience with > >>> DT, especially with making bindings compatible with other ones. > >>> > >>> I'd just forget the simple-panel, and have single gpio array. > >> > >> Well if it's a don't care flag for both of us, let's try to use > >> the existing standard for simple-panel.txt and add mode-gpios > >> property. I'll post a patch for that. > > > > Here's an updated version using enable-gpios, reset-gpios and > > mode-gpios. So it follows simple-panel.txt and adds mode-gpios > > that's currently specific to this panel only. > > > > Also updated for -EPROBE_DEFER handling, tested that by changing > > one of the GPIOs to be a twl4030 GPIO. > > To speed things up a bit, I made the changes I suggested. Compile tested > only. OK thanks did not get the penguin with it so need to look at it a bit more. Regards, Tony -- 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] serial: uart: add hw flow control support configuration
>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Thursday, May 01, 2014 3:05 PM
>To: devicetree@vger.kernel.org; linux-...@vger.kernel.org;
>linux-ker...@vger.kernel.org;
>linux-ser...@vger.kernel.org
>Cc: Karicheri, Muralidharan; Rob Herring; Pawel Moll; Mark Rutland; Ian
>Campbell; Kumar
>Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby; Shilimkar, Santosh
>Subject: [PATCH v2] serial: uart: add hw flow control support configuration
>
>8250 uart driver currently supports only software assisted hw flow control.
>The software
>assisted hw flow control maintains a hw_stopped flag in the tty structure to
>stop and start
>transmission and use modem status interrupt for the event to drive the
>handshake signals.
>This is not needed if hw has flow control capabilities. This patch adds a DT
>attribute for
>enabling hw flow control for a uart port. Also skip stop and start if this
>flag is present in flag
>field of the port structure.
>
>Signed-off-by: Murali Karicheri
>
>CC: Rob Herring
>CC: Pawel Moll
>CC: Mark Rutland
>CC: Ian Campbell
>CC: Kumar Gala
>CC: Randy Dunlap
>CC: Greg Kroah-Hartman
>CC: Jiri Slaby
>CC: Santosh Shilimkar
>---
> .../devicetree/bindings/serial/of-serial.txt |1 +
> drivers/tty/serial/8250/8250_core.c|6 --
> drivers/tty/serial/of_serial.c |4
> drivers/tty/serial/serial_core.c | 12 +---
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
>b/Documentation/devicetree/bindings/serial/of-serial.txt
>index 1928a3e..7705477 100644
>--- a/Documentation/devicetree/bindings/serial/of-serial.txt
>+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>@@ -37,6 +37,7 @@ Optional properties:
> - auto-flow-control: one way to enable automatic flow control support. The
> driver is allowed to detect support for the capability even without this
> property.
>+- has-hw-flow-control: the hardware has flow control capability.
>
> Example:
>
>diff --git a/drivers/tty/serial/8250/8250_core.c
>b/drivers/tty/serial/8250/8250_core.c
>index 0e1bf88..b69aff2 100644
>--- a/drivers/tty/serial/8250/8250_core.c
>+++ b/drivers/tty/serial/8250/8250_core.c
>@@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, struct
>ktermios *termios,
>* the trigger, or the MCR RTS bit is cleared. In the case where
>* the remote UART is not using CTS auto flow control, we must
>* have sufficient FIFO entries for the latency of the remote
>- * UART to respond. IOW, at least 32 bytes of FIFO.
>+ * UART to respond. IOW, at least 32 bytes of FIFO. Also enable
>+ * AFE if hw flow control is supported
>*/
>- if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
>+ if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32)) ||
>+ (port->flags & UPF_HARD_FLOW)) {
> up->mcr &= ~UART_MCR_AFE;
> if (termios->c_cflag & CRTSCTS)
> up->mcr |= UART_MCR_AFE;
>diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
>index
>9924660..77ec6a1 100644
>--- a/drivers/tty/serial/of_serial.c
>+++ b/drivers/tty/serial/of_serial.c
>@@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct
>platform_device *ofdev)
> "auto-flow-control"))
> port8250.capabilities |= UART_CAP_AFE;
>
>+ if (of_property_read_bool(ofdev->dev.of_node,
>+"has-hw-flow-control"))
>+ port8250.port.flags |= UPF_HARD_FLOW;
>+
> ret = serial8250_register_8250_port(&port8250);
> break;
> }
>diff --git a/drivers/tty/serial/serial_core.c
>b/drivers/tty/serial/serial_core.c
>index b68550d..851707a 100644
>--- a/drivers/tty/serial/serial_core.c
>+++ b/drivers/tty/serial/serial_core.c
>@@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty,
>struct
>uart_state *state,
> if (tty->termios.c_cflag & CBAUD)
> uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
> }
>-
>- if (tty_port_cts_enabled(port)) {
>+ /*
>+ * if hw support flow control without software intervention,
>+ * then skip the below check
>+ */
>+ if (tty_port_cts_enabled(port) &&
>+ !(uport->flags & UPF_HARD_FLOW)) {
> spin_lock_irq(&uport->lock);
> if (!(uport->ops->get_mctrl(uport) & TIOCM_CTS))
> tty->hw_stopped = 1;
>@@ -2772,7 +2776,9 @@ void uart_handle_cts_change(struct uart_port *uport,
>unsigned
>int status)
>
> uport->icount.cts++;
>
>- if (tty_port_cts_enabled(port)) {
>+ /* skip below code if the hw flow control is
Re: [PATCH] ARM: dts: at91-sama5d3_xplained: add the regulator device node
On 22/04/2014 03:37, Yang, Wenyou :
> Hi,
>
>> -Original Message-
>> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
>> Sent: Monday, April 21, 2014 8:22 PM
>> To: Yang, Wenyou
>> Cc: devicetree@vger.kernel.org; Ferre, Nicolas; linux-
>> ker...@vger.kernel.org; robh...@kernel.org; broo...@kernel.org; linux-
>> arm-ker...@lists.infradead.org
>> Subject: Re: [PATCH] ARM: dts: at91-sama5d3_xplained: add the regulator
>> device node
>>
>> On 21/04/2014 at 11:54:43 +0200, Alexandre Belloni wrote :
>>> Hi,
>>>
>>> On 21/04/2014 at 12:29:07 +0800, Wenyou Yang wrote :
+
+ vddana_reg: LDO_REG2 {
+ regulator-name =
"VDDANA";
+ regulator-min-microvolt
=
>> <330>;
+ regulator-max-microvolt
=
>> <330>;
+ regulator-always-on;
>>>
>>> I'm pretty sure that one is not always on as you actually have to
>>> configure it to get any voltage. Are you sure you want to set the
>>> regulator-always-on property here ?
>>>
>>
>> Just to clarify my though, wouldn't it be better to make the ADC driver
>> handle that regulator instead of using regulator-always-on ?
> Yes, you are right.
> It should not use regulator-always-on property for this regulator.
> It is ADC driver and ISI driver to handle it(The ISI takes PCK for clock).
Hi Wenyou and Alexandre,
After talking to our system engineers, it not usual to avoid to power
the VDDANA rail. In fact it will prevent you to use all the pads that
are powered by VDDANA: PD20-PD31. Moreover, even if you do not activate
the ADC output on these lines you won't be able to use them as plain
GPIO... (Cf. package and pinout section of the datasheet).
As the ADVREF pin of the SoC is connected to the VDDANA on this board
(even if this default configuration can be modified with a soldering
iron), we have to note that we may consume a little bit more power.
But still, I would recommend to keep the "regulator-always-on" property
on this node. Do you agree and allow me to take your first revision of
the patch?
Bye,
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] net:Add basic DWC Ethernet QoS Driver
On 2014-05-08 at 14:50:14 +0200, Andreas Irestal
wrote:
> This is an early version of a driver for the Synopsys DWC Ethernet QoS IP
> version 4. Unfortunately, version 4.00a and onwards of this IP is totally
> different from earlier versions used in the STMicroelectronics drivers. Both
> functionality and registers are different. As this is my first network driver
> I am submitting an RFC to catch design flaws and bad coding standards at an
> early stage. Also, others looking at this IP could hopefully be helped by this
> early code.
>
> The driver is quite inefficient, yet still functional (Gbit only) and uses a
> polling-driven TX-approach. For the RX side NAPI and interrupts are used.
> There are still quite a lot of work to do. Link handling, more robust
> error-handling, HW Checksumming, scatter-gather and TCP Segmentation and
> checksum offloading to name a few.
>
> All code has been developed and tested using an FPGA implementation of the IP,
> with an ARM Cortex A9 as the main CPU, running Linux 3.13.
>
> Signed-off-by: Andreas Irestaal
> ---
> drivers/net/ethernet/Kconfig|1 +
> drivers/net/ethernet/Makefile |1 +
> drivers/net/ethernet/synopsys/Kconfig | 24 +
> drivers/net/ethernet/synopsys/Makefile |5 +
> drivers/net/ethernet/synopsys/dwc_eth_qos.c | 706
> +++
> drivers/net/ethernet/synopsys/dwc_eth_qos.h | 308
> 6 files changed, 1045 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/ethernet/synopsys/Kconfig
> create mode 100644 drivers/net/ethernet/synopsys/Makefile
> create mode 100644 drivers/net/ethernet/synopsys/dwc_eth_qos.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc_eth_qos.h
[...]
> diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c
> b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
> new file mode 100644
> index 000..20b1a9e
> --- /dev/null
> +++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
> @@ -0,0 +1,706 @@
[...]
> +struct net_local {
> + void __iomem *baseaddr;
> + struct clk *phy_ref_clk;
> + struct clk *apb_pclk;
> +
> + struct net_device *ndev;
> + struct platform_device *pdev;
> +
> + volatile struct dwc_eth_qos_txdesc *tx_descs;
> + volatile struct dwc_eth_qos_rxdesc *rx_descs;
> +
> + void *tx_buf;
> +
> + struct ring_info *rx_skb;
> +
> + dma_addr_t tx_descs_addr;
> + dma_addr_t rx_descs_addr;
> +
> + u32 next_tx;
> + u32 next_rx;
> +
> + struct napi_struct napi;
> +
> + struct net_device_stats stats;
You don't need a private copy of struct net_device_stats, just use the
one from struct net_device. It looks like the driver is not returning
these stats currently anyway. If you use ndev->stats, they will be
picked up by dev_get_stats() and i.e. show up in ifconfig output.
> + spinlock_t rx_lock;
> +};
> +
> +/* Allocate DMA helper structure at position given by index */
> +static void dwceqos_alloc_rxring_desc(struct net_local *lp, int index)
> +{
> + struct sk_buff *new_skb;
> + u32 new_skb_baddr = 0;
> + new_skb = netdev_alloc_skb(lp->ndev, DWCEQOS_RX_BUF_SIZE);
> + if (!new_skb) {
> + dev_err(&lp->ndev->dev, "alloc_skb error for desc %d\n",
> index);
> + goto out;
> + }
> +
> + /* Get dma handle of skb->data */
> + new_skb_baddr = (u32)dma_map_single(lp->ndev->dev.parent,
> + new_skb->data, DWCEQOS_RX_BUF_SIZE, DMA_FROM_DEVICE);
> + if (dma_mapping_error(lp->ndev->dev.parent, new_skb_baddr)) {
> + dev_err(&lp->pdev->dev, "DMA map error\n");
> + dev_kfree_skb(new_skb);
> + new_skb = NULL;
> + }
> +out:
> + lp->rx_skb[index].skb = new_skb;
> + lp->rx_skb[index].mapping = new_skb_baddr;
> + lp->rx_skb[index].len = DWCEQOS_RX_BUF_SIZE;
> +
> + return;
> +}
> +
> +static void dwceqos_mtl_init(struct net_local *lp)
> +{
> + dwceqos_write(lp->baseaddr, DWCEQOS_MTL_OP_MODE, 0x0060);
> +}
> +
> +static void dwceqos_mtl_tx_init(struct net_local *lp)
> +{
> + dwceqos_write(lp->baseaddr, DWCEQOS_MTL_TXQ0_OP_MODE,
> + DWCEQOS_MTL_TXQ_EN);
> +}
> +
> +static void dwceqos_mtl_rx_init(struct net_local *lp)
> +{
> + dwceqos_write(lp->baseaddr, DWCEQOS_MTL_RXQ0_OP_MODE,
> + DWCEQOS_MTL_RXQ_RQS256 | DWCEQOS_MTL_RXQ_DIS_TCP_EF |
> + DWCEQOS_MTL_RXQ_FEP | DWCEQOS_MTL_RXQ_FUP |
> + DWCEQOS_MTL_RXQ_RTC32);
> +}
> +
> +static void dwceqos_mac_rx_init(struct net_local *lp)
> +{
> + u32 val;
> + dwceqos_write(lp->baseaddr, DWCEQOS_MAC_RXQ_CTRL0, 2);
> + val = DWCEQOS_MAC_PKT_FILTER_RX_ALL | DWCEQOS_MAC_PKT_FILTER_PCF_ALL |
> + DWCEQOS_MAC_PKT_FILTER_PROMISCUOUS;
> + dwceqos_write(lp->baseaddr, DWCEQOS_MAC_PKT_FILTER, val);
> +}
> +
> +static int dwceqos_mac_enable(struct net_l
Re: [PATCH v2 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
Hi,
On 05/09/2014 04:50 PM, Boris BREZILLON wrote:
>
> On 09/05/2014 16:31, Maxime Ripard wrote:
>> Hi Boris,
>>
>> On Wed, May 07, 2014 at 07:58:35PM +0200, Boris BREZILLON wrote:
>>
> [...]
>> +
>> +r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +p2wi->regs = devm_ioremap_resource(dev, r);
>> +if (IS_ERR(p2wi->regs)) {
>> +dev_err(dev, "failed to retrieve iomem resource\n");
>> +return PTR_ERR(p2wi->regs);
>> You seem to be returning the error code in the next error messages. It
>> would probably be a good idea to put it there too.
>
> Yes, I'll print the err code in the error message.
>
>>
>>> + }
>>> +
>>> + snprintf(p2wi->adapter.name, sizeof(p2wi->adapter.name), pdev->name);
>>> + ret = platform_get_irq(pdev, 0);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to retrieve irq: %d\n", ret);
>>> + return ret;
>>> + }
>>> + p2wi->irq = ret;
>>> +
>>> + p2wi->clk = devm_clk_get(dev, NULL);
>>> + if (IS_ERR(p2wi->clk)) {
>>> + ret = PTR_ERR(p2wi->clk);
>>> + dev_err(dev, "failed to retrieve clk: %d\n",
>>> + ret);
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_prepare_enable(p2wi->clk);
>>> + if (ret) {
>>> + dev_err(dev, "failed to enable clk: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + parent_clk_freq = clk_get_rate(p2wi->clk);
>>> +
>>> + p2wi->rstc = devm_reset_control_get(dev, NULL);
>>> + if (IS_ERR(p2wi->rstc)) {
>>> + ret = PTR_ERR(p2wi->rstc);
>>> + dev_err(dev, "failed to retrieve reset controller: %d\n",
>>> + ret);
>>> + goto err_clk_disable;
>>> + }
>>> +
>>> + ret = reset_control_deassert(p2wi->rstc);
>>> + if (ret) {
>>> + dev_err(dev, "failed to deassert reset line: %d\n",
>>> + ret);
>>> + goto err_clk_disable;
>>> + }
>>> +
>>> + init_completion(&p2wi->complete);
>>> + p2wi->adapter.dev.parent = dev;
>>> + p2wi->adapter.algo = &p2wi_algo;
>>> + p2wi->adapter.owner = THIS_MODULE;
>>> + p2wi->adapter.dev.of_node = pdev->dev.of_node;
>>> + platform_set_drvdata(pdev, p2wi);
>>> + i2c_set_adapdata(&p2wi->adapter, p2wi);
>>> +
>>> + ret = devm_request_irq(dev, p2wi->irq, p2wi_interrupt, 0, pdev->name,
>>> + p2wi);
>>> + if (ret) {
>>> + dev_err(dev, "can't register interrupt handler irq%d: %d\n",
>>> + p2wi->irq, ret);
>>> + goto err_reset_assert;
>>> + }
>>> +
>>> + writel(P2WI_CTRL_SOFT_RST, p2wi->regs + P2WI_CTRL);
>>> +
>>> + clk_div = parent_clk_freq / clk_freq;
>>> + if (!clk_div) {
>>> + dev_warn(dev,
>>> +"clock-frequency is too high, setting it to %lu Hz\n",
>>> +parent_clk_freq);
>>> + clk_div = 1;
>>> + } else if (clk_div > P2WI_CCR_MAX_CLK_DIV) {
>>> + dev_warn(dev,
>>> +"clock-frequency is too low, setting it to %lu Hz\n",
>>> +parent_clk_freq / P2WI_CCR_MAX_CLK_DIV);
>>> + clk_div = P2WI_CCR_MAX_CLK_DIV;
>>> + }
>>> +
>>> + writel(P2WI_CCR_SDA_OUT_DELAY(1) | P2WI_CCR_CLK_DIV(clk_div),
>>> + p2wi->regs + P2WI_CCR);
>>> +
>>> + if (p2wi_mode_reg >= 0 && p2wi_mode_val >= 0) {
>>> + writel(P2WI_PMCR_PMU_INIT_SEND |
>>> + P2WI_PMCR_PMU_MODE_REG(p2wi_mode_reg) |
>>> + P2WI_PMCR_PMU_INIT_DATA(p2wi_mode_val) |
>>> + P2WI_PMCR_PMU_DEV_ADDR(p2wi->slave_addr),
>>> + p2wi->regs + P2WI_PMCR);
>>> +
>>> + while (readl(p2wi->regs + P2WI_PMCR) &
>>> + P2WI_PMCR_PMU_INIT_SEND)
>>> + cpu_relax();
>>> + }
>> Did we actually encounter such a case? From what I've seen so far,
>> both community's u-boot and Allwinner's bootloader already do this.
>>
>> As you know, I'm really not fond of putting random values and
>> registers offsets into the DT itself. Making the assumption that the
>> PMIC is already switched to P2WI by the bootloader seems pretty safe
>> to me.
>
> Hans, any opinion ?
I think that Maxime is right, any bootloader will need to kick the
pmic to set dram voltage, etc. So it is pretty safe to assume this is
already done and just remove the code.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Describing arbitrary bus mastering relationships in DT
Dave, Mostly agree with your assessment. My $0.02 on one comment: On Fri, May 9, 2014 at 3:33 AM, Dave Martin wrote: > The downside is that is any path flows through a dynamically > configurable component, such as an IOMMU or a bridge that can be > remapped, turned off etc., then unless we describe how the path is > really linked together the kernel will need all sorts of baked-in > knowledge in order to manage the system safely. Absolutely. Some knowledge (assumptions) will be "baked in" as code and some knowledge (explicit parameters) as device tree. My understanding of device tree is it essentially specifies "parameters" and "methods" (code provided in the kernel). All methods make some assumptions about the behavior of the HW it's operating on and as long as all users of a method share that assumption, all is well. We don't need device tree to describe those assumptions. cheers, grant -- 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 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
On 09/05/2014 16:31, Maxime Ripard wrote:
> Hi Boris,
>
> On Wed, May 07, 2014 at 07:58:35PM +0200, Boris BREZILLON wrote:
>
[...]
> +
> + r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + p2wi->regs = devm_ioremap_resource(dev, r);
> + if (IS_ERR(p2wi->regs)) {
> + dev_err(dev, "failed to retrieve iomem resource\n");
> + return PTR_ERR(p2wi->regs);
> You seem to be returning the error code in the next error messages. It
> would probably be a good idea to put it there too.
Yes, I'll print the err code in the error message.
>
>> +}
>> +
>> +snprintf(p2wi->adapter.name, sizeof(p2wi->adapter.name), pdev->name);
>> +ret = platform_get_irq(pdev, 0);
>> +if (ret < 0) {
>> +dev_err(dev, "failed to retrieve irq: %d\n", ret);
>> +return ret;
>> +}
>> +p2wi->irq = ret;
>> +
>> +p2wi->clk = devm_clk_get(dev, NULL);
>> +if (IS_ERR(p2wi->clk)) {
>> +ret = PTR_ERR(p2wi->clk);
>> +dev_err(dev, "failed to retrieve clk: %d\n",
>> +ret);
>> +return ret;
>> +}
>> +
>> +ret = clk_prepare_enable(p2wi->clk);
>> +if (ret) {
>> +dev_err(dev, "failed to enable clk: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +parent_clk_freq = clk_get_rate(p2wi->clk);
>> +
>> +p2wi->rstc = devm_reset_control_get(dev, NULL);
>> +if (IS_ERR(p2wi->rstc)) {
>> +ret = PTR_ERR(p2wi->rstc);
>> +dev_err(dev, "failed to retrieve reset controller: %d\n",
>> +ret);
>> +goto err_clk_disable;
>> +}
>> +
>> +ret = reset_control_deassert(p2wi->rstc);
>> +if (ret) {
>> +dev_err(dev, "failed to deassert reset line: %d\n",
>> +ret);
>> +goto err_clk_disable;
>> +}
>> +
>> +init_completion(&p2wi->complete);
>> +p2wi->adapter.dev.parent = dev;
>> +p2wi->adapter.algo = &p2wi_algo;
>> +p2wi->adapter.owner = THIS_MODULE;
>> +p2wi->adapter.dev.of_node = pdev->dev.of_node;
>> +platform_set_drvdata(pdev, p2wi);
>> +i2c_set_adapdata(&p2wi->adapter, p2wi);
>> +
>> +ret = devm_request_irq(dev, p2wi->irq, p2wi_interrupt, 0, pdev->name,
>> + p2wi);
>> +if (ret) {
>> +dev_err(dev, "can't register interrupt handler irq%d: %d\n",
>> +p2wi->irq, ret);
>> +goto err_reset_assert;
>> +}
>> +
>> +writel(P2WI_CTRL_SOFT_RST, p2wi->regs + P2WI_CTRL);
>> +
>> +clk_div = parent_clk_freq / clk_freq;
>> +if (!clk_div) {
>> +dev_warn(dev,
>> + "clock-frequency is too high, setting it to %lu Hz\n",
>> + parent_clk_freq);
>> +clk_div = 1;
>> +} else if (clk_div > P2WI_CCR_MAX_CLK_DIV) {
>> +dev_warn(dev,
>> + "clock-frequency is too low, setting it to %lu Hz\n",
>> + parent_clk_freq / P2WI_CCR_MAX_CLK_DIV);
>> +clk_div = P2WI_CCR_MAX_CLK_DIV;
>> +}
>> +
>> +writel(P2WI_CCR_SDA_OUT_DELAY(1) | P2WI_CCR_CLK_DIV(clk_div),
>> + p2wi->regs + P2WI_CCR);
>> +
>> +if (p2wi_mode_reg >= 0 && p2wi_mode_val >= 0) {
>> +writel(P2WI_PMCR_PMU_INIT_SEND |
>> + P2WI_PMCR_PMU_MODE_REG(p2wi_mode_reg) |
>> + P2WI_PMCR_PMU_INIT_DATA(p2wi_mode_val) |
>> + P2WI_PMCR_PMU_DEV_ADDR(p2wi->slave_addr),
>> + p2wi->regs + P2WI_PMCR);
>> +
>> +while (readl(p2wi->regs + P2WI_PMCR) &
>> + P2WI_PMCR_PMU_INIT_SEND)
>> +cpu_relax();
>> +}
> Did we actually encounter such a case? From what I've seen so far,
> both community's u-boot and Allwinner's bootloader already do this.
>
> As you know, I'm really not fond of putting random values and
> registers offsets into the DT itself. Making the assumption that the
> PMIC is already switched to P2WI by the bootloader seems pretty safe
> to me.
Hans, any opinion ?
If everybody agrees on that point, I'll remove the initialization part
from the probe (and drop the allwinner,reg-xx properties retrieval).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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] arm/dts: am335x-evmsk enable display and lcd panel support
Tomi Valkeinen wrote on Fri [2014-May-09 14:29:02 +0300]: > On 06/05/14 19:10, Tony Lindgren wrote: > > * Darren Etheridge [140422 13:39]: > >> Add the necessary nodes to enable the LCD controller and the > >> LCD panel that is attached to the Texas Instruments AM335x > >> EVMSK platform. Also setup the necessary pin mux within the > >> DT file to drive the LCD connector and add the correct > >> pinmux settings for the lcd pins to be configured to when > >> the SoC goes into sleep state for the minimum power > >> consumption. > >> > >> For the sleep mode LCD pin settings, MUX_MODE7 is chosen as > >> this corresponds to switching the pins into input GPIO's with > >> an internal pulldown. Which has been determined to offer the > >> lowest power solution vs leaving the pins configured in LCD > >> mode. > > > > Probably best that Tomi queues all the panel .dts changes into > > a separate immutable branch that I can merge too. > > This is not for OMAP DSS, but for the LCDC used in beaglebone, so there > are no dependencies to any of my work. > Benoit had always queued these LCDC dts patches in the past. This is exactly the same as what had been done for AM335x-EVM and AM335x-BeagleBone both of which are already in the mainline kernel. I had just missed the EVMSK previously. Darren -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Tomi Valkeinen [140509 01:02]: > On 09/05/14 02:20, Tony Lindgren wrote: > > * Tony Lindgren [140429 16:53]: > >> Otherwise we can get often errors like the following and the > >> display won't come on: > >> > >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting > >> the output with video overlays disabled > >> > >> There are some earlier references to this issue: > >> > >> http://www.spinics.net/lists/linux-omap/msg59511.html > >> http://www.spinics.net/lists/linux-omap/msg59724.html > >> > >> It seems that it's safe to set the lower values even for 3630. > >> If we can confirm that 3630 works with the higher values > >> reliably we can add further detection. > > > > BTW, I'm also seeing this warning on 3730-evm it may be related: > > > > [3.523101] [ cut here ] > > [3.528015] WARNING: CPU: 0 PID: 6 at > > drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c() > > [3.538360] clk rate mismatch: 10800 != 11520 > > [3.543518] Modules linked in: > > Hmm... Can you paste the clk_summary from debugfs? Somehow the clock > framework calculates the clock rate differently than the dss. Or do we > have different clock.dts files used for 3730 and 3630? OK pasted to the other email in this thread. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Tomi Valkeinen [140509 00:39]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > Otherwise we can get often errors like the following and the
> > display won't come on:
> >
> > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> > omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> > the output with video overlays disabled
> >
> > There are some earlier references to this issue:
> >
> > http://www.spinics.net/lists/linux-omap/msg59511.html
> > http://www.spinics.net/lists/linux-omap/msg59724.html
>
> Those don't sound like the same issue, but it's hard to say. What kind
> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
> without this patch?
Without this patch:
# cat /sys/kernel/debug/omapdss/clk
[ 24.833831] DSS: dss_runtime_get
[ 24.837554] DSS: dss_runtime_put
[ 24.840972] DISPC: dispc_runtime_get
[ 24.844757] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 5760
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 5760
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 5760lck div 1
pck 1920pck div 3
With this patch:
# cat /sys/kernel/debug/omapdss/clk
[ 34.580688] DSS: dss_runtime_get
[ 34.584197] DSS: dss_runtime_put
[ 34.587768] DISPC: dispc_runtime_get
[ 34.591552] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 10800
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 10800
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 10800 lck div 1
pck 1800pck div 6
> What resolution do you have? If it's a very high resolution (say, DVI
> output to a monitor), it could just be an issue of
> not-enough-memory-bandwidth.
This is just the 3730-evm with the Sharp VGA panel mentioned in
this series.
> > It seems that it's safe to set the lower values even for 3630.
> > If we can confirm that 3630 works with the higher values
> > reliably we can add further detection.
> >
> > Signed-off-by: Tony Lindgren
> > ---
> > drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/omap2/dss/dss.c
> > b/drivers/video/fbdev/omap2/dss/dss.c
> > index d55266c..ad6561f 100644
> > --- a/drivers/video/fbdev/omap2/dss/dss.c
> > +++ b/drivers/video/fbdev/omap2/dss/dss.c
> > @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats
> > __initconst = {
> > .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
> > };
> >
> > +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
> > static const struct dss_features omap3630_dss_feats __initconst = {
> > - .fck_div_max= 32,
> > - .dss_fck_multiplier = 1,
> > + .fck_div_max= 16,
> > + .dss_fck_multiplier = 2,
>
> These values tell about the clock hardware, they are not settings that
> can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> and a divider with maximum value of 16.
>
> Tomi
>
>
--
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 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
Hi Boris, On Wed, May 07, 2014 at 07:58:35PM +0200, Boris BREZILLON wrote: > The P2WI looks like an SMBus controller which only supports byte data > transfers. But, it differs from standard SMBus protocol on several > aspects: > - it supports only one slave device, and thus drop the address field > - it adds a parity bit every 8bits of data > - only one read access is required to read a byte (instead of a read > followed by a write access in standard SMBus protocol) > - there's no Ack bit after each byte transfer > > This means this bus cannot be used to interface with standard SMBus > devices (the only known device to support this interface is the AXP221 > PMIC). > > Signed-off-by: Boris BREZILLON > --- > drivers/i2c/busses/Kconfig | 12 ++ > drivers/i2c/busses/Makefile | 1 + > drivers/i2c/busses/i2c-sun6i-p2wi.c | 375 > > 3 files changed, 388 insertions(+) > create mode 100644 drivers/i2c/busses/i2c-sun6i-p2wi.c > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index c94db1c..09bce1c 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -771,6 +771,18 @@ config I2C_STU300 > This driver can also be built as a module. If so, the module > will be called i2c-stu300. > > +config I2C_SUN6I_P2WI > + tristate "Allwinner sun6i internal P2WI controller" > + depends on ARCH_SUNXI > + help > + If you say yes to this option, support will be included for the > + P2WI (Push/Pull 2 Wire Interface) controller embedded in some sunxi > + SOCs. > + The P2WI looks like an SMBus controller (which supports only byte > + accesses), except that it only supports one slave device. > + This interface is used to connect to specific PMIC devices (like the > + AXP221). > + > config I2C_TEGRA > tristate "NVIDIA Tegra internal I2C controller" > depends on ARCH_TEGRA > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile > index 18d18ff..58feeb9 100644 > --- a/drivers/i2c/busses/Makefile > +++ b/drivers/i2c/busses/Makefile > @@ -75,6 +75,7 @@ obj-$(CONFIG_I2C_SIMTEC)+= i2c-simtec.o > obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o > obj-$(CONFIG_I2C_ST) += i2c-st.o > obj-$(CONFIG_I2C_STU300) += i2c-stu300.o > +obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o > obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o > obj-$(CONFIG_I2C_VERSATILE) += i2c-versatile.o > obj-$(CONFIG_I2C_WMT)+= i2c-wmt.o > diff --git a/drivers/i2c/busses/i2c-sun6i-p2wi.c > b/drivers/i2c/busses/i2c-sun6i-p2wi.c > new file mode 100644 > index 000..91c9b12 > --- /dev/null > +++ b/drivers/i2c/busses/i2c-sun6i-p2wi.c > @@ -0,0 +1,375 @@ > +/* > + * P2WI (Push-Pull Two Wire Interface) bus driver. > + * > + * Author: Boris BREZILLON > + * > + * This file is licensed under the terms of the GNU General Public License > + * version 2. This program is licensed "as is" without any warranty of any > + * kind, whether express or implied. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > + > +/* P2WI registers */ > +#define P2WI_CTRL0x0 > +#define P2WI_CCR 0x4 > +#define P2WI_INTE0x8 > +#define P2WI_INTS0xc > +#define P2WI_DADDR0 0x10 > +#define P2WI_DADDR1 0x14 > +#define P2WI_DLEN0x18 > +#define P2WI_DATA0 0x1c > +#define P2WI_DATA1 0x20 > +#define P2WI_LCR 0x24 > +#define P2WI_PMCR0x28 > + > +/* CTRL fields */ > +#define P2WI_CTRL_START_TRANSBIT(7) > +#define P2WI_CTRL_ABORT_TRANSBIT(6) > +#define P2WI_CTRL_GLOBAL_INT_ENB BIT(1) > +#define P2WI_CTRL_SOFT_RST BIT(0) > + > +/* CLK CTRL fields */ > +#define P2WI_CCR_SDA_OUT_DELAY(v)(((v) & 0x7) << 8) > +#define P2WI_CCR_MAX_CLK_DIV 0xff > +#define P2WI_CCR_CLK_DIV(v) ((v) & P2WI_CCR_MAX_CLK_DIV) > + > +/* STATUS fields */ > +#define P2WI_INTS_TRANS_ERR_ID(v)(((v) >> 8) & 0xff) > +#define P2WI_INTS_LOAD_BSY BIT(2) > +#define P2WI_INTS_TRANS_ERR BIT(1) > +#define P2WI_INTS_TRANS_OVER BIT(0) > + > +/* DATA LENGTH fields*/ > +#define P2WI_DLEN_READ BIT(4) > +#define P2WI_DLEN_DATA_LENGTH(v) ((v - 1) & 0x7) > + > +/* LINE CTRL fields*/ > +#define P2WI_LCR_SCL_STATE BIT(5) > +#define P2WI_LCR_SDA_STATE BIT(4) > +#define P2WI_LCR_SCL_CTL BIT(3) > +#define P2WI_LCR_SCL_CTL_EN BIT(2) > +#define P2WI_LCR_SDA_CTL BIT(1) > +#define P2WI_LCR_SDA_CTL_EN BIT(0) > + > +/* PMU MODE CTRL fields */ > +#define P2WI_PMCR_PMU_INIT_SEND BIT(31) > +#define P2WI_PMCR_PMU_INIT_DATA(v) (((v) & 0xff) <<
[RFC PATCH 2/2] drm/panel: update simple-panel DT bindings doc with panel desc properties
Document simple-panel description properties and subnodes.
The display-timings definition is the one described in
Documentation/devicetree/bindings/video/display-timing.txt.
Signed-off-by: Boris BREZILLON
---
.../devicetree/bindings/panel/simple-panel.txt | 34 ++
1 file changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt
b/Documentation/devicetree/bindings/panel/simple-panel.txt
index 1341bbf..3440f78 100644
--- a/Documentation/devicetree/bindings/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
@@ -7,6 +7,13 @@ Optional properties:
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
+- height: the screen height in pixels
+- width: the screen width in pixels
+
+Optional children nodes:
+- display-timings: encode the panel timings.
+ see Documentation/devicetree/bindings/video/display-timing.txt for a full
+ description.
Example:
@@ -19,3 +26,30 @@ Example:
backlight = <&backlight>;
};
+
+or
+panel: panel {
+compatible = "simple-panel";
+ enable-gpios = <&gpio 90 0>;
+
+ backlight = <&backlight>;
+
+ width = 1920;
+ height = 1080;
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 1080p24 {
+ /* 1920x1080p24 */
+ clock-frequency = <5200>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <25>;
+ hback-porch = <25>;
+ hsync-len = <25>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ hsync-active = <1>;
+ };
+ };
+ };
--
1.8.3.2
--
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
[RFC PATCH 1/2] drm/panel: add support for simple-panel description definition using DT
Currently, the only way to add new panel descriptions to the simple panel
driver is to add new entries in the platform_of_match table.
Add support for panel description retrieval from the DT.
Signed-off-by: Boris BREZILLON
---
drivers/gpu/drm/panel/Kconfig| 1 +
drivers/gpu/drm/panel/panel-simple.c | 70
2 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..4fe3d48 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -1,6 +1,7 @@
config DRM_PANEL
bool
depends on DRM
+ select VIDEOMODE_HELPERS
help
Panel registration and lookup framework.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 309f29e..fcf648d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -33,6 +33,10 @@
#include
#include
+#include
+#include
+#include
+
struct panel_desc {
const struct drm_display_mode *modes;
unsigned int num_modes;
@@ -168,6 +172,61 @@ static const struct drm_panel_funcs panel_simple_funcs = {
.get_modes = panel_simple_get_modes,
};
+static struct panel_desc *of_panel_desc_init(struct device *dev)
+{
+ struct display_timings *timings;
+ struct panel_desc *desc;
+ u32 width, height;
+ int err;
+ int i;
+
+ err = of_property_read_u32(dev->of_node, "width", &width);
+ if (err)
+ return ERR_PTR(err);
+
+ err = of_property_read_u32(dev->of_node, "height", &height);
+ if (err)
+ return ERR_PTR(err);
+
+ desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
+ if (!desc)
+ return ERR_PTR(-ENOMEM);
+
+ timings = of_get_display_timings(dev->of_node);
+ if (timings) {
+ struct drm_display_mode *modes =
+ devm_kzalloc(dev,
+timings->num_timings *
+sizeof(*desc->modes),
+GFP_KERNEL);
+
+ if (!modes)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < timings->num_timings; i++) {
+ struct videomode vm;
+
+ if (videomode_from_timings(timings, &vm, i))
+ break;
+
+ drm_display_mode_from_videomode(&vm, modes + i);
+
+ modes[i].type = DRM_MODE_TYPE_DRIVER;
+
+ if (timings->native_mode == i)
+ modes[i].type |= DRM_MODE_TYPE_PREFERRED;
+ desc->num_modes++;
+ }
+
+ kfree(timings);
+ }
+
+ desc->size.width = width;
+ desc->size.height = height;
+
+ return desc;
+}
+
static int panel_simple_probe(struct device *dev, const struct panel_desc
*desc)
{
struct device_node *backlight, *ddc;
@@ -178,6 +237,17 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
if (!panel)
return -ENOMEM;
+ if (!desc) {
+ desc = of_panel_desc_init(dev);
+ /*
+* Do not fail on DT panel desc retrieval error because
+* some systems do not need a panel description to work
+* properly.
+*/
+ if (IS_ERR(desc))
+ desc = NULL;
+ }
+
panel->enabled = false;
panel->desc = desc;
--
1.8.3.2
--
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
[RFC PATCH 0/2] drm/panel: add simple-panel description using DT
Hello Thierry, I noticed you're describing each new panel with a new entry in the of_platform_match table and a new compatible string. I guess you have a good reason to do it this way, because retrieving panel description from DT would be pretty easy (see this series ;-)). Could tell me why you chose this approach ? Best Regards, Boris Boris BREZILLON (2): drm/panel: add support for simple-panel description definition using DT drm/panel: update simple-panel DT bindings doc with panel desc properties .../devicetree/bindings/panel/simple-panel.txt | 34 +++ drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 70 ++ 3 files changed, 105 insertions(+) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Describing arbitrary bus mastering relationships in DT
On Fri, May 02, 2014 at 12:17:50PM -0600, Jason Gunthorpe wrote:
> On Fri, May 02, 2014 at 06:31:20PM +0100, Dave Martin wrote:
>
> > Note that there is no cycle through the "reg" property on iommu:
> > "reg" indicates a sink for transactions; "slaves" indicates a
> > source of transactions, and "ranges" indicates a propagator of
> > transactions.
>
> I wonder if this might be a better naming scheme, I actually don't
> really like 'slave' for this, it really only applies well to AXI style
> unidirectional busses, and any sort of message-based bus architectures
> (HT, PCI, QPI, etc) just have the concept of an initiator and target.
>
> Since initiator/target applies equally well to master/slave buses,
> that seems like better, clearer, naming.
Sure, I wouldn't have a problem with such a suggestion. A more neutral
naming is less likely to cause confusion.
> Using a nomenclature where
> 'reg' describes a target reachable from the CPU initiator via the
> natural DT hierarchy
I would say, reachable from the parent device node (which implies your
statement). This is consistent with the way ePAPR describes device-to-
device DMA (even if Linux doesn't usually make a lot of use of that).
> 'initiator' describes a non-CPU (eg 'DMA') source of ops, and
> travels via the path described to memory (which is the
> target).
CPUs are initiators only; non-mastering devices are targets only.
We might want some terminology to distinguish between mastering
devices and bridges, both of which act as initiators and targets.
We could have a concept of a "forwarder" or "gateway". But a bus
may still be a target as well as forwarder: if the bus contains some
control registers for example. There is nothing to stop "reg" and
"ranges" being present on the same node.
"ranges" and "dma-ranges" both describe a node's forwarding role,
one for transactions received from the parent, and one for transactions
received from children.
> 'path' describes the route between an intitator and target, where
> bridges along the route may alter the operation.
ok
> 'upstream' path direction toward the target, typically memory.
I'm not keen on that, because we would describe the hop between /
and /memory as downstream or upstream depending on who initiates the
transaction. (I appreciate you weren't including CPUs in your
discussion, but if the termology works for the whole system it
would be a bonus).
> 'upstream-bridge' The next hop on a path between an initiator/target
Maybe. I'm still not sure quite why this is considered different
from the downward path through the DT, except that you consider
the cross-links in the DT to be "upward", but I considered them
"downward" (which I think are mostly equivalent approaches).
Can you elaborate?
>
> But I would encourage you to think about the various limitations this
> still has
> - NUMA systems. How does one describe the path from each
>CPU to a target regs, and target memory? This is important for
>automatically setting affinities.
This is a good point.
Currently I had only been considering visibility, not affinity.
We actually have a similar problem with GIC, where there may
be multiple MSI mailboxes visible to a device, but one that is
preferred (due to being fewer hops away in the silicon, even though
the routing may be transparent).
I wasn't trying to solve this problem yet, and don't have a good
answer for it at present.
We could describe a whole separate bus for each CPU, with links
to common interconnect subtrees downstream. But that might involve
a lot of duplication. Your example below doesn't look too bad
though.
> - Peer-to-Peer DMA, this is where a non-CPU initiator speaks to a
>non-memory target, possibly through IOMMUs and what not. ie
>a graphics card in a PCI-E slot DMA'ing through a QPI bus to
>a graphics card in a PCI-E slot attached to a different socket.
Actually, I do intend to describe that and I think I achieved it :)
To try to keep the length of this mail down a bit I won't try to
give an example here, but I'm happy to follow up later if this is
still not answered elsewhere in the thread.
>
> These are already use-cases happening on x86.. and the same underlying
> hardware architectures this tries to describe for DMA to memory is at
> work for the above as well.
>
> Basically, these days, interconnect is a graph. Pretending things are
> a tree is stressful :)
>
> Here is a basic attempt using the above language, trying to describe
> an x86ish system with two sockets, two DMA devices, where one has DMA
> target capabable memory (eg a GPU)
>
> // DT tree is the view from the SMP CPU complex down to regs
> smp_system {
>socket0 {
>cpu0@0 {}
>cpu1@0 {}
>memory@0: {}
>interconnect0: {targets = <&memory@0,interconnect1>;}
>interconnect0_control: {
> ranges;
> peripheral@0 {
> regs = <>;
> int
Re: [PATCH v3 3/7] mfd: add support for sun6i PRCM (Power/Reset/Clock Management) unit
On 09/05/2014 15:52, Lee Jones wrote: >> The PRCM (Power/Reset/Clock Management) block exposes several subdevices >> in different subsystems (clk, reset ...) >> >> Add basic support for the PRCM unit with clk (AR100, AHB0, and APB0 clks) >> and reset controller subdevices. >> >> Other subdevices might be added later (if needed). >> >> Signed-off-by: Boris BREZILLON >> Acked-by: Maxime Ripard >> --- >> drivers/mfd/Kconfig | 8 +++ >> drivers/mfd/Makefile | 1 + >> drivers/mfd/sun6i-prcm.c | 134 >> +++ >> 3 files changed, 143 insertions(+) >> create mode 100644 drivers/mfd/sun6i-prcm.c > [...] > >> +/* >> + * Copyright (C) 2014 Free Electrons >> + * >> + * License Terms: GNU General Public License v2 >> + * Author: Boris BREZILLON >> + * >> + * Allwinner PRCM (Power/Reset/Clock Management) driver >> + * >> + */ >> + >> +#include >> +#include >> +#include > Ah, now isn't that better? Absolutely :-). > Acked-by: Lee Jones > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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
[PATCH v8 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply
Adding support to enable/disable VBUS controlled by a
regulator, to enable vbus supply on the port.
Signed-off-by: Vivek Gautam
---
Changes from v7:
- Rebased on top of [PATCH v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver.
drivers/phy/phy-exynos5-usbdrd.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 8fcdd94..76d862b 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/* Exynos USB PHY registers */
#define EXYNOS5_FSEL_9MHZ6 0x0
@@ -170,6 +171,7 @@ struct exynos5_usbdrd_phy {
} phys[EXYNOS5_DRDPHYS_NUM];
u32 extrefclk;
struct clk *ref_clk;
+ struct regulator *vbus;
};
static inline
@@ -438,6 +440,7 @@ static int exynos5_usbdrd_phy_exit(struct phy *phy)
static int exynos5_usbdrd_phy_power_on(struct phy *phy)
{
+ int ret;
struct phy_usb_instance *inst = phy_get_drvdata(phy);
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
@@ -445,10 +448,24 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd->ref_clk);
+ /* Enable VBUS supply */
+ if (phy_drd->vbus) {
+ ret = regulator_enable(phy_drd->vbus);
+ if (ret) {
+ dev_err(phy_drd->dev, "Failed to enable VBUS supply\n");
+ goto fail_vbus;
+ }
+ }
+
/* Power-on PHY*/
inst->phy_cfg->phy_isol(inst, 0);
return 0;
+
+fail_vbus:
+ clk_disable_unprepare(phy_drd->ref_clk);
+
+ return ret;
}
static int exynos5_usbdrd_phy_power_off(struct phy *phy)
@@ -461,6 +478,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Power-off the PHY */
inst->phy_cfg->phy_isol(inst, 1);
+ /* Disable VBUS supply */
+ if (phy_drd->vbus)
+ regulator_disable(phy_drd->vbus);
+
clk_disable_unprepare(phy_drd->ref_clk);
return 0;
@@ -600,6 +621,17 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
break;
}
+ /* Get Vbus regulator */
+ phy_drd->vbus = devm_regulator_get(dev, "vbus");
+ if (IS_ERR(phy_drd->vbus)) {
+ ret = PTR_ERR(phy_drd->vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, "Failed to get VBUS supply regulator\n");
+ phy_drd->vbus = NULL;
+ }
+
dev_vdbg(dev, "Creating usbdrd_phy phy\n");
for (i = 0; i < EXYNOS5_DRDPHYS_NUM; i++) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Also, created a new header file in linux/mfd/syscon/ for
Exynos5 SoCs and put the required PMU offset definitions
for the basic available PHYs.
Signed-off-by: Vivek Gautam
---
Changes from v7:
- Providing an **alternative** approach for pmu-offset;
instead of getting it from DT, using offset definitions from
a header file, and making use of it in the driver.
- Using 'aliases' for getting channel numbers for multi-controller
PHY, so as to distinguish between the pmu-offsets.
- Added a header file in syscon/ for Exynos5 SoC's pmu offset
definitions.
- Addressed the review comments for nits:
-- Changed 'usbdrd_phy_config' structure with 'exynos5_usbdrd_phy_config'
and corresponding instance names.
.../devicetree/bindings/phy/samsung-phy.txt| 47 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 644
include/linux/mfd/syscon/exynos5-pmu.h | 44 ++
5 files changed, 747 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
create mode 100644 include/linux/mfd/syscon/exynos5-pmu.h
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..2049261 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,50 @@ Example:
compatible = "samsung,exynos-sataphy-i2c";
reg = <0x38>;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
+ - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usbdrd_phy: usbphy@1210 {
+ compatible = "samsung,exynos5250-usbdrd-phy";
+ reg = <0x1210 0x100>;
+ clocks = <&clock 286>, <&clock 1>;
+ clock-names = "phy", "ref";
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ #phy-cells = <1>;
+ };
+
+- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY
controllers,
+ 'usbdrd_phy' nodes should have numbered alias in the aliases node,
+ in the form of usbdrdphyN, N = 0, 1... (depending on number of
+ controllers).
+Example:
+ aliases {
+ usbdrdphy0 = &usb3_phy0;
+ usbdrdphy1 = &usb3_phy1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 4906c27..b70cc07 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -160,6 +160,17 @@ config PHY_EXYNOS5250_USB2
particular SoC is compiled in the driver. In case of Exynos 5250 four
phys are available - device, host, HSIC0 and HSIC.
+config PHY_EXYNOS5_USBDRD
+ tristate "Exynos5 SoC series USB DRD PHY driver"
+ depends on ARCH_EXYNOS5 && OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
config PHY_XGENE
tristate "APM X-Gene 15Gbps PHY support"
depends on HAS_IOMEM && OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 7728518..b4f1d57 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,4 +18,5 @@ phy-exynos-usb2-y += phy-samsung-usb2.o
ph
Re: [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
On Fri, May 9, 2014 at 4:21 PM, Vivek Gautam wrote: > Hi Sylwester, > > > On Fri, May 9, 2014 at 3:43 PM, Sylwester Nawrocki > wrote: >> Hi Vivek, >> >> On 08/05/14 11:03, Vivek Gautam wrote: >> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt >> b/Documentation/devicetree/bindings/phy/samsung-phy.txt >> >>> index b422e38..51efe4c 100644 >> >>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt >> >>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt >> >>> @@ -114,3 +114,43 @@ Example: >> >>> compatible = "samsung,exynos-sataphy-i2c"; >> >>> reg = <0x38>; >> >>> }; >> >>> + >> >>> +Samsung Exynos5 SoC series USB DRD PHY controller >> >>> +-- >> >>> + >> >>> +Required properties: >> >>> +- compatible : Should be set to one of the following supported >> >>> values: >> >>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC, >> >>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC. >> >>> +- reg : Register offset and length of USB DRD PHY register set; >> >>> +- clocks: Clock IDs array as required by the controller >> >>> +- clock-names: names of clocks correseponding to IDs in the clock >> >>> property; >> >>> +Required clocks: >> >>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP >> >>> clock), >> >>> +used for register access. >> >>> + - ref: PHY's reference clock (usually crystal clock), used for >> >>> +PHY operations, associated by phy name. It is used to >> >>> +determine bit values for clock settings register. >> >>> +For Exynos5420 this is given as 'sclk_usbphy30' in CMU. >> >>> +- samsung,pmu-syscon: phandle for PMU system controller interface, >> >>> used to >> >>> + control pmu registers for power isolation. >> >>> +- samsung,pmu-offset: phy power control register offset to >> >>> pmu-system-controller >> >>> + base. > >> > >> It doesn't seem right to have register offset encoded in the device > >> tree > >> like this. I think it'd be more appropriate to associate such an offset > >> with the compatible string's value in the driver. > > Ok, it makes more sense. > Just out of curiosity, what difference would this make ? >>> >>> Moreover, in case of Exynos5420 (and may be in future SoCs), where we >>> have 2 USB DRD PHY controllers, >>> we will need to have a way around to deal with two separate offsets in >>> the driver for one compatible string. >> >> It could be handled by creating a list of offsets per compatible string and >> then adding some way to identify the PHY device instance. So I believe that's >> not a big issue. > > True, we had tried to make use of 'aliases' for multiple controllers > on Exynos5420, > in earlier version V3 of this patch, to handle the pmu-register > offsets in _somewhat_ similar fashion. [1] > But then we had to drop that as per the suggestions in the mailing list. > >> Now you'd be encoding a list of registers offsets in the >> device tree, without encoding bit layout of each register. It's unlikely that >> each instance would have different bits layout, but describing individual >> registers in DT I thought is something that we're not supposed to do. > > Ok, so this is information to me, i was not very much aware of this. > Thanks for explaining it here. > >> >>> Getting the offsets from DT seems a cleaner way to handle this case of >>> multi controllers. >> >> I think it's easier from the driver POV, but isn't it violating the device >> tree rules ? >> Anyway. I'm just pointing this minor issue in the binding as it appears >> to me. The final word of course belongs to a DT binding maintainer. > > Thanks Sylwester, for pointing this out here. > Meantime, please let me know if the approach using aliases is one > possible solution for this or not ? I shall be sending v8 patch series for this, in order to use 'aliases' in the driver to get the distinction between pmu-offsets. So, v8 will give an alternative approach for getting pmu-offsets using macro definitions from a header file. Mark and Rob can suggest us which can be a better approach. > > > [1] [PATCH v3] phy: Add new Exynos5 USB 3.0 PHY driver > https://lkml.org/lkml/2014/1/21/46 -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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: [PATCHv3 3/3] edac: altera: Add EDAC support for Altera SDRAM
On Thu, May 08, 2014 at 03:37:19PM -0500, Thor Thayer wrote: > Yes. Their reasoning is that they want to retain the rights and > warranty language with the file (just in case the COPYING file > changes). Ok, thanks for checking up on this. > Yes. I tested using edac_core.edac_mc_panic_on_ue=1 from the command > line and it worked fine. I'll add a comment to clarify. BTW, thanks > for your help on that. Sure, but the question still remains: do you want to panic on uncorrectable errors by default or want the user to decide? I guess this is something you can answer for your hardware... > I considered using "volatile" variables, but decided against it after > I read Documentation/volatile-considered-harmful.txt and my situation > doesn't fit into the exemptions. Is there a better way to handle this? Off the top of my head, I'd first look at compiler asm output to check what my compiler does with those writes and then take a look at employing the ACCESS_ONCE macro or something similar where we use the asm volatile() as an optimization stop for the compiler, among others. And then I'll look at asm again to make sure it does what it is supposed to do. Something to that effect, in any case... HTH. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 3/7] mfd: add support for sun6i PRCM (Power/Reset/Clock Management) unit
> The PRCM (Power/Reset/Clock Management) block exposes several subdevices > in different subsystems (clk, reset ...) > > Add basic support for the PRCM unit with clk (AR100, AHB0, and APB0 clks) > and reset controller subdevices. > > Other subdevices might be added later (if needed). > > Signed-off-by: Boris BREZILLON > Acked-by: Maxime Ripard > --- > drivers/mfd/Kconfig | 8 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/sun6i-prcm.c | 134 > +++ > 3 files changed, 143 insertions(+) > create mode 100644 drivers/mfd/sun6i-prcm.c [...] > +/* > + * Copyright (C) 2014 Free Electrons > + * > + * License Terms: GNU General Public License v2 > + * Author: Boris BREZILLON > + * > + * Allwinner PRCM (Power/Reset/Clock Management) driver > + * > + */ > + > +#include > +#include > +#include Ah, now isn't that better? Acked-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
On 05/09/14 13:49, Tomasz Figa wrote: Hi Kukjin, Hi Tomasz, On 09.05.2014 04:14, Kukjin Kim wrote: Tomasz Figa wrote: Hi Sachin, On 08.05.2014 06:16, Sachin Kamat wrote: Instead of hardcoding the SYSRAM details for each SoC, pass this information through device tree (DT) and make the code SoC agnostic. Generic SRAM bindings are used for achieving this. Signed-off-by: Sachin Kamat Acked-by: Arnd Bergmann Acked-by: Heiko Stuebner --- Changes since v2. * Updated sysram node for Universal C210 board - Thanks to Tomasz Figa for testing and updating the same. * Added error handling code. * Break if matching node found. * Remove unnecessary error messages. This patch is based on linux next (next-20140501) on top of my Kconfig consolidation patch http://comments.gmane.org/gmane.linux.kernel.samsung-soc/28642 Tested on 4210/4412 Origen, 5250/5420 Arndale and SMDK5420 boards. --- arch/arm/Kconfig | 1 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 15 ++ arch/arm/boot/dts/exynos4210.dtsi | 18 +++ arch/arm/boot/dts/exynos4x12.dtsi | 18 +++ arch/arm/boot/dts/exynos5250.dtsi | 18 +++ arch/arm/boot/dts/exynos5420.dtsi | 18 +++ arch/arm/mach-exynos/common.h | 1 + arch/arm/mach-exynos/exynos.c | 64 -- - arch/arm/mach-exynos/firmware.c | 8 ++- arch/arm/mach-exynos/include/mach/map.h | 7 --- arch/arm/mach-exynos/platsmp.c | 56 ++-- 11 files changed, 148 insertions(+), 76 deletions(-) Looks good, thanks. Reviewed-by: Tomasz Figa Looks good to me but I think, we need to change the name of 'sram' because it can cause some confusing, actually it is not matching _real_ sram area on the SoCs. When we upstreamed regarding patch, I decided the name to use 'SYSRAM', it was called another name in datasheet though. So, I'd like to use 'sysram' instead of 'sram' as we used before. I will change the name when I apply this series in this weekend, if you guys have no objection. You mean s/sram/sysram/ in compatible strings of Exynos-specific reserved areas? If yes, I'm fine, it might be even better. Just remember to update documentation in patch 2/2 as well. Yes, of course ;-) - Kukjin -- 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 3/3] drivers: net: cpsw-phy-sel: add am43xx platform support
AM43xx phy mode selection is similar to AM33xx platform, so adding only
the compatibility string to the driver
Signed-off-by: Mugunthan V N
---
Documentation/devicetree/bindings/net/cpsw-phy-sel.txt | 1 +
drivers/net/ethernet/ti/cpsw-phy-sel.c | 4
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
index d9da911..764c0c7 100644
--- a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
+++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
@@ -4,6 +4,7 @@ TI CPSW Phy mode Selection Device Tree Bindings
Required properties:
- compatible : Should be "ti,am3352-cpsw-phy-sel" for am335x
platform and
"ti,dra7xx-cpsw-phy-sel" for dra7xx platform
+ "ti,am43xx-cpsw-phy-sel" for am43xx platform
- reg : physical base address and size of the cpsw
registers map
- reg-names: names of the register map given in "reg" node
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c
b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index b93838d..aa8bf45 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -167,6 +167,10 @@ static const struct of_device_id cpsw_phy_sel_id_table[] =
{
.compatible = "ti,dra7xx-cpsw-phy-sel",
.data = &cpsw_gmii_sel_dra7xx,
},
+ {
+ .compatible = "ti,am43xx-cpsw-phy-sel",
+ .data = &cpsw_gmii_sel_am3352,
+ },
{}
};
MODULE_DEVICE_TABLE(of, cpsw_phy_sel_id_table);
--
1.9.2.459.g68773ac
--
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 2/3] drivers: net: cpsw-phy-sel: add dra7xx support for phy sel
Add dra7xx support for selecting the phy mode which is present in control
module of dra7xx SoC
Signed-off-by: Mugunthan V N
---
.../devicetree/bindings/net/cpsw-phy-sel.txt | 3 +-
drivers/net/ethernet/ti/cpsw-phy-sel.c | 57 +-
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
index 7ff57a1..d9da911 100644
--- a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
+++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
@@ -2,7 +2,8 @@ TI CPSW Phy mode Selection Device Tree Bindings
---
Required properties:
-- compatible : Should be "ti,am3352-cpsw-phy-sel"
+- compatible : Should be "ti,am3352-cpsw-phy-sel" for am335x
platform and
+ "ti,dra7xx-cpsw-phy-sel" for dra7xx platform
- reg : physical base address and size of the cpsw
registers map
- reg-names: names of the register map given in "reg" node
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c
b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index 86b5dce..b93838d 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -29,6 +29,8 @@
#define AM33XX_GMII_SEL_RMII2_IO_CLK_ENBIT(7)
#define AM33XX_GMII_SEL_RMII1_IO_CLK_ENBIT(6)
+#define GMII_SEL_MODE_MASK 0x3
+
struct cpsw_phy_sel_priv {
struct device *dev;
u32 __iomem *gmii_sel;
@@ -65,7 +67,7 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv
*priv,
break;
};
- mask = 0x3 << (slave * 2) | BIT(slave + 6);
+ mask = GMII_SEL_MODE_MASK << (slave * 2) | BIT(slave + 6);
mode <<= slave * 2;
if (priv->rmii_clock_external) {
@@ -81,6 +83,55 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv
*priv,
writel(reg, priv->gmii_sel);
}
+static void cpsw_gmii_sel_dra7xx(struct cpsw_phy_sel_priv *priv,
+phy_interface_t phy_mode, int slave)
+{
+ u32 reg;
+ u32 mask;
+ u32 mode = 0;
+
+ reg = readl(priv->gmii_sel);
+
+ switch (phy_mode) {
+ case PHY_INTERFACE_MODE_RMII:
+ mode = AM33XX_GMII_SEL_MODE_RMII;
+ break;
+
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ mode = AM33XX_GMII_SEL_MODE_RGMII;
+ break;
+
+ case PHY_INTERFACE_MODE_MII:
+ default:
+ mode = AM33XX_GMII_SEL_MODE_MII;
+ break;
+ };
+
+ switch (slave) {
+ case 0:
+ mask = GMII_SEL_MODE_MASK;
+ break;
+ case 1:
+ mask = GMII_SEL_MODE_MASK << 4;
+ mode <<= 4;
+ break;
+ default:
+ dev_err(priv->dev, "invalid slave number...\n");
+ return;
+ }
+
+ if (priv->rmii_clock_external)
+ dev_err(priv->dev, "RMII External clock is not supported\n");
+
+ reg &= ~mask;
+ reg |= mode;
+
+ writel(reg, priv->gmii_sel);
+}
+
static struct platform_driver cpsw_phy_sel_driver;
static int match(struct device *dev, void *data)
{
@@ -112,6 +163,10 @@ static const struct of_device_id cpsw_phy_sel_id_table[] =
{
.compatible = "ti,am3352-cpsw-phy-sel",
.data = &cpsw_gmii_sel_am3352,
},
+ {
+ .compatible = "ti,dra7xx-cpsw-phy-sel",
+ .data = &cpsw_gmii_sel_dra7xx,
+ },
{}
};
MODULE_DEVICE_TABLE(of, cpsw_phy_sel_id_table);
--
1.9.2.459.g68773ac
--
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 1/3] drivers: net: cpsw-phy-sel: initialize priv->dev
priv->dev is uninitialized, initializing with pdev->dev Signed-off-by: Mugunthan V N --- drivers/net/ethernet/ti/cpsw-phy-sel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c index 148da9a..86b5dce 100644 --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c @@ -132,6 +132,7 @@ static int cpsw_phy_sel_probe(struct platform_device *pdev) return -ENOMEM; } + priv->dev = &pdev->dev; priv->cpsw_phy_sel = of_id->data; res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gmii-sel"); -- 1.9.2.459.g68773ac -- 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 0/3] Add DRA7xx and AM43xx platform support in cpsw-phy-sel driver
Adding DRA7xx and AM43xx platform support to cpsw-phy-sel driver to select phy mode in control driver and fixing the uninitialized dev by initializing to platform device structure pointer. Changes from Initial version * Added back the missing patch (1/3) Mugunthan V N (3): drivers: net: cpsw-phy-sel: initialize priv->dev drivers: net: cpsw-phy-sel: add dra7xx support for phy sel drivers: net: cpsw-phy-sel: add am43xx platform support .../devicetree/bindings/net/cpsw-phy-sel.txt | 4 +- drivers/net/ethernet/ti/cpsw-phy-sel.c | 62 +- 2 files changed, 64 insertions(+), 2 deletions(-) -- 1.9.2.459.g68773ac -- 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/2] Add DRA7xx platform support in cpsw-phy-sel driver
On Friday 09 May 2014 04:33 PM, Mugunthan V N wrote: > Adding DRA7xx platform support to cpsw-phy-sel driver to select phy mode in > control driver and fixing the uninitialized dev by initializing to platform > device structure pointer. > > Mugunthan V N (2): > drivers: net: cpsw-phy-sel: add dra7xx support for phy sel > drivers: net: cpsw-phy-sel: add am43xx platform support > > .../devicetree/bindings/net/cpsw-phy-sel.txt | 4 +- > drivers/net/ethernet/ti/cpsw-phy-sel.c | 61 > +- > 2 files changed, 63 insertions(+), 2 deletions(-) > Please ignore the patch as the second patch is not applicable and one patch is missing. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Describing arbitrary bus mastering relationships in DT
On Fri, May 02, 2014 at 10:36:43PM +0200, Arnd Bergmann wrote:
> On Friday 02 May 2014 18:31:20 Dave Martin wrote:
> > No, but I didn't state it very clearly.
> >
> > In this:
> >
> > parent {
> > child {
> > ranges = < ... >;
> > dma-ranges = < ... >;
> > };
> > };
>
> The ranges and dma-ranges properties belong into parent, not child here.
> I guess that's what you meant at least.
>
> > There are two transaction flows being described. There are transactions
> > from parent -> child, for which "ranges" describes the mappings, and
> > there are transactions from child -> parent, for which "dma-ranges"
> > describes the mappings.
>
> Right.
>
> > The name "dma-ranges" obfuscates this symmetry, so it took me a while
> > to figure out what it really means -- maybe I'm still confused, but
> > I think that's the gist of it.
> >
> >
> > For the purposes of cross-links, my plan was that we interpret all
> > those links as "forward" (i.e., parent -> child) links, where the
> > referencing node is deemed to be the parent, and the referenced node is
> > deemed to be the child. Just as in the ePAPR case, the associated mapping
> > is then described by "ranges".
>
> That seems counterintuitive to me. When a device initiates a transaction,
> it should look at the "dma-ranges" of its parent. The "slaves" property
> would be a way to redirect the parent for these transactions, but it
> doesn't mean that the device suddenly translates ranges as seen from
> its parent.
>
> In other words, "ranges" should always move from CPU to MMIO target
> (slave), while "dma-ranges" should always move from a DMA master towards
> memory. If you want to represent a device-to-device DMA, you may have
> to move up a few levels using "dma-ranges" and then move down again
> using "ranges".
In unidirectional bus architectures with non-CPU bus masters, the
classification of flows as "upstream" or "downstream" is nonsensical.
There is only a single direction at any point: the topology derives
completely from how things are linked together.
Trying to orient the topology of SoC architectures can be like trying to
decide which way is up in an M. C. Escher drawing, but with less elegant
symmetry. While the CPUs would be clearly placed at the top by almost
everybody, it's generally impossible to draw things so that some of the
topology isn't upside-down.
This wouldn't matter, except ePAPR DT does make a fundamental difference
between upstream and downstream: only a single destination is permitted
for upstream via "dma-ranges": the parent node. For downstream,
multiple destinations are permitted, because a node can have multiple
children. We can add additional logical children to a node without
radical change to the way traversal works. But allowing multiple
parents is likely to be a good deal more disruptive.
With dma-ranges, unless multiple logical parent nodes are permitted for
traversal then we have no way to describe independent properties
or mappings for paths to different destinations: ePAPR does not allow
you to pingpong between upstream and downstream directions. You
traverse in the upstream until you reach a common ancestor of the
destination, then you traverse downstream. Towards the common
ancestor there is no chance to describe different paths, because
there is only a single parent node at each point. From the common
ansestor transactions from all masters follow the same paths through
the DT, so there is still no way to describe per-master-per-slave
mappings.
The "ranges" approach solves this problem, which I believe may
be important if we want to describe how ID signals are mapped via
the same mechanisms: we know that there really will be per-master-
per-slave mappings for IDs.
There may be other solutions, or aspects of the problem I still don't
understand properly ... (likely!)
>
> > > Don't you need arguments to the phandle? It seems that in most
> > > cases, you need at least one of a dma-ranges like translation
> > > or a master ID. What you need would be specific to the slave.
> >
> > For any 1:N relationship between nodes, you can describe the
> > _relationship_ by putting properties on the nodes at the "1" end. This
> > is precisely how "ranges" and "dma-ranges" work.
>
> That doesn't seem very helpful or intuitive though. If I have
> an IOMMU that N DMA masters can target, I don't want to have
> information about all the masters in the IOMMU, that information
> belongs into the masters, but the format in which it is stored
> must be specific to the IOMMU.
>
> > The N:M case can be resolved by inserting simple-bus nodes into any
> > links with non-default mappings: i.e., you split each affected link in
> > two, with a simple-bus node in the middle describing the mapping:
>
> Ok, ignoring those oddball cases for now, I'd like to first
> try to come to a more useful representation for the common case.
>
>
[PATCH v2 0/4] dts: Add usb2phy to Exynos 5250/5420
Based on 'for-next' branch of Kgene's linux-samsung tree. These patches are as per discussions on the driver side patches which have already been acked. [1] Changes from v1: - Rebase on 'for-next' branch. - Removed 'phy-names' property as per discuusion in the driver patches. [1] V1 of this series was the next version for earlier patch-series: [PATCH v7 0/2] dts: Add usb2phy to Exynos 5250 [2] Changes from v7 series: - Added patches to enable usb 2.0 support on exynos5420; which include dt nodes for usb2phy as well as ehci and ohci controllers. Changes from v6: - Splitted the patch into two: adding syscon nodes to Exynos5250 and Exynos5420 in first; and phy entry change in the second. - Changed the name of phandle for usb2phy from 'usb2_phy_new' to 'usb2_phy_gen' indicating generic phy. - Using clock macros in dt entries. [1] http://www.spinics.net/lists/linux-usb/msg106908.html http://www.spinics.net/lists/linux-usb/msg106837.html [2] http://www.spinics.net/lists/linux-usb/msg106427.html Kamil Debski (1): ARM: dts: Add usb2phy to Exynos 5250 Vivek Gautam (3): ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420 ARM: dts: Add usb2phy support on exynos5420 ARM: dts: Add usb 2.0 support on exynos5420 arch/arm/boot/dts/exynos5250.dtsi | 27 ++ arch/arm/boot/dts/exynos5420.dtsi | 45 + 2 files changed, 72 insertions(+) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 2/4] ARM: dts: Add usb2phy to Exynos 5250
From: Kamil Debski
Add support to PHY of USB2 of the Exynos 5250 SoC.
Signed-off-by: Kamil Debski
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHCI]
Signed-off-by: Vivek Gautam
---
Changes from v8:
- Removed 'phy-names' property from the 'port'.
- Dropped 'status' property, since default also takes status = okay.
arch/arm/boot/dts/exynos5250.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 70f0cd5..782c524 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -563,6 +563,12 @@
clocks = <&clock CLK_USB2>;
clock-names = "usbhost";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phys = <&usb2_phy_gen 1>;
+ };
};
usb@1212 {
@@ -572,6 +578,12 @@
clocks = <&clock CLK_USB2>;
clock-names = "usbhost";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phys = <&usb2_phy_gen 1>;
+ };
};
usb2_phy: usbphy@1213 {
@@ -589,6 +601,16 @@
};
};
+ usb2_phy_gen: phy@1213 {
+ compatible = "samsung,exynos5250-usb2-phy";
+ reg = <0x1213 0x100>;
+ clocks = <&clock CLK_USB2>, <&clock CLK_FIN_PLL>;
+ clock-names = "phy", "ref";
+ #phy-cells = <1>;
+ samsung,sysreg-phandle = <&sysreg_system_controller>;
+ samsung,pmureg-phandle = <&pmu_system_controller>;
+ };
+
pwm: pwm@12dd {
compatible = "samsung,exynos4210-pwm";
reg = <0x12dd 0x100>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 1/4] ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420
This patch adds sysreg-syscon node to exynos5250 and exynos5420 device
tree, to access System Register's registers using syscon driver.
Signed-off-by: Kamil Debski
[gautam.vi...@samsung.com: Split this syreg-syscon dts entry from
dts: Add usb2phy to Exynos 5250 patch]
[gautam.vi...@samsung.com: added similar syscon entry for exynos5420]
Signed-off-by: Vivek Gautam
---
Changes since v7:
None
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..70f0cd5 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -175,6 +175,11 @@
reg = <0x1004 0x5000>;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = "samsung,exynos5250-sys", "syscon";
+ reg = <0x1005 0x5000>;
+ };
+
watchdog@101D {
compatible = "samsung,exynos5250-wdt";
reg = <0x101D 0x100>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index a802f74..5d5d6e3 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -682,6 +682,11 @@
reg = <0x1004 0x5000>;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = "samsung,exynos5420-sys", "syscon";
+ reg = <0x1005 0x5000>;
+ };
+
tmu_cpu0: tmu@1006 {
compatible = "samsung,exynos5420-tmu";
reg = <0x1006 0x100>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: dts: Add usb 2.0 support on exynos5420
Add required device node for ehci and ohci controllers to
enable USB 2.0 support.
Signed-off-by: Vivek Gautam
---
Changes from v1:
- Removed 'phy-names' property from the 'port'.
- Added node references for the nodes.
arch/arm/boot/dts/exynos5420.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index ddd09a3..77ccefd 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -745,6 +745,36 @@
samsung,power-domain = <&g2d_pd>;
};
+ usbhost2: usb@1211 {
+ compatible = "samsung,exynos4210-ehci";
+ reg = <0x1211 0x100>;
+ interrupts = <0 71 0>;
+
+ clocks = <&clock CLK_USBH20>;
+ clock-names = "usbhost";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phys = <&usb2_phy 1>;
+ };
+ };
+
+ usbhost1: usb@1212 {
+ compatible = "samsung,exynos4210-ohci";
+ reg = <0x1212 0x100>;
+ interrupts = <0 71 0>;
+
+ clocks = <&clock CLK_USBH20>;
+ clock-names = "usbhost";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phys = <&usb2_phy 1>;
+ };
+ };
+
usb2_phy: phy@1213 {
compatible = "samsung,exynos5250-usb2-phy";
reg = <0x1213 0x100>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: dts: Add usb2phy support on exynos5420
Add required device node for usb2phy to let enable USB 2.0
support.
Signed-off-by: Vivek Gautam
---
Changes from v1:
- Added node references for the phy node.
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 5d5d6e3..ddd09a3 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -744,4 +744,14 @@
clock-names = "secss";
samsung,power-domain = <&g2d_pd>;
};
+
+ usb2_phy: phy@1213 {
+ compatible = "samsung,exynos5250-usb2-phy";
+ reg = <0x1213 0x100>;
+ clocks = <&clock CLK_USBH20>, <&clock CLK_SCLK_USBPHY300>;
+ clock-names = "phy", "ref";
+ #phy-cells = <1>;
+ samsung,sysreg-phandle = <&sysreg_system_controller>;
+ samsung,pmureg-phandle = <&pmu_system_controller>;
+ };
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: ux500: Add sdi[n] devices to VAPE power domain
Cc: Tomasz Figa
Cc: devicetree@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Ulf Hansson
---
arch/arm/boot/dts/ste-dbx5x0.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi
b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index 29a7013..630690b 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -11,6 +11,7 @@
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -840,6 +841,7 @@
clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>;
clock-names = "sdi", "apb_pclk";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
status = "disabled";
};
@@ -855,6 +857,7 @@
clocks = <&prcc_kclk 2 4>, <&prcc_pclk 2 6>;
clock-names = "sdi", "apb_pclk";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
status = "disabled";
};
@@ -870,6 +873,7 @@
clocks = <&prcc_kclk 3 4>, <&prcc_pclk 3 4>;
clock-names = "sdi", "apb_pclk";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
status = "disabled";
};
@@ -881,6 +885,7 @@
clocks = <&prcc_kclk 2 5>, <&prcc_pclk 2 7>;
clock-names = "sdi", "apb_pclk";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
status = "disabled";
};
@@ -896,6 +901,7 @@
clocks = <&prcc_kclk 2 2>, <&prcc_pclk 2 4>;
clock-names = "sdi", "apb_pclk";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
status = "disabled";
};
@@ -907,6 +913,7 @@
clocks = <&prcc_kclk 3 7>, <&prcc_pclk 3 7>;
clock-names = "sdi", "apb_pclk";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
status = "disabled";
};
--
1.7.9.5
--
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 2/3] ARM: ux500: Add DT node for ux500 power domains
Cc: Tomasz Figa
Cc: devicetree@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Ulf Hansson
---
arch/arm/boot/dts/ste-dbx5x0.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi
b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index e41eedc..29a7013 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -43,6 +43,10 @@
interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
};
+ pm_domains: pm_domains0 {
+ compatible = "stericsson,ux500-pm-domains";
+ #power-domain-cells = <1>;
+ };
clocks {
compatible = "stericsson,u8500-clks";
--
1.7.9.5
--
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 0/3] ARM: ux500: Add initial support for power domains
Initial support for power domains for ux500. To enable this feature we require to use DT, thus we need to add bindings for the ux500 specific parts as well. The implementation of the ux500 power domains is based upon the generic power domain. An important note, this patchset depends on Tomasz Figa patchset, which is still in the review phase: [PATCH v4 0/3] Generic Device Tree based power domain look-up http://www.spinics.net/lists/kernel/msg1738549.html I assume that patchset will be queued through Rafael's linux pm tree. Let's see what the prefer way is for how to deal with this patchset, after that point. Ulf Hansson (3): ARM: ux500: Initial support for power domains ARM: ux500: Add DT node for ux500 power domains ARM: ux500: Add sdi[n] devices to VAPE power domain .../devicetree/bindings/arm/ux500/power_domain.txt | 35 + arch/arm/boot/dts/ste-dbx5x0.dtsi | 11 +++ arch/arm/mach-ux500/Kconfig|5 ++ arch/arm/mach-ux500/Makefile |1 + arch/arm/mach-ux500/pm.c |4 + arch/arm/mach-ux500/pm_domains.c | 77 arch/arm/mach-ux500/pm_domains.h | 17 + include/dt-bindings/arm/ux500_pm_domains.h | 15 8 files changed, 165 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/ux500/power_domain.txt create mode 100644 arch/arm/mach-ux500/pm_domains.c create mode 100644 arch/arm/mach-ux500/pm_domains.h create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: ux500: Initial support for power domains
Initial support for power domains for ux500. To enable this feature we
require to use DT, thus we need to add bindings for the ux500 specific
parts as well.
The implementation of the ux500 power domains is based upon the generic
power domain.
Cc: Tomasz Figa
Cc: devicetree@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Ulf Hansson
---
.../devicetree/bindings/arm/ux500/power_domain.txt | 35 +
arch/arm/mach-ux500/Kconfig|5 ++
arch/arm/mach-ux500/Makefile |1 +
arch/arm/mach-ux500/pm.c |4 +
arch/arm/mach-ux500/pm_domains.c | 77
arch/arm/mach-ux500/pm_domains.h | 17 +
include/dt-bindings/arm/ux500_pm_domains.h | 15
7 files changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ux500/power_domain.txt
create mode 100644 arch/arm/mach-ux500/pm_domains.c
create mode 100644 arch/arm/mach-ux500/pm_domains.h
create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h
diff --git a/Documentation/devicetree/bindings/arm/ux500/power_domain.txt
b/Documentation/devicetree/bindings/arm/ux500/power_domain.txt
new file mode 100644
index 000..1c98f01
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ux500/power_domain.txt
@@ -0,0 +1,35 @@
+* ST-Ericsson UX500 Power Domains
+
+UX500 supports multiple power domains which are used to gate power to one or
+more peripherals on the SOC.
+
+The implementation of power domains for UX500 are based upon the generic power
+domain and use the corresponding DT bindings.
+
+==Power domain providers==
+
+Required properties:
+ - compatible: Must be "stericsson,ux500-pm-domains".
+ - #power-domain-cells : Number of cells in a power domain specifier, must be
1.
+
+Example:
+ pm_domains: pm_domains0 {
+ compatible = "stericsson,ux500-pm-domains";
+ #power-domain-cells = <1>;
+ };
+
+==Power domain consumers==
+
+Required properties:
+ - power-domains: A phandle and power domain specifier. Below are the list of
+ valid specifiers:
+
+ Index Specifier
+ - -
+ 0 DOMAIN_VAPE
+
+Example:
+ sdi0_per1@80126000 {
+ compatible = "arm,pl18x", "arm,primecell";
+ power-domains = <&pm_domains DOMAIN_VAPE>
+ };
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index b41a42d..0727fa7 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -77,4 +77,9 @@ config UX500_DEBUG_UART
Choose the UART on which kernel low-level debug messages should be
output.
+config UX500_PM_DOMAINS
+ def_bool y
+ depends on PM_RUNTIME && OF
+ select PM_GENERIC_DOMAINS
+
endif
diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index de544aa..0dc5d01 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_MACH_MOP500) += board-mop500-sdi.o \
board-mop500-audio.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
+obj-$(CONFIG_UX500_PM_DOMAINS) += pm_domains.o
CFLAGS_hotplug.o += -march=armv7-a
diff --git a/arch/arm/mach-ux500/pm.c b/arch/arm/mach-ux500/pm.c
index b80a9a2..2cb587b 100644
--- a/arch/arm/mach-ux500/pm.c
+++ b/arch/arm/mach-ux500/pm.c
@@ -17,6 +17,7 @@
#include
#include "db8500-regs.h"
+#include "pm_domains.h"
/* ARM WFI Standby signal register */
#define PRCM_ARM_WFI_STANDBY(prcmu_base + 0x130)
@@ -191,4 +192,7 @@ void __init ux500_pm_init(u32 phy_base, u32 size)
/* Set up ux500 suspend callbacks. */
suspend_set_ops(UX500_SUSPEND_OPS);
+
+ /* Initialize ux500 power domains */
+ ux500_pm_domains_init();
}
diff --git a/arch/arm/mach-ux500/pm_domains.c b/arch/arm/mach-ux500/pm_domains.c
new file mode 100644
index 000..dbc115b
--- /dev/null
+++ b/arch/arm/mach-ux500/pm_domains.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * Author: Ulf Hansson
+ * License terms: GNU General Public License (GPL) version 2
+ *
+ * Implements power domains as generic power domains for ux500.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "pm_domains.h"
+
+static int pd_power_off(struct generic_pm_domain *domain)
+{
+ /*
+* Handle the gating of the power domain regulator here.
+* Drivers/subsystems operating the devices in the power domain needs
+* to handle register context save/restore to be able to enable power
+* domain gating/ungating.
+*/
+ return 0;
+}
+
+static int pd_power_on(struct generic_pm_domain *domain)
+{
+ /*
+* Handle the ungating of the power domain regulator here.
+* Drivers/subsystems operating the
[PATCH 2/4] clk: samsung: exynos5420: Add xclkout debug clock
A new clock provider has been added to configure the XCLKOUT debug
clock. Added a minimal implemetation for Exynos5420 clock driver.
Right now, only one valid parent clock from XCLKOUT is defined
in existing clock driver. The driver will be updated later for other
for other parent clocks.
Signed-off-by: Tushar Behera
CC: Tomasz Figa
---
drivers/clk/samsung/clk-exynos5420.c | 14 ++
include/dt-bindings/clock/exynos5420.h |5 -
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 60b2681..a8f6527 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -296,6 +296,13 @@ PNAME(hdmi_p) = { "dout_hdmi_pixel", "sclk_hdmiphy" };
PNAME(maudio0_p) = { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
"sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
+PNAME(xclkout_p) = {
+ "dummy", "dummy", "dummy", "dummy",
+ "dummy", "dummy", "dummy", "dummy",
+ "dummy", "dummy", "dummy", "dummy",
+ "dummy", "dummy", "dummy", "dummy",
+ "fin_pll", "dummy", "dummy" };
+
/* fixed rate clocks generated outside the soc */
static struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[]
__initdata = {
FRATE(CLK_FIN_PLL, "fin_pll", NULL, CLK_IS_ROOT, 0),
@@ -308,6 +315,7 @@ static struct samsung_fixed_rate_clock
exynos5420_fixed_rate_clks[] __initdata =
FRATE(0, "sclk_usbh20", NULL, CLK_IS_ROOT, 4800),
FRATE(0, "mphy_refclk_ixtal24", NULL, CLK_IS_ROOT, 4800),
FRATE(0, "sclk_usbh20_scan_clk", NULL, CLK_IS_ROOT, 48000),
+ FRATE(0, "dummy", NULL, CLK_IS_ROOT, 0),
};
static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[]
__initdata = {
@@ -770,6 +778,10 @@ static struct samsung_pll_clock exynos5420_plls[nr_plls]
__initdata = {
KPLL_CON0, NULL),
};
+static struct samsung_out_clock exynos5420_clkout[] __initdata = {
+ CLKOUT(CLK_XCLKOUT, "xclkout", xclkout_p),
+};
+
static struct of_device_id ext_clk_match[] __initdata = {
{ .compatible = "samsung,exynos5420-oscclk", .data = (void *)0, },
{ },
@@ -802,6 +814,8 @@ static void __init exynos5420_clk_init(struct device_node
*np)
ARRAY_SIZE(exynos5420_div_clks));
samsung_clk_register_gate(exynos5420_gate_clks,
ARRAY_SIZE(exynos5420_gate_clks));
+ samsung_clk_register_clkout(np,
+ exynos5420_clkout, ARRAY_SIZE(exynos5420_clkout));
exynos5420_clk_sleep_init();
}
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 5eefd88..28eca32 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -182,7 +182,10 @@
/* divider clocks */
#define CLK_DOUT_PIXEL 768
+/* debug clocks */
+#define CLK_XCLKOUT896
+
/* must be greater than maximal clock id */
-#define CLK_NR_CLKS769
+#define CLK_NR_CLKS897
#endif /* _DT_BINDINGS_CLOCK_EXYNOS_5420_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] clk: samsung: out: Add infrastructure to register CLKOUT
All SoC in Exynos-series have a clock with name XCLKOUT to provide
debug information about various clocks available in the SoC. The register
controlling the MUX and GATE of this clock is provided within PMU domain.
Since PMU domain can't be dedicatedly mapped by every driver, the register
needs to be handled through a regmap handle provided by PMU syscon
controller. Right now, CCF doesn't allow regmap based MUX and GATE clocks,
hence a dedicated clock provider for XCLKOUT is added here.
Signed-off-by: Tushar Behera
CC: Tomasz Figa
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-out.c | 181 +
drivers/clk/samsung/clk.h | 33
3 files changed, 215 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-out.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..d23ad4f 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-out.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-out.c b/drivers/clk/samsung/clk-out.c
new file mode 100644
index 000..76489b6
--- /dev/null
+++ b/drivers/clk/samsung/clk-out.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the clkout clocks.
+*/
+
+/**
+ * All SoC in Exynos-series have a clock with name XCLKOUT to provide
+ * debug information about various clocks available in the SoC. The register
+ * controlling the MUX and GATE of this clock is provided within PMU domain.
+ * Since PMU domain can't be dedicatedly mapped every driver, the register
+ * needs to be handled through a regmap handle provided by PMU syscon
+ * controller. Right now, CCF doesn't allow regmap based MUX and GATE clocks,
+ * hence a dedicated clock provider for XCLKOUT is added here.
+ */
+
+#include
+#include
+#include
+
+#include "clk.h"
+
+/**
+ * struct samsung_clkout_soc_data: SoC specific register details
+ * @reg: Offset of CLKOUT register from PMU base
+ * @mux_shift: Start-bit of MUX bit-field
+ * @mux_width: Width of MUX bit-field
+ * @enable_bit: The bit corresponding to gating of this clock
+ */
+struct samsung_clkout_soc_data {
+ unsigned int reg;
+ u8 mux_shift;
+ u8 mux_width;
+ u8 enable_bit;
+};
+
+/**
+ * struct samsung_clkout: Structure to store driver specific clock context
+ * @hw: Handle to CCF clock
+ * @soc_data: SoC specific register details
+ * @regmap: Regmap handle of the PMU
+ */
+struct samsung_clkout {
+ struct clk_hw hw;
+ const struct samsung_clkout_soc_data *soc_data;
+ struct regmap *regmap;
+};
+
+#define to_clk_out(_hw) container_of(_hw, struct samsung_clkout, hw)
+
+int samsung_clkout_enable(struct clk_hw *hw)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int enable_mask = BIT(soc_data->enable_bit);
+
+ /* clkout is enabled if enable bit is low */
+ regmap_update_bits(clkout->regmap, soc_data->reg, enable_mask, 0);
+
+ return 0;
+}
+
+void samsung_clkout_disable(struct clk_hw *hw)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int enable_mask = BIT(soc_data->enable_bit);
+
+ /* clkout is gated if enable bit is high */
+ regmap_update_bits(clkout->regmap, soc_data->reg,
+ enable_mask, enable_mask);
+
+ return;
+}
+
+int samsung_clkout_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int parent_mask = BIT(soc_data->mux_width) - 1;
+
+ regmap_update_bits(clkout->regmap, soc_data->reg,
+ parent_mask << soc_data->mux_shift,
+ index << soc_data->mux_shift);
+
+ return 0;
+}
+
+u8 samsung_clkout_get_parent(struct clk_hw *hw)
+{
+ struct samsung_clkout *clkout = to_clk_out(hw);
+ const struct samsung_clkout_soc_data *soc_data = clkout->soc_data;
+ unsigned int parent_mask = BIT(soc_data->mux_width) - 1;
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clkout->regmap, soc_data->reg, &val);
+
+ return (val >> soc_data->mux_shift) & parent_mask;
+}
+
+static const struct clk_ops samsung_clkout_clk_ops = {
[PATCH 3/4] clk: samsung: exynos5250: Add xclkout debug clock
A new clock provider has been added to configure the XCLKOUT debug
clock. Added a minimal implemetation for Exynos5420 clock driver.
Right now, only one valid parent clock from XCLKOUT is defined
in existing clock driver. The driver will be updated later for other
for other parent clocks.
Signed-off-by: Tushar Behera
CC: Tomasz Figa
---
drivers/clk/samsung/clk-exynos5250.c | 14 ++
include/dt-bindings/clock/exynos5250.h |3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index e7ee442..2637aea 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -225,6 +225,13 @@ PNAME(mout_audio2_p) = { "cdclk2", "fin_pll",
"sclk_hdmi27m", "sclk_dptxphy",
PNAME(mout_spdif_p)= { "sclk_audio0", "sclk_audio1", "sclk_audio2",
"spdif_extclk" };
+PNAME(xclkout_p) = {
+ "dummy", "dummy", "dummy", "dummy",
+ "dummy", "dummy", "dummy", "dummy",
+ "dummy", "dummy", "dummy", "dummy",
+ "dummy", "dummy", "dummy", "dummy",
+ "fin_pll", "dummy", "dummy" };
+
/* fixed rate clocks generated outside the soc */
static struct samsung_fixed_rate_clock exynos5250_fixed_rate_ext_clks[]
__initdata = {
FRATE(CLK_FIN_PLL, "fin_pll", NULL, CLK_IS_ROOT, 0),
@@ -236,6 +243,7 @@ static struct samsung_fixed_rate_clock
exynos5250_fixed_rate_clks[] __initdata =
FRATE(0, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 2700),
FRATE(0, "sclk_dptxphy", NULL, CLK_IS_ROOT, 2400),
FRATE(0, "sclk_uhostphy", NULL, CLK_IS_ROOT, 4800),
+ FRATE(0, "dummy", NULL, CLK_IS_ROOT, 0),
};
static struct samsung_fixed_factor_clock exynos5250_fixed_factor_clks[]
__initdata = {
@@ -678,6 +686,10 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static struct samsung_out_clock exynos5250_clkout[] __initdata = {
+ CLKOUT(CLK_XCLKOUT, "xclkout", xclkout_p),
+};
+
static struct of_device_id ext_clk_match[] __initdata = {
{ .compatible = "samsung,clock-xxti", .data = (void *)0, },
{ },
@@ -721,6 +733,8 @@ static void __init exynos5250_clk_init(struct device_node
*np)
ARRAY_SIZE(exynos5250_div_clks));
samsung_clk_register_gate(exynos5250_gate_clks,
ARRAY_SIZE(exynos5250_gate_clks));
+ samsung_clk_register_clkout(np,
+ exynos5250_clkout, ARRAY_SIZE(exynos5250_clkout));
exynos5250_clk_sleep_init();
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 922f2dc..7c1cd0b 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -151,6 +151,9 @@
#define CLK_MDMA0 346
#define CLK_SMMU_MDMA0 347
+/* debug clocks */
+#define CLK_XCLKOUT896
+
/* mux clocks */
#define CLK_MOUT_HDMI 1024
--
1.7.9.5
--
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 4/4] ARM: dts: Add pmu-syscon handle for Exynos5420/Exynos5250 clock
XCLKOUT in Exynos5420/Exynos5250 is controlled through a register in
PMU domain. Pass pmu-syscon handle to the clock driver so that XCLKOUT
can be properly configured.
Signed-off-by: Tushar Behera
CC: Kukjin Kim
---
arch/arm/boot/dts/exynos5250.dtsi |1 +
arch/arm/boot/dts/exynos5420.dtsi |1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..214db94 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -86,6 +86,7 @@
compatible = "samsung,exynos5250-clock";
reg = <0x1001 0x3>;
#clock-cells = <1>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
};
clock_audss: audss-clock-controller@381 {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..489bd08 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -114,6 +114,7 @@
compatible = "samsung,exynos5420-clock";
reg = <0x1001 0x3>;
#clock-cells = <1>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
};
clock_audss: audss-clock-controller@381 {
--
1.7.9.5
--
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 0/4] Add framework to support clkout
The MUX/GATE register for XCLKOUT doesn't resides within PMU domain, this can be accessed through a regmap provided by syscon driver. Adding another clock provider to handle regmap based handing of XCLKOUT. Dependency: 1. [PATCH v3] mfd: syscon: Support early initialization http://article.gmane.org/gmane.linux.kernel/1679446 Also we need to find a suitable place to call early_syscon_init(), after the device tree has been unflattened and before clock initialization. While testing, I called this before of_clk_init() in arch/arm/kernel/time.c, but that place is too generic. Calling anywhere from exynos.c is not working ATM. Tushar Behera (4): clk: samsung: out: Add infrastructure to register CLKOUT clk: samsung: exynos5420: Add xclkout debug clock clk: samsung: exynos5250: Add xclkout debug clock ARM: dts: Add pmu-syscon handle for Exynos5420/Exynos5250 clock arch/arm/boot/dts/exynos5250.dtsi |1 + arch/arm/boot/dts/exynos5420.dtsi |1 + drivers/clk/samsung/Makefile |2 +- drivers/clk/samsung/clk-exynos5250.c | 14 +++ drivers/clk/samsung/clk-exynos5420.c | 14 +++ drivers/clk/samsung/clk-out.c | 181 drivers/clk/samsung/clk.h | 33 ++ include/dt-bindings/clock/exynos5250.h |3 + include/dt-bindings/clock/exynos5420.h |5 +- 9 files changed, 252 insertions(+), 2 deletions(-) create mode 100644 drivers/clk/samsung/clk-out.c -- 1.7.9.5 -- 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: am335x-bone-common: Add i2c2 definition
On Fri 09 May 2014 12:56:23 AM CDT, Matt Ranostay wrote:
> Add missing i2c2 bus define to access various cape and
> prototype/breakout board devices.
>
> Signed-off-by: Matt Ranostay
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 2e7d932..2aedfee 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -84,6 +84,13 @@
> >;
> };
>
> + i2c2_pins: pinmux_i2c2_pins {
> + pinctrl-single,pins = <
> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
> i2c2_sda.uart1_ctsn */
> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
> i2c2_scl.uart1_rtsn */
I dont understand the comment -> i2c2_sda is being muxed to uart1_cstsn?
> + >;
> + };
> +
> uart0_pins: pinmux_uart0_pins {
> pinctrl-single,pins = <
> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> uart0_rxd.uart0_rxd */
> @@ -222,6 +229,15 @@
>
> };
>
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins>;
> +
> + status = "okay";
> + clock-frequency = <40>;
How did we decide on 400KHz -> do all all i2c2 devices on ALL capes
work in full speed? OR should we consider a conservative 100KHz?
> +};
> +
> /include/ "tps65217.dtsi"
>
> &tps {
--
Regards,
Nishanth Menon
--
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] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
Hi,
On Thu, 2014-04-24 at 13:18 -0500, Josh Cartwright wrote:
> On Wed, Apr 23, 2014 at 04:36:22PM -0700, Courtney Cavin wrote:
> > On Wed, Apr 23, 2014 at 11:46:26PM +0200, Josh Cartwright wrote:
> > > On Tue, Apr 22, 2014 at 05:31:49PM -0700, Courtney Cavin wrote:
> [..]
>
> $ git grep spmi-slave-container arch/arm/boot/dts
> arch/arm/boot/dts/qcom/msm-pm8019.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8019.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8110.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8110.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8226.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8226.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8841.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8841.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8916.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8916.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8941.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pm8941.dtsi: spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pma8084.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pma8084.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmd9635.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmd9635.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmi8962.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmi8962.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmiplutonium.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmiplutonium.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmplutonium.dtsi:
> spmi-slave-container;
> arch/arm/boot/dts/qcom/msm-pmplutonium.dtsi:
> spmi-slave-container;
>
> [..]
> > > > +static const struct of_device_id pm8x41_id_table[] = {
> > > > + { .compatible = "qcom,pm8841", },
> > > > + { .compatible = "qcom,pm8941", },
> > > > + {},
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, pm8x41_id_table);
> > >
> > > I'm thinking we should probably have a generic compatible entry as well,
> > > "qcom,pmic-qpnp" or similar. We should still specify in the binding
> > > that PMIC slaves specify a version-specific string as well as the
> > > generic string. That is, a slave should have:
> > >
> > > compatible = "qcom,pm8841", "qcom,pmic-qpnp";
> > >
> > > ...in case we would ever need to differentiate in the future.
> > >
> > > (I recall that in a previous version I had done this, but I don't
> > > remember why I had changed it..)
> >
> > I gave this some thought but came to the conclusion that there is no
> > benefit of adding a generic compatible to a new binding. Please clarify
> > a use-case where this would be ... useful.
>
> Having a generic compatible entry allows for easily supporting new PMICs
> without having to add yet another vacuous entry in the ID table. In
> this case I think it's perfectly acceptable given that this driver isn't
> really defining a programming model for a specific device, but rather
> acting much more like a bus.
>
> Requiring a specific PMIC listed before a generic one allows us an
> escape hatch in the future if for some reason we need to add a quirk for
> a specific PMIC.
Is there a conclusion on this issue? I am voting for generic name :-)
"qcom,pm-qpnp".
Further complication is that several sub function drivers expect to
runtime detect the exact version of the controller ("qcom, qpnp-iadc",
"qcom, qpnp-vadc", "qcom, qpnp-linear-charger"). This is realized by the
exported function of the driver "qcom, qpnp-revid". Would it be good
idea to merge qpnp-revid and "qcom,pm-qpnp" driver?
Regards,
Ivan
>
> Josh
>
> [1]: git://codeaurora.org/quic/la/kernel/msm-3.10#msm-3.10
>
--
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] ARM: dts: sun6i-a31-app4-evb1.dts: Use sunxi-common-regulators.dtsi
Hi,
On 05/09/2014 11:32 AM, Boris BREZILLON wrote:
>
> On 09/05/2014 11:05, Hans de Goede wrote:
>> Hi,
>>
>> On 05/09/2014 10:55 AM, Boris BREZILLON wrote:
>>> On 09/05/2014 10:43, Hans de Goede wrote:
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
index 270ab97..2bbf886 100644
--- a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
+++ b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
@@ -13,6 +13,7 @@
/dts-v1/;
/include/ "sun6i-a31.dtsi"
+/include/ "sunxi-common-regulators.dtsi"
/ {
model = "Allwinner A31 APP4 EVB1 Evaluation Board";
@@ -49,15 +50,8 @@
};
reg_usb1_vbus: usb1-vbus {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
pinctrl-0 = <&usb1_vbus_pin_a>;
- regulator-name = "usb1-vbus";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
gpio = <&pio 7 27 0>;
status = "okay";
};
>>> I guess we could do the same for usb1_vbus_pin_a (keep the common
>>> definition and change the allwinner,pins property).
>> Hmm, what we do with other boards when the pin does not match the
>> default is change the node name to something baord specific, ie
>> usb1_vbus_pin_app4_evb1
>
> Okay.
> How did you decide which pins should be put in the default definitions
> (the most used ones among available boards ?) ?
The pins used there are used on all-most all A10 and A20 boards,
the sun5i (A10s / A13) boards seem to not really have any standard gpio
they use, and I have not seen enough A31 boards yet to say anything sensible.
We may need to rename the standard pins to include the platform name if
A31 also uses the same pin everywhere (but a different one from A10).
> I'm not sure defining new pin states for each board is a good solution,
> because you'll embed unneeded pin states in your DTB.
> Anyway, this is your call :-).
>
>> Which is why I did not remove the common bits from the pin,
>> I did not notice you did not use a board specific name here.
>
> Then I guess it should be fixed in the same series.
> BTW, AFAIK the original patch adding support for the APP4 EVB1 board has
> not been applied yet, so I think we can fix it send a v2 of this patch.
It is already in Maxime's dt-for-3.16 tree, so it is probably better to fix
this with a followup patch.
Regards,
Hans
--
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 5/5] Doc/DT: hdmi-connector: add HPD GPIO documentation
Add binding documentation for HDMI connector's HPD GPIO. Signed-off-by: Tomi Valkeinen Cc: devicetree@vger.kernel.org --- Documentation/devicetree/bindings/video/hdmi-connector.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt index c19e2573..acd5668b1ce1 100644 --- a/Documentation/devicetree/bindings/video/hdmi-connector.txt +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt @@ -7,6 +7,7 @@ Required properties: Optional properties: - label: a symbolic name for the connector +- hpd-gpios: HPD GPIO number Required nodes: - Video port for HDMI input -- 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 0/3] Add Exynos5800 support
Exynos5800 is a derivative of Exynos5420 with higher clock speeds and most other IP blocks remaining the same except for a few. This patchset is based on Kukjin's for-next branch and Tomasz's samsung-next branch containing Shaik's clock cleanup series for 5420. Changes from v1 -- - Rebased on Shaik's clock consolidation for 5420 - Addressed review comments from Tomasz Alim Akhtar (1): clk: exynos5420: Add 5800 specific clocks Arun Kumar K (2): ARM: dts: Add Exynos5800 dt file ARM: dts: Add peach-pi board support .../devicetree/bindings/clock/exynos5420-clock.txt |3 +- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/exynos5800-peach-pi.dts | 144 + arch/arm/boot/dts/exynos5800.dtsi | 24 ++ drivers/clk/samsung/clk-exynos5420.c | 306 include/dt-bindings/clock/exynos5420.h |4 + 6 files changed, 428 insertions(+), 56 deletions(-) create mode 100644 arch/arm/boot/dts/exynos5800-peach-pi.dts create mode 100644 arch/arm/boot/dts/exynos5800.dtsi -- 1.7.9.5 -- 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 2/3] ARM: dts: Add Exynos5800 dt file
Most of the nodes of exynos5420 remains same for exynos5800.
So the exynos5420.dtsi is included in exynos5800 and the changed
node properties will be overriden.
Signed-off-by: Arun Kumar K
Reviewed-by: Tomasz Figa
Acked-by: Olof Johansson
---
No changes from v1
---
arch/arm/boot/dts/exynos5800.dtsi | 24
1 file changed, 24 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5800.dtsi
diff --git a/arch/arm/boot/dts/exynos5800.dtsi
b/arch/arm/boot/dts/exynos5800.dtsi
new file mode 100644
index 000..6979fc7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -0,0 +1,24 @@
+/*
+ * SAMSUNG EXYNOS5800 SoC device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5800 SoC device nodes are listed in this file.
+ * EXYNOS5800 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * 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 "exynos5420.dtsi"
+
+/ {
+ compatible = "samsung,exynos5800", "samsung,exynos5";
+};
+
+&clock {
+ compatible = "samsung,exynos5800-clock";
+};
--
1.7.9.5
--
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 1/3] clk: exynos5420: Add 5800 specific clocks
From: Alim Akhtar
Exynos5800 clock structure is mostly similar to 5420 with only
a small delta changes. So the 5420 clock file is re-used for
5800 also. The common clocks for both are seggreagated and few
clocks which are different for both are separately initialized.
Signed-off-by: Alim Akhtar
Signed-off-by: Arun Kumar K
---
Changes from v1
---
- Rebased on clock cleanup by Shaik
- Added 5800 also to save / restore handling
- Extra 5800 clocks added as now they have common
terminating gates with 5420 (Added by Shaik's series)
---
.../devicetree/bindings/clock/exynos5420-clock.txt |3 +-
drivers/clk/samsung/clk-exynos5420.c | 306
include/dt-bindings/clock/exynos5420.h |4 +
3 files changed, 258 insertions(+), 55 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index ca88c97..d54f42c 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -1,12 +1,13 @@
* Samsung Exynos5420 Clock Controller
The Exynos5420 clock controller generates and supplies clock to various
-controllers within the Exynos5420 SoC.
+controllers within the Exynos5420 SoC and for the Exynos5800 SoC.
Required Properties:
- compatible: should be one of the following.
- "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC.
+ - "samsung,exynos5800-clock" - controller compatible with Exynos5800 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index e576456..d7dedd9 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -57,15 +57,19 @@
#define SRC_TOP5 0x10214
#define SRC_TOP6 0x10218
#define SRC_TOP7 0x1021c
+#define SRC_TOP8 0x10220 /* 5800 specific */
+#define SRC_TOP9 0x10224 /* 5800 specific */
#define SRC_DISP10 0x1022c
#define SRC_MAU0x10240
#define SRC_FSYS 0x10244
#define SRC_PERIC0 0x10250
#define SRC_PERIC1 0x10254
#define SRC_ISP0x10270
+#define SRC_CAM0x10274 /* 5800 specific */
#define SRC_TOP10 0x10280
#define SRC_TOP11 0x10284
#define SRC_TOP12 0x10288
+#define SRC_TOP13 0x1028c /* 5800 specific */
#define SRC_MASK_TOP2 0x10308
#define SRC_MASK_TOP7 0x1031c
#define SRC_MASK_DISP100x1032c
@@ -76,6 +80,8 @@
#define DIV_TOP0 0x10500
#define DIV_TOP1 0x10504
#define DIV_TOP2 0x10508
+#define DIV_TOP8 0x10520 /* 5800 specific */
+#define DIV_TOP9 0x10524 /* 5800 specific */
#define DIV_DISP10 0x1052c
#define DIV_MAU0x10544
#define DIV_FSYS0 0x10548
@@ -86,6 +92,7 @@
#define DIV_PERIC2 0x10560
#define DIV_PERIC3 0x10564
#define DIV_PERIC4 0x10568
+#define DIV_CAM0x10574 /* 5800 specific */
#define SCLK_DIV_ISP0 0x10580
#define SCLK_DIV_ISP1 0x10584
#define DIV2_RATIO00x10590
@@ -102,6 +109,7 @@
#define GATE_TOP_SCLK_ISP 0x10870
#define GATE_IP_GSCL0 0x10910
#define GATE_IP_GSCL1 0x10920
+#define GATE_IP_CAM0x10924 /* 5800 specific */
#define GATE_IP_MFC0x1092c
#define GATE_IP_DISP1 0x10928
#define GATE_IP_G3D0x10930
@@ -123,23 +131,31 @@
#define SRC_KFC0x28200
#define DIV_KFC0 0x28500
+/* Exynos5x SoC type */
+enum exynos5x_soc {
+ EXYNOS5420,
+ EXYNOS5800,
+};
+
/* list of PLLs */
-enum exynos5420_plls {
+enum exynos5x_plls {
apll, cpll, dpll, epll, rpll, ipll, spll, vpll, mpll,
bpll, kpll,
nr_plls /* number of PLLs */
};
static void __iomem *reg_base;
+static enum exynos5x_soc exynos5x_soc;
#ifdef CONFIG_PM_SLEEP
-static struct samsung_clk_reg_dump *exynos5420_save;
+static struct samsung_clk_reg_dump *exynos5x_save;
+static struct samsung_clk_reg_dump *exynos5800_save;
/*
* list of controller registers to be saved and restored during a
* suspend/resume cycle.
*/
-static unsigned long exynos5420_clk_regs[] __initdata = {
+static unsigned long exynos5x_clk_regs[] __initdata = {
SRC_CPU,
DIV_CPU0,
DIV_CPU1,
@@ -222,18 +238,37 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_KFC0,
};
+static unsigned long exynos5800_clk_regs[] __initdata = {
+ SRC_TOP8,
+ SRC_TOP9,
+ SRC_CAM,
+ SRC_TOP1,
+ DIV_TOP8,
+
[PATCH v2 3/3] ARM: dts: Add peach-pi board support
Adds support for google peach-pi board having the
Exynos5800 SoC.
Signed-off-by: Arun Kumar K
Signed-off-by: Doug Anderson
Reviewed-by: Tomasz Figa
---
Changes from v1
- Updated memory node with a safe size of 2GB
---
arch/arm/boot/dts/Makefile|3 +-
arch/arm/boot/dts/exynos5800-peach-pi.dts | 144 +
2 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/exynos5800-peach-pi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a934648..cd399a2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -77,7 +77,8 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
- exynos5440-ssdk5440.dtb
+ exynos5440-ssdk5440.dtb \
+ exynos5800-peach-pi.dtb
dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb
dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
ecx-2000.dtb
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
new file mode 100644
index 000..4ed9ccc
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -0,0 +1,144 @@
+/*
+ * Google Peach Pi Rev 10+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include
+#include
+#include "exynos5800.dtsi"
+
+/ {
+ model = "Google Peach Pi Rev 10+";
+
+ compatible = "google,pi-rev16",
+ "google,pi-rev15", "google,pi-rev14",
+ "google,pi-rev13", "google,pi-rev12",
+ "google,pi-rev11", "google,pi-rev10",
+ "google,pi", "google,peach", "samsung,exynos5800",
+ "samsung,exynos5";
+
+ memory {
+ reg = <0x2000 0x8000>;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = "samsung,exynos5420-oscclk";
+ clock-frequency = <2400>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&power_key_irq>;
+
+ power {
+ label = "Power";
+ gpios = <&gpx1 2 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ gpio-key,wakeup;
+ };
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 100 0>;
+ brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
+ default-brightness-level = <7>;
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ };
+};
+
+&pinctrl_0 {
+ tpm_irq: tpm-irq {
+ samsung,pins = "gpx1-0";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ power_key_irq: power-key-irq {
+ samsung,pins = "gpx1-2";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&rtc {
+ status = "okay";
+};
+
+&uart_3 {
+ status = "okay";
+};
+
+&mmc_0 {
+ status = "okay";
+ num-slots = <1>;
+ broken-cd;
+ caps2-mmc-hs200-1_8v;
+ supports-highspeed;
+ non-removable;
+ card-detect-delay = <200>;
+ clock-frequency = <4>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <0 4>;
+ samsung,dw-mshc-ddr-timing = <0 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+};
+
+&mmc_2 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ card-detect-delay = <200>;
+ clock-frequency = <4>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&hsi2c_9 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ tpm@20 {
+ compatible = "infineon,slb9645tt";
+ reg = <0x20>;
+ /* Unused irq; but still need to configure the pins */
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpm_irq>;
+ };
+};
+
+/*
+ * Use longest HW watchdog in SoC (32 seconds) since the hardware
+ * watchdog provides no debugging information (compared to soft/hard
+
Re: [PATCH RFC v3 3/6] drivers: cpuidle: implement OF based idle states infrastructure
On Fri, May 09, 2014 at 12:12:19AM +0100, Sebastian Capella wrote:
> Quoting Lorenzo Pieralisi (2014-05-06 11:04:40)
>
> > diff --git a/drivers/cpuidle/of_idle_states.c
> > b/drivers/cpuidle/of_idle_states.c
> > new file mode 100644
> > index 000..360b7ad
> > --- /dev/null
> > +++ b/drivers/cpuidle/of_idle_states.c
> > @@ -0,0 +1,293 @@
> ...
> > +static int __init add_state_node(cpumask_t *cpumask,
> > +struct device_node *state_node)
> > +{
> > + struct state_elem *el;
> > + u32 tmp, val = 0;
> > +
> > + pr_debug(" * %s...\n", state_node->full_name);
> > +
> > + if (!state_cpus_valid(cpumask, state_node))
> > + return -EINVAL;
> > + /*
> > +* Parse just the properties required to sort the states.
> > +* Since we are missing a value defining the energy
> > +* efficiency of a state, for now the sorting code uses
> > +*
> > +* min-residency-us+exit-latency-us
> > +*
> > +* as sorting rank.
> > +*/
> > + if (of_property_read_u32(state_node, "min-residency-us",
> > +&tmp)) {
> > + pr_debug(" * %s missing min-residency-us property\n",
> > +state_node->full_name);
> > + return -EINVAL;
> > + }
> > +
> > + val += tmp;
> > +
> > + if (of_property_read_u32(state_node, "exit-latency-us",
> > +&tmp)) {
> > + pr_debug(" * %s missing exit-latency-us property\n",
> > +state_node->full_name);
> > + return -EINVAL;
> > + }
> > +
> > + val += tmp;
>
> Sorry if i'm rehashing old stuff, but I prefer not to use the
> min-residency + exit-latency to sort. I saw Rob's comment suggesting it
> and your reply. I'm not sure when it was decided.
>
> Would it be possible to sort instead based on the order in the
> cpus->cpu-idle-states? If not, my preference would be to either use
> index like you had before, or specify another sort order / rank value.
>
> I think there's potential for us to create lower power states that
> have lower min-residencies (reduced power consumption in the state,
> allowing us to more quickly recover the higher entrance cost)
> with higher exit latencies in such a way that the formula would not
> sort as we expect. Having a separate value would allow us to control
> the sorting in those cases.
Ok, so adding to my previous comment, would exit_latency by itself be
enough ? Can we think of a system where ranking by exit_latency is wrong ?
If yes, we need a power rank, and this patch is wrong too:
http://marc.info/?l=linux-kernel&m=139924292401056&w=2
If answer is not, I can just rely on exit_latency to sort the states.
Lorenzo
--
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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
Hi, On Thursday 08 May 2014 02:48 PM, Arnd Bergmann wrote: > On Thursday 08 May 2014 18:05:11 Jingoo Han wrote: >> On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: >>> On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas Cc: Marek Vasut Signed-off-by: Kishon Vijay Abraham I Acked-by: Jingoo Han Acked-by: Mohit Kumar >>> >>> Sorry, but NAK. >>> >>> We have a standard 'dma-ranges' property to handle this, so use it. >>> >>> See the x-gene PCIe driver patches for an example. Please also talk >>> to Santosh about it, as he is implementing generic support for >>> parsing dma-ranges in platform devices at the moment. >> >> Hi Arnd, >> >> Do you mean the following patch? >> http://www.spinics.net/lists/kernel/msg1737725.html >> > > That is the patch Santosh did for platform devices, which is related but not > what I meant here. For the PCI inbound window setup, please have a look > at https://lkml.org/lkml/2014/3/19/607 For some reason lkml is not showing any contents. Do you have a different link? Thanks Kishon -- 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 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
Hi Arnd,
On Wednesday 07 May 2014 03:00 PM, Arnd Bergmann wrote:
> On Wednesday 07 May 2014 14:14:55 Kishon Vijay Abraham I wrote:
+static void dra7xx_pcie_enable_interrupts(struct pcie_port *pp)
+{
+struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+
+dra7xx_pcie_writel(dra7xx->base, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN,
+ ~INTERRUPTS);
+dra7xx_pcie_writel(dra7xx->base,
+ PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN,
INTERRUPTS);
+dra7xx_pcie_writel(dra7xx->base, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI,
+ ~LEG_EP_INTERRUPTS & ~MSI);
+
+if (IS_ENABLED(CONFIG_PCI_MSI))
+dra7xx_pcie_writel(dra7xx->base,
+ PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
MSI);
+else
+dra7xx_pcie_writel(dra7xx->base,
+ PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
+ LEG_EP_INTERRUPTS);
>>>
>>> Doesn't this just enable one or the other? In general I'd assume you need
>>> both INTx and MSI, at least if MSI is available.
>>
>> Not sure since the programming sequence in the TRM explicitly states either
>> legacy interrupts or MSI interrupts should be enabled but not both.
>
> Hmm, I think that means you can't have MSI at all. You have to support
> legacy PCI devices that can't do MSI.
>
> Do you know if you have a modern GIC implementation with MSI support
> in these SoCs? It would be better anyway to use the GIC for doing
In DRA7 it is not there. I'm not sure in other platforms.
> MSI, so you can just ignore the internal MSI controller here.
>
+static int add_pcie_port(struct dra7xx_pcie *dra7xx,
+ struct platform_device *pdev)
+{
+int ret;
+struct pcie_port *pp;
+struct resource *res;
+struct device *dev = &pdev->dev;
+
+pp = &dra7xx->pp;
+pp->dev = dev;
+pp->ops = &dra7xx_pcie_host_ops;
+
+spin_lock_init(&pp->conf_lock);
+
+pp->irq = platform_get_irq(pdev, 1);
+if (pp->irq < 0) {
+dev_err(dev, "missing IRQ resource\n");
+return -EINVAL;
+}
>>>
>>> The binding does not list a mandatory "interrupts" property, so
>>> this should not be treated as an error.
>>
>> actually the 'interrupts' property is documented in pci/designware-pcie.txt.
>
> Hmm, but you don't seem to use it the same way as documented there.
> I'm not sure what 'level interrupt, pulse interrupt, special interrupt'
> in the parent binding are, but they don't seem to be the ones you use
> here.
Yeah. I'll update my Documentation. Thanks for pointing this out.
Thanks
Kishon
--
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: am335x-evmsk enable display and lcd panel support
On 06/05/14 19:10, Tony Lindgren wrote: > * Darren Etheridge [140422 13:39]: >> Add the necessary nodes to enable the LCD controller and the >> LCD panel that is attached to the Texas Instruments AM335x >> EVMSK platform. Also setup the necessary pin mux within the >> DT file to drive the LCD connector and add the correct >> pinmux settings for the lcd pins to be configured to when >> the SoC goes into sleep state for the minimum power >> consumption. >> >> For the sleep mode LCD pin settings, MUX_MODE7 is chosen as >> this corresponds to switching the pins into input GPIO's with >> an internal pulldown. Which has been determined to offer the >> lowest power solution vs leaving the pins configured in LCD >> mode. > > Probably best that Tomi queues all the panel .dts changes into > a separate immutable branch that I can merge too. This is not for OMAP DSS, but for the LCDC used in beaglebone, so there are no dependencies to any of my work. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC] Describing arbitrary bus mastering relationships in DT
On Friday 09 May 2014 11:33:18 Dave Martin wrote: > On Mon, May 05, 2014 at 05:14:44PM +0200, Arnd Bergmann wrote: > > On Friday 02 May 2014 18:43:01 Dave Martin wrote: > > > My expectation was that we do some check when probing a device to figure > > > out the path from the device to main memory, thus figuring out the dma > > > mask, the IOMMU (if any) and any relevant device ID. This is a bit more > > > complex than the existing situation, but I still think we could have > > > common code for the bulk of it. > > > > I'd still prefer if we could keep following just "dma-ranges" to find > > a path from device to memory, with an extension to handle IOMMUs etc, > > but not describe the things to the extend that your proposal does. > > This is really a simplification. If we only had to consider the path > from devices to memory, and if the pretence that the memory is at / > works (almost always true, at least for general-purpose memory), then > we often have a simpler problem. It is still not always solvable > though, since a device could still have a unique access path with > unique mappings that cannot be described in terms of any of the other > paths. > > However, this is not just about DMA any more. Devices also master onto > interrupt controllers to generate MSIs, onto IOMMUs to provide them > with address space remapping, onto other devices via IOMMUs; and GPUs > can master onto all kinds of things. > > The alternative to a completely generic description of bus mastering > would be to consider the specific things that we are interested in > allowing devices to master on, and describe the whole end-to-end > link for each in the bus master's node. > > * memory > * interrupt controllers (for MSIs) > * IOMMUs Right. The "memory" and "IOMMU" targets are really variations of the same theme here: The one place we need to know about how to access main memory is when we set up the dma_map_ops, and we already need to know a number of things there: - coherency - bus offsets - swiotlb range, if needed - which IOMMU, if any MSI also seems like something that is worth treating special, in particular since the ARM implementation so much unlike everybody else's and we need to have a way to give a consistent API to device drivers. > This could lead to combinatorial blow-up as the number of target > devices grows, since these linkages have to be re-described for > every bus master -- especially for GPUs which could do a fair amount of > device control by themselves. It could also lead to fragmentation > as each binding solves common problems in different ways. If the linkage is the same for multiple devices on the same bus, I think we can always do it the traditional way using dma-ranges on the parent bus. > The downside is that is any path flows through a dynamically > configurable component, such as an IOMMU or a bridge that can be > remapped, turned off etc., then unless we describe how the path is > really linked together the kernel will need all sorts of baked-in > knowledge in order to manage the system safely. The _effect_ of the > problem component on the path is not static, so we can't describe > that effect directly in the DT. For truly weird features that are > unique to a particular platform that's OK, but "how devices are > linked together" seems a much more general and useful concept than that. My feeling is that this belongs in the same category as for example PCI bus windows or pin control: while in theory we could describe in DT exactly what the hardware is capable of and let the kernel decide how to do it, this is much too complicated in practice, so we are better off describing in DT how we /want/ things to be set up, or how things are already set up by the firmware and not to be touched. > > We already pretend that things are a tree for the purposes of MMIO, > > which is probably still close enough for the vast majority of cases. > > For simplicity, I'd actually prefer keeping the illusion that MMIO > > and DMA are two different things, which matches how operating systems > > see things even if it's no longer true for the hardware. > > > > > If a device has different roles with completely different paths to > > > memory, one option could be for the driver to instantiate two devices in > > > the kernel. This puts the burden on the driver for the device, instead > > > of the core framework. > > > > Yes, this is what I suggested earlier as well. > > I may have missed your point slightly before. Anyway, I think the > "multiple master roles" issue is sufficiently unusual that describing > them using multiple device nodes in the DT is reasonable. So I think > I'm happy to get rid of the ability to specify and distinguish multiple > roles within a single device node. Ok. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] mfd: add support for sun6i PRCM (Power/Reset/Clock Management) unit
The PRCM (Power/Reset/Clock Management) block exposes several subdevices
in different subsystems (clk, reset ...)
Add basic support for the PRCM unit with clk (AR100, AHB0, and APB0 clks)
and reset controller subdevices.
Other subdevices might be added later (if needed).
Signed-off-by: Boris BREZILLON
Acked-by: Maxime Ripard
---
drivers/mfd/Kconfig | 8 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/sun6i-prcm.c | 134 +++
3 files changed, 143 insertions(+)
create mode 100644 drivers/mfd/sun6i-prcm.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2d347c9..56794fe 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -731,6 +731,14 @@ config MFD_STA2X11
select MFD_CORE
select REGMAP_MMIO
+config MFD_SUN6I_PRCM
+ bool "Allwinner A31 PRCM controller"
+ depends on ARCH_SUNXI
+ select MFD_CORE
+ help
+ Support for the PRCM (Power/Reset/Clock Management) unit available
+ in A31 SoC.
+
config MFD_SYSCON
bool "System Controller Register R/W Based on Regmap"
select REGMAP_MMIO
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1efecf2..df7823c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MFD_STA2X11) += sta2x11-mfd.o
obj-$(CONFIG_MFD_STMPE)+= stmpe.o
obj-$(CONFIG_STMPE_I2C)+= stmpe-i2c.o
obj-$(CONFIG_STMPE_SPI)+= stmpe-spi.o
+obj-$(CONFIG_MFD_SUN6I_PRCM) += sun6i-prcm.o
obj-$(CONFIG_MFD_TC3589X) += tc3589x.o
obj-$(CONFIG_MFD_T7L66XB) += t7l66xb.o tmio_core.o
obj-$(CONFIG_MFD_TC6387XB) += tc6387xb.o tmio_core.o
diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
new file mode 100644
index 000..718fc4d
--- /dev/null
+++ b/drivers/mfd/sun6i-prcm.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Boris BREZILLON
+ *
+ * Allwinner PRCM (Power/Reset/Clock Management) driver
+ *
+ */
+
+#include
+#include
+#include
+
+struct prcm_data {
+ int nsubdevs;
+ const struct mfd_cell *subdevs;
+};
+
+static const struct resource sun6i_a31_ar100_clk_res[] = {
+ {
+ .start = 0x0,
+ .end = 0x3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static const struct resource sun6i_a31_apb0_clk_res[] = {
+ {
+ .start = 0xc,
+ .end = 0xf,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static const struct resource sun6i_a31_apb0_gates_clk_res[] = {
+ {
+ .start = 0x28,
+ .end = 0x2b,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static const struct resource sun6i_a31_apb0_rstc_res[] = {
+ {
+ .start = 0xb0,
+ .end = 0xb3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
+ {
+ .name = "sun6i-a31-ar100-clk",
+ .of_compatible = "allwinner,sun6i-a31-ar100-clk",
+ .num_resources = ARRAY_SIZE(sun6i_a31_ar100_clk_res),
+ .resources = sun6i_a31_ar100_clk_res,
+ },
+ {
+ .name = "sun6i-a31-apb0-clk",
+ .of_compatible = "allwinner,sun6i-a31-apb0-clk",
+ .num_resources = ARRAY_SIZE(sun6i_a31_apb0_clk_res),
+ .resources = sun6i_a31_apb0_clk_res,
+ },
+ {
+ .name = "sun6i-a31-apb0-gates-clk",
+ .of_compatible = "allwinner,sun6i-a31-apb0-gates-clk",
+ .num_resources = ARRAY_SIZE(sun6i_a31_apb0_gates_clk_res),
+ .resources = sun6i_a31_apb0_gates_clk_res,
+ },
+ {
+ .name = "sun6i-a31-apb0-clock-reset",
+ .of_compatible = "allwinner,sun6i-a31-clock-reset",
+ .num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
+ .resources = sun6i_a31_apb0_rstc_res,
+ },
+};
+
+static const struct prcm_data sun6i_a31_prcm_data = {
+ .nsubdevs = ARRAY_SIZE(sun6i_a31_prcm_subdevs),
+ .subdevs = sun6i_a31_prcm_subdevs,
+};
+
+static const struct of_device_id sun6i_prcm_dt_ids[] = {
+ {
+ .compatible = "allwinner,sun6i-a31-prcm",
+ .data = &sun6i_a31_prcm_data,
+ },
+ { /* sentinel */ },
+};
+
+static int sun6i_prcm_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match;
+ const struct prcm_data *data;
+ struct resource *res;
+ int ret;
+
+ match = of_match_node(sun6i_prcm_dt_ids, np);
+ if (!match)
+ return -EINVAL;
+
+ data = match->data;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "no prcm memory region provided\n");
+
[PATCH v3 2/7] reset: sunxi: allow MFD subdevices probe
The current implementation uses sunxi_reset_init function for both early
init and platform device probe.
The sunxi_reset_init function uses DT to retrieve device resources, which
will be an issue if reset controllers are registered from an MFD device
that define resources from mfd_cell definition.
Moreover, we can make of devm functions when we're in the probe context.
Signed-off-by: Boris BREZILLON
Acked-by: Maxime Ripard
---
drivers/reset/reset-sunxi.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/reset/reset-sunxi.c b/drivers/reset/reset-sunxi.c
index 695bd34..a94e7a7 100644
--- a/drivers/reset/reset-sunxi.c
+++ b/drivers/reset/reset-sunxi.c
@@ -145,7 +145,24 @@ MODULE_DEVICE_TABLE(of, sunxi_reset_dt_ids);
static int sunxi_reset_probe(struct platform_device *pdev)
{
- return sunxi_reset_init(pdev->dev.of_node);
+ struct sunxi_reset_data *data;
+ struct resource *res;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->membase))
+ return PTR_ERR(data->membase);
+
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.nr_resets = resource_size(res) * 32;
+ data->rcdev.ops = &sunxi_reset_ops;
+ data->rcdev.of_node = pdev->dev.of_node;
+
+ return reset_controller_register(&data->rcdev);
}
static int sunxi_reset_remove(struct platform_device *pdev)
@@ -153,8 +170,6 @@ static int sunxi_reset_remove(struct platform_device *pdev)
struct sunxi_reset_data *data = platform_get_drvdata(pdev);
reset_controller_unregister(&data->rcdev);
- iounmap(data->membase);
- kfree(data);
return 0;
}
--
1.8.3.2
--
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 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support
The PRCM (Power/Reset/Clock Management) unit provides several clock
devices:
- AR100 clk: used to clock the Power Management co-processor
- AHB0 clk: used to clock the AHB0 bus
- APB0 clk and gates: used to clk peripherals connected to the APB0 bus
Add support for these clks in a separate driver so that they can be probed
as platform devices instead of registered during early init.
This is needed to be able to probe PRCM MFD subdevices.
Signed-off-by: Boris BREZILLON
Acked-by: Maxime Ripard
---
drivers/clk/sunxi/Makefile | 2 +
drivers/clk/sunxi/clk-sun6i-prcm.c | 343 +
2 files changed, 345 insertions(+)
create mode 100644 drivers/clk/sunxi/clk-sun6i-prcm.c
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index b5bac91..ef8cdc9 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -3,3 +3,5 @@
#
obj-y += clk-sunxi.o clk-factors.o
+
+obj-$(CONFIG_MFD_SUN6I_PRCM) += clk-sun6i-prcm.o
diff --git a/drivers/clk/sunxi/clk-sun6i-prcm.c
b/drivers/clk/sunxi/clk-sun6i-prcm.c
new file mode 100644
index 000..3efaf8f
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun6i-prcm.c
@@ -0,0 +1,343 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Boris BREZILLON
+ *
+ * Allwinner PRCM (Power/Reset/Clock Management) driver
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#define SUN6I_APB0_GATES_MAX_SIZE 32
+#define SUN6I_AR100_MAX_PARENTS4
+#define SUN6I_AR100_SHIFT_MASK 0x3
+#define SUN6I_AR100_SHIFT_MAX SUN6I_AR100_SHIFT_MASK
+#define SUN6I_AR100_SHIFT_SHIFT4
+#define SUN6I_AR100_DIV_MASK 0x1f
+#define SUN6I_AR100_DIV_MAX(SUN6I_AR100_DIV_MASK + 1)
+#define SUN6I_AR100_DIV_SHIFT 8
+#define SUN6I_AR100_MUX_MASK 0x3
+#define SUN6I_AR100_MUX_SHIFT 16
+
+struct ar100_clk {
+ struct clk_hw hw;
+ void __iomem *reg;
+};
+
+static inline struct ar100_clk *to_ar100_clk(struct clk_hw *hw)
+{
+ return container_of(hw, struct ar100_clk, hw);
+}
+
+static unsigned long ar100_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct ar100_clk *clk = to_ar100_clk(hw);
+ u32 val = readl(clk->reg);
+ int shift = (val >> SUN6I_AR100_SHIFT_SHIFT) & SUN6I_AR100_SHIFT_MASK;
+ int div = (val >> SUN6I_AR100_DIV_SHIFT) & SUN6I_AR100_DIV_MASK;
+
+ return (parent_rate >> shift) / (div + 1);
+}
+
+static long ar100_determine_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *best_parent_rate,
+struct clk **best_parent_clk)
+{
+ int nparents = __clk_get_num_parents(hw->clk);
+ long best_rate = -EINVAL;
+ int i;
+
+ *best_parent_clk = NULL;
+
+ for (i = 0; i < nparents; i++) {
+ unsigned long parent_rate;
+ unsigned long tmp_rate;
+ struct clk *parent;
+ unsigned long div;
+ int shift;
+
+ parent = clk_get_parent_by_index(hw->clk, i);
+ parent_rate = __clk_get_rate(parent);
+ div = DIV_ROUND_UP(parent_rate, rate);
+
+ shift = ffs(div) - 1;
+ if (shift > SUN6I_AR100_SHIFT_MAX)
+ shift = SUN6I_AR100_SHIFT_MAX;
+
+ div >>= shift;
+
+ while (div > SUN6I_AR100_DIV_MAX) {
+ shift++;
+ div >>= 1;
+ if (shift > SUN6I_AR100_SHIFT_MAX)
+ break;
+ }
+
+ if (shift > SUN6I_AR100_SHIFT_MAX)
+ continue;
+
+ tmp_rate = (parent_rate >> shift) / div;
+ if (!*best_parent_clk || tmp_rate > best_rate) {
+ *best_parent_clk = parent;
+ *best_parent_rate = parent_rate;
+ best_rate = tmp_rate;
+ }
+ }
+
+ return best_rate;
+}
+
+static int ar100_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct ar100_clk *clk = to_ar100_clk(hw);
+ u32 val = readl(clk->reg);
+
+ if (index >= SUN6I_AR100_MAX_PARENTS)
+ return -EINVAL;
+
+ val &= ~(SUN6I_AR100_MUX_MASK << SUN6I_AR100_MUX_SHIFT);
+ val |= (index << SUN6I_AR100_MUX_SHIFT);
+ writel(val, clk->reg);
+
+ return 0;
+}
+
+static u8 ar100_get_parent(struct clk_hw *hw)
+{
+ struct ar100_clk *clk = to_ar100_clk(hw);
+ return (readl(clk->reg) >> SUN6I_AR100_MUX_SHIFT) &
+ SUN6I_AR100_MUX_MASK;
+}
+
+static int ar100_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ unsigned long div = parent_rate / rate;
+ struct ar100_clk *clk = to_ar100_clk(hw);
+ u32 val = readl(clk->reg)
[PATCH v3 4/7] mfd: sun6i-prcm: document DT bindings
Document DT bindings of the PRCM (Power/Reset/Clock Management) unit.
Signed-off-by: Boris BREZILLON
---
.../devicetree/bindings/mfd/sun6i-prcm.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
new file mode 100644
index 000..1f5a31f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
@@ -0,0 +1,59 @@
+* Allwinner PRCM (Power/Reset/Clock Management) Multi-Functional Device
+
+PRCM is an MFD device exposing several Power Management related devices
+(like clks and reset controllers).
+
+Required properties:
+ - compatible: "allwinner,sun6i-a31-prcm"
+ - reg: The PRCM registers range
+
+The prcm node may contain several subdevices definitions:
+ - see Documentation/devicetree/clk/sunxi.txt for clock devices
+ - see Documentation/devicetree/reset/allwinner,sunxi-clock-reset.txt for reset
+ controller devices
+
+
+Example:
+
+ prcm: prcm@01f01400 {
+ compatible = "allwinner,sun6i-a31-prcm";
+ reg = <0x01f01400 0x200>;
+
+ /* Put subdevices here */
+ ar100: ar100_clk {
+ compatible = "allwinner,sun6i-a31-ar100-clk";
+ #clock-cells = <0>;
+ clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+ };
+
+ ahb0: ahb0_clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <&ar100_div>;
+ clock-output-names = "ahb0";
+ };
+
+ apb0: apb0_clk {
+ compatible = "allwinner,sun6i-a31-apb0-clk";
+ #clock-cells = <0>;
+ clocks = <&ahb0>;
+ clock-output-names = "apb0";
+ };
+
+ apb0_gates: apb0_gates_clk {
+ compatible = "allwinner,sun6i-a31-apb0-gates-clk";
+ #clock-cells = <1>;
+ clocks = <&apb0>;
+ clock-output-names = "apb0_pio", "apb0_ir",
+ "apb0_timer01", "apb0_p2wi",
+ "apb0_uart", "apb0_1wire",
+ "apb0_i2c";
+ };
+
+ apb0_rst: apb0_rst {
+ compatible = "allwinner,sun6i-a31-clock-reset";
+ #reset-cells = <1>;
+ };
+ };
--
1.8.3.2
--
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
