[PATCH 1/2] ARM: dts: dra72-evm: Enable I2C1 node
From: Keerthy J j-keer...@ti.com
I2C1 bus is used for the following peripherals
P8 connector (MLB)
TLV320AIC3106 Audio codec
J15 LCD header
24WC256 eeprom
TMP102AIDRLT temperature sensor
PCF8575 GPIO expander
PCA9306 i2c voltage translator - Goes to P9 for comm interface
P2 expansion connector
TPS65917 PMIC
The slowest speed of all the peripherals seems to be 400KHz.
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 5147023..1e12862 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,22 @@
};
};
+dra7_pmx_core {
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x400 (PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
+ 0x404 (PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
+ ;
+ };
+};
+
+i2c1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+ clock-frequency = 40;
+};
+
uart1 {
status = okay;
};
--
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 0/2] ARM: dts: dra72-evm: Add i2c1 and tps65917 nodes
On Monday 28 July 2014 11:48 AM, Keerthy wrote: The patch series adds i2c1 and tps65917 and related nodes. The patch series is boot tested on DRA72-EVM. Thanks to Lokesh lokeshvu...@ti.com for testing the series. For booting, this is dependent on recent hwmod fix patch series posted by me: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg108001.html Boot log for this series can be found here: http://paste.ubuntu.com/7881545/ Thanks and regards, Lokesh Keerthy J (2): ARM: dts: dra72-evm: Enable I2C1 node ARM: dts: dra72-evm: Add tps65917 PMIC node arch/arm/boot/dts/dra72-evm.dts | 120 +++ 1 file changed, 120 insertions(+) -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] media: atmel-isi: add primary DT support
This patch add the DT support for Atmel ISI driver.
It use the same v4l2 DT interface that defined in video-interfaces.txt.
Signed-off-by: Josh Wu josh...@atmel.com
Cc: devicetree@vger.kernel.org
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
v3 - v4:
When bus width is 10, we support both 8 10 bits.
Use of_match_ptr().
refine the error message.
v2 - v3:
add bus-width property support.
add error handling when calling atmel_isi_probe_dt().
v1 - v2:
refine the binding document.
add port node description.
removed the optional property.
.../devicetree/bindings/media/atmel-isi.txt| 51 +
drivers/media/platform/soc_camera/atmel-isi.c | 65 +-
2 files changed, 114 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt
b/Documentation/devicetree/bindings/media/atmel-isi.txt
new file mode 100644
index 000..17e71b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
@@ -0,0 +1,51 @@
+Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
+--
+
+Required properties:
+- compatible: must be atmel,at91sam9g45-isi
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the ISI;
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names: must contain isi_clk, which is the isi peripherial clock.
+
+ISI supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+ isi: isi@f0034000 {
+ compatible = atmel,at91sam9g45-isi;
+ reg = 0xf0034000 0x4000;
+ interrupts = 37 IRQ_TYPE_LEVEL_HIGH 5;
+
+ clocks = isi_clk;
+ clock-names = isi_clk;
+
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ isi_0: endpoint {
+ remote-endpoint = ov2640_0;
+ bus-width = 8;
+ };
+ };
+ };
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = omnivision,ov2640;
+ reg = 0x30;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 74af560..e5c1fcf 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -25,6 +25,7 @@
#include media/atmel-isi.h
#include media/soc_camera.h
#include media/soc_mediabus.h
+#include media/v4l2-of.h
#include media/videobuf2-dma-contig.h
#define MAX_BUFFER_NUM 32
@@ -33,6 +34,7 @@
#define VID_LIMIT_BYTES(16 * 1024 * 1024)
#define MIN_FRAME_RATE 15
#define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
+#define ISI_DEFAULT_MCLK_FREQ 2500
/* Frame buffer descriptor */
struct fbd {
@@ -883,6 +885,51 @@ static int atmel_isi_remove(struct platform_device *pdev)
return 0;
}
+static int atmel_isi_probe_dt(struct atmel_isi *isi,
+ struct platform_device *pdev)
+{
+ struct device_node *np= pdev-dev.of_node;
+ struct v4l2_of_endpoint ep;
+ int err;
+
+ /* Default settings for ISI */
+ isi-pdata.full_mode = 1;
+ isi-pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
+ isi-pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
+
+ np = of_graph_get_next_endpoint(np, NULL);
+ if (!np) {
+ dev_err(pdev-dev, Could not find the endpoint\n);
+ return -EINVAL;
+ }
+
+ err = v4l2_of_parse_endpoint(np, ep);
+ if (err) {
+ dev_err(pdev-dev, Could not parse the endpoint\n);
+ goto err_probe_dt;
+ }
+
+ switch (ep.bus.parallel.bus_width) {
+ case 8:
+ isi-pdata.data_width_flags = ISI_DATAWIDTH_8;
+ break;
+ case 10:
+ isi-pdata.data_width_flags =
+ ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
+ break;
+ default:
+ dev_err(pdev-dev, Unsupported bus width: %d\n,
+ ep.bus.parallel.bus_width);
+
[PATCH v4 6/6] ARM: sunxi: Add A31 RTC driver to multi_v7_defconfig
Now that we have a driver for A31's RTC, enable it in multi_v7_defconfig. Signed-off-by: Chen-Yu Tsai w...@csie.org --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index a62ca27..130dd8d 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -346,6 +346,7 @@ CONFIG_RTC_DRV_TPS65910=y CONFIG_RTC_DRV_EM3027=y CONFIG_RTC_DRV_PL031=y CONFIG_RTC_DRV_VT8500=y +CONFIG_RTC_DRV_SUN6I=y CONFIG_RTC_DRV_SUNXI=y CONFIG_RTC_DRV_MV=y CONFIG_RTC_DRV_TEGRA=y -- 2.0.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 v4 3/6] ARM: dts: sun6i: add rtc device node
Now that we have a driver for sun6i's rtc hardware, add a device node
for it so we can use it.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun6i-a31.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 44b07e5..6a16019 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -779,6 +779,12 @@
interrupts = 1 9 0xf04;
};
+ rtc: rtc@01f0 {
+ compatible = allwinner,sun6i-a31-rtc;
+ reg = 0x01f0 0x54;
+ interrupts = 0 40 4;
+ };
+
nmi_intc: interrupt-controller@01f00c0c {
compatible = allwinner,sun6i-a31-sc-nmi;
interrupt-controller;
--
2.0.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 v4 5/6] ARM: sunxi: Add A31 RTC driver to sunxi_defconfig
Now that we have a driver for A31's RTC, enable it in the default sunxi config. Signed-off-by: Chen-Yu Tsai w...@csie.org --- arch/arm/configs/sunxi_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig index 7209bfd..0abc2ab 100644 --- a/arch/arm/configs/sunxi_defconfig +++ b/arch/arm/configs/sunxi_defconfig @@ -93,6 +93,7 @@ CONFIG_LEDS_TRIGGER_DEFAULT_ON=y CONFIG_RTC_CLASS=y # CONFIG_RTC_INTF_SYSFS is not set # CONFIG_RTC_INTF_PROC is not set +CONFIG_RTC_DRV_SUN6I=y CONFIG_RTC_DRV_SUNXI=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_PHY_SUN4I_USB=y -- 2.0.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 v4 1/6] rtc: sun6i: Add sun6i RTC driver
This patch introduces the driver for the RTC in the Allwinner A31 and
A23 SoCs.
Unlike the RTC found in A10/A20 SoCs, which was part of the timer, the
RTC in A31/A23 are a separate hardware block, which also contain a few
controls for the RTC block hardware (a regulator and RTC block GPIO pin
latches), while also having separate interrupts for the alarms.
The hardware is different enough to make a different driver for it.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
.../devicetree/bindings/rtc/sun6i-rtc.txt | 17 +
drivers/rtc/Kconfig| 7 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-sun6i.c| 447 +
4 files changed, 472 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
create mode 100644 drivers/rtc/rtc-sun6i.c
diff --git a/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
new file mode 100644
index 000..b7fb7a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
@@ -0,0 +1,17 @@
+* sun6i Real Time Clock
+
+RTC controller for the Allwinner A31
+
+Required properties:
+- compatible : Should be allwinner,sun6i-a31-rtc
+- reg : physical base address of the controller and length of
+ memory mapped region.
+- interrupts : IRQ line for the RTC alarm 0.
+
+Example:
+
+rtc: rtc@01f0 {
+ compatible = allwinner,sun6i-a31-rtc;
+ reg = 0x01f0 0x54;
+ interrupts = 0 40 4;
+};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 0754f5c..dde2b57 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1167,6 +1167,13 @@ config RTC_DRV_SUN4V
If you say Y here you will get support for the Hypervisor
based RTC on SUN4V systems.
+config RTC_DRV_SUN6I
+ tristate Allwinner A31 RTC
+ depends on MACH_SUN6I || MACH_SUN8I
+ help
+ If you say Y here you will get support for the RTC found on
+ Allwinner A31.
+
config RTC_DRV_SUNXI
tristate Allwinner sun4i/sun7i RTC
depends on ARCH_SUNXI
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 70347d0..a47df29 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -123,6 +123,7 @@ obj-$(CONFIG_RTC_DRV_STARFIRE) += rtc-starfire.o
obj-$(CONFIG_RTC_DRV_STK17TA8) += rtc-stk17ta8.o
obj-$(CONFIG_RTC_DRV_STMP) += rtc-stmp3xxx.o
obj-$(CONFIG_RTC_DRV_SUN4V)+= rtc-sun4v.o
+obj-$(CONFIG_RTC_DRV_SUN6I)+= rtc-sun6i.o
obj-$(CONFIG_RTC_DRV_SUNXI)+= rtc-sunxi.o
obj-$(CONFIG_RTC_DRV_TEGRA)+= rtc-tegra.o
obj-$(CONFIG_RTC_DRV_TEST) += rtc-test.o
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
new file mode 100644
index 000..c169a2c
--- /dev/null
+++ b/drivers/rtc/rtc-sun6i.c
@@ -0,0 +1,447 @@
+/*
+ * An RTC driver for Allwinner A31/A23
+ *
+ * Copyright (c) 2014, Chen-Yu Tsai w...@csie.org
+ *
+ * based on rtc-sunxi.c
+ *
+ * An RTC driver for Allwinner A10/A20
+ *
+ * Copyright (c) 2013, Carlo Caione carlo.cai...@gmail.com
+ *
+ * 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 linux/delay.h
+#include linux/err.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/rtc.h
+#include linux/types.h
+
+/* Control register */
+#define SUN6I_LOSC_CTRL0x
+#define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
+#define SUN6I_LOSC_CTRL_RTC_HMS_ACCBIT(8)
+#define SUN6I_LOSC_CTRL_RTC_YMD_ACCBIT(7)
+#define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
+
+/* RTC */
+#define SUN6I_RTC_YMD 0x0010
+#define SUN6I_RTC_HMS 0x0014
+
+/* Alarm 0 (counter) */
+#define SUN6I_ALRM_COUNTER 0x0020
+#define SUN6I_ALRM_CUR_VAL 0x0024
+#define SUN6I_ALRM_EN 0x0028
+#define SUN6I_ALRM_EN_CNT_EN BIT(0)
+#define SUN6I_ALRM_IRQ_EN 0x002c
+#define SUN6I_ALRM_IRQ_EN_CNT_IRQ_EN BIT(0)
+#define SUN6I_ALRM_IRQ_STA 0x0030
+#define SUN6I_ALRM_IRQ_STA_CNT_IRQ_PENDBIT(0)
+
+/* Alarm 1 (wall clock) */
+#define SUN6I_ALRM1_EN
[PATCH v4 0/6] ARM: sunxi: RTC support for A31/A23
Hi everyone, This is v3 of the sun6i RTC series. This series adds support for the RTC in A31 and A23 SoCs. The series applies to sunxi-next. The A31 has a new RTC block that is separate from the timer block. It has separate interrupts for each of the alarms, and a different format for the counter alarm. The driver has been tested on the A31 Hummingbird, and the A23 tablet I'm using to work on sun8i support. Patch 1 adds the driver for the RTC. Patch 2 is a minor cleanup. This makes rtc-sunxi depend on sun4i or sun7i, the 2 platforms the driver is actually used on. Patch 3 adds the RTC device node to the sun6i DTSI. Patch 4 adds the RTC device node to the sun8i DTSI. Patch 5 adds enables rtc-sun6i in the sunxi defconfig. Patch 6 adds enables rtc-sun6i in the multi_v7 defconfig. This patch applies to arm-soc/next/defconfig (e9a86d96) Changes since v3: - reformatted all multi-line function calls to have indentation match open parenthesis Changes since v2: - fixed indentation in DT binding docs - have function argument indentation match open parenthesis - drop driver owner field Changes since v1: - Enable rtc-sun6i in multi_v7_defconfig - Cleanup the time/date GET/SET macros - Use GENMASK for control register mask - Change Kconfig option to show 'A31' - Remove leftover comment from rtc-sun4i - Remove extra newline Cheers ChenYu Chen-Yu Tsai (6): rtc: sun6i: Add sun6i RTC driver rtc: sunxi: Depend on platforms sun4i/sun7i that actually have the rtc ARM: dts: sun6i: add rtc device node ARM: dts: sun8i: add rtc device node ARM: sunxi: Add A31 RTC driver to sunxi_defconfig ARM: sunxi: Add A31 RTC driver to multi_v7_defconfig .../devicetree/bindings/rtc/sun6i-rtc.txt | 17 + arch/arm/boot/dts/sun6i-a31.dtsi | 6 + arch/arm/boot/dts/sun8i-a23.dtsi | 6 + arch/arm/configs/multi_v7_defconfig| 1 + arch/arm/configs/sunxi_defconfig | 1 + drivers/rtc/Kconfig| 9 +- drivers/rtc/Makefile | 1 + drivers/rtc/rtc-sun6i.c| 447 + 8 files changed, 487 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/rtc/sun6i-rtc.txt create mode 100644 drivers/rtc/rtc-sun6i.c -- 2.0.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 v4 2/6] rtc: sunxi: Depend on platforms sun4i/sun7i that actually have the rtc
Now that we have Kconfig options for individual sunxi platforms, let the rtc-sunxi driver depend on the platforms that actually have this hardware, sun4i and sun7i. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Maxime Ripard maxime.rip...@free-electrons.com --- drivers/rtc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index dde2b57..f933b4b 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -1176,7 +1176,7 @@ config RTC_DRV_SUN6I config RTC_DRV_SUNXI tristate Allwinner sun4i/sun7i RTC - depends on ARCH_SUNXI + depends on MACH_SUN4I || MACH_SUN7I help If you say Y here you will get support for the RTC found on Allwinner A10/A20. -- 2.0.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] pinctrl: qpnp: Qualcomm PMIC pin controller driver
On Fri, 2014-07-25 at 18:43 -0700, David Collins wrote:
On 07/17/2014 08:25 AM, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm GPIO and MPP sub-function blocks found in the PMIC chips.
QPNP_REG_STATUS1_GPIO_EN_REV0_MASK
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
(...)
+static int qpnp_conv_to_pin(struct qpnp_pinctrl *qctrl,
+ struct qpnp_padinfo *pad, unsigned param,
+ unsigned val)
(...)
+ switch (param) {
(...)
+ case PIN_CONFIG_OUTPUT:
+ nattrs = 3;
+ attr[0].addr = QPNP_REG_MODE_CTL;
+ attr[0].shift = QPNP_REG_OUT_SRC_SEL_SHIFT;
+ attr[0].mask = QPNP_REG_OUT_SRC_SEL_MASK;
+ attr[0].val = !!val;
It seems that this patch provides no means to configure the output source
select bits to be anything besides 0 (constant low) or 1 (constant high).
Some non-generic property is needed to configure this for both GPIOs and
MPPs. Passing the value in via the output-high property does not seem
like a good approach since that is a generic pin config property that is
defined to take no value.
True.
The special functions available for GPIOs (e.g.
PWM/LPG, clock, keypad, etc.) which are configured via this register are
used by many boards.
I was not sure what those features are and how to connect the numbers to
the function, which is why I have restricted the values of 0 and 1.
Something else to consider is that QPNP_REG_OUT_SRC_SEL_MASK is being
defined as 0xf which would imply that there are 16 possible output source
select options. While technically true, this makes the situation more
complicated since half of those options are the inverted version of the
other half. In the GPIO hardware this corresponds to an 8-way mux
followed by an XOR gate to conditionally invert the mux output. If output
source select is handled this way, then the following values would need to
be supported in device tree for GPIOs:
* 0: constant low (already supported via output-low;)
* 1: constant high (already supported via output-high;)
* 2: paired GPIO
* 3: inverted paired GPIO
* 4: special function 1
* 5: inverted special function 1
* 6: special function 2
* 7: inverted special function 2
* 8: dtest1
* 9: inverted dtest1
* 10: dtest2
* 11: inverted dtest2
* 12: dtest3
* 13: inverted dtest3
* 14: dtest4
* 15: inverted dtest4
The same options are supported by MPPs except for special function 1,
inverted special function 1, special function 2, and inverted special
function 2.
snip
I am working on proposal from Stephen Boyd to encode GPIO/MPP mode and
source select into combined function. Something like this one:
#define PM8XXX_DIGITAL_IN 0
#define PM8XXX_DIGITAL_OUT 1
#define PM8XXX_DIGITAL_IN_OUT 2
...
/* mode and source select */
#define PM8XXX_FUNCTION(m,s)((m) 16 | (s))
#define PM8921_GPIO1_14_KYPD_SNSPM8XXX_FUNCTION(PM8XXX_DIGITAL_IN, 1)
#define PM8921_GPIO9_14_KYPD_DRVPM8XXX_FUNCTION(PM8XXX_DIGITAL_OUT, 1)
#define PM8921_GPIO33_35_PWMPM8XXX_FUNCTION(PM8XXX_DIGITAL_OUT, 3)
..
snip
There is an off-by-one issue with the indexing between the hardware GPIO
numbers (1-based) and the gpiolib gpio offsets (0-based). Do you agree
that the indexing used within the device tree gpiospecs should match the
hardware numbering scheme? I feel like this would be much less confusing
for users to work with.
Yep, will fix it. Thank you for review.
Regards,
Ivan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
On Sunday 27 July 2014 03:52:44 Andrew Lunn wrote:
Hi Benoit
+ i2c@11000 {
+ compatible = marvell,mv78230-a0-i2c,
+ marvell,mv64xxx-i2c;
The point of my patches is that you don't need the
marvell,mv78230-a0-i2c. It will work out at runtime if the SoC is A0
stepping and automatically enable the workaround. Please test with
only marvell,mv64xxx-i2c;
It should still list both marvell,mv78230-i2c and marvell,mv64xxx-i2c,
as the generic name may not be enough to describe the register layout
correctly.
Arnd
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] rtc: sun6i: Add sun6i RTC driver
On 07/28/2014 01:50 PM, Chen-Yu Tsai wrote: This patch introduces the driver for the RTC in the Allwinner A31 and A23 SoCs. Unlike the RTC found in A10/A20 SoCs, which was part of the timer, the RTC in A31/A23 are a separate hardware block, which also contain a few controls for the RTC block hardware (a regulator and RTC block GPIO pin latches), while also having separate interrupts for the alarms. The hardware is different enough to make a different driver for it. Signed-off-by: Chen-Yu Tsai w...@csie.org --- Reviewed-by: Varka Bhadram varkabhad...@gmail.com -- Regards, Varka Bhadram. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: dts: zynq: Add SPI
On 07/25/2014 04:42 PM, Sören Brinkmann wrote: On Fri, 2014-07-25 at 01:12PM +0200, Andreas Färber wrote: Signed-off-by: Andreas Färber afaer...@suse.de Reviewed-by: Soren Brinkmann soren.brinkm...@xilinx.com Applied to zynq/dt. Thanks, Michal -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: zynq: DT: Add CAN node
Add node describing Zynq's CAN controller.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3:
- Fix clocks description for can1
Changes in v2:
- Add can1
- Enable can0 for zc702
- Use status property
arch/arm/boot/dts/zynq-7000.dtsi | 26 +-
arch/arm/boot/dts/zynq-zc702.dts | 4
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index ef11dab30446..6cc83d4c6c76 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -71,7 +71,31 @@
interrupts = 0 7 4;
interrupt-parent = intc;
clocks = clkc 12;
- };
+ };
+
+ can0: can@e0008000 {
+ compatible = xlnx,zynq-can-1.0;
+ status = disabled;
+ clocks = clkc 19, clkc 36;
+ clock-names = can_clk, pclk;
+ reg = 0xe0008000 0x1000;
+ interrupts = 0 28 4;
+ interrupt-parent = intc;
+ tx-fifo-depth = 0x40;
+ rx-fifo-depth = 0x40;
+ };
+
+ can1: can@e0009000 {
+ compatible = xlnx,zynq-can-1.0;
+ status = disabled;
+ clocks = clkc 20, clkc 37;
+ clock-names = can_clk, pclk;
+ reg = 0xe0009000 0x1000;
+ interrupts = 0 51 4;
+ interrupt-parent = intc;
+ tx-fifo-depth = 0x40;
+ rx-fifo-depth = 0x40;
+ };
gpio0: gpio@e000a000 {
compatible = xlnx,zynq-gpio-1.0;
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 5e09cee33d42..835c3089c61c 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -29,6 +29,10 @@
};
+can0 {
+ status = okay;
+};
+
gem0 {
status = okay;
phy-mode = rgmii;
--
1.8.2.3
pgpLUF5oQUVMv.pgp
Description: PGP signature
Re: [PATCH v2] ARM: zynq: DT: Add CAN node
On 07/25/2014 05:00 PM, Sören Brinkmann wrote:
On Fri, 2014-07-25 at 08:52AM +0200, Michal Simek wrote:
Add node describing Zynq's CAN controller.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2:
- Add can1
- Enable can0 for zc702
- Use status property
arch/arm/boot/dts/zynq-7000.dtsi | 26 +-
arch/arm/boot/dts/zynq-zc702.dts | 4
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
b/arch/arm/boot/dts/zynq-7000.dtsi
index 366ca6434f54..983148111e3a 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -71,7 +71,31 @@
interrupts = 0 7 4;
interrupt-parent = intc;
clocks = clkc 12;
-};
+};
+
+can0: can@e0008000 {
+compatible = xlnx,zynq-can-1.0;
+status = disabled;
+clocks = clkc 19, clkc 36;
+clock-names = can_clk, pclk;
+reg = 0xe0008000 0x1000;
+interrupts = 0 28 4;
+interrupt-parent = intc;
+tx-fifo-depth = 0x40;
+rx-fifo-depth = 0x40;
+};
+
+can1: can@e0009000 {
+compatible = xlnx,zynq-can-1.0;
+status = disabled;
+clocks = clkc 19, clkc 36;
The clocks for CAN1 must be outputs 20 and 37 of the clkc.
Fixed in v3.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/2] ARM: dts: dra72-evm: Add i2c1 and tps65917 nodes
On Monday 28 July 2014 12:00 PM, Lokesh Vutla wrote: On Monday 28 July 2014 11:48 AM, Keerthy wrote: The patch series adds i2c1 and tps65917 and related nodes. The patch series is boot tested on DRA72-EVM. Thanks to Lokesh lokeshvu...@ti.com for testing the series. Correcting the 'to' list. For booting, this is dependent on recent hwmod fix patch series posted by me: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg108001.html Boot log for this series can be found here: http://paste.ubuntu.com/7881545/ Thanks Lokesh! Thanks and regards, Lokesh Keerthy J (2): ARM: dts: dra72-evm: Enable I2C1 node ARM: dts: dra72-evm: Add tps65917 PMIC node arch/arm/boot/dts/dra72-evm.dts | 120 +++ 1 file changed, 120 insertions(+) -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: dra72-evm: Add tps65917 PMIC node
On Monday 28 July 2014 11:48 AM, Keerthy wrote:
From: Keerthy J j-keer...@ti.com
DRA72x-evm uses TPS65917 PMIC. Add the node.
NOTE: LDO2 is actually unused, but the usage if any is expected to be
between 1.8 to 3.3v IO voltage. So define the node.
NOTE: Interrupt used is crossbar number based.
Correcting the 'to' list.
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 104 +++
1 file changed, 104 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 1e12862..4107428 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -33,6 +33,110 @@
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ tps65917: tps65917@58 {
+ compatible = ti,tps65917;
+ reg = 0x58;
+
+ interrupts = GIC_SPI 2 IRQ_TYPE_NONE; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ ti,system-power-controller;
+
+ tps65917_pmic {
+ compatible = ti,tps65917-pmic;
+
+ regulators {
+ smps1_reg: smps1 {
+ /* VDD_MPU */
+ regulator-name = smps1;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 125;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps2_reg: smps2 {
+ /* VDD_CORE */
+ regulator-name = smps2;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 103;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ smps3_reg: smps3 {
+ /* VDD_GPU IVA DSPEVE */
+ regulator-name = smps3;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 125;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ smps4_reg: smps4 {
+ /* VDDS1V8 */
+ regulator-name = smps4;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps5_reg: smps5 {
+ /* VDD_DDR */
+ regulator-name = smps5;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: ldo1 {
+ /* LDO1_OUT -- SDIO */
+ regulator-name = ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ /* LDO2_OUT -- TP1017 (UNUSED) */
+ regulator-name = ldo2;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ };
+
+ ldo3_reg: ldo3 {
+ /* VDDA_1V8_PHY */
+ regulator-name = ldo3;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+
Re: [PATCH 1/2] ARM: dts: dra72-evm: Enable I2C1 node
On Monday 28 July 2014 11:48 AM, Keerthy wrote:
From: Keerthy J j-keer...@ti.com
I2C1 bus is used for the following peripherals
P8 connector (MLB)
TLV320AIC3106 Audio codec
J15 LCD header
24WC256 eeprom
TMP102AIDRLT temperature sensor
PCF8575 GPIO expander
PCA9306 i2c voltage translator - Goes to P9 for comm interface
P2 expansion connector
TPS65917 PMIC
The slowest speed of all the peripherals seems to be 400KHz.
Correcting the 'to' list.
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 5147023..1e12862 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,22 @@
};
};
+dra7_pmx_core {
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x400 (PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
+ 0x404 (PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
+ ;
+ };
+};
+
+i2c1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+ clock-frequency = 40;
+};
+
uart1 {
status = okay;
};
--
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 v8 00/13] Add Maxim 77802 PMIC support
Hello Mike, On 07/26/2014 12:31 AM, Mike Turquette wrote: Quoting Javier Martinez Canillas (2014-07-14 04:35:56) This series are based on drivers added by Simon Glass to the Chrome OS kernel and adds support for the Maxim 77802 Power Management IC, their regulators, clocks, RTC and i2c interface. This is a v8 of the patch-set that addresses issues pointed out in v7. Individual changes are added on each patch but the biggest changes are: * Patches 1-7 from v7 are not included since those were improvements to the max77686 mfd driver and can be applied independently. Lee Jones said that he is going to pick them from the posted v7 series. I've created a patchwork bundle with 1-7 from v7 to make it easy to apply: https://patchwork.kernel.org/bundle/javier/max77686-improvements/ * The Dynamic Voltage Scaling support has been removed since that can be added in a follow up series and shouldn't block the minimum PMIC support. The patch-set has been tested on both Daisy/Snow (max77686) and Peach Pit (max77802) Chromebooks and it's composed of the following patches: [PATCH v8 01/13] mfd: max77686: Add Maxim 77802 PMIC support [PATCH v8 02/13] mfd: max77802: Add DT binding documentation [PATCH v8 03/13] regulator: Add driver for Maxim 77802 PMIC regulators [PATCH v8 04/13] clk: max77686: Add DT include for MAX77686 PMIC clock [PATCH v8 05/13] clk: Add generic driver for Maxim PMIC clocks [PATCH v8 06/13] clk: max77686: Convert to the generic max clock driver [PATCH v8 07/13] clk: max77686: Improve Maxim 77686 PMIC clocks binding [PATCH v8 08/13] clk: Add driver for Maxim 77802 PMIC clocks [PATCH v8 09/13] clk: max77802: Add DT binding documentation For patches 4-9: Acked-by: Mike Turquette mturque...@linaro.org Thanks a lot for your ack! Since the merge window is just around the corner, Lee merged the mfd max77686 headers changes to split the dependencies around kernel releases. So after the merge windows, I'll resend the clock driver (and the other drivers fwiw) as a separate series so you can merge it through your tree for 3.18. Regards, Mike Best regards, Javier -- 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: [RESEND RFC V2] devicetree: Dialog Semiconductor consolidate existing vendor prefixes to standardise on 'dlg'
On 25 July 2014 08:00, Lee Jones wrote:
On Thu, 24 Jul 2014, Opensource [Steve Twiss] wrote:
From: Steve Twiss stwiss.opensou...@diasemi.com
This patch series updates the device tree vendor prefix for
Dialog Semiconductor.
Various methods are currently used throughout the kernel: 'diasemi',
'dialog' and 'dlg'. Others have also been suggested.
This patch set aims to consolidate the usage of the vendor prefix to
use a common standard. The prefix 'dlg' is used.
Signed-off-by: Steve Twiss stwiss.opensou...@diasemi.com
Didn't I Ack the MFD parts already?
Yes -- certainly.
(I should have put them in the main body of the e-mail shouldn't I ..?)
I just need the SHMobile responses now.
I will try to make contact with those guys this week.
I have the following Acks so far.
From: Rob Herring on 21 July 2014 16:43
I'm okay with this, but it also needs acks from i.MX and SHMobile
folks as it could break out of tree users.
Acked-by: Rob Herring r...@kernel.org
From: Shawn Guo on 22 July 2014 02:38
arch/arm/boot/dts/imx53-smd.dts| 2 +-
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 2 +-
Acked-by: Shawn Guo shawn@freescale.com
From: Lee Jones on 22 July 2014 08:09
For the MFD changes:
Acked-by: Lee Jones lee.jo...@linaro.org
and
From: Philipp Zabel on 24 July 2014 20:44
Acked-by: Philipp Zabel p.za...@pengutronix.de
Regards,
Steve
N�r��yb�X��ǧv�^�){.n�+���z��z��z)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH v11 4/8] ata: libahci: allow to use multiple PHYs
Hi,
Thanks, this version is almost perfect, unfortunately a second review
has found one small issue in it, see inline comment below.
On 07/24/2014 11:17 AM, Antoine Ténart wrote:
The current implementation of the libahci does not allow to use multiple
PHYs. This patch adds the support of multiple PHYs by the libahci while
keeping the old bindings valid for device tree compatibility.
This introduce a new way of defining SATA ports in the device tree, with
one port per sub-node. This as the advantage of allowing a per port
configuration. Because some ports may be accessible but disabled in the
device tree, the port_map mask is computed automatically when using
this.
Signed-off-by: Antoine Ténart antoine.ten...@free-electrons.com
---
drivers/ata/ahci.h | 7 +-
drivers/ata/libahci_platform.c | 190
-
2 files changed, 157 insertions(+), 40 deletions(-)
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index cb8d58926851..47de53284ad7 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -332,7 +332,12 @@ struct ahci_host_priv {
boolgot_runtime_pm; /* Did we do pm_runtime_get? */
struct clk *clks[AHCI_MAX_CLKS]; /* Optional */
struct regulator*target_pwr;/* Optional */
- struct phy *phy; /* If platform uses phy */
+ /*
+ * If platform uses PHYs. There is a 1:1 relation between the port
number and
+ * the PHY position in this array.
+ */
+ struct phy **phys;
+ unsignednports; /* Number of ports */
void*plat_data; /* Other platform data */
/*
* Optional ahci_start_engine override, if not set this gets set to the
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index db9b90d876dd..095df56432d9 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -39,6 +39,67 @@ static struct scsi_host_template ahci_platform_sht = {
};
/**
+ * ahci_platform_enable_phys - Enable PHYs
+ * @hpriv: host private area to store config values
+ *
+ * This function enables all the PHYs found in hpriv-phys, if any.
+ * If a PHY fails to be enabled, it disables all the PHYs already
+ * enabled in reverse order and returns an error.
+ *
+ * RETURNS:
+ * 0 on success otherwise a negative error code
+ */
+int ahci_platform_enable_phys(struct ahci_host_priv *hpriv)
+{
+ int rc, i;
+
+ for (i = 0; i hpriv-nports; i++) {
+ if (!hpriv-phys[i])
+ continue;
+
+ rc = phy_init(hpriv-phys[i]);
+ if (rc)
+ goto disable_phys;
+
+ rc = phy_power_on(hpriv-phys[i]);
+ if (rc) {
+ phy_exit(hpriv-phys[i]);
+ goto disable_phys;
+ }
+ }
+
+ return 0;
+
+disable_phys:
+ while (--i = 0) {
+ phy_power_off(hpriv-phys[i]);
+ phy_exit(hpriv-phys[i]);
+ }
+ return rc;
+}
+EXPORT_SYMBOL_GPL(ahci_platform_enable_phys);
+
+/**
+ * ahci_platform_disable_phys - Enable PHYs
+ * @hpriv: host private area to store config values
+ *
+ * This function disables all PHYs found in hpriv-phys.
+ */
+void ahci_platform_disable_phys(struct ahci_host_priv *hpriv)
+{
+ int i;
+
+ for (i = 0; i hpriv-nports; i++) {
+ if (!hpriv-phys[i])
+ continue;
+
+ phy_power_off(hpriv-phys[i]);
+ phy_exit(hpriv-phys[i]);
+ }
+}
+EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
+
+/**
* ahci_platform_enable_clks - Enable platform clocks
* @hpriv: host private area to store config values
*
@@ -92,7 +153,7 @@ EXPORT_SYMBOL_GPL(ahci_platform_disable_clks);
* following order:
* 1) Regulator
* 2) Clocks (through ahci_platform_enable_clks)
- * 3) Phy
+ * 3) Phys
*
* If resource enabling fails at any point the previous enabled resources
* are disabled in reverse order.
@@ -114,17 +175,9 @@ int ahci_platform_enable_resources(struct ahci_host_priv
*hpriv)
if (rc)
goto disable_regulator;
- if (hpriv-phy) {
- rc = phy_init(hpriv-phy);
- if (rc)
- goto disable_clks;
-
- rc = phy_power_on(hpriv-phy);
- if (rc) {
- phy_exit(hpriv-phy);
- goto disable_clks;
- }
- }
+ rc = ahci_platform_enable_phys(hpriv);
+ if (rc)
+ goto disable_clks;
return 0;
@@ -144,16 +197,13 @@ EXPORT_SYMBOL_GPL(ahci_platform_enable_resources);
*
* This function disables all ahci_platform managed resources in the
* following order:
- * 1) Phy
+ * 1) Phys
* 2) Clocks (through ahci_platform_disable_clks)
*
Re: [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Le 28 juil. 2014 à 10:49, Arnd Bergmann a...@arndb.de a écrit :
On Sunday 27 July 2014 03:52:44 Andrew Lunn wrote:
Hi Benoit
Hi Arnd,
+ i2c@11000 {
+ compatible = marvell,mv78230-a0-i2c,
+ marvell,mv64xxx-i2c;
The point of my patches is that you don't need the
marvell,mv78230-a0-i2c. It will work out at runtime if the SoC is A0
stepping and automatically enable the workaround. Please test with
only marvell,mv64xxx-i2c;
It should still list both marvell,mv78230-i2c and marvell,mv64xxx-i2c,
as the generic name may not be enough to describe the register layout
correctly.
I tend to disagree since the dts include the armada-xp.dtsi, which already
declare
i2c0: i2c@11000 {
compatible = marvell,mv78230-i2c,
marvell,mv64xxx-i2c;
reg = 0x11000 0x100;
};
I tested the dts on the device and it does inherits the i2c declaration, did I
miss something here ?
Benoit
Arnd
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
On 07/22/2014 09:59 PM, Arnd Bergmann wrote: On Tuesday 22 July 2014 11:11:14 Chanwoo Choi wrote: This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The s3c24xx is alomost same as ADCv1. But, There are a little difference as following: - ADCMUX register address to select channel - ADCDAT mask (10bit or 12bit ADC resolution according to SoC version) Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Signed-off-by: Arnd Bergmann a...@arndb.de While looking at the driver again to see if the touchscreen patch needs an update for this, I noticed that the s3c24xx variants don't have the ADC_V1_INTCLR and ADC_V1_CLRINTPNDNUP registers, so I assume your patch will have to be updated not to acknowledge the interrupts. It's possible that writing to the missing registers is harmless though and that you don't need that change. OK, I'll remove the function pointer of clear_irq for s3c24xx. Best Regards, Chanwoo Choi -- 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] iio: adc: exynos_adc: add support for s3c64xx adc
On 07/28/2014 03:49 AM, Hartmut Knaack wrote: Chanwoo Choi schrieb: From: Arnd Bergmann a...@arndb.de The ADC in s3c64xx is almost the same as exynosv1, but has a different 'select' method. Adding this here will be helpful to move over the existing s3c64xx platform from the legacy plat-samsung/adc driver to the new exynos-adc. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- .../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 ++ drivers/iio/adc/exynos_adc.c | 32 +- 2 files changed, 33 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt index 6d34891..b6e3989 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt @@ -16,6 +16,8 @@ Required properties: future controllers. Must be samsung,exynos3250-adc for controllers compatible with ADC of Exynos3250. +Must be samsung,s3c6410-adc for +the ADC in s3c6410 and compatibles - reg: Contains ADC register address range (base address and length) and the address of the phy enable register. - interrupts: Contains the interrupt information for the timer. The diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c index 87e0895..05bdd2f12 100644 --- a/drivers/iio/adc/exynos_adc.c +++ b/drivers/iio/adc/exynos_adc.c @@ -40,12 +40,16 @@ #include linux/iio/machine.h #include linux/iio/driver.h -/* EXYNOS4412/5250 ADC_V1 registers definitions */ +/* S3C/EXYNOS4412/5250 ADC_V1 registers definitions */ #define ADC_V1_CON(x) ((x) + 0x00) +#define ADC_V1_TSC(x) ((x) + 0x04) #define ADC_V1_DLY(x) ((x) + 0x08) #define ADC_V1_DATX(x) ((x) + 0x0C) +#define ADC_V1_DATY(x) ((x) + 0x10) +#define ADC_V1_UPDN(x) ((x) + 0x14) #define ADC_V1_INTCLR(x)((x) + 0x18) #define ADC_V1_MUX(x) ((x) + 0x1c) +#define ADC_V1_CLRINTPNDNUP(x) ((x) + 0x20) /* Future ADC_V2 registers definitions */ #define ADC_V2_CON1(x) ((x) + 0x00) @@ -61,6 +65,9 @@ #define ADC_V1_CON_PRSCLV(x)(((x) 0xFF) 6) #define ADC_V1_CON_STANDBY (1u 2) +/* Bit definitions for S3C2410 ADC */ +#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3) There is a whitespace missing. OK, I'll fix it. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Le 28 juil. 2014 à 13:02, Arnd Bergmann a...@arndb.de a écrit :
On Monday 28 July 2014 12:50:47 Benoit Masson wrote:
It should still list both marvell,mv78230-i2c and marvell,mv64xxx-i2c,
as the generic name may not be enough to describe the register layout
correctly.
I tend to disagree since the dts include the armada-xp.dtsi, which already
declare
i2c0: i2c@11000 {
compatible = marvell,mv78230-i2c,
marvell,mv64xxx-i2c;
reg = 0x11000 0x100;
};
I tested the dts on the device and it does inherits the i2c declaration, did
I miss something here ?
Inheriting from armada-xp.dtsi is fine, but if you manually set
marvell,mv64xxx-i2c, that will override the old setting
and drop the marvell,mv78230-i2c part, which is bad because
it may break things later if it turns out that the mv78230
variant is not completely compatible with the old
mv64xxx variant.
Ok then does this mean I can simply remove the compatible line to only
inherits from armada-xp-dtsi ?
i2c@11000 {
clock-frequency = 40;
status = okay;
Would this be enough ?
Benoit
Arnd
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
Doug,
在 2014年07月28日 12:01, Doug Anderson 写道:
Caesar,
On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com wrote:
/*I think will be show the faill log:-
* rockchip-pwm ff9301a0.pwm: can't request region for resource [mem
0xff9301a0-0xff93019f]
*/
pc-base = devm_ioremap_resource(dev, regs);
Did you actually code this up and try it and get this error?
Yeah.
I hadn't
tried it but I researched other dts files and it looked as if there
was one example that was doing this. ...but perhaps it wasn't
actually doing the ioremap_resource on both ranges.
I'd imagine that this is _probably_ equivalent to what Thierry was
suggesting, so if it didn't work then maybe Thierry's won't work
either?
I don't have any other great suggestions other than doing two memory
ranges for lcdc:
lcdc@ff93 {
compatible = rockchip,rk3288-lcdc;
reg = 0xff93 0x1a0, 0xff9301b0 0xfe50;
...
};
pwm@ff9301a0 {
compatible = rockchip,vop-pwm;
reg = 0xff9301a0 0x10;
...
};
...but I am certainly nowhere near an expert on this stuff...
-Doug
I has solve in lcdc driver,but I always feel awkward. I think a good way
to solve in pwm driver.
Unfortunately that so far ,I have not a good idle in pwm driver.
Maybe,I let do it that way in lcdc driver.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
On 07/22/2014 05:39 PM, Arnd Bergmann wrote:
On Tuesday 22 July 2014 11:11:14 Chanwoo Choi wrote:
This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The s3c24xx
is alomost same as ADCv1. But, There are a little difference as following:
- ADCMUX register address to select channel
- ADCDAT mask (10bit or 12bit ADC resolution according to SoC version)
Very good, thanks for doing this patch!
(adding Heiko to Cc, he's probably interested in seeing this as well.
One comment:
@@ -101,12 +107,14 @@ struct exynos_adc {
struct completion completion;
u32 value;
+u32 value2;
unsigned intversion;
};
...
@@ -365,7 +448,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
ret = -ETIMEDOUT;
} else {
*val = info-value;
-*val2 = 0;
+*val2 = info-value2;
ret = IIO_VAL_INT;
}
@@ -377,9 +460,11 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
{
struct exynos_adc *info = (struct exynos_adc *)dev_id;
+u32 mask = info-data-mask;
/* Read value */
-info-value = readl(ADC_V1_DATX(info-regs)) ADC_DATX_MASK;
+info-value = readl(ADC_V1_DATX(info-regs)) mask;
+info-value2 = readl(ADC_V1_DATY(info-regs)) mask;
/* clear irq */
if (info-data-clear_irq)
If I understand it right, this would only be necessary if we want
to do the touchscreen driver as a separate iio client using the
in-kernel interfaces. As Jonathan Cameron commented, we probably
don't want to do that though. Even if we do, it should be a separate
patch and not mixed in with the s3c24xx support.
OK, I'll drop this sentence which reading DATY register.
Best Regards,
Chanwoo Choi
Aside from this:
Acked-by: Arnd Bergmann a...@arndb.de
Arnd
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr ecc controller
On Sun, Jul 27, 2014 at 12:10:52AM +0530, Punnaiah Choudary Kalluri wrote:
Added EDAC support for reporting the ecc errors of synopsys ddr controller.
The ddr ecc controller corrects single bit errors and detects double bit
errors.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes for v3:
- Updated maintainer information
- Driver cleanup as per the review comments
- Shortened the prefix sysnopsys to synps
This is not a good idea, IMO. synopsys is much more understandable
instead of synps. And synopsys-edac is just fine.
Changes for v2:
- Updated the commit header and message
- Renamed the filenames to synopsys_edac
- Corrected the compatilble string, commnets
- Renamed the macros,fucntions and data structures
---
.../devicetree/bindings/edac/synps_edac.txt| 18 +
MAINTAINERS|1 +
drivers/edac/Kconfig |7 +
drivers/edac/Makefile |1 +
drivers/edac/synps_edac.c | 554
5 files changed, 581 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/edac/synps_edac.txt
create mode 100644 drivers/edac/synps_edac.c
diff --git a/Documentation/devicetree/bindings/edac/synps_edac.txt
b/Documentation/devicetree/bindings/edac/synps_edac.txt
new file mode 100644
index 000..c4a559b
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/synps_edac.txt
@@ -0,0 +1,18 @@
+Synopsys EDAC driver, it does reports the DDR ECC single bit errors that are
+corrected and double bit ecc errors that are detected by the DDR ECC
controller.
+ECC support for DDR is available in half-bus width(16 bit) configuration
only.
+
+Required properties:
+- compatible: Should be xlnx,zynq-ddrc-1.04
+- reg: Should contain DDR controller registers location and length.
+
+Example:
+
+
+ddrc0: ddrc@f8006000 {
+ compatible = xlnx,zynq-ddrc-1.04;
+ reg = 0xf8006000 0x1000;
+};
I'd need an ack from device tree people about the DT bits.
+
+Synopsys EDAC driver detects the DDR ECC enable state by reading the
appropriate
+control register.
diff --git a/MAINTAINERS b/MAINTAINERS
index d76e077..984b5a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1479,6 +1479,7 @@ N: xilinx
F: drivers/clocksource/cadence_ttc_timer.c
F: drivers/i2c/busses/i2c-cadence.c
F: drivers/mmc/host/sdhci-of-arasan.c
+F: drivers/edac/synps_edac.c
ARM SMMU DRIVER
M: Will Deacon will.dea...@arm.com
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 878f090..f628a2b 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -368,4 +368,11 @@ config EDAC_OCTEON_PCI
Support for error detection and correction on the
Cavium Octeon family of SOCs.
+config EDAC_SYNPS
+ tristate Synopsys DDR Memory Controller
+ depends on EDAC_MM_EDAC ARCH_ZYNQ
+ help
+ Support for EDAC on the ECC memory used with the Synopsys DDR
+ memory controller.
+
endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 4154ed6..0af900f 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_EDAC_OCTEON_PC)+=
octeon_edac-pc.o
obj-$(CONFIG_EDAC_OCTEON_L2C)+= octeon_edac-l2c.o
obj-$(CONFIG_EDAC_OCTEON_LMC)+= octeon_edac-lmc.o
obj-$(CONFIG_EDAC_OCTEON_PCI)+= octeon_edac-pci.o
+obj-$(CONFIG_EDAC_SYNPS) += synps_edac.o
diff --git a/drivers/edac/synps_edac.c b/drivers/edac/synps_edac.c
new file mode 100644
index 000..a9417fe
--- /dev/null
+++ b/drivers/edac/synps_edac.c
@@ -0,0 +1,554 @@
+/*
+ * Synopsys DDR ECC Driver
+ * This driver is based on ppc4xx_edac.c drivers
+ *
+ * Copyright (C) 2012 - 2014 Xilinx, Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details
+ */
+
+#include linux/edac.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include edac_core.h
+
+/* Number of cs_rows needed per memory controller */
+#define SYNPS_EDAC_NR_CSROWS 1
+
+/* Number of channels per memory controller */
+#define SYNPS_EDAC_NR_CHANS 1
+
+/* Granularity of reported error in bytes */
+#define
Re: [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
On Monday 28 July 2014 13:17:56 Benoit Masson wrote:
Ok then does this mean I can simply remove the compatible line to only
inherits from armada-xp-dtsi ?
i2c@11000 {
clock-frequency = 40;
status = okay;
Would this be enough ?
Yes, this looks ideal.
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] ARM: at91: spi: request all csgpio in spi probe
This fix problem with PA14 set as periph A left from ROMBOOT and need it
to be set to gpio before spi bus communicate with chip on CS0 on other
gpio. As I reported a week ago.
Request all csgpios in spi_probe since cs depends on each other and must
be all of them in right state before any communication on bus. They are
part of bus, like miso, mosi, clk, not part of chips, they are defined
in parent spi node, not in child chip node.
Csgpio moved to atmel_spi struct as part of master bus.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
drivers/spi/spi-atmel.c | 68 +
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 92a6f0d..1fb7bb9 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -22,11 +22,14 @@
#include linux/platform_data/atmel.h
#include linux/platform_data/dma-atmel.h
#include linux/of.h
+#include linux/of_gpio.h
#include linux/io.h
#include linux/gpio.h
#include linux/pinctrl/consumer.h
+#define DRIVER_NAME atmel-spi
+
/* SPI register offsets */
#define SPI_CR 0x
#define SPI_MR 0x0004
@@ -242,11 +245,13 @@ struct atmel_spi {
boolkeep_cs;
boolcs_active;
+
+ /* chip selects */
+ unsigned intcsgpio[];
};
/* Controller-specific per-slave state */
struct atmel_spi_device {
- unsigned intnpcs_pin;
u32 csr;
};
@@ -312,7 +317,7 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
}
mr = spi_readl(as, MR);
- gpio_set_value(asd-npcs_pin, active);
+ gpio_set_value(as-csgpio[spi-chip_select], active);
} else {
u32 cpol = (spi-mode SPI_CPOL) ? SPI_BIT(CPOL) : 0;
int i;
@@ -329,18 +334,16 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
mr = spi_readl(as, MR);
mr = SPI_BFINS(PCS, ~(1 spi-chip_select), mr);
if (spi-chip_select != 0)
- gpio_set_value(asd-npcs_pin, active);
+ gpio_set_value(as-csgpio[spi-chip_select], active);
spi_writel(as, MR, mr);
}
dev_dbg(spi-dev, activate %u%s, mr %08x\n,
- asd-npcs_pin, active ? (high) : ,
- mr);
+ as-csgpio[spi-chip_select], active ? (high) : , mr);
}
static void cs_deactivate(struct atmel_spi *as, struct spi_device *spi)
{
- struct atmel_spi_device *asd = spi-controller_state;
unsigned active = spi-mode SPI_CS_HIGH;
u32 mr;
@@ -354,11 +357,10 @@ static void cs_deactivate(struct atmel_spi *as, struct
spi_device *spi)
}
dev_dbg(spi-dev, DEactivate %u%s, mr %08x\n,
- asd-npcs_pin, active ? (low) : ,
- mr);
+ as-csgpio[spi-chip_select], active ? (low) : , mr);
if (atmel_spi_is_v2(as) || spi-chip_select != 0)
- gpio_set_value(asd-npcs_pin, !active);
+ gpio_set_value(as-csgpio[spi-chip_select], !active);
}
static void atmel_spi_lock(struct atmel_spi *as) __acquires(as-lock)
@@ -989,8 +991,6 @@ static int atmel_spi_setup(struct spi_device *spi)
struct atmel_spi_device *asd;
u32 csr;
unsigned intbits = spi-bits_per_word;
- unsigned intnpcs_pin;
- int ret;
as = spi_master_get_devdata(spi-master);
@@ -1017,27 +1017,13 @@ static int atmel_spi_setup(struct spi_device *spi)
csr |= SPI_BF(DLYBS, 0);
csr |= SPI_BF(DLYBCT, 0);
- /* chipselect must have been muxed as GPIO (e.g. in board setup) */
- npcs_pin = (unsigned int)spi-controller_data;
-
- if (gpio_is_valid(spi-cs_gpio))
- npcs_pin = spi-cs_gpio;
-
asd = spi-controller_state;
if (!asd) {
asd = kzalloc(sizeof(struct atmel_spi_device), GFP_KERNEL);
if (!asd)
return -ENOMEM;
- ret = gpio_request(npcs_pin, dev_name(spi-dev));
- if (ret) {
- kfree(asd);
- return ret;
- }
-
- asd-npcs_pin = npcs_pin;
spi-controller_state = asd;
- gpio_direction_output(npcs_pin, !(spi-mode SPI_CS_HIGH));
}
asd-csr = csr;
@@ -1290,6 +1276,15 @@ static int atmel_spi_probe(struct platform_device *pdev)
int ret;
struct spi_master *master;
struct atmel_spi*as;
+ struct device_node *np = pdev-dev.of_node;
+ int num_cs, i;
+
+ if (!np)
+ return -EINVAL;
+
+
Re: [PATCH v2 09/11] Documentation: devicetree: Fix ADI AXI SPDIF specification
Mark, Am 25.07.2014 12:39, schrieb Mark Brown: On Fri, Jul 25, 2014 at 12:32:43PM +0200, Andreas Färber wrote: I used scripts/get_maintainer.pl --nogit-fallback. If you were not CC'ed and need to be, please submit a MAINTAINERS patch. :) You need to think about what you're doing when you use get_maintainer, it gives both false positives and false negatives. Maybe this works for you? https://patchwork.kernel.org/patch/4620191/ Otherwise I can resend with Ab/Rb. Documentation/SubmittingPatches. Not helpful here, nor is Documentation/devicetree/bindings/submitting-patches.txt. It's separate from code changes, sent via git-send-email, has a Sob, went to LKML and LAKML and DTML. I could add a Fixes: header and CC trivial for this one-line fix IIUC. Doesn't tell me which patches I should CC you on in the future though. Therefore my request to fix the false negative in MAINTAINERS so that me and other kernel newbies don't run into it again. I'll simply interpret your reply as yes, please resend with broo...@kernel.org CC'ed then. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 7/7] PM / devfreq: Add devfreq driver for Exynos5420
Hi Tomasz,
On Wed, Jul 16, 2014 at 11:29 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Tomasz,
On Wed, Jul 16, 2014 at 5:25 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Abhilash,
Please see my comments inline.
On 15.07.2014 20:36, Abhilash Kesavan wrote:
From: Arjun.K.V arjun...@samsung.com
Exynos5420 bus device devfreq driver monitors PPMU counters and
adjusts INT domain operating frequencies and voltages. Support
for 5420 has been added to the extant 5250 support.
Signed-off-by: Arjun.K.V arjun...@samsung.com
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
drivers/devfreq/Kconfig | 10 +-
drivers/devfreq/exynos/exynos5_bus.c | 598
--
2 files changed, 508 insertions(+), 100 deletions(-)
[snip]
-#define MAX_SAFEVOLT 110 /* 1.10V */
-/* Assume that the bus is saturated if the utilization is 25% */
-#define INT_BUS_SATURATION_RATIO 25
+/* Assume that we need to bump up the level if the utilization is 10% */
+#define INT_BUS_SATURATION_RATIO 10
There is nothing about this change in commit message and changing the
ratio from 25% to 10% seems to be rather significant. Please give the
rationale for this change.
Will do.
+#define INT_VOLT_STEP_UV 12500
+
+struct exynos5_busfreq_drv_data {
+ int busf_type;
+};
+
+enum exynos5_busf_type {
+ TYPE_BUSF_EXYNOS5250,
+ TYPE_BUSF_EXYNOS5420,
+};
Using this kind of enums is discouraged. Rather than that, just create a
structure that describes the differences between variants and use this
as type.
OK.
enum int_level_idx {
LV_0,
@@ -41,12 +46,31 @@ enum int_level_idx {
_LV_END
};
[snip]
+
+static struct int_bus_opp_table *exynos5_int_opp_table;
+static struct int_bus_opp_table exynos5250_int_opp_table[] = {
{LV_0, 266000, 1025000},
{LV_1, 20, 1025000},
{LV_2, 16, 1025000},
[snip]
+static struct int_clk_info exynos5420_aclk_300_jpeg[] = {
+ /* Level, Freq, Parent_Pll */
+ {LV_0, 30, D_PLL},
+ {LV_1, 30, D_PLL},
+ {LV_2, 20, D_PLL},
+ {LV_3, 15, D_PLL},
+ {LV_4, 75000, D_PLL},
+};
These should be parsed from DT.
OK.
+
+#define EXYNOS5420_INT_PM_CLK(NAME, CLK, PCLK, CLK_INFO) \
+static struct int_comp_clks int_pm_clks_##NAME = { \
+ .mux_clk_name = CLK,\
+ .div_clk_name = PCLK, \
+ .clk_info = CLK_INFO, \
+}
+
+EXYNOS5420_INT_PM_CLK(aclk_200_fsys, aclk200_fsys,
+ aclk200_fsys_d, exynos5420_aclk_200_fsys);
+EXYNOS5420_INT_PM_CLK(pclk_200_fsys, pclk200_fsys,
+ pclk200_fsys_d, exynos5420_pclk_200_fsys);
+EXYNOS5420_INT_PM_CLK(aclk_100_noc, aclk100_noc,
+ aclk100_noc_d, exynos5420_aclk_100_noc);
+EXYNOS5420_INT_PM_CLK(aclk_400_wcore, aclk400_wcore,
+ aclk400_wcore_d, exynos5420_aclk_400_wcore);
+EXYNOS5420_INT_PM_CLK(aclk_200_fsys2, aclk200_fsys2,
+ aclk200_fsys2_d, exynos5420_aclk_200_fsys2);
+EXYNOS5420_INT_PM_CLK(aclk_400_mscl, aclk400_mscl,
+ aclk400_mscl_d, exynos5420_aclk_400_mscl);
+EXYNOS5420_INT_PM_CLK(aclk_166, aclk166,
+ aclk166_d, exynos5420_aclk_166);
+EXYNOS5420_INT_PM_CLK(aclk_266, aclk266,
+ aclk266_d, exynos5420_aclk_266);
+EXYNOS5420_INT_PM_CLK(aclk_66, aclk66,
+ aclk66_d, exynos5420_aclk_66);
+EXYNOS5420_INT_PM_CLK(aclk_300_disp1, aclk300_disp1,
+ aclk300_disp1_d, exynos5420_aclk_300_disp1);
+EXYNOS5420_INT_PM_CLK(aclk_300_jpeg, aclk300_jpeg,
+ aclk300_jpeg_d, exynos5420_aclk_300_jpeg);
+EXYNOS5420_INT_PM_CLK(aclk_400_disp1, aclk400_disp1,
+ aclk400_disp1_d, exynos5420_aclk_400_disp1);
List of the clocks should be parsed from DT as well, without hardcoding
data for every SoC in the driver.
+
+static struct int_comp_clks *exynos5420_int_pm_clks[] = {
+ int_pm_clks_aclk_200_fsys,
+ int_pm_clks_pclk_200_fsys,
+ int_pm_clks_aclk_100_noc,
+ int_pm_clks_aclk_400_wcore,
+ int_pm_clks_aclk_200_fsys2,
+ int_pm_clks_aclk_400_mscl,
+ int_pm_clks_aclk_166,
+ int_pm_clks_aclk_266,
+ int_pm_clks_aclk_66,
+ int_pm_clks_aclk_300_disp1,
+ int_pm_clks_aclk_300_jpeg,
+ int_pm_clks_aclk_400_disp1,
+ NULL,
+};
+
+static int exynos5250_int_set_rate(struct busfreq_data_int *data,
unsigned long rate)
{
int index, i;
- for (index = 0; index ARRAY_SIZE(exynos5_int_opp_table); index++) {
- if (exynos5_int_opp_table[index].clk == rate)
+ for (index = 0; index ARRAY_SIZE(exynos5250_int_opp_table);
Re: [PATCH 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
On 07/22/2014 07:44 PM, Heiko Stübner wrote:
Am Dienstag, 22. Juli 2014, 10:39:38 schrieb Arnd Bergmann:
On Tuesday 22 July 2014 11:11:14 Chanwoo Choi wrote:
This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The
s3c24xx
is alomost same as ADCv1. But, There are a little difference as following:
- ADCMUX register address to select channel
- ADCDAT mask (10bit or 12bit ADC resolution according to SoC version)
Very good, thanks for doing this patch!
(adding Heiko to Cc, he's probably interested in seeing this as well.
indeed. Thanks for implementing this.
While trying to build a test setup for this, I noticed two points:
(1) I'm not sure what the second register (a phy enable register according
to the binding) is supposed to be.
According to binding and adc code it is mandatory, but I didn't find any
lone adc register in the s3c2416 manual.
You're right. I don't find ADC_PHY_CONTROL register on s3c2410 datasheet.
So, if 'needs_adc_phy' field is true, exynos-adc would only get 'phy enable
register'
from dt node.
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- info-enable_reg = devm_ioremap_resource(pdev-dev, mem);
- if (IS_ERR(info-enable_reg))
- return PTR_ERR(info-enable_reg);
+
+ if (info-data-needs_adc_phy) {
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ info-enable_reg = devm_ioremap_resource(pdev-dev, mem);
+ if (IS_ERR(info-enable_reg))
+ return PTR_ERR(info-enable_reg);
+ }
(2) You might need something along the lines of:
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 11b048a..088c99a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -129,7 +129,7 @@ config AT91_ADC
config EXYNOS_ADC
tristate Exynos ADC driver support
- depends on ARCH_EXYNOS || (OF COMPILE_TEST)
+ depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF
COMPILE_TEST)
help
Core support for the ADC block found in the Samsung EXYNOS series
of SoCs for drivers such as the touchscreen and hwmon to use to
share
OK, I'll modify it as your comment.
Best Regards,
Chanwoo Choi
--
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/2] dma: Add Xilinx AXI DMA DT Binding Documentation
Device-tree binding documentation of Xilinx DMA Engine
Signed-off-by: Srikanth Thokala stho...@xilinx.com
---
Changes in v3:
- Change property 'xlnx,data-width' to 'xlnx,datawidth' in the description
to match the implementation.
Changes in v2:
None
---
.../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 65
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
new file mode 100644
index 000..18e8bcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -0,0 +1,65 @@
+Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
+target devices. It can be configured to have one channel or two channels.
+If configured as two channels, one is to transmit to the device and another
+is to receive from the device.
+
+Required properties:
+- compatible: Should be xlnx,axi-dma-1.00.a
+- #dma-cells: Should be 1, see dmas property below
+- reg: Should contain DMA registers location and length.
+- dma-channel child node: Should have atleast one channel and can have upto
+ two channels per device. This node specifies the properties of each
+ DMA channel (see child node properties below).
+
+Optional properties:
+- xlnx,include-sg: Tells whether configured for Scatter-mode in
+ the hardware.
+
+Required child node properties:
+- compatible: It should be either xlnx,axi-dma-mm2s-channel or
+ xlnx,axi-dma-s2mm-channel.
+- interrupts: Should contain per channel DMA interrupts.
+- xlnx,datawidth: Should contain the stream data width, take values
+ {32,64...1024}.
+
+Option child node properties:
+- xlnx,include-dre: Tells whether hardware is configured for Data
+ Realignment Engine.
+
+Example:
+
+
+axi_dma_0: axidma@4040 {
+ compatible = xlnx,axi-dma-1.00.a;
+ #dma_cells = 1;
+ reg = 0x4040 0x1 ;
+ dma-channel@4040 {
+ compatible = xlnx,axi-dma-mm2s-channel;
+ interrupts = 0 59 4 ;
+ xlnx,datawidth = 0x40;
+ } ;
+ dma-channel@40400030 {
+ compatible = xlnx,axi-dma-s2mm-channel;
+ interrupts = 0 58 4 ;
+ xlnx,datawidth = 0x40;
+ } ;
+} ;
+
+
+* DMA client
+
+Required properties:
+- dmas: a list of [DMA device phandle] [Channel ID] pairs,
+ where Channel ID is '0' for write/tx and '1' for read/rx
+ channel.
+- dma-names: a list of DMA channel names, one per dmas entry
+
+Example:
+
+
+dmatest_0: dmatest@0 {
+ compatible =xlnx,axi-dma-test-1.00.a;
+ dmas = axi_dma_0 0
+ axi_dma_0 1;
+ dma-names = dma0, dma1;
+} ;
--
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
[RFC 5/5] ARM: dts: exynos5410: Add ODROID-XU LEDs
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/exynos5410-odroidxu.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts
b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index b67112bf062a..f6e7555feeff 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -15,6 +15,7 @@
/dts-v1/;
#include exynos5410.dtsi
+#include dt-bindings/gpio/gpio.h
/ {
model = ODROID-XU based on EXYNOS5410;
compatible = hardkernel,odroid-xu, samsung,exynos5410,
samsung,exynos5;
@@ -39,6 +40,30 @@
reg = 0x02037000 0x1000;
};
+ leds {
+ compatible = gpio-leds;
+
+ blue {
+ label = blue:heartbeat;
+ gpios = gpb2 2 GPIO_ACTIVE_HIGH;
+ default-state = off;
+ linux,default-trigger = heartbeat;
+ };
+
+ green {
+ label = green:activity;
+ gpios = gpb2 1 GPIO_ACTIVE_HIGH;
+ default-state = off;
+ linux,default-trigger = mmc0;
+ };
+
+ red {
+ label = red:activity;
+ gpios = gpx2 3 GPIO_ACTIVE_HIGH;
+ default-state = off;
+ linux,default-trigger = mmc1;
+ };
+ };
};
mmc_0 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/5] ARM: dts: add pinctrl support to Exynos5410
From: Hakjoo Kim ruppi@hardkernel.com
Add the required pin configuration support to Exynos5410 using pinctrl
interface.
Cc: Hakjoo Kim ruppi@hardkernel.com
[AF: Rebased]
---
arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 408 ++
arch/arm/boot/dts/exynos5410.dtsi | 32 +++
2 files changed, 440 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi
diff --git a/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
new file mode 100644
index ..8b5288367a00
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
@@ -0,0 +1,408 @@
+/*
+ * Exynos5410 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2013 Hardkernel Co., Ltd.
+ * http://www.hardkernel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+ pinctrl@1340 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb1: gpb1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb2: gpb2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb3: gpb3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc3: gpc3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc2: gpc2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpm5: gpm5 {
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe0: gpe0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe1: gpe1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpg0: gpg0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+
[PATCH v3 2/2] dma: Add Xilinx AXI Direct Memory Access Engine driver support
This is the driver for the AXI Direct Memory Access (AXI DMA) core, which is a soft Xilinx IP core that provides high- bandwidth direct memory access between memory and AXI4-Stream type target peripherals. This module works on Zynq (ARM Based SoC) and Microblaze platforms. Signed-off-by: Srikanth Thokala stho...@xilinx.com --- Changes in v3: - Rebased on 3.16-rc7 Changes in v2: - Simplified the logic to set SOP and APP words in prep_slave_sg(). - Corrected function description comments to match the return type. - Fixed some minor comments as suggested by Andy, Thanks. --- drivers/dma/Kconfig | 13 + drivers/dma/xilinx/Makefile |1 + drivers/dma/xilinx/xilinx_dma.c | 1225 +++ include/linux/amba/xilinx_dma.h | 17 + 4 files changed, 1256 insertions(+) create mode 100644 drivers/dma/xilinx/xilinx_dma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 1eca7b9..b8e831e 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -375,6 +375,19 @@ config XILINX_VDMA channels, Memory Mapped to Stream (MM2S) and Stream to Memory Mapped (S2MM) for the data transfers. +config XILINX_DMA + tristate Xilinx AXI DMA Engine + depends on (ARCH_ZYNQ || MICROBLAZE) + select DMA_ENGINE + help + Enable support for Xilinx AXI DMA Soft IP. + + This engine provides high-bandwidth direct memory access + between memory and AXI4-Stream type target peripherals. + It has two stream interfaces/channels, Memory Mapped to + Stream (MM2S) and Stream to Memory Mapped (S2MM) for the + data transfers. + config DMA_ENGINE bool diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile index 3c4e9f2..6224a49 100644 --- a/drivers/dma/xilinx/Makefile +++ b/drivers/dma/xilinx/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o +obj-$(CONFIG_XILINX_DMA) += xilinx_dma.o diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c new file mode 100644 index 000..0500773 --- /dev/null +++ b/drivers/dma/xilinx/xilinx_dma.c @@ -0,0 +1,1225 @@ +/* + * DMA driver for Xilinx DMA Engine + * + * Copyright (C) 2010 - 2014 Xilinx, Inc. All rights reserved. + * + * Based on the Freescale DMA driver. + * + * Description: + * The AXI DMA, is a soft IP, which provides high-bandwidth Direct Memory + * Access between memory and AXI4-Stream-type target peripherals. It can be + * configured to have one channel or two channels and if configured as two + * channels, one is to transmit data from memory to a device and another is + * to receive from a device. + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License, or + * (at your option) any later version. + */ + +#include linux/amba/xilinx_dma.h +#include linux/bitops.h +#include linux/init.h +#include linux/interrupt.h +#include linux/io.h +#include linux/module.h +#include linux/of_address.h +#include linux/of_dma.h +#include linux/of_irq.h +#include linux/of_platform.h +#include linux/slab.h + +#include ../dmaengine.h + +/* Register Offsets */ +#define XILINX_DMA_REG_CONTROL 0x00 +#define XILINX_DMA_REG_STATUS 0x04 +#define XILINX_DMA_REG_CURDESC 0x08 +#define XILINX_DMA_REG_TAILDESC0x10 +#define XILINX_DMA_REG_SRCADDR 0x18 +#define XILINX_DMA_REG_DSTADDR 0x20 +#define XILINX_DMA_REG_BTT 0x28 + +/* Channel/Descriptor Offsets */ +#define XILINX_DMA_MM2S_CTRL_OFFSET0x00 +#define XILINX_DMA_S2MM_CTRL_OFFSET0x30 + +/* General register bits definitions */ +#define XILINX_DMA_CR_RUNSTOP_MASK BIT(0) +#define XILINX_DMA_CR_RESET_MASK BIT(2) + +#define XILINX_DMA_CR_DELAY_SHIFT 24 +#define XILINX_DMA_CR_COALESCE_SHIFT 16 + +#define XILINX_DMA_CR_DELAY_MAXGENMASK(7, 0) +#define XILINX_DMA_CR_COALESCE_MAX GENMASK(7, 0) + +#define XILINX_DMA_SR_HALTED_MASK BIT(0) +#define XILINX_DMA_SR_IDLE_MASKBIT(1) + +#define XILINX_DMA_XR_IRQ_IOC_MASK BIT(12) +#define XILINX_DMA_XR_IRQ_DELAY_MASK BIT(13) +#define XILINX_DMA_XR_IRQ_ERROR_MASK BIT(14) +#define XILINX_DMA_XR_IRQ_ALL_MASK GENMASK(14, 12) + +/* BD definitions */ +#define XILINX_DMA_BD_STS_ALL_MASK GENMASK(31, 28) +#define XILINX_DMA_BD_SOP BIT(27) +#define XILINX_DMA_BD_EOP BIT(26) + +/* Hw specific definitions */ +#define XILINX_DMA_MAX_CHANS_PER_DEVICE0x2 +#define XILINX_DMA_MAX_TRANS_LEN GENMASK(22, 0) + +/* Delay loop counter to prevent hardware failure */ +#define XILINX_DMA_LOOP_COUNT 100 + +/* Maximum number of Descriptors */ +#define XILINX_DMA_NUM_DESCS 64 + +/** + * struct xilinx_dma_desc_hw - Hardware Descriptor + * @next_desc: Next Descriptor Pointer @0x00 + *
[RFC 3/5] pinctrl: exynos: add exynos5410 SoC specific data
From: Hakjoo Kim ruppi@hardkernel.com
Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
support for all platforms based on EXYNOS5410.
Cc: Hakjoo Kim ruppi@hardkernel.com
[AF: Rebased onto Exynos5260]
---
.../bindings/pinctrl/samsung-pinctrl.txt | 1 +
drivers/pinctrl/pinctrl-exynos.c | 126 +
drivers/pinctrl/pinctrl-samsung.c | 2 +
drivers/pinctrl/pinctrl-samsung.h | 1 +
4 files changed, 130 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 2b32783ba821..1b2ec5a1f1a8 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -17,6 +17,7 @@ Required Properties:
- samsung,exynos4x12-pinctrl: for Exynos4x12 compatible pin-controller.
- samsung,exynos5250-pinctrl: for Exynos5250 compatible pin-controller.
- samsung,exynos5260-pinctrl: for Exynos5260 compatible pin-controller.
+ - samsung,exynos5410-pinctrl: for Exynos5410 compatible pin-controller.
- samsung,exynos5420-pinctrl: for Exynos5420 compatible pin-controller.
- reg: Base address of the pin controller hardware module and length of
diff --git a/drivers/pinctrl/pinctrl-exynos.c b/drivers/pinctrl/pinctrl-exynos.c
index 9609c23834ce..1ea15d98cea2 100644
--- a/drivers/pinctrl/pinctrl-exynos.c
+++ b/drivers/pinctrl/pinctrl-exynos.c
@@ -1191,6 +1191,132 @@ struct samsung_pin_ctrl exynos5260_pin_ctrl[] = {
},
};
+/* pin banks of exynos5410 pin-controller 0 */
+static struct samsung_pin_bank exynos5410_pin_banks0[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpa2, 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x060, gpb0, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, gpb1, 0x10),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0A0, gpb2, 0x14),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0C0, gpb3, 0x18),
+ EXYNOS_PIN_BANK_EINTG(7, 0x0E0, gpc0, 0x1c),
+ EXYNOS_PIN_BANK_EINTG(4, 0x100, gpc3, 0x20),
+ EXYNOS_PIN_BANK_EINTG(7, 0x120, gpc1, 0x24),
+ EXYNOS_PIN_BANK_EINTG(7, 0x140, gpc2, 0x28),
+ EXYNOS_PIN_BANK_EINTN(2, 0x160, gpm5),
+ EXYNOS_PIN_BANK_EINTG(8, 0x180, gpd1, 0x2c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x1A0, gpe0, 0x30),
+ EXYNOS_PIN_BANK_EINTG(2, 0x1C0, gpe1, 0x34),
+ EXYNOS_PIN_BANK_EINTG(6, 0x1E0, gpf0, 0x38),
+ EXYNOS_PIN_BANK_EINTG(8, 0x200, gpf1, 0x3c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x220, gpg0, 0x40),
+ EXYNOS_PIN_BANK_EINTG(8, 0x240, gpg1, 0x44),
+ EXYNOS_PIN_BANK_EINTG(2, 0x260, gpg2, 0x48),
+ EXYNOS_PIN_BANK_EINTG(4, 0x280, gph0, 0x4c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x2A0, gph1, 0x50),
+ EXYNOS_PIN_BANK_EINTN(8, 0x2C0, gpm7),
+ EXYNOS_PIN_BANK_EINTN(6, 0x2E0, gpy0),
+ EXYNOS_PIN_BANK_EINTN(4, 0x300, gpy1),
+ EXYNOS_PIN_BANK_EINTN(6, 0x320, gpy2),
+ EXYNOS_PIN_BANK_EINTN(8, 0x340, gpy3),
+ EXYNOS_PIN_BANK_EINTN(8, 0x360, gpy4),
+ EXYNOS_PIN_BANK_EINTN(8, 0x380, gpy5),
+ EXYNOS_PIN_BANK_EINTN(8, 0x3A0, gpy6),
+ EXYNOS_PIN_BANK_EINTN(8, 0x3C0, gpy7),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC00, gpx0, 0x00),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC20, gpx1, 0x04),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC40, gpx2, 0x08),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC60, gpx3, 0x0c),
+};
+
+/* pin banks of exynos5410 pin-controller 1 */
+static struct samsung_pin_bank exynos5410_pin_banks1[] = {
+ EXYNOS_PIN_BANK_EINTG(5, 0x000, gpj0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, gpj1, 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpj2, 0x08),
+ EXYNOS_PIN_BANK_EINTG(8, 0x060, gpj3, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(2, 0x080, gpj4, 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0A0, gpk0, 0x14),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0C0, gpk1, 0x18),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0E0, gpk2, 0x1c),
+ EXYNOS_PIN_BANK_EINTG(7, 0x100, gpk3, 0x20),
+};
+
+/* pin banks of exynos5410 pin-controller 2 */
+static struct samsung_pin_bank exynos5410_pin_banks2[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, gpv0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, gpv1, 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x060, gpv2, 0x08),
+ EXYNOS_PIN_BANK_EINTG(8, 0x080, gpv3, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(2, 0x0C0, gpv4, 0x10),
+};
+
+/* pin banks of exynos5410 pin-controller 3 */
+static struct samsung_pin_bank exynos5410_pin_banks3[] = {
+ EXYNOS_PIN_BANK_EINTG(7, 0x000, gpz, 0x00),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos5410 SoC. Exynos5410 SoC includes
+ * four gpio/pin-mux/pinconfig controllers.
+ */
+struct samsung_pin_ctrl exynos5410_pin_ctrl[] = {
+ {
+ /* pin-controller instance 0 data */
+ .pin_banks = exynos5410_pin_banks0,
+ .nr_banks =
Re: [PATCH v2 09/11] Documentation: devicetree: Fix ADI AXI SPDIF specification
On Mon, Jul 28, 2014 at 01:43:02PM +0200, Andreas Färber wrote: Am 25.07.2014 12:39, schrieb Mark Brown: On Fri, Jul 25, 2014 at 12:32:43PM +0200, Andreas Färber wrote: Maybe this works for you? https://patchwork.kernel.org/patch/4620191/ Otherwise I can resend with Ab/Rb. Documentation/SubmittingPatches. Not helpful here, nor is Documentation/devicetree/bindings/submitting-patches.txt. It's separate from code changes, sent via git-send-email, has a Sob, went to LKML and LAKML and DTML. I could add a Fixes: header and CC trivial for this one-line fix IIUC. It's telling you that the kernel process is to review patches sent via e-mail, not random links to web appliations - notice the context to which I'm replying, I'm saying that sending a link to something on the web isn't a good way of submitting a patch. Doesn't tell me which patches I should CC you on in the future though. Therefore my request to fix the false negative in MAINTAINERS so that me and other kernel newbies don't run into it again. Feel free to submit patches if you want to see changes. signature.asc Description: Digital signature
Re: [PATCH] ARM: at91: spi: request all csgpio in spi probe
Hi,
Thank you for that patch, a few questions/comments below.
On 28/07/2014 at 13:43:40 +0200, Jiri Prchal wrote :
This fix problem with PA14 set as periph A left from ROMBOOT and need it
to be set to gpio before spi bus communicate with chip on CS0 on other
gpio. As I reported a week ago.
Request all csgpios in spi_probe since cs depends on each other and must
be all of them in right state before any communication on bus. They are
part of bus, like miso, mosi, clk, not part of chips, they are defined
in parent spi node, not in child chip node.
Csgpio moved to atmel_spi struct as part of master bus.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
drivers/spi/spi-atmel.c | 68
+
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 92a6f0d..1fb7bb9 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -22,11 +22,14 @@
#include linux/platform_data/atmel.h
#include linux/platform_data/dma-atmel.h
#include linux/of.h
+#include linux/of_gpio.h
#include linux/io.h
#include linux/gpio.h
#include linux/pinctrl/consumer.h
+#define DRIVER_NAME atmel-spi
+
This is not really related to the issue solved by that patch, maybe it
could go in another patch ?
/* SPI register offsets */
#define SPI_CR 0x
#define SPI_MR 0x0004
@@ -242,11 +245,13 @@ struct atmel_spi {
boolkeep_cs;
boolcs_active;
+
+ /* chip selects */
+ unsigned intcsgpio[];
};
/* Controller-specific per-slave state */
struct atmel_spi_device {
- unsigned intnpcs_pin;
u32 csr;
};
@@ -312,7 +317,7 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
}
mr = spi_readl(as, MR);
- gpio_set_value(asd-npcs_pin, active);
+ gpio_set_value(as-csgpio[spi-chip_select], active);
} else {
u32 cpol = (spi-mode SPI_CPOL) ? SPI_BIT(CPOL) : 0;
int i;
@@ -329,18 +334,16 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
mr = spi_readl(as, MR);
mr = SPI_BFINS(PCS, ~(1 spi-chip_select), mr);
if (spi-chip_select != 0)
- gpio_set_value(asd-npcs_pin, active);
+ gpio_set_value(as-csgpio[spi-chip_select], active);
spi_writel(as, MR, mr);
}
dev_dbg(spi-dev, activate %u%s, mr %08x\n,
- asd-npcs_pin, active ? (high) : ,
- mr);
+ as-csgpio[spi-chip_select], active ? (high) : , mr);
}
static void cs_deactivate(struct atmel_spi *as, struct spi_device *spi)
{
- struct atmel_spi_device *asd = spi-controller_state;
unsigned active = spi-mode SPI_CS_HIGH;
u32 mr;
@@ -354,11 +357,10 @@ static void cs_deactivate(struct atmel_spi *as, struct
spi_device *spi)
}
dev_dbg(spi-dev, DEactivate %u%s, mr %08x\n,
- asd-npcs_pin, active ? (low) : ,
- mr);
+ as-csgpio[spi-chip_select], active ? (low) : , mr);
if (atmel_spi_is_v2(as) || spi-chip_select != 0)
- gpio_set_value(asd-npcs_pin, !active);
+ gpio_set_value(as-csgpio[spi-chip_select], !active);
}
static void atmel_spi_lock(struct atmel_spi *as) __acquires(as-lock)
@@ -989,8 +991,6 @@ static int atmel_spi_setup(struct spi_device *spi)
struct atmel_spi_device *asd;
u32 csr;
unsigned intbits = spi-bits_per_word;
- unsigned intnpcs_pin;
- int ret;
as = spi_master_get_devdata(spi-master);
@@ -1017,27 +1017,13 @@ static int atmel_spi_setup(struct spi_device *spi)
csr |= SPI_BF(DLYBS, 0);
csr |= SPI_BF(DLYBCT, 0);
- /* chipselect must have been muxed as GPIO (e.g. in board setup) */
- npcs_pin = (unsigned int)spi-controller_data;
-
- if (gpio_is_valid(spi-cs_gpio))
- npcs_pin = spi-cs_gpio;
-
asd = spi-controller_state;
if (!asd) {
asd = kzalloc(sizeof(struct atmel_spi_device), GFP_KERNEL);
if (!asd)
return -ENOMEM;
- ret = gpio_request(npcs_pin, dev_name(spi-dev));
- if (ret) {
- kfree(asd);
- return ret;
- }
-
- asd-npcs_pin = npcs_pin;
spi-controller_state = asd;
- gpio_direction_output(npcs_pin, !(spi-mode SPI_CS_HIGH));
}
asd-csr = csr;
@@ -1290,6 +1276,15 @@ static int atmel_spi_probe(struct platform_device
*pdev)
[PATCH 1/5] ARM: dts: exynos5410: Clean up SMDK5410 indentation
The UART status properties are indented one level too deep, and we want
to derive a device tree for the ODROID-XU. Fix this before it propagates.
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index 7275bbd6fc4b..4c495de1bf68 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -70,13 +70,13 @@
};
uart0 {
- status = okay;
+ status = okay;
};
uart1 {
- status = okay;
+ status = okay;
};
uart2 {
- status = okay;
+ status = okay;
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/11] Documentation: devicetree: Fix ADI AXI SPDIF specification
Am 28.07.2014 14:20, schrieb Mark Brown: On Mon, Jul 28, 2014 at 01:43:02PM +0200, Andreas Färber wrote: Am 25.07.2014 12:39, schrieb Mark Brown: On Fri, Jul 25, 2014 at 12:32:43PM +0200, Andreas Färber wrote: Maybe this works for you? https://patchwork.kernel.org/patch/4620191/ Otherwise I can resend with Ab/Rb. Documentation/SubmittingPatches. Not helpful here, nor is Documentation/devicetree/bindings/submitting-patches.txt. It's separate from code changes, sent via git-send-email, has a Sob, went to LKML and LAKML and DTML. I could add a Fixes: header and CC trivial for this one-line fix IIUC. It's telling you that the kernel process is to review patches sent via e-mail, not random links to web appliations - notice the context to which I'm replying, I'm saying that sending a link to something on the web isn't a good way of submitting a patch. Doesn't tell me which patches I should CC you on in the future though. Therefore my request to fix the false negative in MAINTAINERS so that me and other kernel newbies don't run into it again. Feel free to submit patches if you want to see changes. Dude, this patch *was* submitted and has been reviewed by two people. Don't pretend I didn't follow the SubmittingPatches workflow. The link I gave you contains an mbox-format link that can be used with wget and git-am to *apply* the patch if you apparently missed it on the mailing lists. I will *re*-submit it for your convenience. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 1/2] dma: Add Xilinx AXI DMA DT Binding Documentation
On Monday 28 July 2014 17:47:48 Srikanth Thokala wrote: Device-tree binding documentation of Xilinx DMA Engine Signed-off-by: Srikanth Thokala stho...@xilinx.com Looks ok to me, Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] pcie: Add Xilinx PCIe Host Bridge IP driver
Hi Arnd and Rob,
I discussed with Bjorn and we believe this patch is in good shape to
apply. And Bjorn requires ACKs to apply this patch. So, could you
guys please review this patch and provided your ACKs to this patch.
Thanks
Srikanth
On Wed, Jul 23, 2014 at 9:33 PM, Srikanth Thokala stho...@xilinx.com wrote:
This is the driver for Xilinx AXI PCIe Host Bridge Soft IP
Signed-off-by: Srikanth Thokala stho...@xilinx.com
---
Changes in v5:
- Removed unnecessary checking of port structure.
- Changed the return type of verify_config from int to bool.
- Renamed following functions,
xilinx_pcie_is_link_up() - xilinx_pcie_link_is_up()
xilinx_pcie_verify_config() - xilinx_pcie_valid_device()
xilinx_pcie_get_config_base() - xilinx_pcie_config_base()
- Removed link_up bool flag from port structure, as it is not
being used.
- Removed unused constants.
- Rebased on 3.16-rc6.
- Fixed some minor comments.
- Thanks Bjorn for the review.
Changes in v4:
- Regarding the comments to separate ECAM functionality,
I have sent a separate patch and it is decided to implement
it later. The patch is here,
https://lkml.org/lkml/2014/5/18/54
- Fixed issue with adding configuration bus resource.
- Moved the logic for setting up bus resources to probe() from
pcie_setup().
- Instead of mapping all the MSI interrupts in the probe, changed
to map only when a MSI is requested.
- Earlier, the implementation of legacy and MSI interrupts init-
is mutually exclusive, now changed to have the legacy interrupts
init always and MSI interrupt init based on CONFIG_PCI_MSI flag.
- Regarding the MSI generic implementation comment, I will plan to
do on top of this driver patch.
- Rebased on 3.16-rc2.
- Fixed other minor comments.
- Thanks Arnd and Bjorn for the review.
Changes in v3:
- Rebased on v3.15.0-rc1
- Added support for interrupt-map DT functionality.
- Removed map_irq() wrapper, instead using of_irq_parse_and_map_pci().
- Modified resource mapping logic as per the series
PCI: ARM: add support for generic PCI host controller
- Modified devicetree binding documentation to update with interrupt-
map properties.
- Use devm calls wherever applicable.
- Fixed minor comments from Jason
- Thanks Jason for the review and suggestions.
Changes in v2:
- Rebased on v3.14.0-rc8
- Removed IP specific DT properties like include-rc, axibar-num etc.,
as suggested by Jason and Bjorn, Thanks
---
.../devicetree/bindings/pci/xilinx-pcie.txt| 62 ++
drivers/pci/host/Kconfig |7 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pci-xilinx.c | 978
4 files changed, 1048 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xilinx-pcie.txt
create mode 100644 drivers/pci/host/pci-xilinx.c
diff --git a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
new file mode 100644
index 000..3e2c88d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
@@ -0,0 +1,62 @@
+* Xilinx AXI PCIe Root Port Bridge DT description
+
+Required properties:
+- #address-cells: Address representation for root ports, set to 3
+- #size-cells: Size representation for root ports, set to 2
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- compatible: Should contain xlnx,axi-pcie-host-1.00.a
+- reg: Should contain AXI PCIe registers location and length
+- device_type: must be pci
+- interrupts: Should contain AXI PCIe interrupt
+- interrupt-map-mask,
+ interrupt-map: standard PCI properties to define the mapping of the
+ PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+ supported by hardware)
+ Please refer to the standard PCI bus binding document for a more
+ detailed explanation
+
+Optional properties:
+- bus-range: PCI bus numbers covered
+
+Interrupt controller child node
+Required properties:
+- interrupt-controller: identifies the node as an interrupt controller
+- #address-cells: specifies the number of cells needed to encode an
+ address. The value must be 0.
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+
+NOTE:
+The core provides a single interrupt for both INTx/MSI messages. So,
+created a interrupt controller node to support 'interrupt-map' DT
+functionality. The driver will create an IRQ domain for this map, decode
+the four INTx interrupts in ISR and route them to this domain.
+
+
+Example:
+
+
+ pci_express: axi-pcie@5000 {
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+
Re: [PATCH v3 1/2] dma: Add Xilinx AXI DMA DT Binding Documentation
On Mon, Jul 28, 2014 at 5:58 PM, Arnd Bergmann a...@arndb.de wrote: On Monday 28 July 2014 17:47:48 Srikanth Thokala wrote: Device-tree binding documentation of Xilinx DMA Engine Signed-off-by: Srikanth Thokala stho...@xilinx.com Looks ok to me, Acked-by: Arnd Bergmann a...@arndb.de Thanks Arnd. Srikanth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
[PATCHv2 0/3] iio: adc: exynos_adc: Add support for s3c64xx/s3c24xx ADC
This patch add support for s3c64xx/s3c24xx ADC. s3c64xx/s3c24xx is alomost same as ADCv1. But, s3c64xx/s3c24xx has a little difference from ADCv1 as following: - ADCMUX register address to select channel - ADCDAT mask (10bit or 12bit ADC resolution according to SoC version) - s3c24xx/s3c64xx has not included ADC_PHY enable register Changes from v1: - Fix minor coding style. - Remove the sentence which reading DATY register. - Add ARCH_S3C24XX / ARCH_S3C64XX dependency for EXYNOS_ADC to Kconfig. - Remove the function pointer of 'clear_irq' for s3c24xx becase s3c24xx has not included ADC_V1_INTCLR register. - Remove un-necessary white-space in dt-binding documentation Arnd Bergmann (1): iio: adc: exynos_adc: add support for s3c64xx adc Chanwoo Choi (2): iio: adc: exynos_adc: Add support for s3c24xx ADC dt-bindings: samsung: exynos_adc: Remove un-necessary white-sapce .../devicetree/bindings/arm/samsung/exynos-adc.txt | 20 ++- drivers/iio/adc/Kconfig| 2 +- drivers/iio/adc/exynos_adc.c | 137 +++-- 3 files changed, 144 insertions(+), 15 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/3] dt-bindings: samsung: exynos_adc: Remove un-necessary white-sapce
This patch remove un-necessary white-sapce to code clean. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt index 709efaa..5ee0266 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt @@ -30,7 +30,7 @@ Required properties: - The base address and range of ADC register - The base address and range of ADC_PHY register (every SoC except for s3c24xx/s3c64xx ADC) -- interrupts: Contains the interrupt information for the timer. The +- interrupts: Contains the interrupt information for the timer. The format is being dependent on which interrupt controller the Samsung device uses. - #io-channel-cells = 1; As ADC has multiple outputs -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/3] iio: adc: exynos_adc: add support for s3c64xx adc
From: Arnd Bergmann a...@arndb.de
The ADC in s3c64xx is almost the same as exynosv1, but
has a different 'select' method. Adding this here will be
helpful to move over the existing s3c64xx platform from the
legacy plat-samsung/adc driver to the new exynos-adc.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 ++
drivers/iio/adc/exynos_adc.c | 28 +-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index adc61b0..d3dad46 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -16,6 +16,8 @@ Required properties:
future controllers.
Must be samsung,exynos3250-adc for
controllers compatible with ADC of Exynos3250.
+ Must be samsung,s3c6410-adc for
+ the ADC in s3c6410 and compatibles
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 87e0895..ed9e4c8 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,7 +40,7 @@
#include linux/iio/machine.h
#include linux/iio/driver.h
-/* EXYNOS4412/5250 ADC_V1 registers definitions */
+/* S3C/EXYNOS4412/5250 ADC_V1 registers definitions */
#define ADC_V1_CON(x) ((x) + 0x00)
#define ADC_V1_DLY(x) ((x) + 0x08)
#define ADC_V1_DATX(x) ((x) + 0x0C)
@@ -61,6 +61,9 @@
#define ADC_V1_CON_PRSCLV(x) (((x) 0xFF) 6)
#define ADC_V1_CON_STANDBY (1u 2)
+/* Bit definitions for S3C2410 ADC */
+#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3)
+
/* Bit definitions for ADC_V2 */
#define ADC_V2_CON1_SOFT_RESET (1u 2)
@@ -217,6 +220,26 @@ static const struct exynos_adc_data const
exynos_adc_v1_data = {
.start_conv = exynos_adc_v1_start_conv,
};
+static void exynos_adc_s3c64xx_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1;
+
+ con1 = readl(ADC_V1_CON(info-regs));
+ con1 = ~ADC_S3C2410_CON_SELMUX(0x7);
+ con1 |= ADC_S3C2410_CON_SELMUX(addr);
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info-regs));
+}
+
+static struct exynos_adc_data const exynos_adc_s3c64xx_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+
+ .init_hw= exynos_adc_v1_init_hw,
+ .exit_hw= exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_s3c64xx_start_conv,
+};
+
static void exynos_adc_v2_init_hw(struct exynos_adc *info)
{
u32 con1, con2;
@@ -285,6 +308,9 @@ static const struct exynos_adc_data const
exynos3250_adc_data = {
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c6410-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
.compatible = samsung,exynos-adc-v1,
.data = exynos_adc_v1_data,
}, {
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] pcie: Add Xilinx PCIe Host Bridge IP driver
On Monday 28 July 2014 18:04:34 Srikanth Thokala wrote: Hi Arnd and Rob, I discussed with Bjorn and we believe this patch is in good shape to apply. And Bjorn requires ACKs to apply this patch. So, could you guys please review this patch and provided your ACKs to this patch. Looks great for the most part. I've looked through the whole driver again, and I have two small issues remaining: a) Please clarify in the changeset description why there is no support for PCI I/O space. b) I think you should use the 'msi-parent' property, and the of_pci_find_msi_chip_by_node() to find the msi_chip for the PCI controller. This will make it possible to forward MSIs to the main interrupt controller in the system, which is more efficient. See the pcie-mvebu driver for an example of this. Other than these: Acked-by: Arnd Bergmann a...@arndb.de 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] Documentation: devicetree: Fix ADI AXI SPDIF specification
The specification requires compatible = adi,axi-spdif-1.00.a but driver and example and file name indicate adi,axi-spdif-tx-1.00.a. Change the specification to match the implementation. Acked-by: Lars-Peter Clausen l...@metafoo.de Reviewed-by: Michal Simek michal.si...@xilinx.com Fixes: d7b528eff927 (dt: Add bindings documentation for the ADI AXI-SPDIF audio controller) Signed-off-by: Andreas Färber afaer...@suse.de --- v2 - v3: * Added Fixes header * CC broonie (Mark Brown) v2: New Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt b/Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt index 46f344965313..4eb7997674a0 100644 --- a/Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt +++ b/Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt @@ -1,7 +1,7 @@ ADI AXI-SPDIF controller Required properties: - - compatible : Must be adi,axi-spdif-1.00.a + - compatible : Must be adi,axi-spdif-tx-1.00.a - reg : Must contain SPDIF core's registers location and length - clocks : Pairs of phandle and specifier referencing the controller's clocks. The controller expects two clocks, the clock used for the AXI interface and -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V3 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Andrew,
On Sun, Jul 27, 2014 at 03:55:09AM +0200, Andrew Lunn wrote:
On Sat, Jul 26, 2014 at 04:48:10PM -0700, Benoit Masson wrote:
The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
USB2.0 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
http://shop.lenovo.com/us/en/servers/network-storage/lenovoemc/ix4-300d/
Signed-off-by: Benoit Masson ya...@perenite.com
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 285
2 files changed, 287 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
...
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
new file mode 100644
index 000..c82a8e3
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
...
+ i2c@11000 {
+ compatible = marvell,mv64xxx-i2c;
O.K, this version is good.
Is it? As Arnd mentioned against the previous version, this overrides
the default compatible property inherited from the dtsi. Since this is
also compatible with marvell,mv78230-i2c, I think we should just
delete this line.
Benoit, this is still in V4. If Andrew agrees, I'll just remove the
line when I apply V4.
Acked-by: Andrew Lunn and...@lunn.ch
thx,
Jason.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V3 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Benoit, this is still in V4. If Andrew agrees, I'll just remove the line when I apply V4. I'm wrong, Arnd is right. Andrew -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v4 07/21] of: add of_node_ncmp wrapper
On Fri, 11 Jul 2014 16:04:10 +0200, Jacek Anaszewski j.anaszew...@samsung.com wrote: The wrapper for strnicmp is required for checking whether a node has expected prefix. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Grant Likely grant.lik...@linaro.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Michal Simek mon...@monstr.eu --- include/linux/of.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/of.h b/include/linux/of.h index 692b56c..9a53eea 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -199,6 +199,7 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size) #define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2)) #define of_prop_cmp(s1, s2) strcmp((s1), (s2)) #define of_node_cmp(s1, s2) strcasecmp((s1), (s2)) +#define of_node_ncmp(s1, s2, n) strnicmp((s1), (s2), (n)) #endif Don't forget to add an of_node_ncmp() define to arch/sparc/include/asm/prom.h. Sparc has its own rules. g. -- 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] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list.
Benoit, On Wed, Jul 23, 2014 at 03:35:22PM -0700, Benoit Masson wrote: Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational computer technology company with headquarters in Beijing, China, and Morrisville, North Carolina, United States. http://www.lenovo.com/ Signed-off-by: Benoit Masson ya...@perenite.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) Applied to mvebu/dt with a few minor style changes to the commit log. - Added a blank line between the URL and the S-o-B. - Reflowed the paragraph to wrap at 80 chars - Changed subject to match other changes to vendor-prefixes.txt The Subject line now reads: of: Add Lenovo Group Ltd. to the vendor-prefixes list. You can view the patch here: http://git.infradead.org/linux-mvebu.git/commitdiff/74e025501bb834000b3c7eceab69383806520a36 Next, it'll go to arm-soc. Then, Linus' tree. thx, Jason. -- 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 09/11] Documentation: devicetree: Fix ADI AXI SPDIF specification
On Mon, Jul 28, 2014 at 02:28:12PM +0200, Andreas Färber wrote: Dude, this patch *was* submitted and has been reviewed by two people. Don't pretend I didn't follow the SubmittingPatches workflow. The link I gave you contains an mbox-format link that can be used with wget and git-am to *apply* the patch if you apparently missed it on the mailing lists. I will *re*-submit it for your convenience. Which is what I originally requested when I got CCed into the thread - I'm being grumpy because instead of getting the patch sent to me as requested I got sent a link to patchwork. signature.asc Description: Digital signature
Re: [PATCHv9 4/4] dt: mailbox: add generic bindings
On Wed, 23 Jul 2014 00:27:36 +0530, Jassi Brar jaswinder.si...@linaro.org
wrote:
Define generic bindings for the framework clients to
request mailbox channels.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
Looks okay to me.
g.
---
.../devicetree/bindings/mailbox/mailbox.txt| 36
++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/mailbox.txt
b/Documentation/devicetree/bindings/mailbox/mailbox.txt
new file mode 100644
index 000..bb79678
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mailbox.txt
@@ -0,0 +1,36 @@
+* Generic Mailbox Controller and client driver bindings
+
+Generic binding to provide a way for Mailbox controller drivers to
+assign appropriate mailbox channel to client drivers.
+
+* Mailbox Controller
+
+Required property:
+- #mbox-cells: Must be at least 1. Number of cells in a mailbox
+ specifier.
+
+Example:
+ mailbox: mailbox {
+ ...
+ #mbox-cells = 1;
+ };
+
+
+* Mailbox Client
+
+Required property:
+- mboxes: List of phandle and mailbox channel specifiers.
+
+Optional property:
+- mbox-names: List of identifier strings for each mailbox channel
+ required by the client. The use of this property
+ is discouraged in favor of using index in list of
+ 'mboxes' while requesting a mailbox.
+
+Example:
+ pwr_cntrl: power {
+ ...
+ mbox-names = pwr-ctrl, rpc;
+ mboxes = mailbox 0
+ mailbox 1;
+ };
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Benoit, On Sun, Jul 27, 2014 at 04:30:39PM -0700, Benoit Masson wrote: The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb, USB2.0 3.0, powered by a Marvell Armada XP MV78230 dual core CPU. http://shop.lenovo.com/us/en/servers/network-storage/lenovoemc/ix4-300d/ Signed-off-by: Benoit Masson ya...@perenite.com --- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 285 2 files changed, 287 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts I've applied this to mvebu/dt with a few minor fixups. - Insert empty line between URL and S-o-B - Removed i2c compatible property - Removed trailing whitespace from multi-line comment at end of file Also, traditionally, the 'V4' goes inside the square brackets, eg [ PATCH V4 2/2 ] ... This is done because 'git am ...' automagically removes everything between the square brackets and then takes the rest of the subject line to be the first line of the commit message. Well done! You can view the commit here: http://git.infradead.org/linux-mvebu.git/commitdiff/40c2da45366171bdc9ad1968489aaae190248383 thx, Jason. -- 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 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko
grygorii.stras...@ti.com wrote:
Use clkops-clocks property to specify clocks handled by
clock_ops domain PM domain. Only clocks defined in clkops-clocks
set of clocks will be handled by Runtime PM through clock_ops
Pm domain.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/of/of_clk.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
index 35f5e9f..5f9b90e 100644
--- a/drivers/of/of_clk.c
+++ b/drivers/of/of_clk.c
@@ -86,11 +86,8 @@ int of_clk_register_runtime_pm_clocks(struct device_node
*np,
struct clk *clk;
int error;
- for (i = 0; (clk = of_clk_get(np, i)) !IS_ERR(clk); i++) {
- if (!clk_may_runtime_pm(clk)) {
- clk_put(clk);
- continue;
- }
+ for (i = 0; (clk = of_clk_get_from_set(np, clkops, i))
+ !IS_ERR(clk); i++) {
This really looks like an ABI break to me. What happens to all the
existing platforms who don't have this new clkops-clocks in their device
tree?
g.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Le 28 juil. 2014 à 16:08, Jason Cooper ja...@lakedaemon.net a écrit : Benoit, On Sun, Jul 27, 2014 at 04:30:39PM -0700, Benoit Masson wrote: The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb, USB2.0 3.0, powered by a Marvell Armada XP MV78230 dual core CPU. http://shop.lenovo.com/us/en/servers/network-storage/lenovoemc/ix4-300d/ Signed-off-by: Benoit Masson ya...@perenite.com --- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 285 2 files changed, 287 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts I've applied this to mvebu/dt with a few minor fixups. - Insert empty line between URL and S-o-B - Removed i2c compatible property - Removed trailing whitespace from multi-line comment at end of file Also, traditionally, the 'V4' goes inside the square brackets, eg [ PATCH V4 2/2 ] ... This is done because 'git am ...' automagically removes everything between the square brackets and then takes the rest of the subject line to be the first line of the commit message. Well done! Thanks Jason and all for supporting this and following up long discussions on A0 stepping ... ! Just one question is how would you link this patch to the quirk a0 patch since this patch can't work without it ... You can view the commit here: http://git.infradead.org/linux-mvebu.git/commitdiff/40c2da45366171bdc9ad1968489aaae190248383 thx, Jason. -- 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 RESEND 1/4] drivers: of: add automated assignment of reserved regions to client devices
On Mon, 14 Jul 2014 10:28:04 +0200, Marek Szyprowski m.szyprow...@samsung.com
wrote:
This patch adds code for automated assignment of reserved memory regions
to struct device. reserved_mem-ops-device_init()/device_cleanup()
callbacks are called to perform reserved memory driver specific
initialization and cleanup
Based on previous code provided by Josh Cartwright jo...@codeaurora.org
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Applied, thanks
g.
---
drivers/of/of_reserved_mem.c| 70
+
include/linux/of_reserved_mem.h | 7 +
2 files changed, 77 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 632aae861375..59fb12e84e6b 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -206,8 +206,16 @@ void __init fdt_init_reserved_mem(void)
for (i = 0; i reserved_mem_count; i++) {
struct reserved_mem *rmem = reserved_mem[i];
unsigned long node = rmem-fdt_node;
+ int len;
+ const __be32 *prop;
int err = 0;
+ prop = of_get_flat_dt_prop(node, phandle, len);
+ if (!prop)
+ prop = of_get_flat_dt_prop(node, linux,phandle, len);
+ if (prop)
+ rmem-phandle = of_read_number(prop, len/4);
+
if (rmem-size == 0)
err = __reserved_mem_alloc_size(node, rmem-name,
rmem-base, rmem-size);
@@ -215,3 +223,65 @@ void __init fdt_init_reserved_mem(void)
__reserved_mem_init_node(rmem);
}
}
+
+static inline struct reserved_mem *__find_rmem(struct device_node *node)
+{
+ unsigned int i;
+
+ if (!node-phandle)
+ return NULL;
+
+ for (i = 0; i reserved_mem_count; i++)
+ if (reserved_mem[i].phandle == node-phandle)
+ return reserved_mem[i];
+ return NULL;
+}
+
+/**
+ * of_reserved_mem_device_init() - assign reserved memory region to given
device
+ *
+ * This function assign memory region pointed by memory-region device tree
+ * property to the given device.
+ */
+void of_reserved_mem_device_init(struct device *dev)
+{
+ struct reserved_mem *rmem;
+ struct device_node *np;
+
+ np = of_parse_phandle(dev-of_node, memory-region, 0);
+ if (!np)
+ return;
+
+ rmem = __find_rmem(np);
+ of_node_put(np);
+
+ if (!rmem || !rmem-ops || !rmem-ops-device_init)
+ return;
+
+ rmem-ops-device_init(rmem, dev);
+ dev_info(dev, assigned reserved memory node %s\n, rmem-name);
+}
+
+/**
+ * of_reserved_mem_device_release() - release reserved memory device
structures
+ *
+ * This function releases structures allocated for memory region handling for
+ * the given device.
+ */
+void of_reserved_mem_device_release(struct device *dev)
+{
+ struct reserved_mem *rmem;
+ struct device_node *np;
+
+ np = of_parse_phandle(dev-of_node, memory-region, 0);
+ if (!np)
+ return;
+
+ rmem = __find_rmem(np);
+ of_node_put(np);
+
+ if (!rmem || !rmem-ops || !rmem-ops-device_release)
+ return;
+
+ rmem-ops-device_release(rmem, dev);
+}
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index 4669ddfdd5af..5b5efae09135 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -8,6 +8,7 @@ struct reserved_mem_ops;
struct reserved_mem {
const char *name;
unsigned long fdt_node;
+ unsigned long phandle;
const struct reserved_mem_ops *ops;
phys_addr_t base;
phys_addr_t size;
@@ -27,10 +28,16 @@ typedef int (*reservedmem_of_init_fn)(struct reserved_mem
*rmem);
_OF_DECLARE(reservedmem, name, compat, init, reservedmem_of_init_fn)
#ifdef CONFIG_OF_RESERVED_MEM
+void of_reserved_mem_device_init(struct device *dev);
+void of_reserved_mem_device_release(struct device *dev);
+
void fdt_init_reserved_mem(void);
void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
phys_addr_t base, phys_addr_t size);
#else
+static inline void of_reserved_mem_device_init(struct device *dev) { }
+static inline void of_reserved_mem_device_release(struct device *pdev) { }
+
static inline void fdt_init_reserved_mem(void) { }
static inline void fdt_reserved_mem_save_node(unsigned long node,
const char *uname, phys_addr_t base, phys_addr_t size) { }
--
1.9.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 v2 RESEND 2/4] drivers: of: initialize and assign reserved memory to newly created devices
On Mon, 14 Jul 2014 10:28:05 +0200, Marek Szyprowski m.szyprow...@samsung.com
wrote:
Use recently introduced of_reserved_mem_device_init() function to
automatically assign respective reserved memory region to the newly created
platform and amba device.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
I'm still not okay with this patch. I don't think it is appropriate to
add the hook into the generic path that gets used for every platform
device. The devices that need reserved memory should explicitly request
it, and any setup be done at that time.
g.
---
drivers/of/platform.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 500436f9be7f..a9055d3da5c2 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -21,6 +21,7 @@
#include linux/of_device.h
#include linux/of_irq.h
#include linux/of_platform.h
+#include linux/of_reserved_mem.h
#include linux/platform_device.h
const struct of_device_id of_default_bus_match_table[] = {
@@ -233,12 +234,15 @@ static struct platform_device
*of_platform_device_create_pdata(
dev-dev.bus = platform_bus_type;
dev-dev.platform_data = platform_data;
+ of_reserved_mem_device_init(dev-dev);
+
/* We do not fill the DMA ops for platform devices by default.
* This is currently the responsibility of the platform code
* to do such, possibly using a device notifier
*/
if (of_device_add(dev) != 0) {
+ of_reserved_mem_device_release(dev-dev);
platform_device_put(dev);
goto err_clear_flag;
}
@@ -300,6 +304,8 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
else
of_device_make_bus_id(dev-dev);
+ of_reserved_mem_device_init(dev-dev);
+
/* Allow the HW Peripheral ID to be overridden */
prop = of_get_property(node, arm,primecell-periphid, NULL);
if (prop)
@@ -326,6 +332,7 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
return dev;
err_free:
+ of_reserved_mem_device_release(dev-dev);
amba_device_put(dev);
err_clear_flag:
of_node_clear_flag(node, OF_POPULATED);
--
1.9.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 0/4] Support for Qualcomm QPNP PMIC's
Hi all, On 07/24/2014 03:45 PM, Stanimir Varbanov wrote: Hello all, Changes since v2: - 1/4 - added new line, signed-off-by / acked-by and module_authors. - 3/4 - the subject has been changed. The previous v2 can be found at [1]. I'm still waiting Acks for: - 4/4 from Qualcomm folks. - 2/4 and 3/4 from DT folks. Can you look at these patches, please. -- regards, Stan -- 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] devicetree: bindings: document Broadcom CPU enable method
On Mon, Jun 30, 2014 at 05:09:45PM -0500, Alex Elder wrote: Broadcom mobile SoCs use a ROM-implemented holding pen for controlled boot of secondary cores. A special register is used to communicate to the ROM that a secondary core should start executing kernel code. This enable method is currently used for members of the bcm281xx and bcm21664 SoC families. The use of an enable method also allows the SMP operation vector to be assigned as a result of device tree content for these SoCs. Signed-off-by: Alex Elder el...@linaro.org Applied to mach-bcm for-3.17/dt Thanks, Matt -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Benoit, On Mon, Jul 28, 2014 at 04:13:59PM +0200, Benoit Masson wrote: Just one question is how would you link this patch to the quirk a0 patch since this patch can't work without it ... Even though both patches are needed to boot successfully, there is no dependency between them in order to compile. So, they will live in separate branches until those branches get merged together in a final release. The code changes will be applied as a fix to v3.16, and the dts change will, hopefully, make it in to v3.17. Where v3.17 will already contain the code fixes. thx, Jason. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
On Sat, Jul 26, 2014 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
On Fri, 25 Jul 2014, Vinod Koul wrote:
On Fri, Jul 25, 2014 at 05:00:53PM +0200, Guennadi Liakhovetski wrote:
Hi Vinod,
On Fri, 25 Jul 2014, Vinod Koul wrote:
Thanks for your review. However, I find the following a bit odd. As you
remember, you already reviewed v2 of this driver:
http://www.spinics.net/lists/dmaengine/msg00880.html
and provided your comments to it, which I addressed in versions 3 and 4.
Code, that you're commenting on here, hasn't (significantly) changed
since
v1. During your v2 review it didn't seem offending to you, now it does.
Does this mean, that if / once I fix these issues, your next review might
find some more _old_ code snippets, that you decide aren't appropriate?
This isn't the first time such a thing is happening with various
reviewers
and patch submitters. I think a reasonable approach is to trust your own
review. Once I've reviewed a piece of code and found it ok, I _normally_
won't ask a patch author to modify code, that didn't change since my
previous review. Simple. Of course, sometimes it does happen, that the
first review skips some important flaws, but then I consider that my
fault, if I didn't find them during the first round and try to find a
solution to minimise the damage to the author. Now, to specific comments.
I agree you can blame me for not spotting them earlier and yes criticism is
fair. But then overall goal is to ensure that code is better, so even if
comment comes late we should accept it.
Apparently, our approaches differ somewhat here. I explained already what
I normally do in such cases.
On Sat, Jul 19, 2014 at 12:48:51PM +0200, Guennadi Liakhovetski wrote:
This patch adds a driver for NBPF DMAC IP cores from Renesas,
designed for
the AMBA AXI bus.
+struct nbpf_desc {
+ struct dma_async_tx_descriptor async_tx;
+ bool user_wait;
sounds odd?
Maybe it's not the best name, I can gladly try to improve it, but I'm
sure
I'm not the best namer, so, the same can be said about more or less
every identifier in all my code - it could be improved. However, I don't
think it's critical enough to delay mainlining until the next kernel
version?
No it is not critical at all!
+static int nbpf_chan_probe(struct nbpf_device *nbpf, int n)
+{
+ struct dma_device *dma_dev = nbpf-dma_dev;
+ struct nbpf_channel *chan = nbpf-chan + n;
+ int ret;
+
+ chan-nbpf = nbpf;
+ chan-base = nbpf-base + NBPF_REG_CHAN_OFFSET +
NBPF_REG_CHAN_SIZE * n;
+ INIT_LIST_HEAD(chan-desc_page);
+ spin_lock_init(chan-lock);
+ chan-dma_chan.device = dma_dev;
+ dma_cookie_init(chan-dma_chan);
+ nbpf_chan_prepare_default(chan);
+
+ dev_dbg(dma_dev-dev, %s(): channel %d: - %p\n, __func__, n,
chan-base);
+
+ snprintf(chan-name, sizeof(chan-name), nbpf %d, n);
+
+ ret = devm_request_threaded_irq(dma_dev-dev, chan-irq,
+ nbpf_chan_irq, nbpf_chan_irqt, IRQF_SHARED,
+ chan-name, chan);
devm_request_irq and friends arent apt here. You are in .remove and get
an
irq, what prevents that race?
How is this your comment different for DMA drivers from any other
drivers?
Of course you have to make sure no more interrupts are arriving once in
.remove() you lost the ability to handle IRQs. So, AFAIU, it's always a
per-case study: you have to look at .remove() and consider, what happens
if IRQ hits at any point inside it - if at all possible. Besides, DMA
engine drivers are additionally protected by incremented module
use-counts, once a channel is in use? As soon as a channel is released
your driver has to make sure no more IRQs are occurring. Besides, there's
a dmaengine_get()... So, I think, we really need to first find a race
possibility, and then fix it. Besides, you could try
grep -rl devm_request_irq drivers/dma/*.c
And please also see there were regression on few of them, recently dw was
fixed for this case. Similarly few other drivers were fixed for their
behaviour in tasklet kill, syncronizing the irq and freeing up behaviour.
So now back to this driver, since you are using devm_ the irq is not freed,
so how does it prevent race.
How is it not freed? Of course it is freed, but later - after .release()
has completed.
Looking at the code again, I think we need to free irq (you can call
devm_free_irq()) and call syncronize_irq so that anything pending is
flushed. So if you can send follow up patch doing these in .remove, we can
merge these
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
Hi Vinod,
On Mon, 28 Jul 2014, Vinod Koul wrote:
On Sat, Jul 26, 2014 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
On Fri, 25 Jul 2014, Vinod Koul wrote:
On Fri, Jul 25, 2014 at 05:00:53PM +0200, Guennadi Liakhovetski wrote:
Hi Vinod,
On Fri, 25 Jul 2014, Vinod Koul wrote:
Thanks for your review. However, I find the following a bit odd. As you
remember, you already reviewed v2 of this driver:
http://www.spinics.net/lists/dmaengine/msg00880.html
and provided your comments to it, which I addressed in versions 3 and
4.
Code, that you're commenting on here, hasn't (significantly) changed
since
v1. During your v2 review it didn't seem offending to you, now it does.
Does this mean, that if / once I fix these issues, your next review
might
find some more _old_ code snippets, that you decide aren't appropriate?
This isn't the first time such a thing is happening with various
reviewers
and patch submitters. I think a reasonable approach is to trust your
own
review. Once I've reviewed a piece of code and found it ok, I
_normally_
won't ask a patch author to modify code, that didn't change since my
previous review. Simple. Of course, sometimes it does happen, that the
first review skips some important flaws, but then I consider that my
fault, if I didn't find them during the first round and try to find a
solution to minimise the damage to the author. Now, to specific
comments.
I agree you can blame me for not spotting them earlier and yes criticism
is
fair. But then overall goal is to ensure that code is better, so even if
comment comes late we should accept it.
Apparently, our approaches differ somewhat here. I explained already what
I normally do in such cases.
On Sat, Jul 19, 2014 at 12:48:51PM +0200, Guennadi Liakhovetski wrote:
This patch adds a driver for NBPF DMAC IP cores from Renesas,
designed for
the AMBA AXI bus.
+struct nbpf_desc {
+ struct dma_async_tx_descriptor async_tx;
+ bool user_wait;
sounds odd?
Maybe it's not the best name, I can gladly try to improve it, but I'm
sure
I'm not the best namer, so, the same can be said about more or less
every identifier in all my code - it could be improved. However, I
don't
think it's critical enough to delay mainlining until the next kernel
version?
No it is not critical at all!
+static int nbpf_chan_probe(struct nbpf_device *nbpf, int n)
+{
+ struct dma_device *dma_dev = nbpf-dma_dev;
+ struct nbpf_channel *chan = nbpf-chan + n;
+ int ret;
+
+ chan-nbpf = nbpf;
+ chan-base = nbpf-base + NBPF_REG_CHAN_OFFSET +
NBPF_REG_CHAN_SIZE * n;
+ INIT_LIST_HEAD(chan-desc_page);
+ spin_lock_init(chan-lock);
+ chan-dma_chan.device = dma_dev;
+ dma_cookie_init(chan-dma_chan);
+ nbpf_chan_prepare_default(chan);
+
+ dev_dbg(dma_dev-dev, %s(): channel %d: - %p\n, __func__, n,
chan-base);
+
+ snprintf(chan-name, sizeof(chan-name), nbpf %d, n);
+
+ ret = devm_request_threaded_irq(dma_dev-dev, chan-irq,
+ nbpf_chan_irq, nbpf_chan_irqt, IRQF_SHARED,
+ chan-name, chan);
devm_request_irq and friends arent apt here. You are in .remove and
get an
irq, what prevents that race?
How is this your comment different for DMA drivers from any other
drivers?
Of course you have to make sure no more interrupts are arriving once in
.remove() you lost the ability to handle IRQs. So, AFAIU, it's always a
per-case study: you have to look at .remove() and consider, what
happens
if IRQ hits at any point inside it - if at all possible. Besides, DMA
engine drivers are additionally protected by incremented module
use-counts, once a channel is in use? As soon as a channel is released
your driver has to make sure no more IRQs are occurring. Besides,
there's
a dmaengine_get()... So, I think, we really need to first find a race
possibility, and then fix it. Besides, you could try
grep -rl devm_request_irq drivers/dma/*.c
And please also see there were regression on few of them, recently dw was
fixed for this case. Similarly few other drivers were fixed for their
behaviour in tasklet kill, syncronizing the irq and freeing up behaviour.
So now back to this driver, since you are using devm_ the irq is not
freed,
so how does it prevent race.
How is it not freed? Of course it is freed, but later - after .release()
has completed.
Looking at the code again, I think we need to free irq (you can call
devm_free_irq()) and call syncronize_irq so that anything pending is
flushed. So if you can send follow up
Re: [PATCH] Enabling OF selftest to run without machine's devicetree
Hi Rob,
On Jul 27, 2014, at 12:11 AM, Rob Herring wrote:
On Sat, Jul 26, 2014 at 2:48 PM, Gaurav Minocha
gaurav.minocha...@gmail.com wrote:
If there is no devicetree present, this patch adds the selftest
data as a live devicetree. It also removes the same after the
testcase execution is complete.
Tested with and without machine's devicetree.
Signed-off-by: Gaurav Minocha gaurav.minocha...@gmail.com
---
drivers/of/fdt.c |3 +++
drivers/of/selftest.c | 34 ++
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index b777d8f..18088c0 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -366,6 +366,9 @@ void of_fdt_unflatten_tree(unsigned long *blob,
struct device_node **mynodes)
{
__unflatten_device_tree(blob, mynodes, kernel_tree_alloc);
+
+ /* Get pointer to /chosen and /aliases nodes for use everywhere
*/
+ of_alias_scan(kernel_tree_alloc);
}
EXPORT_SYMBOL_GPL(of_fdt_unflatten_tree);
diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index 3a1c5b5..34c9899 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -16,6 +16,7 @@
#include linux/mutex.h
#include linux/slab.h
#include linux/device.h
+#include linux/proc_fs.h
static struct selftest_results {
int passed;
@@ -25,6 +26,7 @@ static struct selftest_results {
#define NO_OF_NODES 2
static struct device_node *nodes[NO_OF_NODES];
static int last_node_index;
+static bool selftest_live_tree;
#define selftest(result, fmt, ...) { \
if (!(result)) { \
@@ -595,7 +597,7 @@ static int attach_node_and_children(struct device_node
*np)
static int __init selftest_data_add(void)
{
void *selftest_data;
- struct device_node *selftest_data_node;
+ struct device_node *selftest_data_node, *np;
extern uint8_t __dtb_testcases_begin[];
extern uint8_t __dtb_testcases_end[];
const int size = __dtb_testcases_end - __dtb_testcases_begin;
@@ -614,10 +616,31 @@ static int __init selftest_data_add(void)
not running tests\n, __func__);
return -ENOMEM;
}
- of_fdt_unflatten_tree(selftest_data, selftest_data_node);
Can't you keep this factored out and just do of_allnodes =
selftest_data_node;?
As far as I can tell the new node full name path walk method from Grant
requires of_allnodes to be pointing to the root of the tree. Is that the case
here?
- /* attach the sub-tree to live tree */
- return attach_node_and_children(selftest_data_node);
+ if (!of_allnodes) {
+ /* enabling flag for removing nodes */
+ selftest_live_tree = true;
If you save the selftest_data_node ptr, then you could test for
(selftest_data_node == of_allnodes) instead of this bool. You may want
the pointer for some other reason later although I can't think of one
right now.
+
+ of_fdt_unflatten_tree(selftest_data, of_allnodes);
+ if (!of_allnodes) {
+ pr_warn(%s: No tree to attach; not running tests\n,
+ __func__);
+ return -ENODATA;
+ }
+
+ for_each_of_allnodes(np)
+ of_node_add(np);
+
+ /* Symlink in /proc as required by userspace ABI */
+ proc_symlink(device-tree, NULL,
/sys/firmware/devicetree/base);
+
+ return 0;
+ } else {
+ of_fdt_unflatten_tree(selftest_data, selftest_data_node);
+
+ /* attach the sub-tree to live tree */
+ return attach_node_and_children(selftest_data_node);
+ }
}
/**
@@ -646,6 +669,9 @@ static void selftest_data_remove(void)
struct device_node *np;
struct property *prop;
+ if (selftest_live_tree)
+ return detach_node_and_children(of_allnodes);
+
while (last_node_index = 0) {
if (nodes[last_node_index]) {
np =
of_find_node_by_path(nodes[last_node_index]-full_name);
--
Regards
-- Pantelis--
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] Enabling OF selftest to run without machine's devicetree
On Sun, Jul 27, 2014 at 10:28 PM, Gaurav Minocha
gaurav.minocha...@gmail.com wrote:
On Sat, Jul 26, 2014 at 3:17 PM, Gaurav Minocha
gaurav.minocha...@gmail.com wrote:
On Sat, Jul 26, 2014 at 2:11 PM, Rob Herring robherri...@gmail.com wrote:
On Sat, Jul 26, 2014 at 2:48 PM, Gaurav Minocha
gaurav.minocha...@gmail.com wrote:
If there is no devicetree present, this patch adds the selftest
data as a live devicetree. It also removes the same after the
testcase execution is complete.
[...]
@@ -614,10 +616,31 @@ static int __init selftest_data_add(void)
not running tests\n, __func__);
return -ENOMEM;
}
- of_fdt_unflatten_tree(selftest_data, selftest_data_node);
Can't you keep this factored out and just do of_allnodes =
selftest_data_node;?
I tried to do that in first place, but of_alias_scan() called from
of_fdt_unflatten_tree(..)
needs of_allnodes. So, had to call it separately.
No, it is not or I'm missing some change. Or it is a bug? It is called
from unflatten_device_tree which is the early boot version.
Actually, it's possible if rather than calling of_alias_scan from
of_fdt_unflatten_tree, I write a wrapper and export it as below.
So, I will be able to call of_fdt_alias_scan explicitly.
of_fdt_alias_scan()
{
of_alias_scan(kernel_tree_alloc);
}
EXPORT_SYMBOL(of_fdt_alias_scan)
I prefer to keep this internal to the DT code. Plus of_fdt_* functions
operate on a flat tree and of_alias_scan operates on unflattened tree.
OR
directly export of_alias_scan() and
kernel_tree_alloc(u64 size, u64 align)
please let me know if I should follow either of the above
approach in my next patch.
Perhaps as you had it is fine.
Rob
--
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: at91: spi: request all csgpio in spi probe
Hello Jiri,
The least you can do when someone helps you debugging something is to
keep him in Cc of the following versions of your patch...
On Mon, 28 Jul 2014 13:43:40 +0200
Jiri Prchal jiri.prc...@aksignal.cz wrote:
This fix problem with PA14 set as periph A left from ROMBOOT and need it
to be set to gpio before spi bus communicate with chip on CS0 on other
gpio. As I reported a week ago.
Request all csgpios in spi_probe since cs depends on each other and must
be all of them in right state before any communication on bus. They are
part of bus, like miso, mosi, clk, not part of chips, they are defined
in parent spi node, not in child chip node.
Csgpio moved to atmel_spi struct as part of master bus.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
drivers/spi/spi-atmel.c | 68
+
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 92a6f0d..1fb7bb9 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -22,11 +22,14 @@
#include linux/platform_data/atmel.h
#include linux/platform_data/dma-atmel.h
#include linux/of.h
+#include linux/of_gpio.h
#include linux/io.h
#include linux/gpio.h
#include linux/pinctrl/consumer.h
+#define DRIVER_NAME atmel-spi
+
/* SPI register offsets */
#define SPI_CR 0x
#define SPI_MR 0x0004
@@ -242,11 +245,13 @@ struct atmel_spi {
boolkeep_cs;
boolcs_active;
+
+ /* chip selects */
+ unsigned intcsgpio[];
Do you really need to store these gpio ids in atmel_spi struct (they
are already stored in the spi_master).
};
/* Controller-specific per-slave state */
struct atmel_spi_device {
- unsigned intnpcs_pin;
Keep this field to handle both DT and non-DT cases.
u32 csr;
};
@@ -312,7 +317,7 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
}
mr = spi_readl(as, MR);
- gpio_set_value(asd-npcs_pin, active);
+ gpio_set_value(as-csgpio[spi-chip_select], active);
Drop this change.
} else {
u32 cpol = (spi-mode SPI_CPOL) ? SPI_BIT(CPOL) : 0;
int i;
@@ -329,18 +334,16 @@ static void cs_activate(struct atmel_spi *as, struct
spi_device *spi)
mr = spi_readl(as, MR);
mr = SPI_BFINS(PCS, ~(1 spi-chip_select), mr);
if (spi-chip_select != 0)
- gpio_set_value(asd-npcs_pin, active);
+ gpio_set_value(as-csgpio[spi-chip_select], active);
Ditto.
spi_writel(as, MR, mr);
}
dev_dbg(spi-dev, activate %u%s, mr %08x\n,
- asd-npcs_pin, active ? (high) : ,
- mr);
+ as-csgpio[spi-chip_select], active ? (high) : , mr);
Ditto.
}
static void cs_deactivate(struct atmel_spi *as, struct spi_device *spi)
{
- struct atmel_spi_device *asd = spi-controller_state;
unsigned active = spi-mode SPI_CS_HIGH;
u32 mr;
@@ -354,11 +357,10 @@ static void cs_deactivate(struct atmel_spi *as, struct
spi_device *spi)
}
dev_dbg(spi-dev, DEactivate %u%s, mr %08x\n,
- asd-npcs_pin, active ? (low) : ,
- mr);
+ as-csgpio[spi-chip_select], active ? (low) : , mr);
if (atmel_spi_is_v2(as) || spi-chip_select != 0)
- gpio_set_value(asd-npcs_pin, !active);
+ gpio_set_value(as-csgpio[spi-chip_select], !active);
Ditto.
}
static void atmel_spi_lock(struct atmel_spi *as) __acquires(as-lock)
@@ -989,8 +991,6 @@ static int atmel_spi_setup(struct spi_device *spi)
struct atmel_spi_device *asd;
u32 csr;
unsigned intbits = spi-bits_per_word;
- unsigned intnpcs_pin;
- int ret;
as = spi_master_get_devdata(spi-master);
@@ -1017,27 +1017,13 @@ static int atmel_spi_setup(struct spi_device *spi)
csr |= SPI_BF(DLYBS, 0);
csr |= SPI_BF(DLYBCT, 0);
- /* chipselect must have been muxed as GPIO (e.g. in board setup) */
- npcs_pin = (unsigned int)spi-controller_data;
-
- if (gpio_is_valid(spi-cs_gpio))
- npcs_pin = spi-cs_gpio;
-
Keep this block and just add:
else {
ret = gpio_request(npcs_pin, dev_name(spi-dev));
if (ret) {
kfree(asd);
return ret;
}
gpio_direction_output(npcs_pin,
!(spi-mode SPI_CS_HIGH));
}
asd = spi-controller_state;
if (!asd) {
asd
Re: [PATCH] Enabling OF selftest to run without machine's devicetree
On Mon, Jul 28, 2014 at 8:00 AM, Rob Herring robherri...@gmail.com wrote:
On Sun, Jul 27, 2014 at 10:28 PM, Gaurav Minocha
gaurav.minocha...@gmail.com wrote:
On Sat, Jul 26, 2014 at 3:17 PM, Gaurav Minocha
gaurav.minocha...@gmail.com wrote:
On Sat, Jul 26, 2014 at 2:11 PM, Rob Herring robherri...@gmail.com wrote:
On Sat, Jul 26, 2014 at 2:48 PM, Gaurav Minocha
gaurav.minocha...@gmail.com wrote:
If there is no devicetree present, this patch adds the selftest
data as a live devicetree. It also removes the same after the
testcase execution is complete.
[...]
@@ -614,10 +616,31 @@ static int __init selftest_data_add(void)
not running tests\n, __func__);
return -ENOMEM;
}
- of_fdt_unflatten_tree(selftest_data, selftest_data_node);
Can't you keep this factored out and just do of_allnodes =
selftest_data_node;?
I tried to do that in first place, but of_alias_scan() called from
of_fdt_unflatten_tree(..)
needs of_allnodes. So, had to call it separately.
No, it is not or I'm missing some change. Or it is a bug? It is called
from unflatten_device_tree which is the early boot version.
So, there are two functions unflatten_device_tree and of_fdt_unflatten_tree.
In of_fdt_unflatten_tree, I added a call to of_alias_scan().
Yes, unflatten_device_tree is the early boot version it already
calls of_alias_scan().
I myself was in doubt to call of_alias_scan from of_fdt_unflatten_tree.
Though it works fine, may be I'm not aware of a testcase in
which it might fail. So, calling explicitly in another option as
mentioned earlier.
Actually, it's possible if rather than calling of_alias_scan from
of_fdt_unflatten_tree, I write a wrapper and export it as below.
So, I will be able to call of_fdt_alias_scan explicitly.
of_fdt_alias_scan()
{
of_alias_scan(kernel_tree_alloc);
}
EXPORT_SYMBOL(of_fdt_alias_scan)
I prefer to keep this internal to the DT code. Plus of_fdt_* functions
operate on a flat tree and of_alias_scan operates on unflattened tree.
OR
directly export of_alias_scan() and
kernel_tree_alloc(u64 size, u64 align)
please let me know if I should follow either of the above
approach in my next patch.
Perhaps as you had it is fine.
Rob
--
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 RFC v4 1/2] Devicetree: Add pl353 smc controller devicetree binding information
Add pl353 static memory controller devicetree binding information.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v4:
- none
Changes in v3:
- none
Changes in v2:
- modified timing binding info as per onfi timing parameters
- add suffix nano second as timing unit
- modified the clock names as per the IP spec
---
.../bindings/memory-controllers/pl353-smc.txt | 53
1 files changed, 53 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
new file mode 100644
index 000..c1f011d
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
@@ -0,0 +1,53 @@
+Device tree bindings for ARM PL353 static memory controller
+
+PL353 static memory controller supports two kinds of memory
+interfaces.i.e NAND and SRAM/NOR interfaces.
+The actual devices are instantiated from the child nodes of pl353 smc node.
+
+Required properties:
+- compatible : Should be arm,pl353-smc-r2p1
+- reg : Controller registers map and length.
+- clock-names : List of input clock names - memclk, aclk
+ (See clock bindings for details).
+- clocks : Clock phandles (see clock bindings for details).
+- address-cells: Address cells, must be 1.
+- size-cells : Size cells. Must be 1.
+
+Child nodes:
+ For NAND the arm,pl353-nand-r2p1 and for NOR the cfi-flash drivers are
+supported as child nodes.
+
+Mandatory timing properties for child nodes:
+- nand-tRC-ns : Read cycle time.
+- nand-tWC-ns : Write cycle time.
+- nand-tREA-ns : re_n assertion delay.
+- nand-tWP-ns : we_n de-assertion delay.
+- nand-tCLR-ns : Status read time
+- nand-tAR-ns : ID read time
+- nand-tRR-ns : busy to re_n
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ pl353smcc_0: pl353smcc@e000e000 {
+ compatible = arm,pl353-smcc-r2p1
+ clock-names = memclk, aclk;
+ clocks = clkc 11, clkc 44;
+ reg = 0xe000e000 0x1000;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ nand_0: nand@e100 {
+ compatible = arm,pl353-nand-r2p1
+ reg = 0xe100 0x100;
+ nand-tRC-ns = 40;
+ nand-tWC-ns = 40;
+ nand-tREA-ns = 10;
+ nand-tWP-ns = 20;
+ nand-tCLR-ns = 20;
+ nand-tAR-ns = 20;
+ nand-tRR-ns = 40;
+ (...)
+ };
+ };
--
1.7.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 RFC v4 2/2] memory: pl353: Add driver for arm pl353 static memory controller
Add driver for arm pl353 static memory controller. This controller is used in xilinx zynq soc for interfacing the nand and nor/sram memory devices. Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com --- Changes in v4: - Modified driver to support multiple instances - Used sleep instaed of busywait for delay Changes in v3: - None Changes in v2: - Since now the timing parameters are in nano seconds, added logic to convert them to the cycles --- drivers/memory/Kconfig |6 + drivers/memory/Makefile |1 + drivers/memory/pl353-smc.c | 590 ++ include/linux/memory/pl353-smc.h | 34 +++ 4 files changed, 631 insertions(+), 0 deletions(-) create mode 100644 drivers/memory/pl353-smc.c create mode 100644 include/linux/memory/pl353-smc.h diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index c59e9c9..58c29a2 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -65,4 +65,10 @@ config FSL_IFC bool depends on FSL_SOC +config PL353_SMC + bool ARM PL353 Static Memory Controller(SMC) driver + default y + depends on ARM + help + This driver is for the ARM PL353 Static Memory Controller(SMC) module. endif diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 71160a2..5040977 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -11,3 +11,4 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o +obj-$(CONFIG_PL353_SMC)+= pl353-smc.o diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c new file mode 100644 index 000..cb54b47 --- /dev/null +++ b/drivers/memory/pl353-smc.c @@ -0,0 +1,590 @@ +/* + * ARM PL353 SMC Driver + * + * Copyright (C) 2012 - 2014 Xilinx, Inc. + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License, or + * (at your option) any later version. + * + * 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. + * + * Currently only a single SMC instance is supported. + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/io.h +#include linux/kernel.h +#include linux/memory/pl353-smc.h +#include linux/module.h +#include linux/of_platform.h +#include linux/platform_device.h +#include linux/slab.h + +/* Register definitions */ +#define PL353_SMC_MEMC_STATUS_OFFS 0 /* Controller status reg, RO */ +#define PL353_SMC_CFG_CLR_OFFS 0xC /* Clear config reg, WO */ +#define PL353_SMC_DIRECT_CMD_OFFS 0x10/* Direct command reg, WO */ +#define PL353_SMC_SET_CYCLES_OFFS 0x14/* Set cycles register, WO */ +#define PL353_SMC_SET_OPMODE_OFFS 0x18/* Set opmode register, WO */ +#define PL353_SMC_ECC_STATUS_OFFS 0x400 /* ECC status register */ +#define PL353_SMC_ECC_MEMCFG_OFFS 0x404 /* ECC mem config reg */ +#define PL353_SMC_ECC_MEMCMD1_OFFS 0x408 /* ECC mem cmd1 reg */ +#define PL353_SMC_ECC_MEMCMD2_OFFS 0x40C /* ECC mem cmd2 reg */ +#define PL353_SMC_ECC_VALUE0_OFFS 0x418 /* ECC value 0 reg */ + +/* Controller status register specifc constants */ +#define PL353_SMC_MEMC_STATUS_RAW_INT_1_SHIFT 6 + +/* Clear configuration register specific constants */ +#define PL353_SMC_CFG_CLR_INT_CLR_10x10 +#define PL353_SMC_CFG_CLR_ECC_INT_DIS_10x40 +#define PL353_SMC_CFG_CLR_INT_DIS_10x2 +#define PL353_SMC_CFG_CLR_DEFAULT_MASK (PL353_SMC_CFG_CLR_INT_CLR_1 | \ +PL353_SMC_CFG_CLR_ECC_INT_DIS_1 | \ +PL353_SMC_CFG_CLR_INT_DIS_1) + +/* Set cycles register specific constants */ +#define PL353_SMC_SET_CYCLES_T0_MASK 0xF +#define PL353_SMC_SET_CYCLES_T0_SHIFT 0 +#define PL353_SMC_SET_CYCLES_T1_MASK 0xF +#define PL353_SMC_SET_CYCLES_T1_SHIFT 4 +#define PL353_SMC_SET_CYCLES_T2_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T2_SHIFT 8 +#define PL353_SMC_SET_CYCLES_T3_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T3_SHIFT 11 +#define PL353_SMC_SET_CYCLES_T4_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T4_SHIFT 14 +#define PL353_SMC_SET_CYCLES_T5_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T5_SHIFT 17 +#define PL353_SMC_SET_CYCLES_T6_MASK 0xF +#define PL353_SMC_SET_CYCLES_T6_SHIFT 20 + +/* ECC status register specific constants */ +#define PL353_SMC_ECC_STATUS_BUSY (1 6) + +/* ECC memory config register specific constants */ +#define PL353_SMC_ECC_MEMCFG_MODE_MASK 0xC +#define PL353_SMC_ECC_MEMCFG_MODE_SHIFT2 +#define PL353_SMC_ECC_MEMCFG_PGSIZE_MASK
[PATCH RFC v4 0/2] Add arm pl353 smc driver for xilinx zynq soc
The following patches add arm pl353 static memory controller driver for xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and nor/sram memory interfaces. The current implementation supports only a single SMC instance and nand specific configuration. xilinx zynq TRM link: http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf ARM pl353 smc TRM link: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ DDI0380G_smc_pl350_series_r2p1_trm.pdf Punnaiah Choudary Kalluri (2): Devicetree: Add pl353 smc controller devicetree binding information memory: pl353: Add driver for arm pl353 static memory controller .../bindings/memory-controllers/pl353-smc.txt | 53 ++ drivers/memory/Kconfig |6 + drivers/memory/Makefile|1 + drivers/memory/pl353-smc.c | 590 include/linux/memory/pl353-smc.h | 34 ++ 5 files changed, 684 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt create mode 100644 drivers/memory/pl353-smc.c create mode 100644 include/linux/memory/pl353-smc.h -- 1.7.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 RFC v4 4/4] Documentation: nand: pl353: Add documentation for controller and driver
Added notes about the controller and driver Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com --- Changes in v4: - None --- Documentation/mtd/nand/pl353-nand.txt | 92 + 1 files changed, 92 insertions(+), 0 deletions(-) create mode 100644 Documentation/mtd/nand/pl353-nand.txt diff --git a/Documentation/mtd/nand/pl353-nand.txt b/Documentation/mtd/nand/pl353-nand.txt new file mode 100644 index 000..4deac94 --- /dev/null +++ b/Documentation/mtd/nand/pl353-nand.txt @@ -0,0 +1,92 @@ +This documents provides some notes about the ARM pl353 smc controller used in +Zynq SOC and confined to NAND specific details. + +Overview of the controller +== + The SMC (PL353) supports two memory interfaces: + Interface 0 type SRAM. + Interface 1 type NAND. + This configuration supports the following configurable options: + . 32-bit or 64-bit AXI data width + . 8-bit, 16-bit, or 32-bit memory data width for interface 0 + . 8-bit, or 16-bit memory data width for interface 1 + . 1-4 chip selects on each interface + . SLC ECC block for interface 1 + +For more information, refer the below link for TRM +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ +DDI0380G_smc_pl350_series_r2p1_trm.pdf + +NAND memory accesses + + . Two phase NAND accesses + . NAND command phase transfers + . NAND data phase transfers + +Two phase NAND accesses + The SMC defines two phases of commands when transferring data to or from +NAND flash. + +Command phase + Commands and optional address information are written to the NAND flash. +The command and address can be associated with either a data phase operation to +write to or read from the array, or a status/ID register transfer. + +Data phase + Data is either written to or read from the NAND flash. This data can be either +data transferred to or from the array, or status/ID register information. + +NAND AXI address setup + AXI address Command phase Data phase + [31:24] Chip address Chip address + [23]NoOfAddCycles_2Reserved + [22]NoOfAddCycles_1Reserved + [21]NoOfAddCycles_0ClearCS + [20]End command valid End command valid + [19]0 1 + [18:11] End commandEnd command + [10:3] Start command [10] ECC Last + [9:3] Reserved + [2:0] Reserved Reserved + +ECC +=== +It operates on a number of 512 byte blocks of NAND memory and can be +programmed to store the ECC codes after the data in memory. For writes, +the ECC is written to the spare area of the page. For reads, the result of +a block ECC check are made available to the device driver. + + +| n * 512 blocks | extra | ecc| | +| | block | codes | | + + +The ECC calculation uses a simple Hamming code, using 1-bit correction 2-bit +detection. It starts when a valid read or write command with a 512 byte aligned +address is detected on the memory interface. + +Driver details +== + The NAND driver has dependancy with the pl353_smc memory controller +driver for intializing the nand timing parameters, bus width, ECC modes, +control and status information. + +Since the controller expects that the chipselect bit should be cleared for the +last data transfer i.e last 4 data bytes, the existing nandbase page +read/write routines for soft ecc and ecc none modes will not work. So, inorder +to make this driver work, it always updates the ecc mode as HW ECC and +implemented the page read/write functions for supporting the SW ECC. + +HW ECC mode: + Upto 2K page size is supported and beyond that it retuns +-ENOSUPPORT error. If the flsh has ONDIE ecc controller then the +priority has given to the ONDIE ecc controller. Also the current +implementation has support for upto 64 byte oob area + +SW ECC mode: + It supports all the pgae sizes. But since, zynq soc bootrom uses +HW ECC for the devices that have pgae size =2K so, to avoid any ecc related +issues during boot, prefer HW ECC over SW ECC. + +For devicetree binding information please refer the below dt binding file +Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt -- 1.7.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 RFC v4 3/4] nand: pl353: Add ONDIE ECC support
Added ONDIE ECC support. Currently this ecc mode is supported for
specific micron parts with oob size 64 bytes.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v4:
- Updated the driver to sync with pl353_smc driver APIs
---
drivers/mtd/nand/pl353_nand.c | 162 -
1 files changed, 144 insertions(+), 18 deletions(-)
diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
index 93dc4ca..5c9b60d 100644
--- a/drivers/mtd/nand/pl353_nand.c
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -140,6 +140,48 @@ static struct nand_ecclayout nand_oob_64 = {
.length = 50} }
};
+static struct nand_ecclayout ondie_nand_oob_64 = {
+ .eccbytes = 32,
+
+ .eccpos = {
+ 8, 9, 10, 11, 12, 13, 14, 15,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 56, 57, 58, 59, 60, 61, 62, 63
+ },
+
+ .oobfree = {
+ { .offset = 4, .length = 4 },
+ { .offset = 20, .length = 4 },
+ { .offset = 36, .length = 4 },
+ { .offset = 52, .length = 4 }
+ }
+};
+
+/* Generic flash bbt decriptors */
+static uint8_t bbt_pattern[] = { 'B', 'b', 't', '0' };
+static uint8_t mirror_pattern[] = { '1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+ | NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+ .offs = 4,
+ .len = 4,
+ .veroffs = 20,
+ .maxblocks = 4,
+ .pattern = bbt_pattern
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
+ | NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+ .offs = 4,
+ .len = 4,
+ .veroffs = 20,
+ .maxblocks = 4,
+ .pattern = mirror_pattern
+};
+
/**
* pl353_nand_calculate_hwecc - Calculate Hardware ECC
* @mtd: Pointer to the mtd_info structure
@@ -816,15 +858,74 @@ static int pl353_nand_device_ready(struct mtd_info *mtd)
}
/**
+ * pl353_nand_detect_ondie_ecc - Get the flash ondie ecc state
+ * @mtd: Pointer to the mtd_info structure
+ *
+ * This function enables the ondie ecc for the Micron ondie ecc capable devices
+ *
+ * Return: 1 on detect, 0 if fail to detect
+ */
+static int pl353_nand_detect_ondie_ecc(struct mtd_info *mtd)
+{
+ struct nand_chip *nand_chip = mtd-priv;
+ u8 maf_id, dev_id, i, get_feature;
+ u8 set_feature[4] = { 0x08, 0x00, 0x00, 0x00 };
+
+ /* Check if On-Die ECC flash */
+ nand_chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+ nand_chip-cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);
+
+ /* Read manufacturer and device IDs */
+ maf_id = readb(nand_chip-IO_ADDR_R);
+ dev_id = readb(nand_chip-IO_ADDR_R);
+
+ if ((maf_id == NAND_MFR_MICRON)
+ ((dev_id == 0xf1) || (dev_id == 0xa1) ||
+(dev_id == 0xb1) || (dev_id == 0xaa) ||
+(dev_id == 0xba) || (dev_id == 0xda) ||
+(dev_id == 0xca) || (dev_id == 0xac) ||
+(dev_id == 0xbc) || (dev_id == 0xdc) ||
+(dev_id == 0xcc) || (dev_id == 0xa3) ||
+(dev_id == 0xb3) ||
+(dev_id == 0xd3) || (dev_id == 0xc3))) {
+
+ nand_chip-cmdfunc(mtd, NAND_CMD_GET_FEATURES,
+ ONDIE_ECC_FEATURE_ADDR, -1);
+ get_feature = readb(nand_chip-IO_ADDR_R);
+
+ if (get_feature 0x08) {
+ return 1;
+ } else {
+ nand_chip-cmdfunc(mtd, NAND_CMD_SET_FEATURES,
+ ONDIE_ECC_FEATURE_ADDR, -1);
+ for (i = 0; i 4; i++)
+ writeb(set_feature[i], nand_chip-IO_ADDR_W);
+
+ ndelay(1000);
+
+ nand_chip-cmdfunc(mtd, NAND_CMD_GET_FEATURES,
+ ONDIE_ECC_FEATURE_ADDR, -1);
+ get_feature = readb(nand_chip-IO_ADDR_R);
+
+ if (get_feature 0x08)
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
+/**
* pl353_nand_ecc_init - Initialize the ecc information as per the ecc mode
* @mtd: Pointer to the mtd_info structure
+ * @ondie_ecc_state: ondie ecc status
*
* This function initializes the ecc block and functional pointers as per the
* ecc mode
*
* Return: Zero on success and error on failure.
*/
-static int pl353_nand_ecc_init(struct mtd_info *mtd)
+static int pl353_nand_ecc_init(struct mtd_info *mtd, int ondie_ecc_state)
{
struct nand_chip *nand_chip = mtd-priv;
struct pl353_nand_info *xnand =
@@ -838,27 +939,50 @@ static int pl353_nand_ecc_init(struct mtd_info *mtd)
switch (xnand-ecc_mode)
[PATCH RFC v4 2/4] nand: pl353: Add software ecc support
Added software ecc support.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v4:
- Updated the driver to sync with pl353_smc driver APIs
---
drivers/mtd/nand/pl353_nand.c | 164 +
1 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
index f97f428..93dc4ca 100644
--- a/drivers/mtd/nand/pl353_nand.c
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -319,6 +319,71 @@ static int pl353_nand_write_oob(struct mtd_info *mtd,
struct nand_chip *chip,
}
/**
+ * pl353_nand_read_page_raw - [Intern] read raw page data without ecc
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the data buffer
+ * @oob_required: Caller requires OOB data read to chip-oob_poi
+ * @page: Page number to read
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_read_page_raw(struct mtd_info *mtd,
+ struct nand_chip *chip,
+ uint8_t *buf, int oob_required, int page)
+{
+ unsigned long data_phase_addr;
+ uint8_t *p;
+
+ chip-read_buf(mtd, buf, mtd-writesize);
+
+ p = chip-oob_poi;
+ chip-read_buf(mtd, p,
+ (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH));
+ p += (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH);
+
+ data_phase_addr = (unsigned long __force)chip-IO_ADDR_R;
+ data_phase_addr |= PL353_NAND_CLEAR_CS;
+ chip-IO_ADDR_R = (void __iomem * __force)data_phase_addr;
+
+ chip-read_buf(mtd, p, PL353_NAND_LAST_TRANSFER_LENGTH);
+ return 0;
+}
+
+/**
+ * pl353_nand_write_page_raw - [Intern] raw page write function
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the data buffer
+ * @oob_required: Caller requires OOB data read to chip-oob_poi
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_write_page_raw(struct mtd_info *mtd,
+ struct nand_chip *chip,
+ const uint8_t *buf, int oob_required)
+{
+ unsigned long data_phase_addr;
+ uint8_t *p;
+
+ chip-write_buf(mtd, buf, mtd-writesize);
+
+ p = chip-oob_poi;
+ chip-write_buf(mtd, p,
+ (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH));
+ p += (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH);
+
+ data_phase_addr = (unsigned long __force)chip-IO_ADDR_W;
+ data_phase_addr |= PL353_NAND_CLEAR_CS;
+ data_phase_addr |= (1 END_CMD_VALID_SHIFT);
+ chip-IO_ADDR_W = (void __iomem * __force)data_phase_addr;
+
+ chip-write_buf(mtd, p, PL353_NAND_LAST_TRANSFER_LENGTH);
+
+ return 0;
+}
+
+/**
* nand_write_page_hwecc - Hardware ECC based page write function
* @mtd: Pointer to the mtd info structure
* @chip: Pointer to the NAND chip info structure
@@ -384,6 +449,39 @@ static int pl353_nand_write_page_hwecc(struct mtd_info
*mtd,
}
/**
+ * pl353_nand_write_page_swecc - [REPLACABLE] software ecc based page write
+ * function
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the data buffer
+ * @oob_required: Caller requires OOB data read to chip-oob_poi
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_write_page_swecc(struct mtd_info *mtd,
+ struct nand_chip *chip, const uint8_t *buf,
+ int oob_required)
+{
+ int i, eccsize = chip-ecc.size;
+ int eccbytes = chip-ecc.bytes;
+ int eccsteps = chip-ecc.steps;
+ uint8_t *ecc_calc = chip-buffers-ecccalc;
+ const uint8_t *p = buf;
+ uint32_t *eccpos = chip-ecc.layout-eccpos;
+
+ /* Software ecc calculation */
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
+ chip-ecc.calculate(mtd, p, ecc_calc[i]);
+
+ for (i = 0; i chip-ecc.total; i++)
+ chip-oob_poi[eccpos[i]] = ecc_calc[i];
+
+ chip-ecc.write_page_raw(mtd, chip, buf, 1);
+
+ return 0;
+}
+
+/**
* pl353_nand_read_page_hwecc - Hardware ECC based page read function
* @mtd: Pointer to the mtd info structure
* @chip: Pointer to the NAND chip info structure
@@ -465,6 +563,52 @@ static int pl353_nand_read_page_hwecc(struct mtd_info *mtd,
}
/**
+ * pl353_nand_read_page_swecc - [REPLACABLE] software ecc based page read
+ * function
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the buffer to store read data
+ * @oob_required: Caller
[PATCH RFC v4 1/4] nand: pl353: Add basic driver for arm pl353 smc nand interface
Add driver for arm pl353 static memory controller nand interface with
HW ECC support. This controller is used in xilinx zynq soc for interfacing
the nand flash memory.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v4:
- Updated the driver to sync with pl353_smc driver APIs
Changes in v3:
- implemented the proper error codes
- further breakdown this patch to multiple sets
- added the controller and driver details to Documentation section
- updated the licenece to GPLv2
- reorganized the pl353_nand_ecc_init function
Changes in v2:
- use depends on rather than select option in kconfig
- remove unused variable parts
- remove dummy helper and use writel_relaxed directly
---
drivers/mtd/nand/Kconfig |7 +
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/pl353_nand.c | 857 +
3 files changed, 865 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/pl353_nand.c
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index f1cf503..a3462e6 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -492,6 +492,13 @@ config MTD_NAND_NUC900
This enables the driver for the NAND Flash on evaluation board based
on w90p910 / NUC9xx.
+config MTD_NAND_PL353
+ tristate ARM Pl353 NAND flash driver
+ depends on MTD_NAND ARM
+ depends on PL353_SMC
+ help
+ This enables access to the NAND flash device on PL353 SMC controller.
+
config MTD_NAND_JZ4740
tristate Support for JZ4740 SoC NAND controller
depends on MACH_JZ4740
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 542b568..a4c2679 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_PL353) += pl353_nand.o
nand-objs := nand_base.o nand_bbt.o
diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
new file mode 100644
index 000..f97f428
--- /dev/null
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -0,0 +1,857 @@
+/*
+ * ARM PL353 NAND Flash Controller Driver
+ *
+ * Copyright (C) 2009 - 2014 Xilinx, Inc.
+ *
+ * This driver is based on plat_nand.c and mxc_nand.c drivers
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/err.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/irq.h
+#include linux/memory/pl353-smc.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/nand_ecc.h
+#include linux/mtd/partitions.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_mtd.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#define PL353_NAND_DRIVER_NAME pl353-nand
+
+/* NAND flash driver defines */
+#define PL353_NAND_CMD_PHASE 1 /* End command valid in command phase */
+#define PL353_NAND_DATA_PHASE 2 /* End command valid in data phase */
+#define PL353_NAND_ECC_SIZE512 /* Size of data for ECC operation */
+
+/* Flash memory controller operating parameters */
+
+#define PL353_NAND_ECC_CONFIG (BIT(4) | /* ECC read at end of page */ \
+(0 5)) /* No Jumping */
+
+/* AXI Address definitions */
+#define START_CMD_SHIFT3
+#define END_CMD_SHIFT 11
+#define END_CMD_VALID_SHIFT20
+#define ADDR_CYCLES_SHIFT 21
+#define CLEAR_CS_SHIFT 21
+#define ECC_LAST_SHIFT 10
+#define COMMAND_PHASE (0 19)
+#define DATA_PHASE BIT(19)
+
+#define PL353_NAND_ECC_LASTBIT(ECC_LAST_SHIFT) /* Set ECC_Last */
+#define PL353_NAND_CLEAR_CSBIT(CLEAR_CS_SHIFT) /* Clear chip select */
+
+#define ONDIE_ECC_FEATURE_ADDR 0x90
+#define PL353_NAND_ECC_BUSY_TIMEOUT(1 * HZ)
+#define PL353_NAND_DEV_BUSY_TIMEOUT(1 * HZ)
+#define PL353_NAND_LAST_TRANSFER_LENGTH4
+
+/**
+ * struct pl353_nand_command_format - Defines NAND flash command format
+ * @start_cmd: First cycle command (Start command)
+ * @end_cmd: Second cycle command (Last command)
+ * @addr_cycles: Number of address cycles required to send the address
+ * @end_cmd_valid: The second cycle command is valid for cmd or data phase
+ */
+struct pl353_nand_command_format {
+ int start_cmd;
+ int end_cmd;
+ u8 addr_cycles;
+ u8 end_cmd_valid;
+};
+
+/**
+ * struct pl353_nand_info - Defines
Re: [PATCH v2 09/11] Documentation: devicetree: Fix ADI AXI SPDIF specification
Am 28.07.2014 15:44, schrieb Mark Brown: On Mon, Jul 28, 2014 at 02:28:12PM +0200, Andreas Färber wrote: I will *re*-submit it for your convenience. Which is what I originally requested when I got CCed into the thread - I'm being grumpy because instead of getting the patch sent to me as requested I got sent a link to patchwork. Hindsight, had you simply replied with Yes, please. instead of the non-telling Documentation/SubmittingPatches., you would've spared yourself keystrokes and us four mailing list messages. ;) Similarly, your statement about false negatives didn't really help in resolving the not-CC'ed problem. I now know to CC you if I ever have something for adi,axi-spdif-tx.txt again, but the next person might make you grumpy again and potentially demotivates new contributors, so certainly worth fixing. Regmap, SPI, regulators, touchscreen MAINTAINERS entries seem unrelated. Should your SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC) MAINTAINERS entry get an F: Documentation/devicetree/bindings/sound/ or is the ANALOG DEVICES Inc ASOC DRIVERS entry missing a line F: sound/soc/adi/ F: Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt (which would then still not CC you) or is a new MAINTAINERS section needed that CCs specifically Lars-Peter and you on the latter? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg signature.asc Description: OpenPGP digital signature
[PATCH RFC v4 0/4] Add arm pl353 smc nand driver for xilinx zynq soc
The following patches add arm pl353 static memory controller driver for xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and nor/sram memory interfaces. The current implementation supports only a single SMC instance and nand specific configuration. xilinx zynq TRM link: http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf ARM pl353 smc TRM link: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ DDI0380G_smc_pl350_series_r2p1_trm.pdf Punnaiah Choudary Kalluri (4): nand: pl353: Add basic driver for arm pl353 smc nand interface nand: pl353: Add software ecc support nand: pl353: Add ONDIE ECC support Documentation: nand: pl353: Add documentation for controller and driver Documentation/mtd/nand/pl353-nand.txt | 92 +++ drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/pl353_nand.c | 1147 + 4 files changed, 1247 insertions(+), 0 deletions(-) create mode 100644 Documentation/mtd/nand/pl353-nand.txt create mode 100644 drivers/mtd/nand/pl353_nand.c -- 1.7.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 v3 1/2] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver
Hello Vinod,
Thanks for your review,
On Fri, Jul 25, 2014 at 12:46:31PM +0530, Vinod Koul wrote:
On Tue, Jul 08, 2014 at 03:11:35PM +0200, Ludovic Desroches wrote:
New atmel DMA controller known as XDMAC, introduced with SAMA5D4
devices.
Didnt check, but how much is delta b/w X/H Dmacs?
If you are wondering if we can have only one driver for both DMA
controller, I don't think so. At the moment you won't find documentation
about this controller since the device is not yet released.
The content of the register has changed, the way irq is managed has
changed too.
+/* Call with lock hold. */
+static void at_xdmac_start_xfer(struct at_xdmac_chan *atchan,
+ struct at_xdmac_desc *first)
+{
+ struct at_xdmac *atxdmac = to_at_xdmac(atchan-chan.device);
+ u32 reg;
+
+ dev_vdbg(chan2dev(atchan-chan), %s: desc 0x%p\n, __func__, first);
+
+ if (at_xdmac_chan_is_enabled(atchan)) {
+ dev_err(chan2dev(atchan-chan),
+ BUG: Attempted to start a non-idle channel\n);
This shouldnt be BUG though. Your tasklet is always supposed to start and if
nothing to silent just return!
Ok, I'll remove this error message.
+
+static dma_cookie_t at_xdmac_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+ struct at_xdmac_desc*desc = txd_to_at_desc(tx);
+ struct at_xdmac_chan*atchan = to_at_xdmac_chan(tx-chan);
+ dma_cookie_tcookie;
+ unsigned long flags;
+
+ spin_lock_irqsave(atchan-lock, flags);
+ cookie = dma_cookie_assign(tx);
+
+ dev_vdbg(chan2dev(tx-chan), %s: atchan 0x%p, add desc 0x%p to
xfers_list\n,
+__func__, atchan, desc);
+ list_add_tail(desc-xfer_node, atchan-xfers_list);
+ if (list_is_singular(atchan-xfers_list))
+ at_xdmac_start_xfer(atchan, desc);
so you dont start if list has more than 1 descriptors, why?
Because I will let at_xdmac_advance_work managing the queue if not
empty. So the only moment when I have to start the transfer in tx_submit
is when I have only one transfer in the queue.
+
+ spin_unlock_irqrestore(atchan-lock, flags);
+ return cookie;
+}
+
+static struct at_xdmac_desc *at_xdmac_alloc_desc(struct dma_chan *chan,
+gfp_t gfp_flags)
why do we need last argument?
No specific reason, I can remove it and use GFP_NOWAIT directly.
+{
+ struct at_xdmac_desc*desc;
+ struct at_xdmac *atxdmac = to_at_xdmac(chan-device);
+ dma_addr_t phys;
+
+ desc = dma_pool_alloc(atxdmac-at_xdmac_desc_pool, gfp_flags, phys);
+ if (desc) {
+ memset(desc, 0, sizeof(*desc));
+ INIT_LIST_HEAD(desc-descs_list);
+ dma_async_tx_descriptor_init(desc-tx_dma_desc, chan);
+ desc-tx_dma_desc.tx_submit = at_xdmac_tx_submit;
+ desc-tx_dma_desc.phys = phys;
+ }
+
+ return desc;
+}
+
+/* Call must be protected by lock. */
+static struct at_xdmac_desc *at_xdmac_get_desc(struct at_xdmac_chan
*atchan)
+{
+ struct at_xdmac_desc *desc;
+
+ if (list_empty(atchan-free_descs_list)) {
+ desc = at_xdmac_alloc_desc(atchan-chan, GFP_ATOMIC);
GFP_NOWAIT pls
Ok
+static struct dma_async_tx_descriptor *
+at_xdmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
dma_addr_t src,
+size_t len, unsigned long flags)
+{
+ struct at_xdmac_chan*atchan = to_at_xdmac_chan(chan);
+ struct at_xdmac_desc*first = NULL, *prev = NULL;
+ size_t remaining_size = len, xfer_size = 0, ublen;
+ dma_addr_t src_addr = src, dst_addr = dest;
+ u32 dwidth;
+ /*
+* WARNING: The channel configuration is set here since there is no
+* dmaengine_slave_config call in this case. Moreover we don't know the
+* direction, it involves we can't dynamically set the source and dest
+* interface so we have to use the same one. Only interface 0 allows EBI
+* access. Hopefully we can access DDR through both ports (at least on
+* SAMA5D4x), so we can use the same interface for source and dest,
+* that solves the fact we don't know the direction.
and why do you need slave config for memcpy?
Maybe the comments is not clear. With slave config we have the direction
per to mem or mem to per. Of course when doing memcpy we don't need this
information. But I use this information not only to set the transfer
direction but also to set the interfaces to use for the source and dest
(these interfaces depend on the connection on the matrix).
So slave config was useful due to direction field to tell which interface
to use as source and which one as dest.
I am lucky because NAND and DDR are on the same interfaces so it's not a
problem.
This comment is more a warning for myself to keep in mind this possible
issue
Re: [PATCH v3] ARM: zynq: DT: Add CAN node
On Mon, 2014-07-28 at 11:17AM +0200, Michal Simek wrote: Add node describing Zynq's CAN controller. Signed-off-by: Michal Simek michal.si...@xilinx.com Reviewed-by: Soren Brinkmann soren.brinkm...@xilinx.com Sören -- 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 00/11] ARM: dts: zynq: Prepare Parallella
Hi Lars-Peter,
Am 25.07.2014 01:00, schrieb Andreas Färber:
most notably I'm missing
ADI ADV7513 and AXI-HDMI support
[...]
Cc: Lars-Peter Clausen l...@metafoo.de (HDMI)
Could you please enlighten us what the status of upstreaming
ADV7511/ADV7513 support is? It is declared work in progress here:
http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511
I see some adv7511 V4L bits in drivers/media/i2c/adv7511.c, but no
drivers/gpu/drm/i2c/adv7511_{core,audio}.c as on the xcomm_zynq branch,
nor any devicetree documentation. Patchwork doesn't show any recent
submissions to LKML.
Is any major rework needed for you to get the 3.14.12 based driver upstream?
AXI SPDIF I found in 3.16, as you noticed; what about AXI HDMI? [*]
Is there any work ongoing to get that upstream as well?
Any pointers appreciated.
Thanks,
Andreas
[*]
http://wiki.analog.com/resources/tools-software/linux-drivers/platforms/zynq
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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
[LINUX PATCH] ARM: zynq: DT: Remove DMA from board DTs
The DMA engine is enabled for all DTs that derive from zynq-7000.dtsi.
There is no need to override the 'status' property in board DTs.
Cc: Andreas Färber afaer...@suse.de
Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
---
When the 'status' property was removed from the DMA node, this had been
overlooked.
Sören
arch/arm/boot/dts/zynq-parallella.dts | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index 1595138ec499..41afd9da6876 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -34,10 +34,6 @@
};
};
-dmac_s {
- status = okay;
-};
-
gem0 {
status = okay;
phy-mode = rgmii-id;
--
2.0.1.1.gfbfc394
--
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 PATCH] ARM: zynq: DT: Remove DMA from board DTs
Am 28.07.2014 18:24, schrieb Soren Brinkmann: The DMA engine is enabled for all DTs that derive from zynq-7000.dtsi. There is no need to override the 'status' property in board DTs. Cc: Andreas Färber afaer...@suse.de Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com --- When the 'status' property was removed from the DMA node, this had been overlooked. Indeed, Reviewed-by: Andreas Färber afaer...@suse.de Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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 00/11] ARM: dts: zynq: Prepare Parallella
On 07/28/2014 06:17 PM, Andreas Färber wrote:
Hi Lars-Peter,
Am 25.07.2014 01:00, schrieb Andreas Färber:
most notably I'm missing
ADI ADV7513 and AXI-HDMI support
[...]
Cc: Lars-Peter Clausen l...@metafoo.de (HDMI)
Could you please enlighten us what the status of upstreaming
ADV7511/ADV7513 support is? It is declared work in progress here:
http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511
I see some adv7511 V4L bits in drivers/media/i2c/adv7511.c, but no
drivers/gpu/drm/i2c/adv7511_{core,audio}.c as on the xcomm_zynq branch,
nor any devicetree documentation. Patchwork doesn't show any recent
submissions to LKML.
Is any major rework needed for you to get the 3.14.12 based driver upstream?
It's complicated. The plan for the driver was to wait for the common display
framework (CDF) and convert it to use CDF and then submit it upstream. The
CDF has been rejected though. Meanwhile the V4L2 adv7511 driver has been
merged. So now we are in the ugly situation that we have two different
drivers for two different frameworks. To fix this we need to merge these two
drivers while still exposing the interfaces to both frameworks.
AXI SPDIF I found in 3.16, as you noticed; what about AXI HDMI? [*]
Is there any work ongoing to get that upstream as well?
We need to teach the DMAengine framework about cyclic interleaved transfers
before the AXI HDMI driver can be submitted upstream.
- Lars
--
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] pwm: add this patch to support the new pwm of Rockchip SoCs
On Mon, Jul 28, 2014 at 4:19 AM, caesar caesar.w...@rock-chips.com wrote:
Doug,
在 2014年07月28日 12:01, Doug Anderson 写道:
Caesar,
On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com
wrote:
/*I think will be show the faill log:-
* rockchip-pwm ff9301a0.pwm: can't request region for resource [mem
0xff9301a0-0xff93019f]
*/
pc-base = devm_ioremap_resource(dev, regs);
Did you actually code this up and try it and get this error?
Yeah.
I hadn't
tried it but I researched other dts files and it looked as if there
was one example that was doing this. ...but perhaps it wasn't
actually doing the ioremap_resource on both ranges.
I'd imagine that this is _probably_ equivalent to what Thierry was
suggesting, so if it didn't work then maybe Thierry's won't work
either?
I don't have any other great suggestions other than doing two memory
ranges for lcdc:
lcdc@ff93 {
compatible = rockchip,rk3288-lcdc;
reg = 0xff93 0x1a0, 0xff9301b0 0xfe50;
...
};
pwm@ff9301a0 {
compatible = rockchip,vop-pwm;
reg = 0xff9301a0 0x10;
...
};
...but I am certainly nowhere near an expert on this stuff...
-Doug
I has solve in lcdc driver,but I always feel awkward. I think a good way to
solve in pwm driver.
Unfortunately that so far ,I have not a good idle in pwm driver.
Maybe,I let do it that way in lcdc driver.
I think there's an easier way to do this, by not focusing _too_ much
on the device tree:
* Define a platform_data structure for the PWM driver, which contains
readl/writel accessors as well as the device type (i.e. what you use
the compatible field and the lookup table for today).
* Populate the platform_device in the clcd driver, and register that
* Make the PWM driver probe as a regular platform device if pdata is passed
* Make a readl/writel wrapper that either falls back to native
readl/writel when there aren't any passed in, or make the DT code fill
in the pdata with the native versions in that case.
Going full MFD on this seems overkill, unless there is also a shared
interrupt that needs to be handled.
-Olof
--
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
[v2] input: drv260x: Add TI drv260x haptics driver
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy dmur...@ti.com
---
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 44 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 537
include/dt-bindings/input/ti-drv260x.h | 30 ++
include/linux/input/drv260x.h | 181 +++
6 files changed, 802 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/input/drv260x.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..930429b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,44 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ ti,drv2604 - DRV2604
+ ti,drv2605 - DRV2605
+ ti,drv2605l - DRV2605L
+ - reg - I2C slave address
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_RTP_MODE - Real time playback mode
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
+ - library_sel - Library to use at power up (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator. If this is not
+ set then the value will be
defaulted to 0x90 in the
+ driver.
+ - vib_overdrive_voltage - The overdrive voltage of the actuator.
+ If this is not set then
the value
+ will be defaulted to
0x90 in the driver.
+Example:
+
+drv2605l: drv2605l@5a {
+ compatible = ti,drv2605l;
+ reg = 0x5a;
+ enable-gpio = gpio1 28 GPIO_ACTIVE_HIGH;
+ mode = DRV260X_RTP_MODE;
+ library_sel = DRV260X_LIB_SEL_DEFAULT;
+ vib_rated_voltage = 3200;
+ vib_overdriver_voltage = 3200;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/drv2605
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2ff4425..99f6762 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -676,4 +676,13 @@ config INPUT_SOC_BUTTON_ARRAY
To compile this driver as a module, choose M here: the
module will be called soc_button_array.
+config INPUT_DRV260X_HAPTICS
+ tristate TI DRV260X haptics support
+ depends on INPUT I2C
+ help
+ Say Y to enable support for the TI DRV260X haptics driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called drv260x-haptics.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 4955ad3..d8ef3c7 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
+obj-$(CONFIG_INPUT_DRV260X_HAPTICS)+= drv260x.o
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
new file mode 100644
index 000..aadfd57
--- /dev/null
+++ b/drivers/input/misc/drv260x.c
@@ -0,0 +1,537 @@
+/*
+ * drv260x.c - DRV260X haptics driver family
+ *
+ * Author: Dan Murphy dmur...@ti.com
+ *
+ * Copyright: (C)
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Grant.
On 07/28/2014 05:05 PM, Grant Likely wrote:
On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko
grygorii.stras...@ti.com wrote:
Use clkops-clocks property to specify clocks handled by
clock_ops domain PM domain. Only clocks defined in clkops-clocks
set of clocks will be handled by Runtime PM through clock_ops
Pm domain.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/of/of_clk.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
index 35f5e9f..5f9b90e 100644
--- a/drivers/of/of_clk.c
+++ b/drivers/of/of_clk.c
@@ -86,11 +86,8 @@ int of_clk_register_runtime_pm_clocks(struct device_node
*np,
struct clk *clk;
int error;
-for (i = 0; (clk = of_clk_get(np, i)) !IS_ERR(clk); i++) {
-if (!clk_may_runtime_pm(clk)) {
-clk_put(clk);
-continue;
-}
+for (i = 0; (clk = of_clk_get_from_set(np, clkops, i))
+ !IS_ERR(clk); i++) {
This really looks like an ABI break to me. What happens to all the
existing platforms who don't have this new clkops-clocks in their device
tree?
Agree. This patch as is will break such platforms.
As possible solution for above problem - the NULL can be used as clock's prefix
by default and platform code can configure new value of clock's prefix during
initialization.
In addition, to make this solution full the of_clk_get_by_name() will
need to be modified too.
But note pls, this is pure RFC patches which I did to find out the answer on
questions:
- What is better: maintain Runtime PM clocks configuration in DT or in code?
- Where and when to call of_clk_register_runtime_pm_clocks()?
Bus notifier/ platform core/ device drivers
Also, May be platform dependent solution [1] can be acceptable for now?
[1] https://lkml.org/lkml/2014/7/25/630
Best regards,
-grygorii
--
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] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver
On Mon, Jul 28, 2014 at 05:54:31PM +0200, Ludovic Desroches wrote:
+{
+ struct at_xdmac_desc*desc = txd_to_at_desc(tx);
+ struct at_xdmac_chan*atchan = to_at_xdmac_chan(tx-chan);
+ dma_cookie_tcookie;
+ unsigned long flags;
+
+ spin_lock_irqsave(atchan-lock, flags);
+ cookie = dma_cookie_assign(tx);
+
+ dev_vdbg(chan2dev(tx-chan), %s: atchan 0x%p, add desc 0x%p to
xfers_list\n,
+ __func__, atchan, desc);
+ list_add_tail(desc-xfer_node, atchan-xfers_list);
+ if (list_is_singular(atchan-xfers_list))
+ at_xdmac_start_xfer(atchan, desc);
so you dont start if list has more than 1 descriptors, why?
Because I will let at_xdmac_advance_work managing the queue if not
empty. So the only moment when I have to start the transfer in tx_submit
is when I have only one transfer in the queue.
So xfers_list is current active descriptors right and if it is always going
to be singular why bother with a list?
+static struct dma_async_tx_descriptor *
+at_xdmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
dma_addr_t src,
+ size_t len, unsigned long flags)
+{
+ struct at_xdmac_chan*atchan = to_at_xdmac_chan(chan);
+ struct at_xdmac_desc*first = NULL, *prev = NULL;
+ size_t remaining_size = len, xfer_size = 0, ublen;
+ dma_addr_t src_addr = src, dst_addr = dest;
+ u32 dwidth;
+ /*
+ * WARNING: The channel configuration is set here since there is no
+ * dmaengine_slave_config call in this case. Moreover we don't know the
+ * direction, it involves we can't dynamically set the source and dest
+ * interface so we have to use the same one. Only interface 0 allows EBI
+ * access. Hopefully we can access DDR through both ports (at least on
+ * SAMA5D4x), so we can use the same interface for source and dest,
+ * that solves the fact we don't know the direction.
and why do you need slave config for memcpy?
Maybe the comments is not clear. With slave config we have the direction
per to mem or mem to per. Of course when doing memcpy we don't need this
information. But I use this information not only to set the transfer
direction but also to set the interfaces to use for the source and dest
(these interfaces depend on the connection on the matrix).
So slave config was useful due to direction field to tell which interface
to use as source and which one as dest.
I am lucky because NAND and DDR are on the same interfaces so it's not a
problem.
This comment is more a warning for myself to keep in mind this possible
issue in order to not have a device with NAND and DDR on different
interfaces because it will be difficult to tell which interface is the
source and which one is the dest.
Well in that case shouldnt NAND be treated like periphral and not memory?
+static enum dma_status
+at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
+ struct dma_tx_state *txstate)
+{
+ struct at_xdmac_chan*atchan = to_at_xdmac_chan(chan);
+ struct at_xdmac *atxdmac = to_at_xdmac(atchan-chan.device);
+ struct at_xdmac_desc*desc, *_desc;
+ unsigned long flags;
+ enum dma_status ret;
+ int residue;
+ u32 cur_nda;
+
+ ret = dma_cookie_status(chan, cookie, txstate);
+ if (ret == DMA_COMPLETE)
+ return ret;
+
+ spin_lock_irqsave(atchan-lock, flags);
+
+ desc = list_first_entry(atchan-xfers_list, struct at_xdmac_desc,
xfer_node);
+
+ if (!desc-active_xfer)
+ dev_err(chan2dev(chan),
+ something goes wrong, there is no active transfer\n);
We can query resiude even when tx_submit hasnt been invoked. You need to
return the full length in that case.
Ok, I was not aware about this case.
+
+ residue = desc-xfer_size;
Also do check if txsate is NULL, in case just bail out here.
Return value will be the one returned by dma_cookie_status?
Yes
+ */
+ list_del(desc-xfer_node);
+ list_splice_init(desc-descs_list, atchan-free_descs_list);
shouldnt you move all the desc in active list in one shot ?
Sorry I don't get it. What are you suggesting by one shot?
Rather than invoking this per descriptor moving descriptors to
free_desc_list one by one, we can move all descriptors togther.
+static void at_xdmac_tasklet(unsigned long data)
+{
+ struct at_xdmac_chan*atchan = (struct at_xdmac_chan *)data;
+ struct at_xdmac_desc*desc;
+ u32 error_mask;
+
+ dev_dbg(chan2dev(atchan-chan), %s: status=0x%08lx\n,
+ __func__, atchan-status);
+
+ error_mask = AT_XDMAC_CIS_RBEIS
+ | AT_XDMAC_CIS_WBEIS
+ | AT_XDMAC_CIS_ROIS;
+
+ if (at_xdmac_chan_is_cyclic(atchan)) {
+
Re: [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr ecc controller
Hi Boris,
On Mon, Jul 28, 2014 at 5:04 PM, Borislav Petkov b...@alien8.de wrote:
On Sun, Jul 27, 2014 at 12:10:52AM +0530, Punnaiah Choudary Kalluri wrote:
Added EDAC support for reporting the ecc errors of synopsys ddr controller.
The ddr ecc controller corrects single bit errors and detects double bit
errors.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes for v3:
- Updated maintainer information
- Driver cleanup as per the review comments
- Shortened the prefix sysnopsys to synps
This is not a good idea, IMO. synopsys is much more understandable
instead of synps. And synopsys-edac is just fine.
Ok. I thought of keeping file name and function name prefixes in sync
will be good and shortening
the prefix would save alignment issues at some places.
As you said i will revert the file name and still i will use synps
as prefix for functions.
Hope this will be ok for you.
Changes for v2:
- Updated the commit header and message
- Renamed the filenames to synopsys_edac
- Corrected the compatilble string, commnets
- Renamed the macros,fucntions and data structures
---
.../devicetree/bindings/edac/synps_edac.txt| 18 +
MAINTAINERS|1 +
drivers/edac/Kconfig |7 +
drivers/edac/Makefile |1 +
drivers/edac/synps_edac.c | 554
5 files changed, 581 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/edac/synps_edac.txt
create mode 100644 drivers/edac/synps_edac.c
diff --git a/Documentation/devicetree/bindings/edac/synps_edac.txt
b/Documentation/devicetree/bindings/edac/synps_edac.txt
new file mode 100644
index 000..c4a559b
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/synps_edac.txt
@@ -0,0 +1,18 @@
+Synopsys EDAC driver, it does reports the DDR ECC single bit errors that are
+corrected and double bit ecc errors that are detected by the DDR ECC
controller.
+ECC support for DDR is available in half-bus width(16 bit) configuration
only.
+
+Required properties:
+- compatible: Should be xlnx,zynq-ddrc-1.04
+- reg: Should contain DDR controller registers location and length.
+
+Example:
+
+
+ddrc0: ddrc@f8006000 {
+ compatible = xlnx,zynq-ddrc-1.04;
+ reg = 0xf8006000 0x1000;
+};
I'd need an ack from device tree people about the DT bits.
+
+Synopsys EDAC driver detects the DDR ECC enable state by reading the
appropriate
+control register.
diff --git a/MAINTAINERS b/MAINTAINERS
index d76e077..984b5a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1479,6 +1479,7 @@ N: xilinx
F: drivers/clocksource/cadence_ttc_timer.c
F: drivers/i2c/busses/i2c-cadence.c
F: drivers/mmc/host/sdhci-of-arasan.c
+F: drivers/edac/synps_edac.c
ARM SMMU DRIVER
M: Will Deacon will.dea...@arm.com
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 878f090..f628a2b 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -368,4 +368,11 @@ config EDAC_OCTEON_PCI
Support for error detection and correction on the
Cavium Octeon family of SOCs.
+config EDAC_SYNPS
+ tristate Synopsys DDR Memory Controller
+ depends on EDAC_MM_EDAC ARCH_ZYNQ
+ help
+ Support for EDAC on the ECC memory used with the Synopsys DDR
+ memory controller.
+
endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 4154ed6..0af900f 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_EDAC_OCTEON_PC)+=
octeon_edac-pc.o
obj-$(CONFIG_EDAC_OCTEON_L2C)+= octeon_edac-l2c.o
obj-$(CONFIG_EDAC_OCTEON_LMC)+= octeon_edac-lmc.o
obj-$(CONFIG_EDAC_OCTEON_PCI)+= octeon_edac-pci.o
+obj-$(CONFIG_EDAC_SYNPS) += synps_edac.o
diff --git a/drivers/edac/synps_edac.c b/drivers/edac/synps_edac.c
new file mode 100644
index 000..a9417fe
--- /dev/null
+++ b/drivers/edac/synps_edac.c
@@ -0,0 +1,554 @@
+/*
+ * Synopsys DDR ECC Driver
+ * This driver is based on ppc4xx_edac.c drivers
+ *
+ * Copyright (C) 2012 - 2014 Xilinx, Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * This file is subject to the terms and conditions of the GNU General
Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details
Re: [PATCH v11 4/8] ata: libahci: allow to use multiple PHYs
On Mon, Jul 28, 2014 at 12:29:56PM +0200, Hans de Goede wrote:
...
+ if (!enabled_ports) {
+ dev_warn(dev, No port enabled\n);
+ return ERR_PTR(-ENODEV);
This should be:
rc = -ENODEV;
goto err_out;
Sorry for not catching that sooner.
Other then that the entire series looks good and is:
Acked-by: Hans de Goede hdego...@redhat.com
Antoine, can you please post an updated version of this patch? No
need to repost the whole series. Also, how should the series be
routed?
Thanks.
--
tejun
--
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: [v2] input: drv260x: Add TI drv260x haptics driver
Hi Dan, On Mon, Jul 28, 2014 at 11:53:23AM -0500, Dan Murphy wrote: Add the TI drv260x haptics/vibrator driver. This device uses the input force feedback to produce a wave form to driver an ERM or LRA actuator device. The initial driver supports the devices real time playback mode. But the device has additional wave patterns in ROM. As it presented the device appears to be a memoryless device, however you present it to the rest of the system as if it can support playback of multiple effects simultaneously, which is incorrect. My guess that you need to engage the memoryless input library to schedule handling multiple effects for your device, including ramping up, ramping down, stopping playback when effects runs out, etc. Thanks. -- Dmitry P.S. If you are using devm_ there is devm_input_allocate_dveice(). -- 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 v3] edac: synps: Added EDAC support for zynq ddr ecc controller
On Mon, Jul 28, 2014 at 10:53:26PM +0530, punnaiah choudary kalluri wrote: I can agree with you that we can use shorter names.But ZYNQ has programmable logic next to processing system where one can add soft memory controller in the same system and may use different driver. So, the edac driver for zynq may include multiple drivers for different memory controllers in the same file. In this case it is difficult to maintain generic macros as you suggested above. So? You can still shorten them a bit - the current names are awfully long. SYNPS_DDRC_ECC_ is too much information, for example. We know it is DDR and we know it is about ECC. So do SYNPS and ZYNQ or OTHER or whatever you wanna call it prefix and then the rest. I.e., SYNPS_reg_bits* ZYNQ_reg_bits* You can even use single letter prefixes like S_ and Z_ and add a comment explaining what those mean. Still much more readable than the long repeating prefixes currently. Also the current edac framework for edac memory controllers is expecting the mc_num from the driver while allocating the memory controller instance using the edac_mc_alloc function. This requirement mandates that if the system contains two different memory controllers then the corresponding edac drivers should be in single file. So you're telling me that you want one edac driver for *two* memory controllers which can be present on a single system *at* *the* *same* *time*? Is that it? How exactly is that topology supposed to look like, work, etc, etc? What kind of error reporting do you imagine you want to do with EDAC? IOW, more info would be appreciated. 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: [v2] input: drv260x: Add TI drv260x haptics driver
Dmitry Thanks for the comments On 07/28/2014 12:43 PM, Dmitry Torokhov wrote: Hi Dan, On Mon, Jul 28, 2014 at 11:53:23AM -0500, Dan Murphy wrote: Add the TI drv260x haptics/vibrator driver. This device uses the input force feedback to produce a wave form to driver an ERM or LRA actuator device. The initial driver supports the devices real time playback mode. But the device has additional wave patterns in ROM. As it presented the device appears to be a memoryless device, however you present it to the rest of the system as if it can support playback of multiple effects simultaneously, which is incorrect. My guess that you need to engage the memoryless input library to schedule handling multiple effects for your device, including ramping up, ramping down, stopping playback when effects runs out, etc. Thanks. I had written the driver originally to be a memless device. But when calling the driver from user space I was not getting the duration, strength of any information from the ff_device structure except the type. The values in the structure were all being passed as 0's. I will attempt it again as a memless device. Dan -- -- Dan Murphy -- 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: [v2] input: drv260x: Add TI drv260x haptics driver
The initial driver supports the devices real time playback mode. But the device has additional wave patterns in ROM. As it presented the device appears to be a memoryless device, however you present it to the rest of the system as if it can support playback of multiple effects simultaneously, which is incorrect. My guess that you need to engage the memoryless input library to schedule handling multiple effects for your device, including ramping up, ramping down, stopping playback when effects runs out, etc. Hi Dan, Elias and Michal (cc'ed) are working on a kernel/userland library to handle sending multiple force feedback signals to 'simple' devices, perhaps you should engage with them. Simon -- 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: [RESEND][PATCHv2 0/3] Fix for buggy u-boot memory banks
On 7/26/2014 2:20 PM, Rob Herring wrote: On Tue, Jul 15, 2014 at 12:03 PM, Laura Abbott lau...@codeaurora.org wrote: Hi, This is a resend of the series to fix the uboot bug exposed by the removal of meminfo. I haven't gotten any acks though. Is the bug with ATAGs that get converted to DT in the decompressor or u-boot puts the wrong info in DT directly? I believe it's u-boot putting the wrong info in DT directly. See http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266782.html Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC Patch V1 22/30] mm, of: Use cpu_to_mem()/numa_mem_id() to support memoryless node
On 28.07.2014 [07:30:40 -0600], Grant Likely wrote:
On Mon, 21 Jul 2014 10:52:41 -0700, Nishanth Aravamudan
n...@linux.vnet.ibm.com wrote:
On 11.07.2014 [15:37:39 +0800], Jiang Liu wrote:
When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
may return a node without memory, and later cause system failure/panic
when calling kmalloc_node() and friends with returned node id.
So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
memory for the/current cpu.
If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id()
is the same as cpu_to_node()/numa_node_id().
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/of/base.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b9864806e9b8..40d4772973ad 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -85,7 +85,7 @@ EXPORT_SYMBOL(of_n_size_cells);
#ifdef CONFIG_NUMA
int __weak of_node_to_nid(struct device_node *np)
{
- return numa_node_id();
+ return numa_mem_id();
}
#endif
Um, NAK. of_node_to_nid() returns the NUMA node ID for a given device
tree node. The default should be the physically local NUMA node, not the
nearest memory-containing node.
That description doesn't match the code. This patch only changes the
default implementation of of_node_to_nid() which doesn't take the device
node into account *at all* when returning a node ID. Just look at the
diff.
I meant that of_node_to_nid() seems to be used throughout the call-sites
to indicate caller locality. We want to keep using cpu_to_node() there,
and fallback appropriately in the MM (when allocations occur offnode due
to memoryless nodes), not indicate memory-specific topology the caller
itself. There was a long thread between between Tejun and I that
discussed what we are trying for: https://lkml.org/lkml/2014/7/18/278
I understand that the code unconditionally returns current's NUMA node
ID right now (ignoring the device node). That seems correct, to me, for
something like:
of_device_add:
/* device_add will assume that this device is on the same node as
* the parent. If there is no parent defined, set the node
* explicitly */
if (!ofdev-dev.parent)
set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node));
I don't think we want the default implementation to set the NUMA node of
a dev to the nearest NUMA node with memory?
I think this patch is correct, and it doesn't affect the override
versions provided by powerpc and sparc.
Yes, agreed, so maybe it doesn't matter. I guess my point was simply
that it only seems reasonable to change callers of cpu_to_node() to
cpu_to_mem() that aren't in the core MM is if they care about memoryless
nodes explicitly. I don't think the OF code does, so I don't think it
should change.
Sorry for my premature NAK and lack of clarity in my explanation.
-Nish
--
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: dts: Add gta04a3 model
Add gta04a3 model with additional acceleromer.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-gta04a3.dts | 48 +
2 files changed, 49 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-gta04a3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3dc9d44..7d45fde 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -283,6 +283,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-devkit8000.dtb \
omap3-evm.dtb \
omap3-evm-37xx.dtb \
+ omap3-gta04a3.dtb \
omap3-gta04a4.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-gta04a3.dts
b/arch/arm/boot/dts/omap3-gta04a3.dts
new file mode 100644
index 000..3099a89
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-gta04a3.dts
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2014 H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include omap3-gta04.dtsi
+
+/ {
+ model = Goldelico GTA04A3;
+};
+
+i2c2 {
+
+ /* alternate accelerometer that might be installed on some GTA04A3
boards */
+ lis302@1d {
+ compatible = st,lis331dlh, st,lis3lv02d;
+ reg = 0x1d;
+ interrupt-parent = gpio3;
+ interrupts = 18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING);
+ Vdd-supply = vaux2;
+ Vdd_IO-supply = vaux2;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 8;
+ st,click-thresh-y = 8;
+ st,click-thresh-z = 10;
+ st,click-click-time-limit = 9;
+ st,click-latency = 50;
+ st,irq1-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 32;
+ st,min-limit-y = 3;
+ st,min-limit-z = 3;
+ st,max-limit-x = 3;
+ st,max-limit-y = 32;
+ st,max-limit-z = 32;
+ };
+};
--
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 3/3] arm: dts: Add gta04a5 model
Add model a5 which have additional jack detection.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-gta04a5.dts | 17 +
2 files changed, 18 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-gta04a5.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7d45fde..576c595 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -285,6 +285,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-evm-37xx.dtb \
omap3-gta04a3.dtb \
omap3-gta04a4.dtb \
+ omap3-gta04a5.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
omap3-ldp.dtb \
diff --git a/arch/arm/boot/dts/omap3-gta04a5.dts
b/arch/arm/boot/dts/omap3-gta04a5.dts
new file mode 100644
index 000..210317c3
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-gta04a5.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2014 H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include omap3-gta04.dtsi
+
+/ {
+ model = Goldelico GTA04A5;
+
+ sound {
+ ti,jack-det-gpio = twl_gpio 2 0;/* GTA04A5 only */
+ };
+};
--
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 1/3] arm: dts: omap3-gta04: Rename gta04.dts to gta04.dtsi and add a4 model
This patch is preparation of adding more boards which have common moved
to omap3-gta04.dtsi. Other boards have only small additions to omap3-gta04a4.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/Makefile | 2 +-
arch/arm/boot/dts/{omap3-gta04.dts = omap3-gta04.dtsi} | 0
arch/arm/boot/dts/omap3-gta04a4.dts | 13 +
3 files changed, 14 insertions(+), 1 deletion(-)
rename arch/arm/boot/dts/{omap3-gta04.dts = omap3-gta04.dtsi} (100%)
create mode 100644 arch/arm/boot/dts/omap3-gta04a4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 82f498b..3dc9d44 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -283,7 +283,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-devkit8000.dtb \
omap3-evm.dtb \
omap3-evm-37xx.dtb \
- omap3-gta04.dtb \
+ omap3-gta04a4.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
omap3-ldp.dtb \
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dtsi
similarity index 100%
rename from arch/arm/boot/dts/omap3-gta04.dts
rename to arch/arm/boot/dts/omap3-gta04.dtsi
diff --git a/arch/arm/boot/dts/omap3-gta04a4.dts
b/arch/arm/boot/dts/omap3-gta04a4.dts
new file mode 100644
index 000..c918bb1
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-gta04a4.dts
@@ -0,0 +1,13 @@
+/*
+ * Copyright (C) 2014 Marek Belisko ma...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include omap3-gta04.dtsi
+
+/ {
+ model = Goldelico GTA04A4;
+};
--
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
