Re: [PATCH v10] reset: Add driver for gpio-controlled reset pins
On Thu, Jul 18, 2013 at 11:26:26AM +0200, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com Tested-by: Shawn Guo shawn@linaro.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] reset: allow drivers to request probe deferral
On Thu, Jul 18, 2013 at 01:57:33PM +0200, Philipp Zabel wrote:
If the requested reset controller is not yet available, have reset_control_get
and device_reset return -EPROBE_DEFER so the driver can decide to request
probe deferral.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/reset/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index d1b6089..b3d99a1 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -167,7 +167,7 @@ struct reset_control *reset_control_get(struct device
*dev, const char *id)
if (!rcdev) {
mutex_unlock(reset_controller_list_mutex);
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(-EPROBE_DEFER);
Yeah, with the change the client device driver does not need to
translate error code -ENODEV into -EPROBE_DEFER, but just return
whatever device_reset() returns in error case. So,
Acked-by: Shawn Guo shawn@linaro.org
}
rstc_id = rcdev-of_xlate(rcdev, args);
--
1.8.3.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote: Hi, On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek pa...@denx.de wrote: It sound to me like keeping ammount of -EPROBE_DEFER to minimum is still preferred. Hand-crafting initcall level ordering of various drivers and subsystem is probably an even greater evil though. We've done it in the past, but now that we have deferred probe we have the option of not having to do it every time, such as this. You're spending an awful lot of energy arguing over this, but nobody has actually shown data of how much deferral is happening -- and that it's a real problem. Until someone does so there's no reason to change it from the default module init level at all, I'd say. On imx6qdl-sabreauto board, there are 3 MAX7310 units as IO expanders to output 3 x 8 = 24 GPIOs. 18 of them are used for resets, enables and pin steering for various peripherals on the board. BACKLITE_ON SAT_SHUTDN_B CPU_PER_RST_B MAIN_PER_RST_B IPOD_RST_B MLB_RST_B SSI_STEERING GPS_RST_B GPS_PWREN VIDEO_ADC_PWRDN_B ENET_CAN1_STEER EIMD30_BTUART3_STEER CAN_STBY CAN_EN USB_H1_PWR USB_OTG_PWR_ON SAT_RST_B NAND_BT_WIFI_STEER Most of these GPIOs need to set up properly at client device driver's probe stage - module_init() time. So if we have all these service providers resets/enables/steering API registered at module_init() too, the probes of all these client device drivers stand a good chance to be deferred. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote: Hi Philipp, On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com I see this patch is very useful, as GPIOs are widely used to reset components/devices on board. But I do not find the patch in v3.11-rc1. What's your plan about it? Also, I'm wondering if we should register the driver a little bit early. Please see the following patch. If it makes sense to you, I can send the patch to you, or you can just quash it into yours. And here is another change request. Shawn 8--- From 822a0c4fb7c99b371844ba7e957affcaa8cb1cfe Mon Sep 17 00:00:00 2001 From: Shawn Guo shawn@linaro.org Date: Sun, 14 Jul 2013 20:28:05 +0800 Subject: [PATCH] ENGR00269945: reset: handle cansleep case in gpio-reset Some gpio reset may be backed by a gpio that can sleep, e.g. pca953x gpio output. For such gpio, gpio_set_value_cansleep() should be called. Otherwise, the WARN_ON(chip-can_sleep) in gpiod_set_value() will be hit. Add a gpio_cansleep() check to handle cansleep gpio. Signed-off-by: Shawn Guo shawn@linaro.org --- drivers/reset/gpio-reset.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c index 5d2515a..4f372f9 100644 --- a/drivers/reset/gpio-reset.c +++ b/drivers/reset/gpio-reset.c @@ -32,7 +32,10 @@ static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted) if (drvdata-active_low) value = !value; - gpio_set_value(drvdata-gpio, value); + if (gpio_cansleep(drvdata-gpio)) + gpio_set_value_cansleep(drvdata-gpio, value); + else + gpio_set_value(drvdata-gpio, value); } static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id) -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 11:51:19AM +0200, Philipp Zabel wrote: Looks good to me. I can squash it into the original patch and resend if you like. Yes, please. Thanks. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()
On Tue, Jul 16, 2013 at 08:05:07PM +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Shawn Guo shawn@linaro.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 11:49:26AM +0200, Philipp Zabel wrote: so you want to have gpio-reset probed at arch_initcall time and you have gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset devices that use gpios on pca953x to reset other peripherals need to be deferred? Yes, they will be deferred, but they will be probed and ready at subsys_initcall time when gpio-pca953x probes. This is still good since most of component device drivers probes at module_init time. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote: Registering the driver earlier won't cause any bugs. However, it's not the correct approach. Deferred probe /is/ the approach for assuring correct dependencies between drivers. It works and should be used. There are not enough initcall levels to play games using initcalls and solve all the issues, and the ordering requirements vary board-to-board. Deferred probe at runtime handles this without having to manually place all the drivers into specific initcall levels, and dynamically adjusts to board differences, since it all happens automatically at run-time. I do not quite follow the argument here. I agree with you that deferred probe is the approach to solve dependencies. But it does not necessarily mean that initcall can not be used to help it save some nasty or nested deferring. Deferred probe and initcalls are not two mutually exclusive mechanisms but two which can help each other. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Tue, Jul 16, 2013 at 09:47:02AM -0600, Stephen Warren wrote: diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c - gpio_set_value(drvdata-gpio, value); + if (gpio_cansleep(drvdata-gpio)) + gpio_set_value_cansleep(drvdata-gpio, value); + else + gpio_set_value(drvdata-gpio, value); That's not right. Calling gpio_set_value() v.s. gpio_set_value_cansleep() should be based on the properties of the calling context, not the GPIO being controlled. In other words, if it's permissible to call gpio_set_value_cansleep() at this point in the code, simply always call that, and remove the conditional logic. Ah, yes. I was confused by the API gpio_cansleep(). Which API we should call depends on the calling context. And the context should come from the gpio-reset client device driver. IOW, we have no idea what the context is in gpio-reset driver. To start with something simple, we may want to define the gpio-reset as a sleepable interface and always call gpio_set_value_cansleep() in there. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
On Mon, Jul 15, 2013 at 02:40:39PM +0800, Robin Gong wrote:
+static const struct of_device_id pfuze_dt_ids[] = {
+ { .compatible = fsl,pfuze100, .data = (void *)PFUZE_ID_PFUZE100},
You do not use .data in the driver at all, and can just drop it.
good catch. .driver_data of i2c_device_id and .data of of_device_id are two
different ways to let driver know which chip used now by DTS or not. I should
use them to know which chip used now ,although I can know by reading chipid
register.
If you can figure out the chip ID from hardware, it should be used as
the preference over compatible and .driver_data.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote: It's a little bit late to register gpio-reset driver at module_init time, because gpio-reset provides reset control via gpio for other devices which are mostly probed at module_init time too. And it becomes even worse, when the gpio comes from IO expander on I2C bus, e.g. pca953x. In that case, gpio-reset needs to be ready before I2C bus driver which is generally ready at subsys_initcall time. Let's register gpio-reset driver in arch_initcall() to have it ready early enough. There's no need for the reset driver to be registered before its users; the users of the reset GPIO will simply have their probe deferred until the reset controller is available, and then everything will work out just fine. The defer probe mechanism is not used here, because a reset controller driver should be reasonably registered early than other devices. More importantly, defer probe doe not help in some nasty cases, e.g. the gpio-pca953x device itself needs a reset from gpio-reset driver to start working. That should work fine with deferred probe. I should probably rework the commit log. But I do not see a problem to register gpio-reset driver a little bit earlier. On the other hand, if we reply on deferred probe, many drivers probe could be deferred. For example, on my system, the gpio-pca953x on I2C bus works as a GPIO controller and provides resets to many board level components. Deferring probe of gpio-pca953x on I2C bus means every single probe of all these components gets deferred. IMO, this situation should be reasonably avoided. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
The patch looks good. Comments below are mostly random coding style
nitpicks.
On Fri, Jul 12, 2013 at 12:54:15PM +0800, Robin Gong wrote:
Add pfuze100 regulator driver.
Signed-off-by: Robin Gong b38...@freescale.com
---
.../devicetree/bindings/regulator/pfuze100.txt | 113 +
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/pfuze100-regulator.c | 489
include/linux/regulator/pfuze.h| 49 ++
We should probably name the header in the same way as driver file, so
pfuze100.h?
5 files changed, 659 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/pfuze100.txt
create mode 100644 drivers/regulator/pfuze100-regulator.c
create mode 100644 include/linux/regulator/pfuze.h
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt
b/Documentation/devicetree/bindings/regulator/pfuze100.txt
new file mode 100644
index 000..d9fc752
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -0,0 +1,113 @@
+PFUZE100 family of regulators
+
+Required properties:
+- compatible: fsl,pfuze100
+- reg: I2C slave address
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Please refer to below doc
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+ The valid names for regulators are:
+ sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ pmic: pfuze100@08 {
+ compatible = fsl,pfuze100;
+ reg = 0x08;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 1875000;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = 6250;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = 11;
+ regulator-max-microvolt = 1875000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = 80;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = 40;
+ regulator-max-microvolt = 1975000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = 40;
+ regulator-max-microvolt = 1975000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = 80;
+ regulator-max-microvolt = 330;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 515;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 300;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = 80;
+ regulator-max-microvolt = 155;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = 80;
+ regulator-max-microvolt = 155;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = 180;
+
Re: [PATCH 1/2] ARM i.MX53: mba53: Fix PWM backlight DT node
On Thu, Jul 11, 2013 at 04:37:47PM +0200, Laurent Pinchart wrote: The i.MX53 PWM controller uses two cells to describe the PWM specifier. Remove the extra unused values from the backlight DT node pwms property. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] ARM: dts: imx27 phyCARD-S I2C devices
On Sun, Jul 07, 2013 at 03:13:28PM +0200, Markus Pargmann wrote: Markus Pargmann (3): ARM: dts: imx27 phyCARD-S SOM remove wrong i2c sensor ARM: dts: imx27 phyCARD-S, move i2c1 and owire to rdk ARM: dts: imx27 phyCARD-S, i2c ADC device node All applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: imx27: Fix documentation for SPLL clock
On Sun, Jun 23, 2013 at 10:51:10AM +0200, Markus Pargmann wrote: spll_gate was added with commit b7eed2076183994dbda2c19bc7fba99b65a135e3 ARM: imx27: add a clock gate to activate SPLL clock. spll_gate is missing in the devicetree clock documentation for imx27. This patch adds it to the list of clocks in the documentation. Signed-off-by: Markus Pargmann m...@pengutronix.de Applied, thanks. Shawn --- Documentation/devicetree/bindings/clock/imx27-clock.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt index ab1a56e..7a20703 100644 --- a/Documentation/devicetree/bindings/clock/imx27-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt @@ -98,6 +98,7 @@ clocks and IDs. fpm 83 mpll_osc_sel 84 mpll_sel 85 + spll_gate86 Examples: -- 1.8.2.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/6] ARM: dts: imx27 cpufreq-cpu0 frequencies
On Thu, Jun 20, 2013 at 04:50:14PM +0200, Markus Pargmann wrote:
Set operating-points for imx27. There is no regulator support, so the
voltages are 0. The frequencies should be the same for all imx27 boards,
so it is defined here and can be overwritten if necessary.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/boot/dts/imx27.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index e883e77..3ebd98a 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -47,6 +47,25 @@
};
};
+ cpus {
+ #size-cells = 0;
+ #address-cells = 1;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = fsl,imx27, arm,arm926ejs;
From what Documentation/devicetree/bindings/arm/cpus.txt tells, it
should be arm,arm926. Also, why do you put fsl,imx27 there?
imx27 is a SoC name not cpu core.
Shawn
+ reg = 0;
+ operating-points =
+ /* kHz uV (No regulator support) */
+ 133000 0
+ 399000 0
+ ;
+ clock-latency = 61036; /* two CLK32 periods */
+ clocks = clks 18;
+ clock-names = cpu;
+ };
+ };
+
soc {
#address-cells = 1;
#size-cells = 1;
--
1.8.2.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/6] ARM: dts: Add device tree support for phycard pca100
On Thu, Jun 20, 2013 at 04:50:15PM +0200, Markus Pargmann wrote:
Based on patches from:
Steffen Trumtrar s.trumt...@pengutronix.de:
- Original patch
- ARM: dts: Set partition offsets for phycard
- ARM: dts: Use CSPI1 instead of CSPI2 on phycard pca100
- ARM: imx27-phytec-phycard-S.dts: resize nand partitions
Jan Luebbe j...@pengutronix.de:
- ARM: dts: Enable bad block table in NAND
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
Cc: Jan Luebbe j...@pengutronix.de
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx27-phytec-phycard-S.dts | 195
+++
arch/arm/mach-imx/Kconfig| 1 +
3 files changed, 197 insertions(+)
create mode 100644 arch/arm/boot/dts/imx27-phytec-phycard-S.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b3a8661..e8fb0bc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -105,6 +105,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx27-pdk.dtb \
imx27-phytec-phycore-som.dtb \
imx27-phytec-phycore-rdk.dtb \
+ imx27-phytec-phycard-S.dtb \
imx31-bug.dtb \
imx51-apf51.dtb \
imx51-apf51dev.dtb \
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-S.dts
b/arch/arm/boot/dts/imx27-phytec-phycard-S.dts
new file mode 100644
index 000..dc3a93b
--- /dev/null
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-S.dts
@@ -0,0 +1,195 @@
+/*
+ * Copyright 2012 Sascha Hauer, Uwe Kleine-König and Steffen Trumtrar,
Pengutronix
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include imx27.dtsi
+
+/ {
+ model = Phytec pca100;
+ compatible = phytec,imx27-pca100, fsl,imx27;
+
+ memory {
+ device_type = memory;
It's been covered by skeleton.dtsi.
+ #address-cells = 1;
+ #size-cells = 1;
They are only needed if there are child nodes with reg property.
+ reg = 0x0 0x0800; // 128MB
+ };
+
+ soc {
+ aipi@1000 { /* aipi */
+ wdog@10002000 {
+ status = okay;
+ };
We now use node label in board dts files to refer to the nodes defined
in soc dts.
+
+ owire@10009000 {
+ status = okay;
+ };
+
+ serial@1000a000 {
+ fsl,uart-has-rtscts;
+ status = okay;
+ };
+
+ serial@1000b000 {
+ fsl,uart-has-rtscts;
+ status = okay;
+ };
+
+ serial@1000c000 {
+ fsl,uart-has-rtscts;
+ status = okay;
+ };
+
+ cspi@1000e000 {
+ fsl,spi-num-chipselects = 2;
+ cs-gpios = gpio4 28 0,
+ gpio4 27 0;
+ status = okay;
+ };
+
+ i2c@10012000 {
+ status = okay;
+ ioexpander@41 {
+ compatible = nxp,pca9536;
+ reg = 0x41;
+ };
Please put blank line before and after node.
+ rtc@51 {
+ compatible = nxp,pcf8563;
+ reg = 0x51;
+ };
+ dimmer@60 {
+ compatible = nxp,pca9530;
+ reg = 0x60;
+ pwm = 1 1;
+ psc = 1 1;
+ leds = led0 led1;
Are these documented/accepted bindings?
+ led0: led0 {
+ label = pba-lcd_brightness;
+ default-state = off;
+ type = led;
What is this type property used for? Is it documented?
+ };
+ led1: led1 {
+ label = pba-free_use;
+ default-state = off;
+ type = led;
+
Re: [PATCH v2] staging: imx_drm: imx_ldb: fix 18 bit format
On Mon, Jun 17, 2013 at 11:02:52AM +0200, Steffen Trumtrar wrote: From: Markus Niebel markus.nie...@tqs.de Since 18 bit is supported as datawidth in device tree it should be supported in driver. Beside the LDB channel the IPU channel has also to be configured to use BGR666. Signed-off-by: Markus Niebel markus.nie...@tqs.de Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- This is based on the series: staging: drm/imx: Add LDB support by Philipp. Greg, Can you queued this patch and staging: drm/imx: Add LDB support from Philipp Zabel for 3.11 please? With these two patches, I can boot my imx6q board into LUbuntu 13.04 with LVDS panel. So for both patches, Tested-by: Shawn Guo shawn@linaro.org Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/5] clk: divider: replace bitfield width with mask
On Sun, Jun 16, 2013 at 07:58:21PM -0700, Mike Turquette wrote: The forthcoming Device Tree binding for the divider clock type will use a bitfield mask instead of bitfield width, which is what the current basic divider implementation uses. This patch replaces the u8 width in struct clk_divider with a u32 mask. The divider code is updated to use the bit mask internally but the two registration functions still accept the width to maintain compatibility with existing users. Also updated in this patch is the clk-private.h divider macro and two Freescale clock divider implementations that are based on struct clk_divider. Cc: Sascha Hauer ker...@pengutronix.de Cc: Shawn Guo shawn@linaro.org Signed-off-by: Mike Turquette mturque...@linaro.org --- No change since v1, new patch arch/arm/mach-imx/clk-busy.c | 2 +- drivers/clk/clk-divider.c| 31 +++ drivers/clk/mxs/clk-div.c| 2 +- include/linux/clk-private.h | 2 +- include/linux/clk-provider.h | 2 +- 5 files changed, 19 insertions(+), 20 deletions(-) On imx and mxs, Tested-by: Shawn Guo shawn@linaro.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] staging: imx_drm: imx_ldb: fix 18 bit format
On Mon, Jun 17, 2013 at 01:59:48PM -0700, Greg Kroah-Hartman wrote: On Mon, Jun 17, 2013 at 11:02:52AM +0200, Steffen Trumtrar wrote: From: Markus Niebel markus.nie...@tqs.de Since 18 bit is supported as datawidth in device tree it should be supported in driver. Beside the LDB channel the IPU channel has also to be configured to use BGR666. Signed-off-by: Markus Niebel markus.nie...@tqs.de Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de Tested-by: Shawn Guo shawn@linaro.org --- This is based on the series: staging: drm/imx: Add LDB support by Philipp. I don't seem to have that series in my queue anywhere, can someone please resend it, and this patch, so that I can apply them? I just resent them to you. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [v1 2/3] ata: ahci_platform: enable imx6q ahci sata support
On Mon, Jun 17, 2013 at 05:52:46PM +0800, Richard Zhu wrote:
imx6q contains the Synopsys AHCI SATA controller which shares
ahci_platform driver with other controllers.
This patch updates the DT compatible list for ahci_platform,
and enable the imx6q ahci sata support.
Signed-off-by: Richard Zhu r65...@freescale.com
---
drivers/ata/ahci_platform.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 7a8a284..61f2142 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -327,6 +327,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend,
ahci_resume);
static const struct of_device_id ahci_of_match[] = {
{ .compatible = snps,spear-ahci, },
+ { .compatible = snps,imx-ahci, },
I'm not sure it makes much sense to invent multiple platform specific
strings for an IP which is completely compatible between them.
Why don't we just have a generic compatible string like snps,ahci
for all those compatible platforms, and only add platform specific
string when there is incompatibility on particular platform to deal
with?
Added devicetree-discuss to get DT people's opinion.
Shawn
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [v1 2/3] ata: ahci_platform: enable imx6q ahci sata support
On Tue, Jun 18, 2013 at 02:19:52AM +, Zhu Richard-R65037 wrote:
Hi TejunShawn:
Thanks for your comments.
Hi Tejun:
I looked through the for-next branch of the libata git-repo, there maybe a
merge conflict.
static const struct of_device_id ahci_of_match[] = {
{ .compatible = snps,spear-ahci, },
{ .compatible = snps,exynos5440-ahci, },
This is exactly what I'm concerned about. We will end up with a huge
match table with all different platform specific compatible strings in
there. But they're all matching to the same programming model of the
same IP block. That's not how device tree compatible table works.
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
How about to re-change the patch, based on for-next branch of the libata
git-repo.
Yes, I think the driver part and platform part can go separately.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8 00/11] ASoC: fsl-ssi: ac97-slave support
On Sun, Jun 16, 2013 at 03:25:06PM +0200, Markus Pargmann wrote: Markus Pargmann (11): ASoC: imx-pcm-dma: DT support ASoC: imx-pcm-fiq: Introduce pcm-fiq-params ASoC: fsl: Move soc_ac97_ops from imx-ssi to fsl_ssi ASoC: fsl-ssi: Add support for imx-pcm-fiq ASoC: fsl-ssi: Use generic DMA bindings if possible ASoC: fsl-ssi: imx ac97 support ARM: imx: Export ac97 reset functions ASoC: Add phycore-ac97-dt driver ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97 ASoC: fsl: Move fsl-ssi binding doc to sound/ ASoC: fsl: Update fsl-ssi binding doc Tested-by: Shawn Guo shawn@linaro.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/7] ARM: mxc: fix gpio-ranges for VF610
On Thu, Jun 13, 2013 at 02:59:53PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com The gpio-ranges properties in vf610.dtsi were written according to an older version of the GPIO bindings. Unfortunately, these were changed incompatibly in commit 86853c8 gpio: add gpio offset in gpio range cells property. This patch adds the missing required extra cell in each gpio-ranges property. Signed-off-by: Stephen Warren swar...@nvidia.com Applied, thanks. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 0/3] clk: dt: bindings for mux divider clocks
On Fri, Jun 07, 2013 at 10:52:54AM -0700, Mike Turquette wrote: Yes, there was a time when I was firmly against doing such a thing. However I'm not sure it is so bad now. More and more SoCs are going to keep getting merged into the kernel and that just means more and more clock data. Perhaps DT is best suited to handle this bloat. I broke the clock data out into a separate file so that it didn't overwhelm the existing omap4.dtsi. I'm actually more concerned by run-time impact. Any of_find_node_*() call will possibly have to scan all those hundreds of nodes to find the desired one. Anyway, it's an OMAP folks decision, and the impact might not be that much on those fast CPUs. Shawn Either way I marked this series as RFC precisely due to your point. I want feedback on how the OMAP folks feel about this. So far no has has NACKed it ;-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] staging: imx_drm: imx_ldb: fix 18 bit format
On Fri, Jun 07, 2013 at 10:37:08AM +0200, Steffen Trumtrar wrote:
From: Markus Niebel markus.nie...@tqs.de
Since 18 bit is supported as datawidth in device tree it should be
supported in driver. Beside the LDB channel the IPU channel has also
to be configured to use BGR666.
Signed-off-by: Markus Niebel markus.nie...@tqs.de
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
This is based on the series: staging: drm/imx: Add LDB support
by Philipp.
drivers/staging/imx-drm/imx-ldb.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index d8fc93c..84bf7d3 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -179,6 +179,7 @@ static void imx_ldb_encoder_prepare(struct drm_encoder
*encoder)
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch-ldb;
struct drm_display_mode *mode = encoder-crtc-mode;
+ u32 pixel_fmt;
unsigned long serial_clk;
unsigned long di_clk = mode-clock * 1000;
int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch-imx_drm_encoder,
@@ -194,8 +195,23 @@ static void imx_ldb_encoder_prepare(struct drm_encoder
*encoder)
imx_ldb_set_clock(ldb, mux, imx_ldb_ch-chno, serial_clk,
di_clk);
}
+ switch (imx_ldb_ch-chno) {
+ case 0:
+ pixel_fmt = (ldb-ldb_ctrl LDB_DATA_WIDTH_CH0_24) ?
+ V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+ break;
+ case 1:
+ pixel_fmt = (ldb-ldb_ctrl LDB_DATA_WIDTH_CH1_24) ?
+ V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+ break;
+ default:
+ dev_err(ldb-dev, unable to config di%d panel format\n,
+ imx_ldb_ch-chno);
+ pixel_fmt = V4L2_PIX_FMT_RGB24;
+ }
+
imx_drm_crtc_panel_format_pins(encoder-crtc, DRM_MODE_ENCODER_LVDS,
- V4L2_PIX_FMT_RGB24, 2, 3);
+ pixel_fmt, 2, 3);
It seems the patch is based on an updated version of staging: drm/imx:
Add LDB support? The last one from Philipp [1] calls function
imx_drm_crtc_panel_format() rather than imx_drm_crtc_panel_format_pins()
there.
Shawn
[1]
http://thread.gmane.org/gmane.linux.drivers.driver-project.devel/36836/focus=36834
}
static void imx_ldb_encoder_commit(struct drm_encoder *encoder)
--
1.8.2.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] ARM i.MX53: tqma53: Fix interrupt polarity for the mc34708
On Tue, Jun 04, 2013 at 11:12:27AM +0200, Steffen Trumtrar wrote: From: Sascha Hauer s.ha...@pengutronix.de It's active high, not active low. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Applied 1 ~ 3. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM i.MX53: tqma53: add WP/CD pinctrl and vmmc to esdhc2
On Tue, Jun 04, 2013 at 11:12:30AM +0200, Steffen Trumtrar wrote:
Add WP/CD pinctrl for esdhc2.
Also, add vmmc-supply for esdhc2.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
arch/arm/boot/dts/imx53-tqma53.dtsi | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi
b/arch/arm/boot/dts/imx53-tqma53.dtsi
index 450e4de..9ecd198 100644
--- a/arch/arm/boot/dts/imx53-tqma53.dtsi
+++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
@@ -35,7 +35,9 @@
esdhc2 {
pinctrl-names = default;
- pinctrl-0 = pinctrl_esdhc2_1;
+ pinctrl-0 = pinctrl_esdhc2_1,
+ pinctrl_esdhc2_2;
+ vmmc-supply = reg_3p3v;
wp-gpios = gpio1 2 0;
cd-gpios = gpio1 4 0;
status = disabled;
@@ -69,6 +71,15 @@
pinctrl-names = default;
pinctrl-0 = pinctrl_hog;
+ esdhc2_2 {
+ pinctrl_esdhc2_2: esdhc2-grp2 {
pinctrl_esdhc2_2 should be used by soc.dtsi to define the second pin
group for esdhc2 function, so please encode the board name in it to
avoid the name space conflict.
Shawn
+ fsl,pins =
+ MX53_PAD_GPIO_4__GPIO1_40x8000 /*
SD2_CD */
+ MX53_PAD_GPIO_2__GPIO1_20x8000 /*
SD2_WP */
+ ;
+ };
+ };
+
i2s {
pinctrl_i2s_1: i2s-grp1 {
fsl,pins =
--
1.8.2.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM i.MX53: Add TVE entry to i.MX53 dtsi
On Tue, Jun 04, 2013 at 12:12:22PM +0200, Steffen Trumtrar wrote: From: Philipp Zabel p.za...@pengutronix.de This adds the Television Encoder (TVEv2) device tree node to the i.MX53 dtsi. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de Applied, thanks. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM i.MX53: tqma53: add WP/CD pinctrl and vmmc to esdhc2
On Thu, Jun 06, 2013 at 11:49:36AM +0200, Steffen Trumtrar wrote: Add WP/CD pinctrl for esdhc2. Also, add vmmc-supply for esdhc2. Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de Applied, thanks. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] update MBa53 support
On Tue, Jun 04, 2013 at 01:07:07PM +0200, Steffen Trumtrar wrote: Markus Niebel (4): ARM i.MX53: mba53: add sound support ARM i.MX53: mba53: add missing gpio stuff for pca9554 ARM i.MX53: mba53: use reset gpio for FEC ARM i.MX53: mba53: add DI1_CLK to pinctrl for disp1 Michael Olbrich (1): ARM i.MX53: mba53: enable usbotg usbh1 Philipp Zabel (1): ARM i.MX53: mba53: add Tevision Encoder Sascha Hauer (1): ARM i.MX53: mba53: Add display support Steffen Trumtrar (1): ARM i.MX53: mba53: fix lvds/disp pinctrl All applied, thanks. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/6] drivers: bus: add a new driver for WEIM
On Tue, May 28, 2013 at 02:20:07PM +0800, Huang Shijie wrote: The WEIM(Wireless External Interface Module) works like a bus. You can attach many different devices on it, such as NOR, onenand. In the case of i.MX6q-sabreauto, the NOR is connected to WEIM. This patch also adds the devicetree binding document. The driver only works when the devicetree is enabled. Signed-off-by: Huang Shijie b32...@freescale.com --- Documentation/devicetree/bindings/bus/imx-weim.txt | 49 +++ drivers/bus/Kconfig|9 ++ drivers/bus/Makefile |1 + drivers/bus/imx-weim.c | 138 4 files changed, 197 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt create mode 100644 drivers/bus/imx-weim.c Since no one is collecting drivers/bus/ patches right now, I just applied the whole series to have the patch go via imx - arm-soc. Please let me know if there is any problem. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 06/11] staging: drm/imx: Add LDB support
On Thu, Mar 28, 2013 at 04:23:30PM +0100, Philipp Zabel wrote:
+static void imx_ldb_encoder_prepare(struct drm_encoder *encoder)
+{
+ struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
+ struct imx_ldb *ldb = imx_ldb_ch-ldb;
+ struct drm_display_mode *mode = encoder-crtc-mode;
+ unsigned long serial_clk;
+ unsigned long di_clk = mode-clock * 1000;
+ int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch-imx_drm_encoder,
+ encoder-crtc);
+
+ if (ldb-ldb_ctrl LDB_SPLIT_MODE_EN) {
+ /* dual channel LVDS mode */
+ serial_clk = 3500UL * mode-clock;
+ imx_ldb_set_clock(ldb, mux, 0, serial_clk, di_clk);
+ imx_ldb_set_clock(ldb, mux, 1, serial_clk, di_clk);
+ } else {
+ serial_clk = 7000UL * mode-clock;
+ imx_ldb_set_clock(ldb, mux, imx_ldb_ch-chno, serial_clk,
di_clk);
+ }
+
+ imx_drm_crtc_panel_format(encoder-crtc, DRM_MODE_ENCODER_LVDS,
+ V4L2_PIX_FMT_RGB24);
I have panel which needs it to be V4L2_PIX_FMT_BGR666. We should
probably have a device tree property for that like interface_pix_fmt in
parallel display support?
Shawn
+}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 06/11] staging: drm/imx: Add LDB support
On Thu, Jun 06, 2013 at 05:54:42PM +0200, Philipp Zabel wrote: I'm not sure. Is this something that should be done unconditionally for fsl,data-width = 18? Ah, yes, that's better. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 0/3] clk: dt: bindings for mux divider clocks
Mike, On Mon, Jun 03, 2013 at 10:53:07AM -0700, Mike Turquette wrote: I am using this code while converting the OMAP4 clock data over to DT I see these basic clk bindings can be useful for platforms that have a relatively simple clock tree, but I'm a little surprised that you plan to move OMAP4 to it. I'm wondering how many nodes you will have to add to OMAP4 device tree. For imx6q example, it means ~200 nodes addition to device tree, which is obviously a bloating of device tree. Shawn and some common boilerplate code can be factored out of several clock drivers if this is merged. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 09/10] ASoC: fsl: Move fsl-ssi binding doc to sound/
On Tue, May 28, 2013 at 04:47:57PM +0200, Markus Pargmann wrote: fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific device, so it should be moved to sound/ as it connects to differen audio codecs. Signed-off-by: Markus Pargmann m...@pengutronix.de --- .../devicetree/bindings/powerpc/fsl/ssi.txt| 73 -- .../devicetree/bindings/sound/fsl,ssi.txt | 73 ++ Please add -M to git format-patch command. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 08/11] ASoC: phycore-ac97: Add DT support
On Thu, May 30, 2013 at 04:51:50PM +0200, Markus Pargmann wrote: Add devicetree support for phycore-ac97 driver. platform_of_node and cpu_of_node are set according to the fsl,audmux phandle. This patch adds handling of ac97 reset functions according to fsl ac97 support. They are setup from here to avoid board specific code in the generic fsl-ssi driver. This patch changes the handling of pca100 boards from non-DT to DT only. pcm043 is still handled without DT. Signed-off-by: Markus Pargmann m...@pengutronix.de Compiling phycore-ac97 as module, I got the following errors. CC [M] sound/soc/fsl/phycore-ac97.o sound/soc/fsl/phycore-ac97.c:305:1: error: redefinition of ‘__inittest’ sound/soc/fsl/phycore-ac97.c:146:1: note: previous definition of ‘__inittest’ was here sound/soc/fsl/phycore-ac97.c:305:1: error: redefinition of ‘init_module’ sound/soc/fsl/phycore-ac97.c:146:1: note: previous definition of ‘init_module’ was here sound/soc/fsl/phycore-ac97.c:305:1: error: redefinition of ‘__exittest’ sound/soc/fsl/phycore-ac97.c:147:1: note: previous definition of ‘__exittest’ was here sound/soc/fsl/phycore-ac97.c:305:1: error: redefinition of ‘cleanup_module’ sound/soc/fsl/phycore-ac97.c:147:1: note: previous definition of ‘cleanup_module’ was here make[4]: *** [sound/soc/fsl/phycore-ac97.o] Error 1 Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 01/10] ASoC: phycore-ac97: Add DT support
On Tue, May 28, 2013 at 04:47:49PM +0200, Markus Pargmann wrote:
Add devicetree support for this audio soc fabric driver.
platform_of_node and cpu_of_node are set according to the fsl,audmux
phandle.
This patch adds handling of ac97 reset functions according to fsl ac97
support. They are setup from here to avoid board specific code in the
generic fsl-ssi driver.
This patch changes the handling of pca100 boards from non-DT to DT only.
pcm043 is still handled without DT.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Notes:
Changes in v6:
- phycore-ac97 now manages the ac97 reset functions of the boards using
this combination of ssi-codec.
- Removed preprocessor ifs for DT, non-DT distinction. pcm043 is now
non-DT only and pca100 DT only.
Changes in v4:
- New property phytec,audmux to check which audmux setup should be
executed. Checking for fsl,imx21-audmux and fsl,imx31-audmux.
Changes in v3:
- Add some more information in the commit message.
Changes in v2:
- Simplify the driver, by combining audmux port configurations. The
audmux driver actually knows on which platform he is running and
will return the appropriate error code if we use functions for
another platform. So we don't need to have the knowledge about it
in phycore-ac97 and can try both functions. This removes the need
of different compatibilities and renames it to phycore-ac97.
- Use a phandle for the cpu_dai link.
- Add devicetree binding documentation.
- Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
Changes in v2:
- Simplify the driver, by combining audmux port configurations. The
audmux driver actually knows on which platform he is running and
will return the appropriate error code if we use functions for
another platform. So we don't need to have the knowledge about it
in phycore-ac97 and can try both functions. This removes the need
of different compatibilities and renames it to imx27-ac97.
- Use a phandle for the cpu_dai link.
- Add devicetree binding documentation.
- Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
.../bindings/sound/phytec,phycore-ac97.txt | 14 ++
sound/soc/fsl/phycore-ac97.c | 241
++---
2 files changed, 229 insertions(+), 26 deletions(-)
create mode 100644
Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
diff --git a/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
new file mode 100644
index 000..41201ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
@@ -0,0 +1,14 @@
+Phytec phycore AC97
+
+Required properties:
+- compatible: phytec,phycore-ac97
+- phytec,ssi: A phandle to the ssi device that is connected to ac97.
+- phytec,audmux: A phandle to the audmux device.
+
+Example:
+
+sound {
+ compatible = phytec,phycore-ac97;
+ phytec,ssi = ssi1;
+ phytec,audmux = audmux;
+};
diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c
index ae403c2..bf2c600 100644
--- a/sound/soc/fsl/phycore-ac97.c
+++ b/sound/soc/fsl/phycore-ac97.c
@@ -20,8 +20,14 @@
#include asm/mach-types.h
#include imx-audmux.h
+#include fsl_ssi.h
+
+#define DRV_NAME phycore-audio-fabric
static struct snd_soc_card imx_phycore;
+static struct device_node *phycore_dai_cpu_node;
+static void (*phycore_ac97_reset) (struct snd_ac97 *ac97);
+static void (*phycore_ac97_warm_reset)(struct snd_ac97 *ac97);
static struct snd_soc_ops imx_phycore_hifi_ops = {
};
@@ -32,12 +38,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
.stream_name= HiFi,
.codec_dai_name = wm9712-hifi,
.codec_name = wm9712-codec,
- .cpu_dai_name = imx-ssi.0,
- .platform_name = imx-ssi.0,
I do not think these and phycore_ac97_plat_name changes are necessary,
since of_node will always take precedence over name in match.
.ops= imx_phycore_hifi_ops,
},
};
+static const char phycore_ac97_plat_name[] = imx-ssi.0;
+
static struct snd_soc_card imx_phycore = {
.name = PhyCORE-ac97-audio,
.owner = THIS_MODULE,
@@ -45,40 +51,52 @@ static struct snd_soc_card imx_phycore = {
.num_links = ARRAY_SIZE(imx_phycore_dai_ac97),
};
-static struct platform_device *imx_phycore_snd_ac97_device;
+static void phycore_ac97_imx21_audmux(void)
+{
+ imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
+ IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+ IMX_AUDMUX_V1_PCR_TFCSEL(3) |
+ IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
Re: [PATCH v6 03/10] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
On Tue, May 28, 2013 at 04:47:51PM +0200, Markus Pargmann wrote: @@ -47,7 +56,8 @@ static inline void imx_pcm_dma_exit(struct platform_device *pdev) #endif #ifdef CONFIG_SND_SOC_IMX_PCM_FIQ -int imx_pcm_fiq_init(struct platform_device *pdev); +int imx_pcm_fiq_init(struct platform_device *pdev, + struct imx_pcm_fiq_params *params); void imx_pcm_fiq_exit(struct platform_device *pdev); #else static inline int imx_pcm_fiq_init(struct platform_device *pdev) This one also needs update with a new parameter. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/6] drivers: bus: add a new driver for WEIM
Hi Arnd, On Tue, May 28, 2013 at 02:20:07PM +0800, Huang Shijie wrote: The WEIM(Wireless External Interface Module) works like a bus. You can attach many different devices on it, such as NOR, onenand. In the case of i.MX6q-sabreauto, the NOR is connected to WEIM. This patch also adds the devicetree binding document. The driver only works when the devicetree is enabled. Signed-off-by: Huang Shijie b32...@freescale.com --- Documentation/devicetree/bindings/bus/imx-weim.txt | 49 +++ drivers/bus/Kconfig|9 ++ drivers/bus/Makefile |1 + drivers/bus/imx-weim.c | 138 What's the general merge path for drivers/bus/ ones? It's not clear to me who is collecting those drivers/bus/ patches. Shawn 4 files changed, 197 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt create mode 100644 drivers/bus/imx-weim.c ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/6] drivers: bus: add a new driver for WEIM
On Fri, May 24, 2013 at 05:59:19PM +0800, Huang Shijie wrote:
+Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
+
+ weim: weim@021b8000 {
+ compatible = fsl,imx6q-weim;
+ reg = 0x021b8000 0x4000;
+ clocks = clks 196;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x0800;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x0200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+
Nit: remove this unneeded blank line.
+ fsl,weim-cs-timing = 0x00620081 0x0001 0x1C022000
+ 0xC000 0x1404a38e 0x;
Nit: please consistently use lower case for hex value.
Please update patch #6 as well.
Other than that,
Reviewed-by: Shawn Guo shawn@linaro.org
+ };
+ };
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 4/6] ARM: dts: imx6q: add pinctrls for WEIM NOR
On Fri, May 24, 2013 at 05:59:22PM +0800, Huang Shijie wrote:
Add two pinctrls for WEIM:
one for the weim nor, another for the chipselect.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6q.dtsi | 61
++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index ed11bcf..7c5bcf4 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -323,6 +323,67 @@
;
};
};
+
+ weim {
+ pinctrl_weim_cs_0: weim_norgrp-1 {
To follow the naming pattern, the ones below are probably better.
pinctrl_weim_cs0_1: weimcs0grp-1
+ fsl,pins =
+
MX6Q_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
+ ;
Nit: fix the indention please.
+ };
+
+ pinctrl_weim_nor_1: weim_norgrp-2 {
s/weim_norgrp-2/weimnorgrp-1
+ fsl,pins =
+
MX6Q_PAD_EIM_OE__EIM_OE_B 0xb0b1
+ MX6Q_PAD_EIM_RW__EIM_RW
0xb0b1
+
MX6Q_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
+
Nit: Remove this blank line.
+ /* data */
+
MX6Q_PAD_EIM_D16__EIM_DATA16 0xb0b1
+
MX6Q_PAD_EIM_D17__EIM_DATA17 0xb0b1
+
MX6Q_PAD_EIM_D18__EIM_DATA18 0xb0b1
+
MX6Q_PAD_EIM_D19__EIM_DATA19 0xb0b1
+
MX6Q_PAD_EIM_D20__EIM_DATA20 0xb0b1
+
MX6Q_PAD_EIM_D21__EIM_DATA21 0xb0b1
+
MX6Q_PAD_EIM_D22__EIM_DATA22 0xb0b1
+
MX6Q_PAD_EIM_D23__EIM_DATA23 0xb0b1
+
MX6Q_PAD_EIM_D24__EIM_DATA24 0xb0b1
+
MX6Q_PAD_EIM_D25__EIM_DATA25 0xb0b1
+
MX6Q_PAD_EIM_D26__EIM_DATA26 0xb0b1
+
MX6Q_PAD_EIM_D27__EIM_DATA27 0xb0b1
+
MX6Q_PAD_EIM_D28__EIM_DATA28 0xb0b1
+
MX6Q_PAD_EIM_D29__EIM_DATA29 0xb0b1
+
MX6Q_PAD_EIM_D30__EIM_DATA30 0xb0b1
+
MX6Q_PAD_EIM_D31__EIM_DATA31 0xb0b1
+
Ditto
Above comments apply on the next patch as well.
Shawn
+ /* address */
+
MX6Q_PAD_EIM_A23__EIM_ADDR23 0xb0b1
+
MX6Q_PAD_EIM_A22__EIM_ADDR22 0xb0b1
+
MX6Q_PAD_EIM_A21__EIM_ADDR21 0xb0b1
+
MX6Q_PAD_EIM_A20__EIM_ADDR20 0xb0b1
+
MX6Q_PAD_EIM_A19__EIM_ADDR19 0xb0b1
+
MX6Q_PAD_EIM_A18__EIM_ADDR18 0xb0b1
+
MX6Q_PAD_EIM_A17__EIM_ADDR17 0xb0b1
+
MX6Q_PAD_EIM_A16__EIM_ADDR16 0xb0b1
+
MX6Q_PAD_EIM_DA15__EIM_AD15 0xb0b1
+
MX6Q_PAD_EIM_DA14__EIM_AD14 0xb0b1
+
MX6Q_PAD_EIM_DA13__EIM_AD13 0xb0b1
+
MX6Q_PAD_EIM_DA12__EIM_AD12 0xb0b1
+
MX6Q_PAD_EIM_DA11__EIM_AD11 0xb0b1
+
MX6Q_PAD_EIM_DA10__EIM_AD10 0xb0b1
+
MX6Q_PAD_EIM_DA9__EIM_AD09 0xb0b1
+
MX6Q_PAD_EIM_DA8__EIM_AD08 0xb0b1
+
MX6Q_PAD_EIM_DA7__EIM_AD07 0xb0b1
+
Re: [PATCH 1/6] drivers: bus: add a new driver for WEIM
On Mon, May 20, 2013 at 04:48:57PM +0800, Huang Shijie wrote:
The WEIM(Wireless External Interface Module) works like a bus.
You can attach many different devices on it, such as NOR, onenand.
In the case of i.MX6q-sabreauto, the NOR is connected to WEIM.
This patch also adds the devicetree binding document.
The driver only works when the devicetree is enabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
Documentation/devicetree/bindings/bus/imx-weim.txt | 69 +
drivers/bus/Kconfig|9 ++
drivers/bus/Makefile |1 +
drivers/bus/imx-weim.c | 145
4 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt
create mode 100644 drivers/bus/imx-weim.c
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt
b/Documentation/devicetree/bindings/bus/imx-weim.txt
new file mode 100644
index 000..9913454
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -0,0 +1,69 @@
+Device tree bindings for i.MX Wireless External Interface Module (WEIM)
+
+The term ???wireless??? does not imply that the WEIM is literally an
interface
wireless
+without wires. It simply means that this module was originally designed for
+wireless and mobile applications that use low-power technology.
+
+The actual devices are instantiated from the child nodes of a WEIM node.
+But now we only have the NOR device.
+
+NOR flash connected to the WEIM (found on i.MX boards) are represented as
+child nodes with a name of nor.
I doubt that WEIM should care the particular device type connected on
it.
+
+Required properties:
+
+ - compatible: Should be set to fsl, imx6q-weim
Drop the space in middle of compatible string.
+ - reg: A resource specifier for the register space
+ (see the example below)
+ - interrupts: the interrupt number, see the example below.
+ - clocks: the clock, see the example below.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells: Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+cs-number 0 physical address of mapping size
+
+Timing properties for child nodes. All are mandatory, not optional.
+
+ -weim-cs-index: The CS index which the device is attaching on.
It seems we can find it out from reg property, so that we can save
this property?
+ -weim-cs-timing:The timing array, contains 6 timing values for the
+ weim-cs-index.
This is a vendor specific property, and should have a vendor (fsl)
perfix. Also please put a space after the first - which acts as
a bullet symbol here.
+
+Example for an i.MX6q-sabreauto board:
You can write it as i.MX6Q SABRE Auto or imx6q-sabreauto.
+ weim: weim@021b8000 {
+ compatible = fsl,imx6q-weim;
+ reg = 0x021b8000 0x4000;
+ interrupts = 0 14 0x04;
+ clocks = clks 196;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x0800;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x0200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+
+ weim-cs-index = 0;
+ weim-cs-timing = 0x00620081 0x0001 0x1C022000
+ 0xC000 0x1404a38e 0x;
+ partition@0 {
+ label = U-Boot;
+ reg = 0x0 0x4;
+ };
+
+ partition@4 {
+ label = U-Boot-ENV;
+ reg = 0x4 0x1;
+ read-only;
+ };
+
+ partition@5 {
+ label = Kernel;
+ reg = 0x5 0x3b;
+ };
+ };
+ };
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b05ecab..0f997af 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -4,6 +4,15 @@
menu Bus devices
+config IMX_WEIM
+ tristate Freescale EIM DRIVER
+ depends on ARCH_MXC MTD_PHYSMAP_OF
I do not see how this driver depends on MTD_PHYSMAP_OF.
+ help
+ Driver for i.MX6 WEIM controller.
+ The WEIM(Wireless External Interface Module) works like a bus.
+ You can attach many different devices on it, such as NOR, onenand.
+
Re: [PATCH 2/6] ARM: dts: imx6q{dl}: fix the pin conflict between SPI and WEIM
On Mon, May 20, 2013 at 04:48:58PM +0800, Huang Shijie wrote:
In the imx6q-sabreauto and imx6dl-sabreauto boards,
the pin MX6Q{DL}_PAD_EIM_D19 is used as a GPIO for SPI NOR, but
it is used as a data pin for the WEIM NOR.
In order to fix the conflict, this patch removes the pin from the hog,
and adds a new pinctrl item: pinctrl_ecspi1_2.
The SPI NOR selects this pinctrl_ecspi1_2 when it is enabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6dl-sabreauto.dts |9 -
arch/arm/boot/dts/imx6q-sabreauto.dts|9 -
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |2 +-
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabreauto.dts
b/arch/arm/boot/dts/imx6dl-sabreauto.dts
index 60f3038..7695f70 100644
--- a/arch/arm/boot/dts/imx6dl-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6dl-sabreauto.dts
@@ -25,7 +25,14 @@
fsl,pins =
MX6DL_PAD_NANDF_CS2__GPIO6_IO15 0x8000
MX6DL_PAD_SD2_DAT2__GPIO1_IO13 0x8000
- MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
+ ;
+ };
+ };
+
+ ecspi1 {
+ pinctrl_ecspi1_2: ecspi1grp-2 {
The naming sounds like another ecspi1 pin groups beside
pinctrl_ecspi1_1, both of which should be ecspi1 pin groups defined by
SoC. Please encode the board name in there to suggest this is a board
specific pin setup for ecspi1, something like pinctrl_ecspi1_sabreauto.
Shawn
+ fsl,pins =
+ MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
;
};
};
diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dts
b/arch/arm/boot/dts/imx6q-sabreauto.dts
index 9fb3e99..67a3a6b 100644
--- a/arch/arm/boot/dts/imx6q-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6q-sabreauto.dts
@@ -29,7 +29,14 @@
fsl,pins =
MX6Q_PAD_NANDF_CS2__GPIO6_IO15 0x8000
MX6Q_PAD_SD2_DAT2__GPIO1_IO13 0x8000
- MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
+ ;
+ };
+ };
+
+ ecspi1 {
+ pinctrl_ecspi1_2: ecspi1grp-2 {
+ fsl,pins =
+ MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
;
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index d6baa51..eb293f5 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -20,7 +20,7 @@
fsl,spi-num-chipselects = 1;
cs-gpios = gpio3 19 0;
pinctrl-names = default;
- pinctrl-0 = pinctrl_ecspi1_1;
+ pinctrl-0 = pinctrl_ecspi1_1 pinctrl_ecspi1_2;
status = disabled; /* pin conflict with WEIM NOR */
flash: m25p80@0 {
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/7] ARM: i.MX53: dts: add Ka-Ro tx53
On Wed, Apr 24, 2013 at 11:41:19AM +0200, Steffen Trumtrar wrote: Hi! This series adds a dtsi for the Ka-Ro TX53 System-On-Module and all necessary pinctrls that are not already in the imx53.dtsi. I tested this on 3.9-rc8 with a custom baseboard, but rebased everything to Shawns imx/dt-3.11, which I presume is the correct base for future dts. Regards, Steffen Steffen Trumtrar (7): ARM: i.MX53: add audmux pinctrl ARM: i.MX53: add csi pinctrl ARM: i.MX53: add ecspi pinctrl ARM: i.MX53: add pwm2 pinctrl ARM: i.MX53: add uart1 pinctrl ARM: i.MX53: add uart2 pinctrl ARM: dts: add Ka-Ro tx53 devicetree All applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 01/10] ASoC: phycore-ac97: Add DT support
On Wed, Apr 24, 2013 at 09:45:40PM +0200, Sascha Hauer wrote:
Hi Markus,
On Wed, Apr 24, 2013 at 04:36:30PM +0200, Markus Pargmann wrote:
Add devicetree support for this audio soc fabric driver.
@@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
.stream_name= HiFi,
.codec_dai_name = wm9712-hifi,
.codec_name = wm9712-codec,
+#ifdef CONFIG_MACH_IMX27_DT
+ .platform_name = imx-fiq-pcm-audio,
+#else
.cpu_dai_name = imx-ssi.0,
.platform_name = imx-fiq-pcm-audio.0,
+#endif
This doesn't work properly. Compiling the kernel with IMX27_DT enabled
does not necessarily mean that it also started with dt support.
Right, we should run-time check pdev-dev.of_node to see if it's a DT
boot and set .platform_of_node rather than .platform_name if it is. But
it's only possible with the cleanup series ASoC: fsl: imx-pcm driver
cleanup I just sent being the base. I hope you can rebase your series
on that :)
Shawn
Personally I am fine with removing platform based support for this
driver if it's too much effort to fix it properly, but we shouldn't
start working with ifdefs here.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 07/10] ASoC: fsl-ssi: imx ac97 support
On Wed, Apr 24, 2013 at 04:36:36PM +0200, Markus Pargmann wrote:
+/*
+ * Pointer to AC97 reset functions for specific boards
+ */
+#if IS_ENABLED(CONFIG_MACH_PCA100)
+extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+#if IS_ENABLED(CONFIG_MACH_PCM043)
+extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
...
@@ -717,13 +956,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
strcpy(ssi_private-name, p);
- /* Initialize this copy of the CPU DAI driver structure */
- memcpy(ssi_private-cpu_dai_drv, fsl_ssi_dai_template,
-sizeof(fsl_ssi_dai_template));
- ssi_private-cpu_dai_drv.name = ssi_private-name;
-
ssi_private-use_dma = !of_property_read_bool(np, fsl,imx-fiq);
+ if (ac97) {
+ sprop = of_get_property(of_find_node_by_path(/), compatible,
+ NULL);
+ p = strrchr(sprop, ',');
+ if (p)
+ sprop = p + 1;
+
+ if (!strcmp(sprop, imx27-pca100)) {
+ ssi_private-ac97_reset = pca100_ac97_cold_reset;
+ ssi_private-ac97_warm_reset = pca100_ac97_warm_reset;
+ } else if (!strcmp(sprop, imx27-pcm043)) {
+ ssi_private-ac97_reset = pcm043_ac97_cold_reset;
+ ssi_private-ac97_warm_reset = pcm043_ac97_warm_reset;
+ } else {
+ dev_err(pdev-dev, Failed to enable ssi AC97 mode,
unknown board.\n);
+ ret = -EINVAL;
+ goto error_kmalloc;
+ }
I do not like these board specific hooks show up in an IP driver
in such way. Can we work it out in other ways, notification or even
platform_data with auxdata?
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 07/17] ARM: dts: imx: cpus/cpu nodes dts updates
On Wed, Apr 24, 2013 at 06:28:12PM +0100, Lorenzo Pieralisi wrote:
This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/boot/dts/imx23.dtsi | 8 ++--
arch/arm/boot/dts/imx28.dtsi | 8 ++--
arch/arm/boot/dts/imx6dl.dtsi | 2 ++
arch/arm/boot/dts/imx6q.dtsi | 1 +
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 56afcf4..0aae18b 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,8 +23,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..07f131fc 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,8 +32,12 @@
};
cpus {
- cpu@0 {
- compatible = arm,arm926ejs;
+ #address-cells = 0;
+ #size-cells = 0;
+
+ cpu {
+ compatible = arm,arm926ej-s;
+ device_type = cpu;
};
};
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 63fafe2..b76d85e 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -16,12 +16,14 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 0;
next-level-cache = L2;
};
cpu@1 {
compatible = arm,cortex-a9;
+ device_type = cpu;
reg = 1;
next-level-cache = L2;
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index cba021e..65c1b62 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -17,6 +17,7 @@
cpu@0 {
compatible = arm,cortex-a9;
+ device_type = cpu;
Shouldn't this line be added for cpu@1, cpu@2 and cpu@3 too? Other than
that,
Acked-by: Shawn Guo shawn@linaro.org
reg = 0;
next-level-cache = L2;
operating-points =
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 05/13] ARM: mach-imx: cpus/cpu nodes dts updates
On Mon, Apr 22, 2013 at 04:27:27PM +0100, Lorenzo Pieralisi wrote:
This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Acked-by: Shawn Guo shawn@linaro.org
---
arch/arm/boot/dts/imx23.dtsi | 2 +-
arch/arm/boot/dts/imx28.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 56afcf4..d98330c 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -24,7 +24,7 @@
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..8c5a3ba 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -33,7 +33,7 @@
cpus {
cpu@0 {
- compatible = arm,arm926ejs;
+ compatible = arm,arm926;
};
};
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND v5 0/2] dma: imx-dma: OFTree support
On Thu, Apr 18, 2013 at 03:21:36PM +0200, Markus Pargmann wrote: Markus Pargmann (2): dma: imx-dma: Add oftree support DMA: imx-dma: imxdma-dev used uninitialized Both, Reviewed-by: Shawn Guo shawn@linaro.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] i2c: imx: use of_alias_get_id to order i2c devices
On Tue, Apr 09, 2013 at 07:09:39PM +0200, Philipp Zabel wrote:
This allows to order i2c character devices as they are numbered
in the reference manual, instead of ordering them by register
base address.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
I'm fine with the patch, but let's see if DT maintainers have an
opinion.
Shawn
---
drivers/i2c/busses/i2c-imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 82f20c6..e5a3f08 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -488,6 +488,7 @@ static struct i2c_algorithm i2c_imx_algo = {
static int __init i2c_imx_probe(struct platform_device *pdev)
{
+ struct device_node *np = pdev-dev.of_node;
const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
pdev-dev);
struct imx_i2c_struct *i2c_imx;
@@ -531,7 +532,7 @@ static int __init i2c_imx_probe(struct platform_device
*pdev)
i2c_imx-adapter.owner = THIS_MODULE;
i2c_imx-adapter.algo = i2c_imx_algo;
i2c_imx-adapter.dev.parent = pdev-dev;
- i2c_imx-adapter.nr = pdev-id;
+ i2c_imx-adapter.nr = (pdev-id 0) ? of_alias_get_id(np,
i2c) : pdev-id;
i2c_imx-adapter.dev.of_node= pdev-dev.of_node;
i2c_imx-base = base;
--
1.8.2.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] i.MX53 TVE clock patches
On Mon, Apr 08, 2013 at 04:46:18PM +0200, Philipp Zabel wrote: Hi, the first two are just cleanups, the following three patches are changes to the i.MX53 clock tree that are necessary to use the TVEv2 module as VGA output on the Freescale i.MX53-QSB or TQ MBa53 boards. regards Philipp --- Documentation/devicetree/bindings/clock/imx5-clock.txt | 1 - arch/arm/mach-imx/clk-imx51-imx53.c| 17 - 2 files changed, 8 insertions(+), 10 deletions(-) All 5 patches applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] staging: drm/imx: Add support for Television Encoder (TVEv2)
On Mon, Apr 08, 2013 at 06:04:38PM +0200, Philipp Zabel wrote: This driver adds support for the Television Encoder integrated on i.MX53 SoCs (TVEv2). Currently only the VGA output mode is supported, which only uses the TVDAC to generate RGB levels. HSYNC and VSYNC signals are routed directly from the IPU signal generator pins through IOMUXC. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/staging/imx-drm/Kconfig | 7 + drivers/staging/imx-drm/Makefile | 1 + drivers/staging/imx-drm/imx-tve.c | 755 ++ 3 files changed, 763 insertions(+) create mode 100644 drivers/staging/imx-drm/imx-tve.c Bindings doc is missing. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: dts: Add NFC support for i.MX27 Phytec PCM038 module
On Sun, Apr 07, 2013 at 07:29:12PM +0400, Alexander Shiyan wrote:
Added NFC node to imx27-phytec-phycore DT file.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
Applied, thanks.
---
arch/arm/boot/dts/imx27-phytec-phycore.dtsp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
index 924097a..7228153 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
+++ b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
@@ -71,3 +71,9 @@
#size-cells = 1;
};
};
+
+nfc {
+ nand-bus-width = 8;
+ nand-ecc-mode = hw;
+ status = okay;
+};
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: dts: Add SPI support for i.MX27 Phytec PCM038 module
On Sun, Apr 07, 2013 at 07:29:13PM +0400, Alexander Shiyan wrote:
Added SPI node to imx27-phytec-phycore DT file.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
arch/arm/boot/dts/imx27-phytec-phycore.dtsp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
index 7228153..354dc77 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
+++ b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
@@ -77,3 +77,9 @@
nand-ecc-mode = hw;
status = okay;
};
+
+cspi1 {
+ fsl,spi-num-chipselects = 1;
+ cs-gpios = gpio4 28 0;
+ status = okay;
+};
I would suggest these codes be sorted in alphabet order of label name.
IOW, cspi1 should be put before nfc.
Shawn
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: dts: Add missing imx27-phytec-phycore dtb target
On Sun, Apr 07, 2013 at 07:29:14PM +0400, Alexander Shiyan wrote: The patch adds missing imx27-phytec-phycore dtb target into Makefile. Signed-off-by: Alexander Shiyan shc_w...@mail.ru Applied, thanks. --- arch/arm/boot/dts/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 35976f0..a06d9f1 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += \ imx27-apf27.dtb \ imx27-apf27dev.dtb \ imx27-pdk.dtb \ + imx27-phytec-phycore.dtb \ imx31-bug.dtb \ imx51-apf51.dtb \ imx51-apf51dev.dtb \ -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: imx51 cpu node
On Sun, Apr 07, 2013 at 09:56:45PM +0200, Markus Pargmann wrote: This patch adds a cpus/cpu@0 node for imx51 with default operating points for the cpufreq-cpu0 driver. There is currently no regulator support, so the voltages are 0 here. Signed-off-by: Markus Pargmann m...@pengutronix.de Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [GIT PULL] dt: run C pre-processor on *.dts, create some standard headers
On Fri, Apr 05, 2013 at 12:46:50PM -0600, Stephen Warren wrote: Rob, it might be worth keeping this in a separate branch in linux-next so you can pull it out if it causes any issues. I've been using these patches for quite a while now, but there's always opportunity for surprises on architectures I don't use. I did just fix a bug when building with O= a few days back, hence the V2 that I posted as patches. This branch enhances the support for running dtc on device tree files. A dedicated directory is created for header files that provide constants for device-tree bindings. The kbuild dependency script processor is enhanced to support processing the dependency outputs from multiple separate commands at once. The kbuild dtc rule is modified so that the C pre-processor is always applied when compiling any device tree. Some standard headers are created which define common constants for GPIO, IRQ, and ARM GIC device tree bindings. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers I just rebuilt my imx/dt branch based on this to avoid all those dts files renaming. So regardless of the path it goes to mainline, I will need it as a dependency in arm-soc tree. Shawn for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda3ca3: ARM: dt: create a DT header for the GIC Stephen Warren (7): kbuild: create an include chroot for DT bindings kbuild: fixdep: support concatenated dep files kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp ARM: dt: add header to define GPIO flags ARM: dt: add header to define IRQ flags ARM: dt: create a DT header for the GIC arch/arm/boot/dts/include/dt-bindings |1 + include/dt-bindings/gpio/gpio.h | 15 +++ .../dt-bindings/interrupt-controller/arm-gic.h | 22 + include/dt-bindings/interrupt-controller/irq.h | 19 scripts/Makefile.lib| 17 ++-- scripts/basic/fixdep.c | 93 -- 6 files changed, 125 insertions(+), 42 deletions(-) create mode 12 arch/arm/boot/dts/include/dt-bindings create mode 100644 include/dt-bindings/gpio/gpio.h create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h create mode 100644 include/dt-bindings/interrupt-controller/irq.h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/8] Reset controller API to reset IP modules on i.MX5 and i.MX6
On Thu, Mar 28, 2013 at 05:35:15PM +0100, Philipp Zabel wrote: The system reset controller (SRC) on i.MX51, i.MX53, and i.MX6q controls reset lines to the GPU, VPU, IPU, and OpenVG IP modules. The following patches add a simple API for devices to request being reset by separate reset controller hardware and implements the reset signal device tree binding proposed by Stephen Warren. Contrary to Tegra hardware, the i.MX SRC contains self-deasserting reset registers, so I've included both ops to manually assert/deassert a reset line, as well as a reset operation that is supposed to assert the reset line and wait for it to deassert. The i.MX SRC is enhanced to provide a reset controller and the IPU driver is made to request being reset by calling the device_reset(pdev-dev) convenience wrapper during probing. No changes since v5, I just reordered the series. All applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/8] Reset controller API to reset IP modules on i.MX5 and i.MX6
On Thu, Mar 28, 2013 at 10:07:54PM +, Arnd Bergmann wrote: On Thursday 28 March 2013, Philipp Zabel wrote: [Added Arnd and Greg to the recipients] I think the first three patches of this series are candidates to go through Arnd's tree. Arnd, would you take those patches? [PATCH v6 1/8] dt: describe base reset signal binding [PATCH v6 2/8] reset: Add reset controller API [PATCH v6 3/8] reset: Add driver for gpio-controlled reset pins Wow, very nice work. I had completely missed the series so far, as I'm quite behind on reading mailing lists. Yes, I can certainly take the three patches through arm-soc. Actually I just handed over to Olof for now, but I'm assume he will also take them when you send a pull request. We also have at least one other platform (sirf/prima2) that will need the subsystem in the near future. I'm probably stating the obvious here, but please make sure that the pull request you send for arm-soc uses the exact git sha1 IDs that will be used for the follow-on patches going through the platform trees. Ok, let me maintain a stable branch on IMX tree and forward the patches to arm-soc, since the other patches in the series that I need to handle will depend on the branch anyway. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] pinctrl: pinctrl-mxs: document the missing pull-ups
On Sat, Mar 30, 2013 at 12:51:12AM +0100, Alexandre Belloni wrote:
Some pins on the i.mx23 and i.mx28 are missing pull-ups, document that
oddity because it was difficult to know the expected behaviour.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
Applied, thanks.
---
I don't think it is necessary to list the pins with the missing pull ups in
that file but we may want to explicitly direct to the datasheet as even with
the same chip, it can depend on the package (BGA or QFP for example).
Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt |4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
index f7e8e8f..3077370 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
@@ -70,6 +70,10 @@ Optional subnode-properties:
0: Disable the internal pull-up
1: Enable the internal pull-up
+Note that when enabling the pull-up, the internal pad keeper gets disabled.
+Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
+will only disable the internal pad keeper.
+
Examples:
pinctrl@80018000 {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/11] LVDS Display Bridge support for i.MX
On Thu, Mar 28, 2013 at 04:23:24PM +0100, Philipp Zabel wrote: Hi, the following patches add support for LVDS displays on i.MX53 and i.MX6q boards. I have reordered the patches, as Shawn has already applied the now first five patches. I do not think you need to necessarily resend the patches that have already been applied. BTW, I applied ARM i.MX53: Add IOMUXC GPR to device tree as well last night. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/11] LVDS Display Bridge support for i.MX
On Thu, Mar 28, 2013 at 04:23:24PM +0100, Philipp Zabel wrote: Hi, the following patches add support for LVDS displays on i.MX53 and i.MX6q boards. I have reordered the patches, as Shawn has already applied the now first five patches. Just applied patches #7, #8 and #11. #9 and #10 were applied yesterday actually. So all ARM: patches are applied. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 01/11] staging: drm/imx: Add LDB support
On Wed, Mar 27, 2013 at 06:30:35PM +0100, Philipp Zabel wrote: +config DRM_IMX_LDB + tristate Support for LVDS displays + help + Choose this to enable the internal LVDS Display Bridge (LDB) + found on i.MX53 and i.MX6 processors. + depends on DRM_IMX + Shouldn't we select OF_VIDEOMODE here, since of_get_drm_display_mode() is called there. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 02/11] ARM i.MX5: Move IPU clock lookups into device tree
On Wed, Mar 27, 2013 at 06:30:36PM +0100, Philipp Zabel wrote:
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Applied, thanks.
---
arch/arm/boot/dts/imx51.dtsi| 2 ++
arch/arm/boot/dts/imx53.dtsi| 2 ++
arch/arm/mach-imx/clk-imx51-imx53.c | 7 ---
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index fcf035b..e9480b8 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -67,6 +67,8 @@
compatible = fsl,imx51-ipu;
reg = 0x4000 0x2000;
interrupts = 11 10;
+ clocks = clks 59, clks 110, clks 61;
+ clock-names = bus, di0, di1;
};
aips@7000 { /* AIPS1 */
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index d05aa21..7a6f5a8 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -72,6 +72,8 @@
compatible = fsl,imx53-ipu;
reg = 0x1800 0x08000;
interrupts = 11 10;
+ clocks = clks 59, clks 110, clks 61;
+ clock-names = bus, di0, di1;
};
aips@5000 { /* AIPS1 */
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 0f39f8c..d22ee6a 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -362,9 +362,6 @@ int __init mx51_clocks_init(unsigned long rate_ckil,
unsigned long rate_osc,
clk_register_clkdev(clk[mx51_mipi], mipi_hsp, NULL);
clk_register_clkdev(clk[vpu_gate], NULL, imx51-vpu.0);
clk_register_clkdev(clk[fec_gate], NULL, imx27-fec.0);
- clk_register_clkdev(clk[ipu_gate], bus, 4000.ipu);
- clk_register_clkdev(clk[ipu_di0_gate], di0, 4000.ipu);
- clk_register_clkdev(clk[ipu_di1_gate], di1, 4000.ipu);
clk_register_clkdev(clk[usb_phy_gate], phy, mxc-ehci.0);
clk_register_clkdev(clk[esdhc1_ipg_gate], ipg, sdhci-esdhc-imx51.0);
clk_register_clkdev(clk[dummy], ahb, sdhci-esdhc-imx51.0);
@@ -471,10 +468,6 @@ int __init mx53_clocks_init(unsigned long rate_ckil,
unsigned long rate_osc,
clk_register_clkdev(clk[vpu_gate], NULL, imx53-vpu.0);
clk_register_clkdev(clk[i2c3_gate], NULL, imx21-i2c.2);
clk_register_clkdev(clk[fec_gate], NULL, imx25-fec.0);
- clk_register_clkdev(clk[ipu_gate], bus, 1800.ipu);
- clk_register_clkdev(clk[ipu_di0_gate], di0, 1800.ipu);
- clk_register_clkdev(clk[ipu_di1_gate], di1, 1800.ipu);
- clk_register_clkdev(clk[ipu_gate], hsp, 1800.ipu);
clk_register_clkdev(clk[usb_phy1_gate], usb_phy1, mxc-ehci.0);
clk_register_clkdev(clk[esdhc1_ipg_gate], ipg, sdhci-esdhc-imx53.0);
clk_register_clkdev(clk[dummy], ahb, sdhci-esdhc-imx53.0);
--
1.8.2.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 03/11] ARM i.MX6q: export imx6q_revision
On Wed, Mar 27, 2013 at 06:30:37PM +0100, Philipp Zabel wrote:
So it can be used in clk-imx6q.c for revision dependent clock tree setup.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Applied, thanks.
---
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/mach-imx6q.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 5a800bf..6c909d1 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -74,6 +74,7 @@ extern void mxc_set_cpu_type(unsigned int type);
extern void mxc_restart(char, const char *);
extern void mxc_arch_reset_init(void __iomem *);
extern int mx53_revision(void);
+extern int imx6q_revision(void);
extern int mx53_display_revision(void);
extern void imx_set_aips(void __iomem *);
extern int mxc_device_init(void);
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 9ffd103..ca10acc 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -41,7 +41,7 @@
#define IMX6Q_ANALOG_DIGPROG 0x260
-static int imx6q_revision(void)
+int imx6q_revision(void)
{
struct device_node *np;
void __iomem *base;
--
1.8.2.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 04/11] ARM i.MX6q: Add audio/video PLL post dividers for i.MX6q rev 1.1
On Wed, Mar 27, 2013 at 06:30:38PM +0100, Philipp Zabel wrote:
Query silicon revision to determine clock tree and add post
dividers for newer revisions.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/mach-imx/clk-imx6q.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 2f9ff93..fbab4a9 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -22,6 +22,7 @@
#include clk.h
#include common.h
+#include hardware.h
#define CCGR00x68
#define CCGR10x6c
@@ -109,29 +110,32 @@ static const char *periph_clk2_sels[] = {
pll3_usb_otg, osc, };
static const char *periph_sels[] = { periph_pre, periph_clk2, };
static const char *periph2_sels[]= { periph2_pre, periph2_clk2, };
static const char *axi_sels[]= { periph, pll2_pfd2_396m,
pll3_pfd1_540m, };
-static const char *audio_sels[] = { pll4_audio, pll3_pfd2_508m,
pll3_pfd3_454m, pll3_usb_otg, };
+static const char *audio_sels[] = { pll4_test_div, pll3_pfd2_508m,
pll3_pfd3_454m, pll3_usb_otg, };
static const char *gpu_axi_sels[]= { axi, ahb, };
static const char *gpu2d_core_sels[] = { axi, pll3_usb_otg,
pll2_pfd0_352m, pll2_pfd2_396m, };
static const char *gpu3d_core_sels[] = { mmdc_ch0_axi, pll3_usb_otg,
pll2_pfd1_594m, pll2_pfd2_396m, };
static const char *gpu3d_shader_sels[] = { mmdc_ch0_axi, pll3_usb_otg,
pll2_pfd1_594m, pll2_pfd9_720m, };
static const char *ipu_sels[]= { mmdc_ch0_axi,
pll2_pfd2_396m, pll3_120m, pll3_pfd1_540m, };
-static const char *ldb_di_sels[] = { pll5_video, pll2_pfd0_352m,
pll2_pfd2_396m, mmdc_ch1_axi, pll3_pfd1_540m, };
-static const char *ipu_di_pre_sels[] = { mmdc_ch0_axi, pll3_usb_otg,
pll5_video, pll2_pfd0_352m, pll2_pfd2_396m, pll3_pfd1_540m, };
+static const char *ldb_di_sels[] = { pll5_control3, pll2_pfd0_352m,
pll2_pfd2_396m, mmdc_ch1_axi, pll3_pfd1_540m, };
+static const char *ipu_di_pre_sels[] = { mmdc_ch0_axi, pll3_usb_otg,
pll5_control3, pll2_pfd0_352m, pll2_pfd2_396m, pll3_pfd1_540m, };
static const char *ipu1_di0_sels[] = { ipu1_di0_pre, dummy, dummy,
ldb_di0, ldb_di1, };
static const char *ipu1_di1_sels[] = { ipu1_di1_pre, dummy, dummy,
ldb_di0, ldb_di1, };
static const char *ipu2_di0_sels[] = { ipu2_di0_pre, dummy, dummy,
ldb_di0, ldb_di1, };
static const char *ipu2_di1_sels[] = { ipu2_di1_pre, dummy, dummy,
ldb_di0, ldb_di1, };
static const char *hsi_tx_sels[] = { pll3_120m, pll2_pfd2_396m, };
static const char *pcie_axi_sels[] = { axi, ahb, };
-static const char *ssi_sels[]= { pll3_pfd2_508m,
pll3_pfd3_454m, pll4_audio, };
+static const char *ssi_sels[]= { pll3_pfd2_508m,
pll3_pfd3_454m, pll4_test_div, };
static const char *usdhc_sels[] = { pll2_pfd2_396m, pll2_pfd0_352m,
};
static const char *enfc_sels[] = { pll2_pfd0_352m, pll2_bus,
pll3_usb_otg, pll2_pfd2_396m, };
static const char *emi_sels[]= { axi, pll3_usb_otg,
pll2_pfd2_396m, pll2_pfd0_352m, };
static const char *vdo_axi_sels[]= { axi, ahb, };
static const char *vpu_axi_sels[]= { axi, pll2_pfd2_396m,
pll2_pfd0_352m, };
-static const char *cko1_sels[] = { pll3_usb_otg, pll2_bus,
pll1_sys, pll5_video,
+static const char *cko1_sels[] = { pll3_usb_otg, pll2_bus,
pll1_sys, pll5_control3,
dummy, axi, enfc, ipu1_di0,
ipu1_di1, ipu2_di0,
- ipu2_di1, ahb, ipg, ipg_per,
ckil, pll4_audio, };
+ ipu2_di1, ahb, ipg, ipg_per,
ckil, pll4_test_div, };
+
+static struct clk_div_table test_div_table[] = { { 2, 1 }, { 1, 2 }, { 0, 4
}, { 0, 0 }, };
+static struct clk_div_table control3_table[] = { { 0, 1 }, { 1, 2 }, { 3, 4
}, { 0, 0 }, };
Please rewrite the tables in the way how clk_enet_ref_table is written.
Also, why { 0, 0 } at the end of both tables?
enum mx6q_clks {
dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
@@ -165,7 +169,7 @@ enum mx6q_clks {
pll4_audio, pll5_video, pll8_mlb, pll7_usb_host, pll6_enet, ssi1_ipg,
ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5,
ldb_di1_div_3_5,
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
usbphy1_gate,
- usbphy2_gate, clk_max
+ usbphy2_gate, pll4_test_div, pll5_test_div, pll5_control3, clk_max
};
static struct clk *clk[clk_max];
@@ -208,6 +212,14 @@ int __init mx6q_clocks_init(void)
base = of_iomap(np, 0);
WARN_ON(!base);
+ /* Audio/video PLL post dividers do not work on i.MX6q revision 1.0 */
+ if (imx6q_revision() == IMX_CHIP_REVISION_1_0) {
+ test_div_table[1].div = 1;
+
Re: [PATCH v2 10/11] ARM i.MX53: Add LDB device to device tree
On Wed, Mar 27, 2013 at 07:43:40PM +0100, Martin Fuzzey wrote:
On 27/03/13 18:30, Philipp Zabel wrote:
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/boot/dts/imx53.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index b07bbdcc..30aed40 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -511,6 +511,33 @@
reg = 0x53fa8000 0xc;
};
+ldb: ldb@53fa8008 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = fsl,imx53-ldb;
+reg = 0x53fa8008 0x4;
+gpr = gpr;
+clocks = clks 122, clks 120,
+ clks 115, clks 116,
+ clks 123, clks 85;
+clock-names = di0_pll, di1_pll,
+ di0_sel, di1_sel,
+ di0, di1;
+status = disabled;
+
+lvds-channel@0 {
+reg = 0;
+crtcs = ipu 0;
+status = disabled;
+};
+
+lvds-channel@1 {
+reg = 1;
+crtcs = ipu 1;
+status = disabled;
+};
+};
+
pwm1: pwm@53fb4000 {
#pwm-cells = 2;
compatible = fsl,imx53-pwm, fsl,imx27-pwm;
Maybe pinctrl entries should also be added?
Generally, the pinctrl entries should be added in board.dts.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 06/11] ARM i.MX: Add imx_clk_divider_flags and imx_clk_mux_flags
On Wed, Mar 27, 2013 at 06:30:40PM +0100, Philipp Zabel wrote: The default is for dividers to set CLK_SET_PARENT_RATE and for muxes to not set that flag. In the LDB clock tree, we need the opposite, so add functions to create divider and mux clocks with configurable flags. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 07/11] ARM i.MX53: fix ldb di divider and selector clocks
On Wed, Mar 27, 2013 at 06:30:41PM +0100, Philipp Zabel wrote: Use imx_clk_mux_flags and imx_clk_divider_flags to set the appropriate flags for the LDB display interface divider and selector clocks. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 08/11] ARM i.MX6q: fix ldb di divider and selector clocks
On Wed, Mar 27, 2013 at 06:30:42PM +0100, Philipp Zabel wrote: Use imx_clk_mux_flags and imx_clk_divider_flags to set the appropriate flags for the LDB display interface divider and selector clocks. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 11/11] ARM i.MX6q: Add LDB device to device tree
On Wed, Mar 27, 2013 at 06:30:45PM +0100, Philipp Zabel wrote:
From: Steffen Trumtrar s.trumt...@pengutronix.de
Add ldb device tree node and clock lookups.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/boot/dts/imx6q.dtsi | 17 +
arch/arm/boot/dts/imx6qdl.dtsi | 26 ++
2 files changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index cba021e..1a30227 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -294,3 +294,20 @@
};
};
};
+
+ldb {
+ clocks = clks 33, clks 34,
+ clks 39, clks 40, clks 41, clks 42,
+ clks 135, clks 136;
+ clock-names = di0_pll, di1_pll,
+ di0_sel, di1_sel, di2_sel, di3_sel,
+ di0, di1;
These are identical with the ones in imx6qdl.dtsi, so not needed at all?
+
+ lvds-channel@0 {
+ crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+ };
+
+ lvds-channel@1 {
+ crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 06ec460..dd5ef96 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -529,6 +529,32 @@
reg = 0x020e 0x38;
};
+ ldb: ldb@020e0008 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,imx6q-ldb, fsl,imx53-ldb;
Since both compatible strings are in the driver matching table, it's not
necessary to have fsl,imx53-ldb listed here.
Shawn
+ clocks = clks 33, clks 34,
+ clks 39, clks 40,
+ clks 135, clks 136;
+ clock-names = di0_pll, di1_pll,
+ di0_sel, di1_sel,
+ di0, di1;
+ gpr = gpr;
+ status = disabled;
+
+ lvds-channel@0 {
+ reg = 0;
+ crtcs = ipu1 0;
+ status = disabled;
+ };
+
+ lvds-channel@1 {
+ reg = 1;
+ crtcs = ipu1 1;
+ status = disabled;
+ };
+ };
+
dcic1: dcic@020e4000 {
reg = 0x020e4000 0x4000;
interrupts = 0 124 0x04;
--
1.8.2.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 RESEND 4/4] ARM: dts: add sram for imx53 and imx6q
On Thu, Mar 28, 2013 at 10:05:18AM +0100, Philipp Zabel wrote:
+
+ ocram: ocram@f800 {
+ compatible = fsl,imx-ocram, mmio-sram;
We should probably just drop fsl,imx-ocram.
Shawn
I thought that in the future somebody might want to implement some i.MX
OCRAM specifics in a different driver, like the L2 cache / OCRAM mode
switching, the timing settings, or the TrustZone bits that are
configurable in the IOMUXC GPR registers.
We can add i.MX OCRAM specific compatible when we see that real need.
Also, generally we should use a specific chip/osc name rather than imx
for compatible to specify the particular hardware version.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 04/11] ARM i.MX6q: Add audio/video PLL post dividers for i.MX6q rev 1.1
On Thu, Mar 28, 2013 at 10:58:00AM +0100, Philipp Zabel wrote:
In the loops in _get_table_maxdiv(), _get_table_div(), and
_get_table_val(), in drivers/clk/clk-divider.c the exit condition
is .div == 0, so there needs to be a sentinel with .div = 0 at the end
of each clk_div_table. It's also documented in the kerneldoc comment for
clk_register_divider_table.
Ah, I do not know that. So clk_enet_ref_table is actually buggy?
I can write that as { }, like this:
static struct clk_div_table test_div_table[] = {
{ .val = 2, .div = 1 },
{ .val = 1, .div = 2 },
{ .val = 0, .div = 4 },
{ }
};
Yes, that's much better for reading. But to be consistent with
clk_enet_ref_table, please also put a comma after .div.
static struct clk_div_table control3_table[] = {
{ .val = 0, .div = 1 },
{ .val = 1, .div = 2 },
{ .val = 3, .div = 4 },
{ }
};
Per Reference Manual, we should have one more entry below?
{ .val = 2, .div = 1, }
...
Because I didn't realize that the names were fixed in the final
documentation. I'll rename pll[45]_test_div to pll[45]_post_div.
pll5_control3 should be renamed to pll5_video_div, I guess.
Yea, that's much easier for users to map code and document.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 11/11] ARM i.MX6q: Add LDB device to device tree
On Thu, Mar 28, 2013 at 10:58:07AM +0100, Philipp Zabel wrote: The ldb node in imx6qdl.dtsi doesn't have the di[23]_sel clocks, because i.MX6dl doesn't have the second IPU. On i.MX6q, di[23]_sel should point to the ipu2_di0_sel and ipu2_di1_sel mux clocks. On i.MX6dl, di2_sel should point to lcdif_sel, eventually, and di3_sel shouldn't be given. Ah, sorry, I overlooked the difference. Should I remove the clocks from imx6qdl.dtsi altogether, to avoid confusion? Yea, I think it's less confusing to just have clocks and clock-names defined in imx6q and imx6dl dts respectively. I originally intended to split the input multiplexer from the LDB driver, as we have the same for HDMI and MIPI on i.MX6 (minus the clock multiplexing requirements), because apart from that, the LDB blocks are identical. Shouldn't this be documented in the device tree? Ok, that's fine then. I had the question because I saw imx6q compatible already in the matching table. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [query] IMX6 DTS : Device node with two interrupt parents
Copy devicetree-discuss ...
On Wed, Mar 27, 2013 at 08:40:58AM +0530, Pankaj Chauhan wrote:
All,
I have a query for adding device node in dts of board based on IMX6.
On the board i have a controller whole interrupt lines are connected
to interruptible GPIOs. But problem is out of three interrupt lines
two are connected to gpio4 and one is connected to gpio5, which means
i have two interrupt parents to specify in device node. My node looks
something like this:
queue-group@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ reg-names = queue-group0;
+ reg = 0x0d48 0x1000;
+ interrupts = 11 0 27 0 26 0;
+ interrupt-parent = gpio4;
+ };
here 27 and 26 are on gpio4 but 11 is on gpio5. Is there a way to
specify multiple interrupt parents? what is the correct way to handle
such configuration.
You may want to check how interrupt-map works. See ePAPR v1.1
2.4.3 Interrupt Nexus Properties for details.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 RESEND 0/4] Add generic driver for on-chip SRAM
On Wed, Mar 27, 2013 at 09:33:34AM +0100, Philipp Zabel wrote: Am Mittwoch, den 20.03.2013, 11:52 +0100 schrieb Philipp Zabel: Hi, last time I posted was a bit close to the merge window, so I'm reposting now. Greg, Arnd, could you take the first two patches? Ping, can I do anything to help move this along? You haven't indicated how the series should be merged and by whom. I think we should have the first two patches get in through either Andrew's tree or Greg's tree, since Andrew is handling genalloc and Greg is handling drivers/misc. Greg, can you please give your ACK on the second patch to have the first two go via Andrew's tree? Otherwise, we can try to ask for Andrew's ACK on the first patch to have them go through yours. Please tell. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 8/8] reset: Add driver for gpio-controlled reset pins
On Mon, Mar 25, 2013 at 06:06:29PM +0100, Philipp Zabel wrote: This driver implements a reset controller device that toggles gpios connected to reset pins of peripheral ICs. The delay between assertion and de-assertion of the reset signal can be configured. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com Reviewed-by: Shawn Guo shawn@linaro.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/5] cpufreq: cpufreq-cpu0: Fix documentation example
On Wed, Mar 27, 2013 at 02:01:30PM +0100, Markus Pargmann wrote:
The example includes a property 'transition-latency', which should be
clock-latency.
Viresh already sent a fix [1] for that.
Shawn
[1] https://lkml.org/lkml/2013/3/26/267
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 4416ccc..051f764 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -32,7 +32,7 @@ cpus {
396000 95
198000 85
;
- transition-latency = 61036; /* two CLK32 periods */
+ clock-latency = 61036; /* two CLK32 periods */
};
cpu@1 {
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM i.MX53: Add GPU clocks to clock tree
On Wed, Mar 27, 2013 at 10:51:33AM +0100, Philipp Zabel wrote: This patch adds the missing GPU2D and GPU3D mux and gate clocks, and the graphics arbiter gate clock. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/5] ARM: imx: Remove cpufreq driver
On Wed, Mar 27, 2013 at 02:01:34PM +0100, Markus Pargmann wrote: The old cpufreq driver is not necessary anymore with DT and cpufreq-cpu0. Signed-off-by: Markus Pargmann m...@pengutronix.de --- arch/arm/Kconfig | 7 -- arch/arm/mach-imx/Makefile| 1 - arch/arm/mach-imx/cpu_op-mx51.c | 31 - arch/arm/mach-imx/cpu_op-mx51.h | 14 --- arch/arm/mach-imx/cpufreq.c | 206 -- arch/arm/mach-imx/mach-cpuimx51sd.c | 5 - arch/arm/mach-imx/mach-mx51_babbage.c | 4 - 7 files changed, 268 deletions(-) delete mode 100644 arch/arm/mach-imx/cpu_op-mx51.c Target cpu_op-mx51.o should be removed from Makefile then. I fixed it up and applied the series expect the first patch. I expect you will send follow-up patches to add imx51 operating-points into device tree though. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 RESEND 3/4] media: coda: use genalloc API
On Wed, Mar 20, 2013 at 11:52:46AM +0100, Philipp Zabel wrote: This patch depends on genalloc: add devres support, allow to find a managed pool by device, which provides the of_get_named_gen_pool and dev_get_gen_pool functions. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-By: Javier Martin javier.mar...@vista-silicon.com Acked-by: Grant Likely grant.lik...@secretlab.ca --- Documentation/devicetree/bindings/media/coda.txt | 30 +++ drivers/media/platform/Kconfig |1 - drivers/media/platform/coda.c| 45 +++--- include/linux/platform_data/coda.h | 18 + 4 files changed, 79 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/coda.txt create mode 100644 include/linux/platform_data/coda.h diff --git a/Documentation/devicetree/bindings/media/coda.txt b/Documentation/devicetree/bindings/media/coda.txt new file mode 100644 index 000..2865d04 --- /dev/null +++ b/Documentation/devicetree/bindings/media/coda.txt @@ -0,0 +1,30 @@ +ChipsMedia Coda multi-standard codec IP + + +Coda codec IPs are present in i.MX SoCs in various versions, +called VPU (Video Processing Unit). + +Required properties: +- compatible : should be fsl,chip-src for i.MX SoCs: fsl,chip-vpu Shawn + (a) fsl,imx27-vpu for CodaDx6 present in i.MX27 + (b) fsl,imx53-vpu for CODA7541 present in i.MX53 + (c) fsl,imx6q-vpu for CODA960 present in i.MX6q ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 RESEND 4/4] ARM: dts: add sram for imx53 and imx6q
On Wed, Mar 27, 2013 at 03:29:10PM -0700, Andrew Morton wrote: On Wed, 20 Mar 2013 11:52:47 +0100 Philipp Zabel p.za...@pengutronix.de wrote: Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Shawn Guo shawn@linaro.org Acked-by: Grant Likely grant.lik...@secretlab.ca --- Changes since v8: - Changed device tree compatible string to mmio-sram --- arch/arm/boot/dts/imx53.dtsi |5 + arch/arm/boot/dts/imx6q.dtsi |6 ++ This doesn't apply, due to stuff which is pending in linux-next. I had a go at fixing it but ran out of confidence - those files have changed significantly. Redo and resend, please? We will merge this patch via IMX tree. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/5] ARM: imx: Remove cpufreq driver
On Wed, Mar 27, 2013 at 04:14:54PM +0100, Markus Pargmann wrote: I just prepared a patch for mx51 babbage board. cpuimx51sd does not seem to have a DTS file yet. In general I think the operating points have to be in the board specific DTS files because the frequencies of imx51 devices are different. Shouldn't the operating-points generally be SoC specific? I think we should have the operating-points recommended by SoC design added in soc.dtsi, and if there is an odd system design requiring different settings, we can override the operating-points in board.dts. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 RESEND 4/4] ARM: dts: add sram for imx53 and imx6q
On Wed, Mar 20, 2013 at 11:52:47AM +0100, Philipp Zabel wrote:
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Shawn Guo shawn@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Changes since v8:
- Changed device tree compatible string to mmio-sram
---
arch/arm/boot/dts/imx53.dtsi |5 +
arch/arm/boot/dts/imx6q.dtsi |6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index edc3f1e..69d0680 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -664,5 +664,10 @@
status = disabled;
};
};
+
+ ocram: ocram@f800 {
+ compatible = fsl,imx-ocram, mmio-sram;
We should probably just drop fsl,imx-ocram.
Shawn
+ reg = 0xf800 0x2;
+ };
};
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index ff1205e..73302db 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -124,6 +124,12 @@
status = disabled;
};
+ ocram: ocram@0090 {
+ compatible = fsl,imx-ocram, mmio-sram;
+ reg = 0x0090 0x3f000;
+ clocks = clks 142;
+ };
+
timer@00a00600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x00a00600 0x20;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/7] kbuild: create an include chroot for DT bindings
On Wed, Mar 06, 2013 at 11:22:57AM -0700, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com The recent dtc+cpp support allows header files and C pre-processor defines/macros to be used when compiling device tree files. These headers will typically define various constants that are part of the device tree bindings. The original patch which set up the dtc+cpp include path only considered using those headers from device tree files. However, most are also useful for kernel code which needs to interpret the device tree. In both the DT files and the kernel, I'd like to include the DT-related headers in the same way, for example, dt-bindings/gpio/tegra-gpio.h. That will simplify any text which discusses the DT header locations. Creating a dt-bindings/ for kernel source to use is as simple as placing files into include/dt-bindings/. However, when compiling DT files, the include path should be restricted so that only the dt-bindings path is available; arbitrary kernel headers shouldn't be exposed. For this reason, create a specific include directory for use by dtc+cpp, and symlink dt-bindings from there to the actual location of include/dt-bindings/. For want of a better location, place this include chroot into the existing dts/ directory. arch/*/boot/dts/include/dt-bindings - ../../../../../include/dt-bindings Some headers used by device tree files may not be useful to the kernel; they may be used simply to aid in constructing the DT file (e.g. macros to create a node), but not define any information that the kernel needs to share. These may be placed directly into arch/*/boot/dts/ along with the DT files themselves. Cc: Shawn Guo shawn@linaro.org Cc: Hiroshi Doyu hd...@nvidia.com Acked-by: Michal Marek mma...@suse.cz Acked-by: Shawn Guo shawn@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: Stephen Warren swar...@nvidia.com --- This first patch was previously posted separately as V2. I'm including it here to keep it with the whole series. I hope this series can be applied as a topic branch in arm-soc. So no comments on the series means that we can start maintain it on a topic branch, so that people can base their works on it? Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 08/10] ASoC: dmaengine_pcm: Add open function for DT DMA request
On Thu, Mar 14, 2013 at 02:08:32PM +0100, Markus Pargmann wrote: On Wed, Mar 13, 2013 at 10:18:29AM +0800, Shawn Guo wrote: On Tue, Mar 12, 2013 at 07:02:07PM +, Mark Brown wrote: On Sun, Mar 10, 2013 at 07:33:09PM +0100, Markus Pargmann wrote: Add a function to open a DMA PCM substream using devicetree data provided via the client device node. The patch introduces a public function and a private subfunction that is called by both open functions. Someone (I think it was Shawn) sent a very similar patch just recently which appears to have fallen out of my inbox unfortunately - can you please check what's going on there and coordinate with them? Let me know if you can't find the patch and I'll dig it out. It's here, Markus. http://thread.gmane.org/gmane.linux.alsa.devel/106027/focus=106031 Thanks. Do you already have a patch for the non-generic function which I could use instead? I do not follow. With my patch in place, there will be two dmaengine_pcm APIs. int snd_dmaengine_pcm_open(struct snd_pcm_substream *substream, dma_filter_fn filter_fn, void *filter_data) int snd_dmaengine_generic_pcm_open(struct snd_pcm_substream *substream, struct device *dev, const char *name) The first one is for users that their dmaengine driver hasn't converted to generic device tree bindings, and the second one is for users that their dmaengine driver is converted to generic device tree bindings. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: GPIO polarity in bindings for Freescale MXS
On Thu, Mar 14, 2013 at 01:35:47PM +0100, Hector Palacios wrote: On 03/14/2013 11:02 AM, Hector Palacios wrote: Hello, Maybe I'm missing something but the MXS processors (at least i.MX23 and i.MX28) cannot set the polarity of the GPIOs, so shouldn't the #gpio-cells be 1? (From Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt): Sorry, I meant: from Documentation/devicetree/bindings/gpio/gpio-mxs.txt - #gpio-cells : Should be two. The first cell is the pin number and the second cell is used to specify the gpio polarity: 0 = active high 1 = active low The second cell is used by client devices to specify their gpio connection polarity. Check of_get_named_gpio_flags() in drivers/mmc/host/mxs-mmc.c for example to see how it's used. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/6] Remove mxsfb auxdata
The mxsfb driver was converted to device tree by asking platform to pass mxsfb_platform_data with auxdata. We did this to have mach-mxs be DT only platform when there was no videomode bindings. Now with the videomode bindings and helpers in place, the series changes mxsfb driver to get display_timings from device tree, and removes mxsfb platform_data and auxdata completely. To maintain the bisectability, the series needs to go via single tree, and I prefer to arm-soc tree. Shawn Guo (6): video: mxsfb: use devm_* managed functions video: mxsfb: remove fb_phys/fb_size from platform_data video: mxsfb: remove dotclk_delay from platform_data video: mxsfb: get display timings from device tree ARM: mxs: move display timing configurations into device tree video: mxsfb: remove mxsfb_platform_data Documentation/devicetree/bindings/fb/mxsfb.txt | 34 arch/arm/boot/dts/imx23-evk.dts| 25 +++ arch/arm/boot/dts/imx28-apf28dev.dts | 25 +++ arch/arm/boot/dts/imx28-apx4devkit.dts | 25 +++ arch/arm/boot/dts/imx28-cfa10049.dts | 25 +++ arch/arm/boot/dts/imx28-evk.dts| 25 +++ arch/arm/boot/dts/imx28-m28evk.dts | 25 +++ arch/arm/mach-mxs/mach-mxs.c | 153 - drivers/video/Kconfig |2 + drivers/video/mxsfb.c | 219 +++- include/linux/mxsfb.h | 49 -- 11 files changed, 320 insertions(+), 287 deletions(-) delete mode 100644 include/linux/mxsfb.h -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/6] video: mxsfb: remove fb_phys/fb_size from platform_data
There is no in-tree users of mxsfb_platform_data fb_phys/fb_size.
With CMA support in the kernel, there is no real need for platform to
reserve memory and pass address and size into driver via platform_data.
So let's remove fb_phys/fb_size from mxsfb_platform_data to ease full
device tree adoption.
Signed-off-by: Shawn Guo shawn@linaro.org
---
drivers/video/mxsfb.c | 39 +++
include/linux/mxsfb.h |9 -
2 files changed, 7 insertions(+), 41 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 2c5ab15..776d0d5 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -168,7 +168,6 @@ struct mxsfb_info {
unsigned ld_intf_width;
unsigned dotclk_delay;
const struct mxsfb_devdata *devdata;
- int mapped;
};
#define mxsfb_is_v3(host) (host-devdata-ipversion == 3)
@@ -685,7 +684,7 @@ static int mxsfb_init_fbinfo(struct mxsfb_info *host)
struct mxsfb_platform_data *pdata = host-pdev-dev.platform_data;
dma_addr_t fb_phys;
void *fb_virt;
- unsigned fb_size = pdata-fb_size;
+ unsigned fb_size;
fb_info-fbops = mxsfb_ops;
fb_info-flags = FBINFO_FLAG_DEFAULT | FBINFO_READS_FAST;
@@ -705,30 +704,12 @@ static int mxsfb_init_fbinfo(struct mxsfb_info *host)
host-ld_intf_width = pdata-ld_intf_width;
/* Memory allocation for framebuffer */
- if (pdata-fb_phys) {
- if (!fb_size)
- return -EINVAL;
-
- fb_phys = pdata-fb_phys;
+ fb_size = SZ_2M;
+ fb_virt = alloc_pages_exact(fb_size, GFP_DMA);
+ if (!fb_virt)
+ return -ENOMEM;
- if (!request_mem_region(fb_phys, fb_size, host-pdev-name))
- return -ENOMEM;
-
- fb_virt = ioremap(fb_phys, fb_size);
- if (!fb_virt) {
- release_mem_region(fb_phys, fb_size);
- return -ENOMEM;
- }
- host-mapped = 1;
- } else {
- if (!fb_size)
- fb_size = SZ_2M; /* default */
- fb_virt = alloc_pages_exact(fb_size, GFP_DMA);
- if (!fb_virt)
- return -ENOMEM;
-
- fb_phys = virt_to_phys(fb_virt);
- }
+ fb_phys = virt_to_phys(fb_virt);
fb_info-fix.smem_start = fb_phys;
fb_info-screen_base = fb_virt;
@@ -744,13 +725,7 @@ static void mxsfb_free_videomem(struct mxsfb_info *host)
{
struct fb_info *fb_info = host-fb_info;
- if (host-mapped) {
- iounmap(fb_info-screen_base);
- release_mem_region(fb_info-fix.smem_start,
- fb_info-screen_size);
- } else {
- free_pages_exact(fb_info-screen_base, fb_info-fix.smem_len);
- }
+ free_pages_exact(fb_info-screen_base, fb_info-fix.smem_len);
}
static struct platform_device_id mxsfb_devtype[] = {
diff --git a/include/linux/mxsfb.h b/include/linux/mxsfb.h
index f14943d..93fc34b 100644
--- a/include/linux/mxsfb.h
+++ b/include/linux/mxsfb.h
@@ -35,15 +35,6 @@ struct mxsfb_platform_data {
unsigned dotclk_delay; /* refer manual HW_LCDIF_VDCTRL4 register */
unsigned ld_intf_width; /* refer STMLCDIF_* macros */
-
- unsigned fb_size; /* Size of the video memory. If zero a
-* default will be used
-*/
- unsigned long fb_phys; /* physical address for the video memory. If
-* zero the framebuffer memory will be
dynamically
-* allocated. If specified,fb_size must also be
specified.
-* fb_phys must be unused by Linux.
-*/
};
#endif /* __LINUX_MXSFB_H */
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/6] video: mxsfb: remove dotclk_delay from platform_data
There is no in-tree mxsfb users using mxsfb_platform_data dotclk_delay.
Let's remove it from mxsfb_platform_data to ease full device tree
adoption of mxsfb driver. If later we have platform/board need to
configure this parameter, we can add it into device tree bindings.
Signed-off-by: Shawn Guo shawn@linaro.org
---
drivers/video/mxsfb.c |1 -
include/linux/mxsfb.h |1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 776d0d5..001983a 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -700,7 +700,6 @@ static int mxsfb_init_fbinfo(struct mxsfb_info *host)
var-accel_flags = 0;
var-vmode = FB_VMODE_NONINTERLACED;
- host-dotclk_delay = pdata-dotclk_delay;
host-ld_intf_width = pdata-ld_intf_width;
/* Memory allocation for framebuffer */
diff --git a/include/linux/mxsfb.h b/include/linux/mxsfb.h
index 93fc34b..6d64e2e 100644
--- a/include/linux/mxsfb.h
+++ b/include/linux/mxsfb.h
@@ -33,7 +33,6 @@ struct mxsfb_platform_data {
unsigned default_bpp;
- unsigned dotclk_delay; /* refer manual HW_LCDIF_VDCTRL4 register */
unsigned ld_intf_width; /* refer STMLCDIF_* macros */
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/6] video: mxsfb: get display timings from device tree
Use videomode helpers to get display timings and configurations from
device tree when platform_data is absent.
Signed-off-by: Shawn Guo shawn@linaro.org
---
Documentation/devicetree/bindings/fb/mxsfb.txt | 34 +++
drivers/video/Kconfig |2 +
drivers/video/mxsfb.c | 118 ++--
3 files changed, 144 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt
b/Documentation/devicetree/bindings/fb/mxsfb.txt
index b41e5e52..7ba3b76 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -5,10 +5,20 @@ Required properties:
imx23 and imx28.
- reg: Address and length of the register set for lcdif
- interrupts: Should contain lcdif interrupts
+- display : phandle to display node (see below for details)
Optional properties:
- panel-enable-gpios : Should specify the gpio for panel enable
+* display node
+
+Required properties:
+- bits-per-pixel : 16 for RGB565, 32 for RGB888/666.
+- bus-width : number of data lines. Could be 8, 16, 18 or 24.
+
+Required sub-node:
+- display-timings : Refer to binding doc display-timing.txt for details.
+
Examples:
lcdif@8003 {
@@ -16,4 +26,28 @@ lcdif@8003 {
reg = 0x8003 2000;
interrupts = 38 86;
panel-enable-gpios = gpio3 30 0;
+
+ display: display {
+ bits-per-pixel = 32;
+ bus-width = 24;
+
+ display-timings {
+ native-mode = timing0;
+ timing0: timing0 {
+ clock-frequency = 3350;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 164;
+ hback-porch = 89;
+ hsync-len = 10;
+ vback-porch = 23;
+ vfront-porch = 10;
+ vsync-len = 10;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 0;
+ };
+ };
+ };
};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..e7718fd 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2437,6 +2437,8 @@ config FB_MXS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS
+ select OF_VIDEOMODE
help
Framebuffer support for the MXS SoC.
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 001983a..cf968c6 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -43,12 +43,14 @@
#include linux/kernel.h
#include linux/of_device.h
#include linux/of_gpio.h
+#include video/of_display_timing.h
#include linux/platform_device.h
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/io.h
#include linux/pinctrl/consumer.h
#include linux/mxsfb.h
+#include video/videomode.h
#define REG_SET4
#define REG_CLR8
@@ -677,6 +679,97 @@ static int mxsfb_restore_mode(struct mxsfb_info *host)
return 0;
}
+static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
+{
+ struct fb_info *fb_info = host-fb_info;
+ struct fb_var_screeninfo *var = fb_info-var;
+ struct device *dev = host-pdev-dev;
+ struct device_node *np = host-pdev-dev.of_node;
+ struct device_node *display_np;
+ struct device_node *timings_np;
+ struct display_timings *timings;
+ u32 width;
+ int i;
+ int ret = 0;
+
+ display_np = of_parse_phandle(np, display, 0);
+ if (!display_np) {
+ dev_err(dev, failed to find display phandle\n);
+ return -ENOENT;
+ }
+
+ ret = of_property_read_u32(display_np, bus-width, width);
+ if (ret 0) {
+ dev_err(dev, failed to get property bus-width\n);
+ goto put_display_node;
+ }
+
+ switch (width) {
+ case 8:
+ host-ld_intf_width = STMLCDIF_8BIT;
+ break;
+ case 16:
+ host-ld_intf_width = STMLCDIF_16BIT;
+ break;
+ case 18:
+ host-ld_intf_width = STMLCDIF_18BIT;
+ break;
+ case 24:
+ host-ld_intf_width = STMLCDIF_24BIT;
+ break;
+ default:
+ dev_err(dev, invalid bus-width value\n);
+ ret = -EINVAL;
+ goto put_display_node;
+ }
+
+ ret = of_property_read_u32(display_np, bits-per-pixel,
+ var-bits_per_pixel);
+ if (ret 0) {
+ dev_err(dev, failed to get property bits-per-pixel\n);
+ goto put_display_node
[PATCH 5/6] ARM: mxs: move display timing configurations into device tree
Move display timing configurations into device tree, so that the
auxdata for mxsfb driver can be killed.
Signed-off-by: Shawn Guo shawn@linaro.org
---
arch/arm/boot/dts/imx23-evk.dts| 25 ++
arch/arm/boot/dts/imx28-apf28dev.dts | 25 ++
arch/arm/boot/dts/imx28-apx4devkit.dts | 25 ++
arch/arm/boot/dts/imx28-cfa10049.dts | 25 ++
arch/arm/boot/dts/imx28-evk.dts| 25 ++
arch/arm/boot/dts/imx28-m28evk.dts | 25 ++
arch/arm/mach-mxs/mach-mxs.c | 153
7 files changed, 150 insertions(+), 153 deletions(-)
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 035c13f..7880e17 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -60,7 +60,32 @@
pinctrl-names = default;
pinctrl-0 = lcdif_24bit_pins_a;
panel-enable-gpios = gpio1 18 0;
+ display = display;
status = okay;
+
+ display: display {
+ bits-per-pixel = 32;
+ bus-width = 24;
+
+ display-timings {
+ native-mode = timing0;
+ timing0: timing0 {
+ clock-frequency =
920;
+ hactive = 480;
+ vactive = 272;
+ hback-porch = 15;
+ hfront-porch = 8;
+ vback-porch = 12;
+ vfront-porch = 4;
+ hsync-len = 1;
+ vsync-len = 1;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 0;
+ };
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/imx28-apf28dev.dts
b/arch/arm/boot/dts/imx28-apf28dev.dts
index 6d8865b..3d905d1 100644
--- a/arch/arm/boot/dts/imx28-apf28dev.dts
+++ b/arch/arm/boot/dts/imx28-apf28dev.dts
@@ -72,7 +72,32 @@
pinctrl-names = default;
pinctrl-0 = lcdif_16bit_pins_a
lcdif_pins_apf28dev;
+ display = display;
status = okay;
+
+ display: display {
+ bits-per-pixel = 16;
+ bus-width = 16;
+
+ display-timings {
+ native-mode = timing0;
+ timing0: timing0 {
+ clock-frequency =
3333;
+ hactive = 800;
+ vactive = 480;
+ hback-porch = 96;
+ hfront-porch = 96;
+ vback-porch = 20;
+ vfront-porch = 21;
+ hsync-len = 64;
+ vsync-len = 4;
+ hsync-active = 1;
+ vsync-active = 1;
+ de-active = 1;
+ pixelclk-active = 0;
+ };
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/imx28-apx4devkit.dts
b/arch/arm/boot/dts/imx28-apx4devkit.dts
index 5171667..43bf3c7 100644
--- a/arch/arm/boot/dts/imx28-apx4devkit.dts
+++ b/arch/arm/boot/dts/imx28-apx4devkit.dts
@@ -94,7 +94,32 @@
pinctrl-names = default;
pinctrl-0 = lcdif_24bit_pins_a
[PATCH 6/6] video: mxsfb: remove mxsfb_platform_data
None of mxsfb users uses mxsfb_platform_data now. Let's remove it
from mxsfb driver.
As the result, include/linux/mxsfb.h gets deleted with a few macros
moved into mxsfb.c. Along with the change, the typo FAILING in macro
name is fixed to be FALLING.
Signed-off-by: Shawn Guo shawn@linaro.org
---
drivers/video/mxsfb.c | 39 +--
include/linux/mxsfb.h | 39 ---
2 files changed, 17 insertions(+), 61 deletions(-)
delete mode 100644 include/linux/mxsfb.h
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index cf968c6..b528f56 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -49,7 +49,7 @@
#include linux/dma-mapping.h
#include linux/io.h
#include linux/pinctrl/consumer.h
-#include linux/mxsfb.h
+#include linux/fb.h
#include video/videomode.h
#define REG_SET4
@@ -109,7 +109,7 @@
#define VDCTRL0_ENABLE_PRESENT (1 28)
#define VDCTRL0_VSYNC_ACT_HIGH (1 27)
#define VDCTRL0_HSYNC_ACT_HIGH (1 26)
-#define VDCTRL0_DOTCLK_ACT_FAILING (1 25)
+#define VDCTRL0_DOTCLK_ACT_FALLING (1 25)
#define VDCTRL0_ENABLE_ACT_HIGH(1 24)
#define VDCTRL0_VSYNC_PERIOD_UNIT (1 21)
#define VDCTRL0_VSYNC_PULSE_WIDTH_UNIT (1 20)
@@ -144,6 +144,14 @@
#define BLUE 2
#define TRANSP 3
+#define STMLCDIF_8BIT 1 /** pixel data bus to the display is of 8 bit width */
+#define STMLCDIF_16BIT 0 /** pixel data bus to the display is of 16 bit width
*/
+#define STMLCDIF_18BIT 2 /** pixel data bus to the display is of 18 bit width
*/
+#define STMLCDIF_24BIT 3 /** pixel data bus to the display is of 24 bit width
*/
+
+#define FB_SYNC_DATA_ENABLE_HIGH_ACT (1 6)
+#define FB_SYNC_DOTCLK_FALLING_ACT (1 7) /* negtive edge sampling */
+
enum mxsfb_devtype {
MXSFB_V3,
MXSFB_V4,
@@ -459,8 +467,8 @@ static int mxsfb_set_par(struct fb_info *fb_info)
vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
if (fb_info-var.sync FB_SYNC_DATA_ENABLE_HIGH_ACT)
vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
- if (fb_info-var.sync FB_SYNC_DOTCLK_FAILING_ACT)
- vdctrl0 |= VDCTRL0_DOTCLK_ACT_FAILING;
+ if (fb_info-var.sync FB_SYNC_DOTCLK_FALLING_ACT)
+ vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
writel(vdctrl0, host-base + LCDC_VDCTRL0);
@@ -759,7 +767,7 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
if (vm.data_flags DISPLAY_FLAGS_DE_HIGH)
fb_vm.sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
if (vm.data_flags DISPLAY_FLAGS_PIXDATA_NEGEDGE)
- fb_vm.sync |= FB_SYNC_DOTCLK_FAILING_ACT;
+ fb_vm.sync |= FB_SYNC_DOTCLK_FALLING_ACT;
fb_add_videomode(fb_vm, fb_info-modelist);
}
@@ -774,7 +782,6 @@ static int mxsfb_init_fbinfo(struct mxsfb_info *host)
{
struct fb_info *fb_info = host-fb_info;
struct fb_var_screeninfo *var = fb_info-var;
- struct mxsfb_platform_data *pdata = host-pdev-dev.platform_data;
dma_addr_t fb_phys;
void *fb_virt;
unsigned fb_size;
@@ -788,15 +795,9 @@ static int mxsfb_init_fbinfo(struct mxsfb_info *host)
fb_info-fix.visual = FB_VISUAL_TRUECOLOR,
fb_info-fix.accel = FB_ACCEL_NONE;
- if (pdata) {
- host-ld_intf_width = pdata-ld_intf_width;
- var-bits_per_pixel =
- pdata-default_bpp ? pdata-default_bpp : 16;
- } else {
- ret = mxsfb_init_fbinfo_dt(host);
- if (ret)
- return ret;
- }
+ ret = mxsfb_init_fbinfo_dt(host);
+ if (ret)
+ return ret;
var-nonstd = 0;
var-activate = FB_ACTIVATE_NOW;
@@ -852,7 +853,6 @@ static int mxsfb_probe(struct platform_device *pdev)
{
const struct of_device_id *of_id =
of_match_device(mxsfb_dt_ids, pdev-dev);
- struct mxsfb_platform_data *pdata = pdev-dev.platform_data;
struct resource *res;
struct mxsfb_info *host;
struct fb_info *fb_info;
@@ -860,7 +860,7 @@ static int mxsfb_probe(struct platform_device *pdev)
struct pinctrl *pinctrl;
int panel_enable;
enum of_gpio_flags flags;
- int i, ret;
+ int ret;
if (of_id)
pdev-id_entry = of_id-data;
@@ -932,11 +932,6 @@ static int mxsfb_probe(struct platform_device *pdev)
if (ret != 0)
goto fb_release;
- if (pdata)
- for (i = 0; i pdata-mode_count; i++)
- fb_add_videomode(pdata-mode_list[i],
-fb_info-modelist);
-
modelist = list_first_entry(fb_info-modelist,
struct fb_modelist, list);
fb_videomode_to_var(fb_info-var, modelist-mode);
diff --git a/include/linux/mxsfb.h b/include/linux/mxsfb.h
Re: [PATCH 2/2] cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup
Copied devicetree-discuss list.
On Mon, Mar 11, 2013 at 06:05:30PM -0500, Nishanth Menon wrote:
commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
now forces platform device to be registered for allowing cpufreq-cpu0
to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c
However, for SoCs that wish to link up using device tree, instead
of platform device, provide compatibility string match:
compatible = cpufreq,cpu0;
This compatible is merely added for asking DT core code to populate
a platform_device for cpufreq driver. It's not describing
hardware/cpus, and it does not belong to device tree.
Shawn
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |3 +++
drivers/cpufreq/cpufreq-cpu0.c |6 ++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f180963..a5699f0 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -10,6 +10,8 @@ under node /cpus/cpu@0.
Required properties:
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
for details
+- compatible: if platform_device is *not* used, should be:
+ cpufreq,cpu0
Optional properties:
- clock-name: If the clock is not converted to device tree, then describe
@@ -24,6 +26,7 @@ Examples:
cpus {
#address-cells = 1;
#size-cells = 0;
+ compatible = cpufreq,cpu0;
cpu@0 {
compatible = arm,cortex-a9;
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 28223c9..a6f0a9b 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -277,9 +277,15 @@ static int cpu0_cpufreq_remove(struct platform_device
*pdev)
return 0;
}
+static struct of_device_id of_cpu0_cpufreq_match[] = {
+ { .compatible = cpufreq,cpu0, },
+ { /* end */ }
+};
+
static struct platform_driver cpu0_cpufreq_platdrv = {
.driver = {
.name = cpufreq-cpu0,
+ .of_match_table = of_cpu0_cpufreq_match,
.owner = THIS_MODULE,
},
.probe = cpu0_cpufreq_probe,
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 08/10] ASoC: dmaengine_pcm: Add open function for DT DMA request
On Tue, Mar 12, 2013 at 07:02:07PM +, Mark Brown wrote: On Sun, Mar 10, 2013 at 07:33:09PM +0100, Markus Pargmann wrote: Add a function to open a DMA PCM substream using devicetree data provided via the client device node. The patch introduces a public function and a private subfunction that is called by both open functions. Someone (I think it was Shawn) sent a very similar patch just recently which appears to have fallen out of my inbox unfortunately - can you please check what's going on there and coordinate with them? Let me know if you can't find the patch and I'll dig it out. It's here, Markus. http://thread.gmane.org/gmane.linux.alsa.devel/106027/focus=106031 Mark, I did not see any objection from you on that patch, so I'm waiting for you to publish a branch for it, so that my mxs-dma generic binding series can move forward. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/9] ARM: i.MX28: define osc in DT
On Fri, Mar 08, 2013 at 10:01:36AM +0100, Steffen Trumtrar wrote:
From: Juergen Beisert j...@pengutronix.de
Instead of hardcoding the ref_xtal in the clk driver, get it from the DT.
Signed-off-by: Juergen Beisert j...@pengutronix.de
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
arch/arm/boot/dts/imx28.dtsi | 11 +++
drivers/clk/mxs/clk-imx28.c | 16 +++-
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..b9e3712 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -37,6 +37,17 @@
};
};
+ clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ osc24m: system-oscillator {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 2400;
+ };
+ };
+
apb@8000 {
compatible = simple-bus;
#address-cells = 1;
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index 76ce6c6..01048b5 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -158,7 +158,21 @@ int __init mx28_clocks_init(void)
clk_misc_init();
- clks[ref_xtal] = mxs_clk_fixed(ref_xtal, 2400);
+ /* retrieve the crystal's frequencies from device tree */
+ for_each_compatible_node(np, NULL, fixed-clock) {
+ u32 rate;
+
+ if (of_property_read_u32(np, clock-frequency, rate))
+ continue;
+
+ if (of_device_is_compatible(np, fsl,mxs-system))
Use node name to save the custom compatible.
But more fundamental question - do you really have a imx28 system
running a ref_xtal that is not 24 MHz? Or does imx28 actually support
any other frequency ref_xtal other than 24 MHz?
Shawn
+ clks[ref_xtal] = mxs_clk_fixed(ref_xtal, rate);
+ }
+
+ /* if not set, guess their frequency */
+ if (clks[ref_xtal] == NULL)
+ clks[ref_xtal] = mxs_clk_fixed(ref_xtal, 2400);
+
clks[pll0] = mxs_clk_pll(pll0, ref_xtal, PLL0CTRL0, 17, 48000);
clks[pll1] = mxs_clk_pll(pll1, ref_xtal, PLL1CTRL0, 17, 48000);
clks[pll2] = mxs_clk_pll(pll2, ref_xtal, PLL2CTRL0, 23, 5000);
--
1.8.2.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/9] MXS/i.MX28: add the possibility to define the used crystals via device tree
For patches that you intend to go via mxs tree, please prefix it with
something like ARM: mxs:
On Mon, Mar 04, 2013 at 03:05:40PM +0100, Steffen Trumtrar wrote:
From: Juergen Beisert j...@pengutronix.de
Please do something with commit log.
Signed-off-by: Juergen Beisert j...@pengutronix.de
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
arch/arm/boot/dts/imx28.dtsi | 11 +++
drivers/clk/mxs/clk-imx28.c | 16 +++-
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..958bd10 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -37,6 +37,17 @@
};
};
+ clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ osc24m: system_oscillator {
+ compatible = fsl,mxs-system, fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 2400;
+ };
+ };
+
apb@8000 {
compatible = simple-bus;
#address-cells = 1;
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index 76ce6c6..01048b5 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -158,7 +158,21 @@ int __init mx28_clocks_init(void)
clk_misc_init();
- clks[ref_xtal] = mxs_clk_fixed(ref_xtal, 2400);
+ /* retrieve the crystal's frequencies from device tree */
+ for_each_compatible_node(np, NULL, fixed-clock) {
+ u32 rate;
+
+ if (of_property_read_u32(np, clock-frequency, rate))
+ continue;
+
+ if (of_device_is_compatible(np, fsl,mxs-system))
+ clks[ref_xtal] = mxs_clk_fixed(ref_xtal, rate);
+ }
+
+ /* if not set, guess their frequency */
+ if (clks[ref_xtal] == NULL)
+ clks[ref_xtal] = mxs_clk_fixed(ref_xtal, 2400);
+
I think ref_xtal has to be 24 MHz, no?
Shawn
clks[pll0] = mxs_clk_pll(pll0, ref_xtal, PLL0CTRL0, 17, 48000);
clks[pll1] = mxs_clk_pll(pll1, ref_xtal, PLL1CTRL0, 17, 48000);
clks[pll2] = mxs_clk_pll(pll2, ref_xtal, PLL2CTRL0, 23, 5000);
--
1.7.10.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/9] MXS/i.MX28: add the possibility to define the external RTC crystal
On Mon, Mar 04, 2013 at 03:05:41PM +0100, Steffen Trumtrar wrote:
From: Juergen Beisert j...@pengutronix.de
Signed-off-by: Juergen Beisert j...@pengutronix.de
You should have your SoB added here.
---
arch/arm/boot/dts/imx28.dtsi |6 ++
drivers/clk/mxs/clk-imx28.c |4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 958bd10..dcd0844 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -41,6 +41,12 @@
#address-cells = 1;
#size-cells = 0;
+ osc32k: rtc_oscillator {
Please use - than _ in node name.
+ compatible = fsl,mxs-rtc, fixed-clock;
I would suggest drop fsl,mxs-rtc here, and ...
+ #clock-cells = 0;
+ clock-frequency = 0;
+ };
+
osc24m: system_oscillator {
compatible = fsl,mxs-system, fixed-clock;
#clock-cells = 0;
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index 01048b5..a910d72 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -141,7 +141,7 @@ enum imx28_clk {
clk32k_div, rtc, lradc, spdif_div, clk32k, pwm, uart, ssp0,
ssp1, ssp2, ssp3, gpmi, spdif, emi, saif0, saif1, lcdif, etm,
fec, can0, can1, usb0, usb1, usb0_phy, usb1_phy, enet_out,
- clk_max
+ rtc_32k, clk_max
Number it in binding doc.
};
static struct clk *clks[clk_max];
@@ -167,6 +167,8 @@ int __init mx28_clocks_init(void)
if (of_device_is_compatible(np, fsl,mxs-system))
clks[ref_xtal] = mxs_clk_fixed(ref_xtal, rate);
+ else if (of_device_is_compatible(np, fsl,mxs-rtc))
... use node name to match, so that we can save a custom compatible.
Shawn
+ clks[rtc_32k] = mxs_clk_fixed(rtc32k, rate);
}
/* if not set, guess their frequency */
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/9] MXS/i.MX28: prepare different clocking of the built-in RTC
On Mon, Mar 04, 2013 at 03:05:42PM +0100, Steffen Trumtrar wrote:
From: Juergen Beisert j...@pengutronix.de
Signed-off-by: Juergen Beisert j...@pengutronix.de
---
drivers/rtc/rtc-stmp3xxx.c |8
1 file changed, 8 insertions(+)
So this is a rtc patch, and should be prefixed with rtc: stmp3xxx:
like patches #6~9.
And IMO, all the changes in this patch can just be added together with
the codes that use them. IOW, it can be merged into patch #4.
diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index 98f0d3c..7311292 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -53,18 +53,26 @@
#define STMP3XXX_RTC_PERSISTENT0 0x60
#define STMP3XXX_RTC_PERSISTENT0_SET 0x64
#define STMP3XXX_RTC_PERSISTENT0_CLR 0x68
+#define STMP3XXX_RTC_PERSISTENT0_CLOCKSOURCE (1 0)
#define STMP3XXX_RTC_PERSISTENT0_ALARM_WAKE_EN 0x0002
#define STMP3XXX_RTC_PERSISTENT0_ALARM_EN0x0004
+#define STMP3XXX_RTC_PERSISTENT0_XTAL24MHZ_PWRUP (1 4)
+#define STMP3XXX_RTC_PERSISTENT0_XTAL32KHZ_PWRUP (1 5)
+#define STMP3XXX_RTC_PERSISTENT0_XTAL32_FREQ (1 6)
+
#define STMP3XXX_RTC_PERSISTENT0_ALARM_WAKE 0x0080
#define STMP3XXX_RTC_PERSISTENT1 0x70
/* missing bitmask in headers */
#define STMP3XXX_RTC_PERSISTENT1_FORCE_UPDATER 0x8000
+enum clock_source { MXS_UNKNOWN, MXS_OSC_24M, MXS_OSC_32K, MXS_OSC_32K768 };
+
We generic write it like
enum clock_source {
MXS_UNKNOWN,
MXS_OSC_24M,
MXS_OSC_32K,
MXS_OSC_32K768
};
Shawn
struct stmp3xxx_rtc_data {
struct rtc_device *rtc;
void __iomem *io;
int irq_alarm;
+ enum clock_source clk_src;
};
#if IS_ENABLED(CONFIG_STMP3XXX_RTC_WATCHDOG)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
