Re: [PATCH] Documentation: dt: update ti,am33xx-hsmmc swakeup workaround
* Andreas Fenkart [150707 10:55]:
> Before 5b83b2234be6733cf the driver was hard coding the wakeup irq to
> be active low. The generic pm wakeirq does not override the active
> high/low parameter, hence it must be specified correctly in the
> device tree.
> Mind that SDIO IRQ is active low as defined in the SDIO specification
>
> Signed-off-by: Andreas Fenkart
> ---
> Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> index 76bf087..74166a0 100644
> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -102,7 +102,7 @@ not every application needs SDIO irq, e.g. MMC cards.
> pinctrl-1 = <&mmc1_idle>;
> pinctrl-2 = <&mmc1_sleep>;
> ...
> - interrupts-extended = <&intc 64 &gpio2 28 0>;
> + interrupts-extended = <&intc 64 &gpio2 28 GPIO_ACTIVE_LOW>;
> };
>
> mmc1_idle : pinmux_cirq_pin {
Looks good to me:
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: Extend exynos5420-pinctrl nodes using labels instead of paths
A previously defined Device Tree node, can be extended either by defining
a node using the same full path or by creating a label for the node and
referencing to it.
Using full paths is more error prone since if there was a typo error, a
new node will be created instead of extending the node as it was desired.
This will lead to run-time errors that could be hard to detect.
A misstyped label on the other hand, will cause a dtc compile error which
makes it easier to detect the mistake since happens at build-time instead.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 1411 ++---
1 file changed, 705 insertions(+), 706 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index 8b153166ebdb..130563b2ca95 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -12,711 +12,710 @@
* published by the Free Software Foundation.
*/
-/ {
- pinctrl@1340 {
- gpy7: gpy7 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpx0: gpx0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- interrupt-parent = <&combiner>;
- #interrupt-cells = <2>;
- interrupts = <23 0>, <24 0>, <25 0>, <25 1>,
-<26 0>, <26 1>, <27 0>, <27 1>;
- };
-
- gpx1: gpx1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- interrupt-parent = <&combiner>;
- #interrupt-cells = <2>;
- interrupts = <28 0>, <28 1>, <29 0>, <29 1>,
-<30 0>, <30 1>, <31 0>, <31 1>;
- };
-
- gpx2: gpx2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpx3: gpx3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- dp_hpd: dp_hpd {
- samsung,pins = "gpx0-7";
- samsung,pin-function = <3>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
- };
- };
-
- pinctrl@1341 {
- gpc0: gpc0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc1: gpc1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc2: gpc2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc3: gpc3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc4: gpc4 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpd1: gpd1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpy0: gpy0 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy1: gpy1 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy2: gpy2 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy3: gpy3 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy4: gpy4 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy5: gpy5 {
- gpio-controller;
-
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Wed, Jul 08, 2015 at 10:37:21AM +0800, Eddie Huang wrote:
> On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote:
> > On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer
> > wrote:
> > > On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> > >> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer
> > >> wrote:
> > >> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> > >> >> Add clk_null, which represents clocks that can not / need not
> > >> >> controlled by software.
> > >> >> There are many clocks' parent set to clk_null.
> > >> >>
> > >> >> Signed-off-by: James Liao
> > >> >> Signed-off-by: Eddie Huang
> > >> >> ---
> > >> >> Base on 4.1-rc1
> > >> >>
> > >> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> > >> >> ---
> > >> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
> > >> >> 1 file changed, 6 insertions(+)
> > >> >>
> > >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> index 924fdb6..4798f44 100644
> > >> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> @@ -81,6 +81,12 @@
> > >> >> cpu_on= <0x8403>;
> > >> >> };
> > >> >>
> > >> >> + clk_null: clk_null {
> > >> >> + compatible = "fixed-clock";
> > >> >> + clock-frequency = <0>;
> > >> >> + #clock-cells = <0>;
> > >> >> + };
> > >> >
> > >> > The discussion around this patch shows that we don't want to have this
> > >> > clock in the device tree as it is not a hardware description.
> > >> >
> > >> > Ok, fine. Eddie, you told us that the rate of the current clk_null
> > >> > children
> > >> > is not interesting. What's the motivation to send this patch anyway
> > >> > then? Why can't you keep its children on the orphan list where they are
> > >> > already now?
> > >> >
> > >> > Another possibility would be to instantiate the clk_null clock from C
> > >> > code rather than from the device tree. This way we wouldn't put any
> > >> > wrong descriptions into the device tree and still can implement the
> > >> > support for the real parent clocks when we actually need them.
> > >>
> > >> Some device nodes, like mmc, use a clk_null phandle as one of their
> > >> clocks:
> > >>
> > >> mmc1: mmc@1124 {
> > >> compatible = "mediatek,mt8173-mmc",
> > >> "mediatek,mt8135-mmc";
> > >> reg = <0 0x1124 0 0x1000>;
> > >> interrupts = ;
> > >> clocks = <&pericfg CLK_PERI_MSDC30_1>,
> > >> <&clk_null>;
> > >> clock-names = "source", "hclk";
> > >> status = "disabled";
> > >> };
> > >
> > > This is another case than the one we discussed about. In the case above
> > > I motivated using a dummy clock since the clock exists in the system,
> > > but is not software controllable. To abstract this from the driver
> > > (which needs this clock since it exists) we here have the dummy clock.
> > > However, of course I can't prove the clock is indeed not software
> > > controllable; that's only the information I have.
> >
> > I was trying to answer your question "What's the motivation to send
> > this patch anyway?".
> > The motivation is to send follow on patches that use the clk_null
> > phandle. We need to provide some clock as the mmc1's hclk. I do not
> > understand why this has to be "clk_null", though. It seems like this
> > should be a real clock coming from one of the real clock_controller
> > nodes. After all, the mmc driver is going to be enabling/disabling
> > this clock for power savings at runtime. What does that even mean for
> > clk_null ?
>
> The original purpose of this patch is to provide a common dummy clock
> for both software don't care clock and clock that is not software
> controllable.I got comments that device tree should describe hardware
> and should put exact clock in device tree. I think this is true. So we
> will remove this clock_null patch, and:
>
> 1. For Mediatek SoC CCF driver, James will clarify clock usage further.
> Actually, we still think it's not necessary to describe whole tree that
> software don't care, James will deal this in clock driver.
I think that aswell since the device tree is not affected in this case.
Should we realize later that we indeed need the missing clocks we can
still implement them without modifying the device tree.
>
> 2. For other module that use SW not controllable clock (mmc case
> mentioned by Dan), because this is a real clock, we will put a dummy
> clock in device tree, like
>
> clk_mmchclk: dummyhclk {
> compatible = "fixed-clock";
> clock-frequency = <0>;
> #clock-cells = <0>;
> };
>
> How about this modification ?
I wouldn't name it 'dummy', this will again raise some eyebrows.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengut
[PATCH 2/4] ARM: dts: Extend exynos5250-pinctrl nodes using labels instead of paths
A previously defined Device Tree node, can be extended either by defining
a node using the same full path or by creating a label for the node and
referencing to it.
Using full paths is more error prone since if there was a typo error, a
new node will be created instead of extending the node as it was desired.
This will lead to run-time errors that could be hard to detect.
A misstyped label on the other hand, will cause a dtc compile error which
makes it easier to detect the mistake since happens at build-time instead.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 1600 ++---
1 file changed, 799 insertions(+), 801 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 886cfca044ac..880917e508b2 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -12,807 +12,805 @@
* published by the Free Software Foundation.
*/
-/ {
- pinctrl@1140 {
- gpa0: gpa0 {
- gpio-controller;
- #gpio-cells = <2>;
+&pinctrl_0 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpa1: gpa1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpa2: gpa2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb0: gpb0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb1: gpb1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb2: gpb2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb3: gpb3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc0: gpc0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc1: gpc1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc2: gpc2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc3: gpc3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpd0: gpd0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpd1: gpd1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpy0: gpy0 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy1: gpy1 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy2: gpy2 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy3: gpy3 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy4: gpy4 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy5: gpy5 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy6: gpy6 {
-
[PATCH 1/4] ARM: dts: Include exynos5250-pinctrl after the nodes were defined
The dtc compiler combines all the defined nodes that have the same path so a device node definition can be in one file and later be extended in another one. That's the case of the Exynos5250 pinctrl device nodes that are defined in the exynos5250.dtsi file and extended in exynos5250-pinctrl.dtsi. But since the exynos5250.dtsi file includes the exynos5250-pinctrl.dtsi before the pinctrl device nodes are actually defined, the definition of the pinctrl device nodes happens in exynos5250-pinctrl.dtsi and are extended in exynos5250.dtsi. That is the opposite of the original intention so even when there is no difference in practice, the exynos5250-pinctrl.dtsi include should be moved at the end of the exynos5250.dtsi file after the pinctrl device nodes have been already defined. This will also allow to later change the exynos5250-pinctrl.dtsi file to use labels instead of full paths to extend the pinctrl nodes. Since keeping the include at the top, would cause a dtc build error due the pinctrl labels not being defined yet. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos5250.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index bf9bee67c416..4a1f88300a28 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -19,7 +19,6 @@ #include #include "exynos5.dtsi" -#include "exynos5250-pinctrl.dtsi" #include "exynos4-cpu-thermal.dtsi" #include @@ -1062,3 +1061,5 @@ clocks = <&clock CLK_UART3>, <&clock CLK_SCLK_UART3>; clock-names = "uart", "clk_uart_baud0"; }; + +#include "exynos5250-pinctrl.dtsi" -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: Include exynos5420-pinctrl after the nodes were defined
The dtc compiler combines all the defined nodes that have the same path so a device node definition can be in one file and later be extended in another one. That's the case of the Exynos5420 pinctrl device nodes that are defined in the exynos5420.dtsi file and extended in exynos5420-pinctrl.dtsi. But since the exynos5420.dtsi file includes the exynos5420-pinctrl.dtsi before the pinctrl device nodes are actually defined, the definition of the pinctrl device nodes happens in exynos5420-pinctrl.dtsi and are extended in exynos5420.dtsi. That is the opposite of the original intention so even when there is no difference in practice, the exynos5420-pinctrl.dtsi include should be moved at the end of the exynos5420.dtsi file after the pinctrl device nodes have been already defined. This will also allow to later change the exynos5420-pinctrl.dtsi file to use labels instead of full paths to extend the pinctrl nodes. Since keeping the include at the top, would cause a dtc build error due the pinctrl labels not being defined yet. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos5420.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index 534f27ceb10b..df9aee92ecf4 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -15,7 +15,6 @@ #include #include "exynos5.dtsi" -#include "exynos5420-pinctrl.dtsi" #include @@ -1166,3 +1165,5 @@ clocks = <&clock CLK_UART3>, <&clock CLK_SCLK_UART3>; clock-names = "uart", "clk_uart_baud0"; }; + +#include "exynos5420-pinctrl.dtsi" -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: dts: Use labels instead of full paths for Exynos5 pinctrl nodes
Hello Kukjin and Krzysztof, This is a trivial series that changes Exynos5 pinctrl dtsi files to extend the pinctrl nodes using labels instead of full paths. Using labels is less error prone since a misstyped label leads to a build error while full paths can lead to the creation of a new node instead of overriding the original which makes the mistake harder to detect. I tested the changes by decompiling the Exynos5* dtbs and comparing before and after. The resulting dts were identical modulo some node ordering due the pinctrl include change. The series is composed of the following trivial patches: Javier Martinez Canillas (4): ARM: dts: Include exynos5250-pinctrl after the nodes were defined ARM: dts: Extend exynos5250-pinctrl nodes using labels instead of paths ARM: dts: Include exynos5420-pinctrl after the nodes were defined ARM: dts: Extend exynos5420-pinctrl nodes using labels instead of paths arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 1600 ++--- arch/arm/boot/dts/exynos5250.dtsi |3 +- arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 1411 + arch/arm/boot/dts/exynos5420.dtsi |3 +- 4 files changed, 1508 insertions(+), 1509 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] iio: light: add support for APDS9660 sensor
This patchset adds support for the APDS9960 ALS + proximity + gesture sensor. Included support for the various adjustable settings and controls: * Falling and rising ALS + proximity thresholds events * Gain controls * ALS time integration Changes from v1: * Reworded sysfs-bus-iio-apds9960 to be more clear about gesture features * Changed gain setting from IIO_CHAN_INFO_CALIBSCALE to IIO_CHAN_INFO_SCALE * Removed superfluous information in iio_chan_spec channels * Fixed likely buffer overrun issue * Make mutex and gain + it setting logic more clear * Fixed typos in comments Matt Ranostay (2): iio: light: DT binding docs for APDS9960 driver iio: light: add APDS9960 ALS + promixity driver .../ABI/testing/sysfs-bus-iio-light-apds9960 | 128 +++ .../devicetree/bindings/iio/light/apds9960.txt | 19 + drivers/iio/light/Kconfig | 12 + drivers/iio/light/Makefile |1 + drivers/iio/light/apds9960.c | 1214 5 files changed, 1374 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-light-apds9960 create mode 100644 Documentation/devicetree/bindings/iio/light/apds9960.txt create mode 100644 drivers/iio/light/apds9960.c -- 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 1/2] iio: light: DT binding docs for APDS9960 driver
Document compatible string, and required DT properties for APDS9960
chipset driver.
Reviewed-by: Marek Vasut
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/iio/light/apds9960.txt| 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/apds9960.txt
diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt
b/Documentation/devicetree/bindings/iio/light/apds9960.txt
new file mode 100644
index 000..7a47d28
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/apds9960.txt
@@ -0,0 +1,19 @@
+* Avago APDS9960 gesture/RGB/ALS/proximity sensor
+
+http://www.avagotech.com/docs/AV02-4191EN
+
+Required properties:
+
+ - compatible: must be "avago,apds9960"
+ - reg: the I2c address of the sensor
+ - interrupt-parent: should be the phandle for the interrupt controller
+ - interrupts: interrupt mapping for GPIO IRQ
+
+Example:
+
+apds9960@39 {
+ compatible = "avago,apds9960";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 1>;
+};
--
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 2/2] iio: light: add APDS9960 ALS + promixity driver
APDS9960 is a combination of ALS, proximity, and gesture sensors. This patch adds support for these functions along with gain control, integration time, and event thresholds. Signed-off-by: Matt Ranostay --- .../ABI/testing/sysfs-bus-iio-light-apds9960 | 128 +++ drivers/iio/light/Kconfig | 12 + drivers/iio/light/Makefile |1 + drivers/iio/light/apds9960.c | 1214 4 files changed, 1355 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-light-apds9960 create mode 100644 drivers/iio/light/apds9960.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960 b/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960 new file mode 100644 index 000..010b8c8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960 @@ -0,0 +1,128 @@ +What: /sys/bus/iio/devices/triggerX/name = "apds9960-gestureX" +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + The APDS9960 kernel module provides a trigger which enables + the gesture engine that pushes motion data to the buffer when + it becomes available. + +What /sys/bus/iio/devices/iio:deviceX/in_proximity0_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the non-gesture proximity sensor value. + +What /sys/bus/iio/devices/iio:deviceX/in_proximity1_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the UP gesture photodiode proximity value. + Access is disabled to prevent the side effect of + userspace clearing the hardware FIFO. + +What /sys/bus/iio/devices/iio:deviceX/in_proximity2_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the DOWN gesture photodiode proximity value. + Access is disabled to prevent the side effect of + userspace clearing the hardware FIFO. + +What /sys/bus/iio/devices/iio:deviceX/in_proximity3_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the LEFT gesture photodiode proximity value. + Access is disabled to prevent the side effect of + userspace clearing the hardware FIFO. + +What /sys/bus/iio/devices/iio:deviceX/in_proximity4_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the RIGHT gesture photodiode proximity value. + Access is disabled to prevent the side effect of + userspace clearing the hardware FIFO. + +What /sys/bus/iio/devices/iio:deviceX/in_intensity_clear_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the current unprocessed illuminance for the clear/ALS + photodiode. + +What /sys/bus/iio/devices/iio:deviceX/in_intensity_red_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the current unprocessed illuminance value for the + red light wavelength photodiode. + +What /sys/bus/iio/devices/iio:deviceX/in_intensity_green_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the current unprocessed illuminance value for the + green light wavelength photodiode. + +What /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_raw +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Get the current unprocessed illuminance value for the + blue light wavelength photodiode. + +What /sys/bus/iio/devices/iio:deviceX/integration_time_available +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Provide allowed integration time values in fractions of a second + for the ALS + RGB sensor engines. + +What /sys/bus/iio/devices/iio:deviceX/in_intensity_integration_time +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Set integration time in fractions of a second for the ALS + RGB + sensor engines. + +What /sys/bus/iio/devices/iio:deviceX/proximity_scale_available +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Provide the allowed gain values for the proximity + gesture + engines. + +What /sys/bus/iio/devices/iio:deviceX/in_proximity_scale +Date: July 2015 +KernelVersion: 4.2 +Contact: Matt Ranostay +Description: + Set the gain value for t
Re: [PATCH v6 23/23] usb: gadget: zero: allocate and init otg descriptor by otg capabilities
On Tue, Jul 07, 2015 at 04:55:16PM +0300, Roger Quadros wrote:
>
> On 29/06/15 10:48, Li Jun wrote:
> >Allocate and initialize usb otg descriptor according to gadget otg
> >capabilities, add it for each usb configurations. If otg capability
> >is not defined, keep its original otg descriptor unchanged.
> >
> >Signed-off-by: Li Jun
> >---
> > drivers/usb/gadget/legacy/zero.c | 32 ++--
> > 1 file changed, 14 insertions(+), 18 deletions(-)
> >
> >diff --git a/drivers/usb/gadget/legacy/zero.c
> >b/drivers/usb/gadget/legacy/zero.c
> >index c986e8a..695c2cb 100644
> >--- a/drivers/usb/gadget/legacy/zero.c
> >+++ b/drivers/usb/gadget/legacy/zero.c
> >@@ -121,24 +121,7 @@ static struct usb_device_descriptor device_desc = {
> > .bNumConfigurations = 2,
> > };
> >
> >-#ifdef CONFIG_USB_OTG
> >-static struct usb_otg_descriptor otg_descriptor = {
> >-.bLength = sizeof otg_descriptor,
> >-.bDescriptorType = USB_DT_OTG,
> >-
> >-/* REVISIT SRP-only hardware is possible, although
> >- * it would not be called "OTG" ...
> >- */
> >-.bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
> >-};
> >-
> >-static const struct usb_descriptor_header *otg_desc[] = {
> >-(struct usb_descriptor_header *) &otg_descriptor,
> >-NULL,
> >-};
> >-#else
> >-#define otg_descNULL
> >-#endif
> >+static const struct usb_descriptor_header *otg_desc[2];
> >
> > /* string IDs are assigned dynamically */
> > /* default serial number takes at least two packets */
> >@@ -341,6 +324,16 @@ static int zero_bind(struct usb_composite_dev *cdev)
> >
> > /* support OTG systems */
> > if (gadget_is_otg(cdev->gadget)) {
> >+if (!otg_desc[0]) {
> >+struct usb_descriptor_header *usb_desc;
> >+
> >+usb_desc = usb_otg_descriptor_alloc(cdev->gadget);
> >+if (!usb_desc)
> >+return -ENOMEM;
> >+usb_otg_descriptor_init(cdev->gadget, usb_desc);
> >+otg_desc[0] = usb_desc;
> >+otg_desc[1] = NULL;
> >+}
>
> There is an error condition in zero_bind(). You need to free the
> otg_descriptor there.
>
Good catch, I will add error handling for the 3 patches you found this
problem.
Li Jun
> > sourcesink_driver.descriptors = otg_desc;
> > sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
> > loopback_driver.descriptors = otg_desc;
> >@@ -397,6 +390,9 @@ static int zero_unbind(struct usb_composite_dev *cdev)
> > if (!IS_ERR_OR_NULL(func_lb))
> > usb_put_function(func_lb);
> > usb_put_function_instance(func_inst_lb);
> >+kfree(otg_desc[0]);
> >+otg_desc[0] = NULL;
> >+
> > return 0;
> > }
> >
> >
>
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: UniPhier: add USB EHCI device nodes
Hi Rob,
2015-07-07 23:53 GMT+09:00 Rob Herring :
> On Sun, Jul 5, 2015 at 10:47 PM, Masahiro Yamada
> wrote:
>> Get USB 2.0 host controllers available with generic-ehci bindings.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>
>> diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> index 1261e6d..b042711 100644
>> --- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> +++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> @@ -127,6 +127,27 @@
>> reg = <0x5980 0x2000>;
>> };
>>
>> + usb0: usb@5a800100 {
>> + compatible = "generic-ehci";
>
> You should also have a chip specific compatible string in addition to
> generic-ehci.
OK, will do.
I will wait a bit more before sending v2
in case someone might have some comments on this series.
--
Best Regards
Masahiro Yamada
--
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 v6 08/23] usb: chipidea: set usb otg capabilities
On Tue, Jul 07, 2015 at 04:25:44PM +0300, Roger Quadros wrote:
> On 29/06/15 10:47, Li Jun wrote:
> >Init and update otg capabilities by DT, set gadget's otg capabilities
> >accordingly.
> >
> >Signed-off-by: Li Jun
> >---
> > drivers/usb/chipidea/core.c | 10 ++
> > drivers/usb/chipidea/udc.c | 7 ++-
> > include/linux/usb/chipidea.h | 1 +
> > 3 files changed, 17 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> >index 74fea4f..248f571 100644
> >--- a/drivers/usb/chipidea/core.c
> >+++ b/drivers/usb/chipidea/core.c
> >@@ -588,6 +588,16 @@ static int ci_get_platdata(struct device *dev,
> > of_usb_host_tpl_support(dev->of_node);
> > }
> >
> >+if (platdata->dr_mode == USB_DR_MODE_OTG) {
> >+/* We can support HNP and SRP of OTG 2.0 */
> >+platdata->ci_otg_caps.otg_rev = 0x0200;
> >+platdata->ci_otg_caps.hnp_support = true;
> >+platdata->ci_otg_caps.srp_support = true;
> >+
> >+/* Update otg capabilities by DT properties */
> >+of_usb_update_otg_caps(dev->of_node, &platdata->ci_otg_caps);
>
> What if this function fails. e.g. DT contains unsupported OTG version?
Just an error print out, otg-rev will be the initial value(0x0200), it will
work as otg 2.0.
> I think we should error out in that case.
>
Disable all otg features? or even stop all usb initialization?
Li Jun
> >+}
> >+
> > if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
> > platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>
> cheers,
> -roger
>
> >
> >diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> >index 764f668..b7cca3e 100644
> >--- a/drivers/usb/chipidea/udc.c
> >+++ b/drivers/usb/chipidea/udc.c
> >@@ -1827,6 +1827,7 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
> > static int udc_start(struct ci_hdrc *ci)
> > {
> > struct device *dev = ci->dev;
> >+struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
> > int retval = 0;
> >
> > spin_lock_init(&ci->lock);
> >@@ -1834,8 +1835,12 @@ static int udc_start(struct ci_hdrc *ci)
> > ci->gadget.ops = &usb_gadget_ops;
> > ci->gadget.speed= USB_SPEED_UNKNOWN;
> > ci->gadget.max_speed= USB_SPEED_HIGH;
> >-ci->gadget.is_otg = ci->is_otg ? 1 : 0;
> > ci->gadget.name = ci->platdata->name;
> >+ci->gadget.otg_caps = otg_caps;
> >+
> >+if (otg_caps->hnp_support || otg_caps->srp_support ||
> >+otg_caps->adp_support)
> >+ci->gadget.is_otg = 1;
> >
> > INIT_LIST_HEAD(&ci->gadget.ep_list);
> >
> >diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> >index ab94f78..e10cefc 100644
> >--- a/include/linux/usb/chipidea.h
> >+++ b/include/linux/usb/chipidea.h
> >@@ -34,6 +34,7 @@ struct ci_hdrc_platform_data {
> > #define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
> > void(*notify_event) (struct ci_hdrc *ci, unsigned event);
> > struct regulator*reg_vbus;
> >+struct usb_otg_caps ci_otg_caps;
> > booltpl_support;
> > };
> >
> >
--
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 v6 07/23] usb: common: add API to update usb otg capabilities by device tree
On Tue, Jul 07, 2015 at 04:23:14PM +0300, Roger Quadros wrote:
> Hi,
>
> On 29/06/15 10:47, Li Jun wrote:
> >Check property of usb hardware to update otg version and disable SRP, HNP
> >and ADP if its disable flag is present.
> >
> >Signed-off-by: Li Jun
> >---
> > drivers/usb/common/common.c | 47
> > +
> > include/linux/usb/of.h | 7 +++
> > 2 files changed, 54 insertions(+)
> >
> >diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> >index b530fd4..10c986b 100644
> >--- a/drivers/usb/common/common.c
> >+++ b/drivers/usb/common/common.c
> >@@ -154,6 +154,53 @@ bool of_usb_host_tpl_support(struct device_node *np)
> > return false;
> > }
> > EXPORT_SYMBOL_GPL(of_usb_host_tpl_support);
> >+
> >+/**
> >+ * of_usb_update_otg_caps - to update usb otg capabilities according to
> >+ * the passed properties in DT.
> >+ * @np: Pointer to the given device_node
> >+ * @otg_caps: Pointer to the target usb_otg_caps to be set
> >+ *
> >+ * The function updates the otg capabilities
> >+ */
> >+int of_usb_update_otg_caps(struct device_node *np,
> >+struct usb_otg_caps *otg_caps)
> >+{
> >+u32 otg_rev;
> >+
> >+if (!otg_caps)
> >+return -EINVAL;
> >+
> >+if (!of_property_read_u32(np, "otg-rev", &otg_rev)) {
> >+switch (otg_rev) {
> >+case 0x0100:
> >+case 0x0120:
> >+case 0x0130:
> >+case 0x0200:
> >+case 0x0300:
>
> we don't support 0x300 yet. I guess it is best to leave it out till
> we have real otg 3.0 support.
>
okay.
> >+otg_caps->otg_rev = otg_rev;
> >+break;
> >+default:
> >+pr_err("%s: unsupported otg-rev: 0x%x\n",
> >+np->full_name, otg_rev);
> >+return -EINVAL;
> >+}
> >+} else {
> >+otg_caps->otg_rev = 0;
>
> Why do we set this to 0 here?
> controller might have set a valid otg_rev and we want to
> maintain it if nothing was passed in DT.
>
Considering otg-rev is mandatory for non-legacy platformsr,
Now you mean what I did in previous version: do not set initial otg-rev
in controller driver, just let it to be 0, and wait it to be updated by DT
or by platform layer code.
Current idea is:
set otg capabilities in controller driver as otg _ability_ like below:
otg-rev = 0x0200;
hnp_support = true;
a) Call to this function to update otg caps if pass by DT, and then/or
b) Update otg caps if some platforms want to update it directly(not by DT).
If both above 2 update not happen, then I need keep otg-rev to be 0 which will
be used to judge this is a legacy platform, so I set otg-rev to be 0 if it not
passed in DT in a).
We also can do this like my previous version:
In controller driver, only set HNP/SRP/ADP as otg ability:
hnp_support = true;
a) Call to this function to update otg caps if pass by DT, and then/or
b) Update otg caps if some platforms want to update it directly(not by DT).
If both above 2 update not happen, otg-rev is still 0, so I need not set it
to be 0 if nothing pass in DT.
Either way is okay I think.
Li Jun
> >+}
> >+
> >+if (of_find_property(np, "hnp-disable", NULL))
> >+otg_caps->hnp_support = false;
> >+if (of_find_property(np, "srp-disable", NULL))
> >+otg_caps->srp_support = false;
> >+if (of_find_property(np, "adp-disable", NULL) ||
> >+(otg_caps->otg_rev < 0x0200))
> >+otg_caps->adp_support = false;
> >+
> >+return 0;
> >+}
> >+EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
> >+
> > #endif
>
> cheers,
> -roger
>
> >
> > MODULE_LICENSE("GPL");
> >diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
> >index cfe0528..8c5a818 100644
> >--- a/include/linux/usb/of.h
> >+++ b/include/linux/usb/of.h
> >@@ -15,6 +15,8 @@
> > enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
> > enum usb_device_speed of_usb_get_maximum_speed(struct device_node *np);
> > bool of_usb_host_tpl_support(struct device_node *np);
> >+int of_usb_update_otg_caps(struct device_node *np,
> >+struct usb_otg_caps *otg_caps);
> > #else
> > static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
> > {
> >@@ -30,6 +32,11 @@ static inline bool of_usb_host_tpl_support(struct
> >device_node *np)
> > {
> > return false;
> > }
> >+static inline int of_usb_update_otg_caps(struct device_node *np,
> >+struct usb_otg_caps *otg_caps)
> >+{
> >+return 0;
> >+}
> > #endif
> >
> > #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] powerpc/85xx: Add binding for SCFG
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 08, 2015 3:50 AM
> To: Wang Dongsheng-B40534
> Cc: robh...@kernel.org; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
> Jain Priyanka-B32167; devicetree@vger.kernel.org
> Subject: Re: [PATCH 1/2] powerpc/85xx: Add binding for SCFG
>
> On Tue, 2015-07-07 at 17:47 +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng
> >
> > SCFG provides SoC specific configuration and status registers for the
> > chip. Add this for powerpc platform.
> >
> > Signed-off-by: Wang Dongsheng
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > index cff38bd..55604fe 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > @@ -3,6 +3,25 @@ Freescale Reference Board Bindings This document
> > describes device tree bindings for various devices that exist on some
> > Freescale reference boards.
> >
> > +* Supplement configuration unit (SCFG)
> > +
> > +SCFG is the supplemental configuration unit, that provides SoC
> > +specific configuration and status registers for the chip. Such as
> > +getting PEX port status.
> > +
> > +Required properties:
> > +
> > +- compatible: should be "fsl,-scfg"
>
> fsl,-scfg
Thanks.
> > +- reg: should contain base address and length of SCFG memory-mapped
> > +registers
> > +
> > +Example:
> > +
> > + scfg: global-utilities@fc000{
> > + compatible = "fsl,t1040-scfg";
> > + reg = <0xfc000 0x1000>;
> > + };
> > +
>
> I don't think board.txt is the right place for this, since it's part of the
> SoC,
> not the board. Put it in its own file.
OK, will put it in Documentation/devicetree/bindings/powerpc/fsl/scfg.txt.
Regards,
-Dongsheng
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote:
> On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer wrote:
> > On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> >> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer
> >> wrote:
> >> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> >> >> Add clk_null, which represents clocks that can not / need not
> >> >> controlled by software.
> >> >> There are many clocks' parent set to clk_null.
> >> >>
> >> >> Signed-off-by: James Liao
> >> >> Signed-off-by: Eddie Huang
> >> >> ---
> >> >> Base on 4.1-rc1
> >> >>
> >> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> >> >> ---
> >> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
> >> >> 1 file changed, 6 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> index 924fdb6..4798f44 100644
> >> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> @@ -81,6 +81,12 @@
> >> >> cpu_on= <0x8403>;
> >> >> };
> >> >>
> >> >> + clk_null: clk_null {
> >> >> + compatible = "fixed-clock";
> >> >> + clock-frequency = <0>;
> >> >> + #clock-cells = <0>;
> >> >> + };
> >> >
> >> > The discussion around this patch shows that we don't want to have this
> >> > clock in the device tree as it is not a hardware description.
> >> >
> >> > Ok, fine. Eddie, you told us that the rate of the current clk_null
> >> > children
> >> > is not interesting. What's the motivation to send this patch anyway
> >> > then? Why can't you keep its children on the orphan list where they are
> >> > already now?
> >> >
> >> > Another possibility would be to instantiate the clk_null clock from C
> >> > code rather than from the device tree. This way we wouldn't put any
> >> > wrong descriptions into the device tree and still can implement the
> >> > support for the real parent clocks when we actually need them.
> >>
> >> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
> >>
> >> mmc1: mmc@1124 {
> >> compatible = "mediatek,mt8173-mmc",
> >> "mediatek,mt8135-mmc";
> >> reg = <0 0x1124 0 0x1000>;
> >> interrupts = ;
> >> clocks = <&pericfg CLK_PERI_MSDC30_1>,
> >> <&clk_null>;
> >> clock-names = "source", "hclk";
> >> status = "disabled";
> >> };
> >
> > This is another case than the one we discussed about. In the case above
> > I motivated using a dummy clock since the clock exists in the system,
> > but is not software controllable. To abstract this from the driver
> > (which needs this clock since it exists) we here have the dummy clock.
> > However, of course I can't prove the clock is indeed not software
> > controllable; that's only the information I have.
>
> I was trying to answer your question "What's the motivation to send
> this patch anyway?".
> The motivation is to send follow on patches that use the clk_null
> phandle. We need to provide some clock as the mmc1's hclk. I do not
> understand why this has to be "clk_null", though. It seems like this
> should be a real clock coming from one of the real clock_controller
> nodes. After all, the mmc driver is going to be enabling/disabling
> this clock for power savings at runtime. What does that even mean for
> clk_null ?
The original purpose of this patch is to provide a common dummy clock
for both software don't care clock and clock that is not software
controllable.I got comments that device tree should describe hardware
and should put exact clock in device tree. I think this is true. So we
will remove this clock_null patch, and:
1. For Mediatek SoC CCF driver, James will clarify clock usage further.
Actually, we still think it's not necessary to describe whole tree that
software don't care, James will deal this in clock driver.
2. For other module that use SW not controllable clock (mmc case
mentioned by Dan), because this is a real clock, we will put a dummy
clock in device tree, like
clk_mmchclk: dummyhclk {
compatible = "fixed-clock";
clock-frequency = <0>;
#clock-cells = <0>;
};
How about this modification ?
Thanks
Eddie
--
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] power_supply: rt9455_charger: Properly notify userspace about charging events
2015-07-07 21:25 GMT+09:00 Anda-Maria Nicolae : > Charging events this patch refers to are: > - charger is connected to/disconnected from the power source > - battery is reconnected to the charger, after it was absent. > > When the charger is connected to/disconnected from the power source, CHRVPI > interrupt occurs and PWR_RDY bit is either set or cleared. PWR_RDY bit is > updated after 1-2 seconds CHRVPI interrupt has occurred. > power_supply_changed() should be called after PWR_RDY bit is updated. > /sys/class/power_supply/rt9455-charger/online file displays the value of > PWR_RDY bit. > This way, if the userspace is notified that a charging event has occurred > and the userspace reads /sys/class/power_supply/rt9455-charger/online file, > this file is properly updated when the userspace reads it. > This is the reason why power_supply_changed() is called in > rt9455_pwr_rdy_work_callback(), instead of being called in interrupt > handler. > > Since no interrupt is triggered when the battery is reconnected to the > charger, the userspace is never notified that the battery is reconnected. > This is why power_supply_changed() is called in > rt9455_max_charging_time_work_callback(), so that the userspace is notified > that the battery is reconnected. > > Signed-off-by: Anda-Maria Nicolae > --- > > Updates from v1 version: > - I have followed Kzrysztof's suggestion and I have added explanations in > the commit message so that the change is more clear > - Code is the same as in v1 Thanks, FWIW: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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: shmobile: kzm9g dts: Use adxl345-specific compatible property
On Tue, Jul 07, 2015 at 09:56:29AM +0300, Laurent Pinchart wrote:
> Hi Simon,
>
> On Tuesday 07 July 2015 09:26:21 Simon Horman wrote:
> > On Mon, Jul 06, 2015 at 04:29:33PM +0300, Laurent Pinchart wrote:
> > > On Monday 06 July 2015 12:55:32 Geert Uytterhoeven wrote:
> > > > Replace the deprecated generic "adi,adxl34x" compatible value by the
> > > > adxl345-specific "adi,adxl345" value, cfr. commit e465bf6fc55d5ce2 ("DT:
> > > > i2c: Deprecate adi,adxl34x compatible string").
> > > >
> > > > Signed-off-by: Geert Uytterhoeven
> > >
> > > Acked-by: Laurent Pinchart
> > >
> > > > ---
> > > > Depends on commit 3a38958d2477b718 ("Input: adxl34x - add OF match
> > > > support"), which is in v4.2-rc1.
> > > >
> > > > This is v2 of "ARM: shmobile: kzm9g dts: Add adxl345-specific compatible
> > > > property".
> >
> > It appears to me that this will cause a regression when booting old kernels
> > with new dts blobs. For that reason think we should consider v1
> > of this change coupled with a schedule to remove use of the deprecated
> > compat string.
>
> That's the forward compatibility that Geert mentioned, is that really an
> issue, especially on this board ?
I think it would be best to provide backwards compatibility unless there
is a compelling reason not to.
--
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/4] irqchip: bcm2835: If a parent interrupt is registered, chain from it.
The BCM2836 (Raspberry Pi 2) uses two levels of interrupt handling
with the CPU-local interrupts being the root, so we need to register
ours as chained off of the CPU's local interrupt.
Signed-off-by: Eric Anholt
---
.../brcm,bcm2835-armctrl-ic.txt| 22 ++
drivers/irqchip/irq-bcm2835.c | 20 ++--
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
index 7da578d..8363bc4 100644
---
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+++
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
@@ -5,6 +5,10 @@ The BCM2835 contains a custom top-level interrupt controller,
which supports
controller, or the HW block containing it, is referred to occasionally
as "armctrl" in the SoC documentation, hence naming of this binding.
+The BCM2836 contains the same interrupt controller with the same
+interrupts, but the per-CPU interrupt controller is the root, and an
+interrupt there indicates that the ARMCTRL has an interrupt to handle.
+
Required properties:
- compatible : should be "brcm,bcm2835-armctrl-ic"
@@ -20,6 +24,12 @@ Required properties:
The 2nd cell contains the interrupt number within the bank. Valid values
are 0..7 for bank 0, and 0..31 for bank 1.
+Optional properties:
+- interrupt-parent : Specifies the parent interrupt controller when this
+ controller is the second level.
+- interrupts : Specifies the interrupt on the parent for this interrupt
+ controller to handle.
+
The interrupt sources are as follows:
Bank 0:
@@ -102,9 +112,21 @@ Bank 2:
Example:
+/* BCM2835, first level */
+intc: interrupt-controller {
+ compatible = "brcm,bcm2835-armctrl-ic";
+ reg = <0x7e00b200 0x200>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
+
+/* BCM2836, second level */
intc: interrupt-controller {
compatible = "brcm,bcm2835-armctrl-ic";
reg = <0x7e00b200 0x200>;
interrupt-controller;
#interrupt-cells = <2>;
+
+ interrupt-parent = <&local_intc>;
+ interrupts = <8>;
};
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 382450a..dc6b159 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -97,6 +97,7 @@ struct armctrl_ic {
static struct armctrl_ic intc __read_mostly;
static void __exception_irq_entry bcm2835_handle_irq(
struct pt_regs *regs);
+static void bcm2835_chained_handle_irq(unsigned int irq, struct irq_desc
*desc);
static void armctrl_mask_irq(struct irq_data *d)
{
@@ -143,7 +144,7 @@ static int __init armctrl_of_init(struct device_node *node,
struct device_node *parent)
{
void __iomem *base;
- int irq, b, i;
+ int irq, parent_irq, b, i;
base = of_iomap(node, 0);
if (!base)
@@ -169,7 +170,14 @@ static int __init armctrl_of_init(struct device_node *node,
}
}
- set_handle_irq(bcm2835_handle_irq);
+ parent_irq = irq_of_parse_and_map(node, 0);
+ if (!parent_irq) {
+ /* No parent IRQ, so we're the root interrupt controller */
+ set_handle_irq(bcm2835_handle_irq);
+ } else {
+ irq_set_chained_handler(parent_irq, bcm2835_chained_handle_irq);
+ }
+
return 0;
}
@@ -220,4 +228,12 @@ static void __exception_irq_entry bcm2835_handle_irq(
handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
}
+static void bcm2835_chained_handle_irq(unsigned int irq, struct irq_desc *desc)
+{
+ u32 hwirq;
+
+ while ((hwirq = get_next_armctrl_hwirq()) != ~0)
+ generic_handle_irq(irq_linear_revmap(intc.domain, hwirq));
+}
+
IRQCHIP_DECLARE(bcm2835_armctrl_ic, "brcm,bcm2835-armctrl-ic",
armctrl_of_init);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2.
This interrupt controller is the new root interrupt controller with
the timer, PMU events, and IPIs, and the bcm2835's interrupt
controller is chained off of it to handle the peripherals.
SMP IPI support was mostly written by Andrea Merello, while I wrote
most of the rest of the IRQ handling.
Signed-off-by: Andrea Merello
Signed-off-by: Eric Anholt
---
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-bcm2836.c | 200 ++
2 files changed, 201 insertions(+)
create mode 100644 drivers/irqchip/irq-bcm2836.c
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b8d4e96..9727681 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_IRQCHIP) += irqchip.o
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
+obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2836.o
obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o
obj-$(CONFIG_ARCH_HIP04) += irq-hip04.o
obj-$(CONFIG_ARCH_MMP) += irq-mmp.o
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
new file mode 100644
index 000..cdb545f
--- /dev/null
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -0,0 +1,200 @@
+/*
+ * Root interrupt controller for the BCM2836 (Raspberry Pi 2).
+ *
+ * Copyright 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define LOCAL_PM_ROUTING_SET 0x010
+#define LOCAL_PM_ROUTING_CLR 0x014
+#define LOCAL_TIMER_INT_CONTROL0 0x040
+#define LOCAL_MAILBOX_INT_CONTROL0 0x050
+#define LOCAL_IRQ_PENDING0 0x060
+#define LOCAL_MAILBOX0_SET00x080
+#define LOCAL_MAILBOX0_CLR00x0c0
+
+#define LOCAL_IRQ_CNTPSIRQ 0
+#define LOCAL_IRQ_CNTPNSIRQ1
+#define LOCAL_IRQ_CNTHPIRQ 2
+#define LOCAL_IRQ_CNTVIRQ 3
+#define LOCAL_IRQ_MAILBOX0 4
+#define LOCAL_IRQ_MAILBOX1 5
+#define LOCAL_IRQ_MAILBOX2 6
+#define LOCAL_IRQ_MAILBOX3 7
+#define LOCAL_IRQ_GPU_FAST 8
+#define LOCAL_IRQ_PMU_FAST 9
+#define LAST_IRQ LOCAL_IRQ_PMU_FAST
+
+struct arm_local_intc {
+ struct irq_domain *domain;
+ void __iomem *base;
+};
+
+static struct arm_local_intc intc __read_mostly;
+
+static void bcm2836_mask_per_cpu_irq(unsigned int reg, unsigned int bit)
+{
+ void __iomem *reg_base = intc.base + reg;
+ unsigned int i;
+
+ for (i = 0; i < 4; i++)
+ writel(readl(reg_base + 4 * i) & ~BIT(bit), reg_base + 4 * i);
+}
+
+static void bcm2836_unmask_per_cpu_irq(unsigned int reg, unsigned int bit)
+{
+ void __iomem *reg_base = intc.base + reg;
+ unsigned int i;
+
+ for (i = 0; i < 4; i++)
+ writel(readl(reg_base + 4 * i) | BIT(bit), reg_base + 4 * i);
+}
+
+static void bcm2836_mask_timer_irq(struct irq_data *d)
+{
+ bcm2836_mask_per_cpu_irq(LOCAL_TIMER_INT_CONTROL0,
+d->hwirq - LOCAL_IRQ_CNTPSIRQ);
+}
+
+static void bcm2836_unmask_timer_irq(struct irq_data *d)
+{
+ bcm2836_unmask_per_cpu_irq(LOCAL_TIMER_INT_CONTROL0,
+ d->hwirq - LOCAL_IRQ_CNTPSIRQ);
+}
+
+static struct irq_chip bcm2836_timer_irqchip = {
+ .name = "bcm2836-timer",
+ .irq_mask = bcm2836_mask_timer_irq,
+ .irq_unmask = bcm2836_unmask_timer_irq
+};
+
+static void bcm2836_mask_pmu_irq(struct irq_data *d)
+{
+ writel(0xf, intc.base + LOCAL_PM_ROUTING_CLR);
+}
+
+static void bcm2836_unmask_pmu_irq(struct irq_data *d)
+{
+ writel(0xf, intc.base + LOCAL_PM_ROUTING_SET);
+}
+
+static struct irq_chip bcm2836_pmu_irqchip = {
+ .name = "bcm2836-pmu",
+ .irq_mask = bcm2836_mask_pmu_irq,
+ .irq_unmask = bcm2836_unmask_pmu_irq
+};
+
+static void bcm2836_mask_gpu_irq(struct irq_data *d)
+{
+}
+
+static void bcm2836_unmask_gpu_irq(struct irq_data *d)
+{
+}
+
+static struct irq_chip bcm2836_gpu_irqchip = {
+ .name = "bcm2836-gpu",
+ .irq_mask = bcm2836_mask_gpu_irq,
+ .irq_unmask = bcm2836_unmask_gpu_irq
+};
+
+static void bcm2836_register_irq(int hwirq, struct irq_chip *chip)
+{
+ int irq = irq_create_mapping(intc.domain, hwirq);
+
+ irq_set_percpu_devid(irq);
+ irq_set_chip_and_handler(irq, chip, handle_percpu_devid_irq);
+ irq_set_status_flags(irq, IRQ_NOAUTOEN);
+}
+
+static void __exception_irq_entry bcm2836_handle_irq(struct pt_regs *regs)
+{
+ int cpu =
[PATCH 1/4] irqchip: bcm2835: Refactor handle_IRQ() calls out of MAKE_HWIRQ.
For BCM2836, we want to chain into this IRQ chip from the root
controller, and for chaining we need to do something else instead of
handle_IRQ() once we have decoded the IRQ.
Note that this changes the behavior a little bit: Previously for a
non-shortcut IRQ, we'd loop reading and handling the second level IRQ
status until it was cleared before returning to the loop reading the
top level IRQ status (Note that the top level bit is just an OR of the
low level bits). For the expected case of just one interrupt to be
handled, this was an extra register read, so we're down from 4 to 3
reads.
Signed-off-by: Eric Anholt
---
drivers/irqchip/irq-bcm2835.c | 57 ++-
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index e68c3b6..382450a 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -179,44 +179,45 @@ static int __init armctrl_of_init(struct device_node
*node,
* handle_IRQ may briefly re-enable interrupts for soft IRQ handling.
*/
-static void armctrl_handle_bank(int bank, struct pt_regs *regs)
+static u32 armctrl_translate_bank(int bank)
{
- u32 stat, irq;
+ u32 stat = readl_relaxed(intc.pending[bank]);
- while ((stat = readl_relaxed(intc.pending[bank]))) {
- irq = MAKE_HWIRQ(bank, ffs(stat) - 1);
- handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
- }
+ return MAKE_HWIRQ(bank, ffs(stat) - 1);
+}
+
+static u32 armctrl_translate_shortcut(int bank, u32 stat)
+{
+ return MAKE_HWIRQ(bank, shortcuts[ffs(stat >> SHORTCUT_SHIFT) - 1]);
}
-static void armctrl_handle_shortcut(int bank, struct pt_regs *regs,
- u32 stat)
+static u32 get_next_armctrl_hwirq(void)
{
- u32 irq = MAKE_HWIRQ(bank, shortcuts[ffs(stat >> SHORTCUT_SHIFT) - 1]);
- handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
+ u32 stat = readl_relaxed(intc.pending[0]) & BANK0_VALID_MASK;
+
+ if (stat == 0)
+ return ~0;
+ else if (stat & BANK0_HWIRQ_MASK)
+ return MAKE_HWIRQ(0, ffs(stat & BANK0_HWIRQ_MASK) - 1);
+ else if (stat & SHORTCUT1_MASK)
+ return armctrl_translate_shortcut(1, stat & SHORTCUT1_MASK);
+ else if (stat & SHORTCUT2_MASK)
+ return armctrl_translate_shortcut(2, stat & SHORTCUT2_MASK);
+ else if (stat & BANK1_HWIRQ)
+ return armctrl_translate_bank(1);
+ else if (stat & BANK2_HWIRQ)
+ return armctrl_translate_bank(2);
+ else
+ BUG();
}
static void __exception_irq_entry bcm2835_handle_irq(
struct pt_regs *regs)
{
- u32 stat, irq;
-
- while ((stat = readl_relaxed(intc.pending[0]) & BANK0_VALID_MASK)) {
- if (stat & BANK0_HWIRQ_MASK) {
- irq = MAKE_HWIRQ(0, ffs(stat & BANK0_HWIRQ_MASK) - 1);
- handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
- } else if (stat & SHORTCUT1_MASK) {
- armctrl_handle_shortcut(1, regs, stat & SHORTCUT1_MASK);
- } else if (stat & SHORTCUT2_MASK) {
- armctrl_handle_shortcut(2, regs, stat & SHORTCUT2_MASK);
- } else if (stat & BANK1_HWIRQ) {
- armctrl_handle_bank(1, regs);
- } else if (stat & BANK2_HWIRQ) {
- armctrl_handle_bank(2, regs);
- } else {
- BUG();
- }
- }
+ u32 hwirq;
+
+ while ((hwirq = get_next_armctrl_hwirq()) != ~0)
+ handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
}
IRQCHIP_DECLARE(bcm2835_armctrl_ic, "brcm,bcm2835-armctrl-ic",
armctrl_of_init);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] irqchip: Add documentation for the bcm2836 interrupt controller.
This is a new per-cpu root interrupt controller on the Raspberry Pi 2,
which will chain to the bcm2835 interrupt controller for peripheral
interrupts.
Signed-off-by: Eric Anholt
---
.../interrupt-controller/brcm,bcm2836-l1-intc.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
new file mode 100644
index 000..f320dcd
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
@@ -0,0 +1,37 @@
+BCM2836 per-CPU interrupt controller
+
+The BCM2836 has a per-cpu interrupt controller for the timer, PMU
+events, and SMP IPIs. One of the CPUs may receive interrupts for the
+peripheral (GPU) events, which chain to the BCM2835-style interrupt
+controller.
+
+Required properties:
+
+- compatible: Should be "brcm,bcm2836-l1-intc"
+- reg: Specifies base physical address and size of the
+ registers
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 1
+
+Please refer to interrupts.txt in this directory for details of the common
+Interrupt Controllers bindings used by client devices.
+
+The interrupt sources are as follows:
+
+0: CNTPSIRQ
+1: CNTPNSIRQ
+2: CNTHPIRQ
+3: CNTVIRQ
+8: GPU_FAST
+9: PMU_FAST
+
+Example:
+
+local_intc: local_intc {
+ compatible = "brcm,bcm2836-l1-intc";
+ reg = <0x4000 0x100>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&local_intc>;
+};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Raspberry Pi 2 support, part 1: Interrupt controller
This is a little over half of the diff for the Raspberry Pi 2 platform. A full series you can build and test can be found at: https://github.com/anholt/linux/tree/bcm2836-irqchip As you can see looking at that tree, it depends on the rpi-dt-clocks series, which is still stalled waiting on the rpi-firmware series to be merged (Lee said he pulled 2/3 of them back on June 5th, but they haven't appeared in the tree). -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] powerpc/85xx: Add binding for SCFG
On Tue, 2015-07-07 at 17:47 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng
>
> SCFG provides SoC specific configuration and status registers for
> the chip. Add this for powerpc platform.
>
> Signed-off-by: Wang Dongsheng
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> index cff38bd..55604fe 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> @@ -3,6 +3,25 @@ Freescale Reference Board Bindings
> This document describes device tree bindings for various devices that
> exist on some Freescale reference boards.
>
> +* Supplement configuration unit (SCFG)
> +
> +SCFG is the supplemental configuration unit, that provides SoC specific
> +configuration and status registers for the chip. Such as getting PEX port
> +status.
> +
> +Required properties:
> +
> +- compatible: should be "fsl,-scfg"
fsl,-scfg
> +- reg: should contain base address and length of SCFG memory-mapped
> +registers
> +
> +Example:
> +
> + scfg: global-utilities@fc000{
> + compatible = "fsl,t1040-scfg";
> + reg = <0xfc000 0x1000>;
> + };
> +
I don't think board.txt is the right place for this, since it's part of the
SoC, not the board. Put it in its own file.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4][v3] ARM: imx: pinctrl-imx: imx7d: add support for iomuxc lpsr
On Tue, Jul 7, 2015 at 2:17 PM, Adrian Alonso wrote:
> * Extend pinctrl-imx driver to support iomux lpsr conntroller,
> * iMX7D has two iomuxc controllers, iomuxc controller similar as
> previous iMX SoC generation and iomuxc-lpsr which provides
> low power state rentetion capabilities on gpios that are part of
> iomuxc-lpsr (GPIO1_IO7..GPIO1_IO0).
> * Use IOMUXC_LPSR_SUPPORT and iput_val most significant bits to
> properly configure iomuxc/iomuxc-lpsr settings.
>
> Signed-off-by: Adrian Alonso
Acked-by: frank...@freescale.com
>
> - Change from v1 to v2:
> - Add suggested comment for input select register shared between
> iomuxc-lpsr and normal iomuxc controller.
> - Use IOMUXC_LPSR_MASK to extract pad group id and aling pin_id to
> 16 bit representation.
> - Change from v2 to v3
> - Use devm_ioremap_resource instead of of_iomap to get iomuxc-lpsr
> base register address.
> ---
> drivers/pinctrl/freescale/pinctrl-imx.c | 72
> ++---
> drivers/pinctrl/freescale/pinctrl-imx.h | 7 +++-
> 2 files changed, 55 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index d7b98ba..aef4ca3 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -1,7 +1,7 @@
> /*
> * Core driver for the imx pin controller
> *
> - * Copyright (C) 2012 Freescale Semiconductor, Inc.
> + * Copyright (C) 2012-2015 Freescale Semiconductor, Inc.
> * Copyright (C) 2012 Linaro Ltd.
> *
> * Author: Dong Aisheng
> @@ -38,7 +38,6 @@
> struct imx_pinctrl {
> struct device *dev;
> struct pinctrl_dev *pctl;
> - void __iomem *base;
> const struct imx_pinctrl_soc_info *info;
> };
>
> @@ -212,12 +211,12 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev,
> unsigned selector,
>
> if (info->flags & SHARE_MUX_CONF_REG) {
> u32 reg;
> - reg = readl(ipctl->base + pin_reg->mux_reg);
> + reg = readl(pin_reg->base + pin_reg->mux_reg);
> reg &= ~(0x7 << 20);
> reg |= (pin->mux_mode << 20);
> - writel(reg, ipctl->base + pin_reg->mux_reg);
> + writel(reg, pin_reg->base + pin_reg->mux_reg);
> } else {
> - writel(pin->mux_mode, ipctl->base + pin_reg->mux_reg);
> + writel(pin->mux_mode, pin_reg->base +
> pin_reg->mux_reg);
> }
> dev_dbg(ipctl->dev, "write: offset 0x%x val 0x%x\n",
> pin_reg->mux_reg, pin->mux_mode);
> @@ -245,16 +244,22 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev,
> unsigned selector,
> * The input_reg[i] here is actually some IOMUXC
> general
> * purpose register, not regular select input
> register.
> */
> - val = readl(ipctl->base + pin->input_reg);
> + val = readl(pin_reg->base + pin->input_reg);
> val &= ~mask;
> val |= select << shift;
> - writel(val, ipctl->base + pin->input_reg);
> + writel(val, pin_reg->base + pin->input_reg);
> } else if (pin->input_reg) {
> /*
> * Regular select input register can never be at
> offset
> * 0, and we only print register value for regular
> case.
> */
> - writel(pin->input_val, ipctl->base + pin->input_reg);
> + if (info->flags & IOMUXC_LPSR_SUPPORT &&
> + IOMUXC_LPSR_MASK(pin->input_val))
> + /* iomuxc-lpsr select input register shared with
> normal iomuxc */
> + writel(pin->input_val, info->base +
> pin->input_reg);
> + else
> + writel(pin->input_val, pin_reg->base +
> pin->input_reg);
> +
> dev_dbg(ipctl->dev,
> "==>select_input: offset 0x%x val 0x%x\n",
> pin->input_reg, pin->input_val);
> @@ -326,10 +331,10 @@ static int imx_pmx_gpio_request_enable(struct
> pinctrl_dev *pctldev,
> return -EINVAL;
>
> mux_pin:
> - reg = readl(ipctl->base + pin_reg->mux_reg);
> + reg = readl(pin_reg->base + pin_reg->mux_reg);
> reg &= ~(0x7 << 20);
> reg |= imx_pin->config;
> - writel(reg, ipctl->base + pin_reg->mux_reg);
> + writel(reg, pin_reg->base + pin_reg->mux_reg);
>
> return 0;
> }
> @@ -354,12 +359,12 @@ static int imx_pmx_gpio_set_direction(struct
> pinctrl_dev *pctldev,
> return -EINVAL;
>
> /* I
Re: [PATCH 4/4][v3] ARM: imx: pinctrl-imx7d: add iomuxc-lpsr gpio group ids
On Tue, Jul 7, 2015 at 2:17 PM, Adrian Alonso wrote:
> * Add imx7d SoC iomuxc-lpsr gpio group id's
> * Add IOMUXC_LPSR_SUPPORT flag for pinctrl-imx driver to
> support iomuxc-lpsr controller.
>
> Signed-off-by: Adrian Alonso
Acked-by: frank...@freescale.com
>
> - Change v1 to v3: resend patch
>
> ---
> drivers/pinctrl/freescale/pinctrl-imx7d.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx7d.c
> b/drivers/pinctrl/freescale/pinctrl-imx7d.c
> index 1fa7530..cf89275 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx7d.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx7d.c
> @@ -172,6 +172,14 @@ enum imx7d_pads {
> MX7D_PAD_ENET1_RX_CLK = 152,
> MX7D_PAD_ENET1_CRS = 153,
> MX7D_PAD_ENET1_COL = 154,
> + MX7D_PAD_GPIO1_IO00 = 155,
> + MX7D_PAD_GPIO1_IO01 = 156,
> + MX7D_PAD_GPIO1_IO02 = 157,
> + MX7D_PAD_GPIO1_IO03 = 158,
> + MX7D_PAD_GPIO1_IO04 = 159,
> + MX7D_PAD_GPIO1_IO05 = 160,
> + MX7D_PAD_GPIO1_IO06 = 161,
> + MX7D_PAD_GPIO1_IO07 = 162,
> };
>
> /* Pad names for the pinmux subsystem */
> @@ -331,11 +339,20 @@ static const struct pinctrl_pin_desc
> imx7d_pinctrl_pads[] = {
> IMX_PINCTRL_PIN(MX7D_PAD_ENET1_RX_CLK),
> IMX_PINCTRL_PIN(MX7D_PAD_ENET1_CRS),
> IMX_PINCTRL_PIN(MX7D_PAD_ENET1_COL),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO00),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO01),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO02),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO03),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO04),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO05),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO06),
> + IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO07),
> };
>
> static struct imx_pinctrl_soc_info imx7d_pinctrl_info = {
> .pins = imx7d_pinctrl_pads,
> .npins = ARRAY_SIZE(imx7d_pinctrl_pads),
> + .flags = IOMUXC_LPSR_SUPPORT,
> };
>
> static struct of_device_id imx7d_pinctrl_of_match[] = {
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4][v3] ARM: imx: imx7d-pinfunc: add gpio pad iomuxc settings
On Tue, Jul 7, 2015 at 2:17 PM, Adrian Alonso wrote: > * Add iMX7D SoC imx7d-pinfunc gpio pad settings > > * iMX7D GPIO1_IO7 to GPIO1_IO0 encode the pad group id in the most > significant bits of input_val to avoid group id overlap bweeten > iomuxc and iomuxc-lpsr. > > Signed-off-by: Adrian Alonso Acked-by: frank...@freescale.com > > - Change v1 to v2: Use input_val upper 16 bits to represent pad group id > - Change v2 to v3: Resend patch > --- > arch/arm/boot/dts/imx7d-pinfunc.h | 116 > ++ > 1 file changed, 116 insertions(+) > > diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h > b/arch/arm/boot/dts/imx7d-pinfunc.h > index a8d8149..9460d5c 100644 > --- a/arch/arm/boot/dts/imx7d-pinfunc.h > +++ b/arch/arm/boot/dts/imx7d-pinfunc.h > @@ -15,6 +15,122 @@ > * > */ > > +#define MX7D_PAD_GPIO1_IO00__GPIO1_IO0 0x > 0x0030 0x 0x0 0x009B > +#define MX7D_PAD_GPIO1_IO00__PWM4_OUT0x > 0x0030 0x 0x1 0x009B > +#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_ANY 0x > 0x0030 0x 0x2 0x009B > +#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B0x > 0x0030 0x 0x3 0x009B > +#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB 0x > 0x0030 0x 0x4 0x009B > +#define MX7D_PAD_GPIO1_IO01__GPIO1_IO1 0x0004 > 0x0034 0x 0x0 0x009C > +#define MX7D_PAD_GPIO1_IO01__PWM1_OUT0x0004 > 0x0034 0x 0x1 0x009C > +#define MX7D_PAD_GPIO1_IO01__CCM_ENET_REF_CLK3 0x0004 > 0x0034 0x 0x2 0x009C > +#define MX7D_PAD_GPIO1_IO01__SAI1_MCLK 0x0004 > 0x0034 0x 0x3 0x009C > +#define MX7D_PAD_GPIO1_IO01__ANATOP_24M_OUT 0x0004 > 0x0034 0x 0x4 0x009C > +#define MX7D_PAD_GPIO1_IO01__OBSERVE0_OUT0x0004 > 0x0034 0x 0x6 0x009C > +#define MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x0008 > 0x0038 0x 0x0 0x009D > +#define MX7D_PAD_GPIO1_IO02__PWM2_OUT0x0008 > 0x0038 0x 0x1 0x009D > +#define MX7D_PAD_GPIO1_IO02__CCM_ENET_REF_CLK1 0x0008 > 0x0038 0x0564 0x2 0x009D0003 > +#define MX7D_PAD_GPIO1_IO02__SAI2_MCLK 0x0008 > 0x0038 0x 0x3 0x009D > +#define MX7D_PAD_GPIO1_IO02__CCM_CLKO1 0x0008 > 0x0038 0x 0x5 0x009D > +#define MX7D_PAD_GPIO1_IO02__OBSERVE1_OUT0x0008 > 0x0038 0x 0x6 0x009D > +#define MX7D_PAD_GPIO1_IO02__USB_OTG1_ID 0x0008 > 0x0038 0x0734 0x7 0x009D0003 > +#define MX7D_PAD_GPIO1_IO03__GPIO1_IO3 0x000C > 0x003C 0x 0x0 0x009E > +#define MX7D_PAD_GPIO1_IO03__PWM3_OUT0x000C > 0x003C 0x 0x1 0x009E > +#define MX7D_PAD_GPIO1_IO03__CCM_ENET_REF_CLK2 0x000C > 0x003C 0x0570 0x2 0x009E0003 > +#define MX7D_PAD_GPIO1_IO03__SAI3_MCLK 0x000C > 0x003C 0x 0x3 0x009E > +#define MX7D_PAD_GPIO1_IO03__CCM_CLKO2 0x000C > 0x003C 0x 0x5 0x009E > +#define MX7D_PAD_GPIO1_IO03__OBSERVE2_OUT0x000C > 0x003C 0x 0x6 0x009E > +#define MX7D_PAD_GPIO1_IO03__USB_OTG2_ID 0x000C > 0x003C 0x0730 0x7 0x009E0003 > +#define MX7D_PAD_GPIO1_IO04__GPIO1_IO4 0x0010 > 0x0040 0x 0x0 0x009F > +#define MX7D_PAD_GPIO1_IO04__USB_OTG1_OC 0x0010 > 0x0040 0x072C 0x1 0x009F0001 > +#define MX7D_PAD_GPIO1_IO04__FLEXTIMER1_CH4 0x0010 > 0x0040 0x0594 0x2 0x009F0001 > +#define MX7D_PAD_GPIO1_IO04__UART5_CTS_B 0x0010 > 0x0040 0x0710 0x3 0x009F0004 > +#define MX7D_PAD_GPIO1_IO04__I2C1_SCL0x0010 > 0x0040 0x05D4 0x4 0x009F0002 > +#define MX7D_PAD_GPIO1_IO04__OBSERVE3_OUT0x0010 > 0x0040 0x 0x6 0x009F > +#define MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x0014 > 0x0044 0x 0x0 0x00A0 > +#define MX7D_PAD_GPIO1_IO05__USB_OTG1_PWR0x0014 > 0x0044 0x 0x1 0x00A0 > +#define MX7D_PAD_GPIO1_IO05__FLEXTIMER1_CH5 0x0014 > 0x0044 0x0598 0x2 0x00A1 > +#define MX7D_PAD_GPIO1_IO05__UART5_RTS_B 0x0014 > 0x0044 0x0710 0x3 0x00A5 > +#define MX7D_PAD_GPIO1_IO05__I2C1_SDA0x0014 > 0x0044 0x05D8 0x4 0x00A2 > +#define MX7D_PAD_GPIO1_IO05__OBSERVE4_OUT0x0014 > 0x0044 0x 0x6 0x00A0 > +#define MX7D_PAD_GPIO1_IO06__GPIO1_IO6 0x0018 > 0x0048 0x 0x0 0x00A1 > +#define MX7D_PAD_GPIO1_IO06__USB_OTG2_OC 0x0018 > 0x0048 0x0728 0x1 0x00A10001
[PATCH 2/4][v3] ARM: dts: imx: imx7d add iomuxc lpsr register base address
* Add iomuxc lpsr register base address to extend
pinctrl-imx driver to support the iomux settings for pins
that support LPSR operation mode.
Signed-off-by: Adrian Alonso
- Change v1 to v3: resend patch
---
arch/arm/boot/dts/imx7d.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index c42cf8d..294a6c6 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -253,7 +253,7 @@
iomuxc: iomuxc@3033 {
compatible = "fsl,imx7d-iomuxc";
- reg = <0x3033 0x1>;
+ reg = <0x3033 0x1>, <0x302c
0x1>;
};
gpr: iomuxc-gpr@3034 {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4][v3] ARM: imx: pinctrl-imx7d: add iomuxc-lpsr gpio group ids
* Add imx7d SoC iomuxc-lpsr gpio group id's
* Add IOMUXC_LPSR_SUPPORT flag for pinctrl-imx driver to
support iomuxc-lpsr controller.
Signed-off-by: Adrian Alonso
- Change v1 to v3: resend patch
---
drivers/pinctrl/freescale/pinctrl-imx7d.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx7d.c
b/drivers/pinctrl/freescale/pinctrl-imx7d.c
index 1fa7530..cf89275 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx7d.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx7d.c
@@ -172,6 +172,14 @@ enum imx7d_pads {
MX7D_PAD_ENET1_RX_CLK = 152,
MX7D_PAD_ENET1_CRS = 153,
MX7D_PAD_ENET1_COL = 154,
+ MX7D_PAD_GPIO1_IO00 = 155,
+ MX7D_PAD_GPIO1_IO01 = 156,
+ MX7D_PAD_GPIO1_IO02 = 157,
+ MX7D_PAD_GPIO1_IO03 = 158,
+ MX7D_PAD_GPIO1_IO04 = 159,
+ MX7D_PAD_GPIO1_IO05 = 160,
+ MX7D_PAD_GPIO1_IO06 = 161,
+ MX7D_PAD_GPIO1_IO07 = 162,
};
/* Pad names for the pinmux subsystem */
@@ -331,11 +339,20 @@ static const struct pinctrl_pin_desc imx7d_pinctrl_pads[]
= {
IMX_PINCTRL_PIN(MX7D_PAD_ENET1_RX_CLK),
IMX_PINCTRL_PIN(MX7D_PAD_ENET1_CRS),
IMX_PINCTRL_PIN(MX7D_PAD_ENET1_COL),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO00),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO01),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO02),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO03),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO04),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO05),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO06),
+ IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO07),
};
static struct imx_pinctrl_soc_info imx7d_pinctrl_info = {
.pins = imx7d_pinctrl_pads,
.npins = ARRAY_SIZE(imx7d_pinctrl_pads),
+ .flags = IOMUXC_LPSR_SUPPORT,
};
static struct of_device_id imx7d_pinctrl_of_match[] = {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4][v3] ARM: imx: pinctrl-imx: imx7d: add support for iomuxc lpsr
* Extend pinctrl-imx driver to support iomux lpsr conntroller,
* iMX7D has two iomuxc controllers, iomuxc controller similar as
previous iMX SoC generation and iomuxc-lpsr which provides
low power state rentetion capabilities on gpios that are part of
iomuxc-lpsr (GPIO1_IO7..GPIO1_IO0).
* Use IOMUXC_LPSR_SUPPORT and iput_val most significant bits to
properly configure iomuxc/iomuxc-lpsr settings.
Signed-off-by: Adrian Alonso
- Change from v1 to v2:
- Add suggested comment for input select register shared between
iomuxc-lpsr and normal iomuxc controller.
- Use IOMUXC_LPSR_MASK to extract pad group id and aling pin_id to
16 bit representation.
- Change from v2 to v3
- Use devm_ioremap_resource instead of of_iomap to get iomuxc-lpsr
base register address.
---
drivers/pinctrl/freescale/pinctrl-imx.c | 72 ++---
drivers/pinctrl/freescale/pinctrl-imx.h | 7 +++-
2 files changed, 55 insertions(+), 24 deletions(-)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
b/drivers/pinctrl/freescale/pinctrl-imx.c
index d7b98ba..aef4ca3 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -1,7 +1,7 @@
/*
* Core driver for the imx pin controller
*
- * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012-2015 Freescale Semiconductor, Inc.
* Copyright (C) 2012 Linaro Ltd.
*
* Author: Dong Aisheng
@@ -38,7 +38,6 @@
struct imx_pinctrl {
struct device *dev;
struct pinctrl_dev *pctl;
- void __iomem *base;
const struct imx_pinctrl_soc_info *info;
};
@@ -212,12 +211,12 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev,
unsigned selector,
if (info->flags & SHARE_MUX_CONF_REG) {
u32 reg;
- reg = readl(ipctl->base + pin_reg->mux_reg);
+ reg = readl(pin_reg->base + pin_reg->mux_reg);
reg &= ~(0x7 << 20);
reg |= (pin->mux_mode << 20);
- writel(reg, ipctl->base + pin_reg->mux_reg);
+ writel(reg, pin_reg->base + pin_reg->mux_reg);
} else {
- writel(pin->mux_mode, ipctl->base + pin_reg->mux_reg);
+ writel(pin->mux_mode, pin_reg->base + pin_reg->mux_reg);
}
dev_dbg(ipctl->dev, "write: offset 0x%x val 0x%x\n",
pin_reg->mux_reg, pin->mux_mode);
@@ -245,16 +244,22 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev,
unsigned selector,
* The input_reg[i] here is actually some IOMUXC general
* purpose register, not regular select input register.
*/
- val = readl(ipctl->base + pin->input_reg);
+ val = readl(pin_reg->base + pin->input_reg);
val &= ~mask;
val |= select << shift;
- writel(val, ipctl->base + pin->input_reg);
+ writel(val, pin_reg->base + pin->input_reg);
} else if (pin->input_reg) {
/*
* Regular select input register can never be at offset
* 0, and we only print register value for regular case.
*/
- writel(pin->input_val, ipctl->base + pin->input_reg);
+ if (info->flags & IOMUXC_LPSR_SUPPORT &&
+ IOMUXC_LPSR_MASK(pin->input_val))
+ /* iomuxc-lpsr select input register shared with normal
iomuxc */
+ writel(pin->input_val, info->base +
pin->input_reg);
+ else
+ writel(pin->input_val, pin_reg->base +
pin->input_reg);
+
dev_dbg(ipctl->dev,
"==>select_input: offset 0x%x val 0x%x\n",
pin->input_reg, pin->input_val);
@@ -326,10 +331,10 @@ static int imx_pmx_gpio_request_enable(struct pinctrl_dev
*pctldev,
return -EINVAL;
mux_pin:
- reg = readl(ipctl->base + pin_reg->mux_reg);
+ reg = readl(pin_reg->base + pin_reg->mux_reg);
reg &= ~(0x7 << 20);
reg |= imx_pin->config;
- writel(reg, ipctl->base + pin_reg->mux_reg);
+ writel(reg, pin_reg->base + pin_reg->mux_reg);
return 0;
}
@@ -354,12 +359,12 @@ static int imx_pmx_gpio_set_direction(struct pinctrl_dev
*pctldev,
return -EINVAL;
/* IBE always enabled allows us to read the value "on the wire" */
- reg = readl(ipctl->base + pin_reg->mux_reg);
+ reg = readl(pin_reg->base + pin_reg->mux_reg);
if (input)
reg &= ~0x2;
else
reg |= 0x2;
- writel(reg, ipctl->base + pin_reg->mux_reg);
+
[PATCH 1/4][v3] ARM: imx: imx7d-pinfunc: add gpio pad iomuxc settings
* Add iMX7D SoC imx7d-pinfunc gpio pad settings * iMX7D GPIO1_IO7 to GPIO1_IO0 encode the pad group id in the most significant bits of input_val to avoid group id overlap bweeten iomuxc and iomuxc-lpsr. Signed-off-by: Adrian Alonso - Change v1 to v2: Use input_val upper 16 bits to represent pad group id - Change v2 to v3: Resend patch --- arch/arm/boot/dts/imx7d-pinfunc.h | 116 ++ 1 file changed, 116 insertions(+) diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h b/arch/arm/boot/dts/imx7d-pinfunc.h index a8d8149..9460d5c 100644 --- a/arch/arm/boot/dts/imx7d-pinfunc.h +++ b/arch/arm/boot/dts/imx7d-pinfunc.h @@ -15,6 +15,122 @@ * */ +#define MX7D_PAD_GPIO1_IO00__GPIO1_IO0 0x 0x0030 0x 0x0 0x009B +#define MX7D_PAD_GPIO1_IO00__PWM4_OUT0x 0x0030 0x 0x1 0x009B +#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_ANY 0x 0x0030 0x 0x2 0x009B +#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B0x 0x0030 0x 0x3 0x009B +#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB 0x 0x0030 0x 0x4 0x009B +#define MX7D_PAD_GPIO1_IO01__GPIO1_IO1 0x0004 0x0034 0x 0x0 0x009C +#define MX7D_PAD_GPIO1_IO01__PWM1_OUT0x0004 0x0034 0x 0x1 0x009C +#define MX7D_PAD_GPIO1_IO01__CCM_ENET_REF_CLK3 0x0004 0x0034 0x 0x2 0x009C +#define MX7D_PAD_GPIO1_IO01__SAI1_MCLK 0x0004 0x0034 0x 0x3 0x009C +#define MX7D_PAD_GPIO1_IO01__ANATOP_24M_OUT 0x0004 0x0034 0x 0x4 0x009C +#define MX7D_PAD_GPIO1_IO01__OBSERVE0_OUT0x0004 0x0034 0x 0x6 0x009C +#define MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x0008 0x0038 0x 0x0 0x009D +#define MX7D_PAD_GPIO1_IO02__PWM2_OUT0x0008 0x0038 0x 0x1 0x009D +#define MX7D_PAD_GPIO1_IO02__CCM_ENET_REF_CLK1 0x0008 0x0038 0x0564 0x2 0x009D0003 +#define MX7D_PAD_GPIO1_IO02__SAI2_MCLK 0x0008 0x0038 0x 0x3 0x009D +#define MX7D_PAD_GPIO1_IO02__CCM_CLKO1 0x0008 0x0038 0x 0x5 0x009D +#define MX7D_PAD_GPIO1_IO02__OBSERVE1_OUT0x0008 0x0038 0x 0x6 0x009D +#define MX7D_PAD_GPIO1_IO02__USB_OTG1_ID 0x0008 0x0038 0x0734 0x7 0x009D0003 +#define MX7D_PAD_GPIO1_IO03__GPIO1_IO3 0x000C 0x003C 0x 0x0 0x009E +#define MX7D_PAD_GPIO1_IO03__PWM3_OUT0x000C 0x003C 0x 0x1 0x009E +#define MX7D_PAD_GPIO1_IO03__CCM_ENET_REF_CLK2 0x000C 0x003C 0x0570 0x2 0x009E0003 +#define MX7D_PAD_GPIO1_IO03__SAI3_MCLK 0x000C 0x003C 0x 0x3 0x009E +#define MX7D_PAD_GPIO1_IO03__CCM_CLKO2 0x000C 0x003C 0x 0x5 0x009E +#define MX7D_PAD_GPIO1_IO03__OBSERVE2_OUT0x000C 0x003C 0x 0x6 0x009E +#define MX7D_PAD_GPIO1_IO03__USB_OTG2_ID 0x000C 0x003C 0x0730 0x7 0x009E0003 +#define MX7D_PAD_GPIO1_IO04__GPIO1_IO4 0x0010 0x0040 0x 0x0 0x009F +#define MX7D_PAD_GPIO1_IO04__USB_OTG1_OC 0x0010 0x0040 0x072C 0x1 0x009F0001 +#define MX7D_PAD_GPIO1_IO04__FLEXTIMER1_CH4 0x0010 0x0040 0x0594 0x2 0x009F0001 +#define MX7D_PAD_GPIO1_IO04__UART5_CTS_B 0x0010 0x0040 0x0710 0x3 0x009F0004 +#define MX7D_PAD_GPIO1_IO04__I2C1_SCL0x0010 0x0040 0x05D4 0x4 0x009F0002 +#define MX7D_PAD_GPIO1_IO04__OBSERVE3_OUT0x0010 0x0040 0x 0x6 0x009F +#define MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x0014 0x0044 0x 0x0 0x00A0 +#define MX7D_PAD_GPIO1_IO05__USB_OTG1_PWR0x0014 0x0044 0x 0x1 0x00A0 +#define MX7D_PAD_GPIO1_IO05__FLEXTIMER1_CH5 0x0014 0x0044 0x0598 0x2 0x00A1 +#define MX7D_PAD_GPIO1_IO05__UART5_RTS_B 0x0014 0x0044 0x0710 0x3 0x00A5 +#define MX7D_PAD_GPIO1_IO05__I2C1_SDA0x0014 0x0044 0x05D8 0x4 0x00A2 +#define MX7D_PAD_GPIO1_IO05__OBSERVE4_OUT0x0014 0x0044 0x 0x6 0x00A0 +#define MX7D_PAD_GPIO1_IO06__GPIO1_IO6 0x0018 0x0048 0x 0x0 0x00A1 +#define MX7D_PAD_GPIO1_IO06__USB_OTG2_OC 0x0018 0x0048 0x0728 0x1 0x00A10001 +#define MX7D_PAD_GPIO1_IO06__FLEXTIMER1_CH6 0x0018 0x0048 0x059C 0x2 0x00A10001 +#define MX7D_PAD_GPIO1_IO06__UART5_RX_DATA 0x0018 0x0048 0x0714 0x3 0x00A10004 +#define MX7D_PAD_GPIO1_IO06__I2C2_SCL0x0018 0x0048 0x
[PATCH][v3] ARM: imx: pinctrl-imx: imx7d: add support for iomuxc lpsr
* Extend pinctrl-imx driver to support iomux lpsr conntroller,
* iMX7D has two iomuxc controllers, iomuxc controller similar as
previous iMX SoC generation and iomuxc-lpsr which provides
low power state rentetion capabilities on gpios that are part of
iomuxc-lpsr (GPIO1_IO7..GPIO1_IO0).
* Use IOMUXC_LPSR_SUPPORT and iput_val most significant bits to
properly configure iomuxc/iomuxc-lpsr settings.
Signed-off-by: Adrian Alonso
* Change from v1 to v2:
- Add suggested comment for input select register shared between
iomuxc-lpsr and normal iomuxc controller.
- Use IOMUXC_LPSR_MASK to extract pad group id and aling pin_id to
16 bit representation.
* Change from v2 to v3
- Use devm_ioremap_resource instead of of_iomap to get iomuxc-lpsr
base register address.
---
drivers/pinctrl/freescale/pinctrl-imx.c | 72 ++---
drivers/pinctrl/freescale/pinctrl-imx.h | 7 +++-
2 files changed, 55 insertions(+), 24 deletions(-)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
b/drivers/pinctrl/freescale/pinctrl-imx.c
index d7b98ba..aef4ca3 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -1,7 +1,7 @@
/*
* Core driver for the imx pin controller
*
- * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012-2015 Freescale Semiconductor, Inc.
* Copyright (C) 2012 Linaro Ltd.
*
* Author: Dong Aisheng
@@ -38,7 +38,6 @@
struct imx_pinctrl {
struct device *dev;
struct pinctrl_dev *pctl;
- void __iomem *base;
const struct imx_pinctrl_soc_info *info;
};
@@ -212,12 +211,12 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev,
unsigned selector,
if (info->flags & SHARE_MUX_CONF_REG) {
u32 reg;
- reg = readl(ipctl->base + pin_reg->mux_reg);
+ reg = readl(pin_reg->base + pin_reg->mux_reg);
reg &= ~(0x7 << 20);
reg |= (pin->mux_mode << 20);
- writel(reg, ipctl->base + pin_reg->mux_reg);
+ writel(reg, pin_reg->base + pin_reg->mux_reg);
} else {
- writel(pin->mux_mode, ipctl->base + pin_reg->mux_reg);
+ writel(pin->mux_mode, pin_reg->base + pin_reg->mux_reg);
}
dev_dbg(ipctl->dev, "write: offset 0x%x val 0x%x\n",
pin_reg->mux_reg, pin->mux_mode);
@@ -245,16 +244,22 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev,
unsigned selector,
* The input_reg[i] here is actually some IOMUXC general
* purpose register, not regular select input register.
*/
- val = readl(ipctl->base + pin->input_reg);
+ val = readl(pin_reg->base + pin->input_reg);
val &= ~mask;
val |= select << shift;
- writel(val, ipctl->base + pin->input_reg);
+ writel(val, pin_reg->base + pin->input_reg);
} else if (pin->input_reg) {
/*
* Regular select input register can never be at offset
* 0, and we only print register value for regular case.
*/
- writel(pin->input_val, ipctl->base + pin->input_reg);
+ if (info->flags & IOMUXC_LPSR_SUPPORT &&
+ IOMUXC_LPSR_MASK(pin->input_val))
+ /* iomuxc-lpsr select input register shared with normal
iomuxc */
+ writel(pin->input_val, info->base +
pin->input_reg);
+ else
+ writel(pin->input_val, pin_reg->base +
pin->input_reg);
+
dev_dbg(ipctl->dev,
"==>select_input: offset 0x%x val 0x%x\n",
pin->input_reg, pin->input_val);
@@ -326,10 +331,10 @@ static int imx_pmx_gpio_request_enable(struct pinctrl_dev
*pctldev,
return -EINVAL;
mux_pin:
- reg = readl(ipctl->base + pin_reg->mux_reg);
+ reg = readl(pin_reg->base + pin_reg->mux_reg);
reg &= ~(0x7 << 20);
reg |= imx_pin->config;
- writel(reg, ipctl->base + pin_reg->mux_reg);
+ writel(reg, pin_reg->base + pin_reg->mux_reg);
return 0;
}
@@ -354,12 +359,12 @@ static int imx_pmx_gpio_set_direction(struct pinctrl_dev
*pctldev,
return -EINVAL;
/* IBE always enabled allows us to read the value "on the wire" */
- reg = readl(ipctl->base + pin_reg->mux_reg);
+ reg = readl(pin_reg->base + pin_reg->mux_reg);
if (input)
reg &= ~0x2;
else
reg |= 0x2;
- writel(reg, ipctl->base + pin_reg->mux_reg);
+
Applied "regulator: pwm-regulator: Re-write bindings" to the regulator tree
The patch
regulator: pwm-regulator: Re-write bindings
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 02258b8bcbb98b28064cc829f7062455da398633 Mon Sep 17 00:00:00 2001
From: Lee Jones
Date: Tue, 7 Jul 2015 16:06:50 +0100
Subject: [PATCH] regulator: pwm-regulator: Re-write bindings
* Add support for continuous-voltage mode
* Put more meat on the bones with regards to voltage-table mode
* Sort out formatting for ease of consumption
Cc: devicetree@vger.kernel.org
Signed-off-by: Lee Jones
Signed-off-by: Mark Brown
---
.../bindings/regulator/pwm-regulator.txt | 68 ++
1 file changed, 56 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index ce91f61feb12..892b36655b3d 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -1,27 +1,71 @@
-pwm regulator bindings
+Bindings for the Generic PWM Regulator
+==
+
+Currently supports 2 modes of operation:
+
+voltage-table: When in this mode, a voltage table (See below) of
+ predefined voltage <=> duty-cycle values must be
+ provided via DT. Limitations are that the regulator can
+ only operate at the voltages supplied in the table.
+ Intermediary duty-cycle values which would normally
+ allow finer grained voltage selection are ignored and
+ rendered useless. Although more control is given to
+ the user if the assumptions made in continuous-voltage
+ mode do not reign true.
+
+continuous-voltage:This mode uses the regulator's maximum and minimum
+ supplied voltages specified in the
+ regulator-{min,max}-microvolt properties to calculate
+ appropriate duty-cycle values. This allows for a much
+ more fine grained solution when compared with
+ voltage-table mode above. This solution does make an
+ assumption that a %50 duty-cycle value will cause the
+ regulator voltage to run at half way between the
+ supplied max_uV and min_uV values.
Required properties:
-- compatible: Should be "pwm-regulator"
-- pwms: OF device-tree PWM specification (see PWM binding pwm.txt)
-- voltage-table: voltage and duty table, include 2 members in each set of
- brackets, first one is voltage(unit: uv), the next is duty(unit: percent)
+
+- compatible: Should be "pwm-regulator"
+
+- pwms:PWM specification (See: ../pwm/pwm.txt)
+
+One of these must be provided:
+- voltage-table: Voltage and Duty-Cycle table consisting of 2 cells
+ First cell is voltage in microvolts (uV)
+ Second cell is duty-cycle in percent (%)
+
+- max-duty-cycle: Maximum Duty-Cycle value -- this will normally be
+ 255 (0xff) for an 8 bit PWM device
-Any property defined as part of the core regulator binding defined in
-regulator.txt can also be used.
+If both are provided, the current default is voltage-table mode.
-Example:
+Any property defined as part of the core regulator binding can also be used.
+(See: ../regulator/regulator.txt)
+
+Continuous Voltage Example:
pwm_regulator {
compatible = "pwm-regulator;
pwms = <&pwm1 0 8448 0>;
+ regulator-min-microvolt = <1016000>;
+ regulator-max-microvolt = <1114000>;
+ regulator-name = "vdd_logic";
+
+ max-duty-cycle = <255>; /* 8bit PWM */
+ };
+Voltage Table Example:
+ pwm_regulator {
+ compatible = "pwm-regulator;
+ pwms = <&pwm1 0 8448 0>;
+ regulator-min-microvolt = <1016000>;
+ regulator-max-microvolt =
[PATCH] Documentation: dt: update ti,am33xx-hsmmc swakeup workaround
Before 5b83b2234be6733cf the driver was hard coding the wakeup irq to
be active low. The generic pm wakeirq does not override the active
high/low parameter, hence it must be specified correctly in the
device tree.
Mind that SDIO IRQ is active low as defined in the SDIO specification
Signed-off-by: Andreas Fenkart
---
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 76bf087..74166a0 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -102,7 +102,7 @@ not every application needs SDIO irq, e.g. MMC cards.
pinctrl-1 = <&mmc1_idle>;
pinctrl-2 = <&mmc1_sleep>;
...
- interrupts-extended = <&intc 64 &gpio2 28 0>;
+ interrupts-extended = <&intc 64 &gpio2 28 GPIO_ACTIVE_LOW>;
};
mmc1_idle : pinmux_cirq_pin {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: perf: extend interrupt-affinity property for PPIs
On systems containing multiple, heterogeneous clusters we need a way to
associate a PMU "device" with the CPU(s) on which it exists. For PMUs
that signal overflow with SPIs, this relationship is determined via the
"interrupt-affinity" property, which contains a list of phandles to CPU
nodes for the PMU. For PMUs using PPIs, the per-cpu nature of the
interrupt isn't enough to determine the set of CPUs which actually
contain the device.
This patch allows the interrupt-affinity property to be specified on a
PMU node irrespective of the interrupt type. For PPIs, it identifies
the set of CPUs signalling the PPI in question.
Tested-by: Stephen Boyd # Krait PMU
Signed-off-by: Will Deacon
---
Documentation/devicetree/bindings/arm/pmu.txt | 12 +++--
arch/arm/kernel/perf_event.c | 65 ++-
2 files changed, 53 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/pmu.txt
b/Documentation/devicetree/bindings/arm/pmu.txt
index 3b5f5d1088c6..435251fa9ce0 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -26,13 +26,19 @@ Required properties:
Optional properties:
-- interrupt-affinity : Valid only when using SPIs, specifies a list of phandles
- to CPU nodes corresponding directly to the affinity of
+- interrupt-affinity : When using SPIs, specifies a list of phandles to CPU
+ nodes corresponding directly to the affinity of
the SPIs listed in the interrupts property.
- This property should be present when there is more than
+ When using a PPI, specifies a list of phandles to CPU
+ nodes corresponding to the set of CPUs which have
+ a PMU of this type signalling the PPI listed in the
+ interrupts property.
+
+ This property should be present when there is more than
a single SPI.
+
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
events.
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 7d5379c1c443..5a8f17bfcc60 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -790,32 +790,39 @@ static int probe_current_pmu(struct arm_pmu *pmu,
static int of_pmu_irq_cfg(struct arm_pmu *pmu)
{
- int i, irq, *irqs;
+ int *irqs, i = 0;
+ bool using_spi = false;
struct platform_device *pdev = pmu->plat_device;
- /* Don't bother with PPIs; they're already affine */
- irq = platform_get_irq(pdev, 0);
- if (irq >= 0 && irq_is_percpu(irq)) {
- cpumask_setall(&pmu->supported_cpus);
- return 0;
- }
-
irqs = kcalloc(pdev->num_resources, sizeof(*irqs), GFP_KERNEL);
if (!irqs)
return -ENOMEM;
- for (i = 0; i < pdev->num_resources; ++i) {
+ do {
struct device_node *dn;
- int cpu;
+ int cpu, irq;
- dn = of_parse_phandle(pdev->dev.of_node, "interrupt-affinity",
- i);
- if (!dn) {
- pr_warn("Failed to parse %s/interrupt-affinity[%d]\n",
- of_node_full_name(pdev->dev.of_node), i);
+ /* See if we have an affinity entry */
+ dn = of_parse_phandle(pdev->dev.of_node, "interrupt-affinity",
i);
+ if (!dn)
break;
+
+ /* Check the IRQ type and prohibit a mix of PPIs and SPIs */
+ irq = platform_get_irq(pdev, i);
+ if (irq >= 0) {
+ bool spi = !irq_is_percpu(irq);
+
+ if (i > 0 && spi != using_spi) {
+ pr_err("PPI/SPI IRQ type mismatch for %s!\n",
+ dn->name);
+ kfree(irqs);
+ return -EINVAL;
+ }
+
+ using_spi = spi;
}
+ /* Now look up the logical CPU number */
for_each_possible_cpu(cpu)
if (arch_find_n_match_cpu_physical_id(dn, cpu, NULL))
break;
@@ -824,20 +831,36 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
pr_warn("Failed to find logical CPU for %s\n",
dn->name);
of_node_put(dn);
+ cpumask_setall(&pmu->supported_cpus);
break;
}
of_node_put(dn);
- irqs[i] = cpu;
+ /* For SPIs, we need to track the affinity per IRQ */
+ if (using_spi) {
+ if (i >= pdev->num_resour
[PATCH v3 0/6] Add support for DA9150 Fuel-Gauge
This patch set adds support for the Dialog DA9150 Fuel-Gauge. In this patch set the following is provided: - MFD Core and DT bindings updates. - Power Supply Fuel-Gauge support and DT bindings documentation. This patch set is baselined against the v4.2-rc1 kernel version. Changes in v3: - MFD: Some tidy up of code (gotos, dropped FG header, DEFINE_RES_IRQ_NAMED) - MFD & Power: Drop use of callback function for temperature reading, as requested by Lee Jones. - MFD (DT): Binding doc update to flesh out example text. - MFD (DT): New patch to change MFD binding doc to use relative paths. - MFD: New patch to use DEFINE_RES_IRQ_NAMED for all other IRQ resources. Changes in v2: - Moved temp callback function prototype to be part of power fuel-gauge patch, as requested by Lee Jones. Adam Thomson (6): mfd: da9150: Add support for Fuel-Gauge mfd: da9150: Update DT bindings for Fuel-Gauge support power: Add support for DA9150 Fuel-Gauge power: da9150: Add DT bindings documentation for Fuel-Gauge mfd: da9150: Use relative paths in DT bindings document mfd: da9150: Use DEFINE_RES_IRQ_NAMED() help macro for IRQ resource Documentation/devicetree/bindings/mfd/da9150.txt | 31 +- .../devicetree/bindings/power/da9150-fg.txt| 23 + drivers/mfd/da9150-core.c | 191 +-- drivers/power/Kconfig | 10 + drivers/power/Makefile | 1 + drivers/power/da9150-fg.c | 574 + include/linux/mfd/da9150/core.h| 19 +- 7 files changed, 805 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/da9150-fg.txt create mode 100644 drivers/power/da9150-fg.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/6] mfd: da9150: Use relative paths in DT bindings document
When referencing other DT bindings documentation, use relative path rather than absolute. Signed-off-by: Adam Thomson --- Changes in v3: - Initial version. Changes in v2: - N/A Documentation/devicetree/bindings/mfd/da9150.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/da9150.txt b/Documentation/devicetree/bindings/mfd/da9150.txt index d629ed5..a99b6d6 100644 --- a/Documentation/devicetree/bindings/mfd/da9150.txt +++ b/Documentation/devicetree/bindings/mfd/da9150.txt @@ -17,13 +17,13 @@ Required properties: the IRQs from da9150 are delivered to. - interrupts: IRQ line info for da9150 chip. - interrupt-controller: da9150 has internal IRQs (own IRQ domain). - (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for + (See ../interrupt-controller/interrupts.txt for further information relating to interrupt properties) Sub-devices: -- da9150-gpadc: See Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt -- da9150-charger: See Documentation/devicetree/bindings/power/da9150-charger.txt -- da9150-fg: See Documentation/devicetree/bindings/power/da9150-fg.txt +- da9150-gpadc: See ../iio/adc/da9150-gpadc.txt +- da9150-charger: See ../power/da9150-charger.txt +- da9150-fg: See ../power/da9150-fg.txt Example: -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/6] mfd: da9150: Add support for Fuel-Gauge
Signed-off-by: Adam Thomson
---
Changes in v3:
- Use DEFINE_RES_IRQ_NAMED() helper for defining FG IRQ resource.
- Unwanted new line & comments removed.
- Remove gotos which can be replaced with straight forward return calls.
- Add enum for indexing MFD cells list, which is used to assign pdata for FG
sub-device.
- Remove use of function pointers for QIF related read/write functions as
currently only I2C supported, so call I2C functions directly.
- Fold fg.h contents into core.h.
Changes in v2:
- Moved temp callback function prototype to be part of power fuel-gauge patch,
as requested by Lee Jones.
drivers/mfd/da9150-core.c | 156 ++--
include/linux/mfd/da9150/core.h | 19 -
2 files changed, 167 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/da9150-core.c b/drivers/mfd/da9150-core.c
index 94b9bbd..fccd4d5 100644
--- a/drivers/mfd/da9150-core.c
+++ b/drivers/mfd/da9150-core.c
@@ -23,6 +23,77 @@
#include
#include
+/* Raw device access, used for QIF */
+static int da9150_i2c_read_device(struct i2c_client *client, u8 addr, int
count,
+ u8 *buf)
+{
+ struct i2c_msg xfer;
+ int ret;
+
+ /*
+* Read is split into two transfers as device expects STOP/START rather
+* than repeated start to carry out this kind of access.
+*/
+
+ /* Write address */
+ xfer.addr = client->addr;
+ xfer.flags = 0;
+ xfer.len = 1;
+ xfer.buf = &addr;
+
+ ret = i2c_transfer(client->adapter, &xfer, 1);
+ if (ret != 1) {
+ if (ret < 0)
+ return ret;
+ else
+ return -EIO;
+ }
+
+ /* Read data */
+ xfer.addr = client->addr;
+ xfer.flags = I2C_M_RD;
+ xfer.len = count;
+ xfer.buf = buf;
+
+ ret = i2c_transfer(client->adapter, &xfer, 1);
+ if (ret == 1)
+ return 0;
+ else if (ret < 0)
+ return ret;
+ else
+ return -EIO;
+}
+
+static int da9150_i2c_write_device(struct i2c_client *client, u8 addr,
+ int count, const u8 *buf)
+{
+ struct i2c_msg xfer;
+ u8 *reg_data;
+ int ret;
+
+ reg_data = kzalloc(1 + count, GFP_KERNEL);
+ if (!reg_data)
+ return -ENOMEM;
+
+ reg_data[0] = addr;
+ memcpy(®_data[1], buf, count);
+
+ /* Write address & data */
+ xfer.addr = client->addr;
+ xfer.flags = 0;
+ xfer.len = 1 + count;
+ xfer.buf = reg_data;
+
+ ret = i2c_transfer(client->adapter, &xfer, 1);
+ kfree(reg_data);
+ if (ret == 1)
+ return 0;
+ else if (ret < 0)
+ return ret;
+ else
+ return -EIO;
+}
+
static bool da9150_volatile_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -107,6 +178,28 @@ static const struct regmap_config da9150_regmap_config = {
.volatile_reg = da9150_volatile_reg,
};
+void da9150_read_qif(struct da9150 *da9150, u8 addr, int count, u8 *buf)
+{
+ int ret;
+
+ ret = da9150_i2c_read_device(da9150->core_qif, addr, count, buf);
+ if (ret < 0)
+ dev_err(da9150->dev, "Failed to read from QIF 0x%x: %d\n",
+ addr, ret);
+}
+EXPORT_SYMBOL_GPL(da9150_read_qif);
+
+void da9150_write_qif(struct da9150 *da9150, u8 addr, int count, const u8 *buf)
+{
+ int ret;
+
+ ret = da9150_i2c_write_device(da9150->core_qif, addr, count, buf);
+ if (ret < 0)
+ dev_err(da9150->dev, "Failed to write to QIF 0x%x: %d\n",
+ addr, ret);
+}
+EXPORT_SYMBOL_GPL(da9150_write_qif);
+
u8 da9150_reg_read(struct da9150 *da9150, u16 reg)
{
int val, ret;
@@ -297,19 +390,35 @@ static struct resource da9150_charger_resources[] = {
},
};
+static struct resource da9150_fg_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9150_IRQ_FG, "FG"),
+};
+
+enum da9150_dev_idx {
+ DA9150_GPADC_IDX = 0,
+ DA9150_CHARGER_IDX,
+ DA9150_FG_IDX,
+};
+
static struct mfd_cell da9150_devs[] = {
- {
+ [DA9150_GPADC_IDX] = {
.name = "da9150-gpadc",
.of_compatible = "dlg,da9150-gpadc",
.resources = da9150_gpadc_resources,
.num_resources = ARRAY_SIZE(da9150_gpadc_resources),
},
- {
+ [DA9150_CHARGER_IDX] = {
.name = "da9150-charger",
.of_compatible = "dlg,da9150-charger",
.resources = da9150_charger_resources,
.num_resources = ARRAY_SIZE(da9150_charger_resources),
},
+ [DA9150_FG_IDX] = {
+ .name = "da9150-fuelgauge",
+ .of_compatible = "dlg,da9150-fg",
+ .resources = da9150_fg_resources,
+ .num_resources = ARRAY_SIZE(da9150_fg_resources),
+ },
[PATCH v3 3/6] power: Add support for DA9150 Fuel-Gauge
Signed-off-by: Adam Thomson
---
Changes in v3:
- Removed use of temp callback function, at request of Lee Jones.
- Comment added to clarify limitation of temperature reading functionality
that remains.
Changes in v2:
- Moved temp callback function prototype to be part of power fuel-gauge patch,
rather than MFD, as requested by Lee Jones.
drivers/power/Kconfig | 10 +
drivers/power/Makefile| 1 +
drivers/power/da9150-fg.c | 574 ++
3 files changed, 585 insertions(+)
create mode 100644 drivers/power/da9150-fg.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 08beeed..5773b87 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -204,6 +204,16 @@ config CHARGER_DA9150
This driver can also be built as a module. If so, the module will be
called da9150-charger.
+config FG_DA9150
+ tristate "Dialog Semiconductor DA9150 Fuel Gauge support"
+ depends on CHARGER_DA9150
+ help
+ Say Y here to enable support for the Fuel-Gauge unit of the DA9150
+ Integrated Charger & Fuel-Gauge IC
+
+ This driver can also be built as a module. If so, the module will be
+ called da9150-fg.
+
config AXP288_CHARGER
tristate "X-Powers AXP288 Charger"
depends on MFD_AXP20X && EXTCON_AXP288
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 5752ce8..25be564 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
obj-$(CONFIG_BATTERY_DA9052) += da9052-battery.o
obj-$(CONFIG_CHARGER_DA9150) += da9150-charger.o
+obj-$(CONFIG_FG_DA9150)+= da9150-fg.o
obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
obj-$(CONFIG_BATTERY_Z2) += z2_battery.o
diff --git a/drivers/power/da9150-fg.c b/drivers/power/da9150-fg.c
new file mode 100644
index 000..09dad57
--- /dev/null
+++ b/drivers/power/da9150-fg.c
@@ -0,0 +1,574 @@
+/*
+ * DA9150 Fuel-Gauge Driver
+ *
+ * Copyright (c) 2015 Dialog Semiconductor
+ *
+ * Author: Adam Thomson
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Core2Wire */
+#define DA9150_QIF_READ(0x0 << 7)
+#define DA9150_QIF_WRITE (0x1 << 7)
+#define DA9150_QIF_CODE_MASK 0x7F
+
+#define DA9150_QIF_BYTE_SIZE 8
+#define DA9150_QIF_BYTE_MASK 0xFF
+#define DA9150_QIF_SHORT_SIZE 2
+#define DA9150_QIF_LONG_SIZE 4
+
+/* QIF Codes */
+#define DA9150_QIF_UAVG6
+#define DA9150_QIF_UAVG_SIZE DA9150_QIF_LONG_SIZE
+#define DA9150_QIF_IAVG8
+#define DA9150_QIF_IAVG_SIZE DA9150_QIF_LONG_SIZE
+#define DA9150_QIF_NTCAVG 12
+#define DA9150_QIF_NTCAVG_SIZE DA9150_QIF_LONG_SIZE
+#define DA9150_QIF_SHUNT_VAL 36
+#define DA9150_QIF_SHUNT_VAL_SIZE DA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_SD_GAIN 38
+#define DA9150_QIF_SD_GAIN_SIZEDA9150_QIF_LONG_SIZE
+#define DA9150_QIF_FCC_MAH 40
+#define DA9150_QIF_FCC_MAH_SIZEDA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_SOC_PCT 43
+#define DA9150_QIF_SOC_PCT_SIZEDA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_CHARGE_LIMIT44
+#define DA9150_QIF_CHARGE_LIMIT_SIZE DA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_DISCHARGE_LIMIT 45
+#define DA9150_QIF_DISCHARGE_LIMIT_SIZEDA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_FW_MAIN_VER 118
+#define DA9150_QIF_FW_MAIN_VER_SIZEDA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_E_FG_STATUS 126
+#define DA9150_QIF_E_FG_STATUS_SIZEDA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_SYNC127
+#define DA9150_QIF_SYNC_SIZE DA9150_QIF_SHORT_SIZE
+#define DA9150_QIF_MAX_CODES 128
+
+/* QIF Sync Timeout */
+#define DA9150_QIF_SYNC_TIMEOUT1000
+#define DA9150_QIF_SYNC_RETRIES10
+
+/* QIF E_FG_STATUS */
+#define DA9150_FG_IRQ_LOW_SOC_MASK (1 << 0)
+#define DA9150_FG_IRQ_HIGH_SOC_MASK(1 << 1)
+
+/* Private data */
+struct da9150_fg {
+ struct da9150 *da9150;
+ struct device *dev;
+
+ struct mutex io_lock;
+
+ struct power_supply *battery;
+ struct delayed_work work;
+ u32 interval;
+
+ int warn_soc;
+ int crit_soc;
+ int soc;
+};
+
+/* Battery Properties */
+static u32 da9150_fg_read_attr(struct da9150_fg *fg, u8 code, u8 size)
+
+{
+ u8 buf[size
[PATCH v3 2/6] mfd: da9150: Update DT bindings for Fuel-Gauge support
Signed-off-by: Adam Thomson
Acked-by: Lee Jones
---
Changes in v3:
- Removal of unwanted new-line.
- Flesh out example bindings usage.
Changes in v2:
- N/A
Documentation/devicetree/bindings/mfd/da9150.txt | 25 +---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/da9150.txt
b/Documentation/devicetree/bindings/mfd/da9150.txt
index d0588ea..d629ed5 100644
--- a/Documentation/devicetree/bindings/mfd/da9150.txt
+++ b/Documentation/devicetree/bindings/mfd/da9150.txt
@@ -6,6 +6,7 @@ Device Description
-- ---
da9150-gpadc : General Purpose ADC
da9150-charger : Battery Charger
+da9150-fg : Battery Fuel-Gauge
==
@@ -22,7 +23,7 @@ Required properties:
Sub-devices:
- da9150-gpadc: See Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt
- da9150-charger: See
Documentation/devicetree/bindings/power/da9150-charger.txt
-
+- da9150-fg: See Documentation/devicetree/bindings/power/da9150-fg.txt
Example:
@@ -34,10 +35,28 @@ Example:
interrupt-controller;
gpadc: da9150-gpadc {
- ...
+ compatible = "dlg,da9150-gpadc";
+ #io-channel-cells = <1>;
};
da9150-charger {
- ...
+ compatible = "dlg,da9150-charger";
+
+ io-channels = <&gpadc 0>,
+ <&gpadc 2>,
+ <&gpadc 8>,
+ <&gpadc 5>;
+ io-channel-names = "CHAN_IBUS",
+ "CHAN_VBUS",
+ "CHAN_TJUNC",
+ "CHAN_VBAT";
+ };
+
+ da9150-fg {
+ compatible = "dlg,da9150-fg";
+
+ dlg,update-interval = <1>;
+ dlg,warn-soc-level = /bits/ 8 <15>;
+ dlg,crit-soc-level = /bits/ 8 <5>
};
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] power: da9150: Add DT bindings documentation for Fuel-Gauge
Signed-off-by: Adam Thomson
---
Changes in v3:
- N/A
Changes in v2:
- N/A
.../devicetree/bindings/power/da9150-fg.txt| 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/da9150-fg.txt
diff --git a/Documentation/devicetree/bindings/power/da9150-fg.txt
b/Documentation/devicetree/bindings/power/da9150-fg.txt
new file mode 100644
index 000..c3c76eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/da9150-fg.txt
@@ -0,0 +1,23 @@
+Dialog Semiconductor DA9150 Fuel-Gauge Power Supply bindings
+
+Required properties:
+- compatible: "dlg,da9150-fg" for DA9150 Fuel-Gauge Power Supply
+
+Optional properties:
+- dlg,update-interval: Interval time (milliseconds) between battery level
checks.
+- dlg,warn-soc-level: Battery discharge level (%) where warning event raised.
+ [1 - 100]
+- dlg,crit-soc-level: Battery discharge level (%) where critical event raised.
+ This value should be lower than the warning level.
+ [1 - 100]
+
+
+Example:
+
+ da9150-fg {
+ compatible = "dlg,da9150-fg";
+
+ dlg,update-interval = <1>;
+ dlg,warn-soc-level = /bits/ 8 <15>;
+ dlg,crit-soc-level = /bits/ 8 <5>;
+ };
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/6] mfd: da9150: Use DEFINE_RES_IRQ_NAMED() help macro for IRQ resource
Signed-off-by: Adam Thomson
---
Changes in v3:
- Initial version.
Changes in v2:
- N/A
drivers/mfd/da9150-core.c | 35 +--
1 file changed, 5 insertions(+), 30 deletions(-)
diff --git a/drivers/mfd/da9150-core.c b/drivers/mfd/da9150-core.c
index fccd4d5..dd4cb9b 100644
--- a/drivers/mfd/da9150-core.c
+++ b/drivers/mfd/da9150-core.c
@@ -355,39 +355,14 @@ static const struct regmap_irq_chip
da9150_regmap_irq_chip = {
};
static struct resource da9150_gpadc_resources[] = {
- {
- .name = "GPADC",
- .start = DA9150_IRQ_GPADC,
- .end = DA9150_IRQ_GPADC,
- .flags = IORESOURCE_IRQ,
- },
+ DEFINE_RES_IRQ_NAMED(DA9150_IRQ_GPADC, "GPADC"),
};
static struct resource da9150_charger_resources[] = {
- {
- .name = "CHG_STATUS",
- .start = DA9150_IRQ_CHG,
- .end = DA9150_IRQ_CHG,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "CHG_TJUNC",
- .start = DA9150_IRQ_TJUNC,
- .end = DA9150_IRQ_TJUNC,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "CHG_VFAULT",
- .start = DA9150_IRQ_VFAULT,
- .end = DA9150_IRQ_VFAULT,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "CHG_VBUS",
- .start = DA9150_IRQ_VBUS,
- .end = DA9150_IRQ_VBUS,
- .flags = IORESOURCE_IRQ,
- },
+ DEFINE_RES_IRQ_NAMED(DA9150_IRQ_CHG, "CHG_STATUS"),
+ DEFINE_RES_IRQ_NAMED(DA9150_IRQ_TJUNC, "CHG_TJUNC"),
+ DEFINE_RES_IRQ_NAMED(DA9150_IRQ_VFAULT, "CHG_VFAULT"),
+ DEFINE_RES_IRQ_NAMED(DA9150_IRQ_VBUS, "CHG_VBUS"),
};
static struct resource da9150_fg_resources[] = {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rx51-battery.ko incompatiblity: board code vs DT
On Tuesday 07 July 2015 17:02:30 Sebastian Reichel wrote: > Hi, > > On Mon, Jul 06, 2015 at 09:44:22PM +0200, Pali Rohár wrote: > > now I found out that rx51-battery.ko driver register sysnode > > /sys/class/power_supply/rx51-battery/ when booting with legacy board > > code. But when booting DT kernel it register sysnode with different name > > /sys/class/power_supply/n900-battery/ > > > > Sysfs node for DT kernel comes from Nokia N900 DTS file: > > arch/arm/boot/dts/omap3-n900.dts > > > > I would propose change which change DTS to "rx51-battery" to have it > > compatible with naming which is for legacy board code. It is just > > because to have compatibility and same naming scheme and also to make > > existing programs to work without needing patching them. > > > > What do you think? > > Change the driver instead (in rx51_battery_probe): > > - di->bat.name = dev_name(&pdev->dev); > + di->bat.name = "rx51-battery" > > This will keep the DT ABI stable and avoid introducing the term rx51 > in the device tree file. > > -- Sebastian Perfect, if it works fine can you send & apply patch? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/9] regulator: pwm-regulator: Re-write bindings
* Add support for continuous-voltage mode
* Put more meat on the bones with regards to voltage-table mode
* Sort out formatting for ease of consumption
Cc: devicetree@vger.kernel.org
Signed-off-by: Lee Jones
---
.../bindings/regulator/pwm-regulator.txt | 68 ++
1 file changed, 56 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index ce91f61..892b366 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -1,27 +1,71 @@
-pwm regulator bindings
+Bindings for the Generic PWM Regulator
+==
+
+Currently supports 2 modes of operation:
+
+voltage-table: When in this mode, a voltage table (See below) of
+ predefined voltage <=> duty-cycle values must be
+ provided via DT. Limitations are that the regulator can
+ only operate at the voltages supplied in the table.
+ Intermediary duty-cycle values which would normally
+ allow finer grained voltage selection are ignored and
+ rendered useless. Although more control is given to
+ the user if the assumptions made in continuous-voltage
+ mode do not reign true.
+
+continuous-voltage:This mode uses the regulator's maximum and minimum
+ supplied voltages specified in the
+ regulator-{min,max}-microvolt properties to calculate
+ appropriate duty-cycle values. This allows for a much
+ more fine grained solution when compared with
+ voltage-table mode above. This solution does make an
+ assumption that a %50 duty-cycle value will cause the
+ regulator voltage to run at half way between the
+ supplied max_uV and min_uV values.
Required properties:
-- compatible: Should be "pwm-regulator"
-- pwms: OF device-tree PWM specification (see PWM binding pwm.txt)
-- voltage-table: voltage and duty table, include 2 members in each set of
- brackets, first one is voltage(unit: uv), the next is duty(unit: percent)
+
+- compatible: Should be "pwm-regulator"
+
+- pwms:PWM specification (See: ../pwm/pwm.txt)
+
+One of these must be provided:
+- voltage-table: Voltage and Duty-Cycle table consisting of 2 cells
+ First cell is voltage in microvolts (uV)
+ Second cell is duty-cycle in percent (%)
+
+- max-duty-cycle: Maximum Duty-Cycle value -- this will normally be
+ 255 (0xff) for an 8 bit PWM device
-Any property defined as part of the core regulator binding defined in
-regulator.txt can also be used.
+If both are provided, the current default is voltage-table mode.
-Example:
+Any property defined as part of the core regulator binding can also be used.
+(See: ../regulator/regulator.txt)
+
+Continuous Voltage Example:
pwm_regulator {
compatible = "pwm-regulator;
pwms = <&pwm1 0 8448 0>;
+ regulator-min-microvolt = <1016000>;
+ regulator-max-microvolt = <1114000>;
+ regulator-name = "vdd_logic";
+
+ max-duty-cycle = <255>; /* 8bit PWM */
+ };
+Voltage Table Example:
+ pwm_regulator {
+ compatible = "pwm-regulator;
+ pwms = <&pwm1 0 8448 0>;
+ regulator-min-microvolt = <1016000>;
+ regulator-max-microvolt = <1114000>;
+ regulator-name = "vdd_logic";
+
+ /* Voltage Duty-Cycle */
voltage-table = <1114000 0>,
<1095000 10>,
<1076000 20>,
<1056000 30>,
<1036000 40>,
<1016000 50>;
-
- regulator-min-microvolt = <1016000>;
- regulator-max-microvolt = <1114000>;
- regulator-name = "vdd_logic";
};
--
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] arm64: dts: mt8173: add clock_null
On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer wrote:
> On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
>> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer wrote:
>> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
>> >> Add clk_null, which represents clocks that can not / need not
>> >> controlled by software.
>> >> There are many clocks' parent set to clk_null.
>> >>
>> >> Signed-off-by: James Liao
>> >> Signed-off-by: Eddie Huang
>> >> ---
>> >> Base on 4.1-rc1
>> >>
>> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
>> >> ---
>> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> index 924fdb6..4798f44 100644
>> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> @@ -81,6 +81,12 @@
>> >> cpu_on= <0x8403>;
>> >> };
>> >>
>> >> + clk_null: clk_null {
>> >> + compatible = "fixed-clock";
>> >> + clock-frequency = <0>;
>> >> + #clock-cells = <0>;
>> >> + };
>> >
>> > The discussion around this patch shows that we don't want to have this
>> > clock in the device tree as it is not a hardware description.
>> >
>> > Ok, fine. Eddie, you told us that the rate of the current clk_null children
>> > is not interesting. What's the motivation to send this patch anyway
>> > then? Why can't you keep its children on the orphan list where they are
>> > already now?
>> >
>> > Another possibility would be to instantiate the clk_null clock from C
>> > code rather than from the device tree. This way we wouldn't put any
>> > wrong descriptions into the device tree and still can implement the
>> > support for the real parent clocks when we actually need them.
>>
>> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
>>
>> mmc1: mmc@1124 {
>> compatible = "mediatek,mt8173-mmc",
>> "mediatek,mt8135-mmc";
>> reg = <0 0x1124 0 0x1000>;
>> interrupts = ;
>> clocks = <&pericfg CLK_PERI_MSDC30_1>,
>> <&clk_null>;
>> clock-names = "source", "hclk";
>> status = "disabled";
>> };
>
> This is another case than the one we discussed about. In the case above
> I motivated using a dummy clock since the clock exists in the system,
> but is not software controllable. To abstract this from the driver
> (which needs this clock since it exists) we here have the dummy clock.
> However, of course I can't prove the clock is indeed not software
> controllable; that's only the information I have.
I was trying to answer your question "What's the motivation to send
this patch anyway?".
The motivation is to send follow on patches that use the clk_null
phandle. We need to provide some clock as the mmc1's hclk. I do not
understand why this has to be "clk_null", though. It seems like this
should be a real clock coming from one of the real clock_controller
nodes. After all, the mmc driver is going to be enabling/disabling
this clock for power savings at runtime. What does that even mean for
clk_null ?
Sorry, I'm not exactly sure what you are saying in your last reply.
>
> 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- |
--
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: rx51-battery.ko incompatiblity: board code vs DT
Hi, On Mon, Jul 06, 2015 at 09:44:22PM +0200, Pali Rohár wrote: > now I found out that rx51-battery.ko driver register sysnode > /sys/class/power_supply/rx51-battery/ when booting with legacy board > code. But when booting DT kernel it register sysnode with different name > /sys/class/power_supply/n900-battery/ > > Sysfs node for DT kernel comes from Nokia N900 DTS file: > arch/arm/boot/dts/omap3-n900.dts > > I would propose change which change DTS to "rx51-battery" to have it > compatible with naming which is for legacy board code. It is just > because to have compatibility and same naming scheme and also to make > existing programs to work without needing patching them. > > What do you think? Change the driver instead (in rx51_battery_probe): - di->bat.name = dev_name(&pdev->dev); + di->bat.name = "rx51-battery" This will keep the DT ABI stable and avoid introducing the term rx51 in the device tree file. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote: > > > On Tuesday 07 July 2015 06:24 PM, Lee Jones wrote: > >On Tue, 07 Jul 2015, Vaibhav Hiremath wrote: > > > >> > >> > >>On Tuesday 07 July 2015 04:48 PM, Vaibhav Hiremath wrote: > >>> > >>> > >>>On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote: > On Tue, 07 Jul 2015, Vaibhav Hiremath wrote: > >On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote: > >>On Tue, 07 Jul 2015, Vaibhav Hiremath wrote: > >>>On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote: > On Mon, 29 Jun 2015, Vaibhav Hiremath wrote: > > >As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe > >(page 0) controls the method of clearing interrupt > >status of 88pm800 family of devices; > > > > 0: clear on read > > 1: clear on write > > > >If pdata is not coming from board file, then set the > >default irq clear method to "irq clear on write" > > > >Also, as suggested by "Lee Jones" renaming variable field > >to appropriate name. > > > >Signed-off-by: Zhao Ye > >Signed-off-by: Vaibhav Hiremath > >--- > > drivers/mfd/88pm800.c | 15 ++- > > include/linux/mfd/88pm80x.h | 10 -- > > 2 files changed, 18 insertions(+), 7 deletions(-) > > > > > > >>> > >>>Yes certainly, this is another option (rather preferred one). > >>> > >>>But to be consistent with other's I proposed this, please refer to the > >>>fn device_800_init(), where all xxx_init() are taking 2 arguments, and > >>>second argument is pdata. > >>> > >>> > >>>There is room for cleanup, I agree. > >>>I can put this too in the next cleanup series. > >>> > >> > >>Note that this is init function, called from probe. > >> > >>So both approach looks ok to me. > > > >Please clean up the other. Function and put it at the front of the > >set when you re-submit. > > > > Sorry for dumb question here :) > I did not understand what do you mean by "in front of the set"? > > You want to see all the patches into one single series? > Or > have separate series, > 1. existing DT addition series > 2. new clean-up series [PATCH v6 0/5] mfd: 88pm800: Add Device tree support ├>[PATCH v6 1/5] mfd: 88pm800: Obtain pdata from 'device' rather than passing as parameter ├>[PATCH v6 2/5] mfd: 88pm800: Add device tree support ├>[PATCH v6 3/5] mfd: 88pm800: Remove unnecessary protection around pdata ├>[PATCH v6 4/5] mfd: 88pm800: Set default interrupt clear method ├>[PATCH v6 5/5] mfd: devicetree: bindings: Add new 88pm800 mfd binding -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
On 07/07/2015 05:13 PM, Wolfram Sang wrote: > On Tue, Jul 07, 2015 at 03:48:52PM +0200, Uwe Kleine-König wrote: >> On Tue, Jul 07, 2015 at 03:37:49PM +0200, Jan Lübbe wrote: >>> On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote: On 11/26/2014 06:04 PM, Uwe Kleine-König wrote: > On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote: >> Having a board where the I2C bus locks up occasionally made it clear >> that the bus recovery in the i2c-davinci driver will only work on >> some boards, because on regular boards, this will only toggle GPIO >> lines that aren't muxed to the actual pins. >> >> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the >> built-in capability to bit-bang its lines by using the ICPFUNC registers >> of the i2c controller. >> Implement the suggested procedure by toggling SCL and checking SDA using >> the ICPFUNC registers of the I2C controller when present. Allow platforms >> to indicate the presence of the ICPFUNC registers with a has_pfunc >> platform >> data flag and add optional DT property "ti,has-pfunc" to indicate >> the same in DT. > On what does it depend if this pfunc stuff works or not? Only the SoC, > or also on some board specific properties? SoC / set of SoCs. Also, similar feature is supported by OMAP and AM335x/AM437x SoCs using I2C_SYSTEST register. > Given the former using the > compatible string to detect its availability would be better. (In this > case also sorry, didn't consider this case when requesting the property > in the last round.) >>> >>> I only stumbled across this after it was merged, with the additional >> I also wonder how it came to the Reviewed-by tag for me. The last thing >> that I said about the patch was "On what does it depend if this pfunc >> stuff works or not? Only the SoC, or also on some board specific >> properties?" (see above) and "the patch looks ok". IMHO this hardly >> justifies to add the Reviewed-by tag for the next round. :-( > > That needs to be discussed with Grygorii. I can't verify the correctness > of tags for every patch, although I do try to keep an eye on it... > Regarding "the patch looks ok" - sincerely sorry! This is not the first time I've treated "looks good.." as Reviewed-by and I got no complaints before :( Will take it into account. Regarding technical comments: OK. Seems I missed smth. or understood wrongly. So, I'll say what's people usually saying here - Sorry for that :( But, to be honest I don't feel guilty, because: - v4 of these patches was merged finally - that v4 missed >2 kernel releases - you were added in "TO:" for all versions of these patches. -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: UniPhier: add USB EHCI device nodes
On Sun, Jul 5, 2015 at 10:47 PM, Masahiro Yamada
wrote:
> Get USB 2.0 host controllers available with generic-ehci bindings.
>
> Signed-off-by: Masahiro Yamada
> ---
> diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
> b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
> index 1261e6d..b042711 100644
> --- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
> +++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
> @@ -127,6 +127,27 @@
> reg = <0x5980 0x2000>;
> };
>
> + usb0: usb@5a800100 {
> + compatible = "generic-ehci";
You should also have a chip specific compatible string in addition to
generic-ehci.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 06:24 PM, Lee Jones wrote: On Tue, 07 Jul 2015, Vaibhav Hiremath wrote: On Tuesday 07 July 2015 04:48 PM, Vaibhav Hiremath wrote: On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote: On Tue, 07 Jul 2015, Vaibhav Hiremath wrote: On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote: On Tue, 07 Jul 2015, Vaibhav Hiremath wrote: On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote: On Mon, 29 Jun 2015, Vaibhav Hiremath wrote: As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe (page 0) controls the method of clearing interrupt status of 88pm800 family of devices; 0: clear on read 1: clear on write If pdata is not coming from board file, then set the default irq clear method to "irq clear on write" Also, as suggested by "Lee Jones" renaming variable field to appropriate name. Signed-off-by: Zhao Ye Signed-off-by: Vaibhav Hiremath --- drivers/mfd/88pm800.c | 15 ++- include/linux/mfd/88pm80x.h | 10 -- 2 files changed, 18 insertions(+), 7 deletions(-) Yes certainly, this is another option (rather preferred one). But to be consistent with other's I proposed this, please refer to the fn device_800_init(), where all xxx_init() are taking 2 arguments, and second argument is pdata. There is room for cleanup, I agree. I can put this too in the next cleanup series. Note that this is init function, called from probe. So both approach looks ok to me. Please clean up the other. Function and put it at the front of the set when you re-submit. Sorry for dumb question here :) I did not understand what do you mean by "in front of the set"? You want to see all the patches into one single series? Or have separate series, 1. existing DT addition series 2. new clean-up series Thanks, Vaibhav -- 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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250
Bartlomiej Zolnierkiewicz wrote: > > Hi, > Hi, > On Thursday, July 02, 2015 09:42:38 AM Chanwoo Choi wrote: > > This patchset use cpufreq-dt driver to support Exynos3250 cpufreq and > > tested it > > on Exynos3250-based Rinato board. > > > > Depends on: > > - next-20150701 tag (master branch) of linux-next kernel tree > > - This patch-set is based on Exynos5250 patch-set[1] because two patch-set > > modify the 'arch/arm/mach-exynos/exynos.c' to add the compatible string. > > [1] https://lkml.org/lkml/2015/6/29/361 > > : [PATCH v2 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 > > platform > > > > Changes from v5: > > (https://lkml.org/lkml/2015/7/1/324) > > - Reorder the cpu dt node in exynos3250-rinato/monk.dts alpabetically. > > - Add reviewed-by tag of Krzysztof Kozlowski > > > > Changes from v4: > > (https://lkml.org/lkml/2014/10/20/215) > > - Rebased on latest linux-next git repository. > > - Remove unnecessary divider clock flag from divider of DIV_CPU0/DIV_CPU1 > > register > > > > Changes from v3: > > - This patchset is based on 3.18-rc1 with new patchset[3] of Thomas Abraham > > [3] [PATCH v11 0/6] cpufreq: use generic cpufreq drivers for exynos > > platforms > > - http://www.spinics.net/lists/arm-kernel/msg370412.html > > > > Changes from v2: > > - Rebased on new patchset of Thomas Abraham > > and for-next branch of samsunc-clk.git of Tomasz Figa > > > > Changes from v1: > > - Rebased on new patchset[1] by Thomas Abraham > > [1] [PATCH v10 0/6] cpufreq: use generic cpufreq drivers for exynos > > platforms > > - http://www.spinics.net/lists/arm-kernel/msg364790.html > > - Modify clk-cpu.c to support Exynos3250 > > - Drop documentation patch on previous patchset[2] > > [2] http://www.spinics.net/lists/cpufreq/msg10265.html > > - Add only operating-points for Exynos3250 without armclk-divider-table > > > > Chanwoo Choi (3): > > clk: samsung: exynos3250: Add cpu clock configuration data and instaniate > > cpu clock > > ARM: dts: Add CPU OPP and regulator supply property for Exynos3250 > > ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver > > > > arch/arm/boot/dts/exynos3250-monk.dts | 4 > > arch/arm/boot/dts/exynos3250-rinato.dts | 4 > > arch/arm/boot/dts/exynos3250.dtsi | 15 +++ > > arch/arm/mach-exynos/exynos.c | 1 + > > drivers/clk/samsung/clk-exynos3250.c| 32 > > ++-- > > include/dt-bindings/clock/exynos3250.h | 1 + > > 6 files changed, 55 insertions(+), 2 deletions(-) > > Reviewed-by: Bartlomiej Zolnierkiewicz > > Thank you for working on this. > +1 Thanks. Mike and Sylwester, if you're OK on this series, I'd like to pick up in Samsung tree together. And if you want, I could provide topic branch for clk tree. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer wrote:
> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> >> Add clk_null, which represents clocks that can not / need not
> >> controlled by software.
> >> There are many clocks' parent set to clk_null.
> >>
> >> Signed-off-by: James Liao
> >> Signed-off-by: Eddie Huang
> >> ---
> >> Base on 4.1-rc1
> >>
> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> >> ---
> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> index 924fdb6..4798f44 100644
> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> @@ -81,6 +81,12 @@
> >> cpu_on= <0x8403>;
> >> };
> >>
> >> + clk_null: clk_null {
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <0>;
> >> + #clock-cells = <0>;
> >> + };
> >
> > The discussion around this patch shows that we don't want to have this
> > clock in the device tree as it is not a hardware description.
> >
> > Ok, fine. Eddie, you told us that the rate of the current clk_null children
> > is not interesting. What's the motivation to send this patch anyway
> > then? Why can't you keep its children on the orphan list where they are
> > already now?
> >
> > Another possibility would be to instantiate the clk_null clock from C
> > code rather than from the device tree. This way we wouldn't put any
> > wrong descriptions into the device tree and still can implement the
> > support for the real parent clocks when we actually need them.
>
> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
>
> mmc1: mmc@1124 {
> compatible = "mediatek,mt8173-mmc",
> "mediatek,mt8135-mmc";
> reg = <0 0x1124 0 0x1000>;
> interrupts = ;
> clocks = <&pericfg CLK_PERI_MSDC30_1>,
> <&clk_null>;
> clock-names = "source", "hclk";
> status = "disabled";
> };
This is another case than the one we discussed about. In the case above
I motivated using a dummy clock since the clock exists in the system,
but is not software controllable. To abstract this from the driver
(which needs this clock since it exists) we here have the dummy clock.
However, of course I can't prove the clock is indeed not software
controllable; that's only the information I have.
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- |
--
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] arm64: dts: mt8173: add clock_null
On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer wrote:
> On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
>> Add clk_null, which represents clocks that can not / need not
>> controlled by software.
>> There are many clocks' parent set to clk_null.
>>
>> Signed-off-by: James Liao
>> Signed-off-by: Eddie Huang
>> ---
>> Base on 4.1-rc1
>>
>> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 924fdb6..4798f44 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -81,6 +81,12 @@
>> cpu_on= <0x8403>;
>> };
>>
>> + clk_null: clk_null {
>> + compatible = "fixed-clock";
>> + clock-frequency = <0>;
>> + #clock-cells = <0>;
>> + };
>
> The discussion around this patch shows that we don't want to have this
> clock in the device tree as it is not a hardware description.
>
> Ok, fine. Eddie, you told us that the rate of the current clk_null children
> is not interesting. What's the motivation to send this patch anyway
> then? Why can't you keep its children on the orphan list where they are
> already now?
>
> Another possibility would be to instantiate the clk_null clock from C
> code rather than from the device tree. This way we wouldn't put any
> wrong descriptions into the device tree and still can implement the
> support for the real parent clocks when we actually need them.
Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
mmc1: mmc@1124 {
compatible = "mediatek,mt8173-mmc",
"mediatek,mt8135-mmc";
reg = <0 0x1124 0 0x1000>;
interrupts = ;
clocks = <&pericfg CLK_PERI_MSDC30_1>,
<&clk_null>;
clock-names = "source", "hclk";
status = "disabled";
};
-Dan
> 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- |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: socfpga: dts: Fix adxl34x formating
On 6/26/15 5:36 AM, Walter Lozano wrote:
> Hi Steffen
>
> On Fri, Jun 26, 2015 at 4:16 AM, Steffen Trumtrar
> wrote:
>> Hi Walter!
>>
>> On Thu, Jun 25, 2015 at 11:25:57PM -0300, Walter Lozano wrote:
>>> This patch fixes the formating of DTS bindings for the adxl34x digital
>>> accelerometer.
>>>
>>> Signed-off-by: Walter Lozano
>>> ---
>>> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts |6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>>> b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>>> index 71468a7..5b60692 100644
>>> --- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>>> @@ -73,14 +73,14 @@
>>> status = "okay";
>>> };
>>>
>>> -&i2c1{
>>> +&i2c1 {
>>> status = "okay";
>>>
>>> - accel1: accel1@53{
>>> + accel1: accelerometer@53 {
>>> compatible = "adxl34x";
>>> reg = <0x53>;
>>>
>>> - interrupt-parent = < &portc >;
>>> + interrupt-parent = <&portc>;
>>> interrupts = <3 2>;
>>> };
>>> };
>>
>> I would personally squash 3/3 into this one, but otherwise:
>>
>> Whole series
>>
>> Acked-by: Steffen Trumtrar
>>
>
> Thanks for your comments. I have no problem at all. Dinh?
I've applied and squashed 1/3 and 3/3 together.
Thanks,
Dinh
--
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 5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
On Tue, Jul 07, 2015 at 03:48:52PM +0200, Uwe Kleine-König wrote: > Hello, > > On Tue, Jul 07, 2015 at 03:37:49PM +0200, Jan Lübbe wrote: > > On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote: > > > On 11/26/2014 06:04 PM, Uwe Kleine-König wrote: > > > > On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote: > > > >> Having a board where the I2C bus locks up occasionally made it clear > > > >> that the bus recovery in the i2c-davinci driver will only work on > > > >> some boards, because on regular boards, this will only toggle GPIO > > > >> lines that aren't muxed to the actual pins. > > > >> > > > >> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the > > > >> built-in capability to bit-bang its lines by using the ICPFUNC > > > >> registers > > > >> of the i2c controller. > > > >> Implement the suggested procedure by toggling SCL and checking SDA > > > >> using > > > >> the ICPFUNC registers of the I2C controller when present. Allow > > > >> platforms > > > >> to indicate the presence of the ICPFUNC registers with a has_pfunc > > > >> platform > > > >> data flag and add optional DT property "ti,has-pfunc" to indicate > > > >> the same in DT. > > > > On what does it depend if this pfunc stuff works or not? Only the SoC, > > > > or also on some board specific properties? > > > > > > SoC / set of SoCs. Also, similar feature is supported by OMAP and > > > AM335x/AM437x SoCs > > > using I2C_SYSTEST register. > > > > > > > Given the former using the > > > > compatible string to detect its availability would be better. (In this > > > > case also sorry, didn't consider this case when requesting the property > > > > in the last round.) > > > > I only stumbled across this after it was merged, with the additional > I also wonder how it came to the Reviewed-by tag for me. The last thing > that I said about the patch was "On what does it depend if this pfunc > stuff works or not? Only the SoC, or also on some board specific > properties?" (see above) and "the patch looks ok". IMHO this hardly > justifies to add the Reviewed-by tag for the next round. :-( That needs to be discussed with Grygorii. I can't verify the correctness of tags for every patch, although I do try to keep an eye on it... signature.asc Description: Digital signature
Re: [PATCH v10 4/5] crypto: Add Allwinner Security System crypto accelerator
Hi Corentin, On Mon, Jul 06, 2015 at 09:10:47PM +0200, LABBE Corentin wrote: > Add support for the Security System included in Allwinner SoC A20. > The Security System is a hardware cryptographic accelerator that support: > - MD5 and SHA1 hash algorithms > - AES block cipher in CBC/ECB mode with 128/196/256bits keys. > - DES and 3DES block cipher in CBC/ECB mode > > Signed-off-by: LABBE Corentin There's still a number of style issues. Make sure to run checkpatch with the --strict option, and fix everything that's reported. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 1/3] ARM: socfpga: dts: Fix adxl34x formating
On Tue, Jul 7, 2015 at 11:00 AM, Dinh Nguyen
wrote:
>
>
> On 6/26/15 5:36 AM, Walter Lozano wrote:
>> Hi Steffen
>>
>> On Fri, Jun 26, 2015 at 4:16 AM, Steffen Trumtrar
>> wrote:
>>> Hi Walter!
>>>
>>> On Thu, Jun 25, 2015 at 11:25:57PM -0300, Walter Lozano wrote:
This patch fixes the formating of DTS bindings for the adxl34x digital
accelerometer.
Signed-off-by: Walter Lozano
---
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 71468a7..5b60692 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -73,14 +73,14 @@
status = "okay";
};
-&i2c1{
+&i2c1 {
status = "okay";
- accel1: accel1@53{
+ accel1: accelerometer@53 {
compatible = "adxl34x";
reg = <0x53>;
- interrupt-parent = < &portc >;
+ interrupt-parent = <&portc>;
interrupts = <3 2>;
};
};
>>>
>>> I would personally squash 3/3 into this one, but otherwise:
>>>
>>> Whole series
>>>
>>> Acked-by: Steffen Trumtrar
>>>
>>
>> Thanks for your comments. I have no problem at all. Dinh?
>
> I've applied and squashed 1/3 and 3/3 together.
>
Great! Thanks!
--
Walter Lozano, VanguardiaSur
www.vanguardiasur.com.ar
--
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 v6 23/23] usb: gadget: zero: allocate and init otg descriptor by otg capabilities
On 29/06/15 10:48, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations. If otg capability
is not defined, keep its original otg descriptor unchanged.
Signed-off-by: Li Jun
---
drivers/usb/gadget/legacy/zero.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/legacy/zero.c b/drivers/usb/gadget/legacy/zero.c
index c986e8a..695c2cb 100644
--- a/drivers/usb/gadget/legacy/zero.c
+++ b/drivers/usb/gadget/legacy/zero.c
@@ -121,24 +121,7 @@ static struct usb_device_descriptor device_desc = {
.bNumConfigurations = 2,
};
-#ifdef CONFIG_USB_OTG
-static struct usb_otg_descriptor otg_descriptor = {
- .bLength = sizeof otg_descriptor,
- .bDescriptorType = USB_DT_OTG,
-
- /* REVISIT SRP-only hardware is possible, although
-* it would not be called "OTG" ...
-*/
- .bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
- (struct usb_descriptor_header *) &otg_descriptor,
- NULL,
-};
-#else
-#define otg_desc NULL
-#endif
+static const struct usb_descriptor_header *otg_desc[2];
/* string IDs are assigned dynamically */
/* default serial number takes at least two packets */
@@ -341,6 +324,16 @@ static int zero_bind(struct usb_composite_dev *cdev)
/* support OTG systems */
if (gadget_is_otg(cdev->gadget)) {
+ if (!otg_desc[0]) {
+ struct usb_descriptor_header *usb_desc;
+
+ usb_desc = usb_otg_descriptor_alloc(cdev->gadget);
+ if (!usb_desc)
+ return -ENOMEM;
+ usb_otg_descriptor_init(cdev->gadget, usb_desc);
+ otg_desc[0] = usb_desc;
+ otg_desc[1] = NULL;
+ }
There is an error condition in zero_bind(). You need to free the
otg_descriptor there.
sourcesink_driver.descriptors = otg_desc;
sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
loopback_driver.descriptors = otg_desc;
@@ -397,6 +390,9 @@ static int zero_unbind(struct usb_composite_dev *cdev)
if (!IS_ERR_OR_NULL(func_lb))
usb_put_function(func_lb);
usb_put_function_instance(func_inst_lb);
+ kfree(otg_desc[0]);
+ otg_desc[0] = NULL;
+
return 0;
}
cheers,
-roger
--
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 v6 22/23] usb: gadget: serial: allocate and init otg descriptor by otg capabilities
On 29/06/15 10:48, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations. If otg capability
is not defined, keep its original otg descriptor unchanged.
Signed-off-by: Li Jun
---
drivers/usb/gadget/legacy/serial.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/legacy/serial.c
b/drivers/usb/gadget/legacy/serial.c
index 8b7528f..d1cd025 100644
--- a/drivers/usb/gadget/legacy/serial.c
+++ b/drivers/usb/gadget/legacy/serial.c
@@ -79,20 +79,7 @@ static struct usb_device_descriptor device_desc = {
.bNumConfigurations = 1,
};
-static struct usb_otg_descriptor otg_descriptor = {
- .bLength = sizeof otg_descriptor,
- .bDescriptorType = USB_DT_OTG,
-
- /* REVISIT SRP-only hardware is possible, although
-* it would not be called "OTG" ...
-*/
- .bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
- (struct usb_descriptor_header *) &otg_descriptor,
- NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
/*-*/
@@ -191,6 +178,16 @@ static int gs_bind(struct usb_composite_dev *cdev)
serial_config_driver.iConfiguration = status;
if (gadget_is_otg(cdev->gadget)) {
+ if (!otg_desc[0]) {
+ struct usb_descriptor_header *usb_desc;
+
+ usb_desc = usb_otg_descriptor_alloc(cdev->gadget);
+ if (!usb_desc)
+ return -ENOMEM;
+ usb_otg_descriptor_init(cdev->gadget, usb_desc);
+ otg_desc[0] = usb_desc;
+ otg_desc[1] = NULL;
+ }
serial_config_driver.descriptors = otg_desc;
serial_config_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
}
There is a failure condition in gs_bind() and you need to free the
otg_descriptor there.
@@ -227,6 +224,10 @@ static int gs_unbind(struct usb_composite_dev *cdev)
usb_put_function(f_serial[i]);
usb_put_function_instance(fi_serial[i]);
}
+
+ kfree(otg_desc[0]);
+ otg_desc[0] = NULL;
+
return 0;
}
cheers,
-roger
--
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 v6 21/23] usb: gadget: printer: allocate and init otg descriptor by otg capabilities
On 29/06/15 10:48, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations. If otg capability
is not defined, keep its original otg descriptor unchanged.
Signed-off-by: Li Jun
---
drivers/usb/gadget/legacy/printer.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/legacy/printer.c
b/drivers/usb/gadget/legacy/printer.c
index 1ce7df1..2ad1124 100644
--- a/drivers/usb/gadget/legacy/printer.c
+++ b/drivers/usb/gadget/legacy/printer.c
@@ -82,16 +82,7 @@ static struct usb_device_descriptor device_desc = {
.bNumConfigurations = 1
};
-static struct usb_otg_descriptor otg_descriptor = {
- .bLength = sizeof otg_descriptor,
- .bDescriptorType = USB_DT_OTG,
- .bmAttributes = USB_OTG_SRP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
- (struct usb_descriptor_header *) &otg_descriptor,
- NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
/*-*/
@@ -136,7 +127,6 @@ static int printer_do_config(struct usb_configuration *c)
usb_gadget_set_selfpowered(gadget);
if (gadget_is_otg(gadget)) {
- otg_descriptor.bmAttributes |= USB_OTG_HNP;
printer_cfg_driver.descriptors = otg_desc;
printer_cfg_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
}
@@ -182,6 +172,17 @@ static int printer_bind(struct usb_composite_dev *cdev)
device_desc.iProduct = strings[USB_GADGET_PRODUCT_IDX].id;
device_desc.iSerialNumber = strings[USB_GADGET_SERIAL_IDX].id;
+ if (gadget_is_otg(cdev->gadget) && !otg_desc[0]) {
+ struct usb_descriptor_header *usb_desc;
+
+ usb_desc = usb_otg_descriptor_alloc(cdev->gadget);
+ if (!usb_desc)
+ return -ENOMEM;
+ usb_otg_descriptor_init(cdev->gadget, usb_desc);
+ otg_desc[0] = usb_desc;
+ otg_desc[1] = NULL;
+ }
+
ret = usb_add_config(cdev, &printer_cfg_driver, printer_do_config);
if (ret) {
You need to free the otg descriptor here.
usb_put_function_instance(fi_printer);
@@ -196,6 +197,9 @@ static int printer_unbind(struct usb_composite_dev *cdev)
usb_put_function(f_printer);
usb_put_function_instance(fi_printer);
+ kfree(otg_desc[0]);
+ otg_desc[0] = NULL;
+
return 0;
}
cheers,
-roger
--
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 v6 12/23] usb: gadget: ether: allocate and init otg descriptor by otg capabilities
On 29/06/15 10:47, Li Jun wrote:
Allocate and initialize usb otg descriptor according to gadget otg
capabilities, add it for each usb configurations, free it while
ether unbind. If otg capability is not defined, keep its otg
descriptor unchanged.
Signed-off-by: Li Jun
For patches 12 to 20
Reviewed-by: Roger Quadros
cheers,
-roger
---
drivers/usb/gadget/legacy/ether.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/legacy/ether.c
b/drivers/usb/gadget/legacy/ether.c
index a3323dc..31e9160 100644
--- a/drivers/usb/gadget/legacy/ether.c
+++ b/drivers/usb/gadget/legacy/ether.c
@@ -171,20 +171,7 @@ static struct usb_device_descriptor device_desc = {
.bNumConfigurations = 1,
};
-static struct usb_otg_descriptor otg_descriptor = {
- .bLength = sizeof otg_descriptor,
- .bDescriptorType = USB_DT_OTG,
-
- /* REVISIT SRP-only hardware is possible, although
-* it would not be called "OTG" ...
-*/
- .bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
- (struct usb_descriptor_header *) &otg_descriptor,
- NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
static struct usb_string strings_dev[] = {
[USB_GADGET_MANUFACTURER_IDX].s = "",
@@ -416,17 +403,28 @@ static int eth_bind(struct usb_composite_dev *cdev)
device_desc.iManufacturer = strings_dev[USB_GADGET_MANUFACTURER_IDX].id;
device_desc.iProduct = strings_dev[USB_GADGET_PRODUCT_IDX].id;
+ if (gadget_is_otg(gadget) && !otg_desc[0]) {
+ struct usb_descriptor_header *usb_desc;
+
+ usb_desc = usb_otg_descriptor_alloc(gadget);
+ if (!usb_desc)
+ goto fail1;
+ usb_otg_descriptor_init(gadget, usb_desc);
+ otg_desc[0] = usb_desc;
+ otg_desc[1] = NULL;
+ }
+
/* register our configuration(s); RNDIS first, if it's used */
if (has_rndis()) {
status = usb_add_config(cdev, &rndis_config_driver,
rndis_do_config);
if (status < 0)
- goto fail1;
+ goto fail2;
}
status = usb_add_config(cdev, ð_config_driver, eth_do_config);
if (status < 0)
- goto fail1;
+ goto fail2;
usb_composite_overwrite_options(cdev, &coverwrite);
dev_info(&gadget->dev, "%s, version: " DRIVER_VERSION "\n",
@@ -434,6 +432,9 @@ static int eth_bind(struct usb_composite_dev *cdev)
return 0;
+fail2:
+ kfree(otg_desc[0]);
+ otg_desc[0] = NULL;
fail1:
if (has_rndis())
usb_put_function_instance(fi_rndis);
@@ -463,6 +464,9 @@ static int eth_unbind(struct usb_composite_dev *cdev)
usb_put_function(f_geth);
usb_put_function_instance(fi_geth);
}
+ kfree(otg_desc[0]);
+ otg_desc[0] = NULL;
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 4/5] crypto: Add Allwinner Security System crypto accelerator
On Mon, Jul 06, 2015 at 09:10:47PM +0200, LABBE Corentin wrote:
>
> +int sun4i_hash_init(struct ahash_request *areq)
> +{
> + const char *hash_type;
> + struct sun4i_req_ctx *op = ahash_request_ctx(areq);
> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
> + struct ahash_alg *alg = __crypto_ahash_alg(tfm->base.__crt_alg);
> + struct sun4i_ss_alg_template *algt;
> + struct sun4i_ss_ctx *ss;
> +
> + memset(op, 0, sizeof(struct sun4i_req_ctx));
> +
> + algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
> + ss = algt->ss;
> + op->ss = algt->ss;
> +
> + hash_type = crypto_tfm_alg_name(areq->base.tfm);
> +
> + if (strcmp(hash_type, "sha1") == 0)
> + op->mode = SS_OP_SHA1;
> + else if (strcmp(hash_type, "md5") == 0)
> + op->mode = SS_OP_MD5;
Please store these modes in algt and then you wouldn't need to do
the strcmp.
> +int sun4i_hash_import_md5(struct ahash_request *areq, const void *in)
> +{
> + struct sun4i_req_ctx *op = ahash_request_ctx(areq);
> + const struct md5_state *ictx = in;
> + int i;
You need to initialise op->ss here. Ditto for SHA.
> + /* get the partial hash only if something was written */
> + if (op->mode == SS_OP_SHA1) {
> + for (i = 0; i < 5; i++)
> + op->hash[i] = readl(ss->base + SS_MD0 + i * 4);
> + } else {
> + for (i = 0; i < 4; i++)
> + op->hash[i] = readl(ss->base + SS_MD0 + i * 4);
> + }
You can avoid the op->mode check by storing the hash size in algt.
> +int sun4i_hash_finup(struct ahash_request *areq)
> +{
> + int err;
> +
> + err = sun4i_hash_update(areq);
> + if (err != 0)
> + return err;
> +
> + return sun4i_hash_final(areq);
You can drop finup since the API provides a default finup that's
exactly the same as this. You only need to provide finup if it
can optimise on this.
Ditto for digest.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
Hello, On Tue, Jul 07, 2015 at 03:37:49PM +0200, Jan Lübbe wrote: > On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote: > > On 11/26/2014 06:04 PM, Uwe Kleine-König wrote: > > > On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote: > > >> Having a board where the I2C bus locks up occasionally made it clear > > >> that the bus recovery in the i2c-davinci driver will only work on > > >> some boards, because on regular boards, this will only toggle GPIO > > >> lines that aren't muxed to the actual pins. > > >> > > >> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the > > >> built-in capability to bit-bang its lines by using the ICPFUNC registers > > >> of the i2c controller. > > >> Implement the suggested procedure by toggling SCL and checking SDA using > > >> the ICPFUNC registers of the I2C controller when present. Allow platforms > > >> to indicate the presence of the ICPFUNC registers with a has_pfunc > > >> platform > > >> data flag and add optional DT property "ti,has-pfunc" to indicate > > >> the same in DT. > > > On what does it depend if this pfunc stuff works or not? Only the SoC, > > > or also on some board specific properties? > > > > SoC / set of SoCs. Also, similar feature is supported by OMAP and > > AM335x/AM437x SoCs > > using I2C_SYSTEST register. > > > > > Given the former using the > > > compatible string to detect its availability would be better. (In this > > > case also sorry, didn't consider this case when requesting the property > > > in the last round.) > > I only stumbled across this after it was merged, with the additional I also wonder how it came to the Reviewed-by tag for me. The last thing that I said about the patch was "On what does it depend if this pfunc stuff works or not? Only the SoC, or also on some board specific properties?" (see above) and "the patch looks ok". IMHO this hardly justifies to add the Reviewed-by tag for the next round. :-( Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
> I only stumbled across this after it was merged, with the additional > ti,has-pfunc property instead of using the compatible string (which > would be better for a soc-dependent feature). Can we still fix this? Makes sense to me. signature.asc Description: Digital signature
Re: [RESEND 06/10] dt: regulator: pwm-regulator: Re-write bindings
On Mon, Jul 06, 2015 at 09:58:28AM +0100, Lee Jones wrote: > * Add support for continuous-voltage mode > * Put more meat on the bones with regards to voltage-table mode > * Sort out formatting for ease of consumption Please when posting again use a subject line reflecting the style for the subsystem and try to reflow the documentation to fit within 80 columns. signature.asc Description: Digital signature
Re: [PATCH v2 5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote: > On 11/26/2014 06:04 PM, Uwe Kleine-König wrote: > > On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote: > >> Having a board where the I2C bus locks up occasionally made it clear > >> that the bus recovery in the i2c-davinci driver will only work on > >> some boards, because on regular boards, this will only toggle GPIO > >> lines that aren't muxed to the actual pins. > >> > >> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the > >> built-in capability to bit-bang its lines by using the ICPFUNC registers > >> of the i2c controller. > >> Implement the suggested procedure by toggling SCL and checking SDA using > >> the ICPFUNC registers of the I2C controller when present. Allow platforms > >> to indicate the presence of the ICPFUNC registers with a has_pfunc platform > >> data flag and add optional DT property "ti,has-pfunc" to indicate > >> the same in DT. > > On what does it depend if this pfunc stuff works or not? Only the SoC, > > or also on some board specific properties? > > SoC / set of SoCs. Also, similar feature is supported by OMAP and > AM335x/AM437x SoCs > using I2C_SYSTEST register. > > > Given the former using the > > compatible string to detect its availability would be better. (In this > > case also sorry, didn't consider this case when requesting the property > > in the last round.) I only stumbled across this after it was merged, with the additional ti,has-pfunc property instead of using the compatible string (which would be better for a soc-dependent feature). Can we still fix this? Regards, Jan -- 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- | -- 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 v6 08/23] usb: chipidea: set usb otg capabilities
On 29/06/15 10:47, Li Jun wrote:
Init and update otg capabilities by DT, set gadget's otg capabilities
accordingly.
Signed-off-by: Li Jun
---
drivers/usb/chipidea/core.c | 10 ++
drivers/usb/chipidea/udc.c | 7 ++-
include/linux/usb/chipidea.h | 1 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 74fea4f..248f571 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -588,6 +588,16 @@ static int ci_get_platdata(struct device *dev,
of_usb_host_tpl_support(dev->of_node);
}
+ if (platdata->dr_mode == USB_DR_MODE_OTG) {
+ /* We can support HNP and SRP of OTG 2.0 */
+ platdata->ci_otg_caps.otg_rev = 0x0200;
+ platdata->ci_otg_caps.hnp_support = true;
+ platdata->ci_otg_caps.srp_support = true;
+
+ /* Update otg capabilities by DT properties */
+ of_usb_update_otg_caps(dev->of_node, &platdata->ci_otg_caps);
What if this function fails. e.g. DT contains unsupported OTG version?
I think we should error out in that case.
+ }
+
if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
cheers,
-roger
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 764f668..b7cca3e 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1827,6 +1827,7 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
static int udc_start(struct ci_hdrc *ci)
{
struct device *dev = ci->dev;
+ struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
int retval = 0;
spin_lock_init(&ci->lock);
@@ -1834,8 +1835,12 @@ static int udc_start(struct ci_hdrc *ci)
ci->gadget.ops = &usb_gadget_ops;
ci->gadget.speed= USB_SPEED_UNKNOWN;
ci->gadget.max_speed= USB_SPEED_HIGH;
- ci->gadget.is_otg = ci->is_otg ? 1 : 0;
ci->gadget.name = ci->platdata->name;
+ ci->gadget.otg_caps = otg_caps;
+
+ if (otg_caps->hnp_support || otg_caps->srp_support ||
+ otg_caps->adp_support)
+ ci->gadget.is_otg = 1;
INIT_LIST_HEAD(&ci->gadget.ep_list);
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index ab94f78..e10cefc 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -34,6 +34,7 @@ struct ci_hdrc_platform_data {
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
void(*notify_event) (struct ci_hdrc *ci, unsigned event);
struct regulator*reg_vbus;
+ struct usb_otg_caps ci_otg_caps;
booltpl_support;
};
--
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 v6 07/23] usb: common: add API to update usb otg capabilities by device tree
Hi,
On 29/06/15 10:47, Li Jun wrote:
Check property of usb hardware to update otg version and disable SRP, HNP
and ADP if its disable flag is present.
Signed-off-by: Li Jun
---
drivers/usb/common/common.c | 47 +
include/linux/usb/of.h | 7 +++
2 files changed, 54 insertions(+)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index b530fd4..10c986b 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -154,6 +154,53 @@ bool of_usb_host_tpl_support(struct device_node *np)
return false;
}
EXPORT_SYMBOL_GPL(of_usb_host_tpl_support);
+
+/**
+ * of_usb_update_otg_caps - to update usb otg capabilities according to
+ * the passed properties in DT.
+ * @np: Pointer to the given device_node
+ * @otg_caps: Pointer to the target usb_otg_caps to be set
+ *
+ * The function updates the otg capabilities
+ */
+int of_usb_update_otg_caps(struct device_node *np,
+ struct usb_otg_caps *otg_caps)
+{
+ u32 otg_rev;
+
+ if (!otg_caps)
+ return -EINVAL;
+
+ if (!of_property_read_u32(np, "otg-rev", &otg_rev)) {
+ switch (otg_rev) {
+ case 0x0100:
+ case 0x0120:
+ case 0x0130:
+ case 0x0200:
+ case 0x0300:
we don't support 0x300 yet. I guess it is best to leave it out till we
have real otg 3.0 support.
+ otg_caps->otg_rev = otg_rev;
+ break;
+ default:
+ pr_err("%s: unsupported otg-rev: 0x%x\n",
+ np->full_name, otg_rev);
+ return -EINVAL;
+ }
+ } else {
+ otg_caps->otg_rev = 0;
Why do we set this to 0 here?
controller might have set a valid otg_rev and we want to
maintain it if nothing was passed in DT.
+ }
+
+ if (of_find_property(np, "hnp-disable", NULL))
+ otg_caps->hnp_support = false;
+ if (of_find_property(np, "srp-disable", NULL))
+ otg_caps->srp_support = false;
+ if (of_find_property(np, "adp-disable", NULL) ||
+ (otg_caps->otg_rev < 0x0200))
+ otg_caps->adp_support = false;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
+
#endif
cheers,
-roger
MODULE_LICENSE("GPL");
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index cfe0528..8c5a818 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -15,6 +15,8 @@
enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
enum usb_device_speed of_usb_get_maximum_speed(struct device_node *np);
bool of_usb_host_tpl_support(struct device_node *np);
+int of_usb_update_otg_caps(struct device_node *np,
+ struct usb_otg_caps *otg_caps);
#else
static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
{
@@ -30,6 +32,11 @@ static inline bool of_usb_host_tpl_support(struct
device_node *np)
{
return false;
}
+static inline int of_usb_update_otg_caps(struct device_node *np,
+ struct usb_otg_caps *otg_caps)
+{
+ return 0;
+}
#endif
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
--
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] arm64: dts: mt8173: add clock_null
On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> Add clk_null, which represents clocks that can not / need not
> controlled by software.
> There are many clocks' parent set to clk_null.
>
> Signed-off-by: James Liao
> Signed-off-by: Eddie Huang
> ---
> Base on 4.1-rc1
>
> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 924fdb6..4798f44 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -81,6 +81,12 @@
> cpu_on= <0x8403>;
> };
>
> + clk_null: clk_null {
> + compatible = "fixed-clock";
> + clock-frequency = <0>;
> + #clock-cells = <0>;
> + };
The discussion around this patch shows that we don't want to have this
clock in the device tree as it is not a hardware description.
Ok, fine. Eddie, you told us that the rate of the current clk_null children
is not interesting. What's the motivation to send this patch anyway
then? Why can't you keep its children on the orphan list where they are
already now?
Another possibility would be to instantiate the clk_null clock from C
code rather than from the device tree. This way we wouldn't put any
wrong descriptions into the device tree and still can implement the
support for the real parent clocks when we actually need them.
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- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
>
>
> On Tuesday 07 July 2015 04:48 PM, Vaibhav Hiremath wrote:
> >
> >
> >On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote:
> >>On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> >>>On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
> On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> >On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
> >>On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
> >>
> >>>As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
> >>>(page 0) controls the method of clearing interrupt
> >>>status of 88pm800 family of devices;
> >>>
> >>> 0: clear on read
> >>> 1: clear on write
> >>>
> >>>If pdata is not coming from board file, then set the
> >>>default irq clear method to "irq clear on write"
> >>>
> >>>Also, as suggested by "Lee Jones" renaming variable field
> >>>to appropriate name.
> >>>
> >>>Signed-off-by: Zhao Ye
> >>>Signed-off-by: Vaibhav Hiremath
> >>>---
> >>> drivers/mfd/88pm800.c | 15 ++-
> >>> include/linux/mfd/88pm80x.h | 10 --
> >>> 2 files changed, 18 insertions(+), 7 deletions(-)
> >>>
> >>>diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> >>>index d495737..66347be 100644
> >>>--- a/drivers/mfd/88pm800.c
> >>>+++ b/drivers/mfd/88pm800.c
> >>>@@ -374,7 +374,7 @@ static int device_irq_init_800(struct
> >>>pm80x_chip *chip)
> >>> {
> >>> struct regmap *map = chip->regmap;
> >>> unsigned long flags = IRQF_ONESHOT;
> >>>-int data, mask, ret = -EINVAL;
> >>>+int irq_clr_mode, mask, ret = -EINVAL;
> >>>
> >>> if (!map || !chip->irq) {
> >>> dev_err(chip->dev, "incorrect parameters\n");
> >>>@@ -382,15 +382,16 @@ static int device_irq_init_800(struct
> >>>pm80x_chip *chip)
> >>> }
> >>>
> >>> /*
> >>>- * irq_mode defines the way of clearing interrupt. it's
> >>>read-clear by
> >>>- * default.
> >>>+ * irq_clr_on_wr defines the way of clearing interrupt by
> >>>+ * read/write(0/1). It's read-clear by default.
> >>> */
> >>> mask =
> >>> PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
> >>> PM800_WAKEUP2_INT_MASK;
> >>>
> >>>-data = PM800_WAKEUP2_INT_CLEAR;
> >>>-ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
> >>>+irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
> >>>+PM800_WAKEUP2_INT_WRITE_CLEAR :
> >>>PM800_WAKEUP2_INT_READ_CLEAR;
> >>>+ret = regmap_update_bits(map, PM800_WAKEUP2, mask,
> >>>irq_clr_mode);
> >>
> >>What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
> >>PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
> >>directly without all of this faffing about.
> >>
> >> regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
> >>
> >
> >Because "irq_clr_method" is of boolean type.
> >And macros which you are referring to is,
> >
> >#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
> >#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
> >
> >
> >And also, I feel it is more cleaner approach with the current code as
> >register definition and userflag are maintained separately.
>
> I see your point, although it's a shame we have to have this code in
> its place.
>
> One thing I think you can do though is rid chip->irq_clr_method, just
> use the one you already have in pdata.
>
> >>>
> >>>Looking at the current code,
> >>>Yes, this can be done, but I have to do some more changes around it,
> >>>to make code cleaner,
> >>>
> >>>change the signature of
> >>>
> >>>static int device_irq_init_800(struct pm80x_chip *chip)
> >>>
> >>>TO
> >>>
> >>>static int device_irq_init_800(struct pm80x_chip *chip, struct
> >>>pm80x_platform_data *pdata)
> >>>
> >>>
> >>>and then only use pdata->irq_clr_method.
> >>>
> >>>
> >>>How do you want to get this inside? V6 version? or separate patch?
> >>>
> >>>I have one more cleanup patch in the queue, which I am planning to
> >>>submit today, if you are ok then I can submit along with that.
> >>
> >>Ideally not. Don't you save the 'struct device' into *chip? You
> >>should use that to fetch the pdata, like:
> >>
> >>pdata = dev_get_platdata(chip->dev);
> >>
> >
> >Yes certainly, this is another option (rather preferred one).
> >
> >But to be consistent with other's I proposed this, please refer to the
> >fn device_800_init(), where all xxx_init() are taking 2 arguments, and
> >second argument is pdata.
> >
> >
> >There is room for cleanup, I agree.
> >I can put this too in the next cleanup series.
> >
>
> Note that this is init function, called from probe.
>
> So both approach looks ok to me.
Please clean up the other. Functio
Re: [PATCH v2 0/5] Add support for PWMSS on DRA7
On 07/06/2015 09:11 AM, Vignesh R wrote: On Wednesday 03 June 2015 05:21 PM, Vignesh R wrote: Hi, This patch series adds support for PWMSS on DRA7. The IP is same as that present in AM33XX and AM43XX. The first patch changes clock domain in which PWMSS is present (l4per2_7xx_clkdm) to SW_WKUP. This is because legacy IPs like PWM does'nt support HW_AUTO prorperly. Hence, switch clock domain to SW_WKUP. This is based on the input from the hardware team. The rest of the patches add hwmod and dt entries and enable PWMSS on DRA7 based SoCs. Gentle ping... Patches 1-4 look good to me, not going to try to review patch 5 as I have no clue about PWM driver itself. So, for 1-4: Acked-by: Tero Kristo Some of the patches cause trivial merge conflicts with 4.2-rc1 though. -Tero -- 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] power_supply: rt9455_charger: Properly notify userspace about charging events
Charging events this patch refers to are:
- charger is connected to/disconnected from the power source
- battery is reconnected to the charger, after it was absent.
When the charger is connected to/disconnected from the power source, CHRVPI
interrupt occurs and PWR_RDY bit is either set or cleared. PWR_RDY bit is
updated after 1-2 seconds CHRVPI interrupt has occurred.
power_supply_changed() should be called after PWR_RDY bit is updated.
/sys/class/power_supply/rt9455-charger/online file displays the value of
PWR_RDY bit.
This way, if the userspace is notified that a charging event has occurred
and the userspace reads /sys/class/power_supply/rt9455-charger/online file,
this file is properly updated when the userspace reads it.
This is the reason why power_supply_changed() is called in
rt9455_pwr_rdy_work_callback(), instead of being called in interrupt
handler.
Since no interrupt is triggered when the battery is reconnected to the
charger, the userspace is never notified that the battery is reconnected.
This is why power_supply_changed() is called in
rt9455_max_charging_time_work_callback(), so that the userspace is notified
that the battery is reconnected.
Signed-off-by: Anda-Maria Nicolae
---
Updates from v1 version:
- I have followed Kzrysztof's suggestion and I have added explanations in
the commit message so that the change is more clear
- Code is the same as in v1
drivers/power/rt9455_charger.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/power/rt9455_charger.c b/drivers/power/rt9455_charger.c
index 08baac6..a49a9d4 100644
--- a/drivers/power/rt9455_charger.c
+++ b/drivers/power/rt9455_charger.c
@@ -973,7 +973,6 @@ static int rt9455_irq_handler_check_irq2_register(struct
rt9455_info *info,
if (irq2 & GET_MASK(F_CHRVPI)) {
dev_dbg(dev, "Charger fault occurred\n");
- alert_userspace = true;
/*
* CHRVPI bit is set in 2 cases:
* 1. when the power source is connected to the charger.
@@ -981,6 +980,9 @@ static int rt9455_irq_handler_check_irq2_register(struct
rt9455_info *info,
* To identify the case, PWR_RDY bit is checked. Because
* PWR_RDY bit is set / cleared after CHRVPI interrupt is
* triggered, it is used delayed_work to later read PWR_RDY bit.
+* Also, do not set to true alert_userspace, because there is no
+* need to notify userspace when CHRVPI interrupt has occurred.
+* Userspace will be notified after PWR_RDY bit is read.
*/
queue_delayed_work(system_power_efficient_wq,
&info->pwr_rdy_work,
@@ -1178,7 +1180,7 @@ static irqreturn_t rt9455_irq_handler_thread(int irq,
void *data)
/*
* Sometimes, an interrupt occurs while rt9455_probe() function
* is executing and power_supply_register() is not yet called.
-* Do not call power_supply_charged() in this case.
+* Do not call power_supply_changed() in this case.
*/
if (info->charger)
power_supply_changed(info->charger);
@@ -1478,6 +1480,11 @@ static void rt9455_pwr_rdy_work_callback(struct
work_struct *work)
RT9455_MAX_CHARGING_TIME * HZ);
break;
}
+ /*
+* Notify userspace that the charger has been either connected to or
+* disconnected from the power source.
+*/
+ power_supply_changed(info->charger);
}
static void rt9455_max_charging_time_work_callback(struct work_struct *work)
@@ -1533,6 +1540,11 @@ static void rt9455_batt_presence_work_callback(struct
work_struct *work)
if (ret)
dev_err(dev, "Failed to unmask BATAB
interrupt\n");
}
+ /*
+* Notify userspace that the battery is now connected to the
+* charger.
+*/
+ power_supply_changed(info->charger);
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] ARM: shmobile: koelsch: make USB0 perform Host/Function switching
Both USB Host (pci0) and Function (USBHS) drivers are enabled.
The USB PHY driver determines which IP block should be connected
based on vbus and id signals read via gpios.
Note that switch SW5 and SW6 on Koelsch board needs to be set to
position 3 for this to work.
Signed-off-by: Phil Edworthy
---
Not for upstream until the following patches have been accepted:
"usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS"
"phy: rcar-gen2 usb: Add Host/Function switching for USB0"
Hence, not signed off.
v4:
- Changed prefix in title.
v3:
- Remove "pinctrl-names" as well as "pinctrl-0" props.
v2:
- Added -gpio to dts prop names of GPIO pins.
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index cffe33f..21c2fdc 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -615,8 +615,6 @@
&pci0 {
status = "okay";
- pinctrl-0 = <&usb0_pins>;
- pinctrl-names = "default";
};
&pci1 {
@@ -627,13 +625,14 @@
&hsusb {
status = "okay";
- pinctrl-0 = <&usb0_pins>;
- pinctrl-names = "default";
- renesas,enable-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
};
&usbphy {
status = "okay";
+ renesas,pwr-gpio = <&gpio2 4 GPIO_ACTIVE_HIGH>;
+ renesas,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ renesas,vbus-gpio = <&gpio7 24 GPIO_ACTIVE_HIGH>;
+ renesas,vbus-pwr-gpio = <&gpio7 23 GPIO_ACTIVE_HIGH>;
};
&pcie_bus_clk {
--
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 v2 05/11] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding
FAO Mark and DT chaps,
> From: Bjorn Andersson
>
> Add binding documentation for the Qualcomm Resource Power Manager (RPM)
> using shared memory (Qualcomm SMD) as transport mechanism. This is found
> in 8974 and newer based devices.
>
> The binding currently describes the rpm itself and the regulator
> subnodes.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../devicetree/bindings/mfd/qcom-rpm-smd.txt | 117
> +
> include/dt-bindings/mfd/qcom-smd-rpm.h | 28 +
> 2 files changed, 145 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> create mode 100644 include/dt-bindings/mfd/qcom-smd-rpm.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> new file mode 100644
> index 000..e27f5c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> @@ -0,0 +1,117 @@
> +Qualcomm Resource Power Manager (RPM) over SMD
> +
> +This driver is used to interface with the Resource Power Manager (RPM) found
> in
> +various Qualcomm platforms. The RPM allows each component in the system to
> vote
> +for state of the system resources, such as clocks, regulators and bus
> +frequencies.
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,rpm-msm8974"
> +
> +- qcom,smd-channels:
> + Usage: required
> + Value type:
> + Definition: Shared Memory channel used for communication with the RPM
This is going to require a DT Ack.
Also, I don't see it being used anywhere.
> += SUBDEVICES
> +
> +The RPM exposes resources to its subnodes. The below bindings specify the set
> +of valid subnodes that can operate on these resources.
> +
> +== Regulators
> +
> +Regulator nodes are identified by their compatible:
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,rpm-pm8841-regulators"
> + "qcom,rpm-pm8941-regulators"
> +
> +- vdd_s1-supply:
> +- vdd_s2-supply:
> +- vdd_s3-supply:
> +- vdd_s4-supply:
> +- vdd_s5-supply:
> +- vdd_s6-supply:
> +- vdd_s7-supply:
> +- vdd_s8-supply:
> + Usage: optional (pm8841 only)
> + Value type:
> + Definition: reference to regulator supplying the input pin, as
> + described in the data sheet
> +
> +- vdd_s1-supply:
> +- vdd_s2-supply:
> +- vdd_s3-supply:
> +- vdd_l1_l3-supply:
> +- vdd_l2_lvs1_2_3-supply:
> +- vdd_l4_l11-supply:
> +- vdd_l5_l7-supply:
> +- vdd_l6_l12_l14_l15-supply:
> +- vdd_l8_l16_l18_l19-supply:
> +- vdd_l9_l10_l17_l22-supply:
> +- vdd_l13_l20_l23_l24-supply:
> +- vdd_l21-supply:
> +- vin_5vs-supply:
> + Usage: optional (pm8941 only)
> + Value type:
> + Definition: reference to regulator supplying the input pin, as
> + described in the data sheet
> +
> +The regulator node houses sub-nodes for each regulator within the device.
> Each
> +sub-node is identified using the node's name, with valid values listed for
> each
> +of the pmics below.
> +
> +pm8841:
> + s1, s2, s3, s4, s5, s6, s7, s8
> +
> +pm8941:
> + s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
> + l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
> + lvs3, 5vs1, 5vs2
> +
> +The content of each sub-node is defined by the standard binding for
> regulators -
> +see regulator.txt.
s-regulator.txt-../regulator/regulator.txt-
> +
> += EXAMPLE
> +
> + smd {
> + compatible = "qcom,smd";
Is an SMD (Shared Memory Device?) real hardware?
> + rpm {
> + interrupts = <0 168 1>;
> + qcom,ipc = <&apcs 8 0>;
> + qcom,smd-edge = <15>;
The child node won't probe without a compatible string. Shouldn't
"qcom,rpm-msm8974" be in here instead?
> + rpm_requests {
This node appears to be undocumented.
Does it represent real h/w?
> + compatible = "qcom,rpm-msm8974";
> + qcom,smd-channels = "rpm_requests";
> +
> + pm8941-regulators {
> + compatible =
> "qcom,rpm-pm8941-regulators";
> + vdd_l13_l20_l23_l24-supply =
> <&pm8941_boost>;
I'd like Mark to glance at this.
> + pm8941_s3: s3 {
> + regulator-min-microvolt =
> <180>;
> + regulator-max-microvolt =
> <180>;
Aren't these fixed regulators?
> + };
> +
> + pm8941_boost: s4 {
> + regulator-min-microvolt =
> <500>;
> + regulator-max-microvolt =
> <50
RE: [PATCH V5 1/2] mfd: da9062: DA9062 MFD core driver
On 07 July 2015 12:42, Lee Jones wrote: > To: Opensource [Steve Twiss] > Subject: Re: [PATCH V5 1/2] mfd: da9062: DA9062 MFD core driver > > > From: S Twiss > > > > Add MFD core driver support for DA9062 > > > > Signed-off-by: Steve Twiss > > [...] > > > Applied, thanks. Hi Lee, Thank you for your efforts on this. Regards, Steve [...]
[PATCH v3] phy: rcar-gen2 usb: Add Host/Function switching for USB0
Instead of statically selecting the PHY connection to either the
USBHS (Function) or PCI0 (Host) IP blocks, this change allows the
dts to specifiy gpio pins for the vbus and id signals. Additional
gpio pins are used to control power to an external OTG device and
an override to turn vbus on/off.
Note: the R-Car USB PHY only allows this Host/Function switching
on channel 0.
This has been tested on a r8a7791 based Koelsch board, which uses
a MAX3355 device to supply vbus power when needed.
Signed-off-by: Phil Edworthy
---
v3:
- Do not call usb_gadget_vbus_disconnect will a NULL ptr.
- Formatting to avoid a line length of over 80 chars.
v2:
- Added -gpio to dts prop names of GPIO pins.
- Document the new bindings.
---
.../devicetree/bindings/phy/rcar-gen2-phy.txt | 10 +
drivers/phy/phy-rcar-gen2.c| 269 +++--
2 files changed, 257 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
index 00fc52a..3a501fe 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
@@ -30,6 +30,16 @@ the USB channel; see the selector meanings below:
| 2 | PCI EHCI/OHCI | xHCI |
+---+---+---+
+Optional properties:
+ - renesas,pwr-gpio: A gpio specifier that will be active when the
+ PHY is powered on.
+ - renesas,id-gpio: A gpio specifier that is read to get the USB
+ ID signal.
+ - renesas,vbus-gpio: A gpio specifier that is read to get the USB
+ VBUS signal.
+ - renesas,vbus-pwr-gpio: A gpio specifier that will be active when VBUS
+ is required to be powered.
+
Example (Lager board):
usb-phy@e6590100 {
diff --git a/drivers/phy/phy-rcar-gen2.c b/drivers/phy/phy-rcar-gen2.c
index 97d45f4..1286892 100644
--- a/drivers/phy/phy-rcar-gen2.c
+++ b/drivers/phy/phy-rcar-gen2.c
@@ -1,5 +1,5 @@
/*
- * Renesas R-Car Gen2 PHY driver
+ * Renesas R-Car Gen2 USB PHY driver
*
* Copyright (C) 2014 Renesas Solutions Corp.
* Copyright (C) 2014 Cogent Embedded, Inc.
@@ -12,11 +12,16 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
+#include
+#include
+#include
#include
@@ -58,6 +63,18 @@ struct rcar_gen2_channel {
struct rcar_gen2_phy phys[PHYS_PER_CHANNEL];
int selected_phy;
u32 select_mask;
+
+ /* external power enable pin */
+ int gpio_pwr;
+
+ /* Host/Function switching */
+ struct delayed_work work;
+ int use_otg;
+ int gpio_vbus;
+ int gpio_id;
+ int gpio_vbus_pwr;
+ struct usb_phy *usbphy;
+ struct usb_otg *otg;
};
struct rcar_gen2_phy_driver {
@@ -68,31 +85,50 @@ struct rcar_gen2_phy_driver {
struct rcar_gen2_channel *channels;
};
-static int rcar_gen2_phy_init(struct phy *p)
+static void rcar_gen2_phy_switch(struct rcar_gen2_channel *channel,
+ u32 select_value)
{
- struct rcar_gen2_phy *phy = phy_get_drvdata(p);
- struct rcar_gen2_channel *channel = phy->channel;
struct rcar_gen2_phy_driver *drv = channel->drv;
unsigned long flags;
u32 ugctrl2;
- /*
-* Try to acquire exclusive access to PHY. The first driver calling
-* phy_init() on a given channel wins, and all attempts to use another
-* PHY on this channel will fail until phy_exit() is called by the first
-* driver. Achieving this with cmpxcgh() should be SMP-safe.
-*/
- if (cmpxchg(&channel->selected_phy, -1, phy->number) != -1)
- return -EBUSY;
-
- clk_prepare_enable(drv->clk);
-
spin_lock_irqsave(&drv->lock, flags);
ugctrl2 = readl(drv->base + USBHS_UGCTRL2);
ugctrl2 &= ~channel->select_mask;
- ugctrl2 |= phy->select_value;
+ ugctrl2 |= select_value;
writel(ugctrl2, drv->base + USBHS_UGCTRL2);
spin_unlock_irqrestore(&drv->lock, flags);
+}
+
+static int rcar_gen2_phy_init(struct phy *p)
+{
+ struct rcar_gen2_phy *phy = phy_get_drvdata(p);
+ struct rcar_gen2_channel *channel = phy->channel;
+ struct rcar_gen2_phy_driver *drv = channel->drv;
+
+ if (!channel->use_otg) {
+ /*
+* Static Host/Function role.
+* Try to acquire exclusive access to PHY. The first driver
+* calling phy_init() on a given channel wins, and all attempts
+* to use another PHY on this channel will fail until
+* phy_exit() is called by the first driver. Achieving this
+
Re: [PATCH V5 2/2] devicetree: da9062: Add bindings for DA9062 driver
On Wed, 01 Jul 2015, S Twiss wrote:
> From: S Twiss
>
> Add device tree bindings for the DA9062 driver
>
> Signed-off-by: Steve Twiss
>
> ---
> Changes in V5:
> - No change
>
> Changes in V4:
> - No change
>
> Changes in V3:
> - No change
>
> Changes in V2:
> - Dropped the RTC and Onkey binding information in this patch-set
>Those drivers have been dropped from this patch set and the
>binding information has been removed accordingly.
>
> This patch applies against linux-next and next-20150701
>
>
>
> Documentation/devicetree/bindings/mfd/da9062.txt | 79
>
> 1 file changed, 79 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/da9062.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> new file mode 100644
> index 000..5765ed9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -0,0 +1,79 @@
> +* Dialog DA9062 Power Management Integrated Circuit (PMIC)
> +
> +DA9062 consists of a large and varied group of sub-devices:
> +
> +Device Supply NamesDescription
> +-- ---
> +da9062-regulator: : LDOs & BUCKs
> +da9062-watchdog : : Watchdog Timer
> +
> +==
> +
> +Required properties:
> +
> +- compatible : Should be "dlg,da9062".
> +- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
> + modified to match the chip's OTP settings).
> +- interrupt-parent : Specifies the reference to the interrupt controller for
> + the DA9062.
> +- interrupts : IRQ line information.
> +- interrupt-controller
> +
> +See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
> +further information on IRQ bindings.
> +
> +Sub-nodes:
> +
> +- regulators : This node defines the settings for the LDOs and BUCKs. The
> + DA9062 regulators are bound using their names listed below:
> +
> +buck1: BUCK_1
> +buck2: BUCK_2
> +buck3: BUCK_3
> +buck4: BUCK_4
> +ldo1 : LDO_1
> +ldo2 : LDO_2
> +ldo3 : LDO_3
> +ldo4 : LDO_4
> +
> + The component follows the standard regulator framework and the bindings
> + details of individual regulator device can be found in:
> + Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +
> +- watchdog: This node defines the settings for the watchdog driver associated
> + with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be
> added
> + if a node is created.
> +
> +
> +Example:
> +
> + pmic0: da9062@58 {
> + compatible = "dlg,da9062";
> + reg = <0x58>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> +
> + watchdog {
> + compatible = "dlg,da9062-watchdog";
> + };
> +
> + regulators {
> + DA9062_BUCK1: buck1 {
> + regulator-name = "BUCK1";
> + regulator-min-microvolt = <30>;
> + regulator-max-microvolt = <157>;
> + regulator-min-microamp = <50>;
> + regulator-max-microamp = <200>;
> + regulator-boot-on;
> + };
> + DA9062_LDO1: ldo1 {
> + regulator-name = "LDO_1";
> + regulator-min-microvolt = <90>;
> + regulator-max-microvolt = <360>;
> + regulator-boot-on;
> + };
> + };
> + };
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 1/2] mfd: da9062: DA9062 MFD core driver
On Wed, 01 Jul 2015, S Twiss wrote: > From: S Twiss > > Add MFD core driver support for DA9062 > > Signed-off-by: Steve Twiss > > --- > Changes in V5: > - Alter register.h file with the following: >bit macro change defines of the form (0x01> Changes in V4: > - Removal of struct da9062 unrequired data from core.h and driver code > - Remove IRQ handler for VDD_WARN and corresponding IRQ request code > - Use DEFINE_RES_NAMED() macro for resource definitions > - Refactor da9062_clear_fault_log() to remove inconsistencies > - Refactor da9062_device_init() and da9062_irq_init() into probe() > - Add new function get_device_type() for variant and device_id information > - devm_kzalloc to alloc *chip instead of struct and use not-chip on error > - Move da9062_dt_ids closer to usage > - Move LUT definitions into da9062_regmap_config structure > - Erase da9062_device_exit() abstractions > - Clean up header inclusions through removal of redundant entries > - Whitespace and string literal discipline > > Changes in V3: > - Removed references to the RTC and OnKey in the mfd_cell definition. > > Changes in V2: > - Copyright headers GPL v2 (and later) match correct 'GPL' in MODULE_LICENSE > - Ensure DA9062 core is tristate in Kconfig so it can be built as a module > - Move VDD_WARN code and resource into the core instead of regulator driver > > This patch applies against linux-next and next-20150701 > > > > drivers/mfd/Kconfig | 12 + > drivers/mfd/Makefile |3 +- > drivers/mfd/da9062-core.c| 512 > include/linux/mfd/da9062/core.h | 50 ++ > include/linux/mfd/da9062/registers.h | 1108 > ++ > 5 files changed, 1684 insertions(+), 1 deletion(-) > create mode 100644 drivers/mfd/da9062-core.c > create mode 100644 include/linux/mfd/da9062/core.h > create mode 100644 include/linux/mfd/da9062/registers.h Applied, thanks. > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 6538159..1109d09 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -186,6 +186,18 @@ config MFD_DA9055 > This driver can be built as a module. If built as a module it will be > called "da9055" > > +config MFD_DA9062 > + tristate "Dialog Semiconductor DA9062 PMIC Support" > + select MFD_CORE > + select REGMAP_I2C > + select REGMAP_IRQ > + depends on I2C=y > + help > + Say yes here for support for the Dialog Semiconductor DA9062 PMIC. > + This includes the I2C driver and core APIs. > + Additional drivers must be enabled in order to use the functionality > + of the device. > + > config MFD_DA9063 > bool "Dialog Semiconductor DA9063 PMIC Support" > select MFD_CORE > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index ea40e07..fd4d8b4 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -110,10 +110,11 @@ obj-$(CONFIG_MFD_LP8788)+= lp8788.o lp8788-irq.o > > da9055-objs := da9055-core.o da9055-i2c.o > obj-$(CONFIG_MFD_DA9055) += da9055.o > - > +obj-$(CONFIG_MFD_DA9062) += da9062-core.o > da9063-objs := da9063-core.o da9063-irq.o da9063-i2c.o > obj-$(CONFIG_MFD_DA9063) += da9063.o > obj-$(CONFIG_MFD_DA9150) += da9150-core.o > + > obj-$(CONFIG_MFD_MAX14577) += max14577.o > obj-$(CONFIG_MFD_MAX77686) += max77686.o > obj-$(CONFIG_MFD_MAX77693) += max77693.o > diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c > new file mode 100644 > index 000..4cf0643 > --- /dev/null > +++ b/drivers/mfd/da9062-core.c > @@ -0,0 +1,512 @@ > +/* > + * Core, IRQ and I2C device driver for DA9062 PMIC > + * Copyright (C) 2015 Dialog Semiconductor Ltd. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DA9062_REG_EVENT_A_OFFSET 0 > +#define DA9062_REG_EVENT_B_OFFSET 1 > +#define DA9062_REG_EVENT_C_OFFSET 2 > + > +static struct regmap_irq da9062_irqs[] = { > + /* EVENT A */ > + [DA9062_IRQ_ONKEY] = { > + .reg_offset = DA9062_REG_EVENT_A_OFFSET, > + .mask = DA9062AA_M_NONKEY_MASK, > + }, > + [DA9062_IRQ_ALARM] = { > + .reg_o
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 04:48 PM, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct
pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
-int data, mask, ret = -EINVAL;
+int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct
pm80x_chip *chip)
}
/*
- * irq_mode defines the way of clearing interrupt. it's
read-clear by
- * default.
+ * irq_clr_on_wr defines the way of clearing interrupt by
+ * read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
-data = PM800_WAKEUP2_INT_CLEAR;
-ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+PM800_WAKEUP2_INT_WRITE_CLEAR :
PM800_WAKEUP2_INT_READ_CLEAR;
+ret = regmap_update_bits(map, PM800_WAKEUP2, mask,
irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
Looking at the current code,
Yes, this can be done, but I have to do some more changes around it,
to make code cleaner,
change the signature of
static int device_irq_init_800(struct pm80x_chip *chip)
TO
static int device_irq_init_800(struct pm80x_chip *chip, struct
pm80x_platform_data *pdata)
and then only use pdata->irq_clr_method.
How do you want to get this inside? V6 version? or separate patch?
I have one more cleanup patch in the queue, which I am planning to
submit today, if you are ok then I can submit along with that.
Ideally not. Don't you save the 'struct device' into *chip? You
should use that to fetch the pdata, like:
pdata = dev_get_platdata(chip->dev);
Yes certainly, this is another option (rather preferred one).
But to be consistent with other's I proposed this, please refer to the
fn device_800_init(), where all xxx_init() are taking 2 arguments, and
second argument is pdata.
There is room for cleanup, I agree.
I can put this too in the next cleanup series.
Note that this is init function, called from probe.
So both approach looks ok to me.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
- int data, mask, ret = -EINVAL;
+ int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip *chip)
}
/*
-* irq_mode defines the way of clearing interrupt. it's read-clear by
-* default.
+* irq_clr_on_wr defines the way of clearing interrupt by
+* read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
- data = PM800_WAKEUP2_INT_CLEAR;
- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
Looking at the current code,
Yes, this can be done, but I have to do some more changes around it,
to make code cleaner,
change the signature of
static int device_irq_init_800(struct pm80x_chip *chip)
TO
static int device_irq_init_800(struct pm80x_chip *chip, struct
pm80x_platform_data *pdata)
and then only use pdata->irq_clr_method.
How do you want to get this inside? V6 version? or separate patch?
I have one more cleanup patch in the queue, which I am planning to
submit today, if you are ok then I can submit along with that.
Ideally not. Don't you save the 'struct device' into *chip? You
should use that to fetch the pdata, like:
pdata = dev_get_platdata(chip->dev);
Yes certainly, this is another option (rather preferred one).
But to be consistent with other's I proposed this, please refer to the
fn device_800_init(), where all xxx_init() are taking 2 arguments, and
second argument is pdata.
There is room for cleanup, I agree.
I can put this too in the next cleanup series.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
> >On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> >>On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
> >>>On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
> >>>
> As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
> (page 0) controls the method of clearing interrupt
> status of 88pm800 family of devices;
>
> 0: clear on read
> 1: clear on write
>
> If pdata is not coming from board file, then set the
> default irq clear method to "irq clear on write"
>
> Also, as suggested by "Lee Jones" renaming variable field
> to appropriate name.
>
> Signed-off-by: Zhao Ye
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/mfd/88pm800.c | 15 ++-
> include/linux/mfd/88pm80x.h | 10 --
> 2 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> index d495737..66347be 100644
> --- a/drivers/mfd/88pm800.c
> +++ b/drivers/mfd/88pm800.c
> @@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip
> *chip)
> {
> struct regmap *map = chip->regmap;
> unsigned long flags = IRQF_ONESHOT;
> - int data, mask, ret = -EINVAL;
> + int irq_clr_mode, mask, ret = -EINVAL;
>
> if (!map || !chip->irq) {
> dev_err(chip->dev, "incorrect parameters\n");
> @@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip
> *chip)
> }
>
> /*
> - * irq_mode defines the way of clearing interrupt. it's read-clear by
> - * default.
> + * irq_clr_on_wr defines the way of clearing interrupt by
> + * read/write(0/1). It's read-clear by default.
> */
> mask =
> PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
> PM800_WAKEUP2_INT_MASK;
>
> - data = PM800_WAKEUP2_INT_CLEAR;
> - ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
> + irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
> + PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
> + ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
> >>>
> >>>What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
> >>>PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
> >>>directly without all of this faffing about.
> >>>
> >>> regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
> >>>
> >>
> >>Because "irq_clr_method" is of boolean type.
> >>And macros which you are referring to is,
> >>
> >>#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
> >>#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
> >>
> >>
> >>And also, I feel it is more cleaner approach with the current code as
> >>register definition and userflag are maintained separately.
> >
> >I see your point, although it's a shame we have to have this code in
> >its place.
> >
> >One thing I think you can do though is rid chip->irq_clr_method, just
> >use the one you already have in pdata.
> >
>
> Looking at the current code,
> Yes, this can be done, but I have to do some more changes around it,
> to make code cleaner,
>
> change the signature of
>
> static int device_irq_init_800(struct pm80x_chip *chip)
>
> TO
>
> static int device_irq_init_800(struct pm80x_chip *chip, struct
> pm80x_platform_data *pdata)
>
>
> and then only use pdata->irq_clr_method.
>
>
> How do you want to get this inside? V6 version? or separate patch?
>
> I have one more cleanup patch in the queue, which I am planning to
> submit today, if you are ok then I can submit along with that.
Ideally not. Don't you save the 'struct device' into *chip? You
should use that to fetch the pdata, like:
pdata = dev_get_platdata(chip->dev);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
- int data, mask, ret = -EINVAL;
+ int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip *chip)
}
/*
-* irq_mode defines the way of clearing interrupt. it's read-clear by
-* default.
+* irq_clr_on_wr defines the way of clearing interrupt by
+* read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
- data = PM800_WAKEUP2_INT_CLEAR;
- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
Looking at the current code,
Yes, this can be done, but I have to do some more changes around it,
to make code cleaner,
change the signature of
static int device_irq_init_800(struct pm80x_chip *chip)
TO
static int device_irq_init_800(struct pm80x_chip *chip, struct
pm80x_platform_data *pdata)
and then only use pdata->irq_clr_method.
How do you want to get this inside? V6 version? or separate patch?
I have one more cleanup patch in the queue, which I am planning to
submit today, if you are ok then I can submit along with that.
Thanks,
Vaibhav
--
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] clk: mediatek: Add MT8173 MMPLL change rate support
Am Dienstag, 7. Juli 2015, 17:48:45 schrieb James Liao:
> Hi Heiko,
>
> On Tue, 2015-07-07 at 11:34 +0200, Heiko Stübner wrote:
> > > > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct
> > > > > mtk_clk_pll
> > > > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > > >
> > > > > {
> > > > >
> > > > > unsigned long fmin = 1000 * MHZ;
> > > > >
> > > > > + const unsigned long *div_rate = pll->data->div_rate;
> > > > >
> > > > > u64 _pcw;
> > > > > u32 val;
> > > > >
> > > > > if (freq > pll->data->fmax)
> > > > >
> > > > > freq = pll->data->fmax;
> > > > >
> > > > > - for (val = 0; val < 4; val++) {
> > > > > + if (div_rate) {
> > > > > + for (val = 1; div_rate[val] != 0; val++) {
> > > > > + if (freq > div_rate[val])
> > > > > + break;
> > > > > + }
> > > > > + val--;
> > > >
> > > > if you're changing the table struct, this of course also would need to
> > > > be
> > > > adapted.
> > > >
> > > >
> > > > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the
> > > > table,
> > > > if
> > > > you ignore it here all the time?
> > > >
> > > > So the table should probably look more like [when using the concept
> > > > from
> > > > above]
> > > >
> > > > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > > >
> > > > { .freq = 10, .div = 0 },
> > > > { .freq = 70200, .div = 1 },
> > > > { .freq = 25350, .div = 2 },
> > > > { .freq = 12675, .div = 3 },
> > > > { /* sentinel */ },
> > > >
> > > > };
> > >
> > > The freq-div table describes the maximum frequency of each divider
> > > setting. Although the first element doesn't used in current
> > > implementation, I think it's better to keep freq-div table's
> > > completeness.
> >
> > the issue I see is, that its value is currently 0 and the code substracts
> > 1. So if anything would (accidentially) select MT8173_PLL_FMAX, the u32
> > val would wrap around, as you're subtracting 1 from 0 .
>
> Subtracting 1 from val is safe now because it starts from 1:
>
> for (val = 1; div_rate[val] != 0; val++) {
> ...
> }
> val--;
>
> I can change this implementation to a more readable one such as:
>
> for (val = 0; div_rate[val + 1] != 0; val++) {
> if (freq <= div_rate[val] && freq > div_rate[val + 1]) {
> ...
>
> Do you think it is OK?
My issue is, that you have the MT8173_PLL_FMAX entry in the table, which is
effectively unused, as it is ignored by the for loop. They why have it all, if
nothing cares about it.
So if in the future somebody notices, "oh this is ignoring the first entry"
without look further what the code does, this explodes ;-)
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH v3 3/4] mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
On Tue, 07 Jul 2015, Hans de Goede wrote: > On 07-07-15 09:01, Lee Jones wrote: > >On Fri, 26 Jun 2015, Hans de Goede wrote: > > > >>Add a cell for the usb power_supply part of the axp20x PMICs. > >> > >>Note that this cell is only for the usb power_supply part and not the > >>ac-power / battery-charger / rtc-backup-bat-charger bits. > >> > >>Depending on the board each of those must be enabled / disabled separately > >>in devicetree as most boards do not use all 4. So in dt each one needs its > >>own child-node of the axp20x node. Another reason for using separate child > >>nodes for each is so that other devicetree nodes can have a power-supply > >>property with a phandle referencing a node representing a single > >>power-supply. > >> > >>The decision to use a separate devicetree node for each is reflected on > >>the kernel side by each getting its own mfd-cell / platform_device and > >>platform-driver. > >> > >>Note this commit also makes some whitespace changes to the intialization > >>of existing cells in axp20x_cells, these are pure whitespace changes, > >>functionally nothing changes. > >> > >>Cc: Bruno Prémont > >>Acked-by: Lee Jones > >>Signed-off-by: Bruno Prémont > >>Signed-off-by: Hans de Goede > >>--- > >>Changes in v2: > >>-Use DEFINE_RES_IRQ_NAMED > >>-Change indentation of axp20x_cells initializers to avoid line wrapping > >>Changes in v3: > >>-Improve commit message > >>-Add Bruno's S-o-b > >>--- > >> drivers/mfd/axp20x.c | 20 > >> 1 file changed, 16 insertions(+), 4 deletions(-) > > > >For my own reference: > > Acked-by: Lee Jones > > > >Are these two patches tied to any other in the set, or can I apply > >them separately? > > You can apply them seperately, thanks. > > I'm wondering who will take care of upstreaming the first patch of this > set: "ARM: dts: Add binding documentation for AXP20x pmic usb power supply" > > If you can take that one too that would be great. I can do, but I need an Ack from these guys: POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS M: Sebastian Reichel M: Dmitry Eremin-Solenikov M: David Woodhouse L: linux...@vger.kernel.org T: git git://git.infradead.org/battery-2.6.git S: Maintained F: include/linux/power_supply.h F: drivers/power/ ... failing that, they should take it. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rx51-battery.ko incompatiblity: board code vs DT
On Mon 2015-07-06 21:44:22, Pali Rohár wrote: > Hello, > > now I found out that rx51-battery.ko driver register sysnode > /sys/class/power_supply/rx51-battery/ when booting with legacy board > code. But when booting DT kernel it register sysnode with different name > /sys/class/power_supply/n900-battery/ > > Sysfs node for DT kernel comes from Nokia N900 DTS file: > arch/arm/boot/dts/omap3-n900.dts > > I would propose change which change DTS to "rx51-battery" to have it > compatible with naming which is for legacy board code. It is just > because to have compatibility and same naming scheme and also to make > existing programs to work without needing patching them. > > What do you think? Makes sense.. along with _big_ comment in the dts why we are doing this. 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-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
> >On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
> >
> >>As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
> >>(page 0) controls the method of clearing interrupt
> >>status of 88pm800 family of devices;
> >>
> >> 0: clear on read
> >> 1: clear on write
> >>
> >>If pdata is not coming from board file, then set the
> >>default irq clear method to "irq clear on write"
> >>
> >>Also, as suggested by "Lee Jones" renaming variable field
> >>to appropriate name.
> >>
> >>Signed-off-by: Zhao Ye
> >>Signed-off-by: Vaibhav Hiremath
> >>---
> >> drivers/mfd/88pm800.c | 15 ++-
> >> include/linux/mfd/88pm80x.h | 10 --
> >> 2 files changed, 18 insertions(+), 7 deletions(-)
> >>
> >>diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> >>index d495737..66347be 100644
> >>--- a/drivers/mfd/88pm800.c
> >>+++ b/drivers/mfd/88pm800.c
> >>@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
> >> {
> >>struct regmap *map = chip->regmap;
> >>unsigned long flags = IRQF_ONESHOT;
> >>- int data, mask, ret = -EINVAL;
> >>+ int irq_clr_mode, mask, ret = -EINVAL;
> >>
> >>if (!map || !chip->irq) {
> >>dev_err(chip->dev, "incorrect parameters\n");
> >>@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip
> >>*chip)
> >>}
> >>
> >>/*
> >>-* irq_mode defines the way of clearing interrupt. it's read-clear by
> >>-* default.
> >>+* irq_clr_on_wr defines the way of clearing interrupt by
> >>+* read/write(0/1). It's read-clear by default.
> >> */
> >>mask =
> >>PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
> >>PM800_WAKEUP2_INT_MASK;
> >>
> >>- data = PM800_WAKEUP2_INT_CLEAR;
> >>- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
> >>+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
> >>+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
> >>+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
> >
> >What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
> >PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
> >directly without all of this faffing about.
> >
> > regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
> >
>
> Because "irq_clr_method" is of boolean type.
> And macros which you are referring to is,
>
> #define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
> #define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
>
>
> And also, I feel it is more cleaner approach with the current code as
> register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
> >>if (ret < 0)
> >>goto out;
> >>@@ -512,6 +513,7 @@ static int device_800_init(struct pm80x_chip *chip,
> >>}
> >>
> >>chip->regmap_irq_chip = &pm800_irq_chip;
> >>+ chip->irq_clr_method = pdata->irq_clr_method;
> >>
> >>ret = device_irq_init_800(chip);
> >>if (ret < 0) {
> >>@@ -564,6 +566,9 @@ static int pm800_probe(struct i2c_client *client,
> >>pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> >>if (!pdata)
> >>return -ENOMEM;
> >>+
> >>+ /* by default, set irq clear method on write */
> >>+ pdata->irq_clr_method = PM800_IRQ_CLR_ON_WRITE;
> >>}
> >>
> >>ret = pm80x_init(client);
> >>diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
> >>index 8fcad63..648e01a 100644
> >>--- a/include/linux/mfd/88pm80x.h
> >>+++ b/include/linux/mfd/88pm80x.h
> >>@@ -77,6 +77,8 @@ enum {
> >> #define PM800_WAKEUP2 (0x0E)
> >> #define PM800_WAKEUP2_INV_INT BIT(0)
> >> #define PM800_WAKEUP2_INT_CLEAR BIT(1)
> >>+#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
> >>+#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
> >> #define PM800_WAKEUP2_INT_MASKBIT(2)
> >>
> >> #define PM800_POWER_UP_LOG(0x10)
> >>@@ -300,7 +302,11 @@ struct pm80x_chip {
> >>struct regmap_irq_chip_data *irq_data;
> >>int type;
> >>int irq;
> >>- int irq_mode;
> >>+
> >>+#define PM800_IRQ_CLR_ON_READ 0
> >>+#define PM800_IRQ_CLR_ON_WRITE 1
> >
> >Defines in the middle of structs makes for ugly code.
> >
>
> Sorry, but kernel code is full of such implementations.
> Infact it is right place in terms of readability.
>
> If you still feel insist to fix it, please let me know whether you want
> to submit V6 just for this. Or you will fix it while merging.
> I am OK with anything here...
>
>
> Thanks,
> Vaibhav
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow
[PATCH 2/2] powerpc/mpc85xx:Add SCFG device tree support of T104x
From: Wang Dongsheng
Signed-off-by: Wang Dongsheng
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 9e9f7e2..9770d02 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -484,6 +484,11 @@
reg= <0xea000 0x4000>;
};
+ scfg: global-utilities@fc000 {
+ compatible = "fsl,t1040-scfg";
+ reg = <0xfc000 0x1000>;
+ };
+
/include/ "elo3-dma-0.dtsi"
/include/ "elo3-dma-1.dtsi"
/include/ "qoriq-espi-0.dtsi"
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] powerpc/85xx: Add binding for SCFG
From: Wang Dongsheng
SCFG provides SoC specific configuration and status registers for
the chip. Add this for powerpc platform.
Signed-off-by: Wang Dongsheng
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index cff38bd..55604fe 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -3,6 +3,25 @@ Freescale Reference Board Bindings
This document describes device tree bindings for various devices that
exist on some Freescale reference boards.
+* Supplement configuration unit (SCFG)
+
+SCFG is the supplemental configuration unit, that provides SoC specific
+configuration and status registers for the chip. Such as getting PEX port
+status.
+
+Required properties:
+
+- compatible: should be "fsl,-scfg"
+- reg: should contain base address and length of SCFG memory-mapped
+registers
+
+Example:
+
+ scfg: global-utilities@fc000 {
+ compatible = "fsl,t1040-scfg";
+ reg = <0xfc000 0x1000>;
+ };
+
* Board Control and Status (BCSR)
Required properties:
--
2.1.0.27.g96db324
--
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] dmaengine: xgene-dma: Fix the resource map to handle overlapping
There is an overlap in dma ring cmd csr region due to sharing of ethernet
ring cmd csr region. This patch fix the resource overlapping by mapping
the entire dma ring cmd csr region.
Signed-off-by: Rameshwar Prasad Sahu
---
Documentation/devicetree/bindings/dma/apm-xgene-dma.txt | 2 +-
arch/arm64/boot/dts/apm/apm-storm.dtsi | 2 +-
drivers/dma/xgene-dma.c | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
index d305876..c53e0b0 100644
--- a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
+++ b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
@@ -35,7 +35,7 @@ Example:
device_type = "dma";
reg = <0x0 0x1f27 0x0 0x1>,
<0x0 0x1f20 0x0 0x1>,
- <0x0 0x1b008000 0x0 0x2000>,
+ <0x0 0x1b00 0x0 0x40>,
<0x0 0x1054a000 0x0 0x100>;
interrupts = <0x0 0x82 0x4>,
<0x0 0xb8 0x4>,
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0689c3f..58093ed 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -823,7 +823,7 @@
device_type = "dma";
reg = <0x0 0x1f27 0x0 0x1>,
<0x0 0x1f20 0x0 0x1>,
- <0x0 0x1b008000 0x0 0x2000>,
+ <0x0 0x1b00 0x0 0x40>,
<0x0 0x1054a000 0x0 0x100>;
interrupts = <0x0 0x82 0x4>,
<0x0 0xb8 0x4>,
diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index 620fd55ec..dff22ab 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -111,6 +111,7 @@
#define XGENE_DMA_MEM_RAM_SHUTDOWN 0xD070
#define XGENE_DMA_BLK_MEM_RDY 0xD074
#define XGENE_DMA_BLK_MEM_RDY_VAL 0x
+#define XGENE_DMA_RING_CMD_SM_OFFSET 0x8000
/* X-Gene SoC EFUSE csr register and bit defination */
#define XGENE_SOC_JTAG1_SHADOW 0x18
@@ -1887,6 +1888,8 @@ static int xgene_dma_get_resources(struct platform_device
*pdev,
return -ENOMEM;
}
+ pdma->csr_ring_cmd += XGENE_DMA_RING_CMD_SM_OFFSET;
+
/* Get efuse csr region */
res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
if (!res) {
--
1.8.2.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-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
- int data, mask, ret = -EINVAL;
+ int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip *chip)
}
/*
-* irq_mode defines the way of clearing interrupt. it's read-clear by
-* default.
+* irq_clr_on_wr defines the way of clearing interrupt by
+* read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
- data = PM800_WAKEUP2_INT_CLEAR;
- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
if (ret < 0)
goto out;
@@ -512,6 +513,7 @@ static int device_800_init(struct pm80x_chip *chip,
}
chip->regmap_irq_chip = &pm800_irq_chip;
+ chip->irq_clr_method = pdata->irq_clr_method;
ret = device_irq_init_800(chip);
if (ret < 0) {
@@ -564,6 +566,9 @@ static int pm800_probe(struct i2c_client *client,
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
+
+ /* by default, set irq clear method on write */
+ pdata->irq_clr_method = PM800_IRQ_CLR_ON_WRITE;
}
ret = pm80x_init(client);
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 8fcad63..648e01a 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -77,6 +77,8 @@ enum {
#define PM800_WAKEUP2 (0x0E)
#define PM800_WAKEUP2_INV_INT BIT(0)
#define PM800_WAKEUP2_INT_CLEAR BIT(1)
+#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
+#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
#define PM800_WAKEUP2_INT_MASKBIT(2)
#define PM800_POWER_UP_LOG(0x10)
@@ -300,7 +302,11 @@ struct pm80x_chip {
struct regmap_irq_chip_data *irq_data;
int type;
int irq;
- int irq_mode;
+
+#define PM800_IRQ_CLR_ON_READ 0
+#define PM800_IRQ_CLR_ON_WRITE 1
Defines in the middle of structs makes for ugly code.
Sorry, but kernel code is full of such implementations.
Infact it is right place in terms of readability.
If you still feel insist to fix it, please let me know whether you want
to submit V6 just for this. Or you will fix it while merging.
I am OK with anything here...
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH v3 3/4] mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
Hi, On 07-07-15 09:01, Lee Jones wrote: On Fri, 26 Jun 2015, Hans de Goede wrote: Add a cell for the usb power_supply part of the axp20x PMICs. Note that this cell is only for the usb power_supply part and not the ac-power / battery-charger / rtc-backup-bat-charger bits. Depending on the board each of those must be enabled / disabled separately in devicetree as most boards do not use all 4. So in dt each one needs its own child-node of the axp20x node. Another reason for using separate child nodes for each is so that other devicetree nodes can have a power-supply property with a phandle referencing a node representing a single power-supply. The decision to use a separate devicetree node for each is reflected on the kernel side by each getting its own mfd-cell / platform_device and platform-driver. Note this commit also makes some whitespace changes to the intialization of existing cells in axp20x_cells, these are pure whitespace changes, functionally nothing changes. Cc: Bruno Prémont Acked-by: Lee Jones Signed-off-by: Bruno Prémont Signed-off-by: Hans de Goede --- Changes in v2: -Use DEFINE_RES_IRQ_NAMED -Change indentation of axp20x_cells initializers to avoid line wrapping Changes in v3: -Improve commit message -Add Bruno's S-o-b --- drivers/mfd/axp20x.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) For my own reference: Acked-by: Lee Jones Are these two patches tied to any other in the set, or can I apply them separately? You can apply them seperately, thanks. I'm wondering who will take care of upstreaming the first patch of this set: "ARM: dts: Add binding documentation for AXP20x pmic usb power supply" If you can take that one too that would be great. 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] clk: mediatek: Add MT8173 MMPLL change rate support
Hi Heiko,
On Tue, 2015-07-07 at 11:34 +0200, Heiko Stübner wrote:
> > > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > >
> > > > {
> > > >
> > > > unsigned long fmin = 1000 * MHZ;
> > > >
> > > > + const unsigned long *div_rate = pll->data->div_rate;
> > > >
> > > > u64 _pcw;
> > > > u32 val;
> > > >
> > > > if (freq > pll->data->fmax)
> > > >
> > > > freq = pll->data->fmax;
> > > >
> > > > - for (val = 0; val < 4; val++) {
> > > > + if (div_rate) {
> > > > + for (val = 1; div_rate[val] != 0; val++) {
> > > > + if (freq > div_rate[val])
> > > > + break;
> > > > + }
> > > > + val--;
> > >
> > > if you're changing the table struct, this of course also would need to be
> > > adapted.
> > >
> > >
> > > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the table,
> > > if
> > > you ignore it here all the time?
> > >
> > > So the table should probably look more like [when using the concept from
> > > above]
> > >
> > > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > >
> > > { .freq = 10, .div = 0 },
> > > { .freq = 70200, .div = 1 },
> > > { .freq = 25350, .div = 2 },
> > > { .freq = 12675, .div = 3 },
> > > { /* sentinel */ },
> > >
> > > };
> >
> > The freq-div table describes the maximum frequency of each divider
> > setting. Although the first element doesn't used in current
> > implementation, I think it's better to keep freq-div table's
> > completeness.
>
> the issue I see is, that its value is currently 0 and the code substracts 1.
> So if anything would (accidentially) select MT8173_PLL_FMAX, the u32 val
> would
> wrap around, as you're subtracting 1 from 0 .
Subtracting 1 from val is safe now because it starts from 1:
for (val = 1; div_rate[val] != 0; val++) {
...
}
val--;
I can change this implementation to a more readable one such as:
for (val = 0; div_rate[val + 1] != 0; val++) {
if (freq <= div_rate[val] && freq > div_rate[val + 1]) {
...
Do you think it is OK?
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] ARM: dts: stm32f429: Adopt STM32F4 clock driver
Hi Daniel, 2015-06-10 22:09 GMT+02:00 Daniel Thompson : > New bindings and driver have been created for STM32F42xxx series parts. > This patch integrates these changes. > > Note: Earlier device tree blobs (those without st,stm32f42xxx > compatibles for the rcc) could still be used to boot basic > systems. Such systems rely on the bootloader to configure the > clock gates for vital periperhals. > > Signed-off-by: Daniel Thompson > Reviewed-by: Maxime Coquelin > --- > arch/arm/boot/dts/stm32f429-disco.dts | 4 ++ > arch/arm/boot/dts/stm32f429.dtsi | 79 > +++ > 2 files changed, 28 insertions(+), 55 deletions(-) > Patch applied to next/dt-for-v4.3 of stm32 tree. Thanks! Maxime -- 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] clk: mediatek: Add MT8173 MMPLL change rate support
Hi James,
Am Dienstag, 7. Juli 2015, 17:28:38 schrieb James Liao:
> On Tue, 2015-07-07 at 10:58 +0200, Heiko Stübner wrote:
> > > +#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,
> > > \
> > > + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, \
> > > + _pcw_shift) \
> > > + PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
> > > + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, _pcw_shift, \
> > > + NULL)
> > > +
> > > +const unsigned long mmpll_div_rate[] = {
> >
> > static?
>
> OK. I'll add it.
>
> > > + MT8173_PLL_FMAX,
> > > + 10,
> > > + 70200,
> > > + 25350,
> > > + 12675,
> > > + 0,
> >
> > it's more common to label sentinel entries (the 0 marking the end) with
> >
> > /* sentinel */
> >
> > instead of value 0.
>
> OK. I'll add it.
>
> > If I'm reading the code correctly, this is a mapping divider -> frequency,
> > right? So it may be nice to make this a bit more explicit, like:
> >
> > struct mtk_pll_div_table {
> >
> > unsigned intfreq;
> > unsigned intdiv;
> >
> > };
> >
> > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> >
> > { .freq = MT8173_PLL_FMAX, .div = 0 },
> > { .freq = 10, .div = 1 },
> > { .freq = 70200, .div = 2 },
> > { .freq = 25350, .div = 3 },
> > { .freq = 12675, .div = 4 },
> > { /* sentinel */ },
> >
> > };
>
> Hmm.. OK. I'll try to use a more readable way to implement it.
>
> > -
> >
> > > - u32 con1, pd, val;
> > > + u32 con1, val;
> > >
> > > int pll_en;
> > >
> > > - /* set postdiv */
> > > - pd = readl(pll->pd_addr);
> > > - pd &= ~(POSTDIV_MASK << pll->data->pd_shift);
> > > - pd |= (ffs(postdiv) - 1) << pll->data->pd_shift;
> > > - writel(pd, pll->pd_addr);
> > > -
> > >
> > > pll_en = readl(pll->base_addr + REG_CON0) & CON0_BASE_EN;
> > >
> > > - /* set pcw */
> > > - val = readl(pll->pcw_addr);
> > > + /* set postdiv */
> > > + val = readl(pll->pd_addr);
> > > + val &= ~(POSTDIV_MASK << pll->data->pd_shift);
> > > + val |= (ffs(postdiv) - 1) << pll->data->pd_shift;
> > > +
> > > + /* postdiv and pcw need to set at the same time if on same register
*/
> > > + if (pll->pd_addr != pll->pcw_addr) {
> > > + writel(val, pll->pd_addr);
> > > + val = readl(pll->pcw_addr);
> > > + }
> > >
> > > + /* set pcw */
> > >
> > > val &= ~GENMASK(pll->data->pcw_shift + pll->data->pcwbits - 1,
> > >
> > > pll->data->pcw_shift);
> > >
> > > val |= pcw << pll->data->pcw_shift;
> >
> > This whole block probably wants to be a separate patch ;-) .
> >
> > While it may not affect previous pll implementations, it changes how
> > register accesses are handled and should not hide in another patch.
>
> OK, I'll separate it.
>
> > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > >
> > > {
> > >
> > > unsigned long fmin = 1000 * MHZ;
> > >
> > > + const unsigned long *div_rate = pll->data->div_rate;
> > >
> > > u64 _pcw;
> > > u32 val;
> > >
> > > if (freq > pll->data->fmax)
> > >
> > > freq = pll->data->fmax;
> > >
> > > - for (val = 0; val < 4; val++) {
> > > + if (div_rate) {
> > > + for (val = 1; div_rate[val] != 0; val++) {
> > > + if (freq > div_rate[val])
> > > + break;
> > > + }
> > > + val--;
> >
> > if you're changing the table struct, this of course also would need to be
> > adapted.
> >
> >
> > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the table,
> > if
> > you ignore it here all the time?
> >
> > So the table should probably look more like [when using the concept from
> > above]
> >
> > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> >
> > { .freq = 10, .div = 0 },
> > { .freq = 70200, .div = 1 },
> > { .freq = 25350, .div = 2 },
> > { .freq = 12675, .div = 3 },
> > { /* sentinel */ },
> >
> > };
>
> The freq-div table describes the maximum frequency of each divider
> setting. Although the first element doesn't used in current
> implementation, I think it's better to keep freq-div table's
> completeness.
the issue I see is, that its value is currently 0 and the code substracts 1.
So if anything would (accidentially) select MT8173_PLL_FMAX, the u32 val would
wrap around, as you're subtracting 1 from 0 .
Heiko
--
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] clk: mediatek: Add MT8173 MMPLL change rate support
Hi Heiko,
On Tue, 2015-07-07 at 10:58 +0200, Heiko Stübner wrote:
> > +#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,
> > \
> > + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, \
> > + _pcw_shift) \
> > + PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
> > + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, _pcw_shift, \
> > + NULL)
> > +
> > +const unsigned long mmpll_div_rate[] = {
>
> static?
OK. I'll add it.
>
> > + MT8173_PLL_FMAX,
> > + 10,
> > + 70200,
> > + 25350,
> > + 12675,
> > + 0,
>
> it's more common to label sentinel entries (the 0 marking the end) with
> /* sentinel */
> instead of value 0.
OK. I'll add it.
>
> If I'm reading the code correctly, this is a mapping divider -> frequency,
> right? So it may be nice to make this a bit more explicit, like:
>
> struct mtk_pll_div_table {
> unsigned intfreq;
> unsigned intdiv;
> };
>
> static const struct mtk_pll_div_table mmpll_div_rate[] = {
> { .freq = MT8173_PLL_FMAX, .div = 0 },
> { .freq = 10, .div = 1 },
> { .freq = 70200, .div = 2 },
> { .freq = 25350, .div = 3 },
> { .freq = 12675, .div = 4 },
> { /* sentinel */ },
> };
Hmm.. OK. I'll try to use a more readable way to implement it.
> -
>
> > - u32 con1, pd, val;
> > + u32 con1, val;
> > int pll_en;
> >
> > - /* set postdiv */
> > - pd = readl(pll->pd_addr);
> > - pd &= ~(POSTDIV_MASK << pll->data->pd_shift);
> > - pd |= (ffs(postdiv) - 1) << pll->data->pd_shift;
> > - writel(pd, pll->pd_addr);
> > -
> > pll_en = readl(pll->base_addr + REG_CON0) & CON0_BASE_EN;
> >
> > - /* set pcw */
> > - val = readl(pll->pcw_addr);
> > + /* set postdiv */
> > + val = readl(pll->pd_addr);
> > + val &= ~(POSTDIV_MASK << pll->data->pd_shift);
> > + val |= (ffs(postdiv) - 1) << pll->data->pd_shift;
> > +
> > + /* postdiv and pcw need to set at the same time if on same register */
> > + if (pll->pd_addr != pll->pcw_addr) {
> > + writel(val, pll->pd_addr);
> > + val = readl(pll->pcw_addr);
> > + }
> >
> > + /* set pcw */
> > val &= ~GENMASK(pll->data->pcw_shift + pll->data->pcwbits - 1,
> > pll->data->pcw_shift);
> > val |= pcw << pll->data->pcw_shift;
>
> This whole block probably wants to be a separate patch ;-) .
>
> While it may not affect previous pll implementations, it changes how register
> accesses are handled and should not hide in another patch.
OK, I'll separate it.
> > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > {
> > unsigned long fmin = 1000 * MHZ;
> > + const unsigned long *div_rate = pll->data->div_rate;
> > u64 _pcw;
> > u32 val;
> >
> > if (freq > pll->data->fmax)
> > freq = pll->data->fmax;
> >
> > - for (val = 0; val < 4; val++) {
> > + if (div_rate) {
> > + for (val = 1; div_rate[val] != 0; val++) {
> > + if (freq > div_rate[val])
> > + break;
> > + }
> > + val--;
>
> if you're changing the table struct, this of course also would need to be
> adapted.
>
>
> Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the table, if
> you ignore it here all the time?
>
> So the table should probably look more like [when using the concept from
> above]
>
> static const struct mtk_pll_div_table mmpll_div_rate[] = {
> { .freq = 10, .div = 0 },
> { .freq = 70200, .div = 1 },
> { .freq = 25350, .div = 2 },
> { .freq = 12675, .div = 3 },
> { /* sentinel */ },
> };
The freq-div table describes the maximum frequency of each divider
setting. Although the first element doesn't used in current
implementation, I think it's better to keep freq-div table's
completeness.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] ARM/PCI: remove align_resource callback in pcibios_align_resource
On Tue, Jul 07, 2015 at 06:44:01AM +0100, Zhou Wang wrote:
> On 2015/7/3 1:50, Liviu Dudau wrote:
> > On Wed, Jul 01, 2015 at 10:43:33AM +0100, Zhou Wang wrote:
> >> This patch had added by Arnd Bergmann during last reviewing of v1
> >> patchset[1].
> >>
> >> PCI core codes call pcibios_align_resource(). In ARM specific one, it will
> >> dereference pci_sys_data and call sys->align_resource. If we try to unify
> >> ARM
> >> and ARM64 PCIe API in pcie-designware. it will bring kernel crash when run
> >> into
> >> this dereferencing.
> >>
> >> However, in ARM there is only pci-mvebu which implements align_resource. So
> >> add align_resource call back in pci_host_bridge structure and override
> >> pcibios_align_resource with it.
> >>
> >> Signed-off-by: Arnd Bergmann
> >> Signed-off-by: Zhou Wang
> >> Tested-by: Fabrice Gasnier
> >>
> >> [1] http://www.spinics.net/lists/linux-pci/msg41671.html
> >> ---
> >> arch/arm/kernel/bios32.c | 6 --
> >> drivers/pci/host/pci-mvebu.c | 47
> >>
> >> drivers/pci/setup-res.c | 27 -
> >> include/linux/pci.h | 3 +++
> >> 4 files changed, 55 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> >> index fc1..b01189f 100644
> >> --- a/arch/arm/kernel/bios32.c
> >> +++ b/arch/arm/kernel/bios32.c
> >> @@ -468,7 +468,6 @@ static void pcibios_init_hw(struct device *parent,
> >> struct hw_pci *hw,
> >>sys->busnr = busnr;
> >>sys->swizzle = hw->swizzle;
> >>sys->map_irq = hw->map_irq;
> >> - sys->align_resource = hw->align_resource;
> >>INIT_LIST_HEAD(&sys->resources);
> >>
> >>if (hw->private_data)
> >> @@ -588,8 +587,6 @@ char * __init pcibios_setup(char *str)
> >> resource_size_t pcibios_align_resource(void *data, const struct resource
> >> *res,
> >>resource_size_t size, resource_size_t align)
> >> {
> >> - struct pci_dev *dev = data;
> >> - struct pci_sys_data *sys = dev->sysdata;
> >>resource_size_t start = res->start;
> >>
> >>if (res->flags & IORESOURCE_IO && start & 0x300)
> >> @@ -597,9 +594,6 @@ resource_size_t pcibios_align_resource(void *data,
> >> const struct resource *res,
> >>
> >>start = (start + align - 1) & ~(align - 1);
> >>
> >> - if (sys->align_resource)
> >> - return sys->align_resource(dev, res, start, size, align);
> >> -
> >>return start;
> >> }
> >>
> >> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> >> index 1ab8635..155d05f 100644
> >> --- a/drivers/pci/host/pci-mvebu.c
> >> +++ b/drivers/pci/host/pci-mvebu.c
> >> @@ -22,6 +22,8 @@
> >> #include
> >> #include
> >>
> >> +#include "../pci.h" /* HACK to see pci_find_host_bridge */
> >> +
> >> /*
> >> * PCIe unit register offsets.
> >> */
> >> @@ -751,27 +753,20 @@ static int mvebu_pcie_setup(int nr, struct
> >> pci_sys_data *sys)
> >>return 1;
> >> }
> >>
> >> -static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data
> >> *sys)
> >> +static resource_size_t mvebu_pcie_align_resource(void *data,
> >> + const struct resource *res,
> >> + resource_size_t size,
> >> + resource_size_t align)
> >> {
> >> - struct mvebu_pcie *pcie = sys_to_pcie(sys);
> >> - struct pci_bus *bus;
> >> + struct pci_dev *dev = data;
> >>
> >> - bus = pci_create_root_bus(&pcie->pdev->dev, sys->busnr,
> >> -&mvebu_pcie_ops, sys, &sys->resources);
> >> - if (!bus)
> >> - return NULL;
> >> + resource_size_t start = res->start;
> >>
> >> - pci_scan_child_bus(bus);
> >> + if (res->flags & IORESOURCE_IO && start & 0x300)
> >> + start = (start + 0x3ff) & ~0x3ff;
> >>
> >> - return bus;
> >> -}
> >> + start = (start + align - 1) & ~(align - 1);
> >
> > Honestly, I don't see here anything that is mvebu specific. Could you move
>
> What I mean is that there is only mvebu who implemented sys->align_resource
> callback in ARM
> arch.
>
> > this function in the generic pci/host area and have a flag in the
> > pci_host_bridge
> > structure whether the function should be called or not? I know that in a way
> > that looks very close to the existing implementation which uses
> > pcibios_align_resource,
>
> I am confused about "the existing implementation". Now pcibios_align_resource
> are
> implemented by each arch code and are called directly. Did I miss anything
> about
> pcibios_align_resource?
Sorry, I meant existing implementation_s_ and yes, I was reffering to the arch
specific
code. If you look at the cris, frv/mb93090-mb00, m68k, microblaze, powerpc,
unicore32
and x86 they all share the code with your version, plus or minus additional
checks.
I was thinking that for those arch versions
Re: [PATCH] arm64: dts: mt8173: Add afe device node
On Tue, 2015-07-07 at 09:46 +0200, Matthias Brugger wrote:
> On Monday, July 06, 2015 09:02:38 PM Daniel Kurtz wrote:
> > On Mon, Jul 6, 2015 at 2:52 PM, Koro Chen wrote:
> > > This adds afe (audio front end) device node to the MT8173 dtsi file.
> > >
> > > This patch is based on Matthias's tree:
> > > https://github.com/mbgg/linux-mediatek
> > > branch: v4.2-next/arm64
> > >
> > > Signed-off-by: Koro Chen
> > > ---
> > >
> > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 32
> > > 1 file changed, 32 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi index 0696f8f..f8afab4 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > > @@ -14,6 +14,7 @@
> > >
> > > #include
> > > #include
> > > #include
> > >
> > > +#include
> > >
> > > #include
> > > #include "mt8173-pinfunc.h"
> > >
> > > @@ -393,6 +394,37 @@
> > >
> > > #size-cells = <0>;
> > > status = "disabled";
> > >
> > > };
> > >
> > > +
> > > + afe: mt8173-afe-pcm@1122 {
> >
> > I believe this should be something generic, like:
> >
> > afe: audio-controller@1122
> >
>
> Yes, please find a name that better describes the component instead of just
> using the compatible string.
>
Thanks both, I will change the name to audio-controller.
> Thanks.
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
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] clk: mediatek: Add MT8173 MMPLL change rate support
Hi James,
Am Dienstag, 2. Juni 2015, 13:26:00 schrieb James Liao:
> MT8173 MMPLL frequency settings are different from common PLLs.
> It needs different post divider settings for some ranges of frequency.
> This patch add support for MT8173 MMPLL frequency setting, includes:
>
> 1. Add div-rate table for PLLs.
> 2. Increase the max ost divider setting from 3 (/8) to 4 (/16).
> 3. Write postdiv and pcw settings at the same time.
>
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/clk-mt8173.c | 24 +---
> drivers/clk/mediatek/clk-mtk.h| 1 +
> drivers/clk/mediatek/clk-pll.c| 37
> + 3 files changed, 47 insertions(+), 15
> deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c index 357b080..821de7d 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -779,8 +779,9 @@ CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg",
> mtk_pericfg_init);
>
> #define CON0_MT8173_RST_BAR BIT(24)
>
> -#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,
> _pd_reg, _pd_shift, \ - _tuner_reg, _pcw_reg,
> _pcw_shift) { \
> +#define PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,
> \
> + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, \
> + _pcw_shift, _div_rate) {\
> .id = _id, \
> .name = _name, \
> .reg = _reg,\
> @@ -795,14 +796,31 @@ CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg",
> mtk_pericfg_init); .tuner_reg = _tuner_reg, \
> .pcw_reg = _pcw_reg,\
> .pcw_shift = _pcw_shift,\
> + .div_rate = _div_rate, \
> }
>
> +#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
> + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, \
> + _pcw_shift) \
> + PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
> + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, _pcw_shift, \
> + NULL)
> +
> +const unsigned long mmpll_div_rate[] = {
static?
> + MT8173_PLL_FMAX,
> + 10,
> + 70200,
> + 25350,
> + 12675,
> + 0,
it's more common to label sentinel entries (the 0 marking the end) with
/* sentinel */
instead of value 0.
If I'm reading the code correctly, this is a mapping divider -> frequency,
right? So it may be nice to make this a bit more explicit, like:
struct mtk_pll_div_table {
unsigned intfreq;
unsigned intdiv;
};
static const struct mtk_pll_div_table mmpll_div_rate[] = {
{ .freq = MT8173_PLL_FMAX, .div = 0 },
{ .freq = 10, .div = 1 },
{ .freq = 70200, .div = 2 },
{ .freq = 25350, .div = 3 },
{ .freq = 12675, .div = 4 },
{ /* sentinel */ },
};
> +};
> +
> static const struct mtk_pll_data plls[] = {
> PLL(CLK_APMIXED_ARMCA15PLL, "armca15pll", 0x200, 0x20c, 0x0001, 0,
21,
> 0x204, 24, 0x0, 0x204, 0), PLL(CLK_APMIXED_ARMCA7PLL, "armca7pll", 0x210,
> 0x21c, 0x0001, 0, 21, 0x214, 24, 0x0, 0x214, 0),
> PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x220, 0x22c, 0xf101, HAVE_RST_BAR,
> 21, 0x220, 4, 0x0, 0x224, 0), PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x230,
> 0x23c, 0xfe01, HAVE_RST_BAR, 7, 0x230, 4, 0x0, 0x234, 14),
> - PLL(CLK_APMIXED_MMPLL, "mmpll", 0x240, 0x24c, 0x0001, 0, 21, 0x244,
> 24, 0x0, 0x244, 0), + PLL_B(CLK_APMIXED_MMPLL, "mmpll", 0x240, 0x24c,
> 0x0001, 0, 21, 0x244, 24, 0x0, 0x244, 0, mmpll_div_rate),
> PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x250, 0x25c, 0x0001, 0, 21, 0x250,
> 4, 0x0, 0x254, 0), PLL(CLK_APMIXED_VENCPLL, "vencpll", 0x260, 0x26c,
> 0x0001, 0, 21, 0x260, 4, 0x0, 0x264, 0), PLL(CLK_APMIXED_TVDPLL,
> "tvdpll", 0x270, 0x27c, 0x0001, 0, 21, 0x270, 4, 0x0, 0x274, 0), diff
> --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 61035b9..645af7c 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -150,6 +150,7 @@ struct mtk_pll_data {
> int pcwbits;
> uint32_t pcw_reg;
> int pcw_shift;
> + const unsigned long *div_rate;
> };
>
> void __init mtk_clk_register_plls(struct device_node *node,
> diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> index 44409e9..4680a09 100644
> --- a/drivers/clk/mediatek/clk-pll.c
> +++ b/drivers/clk/mediatek/clk-pll.c
> @@ -90,20 +90,23 @@ static unsigned long __mtk_pll_recalc_rate(struct
> mtk_clk_pll *pll, u
RE: [PATCH v2] phy: rcar-gen2 usb: Add Host/Function switching for USB0
Hi Shimoda-san,
On 06 July 2015 08:18, Shimoda-san wrote:
> Hi Phil-san,
>
> Thank you very much for the patch!
>
> > Sent: Thursday, July 02, 2015 5:06 PM
> < snip >
> > +/* VBUS change IRQ handler */
> > +static irqreturn_t gpio_vbus_irq(int irq, void *data)
> > +{
> > + struct rcar_gen2_channel *channel = data;
> > +
> > + /* Wait 20ms before doing anything as VBUS needs to settle */
> > + schedule_delayed_work(&channel->work, msecs_to_jiffies(20));
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int probe_otg(struct platform_device *pdev,
> > + struct rcar_gen2_phy_driver *drv)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct rcar_gen2_channel *ch = drv->channels;
> > + int irq;
> > + int ret;
> > +
> > + /* GPIOs for Host/Fn switching */
> > + ch->gpio_id = of_get_named_gpio_flags(dev->of_node,
> > + "renesas,id-gpio", 0, NULL);
> > + ch->gpio_vbus = of_get_named_gpio_flags(dev->of_node,
> > + "renesas,vbus-gpio", 0, NULL);
> > +
> > + /* Need valid ID and VBUS gpios for Host/Fn switching */
> > + if (gpio_is_valid(ch->gpio_id) && gpio_is_valid(ch->gpio_vbus)) {
> > + ch->use_otg = 1;
> > +
> > + /* GPIO for ID input */
> > + ret = devm_gpio_request_one(dev, ch->gpio_id, GPIOF_IN,
> "id");
> > + if (ret)
> > + return ret;
> > +
> > + /* GPIO for VBUS input */
> > + ret = devm_gpio_request_one(dev, ch->gpio_vbus, GPIOF_IN,
> "vbus");
>
> According to the checkpatch.pl, "line over 80 characters".
As I understand it, the 80 chars is not a hard rule. One reason for the
80 char guideline is to avoid overly complex code, but I don't think
that can be said of the above line!
> > + if (ret)
> > + return ret;
> > +
> > + irq = gpio_to_irq(ch->gpio_vbus);
> > + ret = devm_request_irq(dev, irq, gpio_vbus_irq,
> VBUS_IRQ_FLAGS,
> > + "vbus_detect", ch);
> > + if (ret)
> > + return ret;
> > +
> > + /* Optional GPIO for VBUS power */
> > + ch->gpio_vbus_pwr = of_get_named_gpio_flags(dev->of_node,
> > + "renesas,vbus-pwr-gpio", 0,
> NULL);
>
> Same above.
Since this code was already split over two lines, I agree with you here.
>
> > + if (gpio_is_valid(ch->gpio_id)) {
> > + ret = devm_gpio_request_one(dev, ch->gpio_vbus_pwr,
> > + GPIOF_OUT_INIT_LOW, "vbus-pwr");
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + } else if (gpio_is_valid(ch->gpio_id)) {
> > + dev_err(dev, "Failed to get VBUS gpio\n");
> > + return ch->gpio_vbus;
> > + } else if (gpio_is_valid(ch->gpio_vbus)) {
> > + dev_err(dev, "Failed to get ID gpio\n");
> > + return ch->gpio_id;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/* bind/unbind the peripheral controller */
> > +static int rcar_gen2_usb_set_peripheral(struct usb_otg *otg,
> > + struct usb_gadget *gadget)
> > +{
> > + otg->gadget = gadget;
> > + if (!gadget) {
> > + usb_gadget_vbus_disconnect(otg->gadget);
>
> Since the otg->gadget is NULL, this driver should not call this function here.
Ah, yes you are correct!
> > + otg->state = OTG_STATE_UNDEFINED;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int rcar_gen2_phy_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> < snip >
> > @@ -323,6 +540,14 @@ static int rcar_gen2_phy_probe(struct platform_device
> *pdev)
> >
> > dev_set_drvdata(dev, drv);
> >
> > + /*
> > +* If we already have something plugged into USB0, we won't get an edge
> > +* on VBUS, so we have to manually schedule work to look at the VBUS
> > +* and ID signals.
> > +*/
> > + if (drv->channels->use_otg)
> > + schedule_delayed_work(&drv->channels->work,
> msecs_to_jiffies(100));
>
> This line is also "line over 80 characters".
I don't think it is necessary to force this into the 80 char recommendation.
> Best regards,
> Yoshihiro Shimoda
>
> > +
> > return 0;
> > }
> >
> > --
> > 1.9.1
Best regards
Phil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: mediatek: add mt6580 basic support
Hi all
Sorry for this title of mail. It should be:
[PATCH v3 2/2] ARM: dts: mediatek: add mt6580 basic support
Thanks.
On Tue, 2015-07-07 at 15:56 +0800, mars.ch...@mediatek.com wrote:
> From: Mars Cheng
>
> This adds basic chip support for Mediatek 6580.
>
> Signed-off-by: Mars Cheng
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/mt6580-evbp1.dts | 35 +++
> arch/arm/boot/dts/mt6580.dtsi | 123
> +
> 3 files changed, 159 insertions(+)
> create mode 100644 arch/arm/boot/dts/mt6580-evbp1.dts
> create mode 100644 arch/arm/boot/dts/mt6580.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 246473a..919e7c6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -705,6 +705,7 @@ dtb-$(CONFIG_MACH_DOVE) += \
> dove-dove-db.dtb \
> dove-sbc-a510.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += \
> + mt6580-evbp1.dtb \
> mt6589-aquaris5.dtb \
> mt6592-evb.dtb \
> mt8127-moose.dtb \
> diff --git a/arch/arm/boot/dts/mt6580-evbp1.dts
> b/arch/arm/boot/dts/mt6580-evbp1.dts
> new file mode 100644
> index 000..8c42335
> --- /dev/null
> +++ b/arch/arm/boot/dts/mt6580-evbp1.dts
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Mars.C
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +#include "mt6580.dtsi"
> +
> +/ {
> + model = "MediaTek MT6580 evaluation board";
> + compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
> +
> + chosen {
> + bootargs = "console=ttyS0,921600n8 earlyprintk";
> + stdout-path = &uart0;
> + };
> +
> + memory {
> + reg = <0x8000 0x2000>;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> diff --git a/arch/arm/boot/dts/mt6580.dtsi b/arch/arm/boot/dts/mt6580.dtsi
> new file mode 100644
> index 000..09852cd
> --- /dev/null
> +++ b/arch/arm/boot/dts/mt6580.dtsi
> @@ -0,0 +1,123 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Mars.C
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "mediatek,mt6580";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&sysirq>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x0>;
> + };
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x1>;
> + };
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x2>;
> + };
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x3>;
> + };
> +
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges;
> +
> + system_clk: dummy13m {
> + compatible = "fixed-clock";
> + clock-frequency = <1300>;
> + #clock-cells = <0>;
> + };
> +
> + rtc_clk: dummy32k {
> + compatible = "fixed-clock";
> + clock-frequency = <32000>;
> + #clock-cells = <0>;
> + };
> +
> + uart_clk: dummy26m {
> + compatible = "fixed-clock";
> + clock-frequency = <2600>;
> + #clock-cells = <0>;
> + };
> + };
> +
> + timer: timer@10008000 {
> + compatible = "mediatek,mt6580-timer",
> + "mediatek,mt6577-timer";
> + reg = <0x1000
