Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Hi Pavel, On Sat, Apr 04, 2015 at 09:43:37AM +0200, Pavel Machek wrote: Documentation for adp1653 binding. s/binding/bindings/ Signed-off-by: Pavel Machek pa...@ucw.cz --- Please apply. Sorry, wrong version of patch was sent last time. Pavel diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt b/Documentation/devicetree/bindings/media/i2c/adp1653.txt new file mode 100644 index 000..4607ce3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt @@ -0,0 +1,37 @@ +* Analog Devices ADP1653 flash LED driver + +Required Properties: + + - compatible: Must contain be adi,adp1653 s/be // + + - reg: I2C slave address + + - enable-gpios: Reference to the GPIO that controls the power for the chip. How about: enable-gpios: Specifier of the GPIO connected to EN pin I can make the changes if you're ok with that, otherwise please send v7. Then I'll apply that to my tree. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi! And if you want to hide uart1 from the user-space, that should be a property of the uart1 node (whereever it is defined). Sorry? That would be one heck of layering violation. Which layering? Device tree is not operating system specific. It does not know what user space is, and can't assume we have uart nodes in /dev. Therefore it can't contain information that it should be hidden. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: sun7i: Add dts file for the Orangepi mini SBC
The Orangepi mini is a development board using the Allwinner A20 SoC,
with 1G RAM, 2 microsd slots (use the top side one for booting), HDMI,
1Gbit ethernet, USB wifi, Micro USB (otg), sata, 4 USB A ports,
ir receiver and a headphones jack.
Also see:
http://linux-sunxi.org/Xunlong_Orange_Pi_Mini
http://www.orangepi.org/
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts | 251 ++
2 files changed, 252 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d9b609d..13de5d6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -552,6 +552,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
sun7i-a20-orangepi.dtb \
+ sun7i-a20-orangepi-mini.dtb \
sun7i-a20-pcduino3.dtb \
sun7i-a20-pcduino3-nano.dtb \
sun7i-a20-wexler-tab7200.dtb
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
b/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
new file mode 100644
index 000..f6a6bf6
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
@@ -0,0 +1,251 @@
+/*
+ * Copyright 2015 Hans de Goede hdego...@redhat.com
+ *
+ * Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include sun7i-a20.dtsi
+#include sunxi-common-regulators.dtsi
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/pinctrl/sun4i-a10.h
+
+/ {
+ model = Orange Pi Mini;
+ compatible = xunlong,orangepi-mini, allwinner,sun7i-a20;
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 = led_pins_orangepi;
+
+ green {
+ label = orangepi:green:usr;
+ gpios = pio 7 24 GPIO_ACTIVE_HIGH; /* PH24 */
+ };
+
+ blue {
+ label = orangepi:blue:usr;
+ gpios = pio 7 25 GPIO_ACTIVE_HIGH; /* PH25 */
+ };
+ };
+
+ reg_gmac_3v3: gmac-3v3 {
+ compatible = regulator-fixed;
+ pinctrl-names = default;
+ pinctrl-0 = gmac_power_pin_orangepi;
+ regulator-name = gmac-3v3;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ startup-delay-us = 10;
+ enable-active-high;
+ gpio = pio 7 23 GPIO_ACTIVE_HIGH; /* PH23 */
+ };
+};
+
+ahci {
+ status = okay;
+};
+
[PATCH 1/2] ARM: dts: sun7i: Add dts file for the Orangepi SBC
The Orangepi is a development board using the Allwinner A20 SoC, with 1G RAM,
microsd slot, HDMI, 1Gbit ethernet, USB wifi, Micro USB (otg), sata, 4 USB A
ports, ir receiver and a headphones jack.
Also see:
http://linux-sunxi.org/Xunlong_Orange_Pi
http://www.orangepi.org/
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-orangepi.dts | 229 +++
2 files changed, 230 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-orangepi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2426f0a..d9b609d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -551,6 +551,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
+ sun7i-a20-orangepi.dtb \
sun7i-a20-pcduino3.dtb \
sun7i-a20-pcduino3-nano.dtb \
sun7i-a20-wexler-tab7200.dtb
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi.dts
b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
new file mode 100644
index 000..2ef79b7
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
@@ -0,0 +1,229 @@
+/*
+ * Copyright 2015 Hans de Goede hdego...@redhat.com
+ *
+ * Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include sun7i-a20.dtsi
+#include sunxi-common-regulators.dtsi
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/pinctrl/sun4i-a10.h
+
+/ {
+ model = Orange Pi;
+ compatible = xunlong,orangepi, allwinner,sun7i-a20;
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 = led_pins_orangepi;
+
+ green {
+ label = orangepi:green:usr;
+ gpios = pio 7 24 GPIO_ACTIVE_HIGH; /* PH24 */
+ };
+ };
+
+ reg_gmac_3v3: gmac-3v3 {
+ compatible = regulator-fixed;
+ pinctrl-names = default;
+ pinctrl-0 = gmac_power_pin_orangepi;
+ regulator-name = gmac-3v3;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ startup-delay-us = 10;
+ enable-active-high;
+ gpio = pio 7 23 GPIO_ACTIVE_HIGH; /* PH23 */
+ };
+};
+
+ahci {
+ status = okay;
+};
+
+ehci0 {
+ status = okay;
+};
+
+ehci1 {
+ status = okay;
+};
+
+gmac {
+ pinctrl-names = default;
+ pinctrl-0 = gmac_pins_rgmii_a;
+ phy = phy1;
+ phy-mode = rgmii;
+ phy-supply = reg_gmac_3v3;
+
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 04.04.2015 um 10:16 schrieb Pavel Machek pa...@ucw.cz: Hi! Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? Least squares fitting of my coefficients to your tables. Ah, I see. A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. How big battery do you have? 1200 mAh According to least squares fitting, assuming maximum charge of .46A, you were taking about 25mA when doing the discharge test. No, that can’t fit well. But I do not remember who has done this calibration in which situation because it was done many months ago for the platform data version. We have just reformatted the table for the DT. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. Yah, and your battery meter will be wrong in such case, as will be mine, because they are based on same information. Well, it is not “mine”, it is the platform_data based driver already in kernel.org since ca. 3.12. We have just updated it to DT to get rid of platform_data in this area as well… Yes, I see your argument that hiding the tables (two characteristic curves) into an analytic approximation can be superior. The problem I see is just that your formula needs some parameters which are difficult to derive or estimate. And must be adjusted to the specific battery and system setup in a non-trivial way. At least we must supply a tool (in the kernel/scripts directory?) where someone can can estimate the parameters of the formula from the characteristic curves. Maybe a tool that automatically runs several charge/discharge cycles at different system load. And measures time vs. voltage. And assumes a linear capacity decrease between the end points. (i.e. if it needs 10 hours to charge from completely empty to full, we can assume 50% after 5,0 hours). So my goal is to measure all characteristics of the battery - and no need to study a (potentially non-existing) data sheet. If you can provide that for all parameters of your algorithm I am fine with it. The thing is, mine can be improved without adding more tables. How can you improve your algorithm without tweaking or adding new parameters? It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. Umm. When not calling, your phone should not heat itself up. Yes, in suspend it needs 20 mA which does not heat or course. But steady operation at 20-400 mA does significantly rise OMAP temperature beyond environment temperature. And you definitely can power it down, leave it in outer pocket, then power it up. It is actually something people do when they want to preserve battery... I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? Because then other users can share the same code, and because you But you have ugly parameters in dts that nobody can easily see in the schematics and that are full of assumptions. From a perspective of uncertainty analysis, estimation of the internal parameters needs a higher precision than the calibration points. avoid big ugly tables in dts. Well, the biggest tables I have seen in dts are keyboard matrix codes… I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. And my email suggested solution better than your driver, so why not just use it? I am not yet convinced that it is better. It just moves the (unavoidable) limitations (measuring multiple calibration points) just to a different area (measuring the hidden and not precisely known parameter of the system). #perc = percent(volt) compute(charging, 1) compute(discharging, 0) Please explain what you calculate here. Especially what “Badness” is?
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Documentation for adp1653 binding.
Signed-off-by: Pavel Machek pa...@ucw.cz
---
Please apply.
Sorry, wrong version of patch was sent last time.
Pavel
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mode 100644
index 000..4607ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be adi,adp1653
+
+ - reg: I2C slave address
+
+ - enable-gpios: Reference to the GPIO that controls the power for the chip.
+
+There are two LED outputs available - flash and indicator. One LED is
+represented by one child node, nodes need to be named flash and indicator.
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = adi,adp1653;
+ reg = 0x30;
+ enable-gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
+
+ flash {
+ flash-timeout-us = 50;
+ flash-max-microamp = 32;
+ max-microamp = 5;
+ };
+ indicator {
+ max-microamp = 17500;
+ };
+ };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? Least squares fitting of my coefficients to your tables. A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. How big battery do you have? According to least squares fitting, assuming maximum charge of .46A, you were taking about 25mA when doing the discharge test. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. Yah, and your battery meter will be wrong in such case, as will be mine, because they are based on same information. The thing is, mine can be improved without adding more tables. It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. Umm. When not calling, your phone should not heat itself up. And you definitely can power it down, leave it in outer pocket, then power it up. It is actually something people do when they want to preserve battery... I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? Because then other users can share the same code, and because you avoid big ugly tables in dts. I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. And my email suggested solution better than your driver, so why not just use it? #perc = percent(volt) compute(charging, 1) compute(discharging, 0) Please explain what you calculate here. Especially what “Badness” is? Badness is error in least squares method. Here are updated tables: pavel@duo:~/g/tui/ofone$ ./liion_maps Charging Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.078 A computed 97 % Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.078 A computed 87 % Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.233 A computed 69 % Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 0.467 A computed 26 % Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 0.467 A computed 3 % Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 0.467 A computed 2 % Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 0.467 A computed 1 % Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 0.467 A computed -1 % Badness 395.4861761427434 Discharging Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.025 A computed 100 % Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.025 A computed 91 % Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.025 A computed 79 % Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.025 A computed 46 % Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.025 A computed 3 % Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.025 A computed 2 % Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.025 A computed 0 % Badness 171.69576218433212 pavel@duo:~/g/tui/ofone$ python Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] ARM: sunxi: SRAM mapping support
On Thu, Mar 26, 2015 at 03:53:40PM +0100, Hans de Goede wrote: Hi All, Here is v2 of my cleaned up version of Maxime's sunxi SRAM controller driver. Changes since v1: - Make the SUNXI_SRAM Kconfig option hidden, enabled by default if ARCH_SUNXI - Fix some typos in the comments in the dts file, both in the example in the devicetree-binding documentation, as well as in the actual dts files - Drop the bogus change to drivers/net/ethernet/stmicro/stmmac/Kconfig Since this is a prereq for my musb work, if there are no objections then I would like to see this go upstream soon. Since it only touches sunxi files (and one Makefile), it is probably best if this all goes upstream through Maxime. Merged patches 1-4. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 1/2] ARM: dts: sun7i: Add dts file for the Orangepi SBC
On Sat, Apr 04, 2015 at 10:59:53AM +0200, Hans de Goede wrote: The Orangepi is a development board using the Allwinner A20 SoC, with 1G RAM, microsd slot, HDMI, 1Gbit ethernet, USB wifi, Micro USB (otg), sata, 4 USB A ports, ir receiver and a headphones jack. Also see: http://linux-sunxi.org/Xunlong_Orange_Pi http://www.orangepi.org/ Signed-off-by: Hans de Goede hdego...@redhat.com Merged these two patches. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v3 0/2] WM8505/WM8650 DT fixes for SD card controller
В Sun, 1 Mar 2015 23:39:11 +0300 Roman Volkov rvol...@v1ros.org пишет: В Sun, 01 Mar 2015 20:52:55 +0100 Arnd Bergmann a...@arndb.de пишет: On Sunday 01 March 2015 19:06:45 Roman Volkov wrote: This patch set enables SD controller support for WM8650 and fixes minor errors in WM8505 Device Tree file. Changes in v3: 1. Add minor fixes for WM8505 SDHC node Tested on both WM8505 and WM8650. Roman Volkov (2): dts: vt8500: Add SDHC node to DTS file for WM8650 dts: vt8500: Fix errors in SDHC node for WM8505 arch/arm/boot/dts/wm8505.dtsi | 4 ++-- arch/arm/boot/dts/wm8650.dtsi | 9 + 2 files changed, 11 insertions(+), 2 deletions(-) -- Hi maintainers, I see my previous versions were not applied. Could this little patch set be applied for the linux-next? I don't think this is new functionality, this must be considered as bugfix for existing Device Tree. Any other suggestions? According to the MAINTAINERS file, Tony Prisk should be the person to pick them up, but he was not the recipient of the mail. Arnd Thanks for the tip. Tony probably need to add these files to his list of maintained files. get_maintainer.pl doesn't mention him. Roman Arnd, No response yet from Tony for over a month. Roman -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: sun5i: Enable touchscreen on Utoo P66
Hi Hans,
On Wed, Apr 01, 2015 at 05:29:37PM +0200, Hans de Goede wrote:
Add a node for the chipone-icn8318 touchscreen found on the Utoo P66 tablet.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Fix touchscreen node name
---
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index 9108ecd..00bdf28 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -50,6 +50,7 @@
#include sunxi-common-regulators.dtsi
#include dt-bindings/gpio/gpio.h
#include dt-bindings/input/input.h
+#include dt-bindings/interrupt-controller/irq.h
#include dt-bindings/pinctrl/sun4i-a10.h
/ {
@@ -93,6 +94,20 @@
pinctrl-0 = i2c1_pins_a;
status = okay;
+ icn8318: touchscreen@40 {
+ compatible = chipone,icn8318;
+ reg = 0x40;
+ interrupt-parent = pio;
+ interrupts = 9 IRQ_TYPE_EDGE_FALLING; /* EINT9 (PG9) */
I don't think you sent a reply to this comment, but this should really
be in a pinctrl node so that no one else can request the pin and
change its muxing and it shows up in debugfs.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 1/2] ARM: dts: sun7i: Add dts file for the Orangepi SBC
Hi Hans,
On Sat, Apr 04, 2015 at 10:59:53AM +0200, Hans de Goede wrote:
The Orangepi is a development board using the Allwinner A20 SoC, with 1G RAM,
microsd slot, HDMI, 1Gbit ethernet, USB wifi, Micro USB (otg), sata, 4 USB A
ports, ir receiver and a headphones jack.
Also see:
http://linux-sunxi.org/Xunlong_Orange_Pi
http://www.orangepi.org/
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-orangepi.dts | 229
+++
2 files changed, 230 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-orangepi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2426f0a..d9b609d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -551,6 +551,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
+ sun7i-a20-orangepi.dtb \
sun7i-a20-pcduino3.dtb \
sun7i-a20-pcduino3-nano.dtb \
sun7i-a20-wexler-tab7200.dtb
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi.dts
b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
new file mode 100644
index 000..2ef79b7
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
@@ -0,0 +1,229 @@
+/*
+ * Copyright 2015 Hans de Goede hdego...@redhat.com
+ *
+ * Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include sun7i-a20.dtsi
+#include sunxi-common-regulators.dtsi
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/pinctrl/sun4i-a10.h
+
+/ {
+ model = Orange Pi;
+ compatible = xunlong,orangepi, allwinner,sun7i-a20;
+
+ aliases {
+ serial0 = uart0;
+ };
This should have a matching /chosen/stdout-path property.
The rest of the patch is fine, I can apply it and add the property, if
that's ok for you.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 1/2] ARM: dts: sun7i: Add dts file for the Orangepi SBC
Hi,
On 04-04-15 14:47, Maxime Ripard wrote:
Hi Hans,
On Sat, Apr 04, 2015 at 10:59:53AM +0200, Hans de Goede wrote:
The Orangepi is a development board using the Allwinner A20 SoC, with 1G RAM,
microsd slot, HDMI, 1Gbit ethernet, USB wifi, Micro USB (otg), sata, 4 USB A
ports, ir receiver and a headphones jack.
Also see:
http://linux-sunxi.org/Xunlong_Orange_Pi
http://www.orangepi.org/
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-orangepi.dts | 229 +++
2 files changed, 230 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-orangepi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2426f0a..d9b609d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -551,6 +551,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
+ sun7i-a20-orangepi.dtb \
sun7i-a20-pcduino3.dtb \
sun7i-a20-pcduino3-nano.dtb \
sun7i-a20-wexler-tab7200.dtb
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi.dts
b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
new file mode 100644
index 000..2ef79b7
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-orangepi.dts
@@ -0,0 +1,229 @@
+/*
+ * Copyright 2015 Hans de Goede hdego...@redhat.com
+ *
+ * Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include sun7i-a20.dtsi
+#include sunxi-common-regulators.dtsi
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/pinctrl/sun4i-a10.h
+
+/ {
+ model = Orange Pi;
+ compatible = xunlong,orangepi, allwinner,sun7i-a20;
+
+ aliases {
+ serial0 = uart0;
+ };
This should have a matching /chosen/stdout-path property.
The rest of the patch is fine, I can apply it and add the property, if
that's ok for you.
Yes that ok with me.
Thanks,
Hans
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: sun5i: Enable touchscreen on Utoo P66
Hi,
On 04-04-15 14:44, Maxime Ripard wrote:
Hi Hans,
On Wed, Apr 01, 2015 at 05:29:37PM +0200, Hans de Goede wrote:
Add a node for the chipone-icn8318 touchscreen found on the Utoo P66 tablet.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Fix touchscreen node name
---
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index 9108ecd..00bdf28 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -50,6 +50,7 @@
#include sunxi-common-regulators.dtsi
#include dt-bindings/gpio/gpio.h
#include dt-bindings/input/input.h
+#include dt-bindings/interrupt-controller/irq.h
#include dt-bindings/pinctrl/sun4i-a10.h
/ {
@@ -93,6 +94,20 @@
pinctrl-0 = i2c1_pins_a;
status = okay;
+ icn8318: touchscreen@40 {
+ compatible = chipone,icn8318;
+ reg = 0x40;
+ interrupt-parent = pio;
+ interrupts = 9 IRQ_TYPE_EDGE_FALLING; /* EINT9 (PG9) */
I don't think you sent a reply to this comment, but this should really
be in a pinctrl node so that no one else can request the pin and
change its muxing and it shows up in debugfs.
I did reply to that comment on v1 of this patch:
That is not necessary when specifying a gpio interrupt through the
irq chip (rather then through a gpios property), the mux is automatically
set to irq by the kernel when requesting the irq.
Also note that we must use the interrupts notation here as this is specified
by the i2c client bindings. None of the other boards using i2c + oob irq
pins specifies a pinmux for the irq pin either.
I've just double checked and I cannot (quickly) find any existing devicetree
files using interrupts = foo combined with pinctrl for i2c clients.
If you look in e.g. arch/arm/boot/dts/exynos4210-trats.dts and
arch/arm/boot/dts/exynos4412-trats2.dts you will see the same pattern of
using interrupts = foo pointing to a gpio without using pinctrl
And we already to the same for sdio oob interrupts in sun7i-a20-cubietruck.dts
and arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts, so I vote for being consistent
here and not using pinctrl for the irq pin here either.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 5/6] staging: board: Add support for devices with complex dependencies
Hi Geert,
Thank you for the patch.
On Friday 03 April 2015 14:42:02 Geert Uytterhoeven wrote:
Add support for easy registering of one ore more platform devices that
may:
- need clocks that are described in DT,
- need pin control configuration,
- rely on a configured GPIO,
- be part of a PM Domain.
All these dependencies are optional.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/staging/board/board.c | 76
drivers/staging/board/board.h | 31 ++
2 files changed, 107 insertions(+)
diff --git a/drivers/staging/board/board.c b/drivers/staging/board/board.c
index b84ac2837a20bf06..da2469e2d4262fac 100644
--- a/drivers/staging/board/board.c
+++ b/drivers/staging/board/board.c
@@ -9,6 +9,9 @@
#define pr_fmt(fmt) board_staging: fmt
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/gpio.h
#include linux/init.h
#include linux/irq.h
#include linux/device.h
@@ -16,6 +19,9 @@
#include linux/of.h
#include linux/of_address.h
#include linux/of_irq.h
+#include linux/pinctrl/machine.h
+#include linux/platform_device.h
+#include linux/pm_domain.h
#include board.h
@@ -104,3 +110,73 @@ void __init board_staging_fixup_irq_resources(struct
resource *res, res[i].start = virq;
}
}
+
+int __init board_staging_register_clock(const struct board_staging_clk
*bsc) +{
+ struct clk *clk;
+ int error;
+
+ pr_debug(Registering clock %s for con_id %s dev_id %s\n, bsc-clk,
+ bsc-con_id, bsc-dev_id);
+ clk = clk_get(NULL, bsc-clk);
+ if (IS_ERR(clk)) {
+ error = PTR_ERR(clk);
+ pr_err(Failed to get clock %s (%d)\n, bsc-clk, error);
+ return error;
+ }
+
+ error = clk_register_clkdev(clk, bsc-con_id, bsc-dev_id);
+ if (error)
+ pr_err(Failed to register clock %s (%d)\n, bsc-clk, error);
+ return error;
+
+ clk_put(clk);
+ return 0;
+}
+
+int __init board_staging_register_device(const struct board_staging_dev
*dev) +{
+ struct platform_device *pdev = dev-pdev;
+ unsigned int i;
+ int error;
+
+ pr_debug(Trying to register device %s\n, pdev-name);
+ if (board_staging_dt_node_available(pdev-resource,
+ pdev-num_resources)) {
+ pr_warn(Skipping %s, already in DT\n, pdev-name);
+ return -EEXIST;
+ }
+
+ board_staging_fixup_irq_resources(pdev-resource, pdev-num_resources);
+
+ for (i = 0; i dev-nclocks; i++)
+ board_staging_register_clock(dev-clocks[i]);
+
+ if (dev-npinmaps)
+ pinctrl_register_mappings(dev-pinmaps, dev-npinmaps);
+
+ for (i = 0; i dev-ngpios; i++)
+ gpio_request_one(dev-gpios[i].gpio, dev-gpios[i].flags,
+ pdev-name);
Aren't GPIO numbers dynamic too in DT-based systems ? Beside, shouldn't it be
the responsibility of the drievr to request the GPIOs it needs ?
+ error = platform_device_register(pdev);
+ if (error) {
+ pr_err(Failed to register device %s (%d)\n, pdev-name,
+error);
+ return error;
+ }
+
+ if (dev-domain)
+ __pm_genpd_name_add_device(dev-domain, pdev-dev, NULL);
+
+ return error;
+}
+
+void __init board_staging_register_devices(const struct board_staging_dev
*devs, + unsigned int ndevs)
+{
+ unsigned int i;
+
+ for (i = 0; i ndevs; i++)
+ board_staging_register_device(devs[i]);
+}
diff --git a/drivers/staging/board/board.h b/drivers/staging/board/board.h
index 4cedc3c46e287eb7..7aaa0f7d6fafb9e5 100644
--- a/drivers/staging/board/board.h
+++ b/drivers/staging/board/board.h
@@ -4,12 +4,43 @@
#include linux/init.h
#include linux/of.h
+struct board_staging_clk {
+ const char *clk;
+ const char *con_id;
+ const char *dev_id;
+};
+
+struct board_staging_gpio {
+ unsigned int gpio;
+ unsigned long flags;/* See GPIOF_* */
+};
+
+struct board_staging_dev {
+ /* Platform Device */
+ struct platform_device *pdev;
+ /* Clocks (optional) */
+ const struct board_staging_clk *clocks;
+ unsigned int nclocks;
+ /* Pin Control Maps (optional) */
+ const struct pinctrl_map *pinmaps;
+ unsigned int npinmaps;
+ /* GPIOs (optional) */
+ const struct board_staging_gpio *gpios;
+ unsigned int ngpios;
+ /* PM Domain (optional) */
+ const char *domain;
+};
+
struct resource;
bool board_staging_dt_node_available(const struct resource *resource,
unsigned int num_resources);
int board_staging_setup_hwirq_xlate(const char *irqc_match, unsigned int
base); void board_staging_fixup_irq_resources(struct resource *res,
unsigned int
Re: [PATCH] libfdt: Add fdt_path_offset_namelen()
On 03/13/2015 01:43 AM, David Gibson wrote:
On Tue, Mar 10, 2015 at 09:47:44AM -0400, Peter Hurley wrote:
Hi David,
On 03/09/2015 08:17 PM, David Gibson wrote:
On Fri, Mar 06, 2015 at 10:12:38AM -0500, Peter Hurley wrote:
Properties may contain path names which are not NUL-terminated.
For example, the 'stdout-path' property allows the form 'path:options',
where the ':' character terminates the path specifier.
Allow these path names to be used in-place for path descending;
add fdt_path_offset_namelen(), which limits the path name to 'namelen'
characters.
Reimplement fdt_path_offset() as a trivial wrapper.
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
I think this function is a good idea, however I would like to see a
testcase for it.
Sure, I can do that.
I assume you mean a path name with non-NUL termination because
the fdt_path_offset() tests are already exercising the
fdt_path_offset_name() implementation.
Yes, I mean the non-\0-terminated case. Or more specifically still,
making sure that if you call fdt_path_offset_namelen() on a portion of
a longer path, it correctly gives you the offset for only the partial
path.
That said, there may be some other edge cases that could do with
testing too, if you have time. In particular I'm thinking of paths
where there are repeated '/' character, and paths ending with one or
more '/' characters.
Is there a readme somewhere regarding the test matrix (ie.,
which dts files go with which tests)?
I'm afraid not, apart from the test runner script itself. I'm not
sure quite what information you're after here.
Ok, now that I have the test working, I see why you didn't understand
what I was after.
The purpose of fdt_path_offset_namelen() is to perform path-descending
from in-place property values; for example, finding the node offset from
the /chosen/stdout-path property of the form
/ {
chosen {
stdout-path = /ocp/serial@44e04d00:115200;
};
}
I wrote the test to get string properties containing paths from the
fdt; for example, assuming the fdt contains
path1 = /subnode@1/subsubnode:;
path2 = /subnode@2/subsubnode@0:;
path3 = /subnode@1subsubnode///:;
path4 = /subnode@2///subsubnode///:/subnode@1;
the test did:
const char *path1;
path1 = fdt_getprop(fdt, 0, path1, len);
...
I had looked at the run_test.sh scripts and known that there were
multiple dtb files produced for the test_tree1 tests so I was asking
for a handy readme to tell me which dts(i) files to add the string
properties to.
When I got the test running for dtbs produced from test_tree1.body.dtsi,
I discovered there were some cross-referenced tests from other
sources, like sw_tree1.c; thus the changes to test_tree1.body.dtsi
cause other tests to fail.
So I've given up on testing fdt_path_offset_namelen() that way,
and instead, am just using static const paths defined in the test
itself, which I will submit shortly.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe devicetree-compiler
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libfdt: Add fdt_path_offset_namelen()
On 03/13/2015 01:43 AM, David Gibson wrote:
On Tue, Mar 10, 2015 at 09:47:44AM -0400, Peter Hurley wrote:
Hi David,
On 03/09/2015 08:17 PM, David Gibson wrote:
On Fri, Mar 06, 2015 at 10:12:38AM -0500, Peter Hurley wrote:
Properties may contain path names which are not NUL-terminated.
For example, the 'stdout-path' property allows the form 'path:options',
where the ':' character terminates the path specifier.
Allow these path names to be used in-place for path descending;
add fdt_path_offset_namelen(), which limits the path name to 'namelen'
characters.
Reimplement fdt_path_offset() as a trivial wrapper.
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
I think this function is a good idea, however I would like to see a
testcase for it.
Sure, I can do that.
I assume you mean a path name with non-NUL termination because
the fdt_path_offset() tests are already exercising the
fdt_path_offset_name() implementation.
Yes, I mean the non-\0-terminated case. Or more specifically still,
making sure that if you call fdt_path_offset_namelen() on a portion of
a longer path, it correctly gives you the offset for only the partial
path.
That said, there may be some other edge cases that could do with
testing too, if you have time. In particular I'm thinking of paths
where there are repeated '/' character, and paths ending with one or
more '/' characters.
Is there a readme somewhere regarding the test matrix (ie.,
which dts files go with which tests)?
I'm afraid not, apart from the test runner script itself. I'm not
sure quite what information you're after here.
Ok, now that I have the test working, I see why you didn't understand
what I was after.
The purpose of fdt_path_offset_namelen() is to perform path-descending
from in-place property values; for example, finding the node offset from
the /chosen/stdout-path property of the form
/ {
chosen {
stdout-path = /ocp/serial@44e04d00:115200;
};
}
I wrote the test to get string properties containing paths from the
fdt; for example, assuming the fdt contains
path1 = /subnode@1/subsubnode:;
path2 = /subnode@2/subsubnode@0:;
path3 = /subnode@1subsubnode///:;
path4 = /subnode@2///subsubnode///:/subnode@1;
the test did:
const char *path1;
path1 = fdt_getprop(fdt, 0, path1, len);
...
I had looked at the run_test.sh scripts and known that there were
multiple dtb files produced for the test_tree1 tests so I was asking
for a handy readme to tell me which dts(i) files to add the string
properties to.
When I got the test running for dtbs produced from test_tree1.body.dtsi,
I discovered there were some cross-referenced tests from other
sources, like sw_tree1.c; thus the changes to test_tree1.body.dtsi
cause other tests to fail.
So I've given up on testing fdt_path_offset_namelen() that way,
and instead, am just using static const paths defined in the test
itself, which I will submit shortly.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libfdt/tests: Add fdt_path_offset_namelen() test
Add unit test for fdt_path_offset_namelen(). Verify partial path-
descending retrieves the same node offset as fdt_subnode_offset().
Verify parsing correctness with multiple path separators, both
mid-path and trailing.
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
tests/Makefile.tests| 2 +-
tests/path_offset_namelen.c | 169
tests/run_tests.sh | 1 +
3 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 tests/path_offset_namelen.c
diff --git a/tests/Makefile.tests b/tests/Makefile.tests
index dafb618..9d5c456 100644
--- a/tests/Makefile.tests
+++ b/tests/Makefile.tests
@@ -1,6 +1,6 @@
LIB_TESTS_L = get_mem_rsv \
root_node find_property subnode_offset path_offset \
- get_name getprop get_phandle \
+ path_offset_namelen get_name getprop get_phandle \
get_path supernode_atdepth_offset parent_offset \
node_offset_by_prop_value node_offset_by_phandle \
node_check_compatible node_offset_by_compatible \
diff --git a/tests/path_offset_namelen.c b/tests/path_offset_namelen.c
new file mode 100644
index 000..3893d89
--- /dev/null
+++ b/tests/path_offset_namelen.c
@@ -0,0 +1,169 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_path_offset_namelen()
+ * Copyright (C) 2015 Peter Hurley
+ * based on path_offset.c, Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include stdint.h
+
+#include libfdt.h
+
+#include tests.h
+#include testdata.h
+
+static int check_subnode(void *fdt, int parent, const char *name)
+{
+ int offset;
+ const struct fdt_node_header *nh;
+ uint32_t tag;
+
+ verbose_printf(Checking subnode \%s\ of %d..., name, parent);
+ offset = fdt_subnode_offset(fdt, parent, name);
+ verbose_printf(offset %d..., offset);
+ if (offset 0)
+ FAIL(fdt_subnode_offset(\%s\): %s, name,
fdt_strerror(offset));
+ nh = fdt_offset_ptr(fdt, offset, sizeof(*nh));
+ verbose_printf(pointer %p\n, nh);
+ if (! nh)
+ FAIL(NULL retrieving subnode \%s\, name);
+
+ tag = fdt32_to_cpu(nh-tag);
+
+ if (tag != FDT_BEGIN_NODE)
+ FAIL(Incorrect tag 0x%08x on property \%s\, tag, name);
+ if (!nodename_eq(nh-name, name))
+ FAIL(Subnode name mismatch \%s\ instead of \%s\,
+nh-name, name);
+
+ return offset;
+}
+
+static void check_root(void *fdt)
+{
+ int root;
+
+ root = fdt_path_offset_namelen(fdt, /, 1);
+ if (root 0)
+ FAIL(fdt_path_offset_namelen(\/\) failed: %s,
+fdt_strerror(root));
+ else if (root != 0)
+ FAIL(fdt_path_offset_namelen(\/\) bad offset %d, root);
+}
+
+static void check_offsets(int subnode, int path)
+{
+ if (subnode != path)
+ FAIL(Mismatch: subnode_offset (%d) != path_offset (%d),
+subnode, path);
+}
+
+static const char *get_subpath(const char *path, int len)
+{
+ const char *p;
+
+ p = strchr(path, '/');
+ if (!p)
+ FAIL(no / in %s, path);
+ p = strchr(p + 1, '/');
+ if (!p)
+ FAIL(no subpath %s, path);
+ if (p - path = len)
+ FAIL(subpath len (%d) path (%s) length (%d),
+(int)(p - path), path, len);
+
+ return p;
+}
+
+static const char *get_subsubpath(const char *path, int len)
+{
+ const char *p;
+
+ p = strchr(path, ':');
+ if (!p)
+ FAIL(no subsubpath in %s, path);
+ if (p - path = len)
+ FAIL(subsubpath len (%d) path (%s) length (%d),
+(int)(p - path), path, len);
+
+ return p;
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int subnode1_offset, subnode2_offset;
+ int subnode1_offset_p, subnode2_offset_p;
+ int subsubnode1_offset, subsubnode2_offset, subsubnode2_offset2;
+ int subsubnode1_offset_p, subsubnode2_offset_p, subsubnode2_offset2_p;
+ int path1_len, path2_len, path3_len, path4_len;
+ const char *p1, *p2, *p3, *p4;
+
+ static
Re: [PATCH v2 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl
Hi Paul,
thank you for your review.
Am 27.03.2015 um 18:10 schrieb Paul Bolle:
This patch adds a mismatch between the Kconfig symbol (bool) and the
code (which assumes a modular built too).
On Fri, 2015-03-27 at 10:36 +0100, Oleksij Rempel wrote:
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -47,6 +47,14 @@ config PINCTRL_AS3722
open drain configuration for the GPIO pins of AS3722 devices. It also
supports the GPIO functionality through gpiolib.
+config PINCTRL_ASM9260
+bool Pinctrl driver for Alphascale asm9260
This adds a bool symbol.
+depends on MACH_ASM9260
+select PINMUX
+select GENERIC_PINCONF
+help
+ Say Y here to enable the Alphascale asm9260 pinctrl driver
+
-- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
+obj-$(CONFIG_PINCTRL_ASM9260) += pinctrl-asm9260.o
So this object can now only be built-in.
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-asm9260.c
@@ -0,0 +1,733 @@
+/*
+ * Pinctrl driver for the Alphascale ASM9260 SoC
+ *
+ * Copyright (c) 2014, Oleksij Rempel li...@rempel-privat.de
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/module.h
This include is probably not needed.
This include is still needed for MODULE_DEVICE_TABLE.
+#include linux/pinctrl/pinconf-generic.h
+#include linux/pinctrl/pinmux.h
+#include linux/platform_device.h
+
+#include core.h
+#include pinctrl-utils.h
+/*
+ * Pin control driver setup
+ */
+static struct pinctrl_desc asm9260_pinctrl_desc = {
+.pctlops= asm9260_pinctrl_ops,
+.pmxops = asm9260_pinmux_ops,
+.confops= asm9260_pinconf_ops,
+.owner = THIS_MODULE,
THIS_MODULE is, basically, equivalent to NULL for built-in code.
+};
+
+MODULE_DEVICE_TABLE(of, asm9260_pinctrl_of_match);
This will be preprocessed away for built-in code.
+module_platform_driver(asm9260_pinctrl_driver);
The built-in equivalent of this seems to be a wrapper that
only does
platform_driver_register(asm9260_pinctrl_driver);
and mark that wrapper as a device_initcall(). There appears to be no
macro that does all that in one line.
+MODULE_AUTHOR(Oleksij Rempel li...@rempel-privat.de);
+MODULE_DESCRIPTION(Alphascale ASM9260 pinctrl driver);
+MODULE_LICENSE(GPL);
These three macros will be, effectively, preprocessed away for built-in
code. (By the way, you probably want to use GPL v2 as the license
ident if it would be possible to build this code modular.)
According to:
http://lxr.free-electrons.com/source/include/linux/module.h#L100
GPL [GNU Public License v2 or later]
which reflects statement provided in the header :)
I assume all this changes are in the grey zone between: make it pretty
and it won't make any difference :D
Are you ok if we leave it as is?
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
Re: USB device nodes in device tree
Le 30/03/2015 12:35, Alan Stern a écrit : On Mon, 30 Mar 2015, Valentin Longchamp wrote: Hello, We are currently developing a board with an USB MFD device (I2C and GPIOs are to be supported). The device is soldered on the board and is the only one on the bus, so the bus is not really dynamic. Since it's an USB device, it should be dynamically detected by the kernel and it would not require a node in the board's DTS. However, I need to have the devices which are behind the MFD USB device to be in the DTS (I2C bus topology, and some of the GPIOs are to be used directly by some other DTS nodes as well). Is there a way to add a node for USB device in a DTS ? Is there an available example for this ? No, there is no way to do it as far as I know. The main problem is that Device Tree is static whereas USB devices are dynamic. The PCI(e) bus has the same problem, yet you can specify a PCI device child node, and have a compatible string which will match the vendor id/device id tuple, device class etc... such that you can use Device Tree to add additional information not necessarily available in other ways such as MAC addresses and similar. Once the PCI bus is scanned, pci_device present in Device Tree get a device_node pointer assigned. I don't think there is anything doing this yet for USB devices, but maybe that's something that should be there? -- Florian -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v18 01/11] ARM: qcom: Add Subsystem Power Manager (SPM) driver
On Fri, Apr 03 2015 at 15:54 -0600, Kevin Hilman wrote: Lina Iyer lina.i...@linaro.org writes: SPM is a hardware block that controls the peripheral logic surrounding the application cores (cpu/l$). When the core executes WFI instruction, the SPM takes over the putting the core in low power state as configured. The wake up for the SPM is an interrupt at the GIC, which then completes the rest of low power mode sequence and brings the core out of low power mode. The SPM has a set of control registers that configure the SPMs individually based on the type of the core and the runtime conditions. SPM is a finite state machine block to which a sequence is provided and it interprets the bytes and executes them in sequence. Each low power mode that the core can enter into is provided to the SPM as a sequence. Configure the SPM to set the core (cpu or L2) into its low power mode, the index of the first command in the sequence is set in the SPM_CTL register. When the core executes ARM wfi instruction, it triggers the SPM state machine to start executing from that index. The SPM state machine waits until the interrupt occurs and starts executing the rest of the sequence until it hits the end of the sequence. The end of the sequence jumps the core out of its low power mode. Add support for an idle driver to set up the SPM to place the core in Standby or Standalone power collapse mode when the core is idle. Based on work by: Mahesh Sivasubramanian msiva...@codeaurora.org, Ai Li a...@codeaurora.org, Praveen Chidambaram pchid...@codeaurora.org Original tree available at - git://codeaurora.org/quic/la/kernel/msm-3.10.git Cc: Stephen Boyd sb...@codeaurora.org Cc: Arnd Bergmann a...@arndb.de Cc: Kevin Hilman khil...@linaro.org Cc: Daniel Lezcano daniel.lezc...@linaro.org Signed-off-by: Lina Iyer lina.i...@linaro.org Acked-by: Kevin Hilman khil...@linaro.org and also tested on qcom-apq8064-ifc6410 and qcom-msm8974-sony-xperia-honami and saw the various states being entered on all CPUs. Thanks Kevin. Tested-by: Kevin Hilman khil...@linaro.org Kevin -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH repost] ARM: shmobile: r8a7790: Remove MSIOF address from device tree
From: Ryo Kataoka ryo.kataoka...@renesas.com
MSIOF Base Address H'E6xx can be accessed by CPU and DMAC.
MSIOF Base Address H'E7xx for DMAC was removed from H/W manual.
Signed-off-by: Ryo Kataoka ryo.kataoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
This patch is based on devel branch of Simon Horman's renesas tree.
v1 repost [Yoshihiro Kaneko]
* Dropped RFC designation
arch/arm/boot/dts/r8a7790.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 4bb2f4c..f3b8430 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1273,7 +1273,7 @@
msiof0: spi@e6e2 {
compatible = renesas,msiof-r8a7790;
- reg = 0 0xe6e2 0 0x0064, 0 0xe7e2 0 0x0064;
+ reg = 0 0xe6e2 0 0x0064;
interrupts = 0 156 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp0_clks R8A7790_CLK_MSIOF0;
dmas = dmac0 0x51, dmac0 0x52;
@@ -1285,7 +1285,7 @@
msiof1: spi@e6e1 {
compatible = renesas,msiof-r8a7790;
- reg = 0 0xe6e1 0 0x0064, 0 0xe7e1 0 0x0064;
+ reg = 0 0xe6e1 0 0x0064;
interrupts = 0 157 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp2_clks R8A7790_CLK_MSIOF1;
dmas = dmac0 0x55, dmac0 0x56;
@@ -1297,7 +1297,7 @@
msiof2: spi@e6e0 {
compatible = renesas,msiof-r8a7790;
- reg = 0 0xe6e0 0 0x0064, 0 0xe7e0 0 0x0064;
+ reg = 0 0xe6e0 0 0x0064;
interrupts = 0 158 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp2_clks R8A7790_CLK_MSIOF2;
dmas = dmac0 0x41, dmac0 0x42;
@@ -1309,7 +1309,7 @@
msiof3: spi@e6c9 {
compatible = renesas,msiof-r8a7790;
- reg = 0 0xe6c9 0 0x0064, 0 0xe7c9 0 0x0064;
+ reg = 0 0xe6c9 0 0x0064;
interrupts = 0 159 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp2_clks R8A7790_CLK_MSIOF3;
dmas = dmac0 0x45, dmac0 0x46;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: shmobile: r8a7791: Remove MSIOF address from device tree
From: Ryo Kataoka ryo.kataoka...@renesas.com
MSIOF Base Address H'E6xx can be accessed by CPU and DMAC.
MSIOF Base Address H'E7xx for DMAC was removed from H/W manual.
Signed-off-by: Ryo Kataoka ryo.kataoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
This patch is based on devel branch of Simon Horman's renesas tree.
v2 [Yoshihiro Kaneko]
* Update the binding documentation
Documentation/devicetree/bindings/spi/sh-msiof.txt | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt
b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index 4c388bb..8f77144 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -60,7 +60,7 @@ Example:
msiof0: spi@e6e2 {
compatible = renesas,msiof-r8a7791;
- reg = 0 0xe6e2 0 0x0064, 0 0xe7e2 0 0x0064;
+ reg = 0 0xe6e2 0 0x0064;
interrupts = 0 156 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp0_clks R8A7791_CLK_MSIOF0;
dmas = dmac0 0x51, dmac0 0x52;
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 4696062..3e9f824 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1288,7 +1288,7 @@
msiof0: spi@e6e2 {
compatible = renesas,msiof-r8a7791;
- reg = 0 0xe6e2 0 0x0064, 0 0xe7e2 0 0x0064;
+ reg = 0 0xe6e2 0 0x0064;
interrupts = 0 156 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp0_clks R8A7791_CLK_MSIOF0;
dmas = dmac0 0x51, dmac0 0x52;
@@ -1300,7 +1300,7 @@
msiof1: spi@e6e1 {
compatible = renesas,msiof-r8a7791;
- reg = 0 0xe6e1 0 0x0064, 0 0xe7e1 0 0x0064;
+ reg = 0 0xe6e1 0 0x0064;
interrupts = 0 157 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp2_clks R8A7791_CLK_MSIOF1;
dmas = dmac0 0x55, dmac0 0x56;
@@ -1312,7 +1312,7 @@
msiof2: spi@e6e0 {
compatible = renesas,msiof-r8a7791;
- reg = 0 0xe6e0 0 0x0064, 0 0xe7e0 0 0x0064;
+ reg = 0 0xe6e0 0 0x0064;
interrupts = 0 158 IRQ_TYPE_LEVEL_HIGH;
clocks = mstp2_clks R8A7791_CLK_MSIOF2;
dmas = dmac0 0x41, dmac0 0x42;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: Add binding for Broadcom MSPI driver.
Le 02/04/2015 12:23, Jonathan Richardson a écrit :
Signed-off-by: Jonathan Richardson jonat...@broadcom.com
---
.../devicetree/bindings/spi/brcm,mspi-spi.txt | 38
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
diff --git a/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
new file mode 100644
index 000..16164e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
@@ -0,0 +1,38 @@
+Broadcom MSPI controller
+
+Required properties:
+- compatible: Must be either brcm,mspi or brcm,bcma-mspi. Use
+ brcm,bcma-mspi for controllers on a bcma bus and brcm,mspi otherwise.
We need a more specific compatible property here since there are at
least 3 known SoCs families within Broadcom (Cygnus, BCM53xx, BCM7xxx)
that use this controller, also older versions of the core did not have a
revision register, yet they had an internal version numbering that we
might want to reflect here. This does not need to be fixed immediately
though, we can add compatible strings as we start adding support for
older cores.
+
+- reg: Physical base address and length of the controller's registers.
+
+- interrupts: The interrupt id for the controller.
I think this should be two cells, on BCM7xxx chips there is a MSPI_DONE
and a MSPI_ERROR interrupt bit, we typically only use the first one, but
since we are describing the hardware here, we need to be exhaustive.
+
+- #address-cells: should be 1.
+
+- #size-cells: should be 0.
+
+Optional properties:
+- clocks: The MSPI reference clock. If not provided then it is assumed a
clock
+ is enabled by default and no control of clock-frequency (see below) is
+ possible.
+
+- clock-names: The name of the reference clock.
+
+- clock-frequency: Desired frequency of the clock. This will set the serial
+ clock baud rate (SPBR) based on the reference clock frequency. The
frequency
+ of the SPBR is mspi_clk / (2 * SPBR) where SPBR is a value between 1-255
+ determined by the desired 'clock-frequency'. If not provided then the
default
+ baud rate of the controller is used.
See my reply to the patch 4, that does not seem to match the
clock-frequency vs. clock phandles practices in DT.
+
+Example:
+
+mspi@18047000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = brcm,mspi;
+ reg = 0x18047000 0x1000;
+ clocks = axi41_clk;
+ clock-names = mspi_clk;
+ clock-frequency = 1250;
Since interrupts is a mandatory property you might want the example to
show it for consistency.
--
Florian
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Hi! enable-gpios: Specifier of the GPIO connected to EN pin I can make the changes if you're ok with that, otherwise please send v7. Then I'll apply that to my tree. I'm ok with that. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] spi: bcm-mspi: Add support to set serial baud clock rate
Le 02/04/2015 12:23, Jonathan Richardson a écrit :
The driver wasn't setting the SPBR (serial clock baud rate) which caused
it to run at the slowest speed possible. The driver now calculates the
SPBR based on the reference clock frequency resulting in much faster
SPI transfers.
Signed-off-by: Jonathan Richardson jonat...@broadcom.com
---
[snip]
+ data-clk = devm_clk_get(dev, mspi_clk);
+ if (!IS_ERR(data-clk)) {
+ int ret = clk_prepare_enable(data-clk);
+
+ if (ret 0) {
+ dev_err(dev, failed to enable clock: %d\n, ret);
+ return 0;
+ }
+
+ /* Calculate SPBR if clock-frequency provided. */
+ if (of_property_read_u32(dev-of_node, clock-frequency,
+ desired_rate) = 0) {
+ u32 spbr = clk_get_rate(data-clk) / (2 * desired_rate);
Usually, specifying a clock-frequency property is done when there is
no clock provider available, yet we take this code path only if we could
find a mspi_clk which sounds a litle weird.
Once there is a proper mspi_clk clock, I would make it mandatory for
the clock provider to be able to provide the rate as well?
--
Florian
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
On Sat, Apr 04, 2015 at 07:11:16PM +0200, Pavel Machek wrote: Hi! enable-gpios: Specifier of the GPIO connected to EN pin I can make the changes if you're ok with that, otherwise please send v7. Then I'll apply that to my tree. I'm ok with that. Thanks. The patch is applied here: git://linuxtv.org/sailus/media_tree.git, branch adp1653 -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about shared interrupts in devicetree
Hi,
i'm currently working on drivers (regulator and power switch) for a power
subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts for the
power subsystem which share the same interrupt line. This interrupt line is
needed by both drivers (regulator and power switch).
Now the question what is the right way (tm) to specify the interrupt in the
devicetree and fetch the irq number during driver probe?
Option A (define interrupt in parent node):
power: power@80044000 {
compatible = fsl,imx28-power, syscon;
reg = 0x80044000 0x2000;
interrupts = 6;
reg_vddd: regulator@1 {
compatible = fsl,imx28-vddd;
};
pswitch: pswitch@5 {
compatible = fsl,mxs-pswitch;
linux,code = 116;
};
}
int irq = irq_of_parse_and_map(parent, 0);
Option B (define interrupt for each child node):
power: power@80044000 {
compatible = fsl,imx28-power, syscon;
reg = 0x80044000 0x2000;
reg_vddd: regulator@1 {
compatible = fsl,imx28-vddd;
interrupts = 6;
};
pswitch: pswitch@5 {
compatible = fsl,mxs-pswitch;
linux,code = 116;
interrupts = 6;
};
}
int irq = platform_get_irq(pdev, 0);
Best regards
Stefan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device nodes in device tree
On Saturday 04 April 2015 12:08:36 Florian Fainelli wrote: Le 30/03/2015 12:35, Alan Stern a écrit : On Mon, 30 Mar 2015, Valentin Longchamp wrote: Hello, We are currently developing a board with an USB MFD device (I2C and GPIOs are to be supported). The device is soldered on the board and is the only one on the bus, so the bus is not really dynamic. Since it's an USB device, it should be dynamically detected by the kernel and it would not require a node in the board's DTS. However, I need to have the devices which are behind the MFD USB device to be in the DTS (I2C bus topology, and some of the GPIOs are to be used directly by some other DTS nodes as well). Is there a way to add a node for USB device in a DTS ? Is there an available example for this ? No, there is no way to do it as far as I know. The main problem is that Device Tree is static whereas USB devices are dynamic. The PCI(e) bus has the same problem, yet you can specify a PCI device child node, and have a compatible string which will match the vendor id/device id tuple, device class etc... such that you can use Device Tree to add additional information not necessarily available in other ways such as MAC addresses and similar. Once the PCI bus is scanned, pci_device present in Device Tree get a device_node pointer assigned. I don't think there is anything doing this yet for USB devices, but maybe that's something that should be there? It's come up a number of times. Basically we should support this, and I believe it's relatively straightforward to do, someone just has to implement it, but setting the of_node pointer for a USB device that gets added and if that has a matching node. There is a binding for USB that we never implemented in Linux. It used to be at http://playground.sun.com/1275/bindings/usb/usb-1_0.ps and I can send a copy to anyone that needs one. Most of the contents are irrelevant unless you want to implement a full Open Firmware rather than a flattened device tree. The important parts are: #address-cells: needs to be 1 #size-cells: needs to be 0 reg: 'The reg property for a device node shall consist of the number of the USB hub port or the USB host controller port to which this USB device is attached. As specified in [2] section 11.11.2.1, port numbers range from 1 to 255.' Arnd -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
