* [PATCH 5/5] ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Simon Horman, Magnus Damm, Chris Paterson, devicetree,
linux-renesas-soc, linux-arm-kernel, Biju Das
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
This patch enables SGTL5000 audio codec on the carrier board.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 54470c6..2070b14 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -20,6 +20,20 @@
stdout-path = "serial0:115200n8";
};
+ audio_clock: audio_clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ reg_1p5v: 1p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P5V";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
vcc_sdhi1: regulator-vcc-sdhi1 {
compatible = "regulator-fixed";
@@ -83,6 +97,16 @@
compatible = "ti,bq32000";
reg = <0x68>;
};
+
+ sgtl5000: codec@0a {
+ compatible = "fsl,sgtl5000";
+ #sound-dai-cells = <0>;
+ reg = <0x0a>;
+ clocks = <&audio_clock>;
+ VDDA-supply = <®_3p3v>;
+ VDDIO-supply = <®_3p3v>;
+ VDDD-supply = <®_1p5v>;
+ };
};
&pci0 {
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Add CMT support to r8a774[35]
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Fabrizio Castro, Daniel Lezcano, Thomas Gleixner, Simon Horman,
Magnus Damm, Geert Uytterhoeven, Chris Paterson, Biju Das,
devicetree, linux-renesas-soc, linux-arm-kernel
This series adds CMT support for r8a7743 and r8a7745.
Thanks,
Fabrizio Castro (3):
dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
ARM: dts: r8a7743: Add CMT SoC specific support
ARM: dts: r8a7745: Add CMT SoC specific support
.../devicetree/bindings/timer/renesas,cmt.txt | 12 ++++++---
arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++
arch/arm/boot/dts/r8a7745.dtsi | 30 ++++++++++++++++++++++
3 files changed, 69 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Fabrizio Castro, linux-renesas-soc, Daniel Lezcano,
Thomas Gleixner, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das, devicetree
In-Reply-To: <1513104579-6333-1-git-send-email-fabrizio.castro@bp.renesas.com>
Document SoC specific compatible strings for r8a7743 and r8a7745.
No driver change is needed as the fallback strings will activate
the right code.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
Documentation/devicetree/bindings/timer/renesas,cmt.txt | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
index d740989..1e4fe98 100644
--- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
@@ -22,6 +22,10 @@ Required Properties:
- "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
- "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
+ - "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743.
+ - "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743.
+ - "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745.
+ - "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745.
- "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790.
- "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790.
- "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791.
@@ -31,9 +35,11 @@ Required Properties:
- "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794.
- "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794.
- - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2.
- - "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2.
- These are fallbacks for r8a73a4 and all the R-Car Gen2
+ - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2 or
+ RZ/G1.
+ - "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2 or
+ RZ/G1.
+ These are fallbacks for r8a73a4, all the R-Car Gen2 and RZ/G1
entries listed above.
- reg: base address and length of the registers block for the timer module.
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1513104579-6333-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 59860c8..0e2834a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -262,6 +262,36 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer@ffca0000 {
+ compatible = "renesas,r8a7743-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ };
+
+ cmt1: timer@e6130000 {
+ compatible = "renesas,r8a7743-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ };
+
cpg: clock-controller@e6150000 {
compatible = "renesas,r8a7743-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: r8a7745: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1513104579-6333-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7745.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0fa7861..765a80d 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -235,6 +235,36 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer@ffca0000 {
+ compatible = "renesas,r8a7745-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ };
+
+ cmt1: timer@e6130000 {
+ compatible = "renesas,r8a7745-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ };
+
cpg: clock-controller@e6150000 {
compatible = "renesas,r8a7745-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/6] Updated LP8860 driver series
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
All
v3 - Made changes to the patch set to address concerns on DT node naming conventions
based on discussion in the RFC patch https://patchwork.kernel.org/patch/10089047/
also made requested changes to the DT and driver based on feedback. Patchworks
links in each patch.
v2 - Added an initial patch to bring the DT binding up to standard prior to adding
the changes for the label and triggers.
v1 Cover letter repeat below
After creating a new LED driver for the LM3692x device I went back to the
LP8860 driver that I authored and found some updates that need to be applied.
First the way the LP8860 retrieved the label from the DT was incorrect as the
label should have been from a child node as opposed to the parent. This is now
fixed with this series.
Second, since that device can be used to as either a backlight driver or as a
string agnostic driver a trigger to the backlight needed to be added.
Finally there are changes to the driver that need to be made as either
unnoticed bugs or updates to the driver to align with the current LED
framework. For instance moving to the devm LED class registration, destroying
the mutex upon driver removal and removing the in driver dependency on CONFIG_OF
and moving it to the Kconfig.
With these changes this should at least bring the driver into a better shape.
There are additional changes coming for this driver but I wanted to get the
driver up to snuff before adding a feature to it.
Dan
Dan Murphy (6):
dt: bindings: lp8860: Update bindings for lp8860
dt: bindings: lp8860: Update DT label binding
leds: lp8860: Update the dt parsing for LED labeling
dt: bindings: lp8860: Add trigger binding to the lp8860
leds: lp8860: Add DT parsing to retrieve the trigger node
leds: lp8860: Various fixes to align with LED framework
.../devicetree/bindings/leds/leds-lp8860.txt | 32 ++++++++++++-----
drivers/leds/Kconfig | 2 +-
drivers/leds/leds-lp8860.c | 40 ++++++++++++----------
3 files changed, 46 insertions(+), 28 deletions(-)
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/6] dt: bindings: lp8860: Update bindings for lp8860
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171212185809.23880-1-dmurphy@ti.com>
Update the lp8860 bindings to fix various issues
found. Add address-cells and size-cells, rename
enable-gpio to enable-gpios, update the node name
to the device name and indent the node example.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v3 - Indicatd enable-gpios is active high, moved address and size cells to child
node patch and updated parent DT node name - https://patchwork.kernel.org/patch/10093745/
v2 - New patch
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index aad38dd94d4b..b9d09acbaa73 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -6,22 +6,22 @@ current sinks that can be controlled by a PWM input
signal, a SPI/I2C master, or both.
Required properties:
- - compatible:
+ - compatible :
"ti,lp8860"
- - reg - I2C slave address
- - label - Used for naming LEDs
+ - reg : I2C slave address
+ - label : Used for naming LEDs
Optional properties:
- - enable-gpio - gpio pin to enable/disable the device.
- - supply - "vled" - LED supply
+ - enable-gpios : gpio pin to enable (active high)/disable the device.
+ - vled-supply : LED supply
Example:
-leds: leds@6 {
+led-controller@2d {
compatible = "ti,lp8860";
reg = <0x2d>;
label = "display_cluster";
- enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
vled-supply = <&vbatt>;
}
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH v3 1/1] leds: lp8860: Various fixes to align with LED framework
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171212185809.23880-1-dmurphy@ti.com>
Update the driver to conform with the LED framework.
Use devm_led_classdev_register
Destroy mutex on exit
Remove dependency on CONFIG_OF in the driver and move
to the Kconfig
Update the MODULE_LICENSE to GPL v2
Remove setting of MAX brightness as the LED framework
does this.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/leds/Kconfig | 2 +-
drivers/leds/leds-lp8860.c | 13 +++++--------
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 318a28fd58fe..ac4d9d8bf96b 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -347,7 +347,7 @@ config LEDS_LP8788
config LEDS_LP8860
tristate "LED support for the TI LP8860 4 channel LED driver"
- depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS && I2C && OF
select REGMAP_I2C
help
If you say yes here you get support for the TI LP8860 4 channel
diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index 309a73a0c2dd..f38531c30185 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -399,7 +399,6 @@ static int lp8860_probe(struct i2c_client *client,
led->client = client;
led->led_dev.name = led->label;
- led->led_dev.max_brightness = LED_FULL;
led->led_dev.brightness_set_blocking = lp8860_brightness_set;
mutex_init(&led->lock);
@@ -426,7 +425,7 @@ static int lp8860_probe(struct i2c_client *client,
if (ret)
return ret;
- ret = led_classdev_register(&client->dev, &led->led_dev);
+ ret = devm_led_classdev_register(&client->dev, &led->led_dev);
if (ret) {
dev_err(&client->dev, "led register err: %d\n", ret);
return ret;
@@ -440,8 +439,6 @@ static int lp8860_remove(struct i2c_client *client)
struct lp8860_led *led = i2c_get_clientdata(client);
int ret;
- led_classdev_unregister(&led->led_dev);
-
if (led->enable_gpio)
gpiod_direction_output(led->enable_gpio, 0);
@@ -452,6 +449,8 @@ static int lp8860_remove(struct i2c_client *client)
"Failed to disable regulator\n");
}
+ mutex_destroy(&led->lock);
+
return 0;
}
@@ -461,18 +460,16 @@ static const struct i2c_device_id lp8860_id[] = {
};
MODULE_DEVICE_TABLE(i2c, lp8860_id);
-#ifdef CONFIG_OF
static const struct of_device_id of_lp8860_leds_match[] = {
{ .compatible = "ti,lp8860", },
{},
};
MODULE_DEVICE_TABLE(of, of_lp8860_leds_match);
-#endif
static struct i2c_driver lp8860_driver = {
.driver = {
.name = "lp8860",
- .of_match_table = of_match_ptr(of_lp8860_leds_match),
+ .of_match_table = of_lp8860_leds_match,
},
.probe = lp8860_probe,
.remove = lp8860_remove,
@@ -482,4 +479,4 @@ module_i2c_driver(lp8860_driver);
MODULE_DESCRIPTION("Texas Instruments LP8860 LED driver");
MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH v3 2/6] dt: bindings: lp8860: Update DT label binding
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
In-Reply-To: <20171212185809.23880-1-dmurphy-l0cyMroinI0@public.gmane.org>
Update the lp8860 label binding to the LED
standard as documented in
Documentation/devicetree/bindings/leds/common.txt
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v3 - Added address and size cells, updated label with color and inserted spaces
around the reg node - https://patchwork.kernel.org/patch/10093749/
v2 - Added reg to child node and made it required
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index b9d09acbaa73..c3d64ade1e26 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -9,20 +9,33 @@ Required properties:
- compatible :
"ti,lp8860"
- reg : I2C slave address
- - label : Used for naming LEDs
+ - #address-cells : 1
+ - #size-cells : 0
Optional properties:
- enable-gpios : gpio pin to enable (active high)/disable the device.
- vled-supply : LED supply
+Required child properties:
+ - reg : 0
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
Example:
led-controller@2d {
compatible = "ti,lp8860";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x2d>;
- label = "display_cluster";
enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
vled-supply = <&vbatt>;
+
+ led@0 {
+ reg = <0>;
+ label = "white:display_cluster";
+ };
}
For more product information please see the link below:
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 3/6] leds: lp8860: Update the dt parsing for LED labeling
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
In-Reply-To: <20171212185809.23880-1-dmurphy-l0cyMroinI0@public.gmane.org>
Update the DT parsing for the label node so that
the label is retrieved from the device child as
opposed to being part of the parent.
This will align this driver with the LED
binding documentation
Documentation/devicetree/bindings/leds/common.txt
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v3 - Changed the label generation to pull the name from the i2c device id
as opposed to pulling the id from the parent dt node since that will just be
led-controller - https://patchwork.kernel.org/patch/10093753/
v2 - no changes
drivers/leds/leds-lp8860.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index 3e70775a2d54..bc432764c99d 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -22,6 +22,7 @@
#include <linux/of_gpio.h>
#include <linux/gpio/consumer.h>
#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
#define LP8860_DISP_CL1_BRT_MSB 0x00
#define LP8860_DISP_CL1_BRT_LSB 0x01
@@ -86,8 +87,6 @@
#define LP8860_CLEAR_FAULTS 0x01
-#define LP8860_DISP_LED_NAME "display_cluster"
-
/**
* struct lp8860_led -
* @lock - Lock for reading/writing the device
@@ -107,7 +106,7 @@ struct lp8860_led {
struct regmap *eeprom_regmap;
struct gpio_desc *enable_gpio;
struct regulator *regulator;
- const char *label;
+ char label[LED_MAX_NAME_SIZE];
};
struct lp8860_eeprom_reg {
@@ -365,19 +364,21 @@ static int lp8860_probe(struct i2c_client *client,
int ret;
struct lp8860_led *led;
struct device_node *np = client->dev.of_node;
+ struct device_node *child_node;
+ const char *name;
led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
if (!led)
return -ENOMEM;
- led->label = LP8860_DISP_LED_NAME;
-
- if (client->dev.of_node) {
- ret = of_property_read_string(np, "label", &led->label);
- if (ret) {
- dev_err(&client->dev, "Missing label in dt\n");
- return -EINVAL;
- }
+ for_each_available_child_of_node(np, child_node) {
+ ret = of_property_read_string(child_node, "label", &name);
+ if (!ret)
+ snprintf(led->label, sizeof(led->label), "%s:%s",
+ id->name, name);
+ else
+ snprintf(led->label, sizeof(led->label),
+ "%s::display_cluster", id->name);
}
led->enable_gpio = devm_gpiod_get_optional(&client->dev,
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 4/6] dt: bindings: lp8860: Add trigger binding to the lp8860
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171212185809.23880-1-dmurphy@ti.com>
Add a default trigger optional node to the child node.
This will allow the driver to set the trigger for a backlight.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v3 - Removed optional and rebased - https://patchwork.kernel.org/patch/10093755/
v2 - Moved binding changes to first patch in the series.
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index c3d64ade1e26..cdb9e12bd0aa 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -21,6 +21,8 @@ Required child properties:
Optional child properties:
- label : see Documentation/devicetree/bindings/leds/common.txt
+ - linux,default-trigger :
+ see Documentation/devicetree/bindings/leds/common.txt
Example:
@@ -35,6 +37,7 @@ led-controller@2d {
led@0 {
reg = <0>;
label = "white:display_cluster";
+ linux,default-trigger = "backlight";
};
}
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH v3 5/6] leds: lp8860: Add DT parsing to retrieve the trigger node
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171212185809.23880-1-dmurphy@ti.com>
Add the ability to parse the DT and set the default
trigger mode for the LED.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v3 - no changes - https://patchwork.kernel.org/patch/10093751/
v2 - no changes
drivers/leds/leds-lp8860.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index bc432764c99d..309a73a0c2dd 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -372,6 +372,10 @@ static int lp8860_probe(struct i2c_client *client,
return -ENOMEM;
for_each_available_child_of_node(np, child_node) {
+ led->led_dev.default_trigger = of_get_property(child_node,
+ "linux,default-trigger",
+ NULL);
+
ret = of_property_read_string(child_node, "label", &name);
if (!ret)
snprintf(led->label, sizeof(led->label), "%s:%s",
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH v3 6/6] leds: lp8860: Various fixes to align with LED framework
From: Dan Murphy @ 2017-12-12 18:58 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171212185809.23880-1-dmurphy@ti.com>
Update the driver to conform with the LED framework.
Use devm_led_classdev_register
Destroy mutex on exit
Remove dependency on CONFIG_OF in the driver and move
to the Kconfig
Update the MODULE_LICENSE to GPL v2
Remove setting of MAX brightness as the LED framework
does this.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v3 - no changes - https://patchwork.kernel.org/patch/10093747/
v2 - no changes
drivers/leds/Kconfig | 2 +-
drivers/leds/leds-lp8860.c | 13 +++++--------
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 318a28fd58fe..ac4d9d8bf96b 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -347,7 +347,7 @@ config LEDS_LP8788
config LEDS_LP8860
tristate "LED support for the TI LP8860 4 channel LED driver"
- depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS && I2C && OF
select REGMAP_I2C
help
If you say yes here you get support for the TI LP8860 4 channel
diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index 309a73a0c2dd..f38531c30185 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -399,7 +399,6 @@ static int lp8860_probe(struct i2c_client *client,
led->client = client;
led->led_dev.name = led->label;
- led->led_dev.max_brightness = LED_FULL;
led->led_dev.brightness_set_blocking = lp8860_brightness_set;
mutex_init(&led->lock);
@@ -426,7 +425,7 @@ static int lp8860_probe(struct i2c_client *client,
if (ret)
return ret;
- ret = led_classdev_register(&client->dev, &led->led_dev);
+ ret = devm_led_classdev_register(&client->dev, &led->led_dev);
if (ret) {
dev_err(&client->dev, "led register err: %d\n", ret);
return ret;
@@ -440,8 +439,6 @@ static int lp8860_remove(struct i2c_client *client)
struct lp8860_led *led = i2c_get_clientdata(client);
int ret;
- led_classdev_unregister(&led->led_dev);
-
if (led->enable_gpio)
gpiod_direction_output(led->enable_gpio, 0);
@@ -452,6 +449,8 @@ static int lp8860_remove(struct i2c_client *client)
"Failed to disable regulator\n");
}
+ mutex_destroy(&led->lock);
+
return 0;
}
@@ -461,18 +460,16 @@ static const struct i2c_device_id lp8860_id[] = {
};
MODULE_DEVICE_TABLE(i2c, lp8860_id);
-#ifdef CONFIG_OF
static const struct of_device_id of_lp8860_leds_match[] = {
{ .compatible = "ti,lp8860", },
{},
};
MODULE_DEVICE_TABLE(of, of_lp8860_leds_match);
-#endif
static struct i2c_driver lp8860_driver = {
.driver = {
.name = "lp8860",
- .of_match_table = of_match_ptr(of_lp8860_leds_match),
+ .of_match_table = of_lp8860_leds_match,
},
.probe = lp8860_probe,
.remove = lp8860_remove,
@@ -482,4 +479,4 @@ module_i2c_driver(lp8860_driver);
MODULE_DESCRIPTION("Texas Instruments LP8860 LED driver");
MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* Re: [PATCH v4 3/3] dt-bindings: iio: temperature: add MLX90632 device bindings
From: Crt Mori @ 2017-12-12 19:19 UTC (permalink / raw)
To: Andreas Färber
Cc: Rob Herring, Jonathan Cameron, Linux Iio,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <13b298c0-d618-e217-406d-63bac56106fc-l3A5Bk7waGM@public.gmane.org>
On 12 December 2017 at 18:45, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
> Am 11.12.2017 um 10:20 schrieb Crt Mori:
>> Add device tree bindings for MLX90632 IR temperature sensor.
>>
>> Signed-off-by: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> .../bindings/iio/temperature/mlx90632.txt | 28 ++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
>> new file mode 100644
>> index 000000000000..0b05812001f8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
> [...]
>> +Example:
>> +
>> +mlx90632@3a {
>
> Shouldn't the node name be more general like temperature@3a?
>
None of the current temperature drivers have that, but it would be
nice for portability. I can prepare a patch to fix them all (a quick
check confirmed it is not consistent in pressure and light as well)
>> + compatible = "melexis,mlx90632";
>> + reg = <0x3a>;
>> +};
>
> Also generally the dt-bindings patch should go before the first use of
> the compatible string.
>
OK, will keep in mind in case of v5 to reorder the commits once again.
Best regards,
Crt
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813
From: Jonathan Cameron @ 2017-12-12 19:55 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <873410df-046e-bd86-584d-0d35b9d8c993-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 11 Dec 2017 09:35:43 +0100
Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Jonathan,
>
> On 10/12/2017 17:49, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 15:12:51 +0100
> > Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >
> >> The X-Powers AXP813 PMIC has got some slight differences from
> >> AXP20X/AXP22X PMICs:
> >> - the maximum voltage supplied by the PMIC is 4.35 instead of 4.36/4.24
> >> for AXP20X/AXP22X,
> >> - the constant charge current formula is different,
> >>
> >> It also has a bit to tell whether the battery percentage returned by the
> >> PMIC is valid.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >
> > I'd use switch statements when matching the IDs as that'll be more elegant
> > as you perhaps add further devices going forward...
> >
> > Other than that, looks good to me.
> >
>
> Well, I was wondering if it shouldn't be better to define a structure
> for each device containing their quirks, functions, etc... like it is
> done for the ADC or the ACIN power supply driver part.
>
Even better.
> struct axp20x_data {
> bool has_valid_fg_reg;
> void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val);
> void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val);
> int get_max_voltage(struct axp20x_batt_ps *axp, int *val);
> [...]
> };
>
> static const struct of_device_id axp20x_battery_ps_id[] = {
> { .compatible = "x-powers,axp209-battery-power-supply", .data = (void
> *)&axp209_data, }, {}
> };
>
> void probe()
> {
> [...]
> axp20x_batt->info = of_device_get_match_data(&pdev->dev);
> [...]
> }
>
> Sebastian, any objection on doing this?
>
> Thanks,
> Quentin
>
> > Jonathan
> >
> >> ---
> >> drivers/power/supply/axp20x_battery.c | 44 +++++++++++++++++++++++++++-
> >> 1 file changed, 43 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
> >> index 7494f0f..cb30302 100644
> >> --- a/drivers/power/supply/axp20x_battery.c
> >> +++ b/drivers/power/supply/axp20x_battery.c
> >> @@ -46,6 +46,8 @@
> >> #define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
> >> #define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
> >>
> >> +#define AXP813_CHRG_CTRL1_TGT_4_35V (3 << 5)
> >> +
> >> #define AXP22X_CHRG_CTRL1_TGT_4_22V (1 << 5)
> >> #define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
> >>
> >> @@ -123,10 +125,41 @@ static int axp22x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> >> return 0;
> >> }
> >>
> >> +static int axp813_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> >> + int *val)
> >> +{
> >> + int ret, reg;
> >> +
> >> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
> >
> > You could do a lookup based from a table instead which might
> > be ever so slightly more elegant..
> >
> >> + case AXP20X_CHRG_CTRL1_TGT_4_1V:
> >> + *val = 4100000;
> >> + break;
> >> + case AXP20X_CHRG_CTRL1_TGT_4_15V:
> >> + *val = 4150000;
> >> + break;
> >> + case AXP20X_CHRG_CTRL1_TGT_4_2V:
> >> + *val = 4200000;
> >> + break;
> >> + case AXP813_CHRG_CTRL1_TGT_4_35V:
> >> + *val = 4350000;
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> static void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val)
> >> {
> >> if (axp->axp_id == AXP209_ID)
> >> *val = *val * 100000 + 300000;
> >> + else if (axp->axp_id == AXP813_ID)
> >> + *val = *val * 200000 + 200000;
> >> else
> >> *val = *val * 150000 + 300000;
> >
> > Switch?
> >
> >> }
> >> @@ -135,6 +168,8 @@ static void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val)
> >> {
> >> if (axp->axp_id == AXP209_ID)
> >> *val = (*val - 300000) / 100000;
> >> + else if (axp->axp_id == AXP813_ID)
> >> + *val = (*val - 200000) / 200000;
> >> else
> >> *val = (*val - 300000) / 150000;
> >> }
> >> @@ -269,7 +304,8 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> >> if (ret)
> >> return ret;
> >>
> >> - if (axp20x_batt->axp_id == AXP221_ID &&
> >> + if ((axp20x_batt->axp_id == AXP221_ID ||
> >> + axp20x_batt->axp_id == AXP813_ID) &&
> >> !(reg & AXP22X_FG_VALID))
> >> return -EINVAL;
> >>
> >> @@ -284,6 +320,9 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> >> if (axp20x_batt->axp_id == AXP209_ID)
> >> return axp20x_battery_get_max_voltage(axp20x_batt,
> >> &val->intval);
> >> + else if (axp20x_batt->axp_id == AXP813_ID)
> >> + return axp813_battery_get_max_voltage(axp20x_batt,
> >> + &val->intval);
> >> return axp22x_battery_get_max_voltage(axp20x_batt,
> >> &val->intval);
> >
> > Worth converting to a switch statement to make it more elegant for future
> > devices?
> >
> >>
> >> @@ -467,6 +506,9 @@ static const struct of_device_id axp20x_battery_ps_id[] = {
> >> }, {
> >> .compatible = "x-powers,axp221-battery-power-supply",
> >> .data = (void *)AXP221_ID,
> >> + }, {
> >> + .compatible = "x-powers,axp813-battery-power-supply",
> >> + .data = (void *)AXP813_ID,
> >> }, { /* sentinel */ },
> >> };
> >> MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
> >
>
^ permalink raw reply
* Re: [RFC 0/5] Add I3C subsystem
From: Boris Brezillon @ 2017-12-12 19:58 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
In-Reply-To: <20170731191745.GB1542@katana>
On Mon, 31 Jul 2017 21:17:45 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> Hi Boris,
>
> > This patch series is a proposal for a new I3C [1] subsystem.
>
> Nice. Good luck with that!
>
> Some hi-level comments from me related to I2C. I can't say a lot more
> because the specs are not public :(
>
> > - the bus element is a separate object and is not implicitly described
> > by the master (as done in I2C). The reason is that I want to be able
> > to handle multiple master connected to the same bus and visible to
> > Linux.
> > In this situation, we should only have one instance of the device and
> > not one per master, and sharing the bus object would be part of the
> > solution to gracefully handle this case.
> > I'm not sure if we will ever need to deal with multiple masters
> > controlling the same bus and exposed under Linux, but separating the
> > bus and master concept is pretty easy, hence the decision to do it
> > now, just in case we need it some day.
>
> From my experience, it is a good thing to have this separation.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
>
> I agree this is the least invasive and also the most compatible
> approach. The other solution would probably be to have some kind of
> emulation layer?
>
> > I'd also like to get feedback on the doc. Should I detail a bit more
> > the protocol or the framework API? Is this the kind of things you
> > expect in a subsystem doc?
>
> Since the spec is not public, details about the protocol will be
> especially useful, I'd say.
MIPI has opened the I3C spec [1], it can be downloaded here [2].
v2 of this series will come soon (sorry for the delay).
Regards,
Boris
[1]https://www.businesswire.com/news//home/20171212005059/en/MIPI-Alliance-Opens-Access-MIPI-I3C-Sensor
[2]http://resources.mipi.org/mipi-i3c-v1-download
^ permalink raw reply
* Re: [PATCH v2 1/2] Documentation: devicetree: Add DT bindings to xlnx_vcu driver
From: Rob Herring @ 2017-12-12 20:07 UTC (permalink / raw)
To: Dhaval Shah
Cc: arnd-r2nGTMty4D4, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
pombredanne-od1rfyK75/E, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA, hyunk-gjFFaj9aHVfQT0dZR+AlfA,
Dhaval Shah
In-Reply-To: <1512682276-6082-2-git-send-email-dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
On Thu, Dec 07, 2017 at 01:31:15PM -0800, Dhaval Shah wrote:
> Add Device Tree binding document for logicoreIP. This logicoreIP
> provides the isolation between the processing system and
> programmable logic. Also provides the clock related information.
>
> Signed-off-by: Dhaval Shah <dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> ---
> Changes since v2:
> * Describe the h/w
> * compatible string is updated to make it more specific
> based on the logicoreIP version.
> * Removed that encoder and decoder child nodes and relatd properties as that
> will be a separate driver and dts nodes. other team is working on that.
> * Updated to use as a single driver.
>
> .../devicetree/bindings/misc/xlnx,vcu.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
One nit. Use "dt-bindings: misc: ..." for the subject.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: Add optional nvmem BD address bindings to ti,wlink-st
From: Rob Herring @ 2017-12-12 20:09 UTC (permalink / raw)
To: David Lechner
Cc: devicetree, linux-bluetooth, Mark Rutland, Marcel Holtmann,
Gustavo Padovan, Johan Hedberg, netdev, linux-kernel
In-Reply-To: <1512701860-8321-3-git-send-email-david@lechnology.com>
On Thu, Dec 07, 2017 at 08:57:39PM -0600, David Lechner wrote:
> This adds optional nvmem consumer properties to the ti,wlink-st device tree
> bindings to allow specifying the BD address.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v2 changes:
> * Renamed "mac-address" to "bd-address"
> * Fixed typos in example
> * Specify byte order of "bd-address"
>
> Documentation/devicetree/bindings/net/ti,wilink-st.txt | 5 +++++
> 1 file changed, 5 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 29/33] dt-bindings: nds32 CPU Bindings
From: Rob Herring @ 2017-12-12 20:10 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, netdev, deanbo422, devicetree, viro, dhowells,
will.deacon, daniel.lezcano, linux-serial, geert.uytterhoeven,
linus.walleij, mark.rutland, greg, Vincent Chen, Rick Chen,
Zong Li
In-Reply-To: <b082ead87b647f6f0797e51d3ceeaf6c87038dd1.1512723245.git.green.hu@gmail.com>
On Fri, Dec 08, 2017 at 05:12:12PM +0800, Greentime Hu wrote:
> From: Greentime Hu <greentime@andestech.com>
>
> This patch adds nds32 CPU binding documents.
>
> Signed-off-by: Vincent Chen <vincentc@andestech.com>
> Signed-off-by: Rick Chen <rick@andestech.com>
> Signed-off-by: Zong Li <zong@andestech.com>
> Signed-off-by: Greentime Hu <greentime@andestech.com>
> ---
> Documentation/devicetree/bindings/nds32/cpus.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nds32/cpus.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 30/33] dt-bindings: nds32 SoC Bindings
From: Rob Herring @ 2017-12-12 20:12 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, netdev, deanbo422, devicetree, viro, dhowells,
will.deacon, daniel.lezcano, linux-serial, geert.uytterhoeven,
linus.walleij, mark.rutland, greg
In-Reply-To: <4c33141ec34c73abe4a9106cbe71f2a97621958e.1512723245.git.green.hu@gmail.com>
On Fri, Dec 08, 2017 at 05:12:13PM +0800, Greentime Hu wrote:
> From: Greentime Hu <greentime@andestech.com>
>
> This patch adds nds32 SoC(AE3XX and AG101P) binding documents.
>
> Signed-off-by: Greentime Hu <greentime@andestech.com>
> ---
> .../devicetree/bindings/nds32/andestech-boards | 40 ++++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nds32/andestech-boards
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] PCI: qcom: add missing supplies required for msm8996
From: Rob Herring @ 2017-12-12 20:17 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: stanimir.varbanov, Stanimir Varbanov, linux-pci, bhelgaas,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20171208092053.4417-1-srinivas.kandagatla@linaro.org>
On Fri, Dec 08, 2017 at 09:20:53AM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> This patch adds supplies that are required for msm8996. Two of them vdda
> and vdda-1p8 are analog supplies that go in to controller, and the rest
> of the two vddpe's are supplies to PCIe endpoints.
>
> Without these supplies PCIe endpoints which require power supplies are
> not enumerated at all, as there is no one to power it up.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../devicetree/bindings/pci/qcom,pcie.txt | 16 +++++++++++++
> drivers/pci/dwc/pcie-qcom.c | 28 ++++++++++++++++++++--
> 2 files changed, 42 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-12 20:27 UTC (permalink / raw)
To: Andy Shevchenko, Linus Walleij,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
Cc: linux-arm-msm, Linux ARM, linux-gpio, Mika Westerberg,
thierry.reding@gmail.com, Stephen Boyd, David Brown, Andy Gross,
Bjorn Andersson, Varadarajan Narayanan, Archit Taneja
In-Reply-To: <1513076836.25007.641.camel@linux.intel.com>
On 12/12/2017 05:07 AM, Andy Shevchenko wrote:
> Not ACPI standards as of my knowledge. ACPI standard defines a common
> scheme how to define properties, it doesn't tell anything about property
> names or any mappings between names to values or names to "OS
> subsystem").
There was an attempt a while back to standardize this like we do for
device tree, but it fell apart. Device-specific ACPI-only properties
are not standarized. This driver is initialized only on ACPI systems.
It has no device tree binding.
> As for GPIO we just follow *de facto* what DT has right now, i.e. "xxx-
> gpio" or "xxx-gpios" pattern is used to map ACPI standard resource to a
> GPIO name. That's how GPIO ACPI lib is being developed.
GPIOs in device tree are defined completely differently than in ACPI.
On DT, the kernel controls the pin muxing. On ACPI, pins are muxed by
firmware and never re-muxed by the operating system. So all this driver
does is expose a few pins as simple GPIOs.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v8 10/13] IIO: ADC: add stm32 DFSDM support for PDM microphone
From: Jonathan Cameron @ 2017-12-12 20:27 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
Liam Girdwood, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
Alexandre Torgue
In-Reply-To: <1512987524-2901-11-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
On Mon, 11 Dec 2017 11:18:41 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:
> This code offers a way to handle PDM audio microphones in
> ASOC framework. Audio driver should use consumer API.
> A specific management is implemented for DMA, with a
> callback, to allows to handle audio buffers efficiently.
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
Hi Arnaud,
I raise a few queries on v7 of this patch.
https://marc.info/?l=linux-iio&m=151292965915376&w=2
Jonathan
> ---
> .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 16 +
> drivers/iio/adc/stm32-dfsdm-adc.c | 508 ++++++++++++++++++++-
> include/linux/iio/adc/stm32-dfsdm-adc.h | 18 +
> 3 files changed, 534 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> new file mode 100644
> index 0000000..da98223
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> @@ -0,0 +1,16 @@
> +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_spi_clk_freq
> +KernelVersion: 4.14
> +Contact: arnaud.pouliquen-qxv4g6HH51o@public.gmane.org
> +Description:
> + For audio purpose only.
> + Used by audio driver to set/get the spi input frequency.
> + This is mandatory if DFSDM is slave on SPI bus, to
> + provide information on the SPI clock frequency during runtime
> + Notice that the SPI frequency should be a multiple of sample
> + frequency to ensure the precision.
> + if DFSDM input is SPI master
> + Reading SPI clkout frequency,
> + error on writing
> + If DFSDM input is SPI Slave:
> + Reading returns value previously set.
> + Writing value before starting conversions.
> \ No newline at end of file
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
> index 68b5920..2d6aed5 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -6,19 +6,25 @@
> * Author: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>.
> */
>
> +#include <linux/dmaengine.h>
> +#include <linux/dma-mapping.h>
> #include <linux/interrupt.h>
> #include <linux/iio/buffer.h>
> #include <linux/iio/hw-consumer.h>
> #include <linux/iio/iio.h>
> #include <linux/iio/sysfs.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> #include <linux/module.h>
> -#include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> #include <linux/slab.h>
>
> #include "stm32-dfsdm.h"
>
> +#define DFSDM_DMA_BUFFER_SIZE (4 * PAGE_SIZE)
> +
> /* Conversion timeout */
> #define DFSDM_TIMEOUT_US 100000
> #define DFSDM_TIMEOUT (msecs_to_jiffies(DFSDM_TIMEOUT_US / 1000))
> @@ -58,6 +64,18 @@ struct stm32_dfsdm_adc {
> struct completion completion;
> u32 *buffer;
>
> + /* Audio specific */
> + unsigned int spi_freq; /* SPI bus clock frequency */
> + unsigned int sample_freq; /* Sample frequency after filter decimation */
> + int (*cb)(const void *data, size_t size, void *cb_priv);
> + void *cb_priv;
> +
> + /* DMA */
> + u8 *rx_buf;
> + unsigned int bufi; /* Buffer current position */
> + unsigned int buf_sz; /* Buffer size */
> + struct dma_chan *dma_chan;
> + dma_addr_t dma_buf;
> };
>
> struct stm32_dfsdm_str2field {
> @@ -351,10 +369,63 @@ int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
> return 0;
> }
>
> +static ssize_t dfsdm_adc_audio_get_spiclk(struct iio_dev *indio_dev,
> + uintptr_t priv,
> + const struct iio_chan_spec *chan,
> + char *buf)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> +
> + return snprintf(buf, PAGE_SIZE, "%d\n", adc->spi_freq);
> +}
> +
> +static ssize_t dfsdm_adc_audio_set_spiclk(struct iio_dev *indio_dev,
> + uintptr_t priv,
> + const struct iio_chan_spec *chan,
> + const char *buf, size_t len)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id];
> + struct stm32_dfsdm_channel *ch = &adc->dfsdm->ch_list[adc->ch_id];
> + unsigned int sample_freq = adc->sample_freq;
> + unsigned int spi_freq;
> + int ret;
> +
> + dev_err(&indio_dev->dev, "enter %s\n", __func__);
> + /* If DFSDM is master on SPI, SPI freq can not be updated */
> + if (ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
> + return -EPERM;
> +
> + ret = kstrtoint(buf, 0, &spi_freq);
> + if (ret)
> + return ret;
> +
> + if (!spi_freq)
> + return -EINVAL;
> +
> + if (sample_freq) {
> + if (spi_freq % sample_freq)
> + dev_warn(&indio_dev->dev,
> + "Sampling rate not accurate (%d)\n",
> + spi_freq / (spi_freq / sample_freq));
> +
> + ret = stm32_dfsdm_set_osrs(fl, 0, (spi_freq / sample_freq));
> + if (ret < 0) {
> + dev_err(&indio_dev->dev,
> + "No filter parameters that match!\n");
> + return ret;
> + }
> + }
> + adc->spi_freq = spi_freq;
> +
> + return len;
> +}
> +
> static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc, bool dma)
> {
> struct regmap *regmap = adc->dfsdm->regmap;
> int ret;
> + unsigned int dma_en = 0, cont_en = 0;
>
> ret = stm32_dfsdm_start_channel(adc->dfsdm, adc->ch_id);
> if (ret < 0)
> @@ -365,6 +436,24 @@ static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc, bool dma)
> if (ret < 0)
> goto stop_channels;
>
> + if (dma) {
> + /* Enable DMA transfer*/
> + dma_en = DFSDM_CR1_RDMAEN(1);
> + /* Enable conversion triggered by SPI clock*/
> + cont_en = DFSDM_CR1_RCONT(1);
> + }
> + /* Enable DMA transfer*/
> + ret = regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
> + DFSDM_CR1_RDMAEN_MASK, dma_en);
> + if (ret < 0)
> + goto stop_channels;
> +
> + /* Enable conversion triggered by SPI clock*/
> + ret = regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
> + DFSDM_CR1_RCONT_MASK, cont_en);
> + if (ret < 0)
> + goto stop_channels;
> +
> ret = stm32_dfsdm_start_filter(adc->dfsdm, adc->fl_id);
> if (ret < 0)
> goto stop_channels;
> @@ -398,6 +487,231 @@ static void stm32_dfsdm_stop_conv(struct stm32_dfsdm_adc *adc)
> stm32_dfsdm_stop_channel(adc->dfsdm, adc->ch_id);
> }
>
> +static int stm32_dfsdm_set_watermark(struct iio_dev *indio_dev,
> + unsigned int val)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + unsigned int watermark = DFSDM_DMA_BUFFER_SIZE / 2;
> +
> + /*
> + * DMA cyclic transfers are used, buffer is split into two periods.
> + * There should be :
> + * - always one buffer (period) DMA is working on
> + * - one buffer (period) driver pushed to ASoC side.
> + */
> + watermark = min(watermark, val * (unsigned int)(sizeof(u32)));
> + adc->buf_sz = watermark * 2;
> +
> + return 0;
> +}
> +
> +static unsigned int stm32_dfsdm_adc_dma_residue(struct stm32_dfsdm_adc *adc)
> +{
> + struct dma_tx_state state;
> + enum dma_status status;
> +
> + status = dmaengine_tx_status(adc->dma_chan,
> + adc->dma_chan->cookie,
> + &state);
> + if (status == DMA_IN_PROGRESS) {
> + /* Residue is size in bytes from end of buffer */
> + unsigned int i = adc->buf_sz - state.residue;
> + unsigned int size;
> +
> + /* Return available bytes */
> + if (i >= adc->bufi)
> + size = i - adc->bufi;
> + else
> + size = adc->buf_sz + i - adc->bufi;
> +
> + return size;
> + }
> +
> + return 0;
> +}
> +
> +static void stm32_dfsdm_audio_dma_buffer_done(void *data)
> +{
> + struct iio_dev *indio_dev = data;
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + int available = stm32_dfsdm_adc_dma_residue(adc);
> + size_t old_pos;
> +
> + /*
> + * FIXME: In Kernel interface does not support cyclic DMA buffer,and
> + * offers only an interface to push data samples per samples.
> + * For this reason IIO buffer interface is not used and interface is
> + * bypassed using a private callback registered by ASoC.
> + * This should be a temporary solution waiting a cyclic DMA engine
> + * support in IIO.
> + */
> +
> + dev_dbg(&indio_dev->dev, "%s: pos = %d, available = %d\n", __func__,
> + adc->bufi, available);
> + old_pos = adc->bufi;
> +
> + while (available >= indio_dev->scan_bytes) {
> + u32 *buffer = (u32 *)&adc->rx_buf[adc->bufi];
> +
> + /* Mask 8 LSB that contains the channel ID */
> + *buffer = (*buffer & 0xFFFFFF00) << 8;
> + available -= indio_dev->scan_bytes;
> + adc->bufi += indio_dev->scan_bytes;
> + if (adc->bufi >= adc->buf_sz) {
> + if (adc->cb)
> + adc->cb(&adc->rx_buf[old_pos],
> + adc->buf_sz - old_pos, adc->cb_priv);
> + adc->bufi = 0;
> + old_pos = 0;
> + }
> + }
> + if (adc->cb)
> + adc->cb(&adc->rx_buf[old_pos], adc->bufi - old_pos,
> + adc->cb_priv);
> +}
> +
> +static int stm32_dfsdm_adc_dma_start(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct dma_async_tx_descriptor *desc;
> + dma_cookie_t cookie;
> + int ret;
> +
> + if (!adc->dma_chan)
> + return -EINVAL;
> +
> + dev_dbg(&indio_dev->dev, "%s size=%d watermark=%d\n", __func__,
> + adc->buf_sz, adc->buf_sz / 2);
> +
> + /* Prepare a DMA cyclic transaction */
> + desc = dmaengine_prep_dma_cyclic(adc->dma_chan,
> + adc->dma_buf,
> + adc->buf_sz, adc->buf_sz / 2,
> + DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT);
> + if (!desc)
> + return -EBUSY;
> +
> + desc->callback = stm32_dfsdm_audio_dma_buffer_done;
> + desc->callback_param = indio_dev;
> +
> + cookie = dmaengine_submit(desc);
> + ret = dma_submit_error(cookie);
> + if (ret) {
> + dmaengine_terminate_all(adc->dma_chan);
> + return ret;
> + }
> +
> + /* Issue pending DMA requests */
> + dma_async_issue_pending(adc->dma_chan);
> +
> + return 0;
> +}
> +
> +static int stm32_dfsdm_postenable(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + /* Reset adc buffer index */
> + adc->bufi = 0;
> +
> + ret = stm32_dfsdm_start_dfsdm(adc->dfsdm);
> + if (ret < 0)
> + return ret;
> +
> + ret = stm32_dfsdm_start_conv(adc, true);
> + if (ret) {
> + dev_err(&indio_dev->dev, "Can't start conversion\n");
> + goto stop_dfsdm;
> + }
> +
> + if (adc->dma_chan) {
> + ret = stm32_dfsdm_adc_dma_start(indio_dev);
> + if (ret) {
> + dev_err(&indio_dev->dev, "Can't start DMA\n");
> + goto err_stop_conv;
> + }
> + }
> +
> + return 0;
> +
> +err_stop_conv:
> + stm32_dfsdm_stop_conv(adc);
> +stop_dfsdm:
> + stm32_dfsdm_stop_dfsdm(adc->dfsdm);
> +
> + return ret;
> +}
> +
> +static int stm32_dfsdm_predisable(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> +
> + if (adc->dma_chan)
> + dmaengine_terminate_all(adc->dma_chan);
> +
> + stm32_dfsdm_stop_conv(adc);
> +
> + stm32_dfsdm_stop_dfsdm(adc->dfsdm);
> +
> + return 0;
> +}
> +
> +static const struct iio_buffer_setup_ops stm32_dfsdm_buffer_setup_ops = {
> + .postenable = &stm32_dfsdm_postenable,
> + .predisable = &stm32_dfsdm_predisable,
> +};
> +
> +/**
> + * stm32_dfsdm_get_buff_cb() - register a callback that will be called when
> + * DMA transfer period is achieved.
> + *
> + * @iio_dev: Handle to IIO device.
> + * @cb: Pointer to callback function:
> + * - data: pointer to data buffer
> + * - size: size in byte of the data buffer
> + * - private: pointer to consumer private structure.
> + * @private: Pointer to consumer private structure.
> + */
> +int stm32_dfsdm_get_buff_cb(struct iio_dev *iio_dev,
> + int (*cb)(const void *data, size_t size,
> + void *private),
> + void *private)
> +{
> + struct stm32_dfsdm_adc *adc;
> +
> + if (!iio_dev)
> + return -EINVAL;
> + adc = iio_priv(iio_dev);
> +
> + adc->cb = cb;
> + adc->cb_priv = private;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(stm32_dfsdm_get_buff_cb);
> +
> +/**
> + * stm32_dfsdm_release_buff_cb - unregister buffer callback
> + *
> + * @iio_dev: Handle to IIO device.
> + */
> +int stm32_dfsdm_release_buff_cb(struct iio_dev *iio_dev)
> +{
> + struct stm32_dfsdm_adc *adc;
> +
> + if (!iio_dev)
> + return -EINVAL;
> + adc = iio_priv(iio_dev);
> +
> + adc->cb = NULL;
> + adc->cb_priv = NULL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(stm32_dfsdm_release_buff_cb);
> +
> static int stm32_dfsdm_single_conv(struct iio_dev *indio_dev,
> const struct iio_chan_spec *chan, int *res)
> {
> @@ -453,15 +767,41 @@ static int stm32_dfsdm_write_raw(struct iio_dev *indio_dev,
> {
> struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id];
> + struct stm32_dfsdm_channel *ch = &adc->dfsdm->ch_list[adc->ch_id];
> + unsigned int spi_freq = adc->spi_freq;
> int ret = -EINVAL;
>
> - if (mask == IIO_CHAN_INFO_OVERSAMPLING_RATIO) {
> + switch (mask) {
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> ret = stm32_dfsdm_set_osrs(fl, 0, val);
> if (!ret)
> adc->oversamp = val;
> +
> + return ret;
> +
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + if (!val)
> + return -EINVAL;
> + if (ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
> + spi_freq = adc->dfsdm->spi_master_freq;
> +
> + if (spi_freq % val)
> + dev_warn(&indio_dev->dev,
> + "Sampling rate not accurate (%d)\n",
> + spi_freq / (spi_freq / val));
> +
> + ret = stm32_dfsdm_set_osrs(fl, 0, (spi_freq / val));
> + if (ret < 0) {
> + dev_err(&indio_dev->dev,
> + "Not able to find parameter that match!\n");
> + return ret;
> + }
> + adc->sample_freq = val;
> +
> + return 0;
> }
>
> - return ret;
> + return -EINVAL;
> }
>
> static int stm32_dfsdm_read_raw(struct iio_dev *indio_dev,
> @@ -494,11 +834,22 @@ static int stm32_dfsdm_read_raw(struct iio_dev *indio_dev,
> *val = adc->oversamp;
>
> return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *val = adc->sample_freq;
> +
> + return IIO_VAL_INT;
> }
>
> return -EINVAL;
> }
>
> +static const struct iio_info stm32_dfsdm_info_audio = {
> + .hwfifo_set_watermark = stm32_dfsdm_set_watermark,
> + .read_raw = stm32_dfsdm_read_raw,
> + .write_raw = stm32_dfsdm_write_raw,
> +};
> +
> static const struct iio_info stm32_dfsdm_info_adc = {
> .read_raw = stm32_dfsdm_read_raw,
> .write_raw = stm32_dfsdm_write_raw,
> @@ -531,6 +882,60 @@ static irqreturn_t stm32_dfsdm_irq(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> +/*
> + * Define external info for SPI Frequency and audio sampling rate that can be
> + * configured by ASoC driver through consumer.h API
> + */
> +static const struct iio_chan_spec_ext_info dfsdm_adc_audio_ext_info[] = {
> + /* spi_clk_freq : clock freq on SPI/manchester bus used by channel */
> + {
> + .name = "spi_clk_freq",
> + .shared = IIO_SHARED_BY_TYPE,
> + .read = dfsdm_adc_audio_get_spiclk,
> + .write = dfsdm_adc_audio_set_spiclk,
> + },
> + {},
> +};
> +
> +static int stm32_dfsdm_dma_request(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct dma_slave_config config;
> + int ret;
> +
> + adc->dma_chan = dma_request_slave_channel(&indio_dev->dev, "rx");
> + if (!adc->dma_chan)
> + return -EINVAL;
> +
> + adc->rx_buf = dma_alloc_coherent(adc->dma_chan->device->dev,
> + DFSDM_DMA_BUFFER_SIZE,
> + &adc->dma_buf, GFP_KERNEL);
> + if (!adc->rx_buf) {
> + ret = -ENOMEM;
> + goto err_release;
> + }
> +
> + /* Configure DMA channel to read data register */
> + memset(&config, 0, sizeof(config));
> + config.src_addr = (dma_addr_t)adc->dfsdm->phys_base;
> + config.src_addr += DFSDM_RDATAR(adc->fl_id);
> + config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> +
> + ret = dmaengine_slave_config(adc->dma_chan, &config);
> + if (ret)
> + goto err_free;
> +
> + return 0;
> +
> +err_free:
> + dma_free_coherent(adc->dma_chan->device->dev, DFSDM_DMA_BUFFER_SIZE,
> + adc->rx_buf, adc->dma_buf);
> +err_release:
> + dma_release_channel(adc->dma_chan);
> +
> + return ret;
> +}
> +
> static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
> struct iio_chan_spec *ch)
> {
> @@ -551,7 +956,12 @@ static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
> ch->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
> ch->info_mask_shared_by_all = BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO);
>
> - ch->scan_type.sign = 'u';
> + if (adc->dev_data->type == DFSDM_AUDIO) {
> + ch->scan_type.sign = 's';
> + ch->ext_info = dfsdm_adc_audio_ext_info;
> + } else {
> + ch->scan_type.sign = 'u';
> + }
> ch->scan_type.realbits = 24;
> ch->scan_type.storagebits = 32;
> adc->ch_id = ch->channel;
> @@ -560,6 +970,64 @@ static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
> &adc->dfsdm->ch_list[ch->channel]);
> }
>
> +static int stm32_dfsdm_audio_init(struct iio_dev *indio_dev)
> +{
> + struct iio_chan_spec *ch;
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct stm32_dfsdm_channel *d_ch;
> + int ret;
> +
> + ret = stm32_dfsdm_dma_request(indio_dev);
> + if (ret) {
> + dev_err(&indio_dev->dev, "DMA request failed\n");
> + return ret;
> + }
> +
> + indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
> +
> + ret = iio_triggered_buffer_setup(indio_dev,
> + &iio_pollfunc_store_time,
> + NULL,
> + &stm32_dfsdm_buffer_setup_ops);
> + if (ret) {
> + dev_err(&indio_dev->dev, "Buffer setup failed\n");
> + goto err_dma_disable;
> + }
> +
> + ch = devm_kzalloc(&indio_dev->dev, sizeof(*ch), GFP_KERNEL);
> + if (!ch)
> + return -ENOMEM;
> +
> + ch->scan_index = 0;
> + ret = stm32_dfsdm_adc_chan_init_one(indio_dev, ch);
> + if (ret < 0) {
> + dev_err(&indio_dev->dev, "channels init failed\n");
> + goto err_buffer_cleanup;
> + }
> + ch->info_mask_separate = BIT(IIO_CHAN_INFO_SAMP_FREQ);
> +
> + d_ch = &adc->dfsdm->ch_list[adc->ch_id];
> + if (d_ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
> + adc->spi_freq = adc->dfsdm->spi_master_freq;
> +
> + indio_dev->num_channels = 1;
> + indio_dev->channels = ch;
> +
> + return 0;
> +
> +err_buffer_cleanup:
> + iio_triggered_buffer_cleanup(indio_dev);
> +
> +err_dma_disable:
> + if (adc->dma_chan) {
> + dma_free_coherent(adc->dma_chan->device->dev,
> + DFSDM_DMA_BUFFER_SIZE,
> + adc->rx_buf, adc->dma_buf);
> + dma_release_channel(adc->dma_chan);
> + }
> + return ret;
> +}
> +
> static int stm32_dfsdm_adc_init(struct iio_dev *indio_dev)
> {
> struct iio_chan_spec *ch;
> @@ -612,11 +1080,20 @@ static const struct stm32_dfsdm_dev_data stm32h7_dfsdm_adc_data = {
> .init = stm32_dfsdm_adc_init,
> };
>
> +static const struct stm32_dfsdm_dev_data stm32h7_dfsdm_audio_data = {
> + .type = DFSDM_AUDIO,
> + .init = stm32_dfsdm_audio_init,
> +};
> +
> static const struct of_device_id stm32_dfsdm_adc_match[] = {
> {
> .compatible = "st,stm32-dfsdm-adc",
> .data = &stm32h7_dfsdm_adc_data,
> },
> + {
> + .compatible = "st,stm32-dfsdm-dmic",
> + .data = &stm32h7_dfsdm_audio_data,
> + },
> {}
> };
>
> @@ -667,8 +1144,13 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
> name = devm_kzalloc(dev, sizeof("dfsdm-adc0"), GFP_KERNEL);
> if (!name)
> return -ENOMEM;
> - iio->info = &stm32_dfsdm_info_adc;
> - snprintf(name, sizeof("dfsdm-adc0"), "dfsdm-adc%d", adc->fl_id);
> + if (dev_data->type == DFSDM_AUDIO) {
> + iio->info = &stm32_dfsdm_info_audio;
> + snprintf(name, sizeof("dfsdm-pdm0"), "dfsdm-pdm%d", adc->fl_id);
> + } else {
> + iio->info = &stm32_dfsdm_info_adc;
> + snprintf(name, sizeof("dfsdm-adc0"), "dfsdm-adc%d", adc->fl_id);
> + }
> iio->name = name;
>
> /*
> @@ -700,7 +1182,10 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> - return iio_device_register(iio);
> + iio_device_register(iio);
> + if (dev_data->type == DFSDM_AUDIO)
> + return devm_of_platform_populate(&pdev->dev);
> + return 0;
> }
>
> static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
> @@ -709,7 +1194,14 @@ static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
> struct iio_dev *indio_dev = iio_priv_to_dev(adc);
>
> iio_device_unregister(indio_dev);
> -
> + if (indio_dev->pollfunc)
> + iio_triggered_buffer_cleanup(indio_dev);
> + if (adc->dma_chan) {
> + dma_free_coherent(adc->dma_chan->device->dev,
> + DFSDM_DMA_BUFFER_SIZE,
> + adc->rx_buf, adc->dma_buf);
> + dma_release_channel(adc->dma_chan);
> + }
> return 0;
> }
>
> diff --git a/include/linux/iio/adc/stm32-dfsdm-adc.h b/include/linux/iio/adc/stm32-dfsdm-adc.h
> new file mode 100644
> index 0000000..e7dc7a5
> --- /dev/null
> +++ b/include/linux/iio/adc/stm32-dfsdm-adc.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * This file discribe the STM32 DFSDM IIO driver API for audio part
> + *
> + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
> + * Author(s): Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>.
> + */
> +
> +#ifndef STM32_DFSDM_ADC_H
> +#define STM32_DFSDM_ADC_H
> +
> +int stm32_dfsdm_get_buff_cb(struct iio_dev *iio_dev,
> + int (*cb)(const void *data, size_t size,
> + void *private),
> + void *private);
> +int stm32_dfsdm_release_buff_cb(struct iio_dev *iio_dev);
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v4 04/12] clk: qcom: Add HFPLL driver
From: Rob Herring @ 2017-12-12 20:35 UTC (permalink / raw)
To: Sricharan R
Cc: mturquette, sboyd, devicetree, linux-pm, linux-arm-msm,
linux-kernel, viresh.kumar, linux-arm-kernel
In-Reply-To: <1512726150-7204-5-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 08, 2017 at 03:12:22PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> On some devices (MSM8974 for example), the HFPLLs are
> instantiated within the Krait processor subsystem as separate
> register regions. Add a driver for these PLLs so that we can
> provide HFPLL clocks for use by the system.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,hfpll.txt | 40 ++++++++
> drivers/clk/qcom/Kconfig | 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/hfpll.c | 106 +++++++++++++++++++++
> 4 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> create mode 100644 drivers/clk/qcom/hfpll.c
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> new file mode 100644
> index 0000000..fee92bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> @@ -0,0 +1,40 @@
> +High-Frequency PLL (HFPLL)
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: must be "qcom,hfpll"
Fine for a fallback, but please add SoC specific compatibles.
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: address and size of HPLL registers. An optional second
> + element specifies the address and size of the alias
> + register region.
> +
> +- clock-output-names:
> + Usage: required
> + Value type: <string>
> + Definition: Name of the PLL. Typically hfpllX where X is a CPU number
> + starting at 0. Otherwise hfpll_Y where Y is more specific
> + such as "l2".
> +
> +Example:
> +
> +1) An HFPLL for the L2 cache.
> +
> + clock-controller@f9016000 {
> + compatible = "qcom,hfpll";
> + reg = <0xf9016000 0x30>;
> + clock-output-names = "hfpll_l2";
> + };
> +
> +2) An HFPLL for CPU0. This HFPLL has the alias register region.
> +
> + clock-controller@f908a000 {
> + compatible = "qcom,hfpll";
> + reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
> + clock-output-names = "hfpll0";
> + };
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 20b5d6f..6c811bd 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -205,3 +205,11 @@ config SPMI_PMIC_CLKDIV
> Technologies, Inc. SPMI PMIC. It configures the frequency of
> clkdiv outputs of the PMIC. These clocks are typically wired
> through alternate functions on GPIO pins.
> +
> +config QCOM_HFPLL
> + tristate "High-Frequency PLL (HFPLL) Clock Controller"
> + depends on COMMON_CLK_QCOM
> + help
> + Support for the high-frequency PLLs present on Qualcomm devices.
> + Say Y if you want to support CPU frequency scaling on devices
> + such as MSM8974, APQ8084, etc.
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 4795e21..4a4bf38 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -36,3 +36,4 @@ obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
> +obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
> new file mode 100644
> index 0000000..7405bb6
> --- /dev/null
> +++ b/drivers/clk/qcom/hfpll.c
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
It's 2017.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only 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.
Use SPDX tags.
Rob
^ permalink raw reply
* Re: [PATCH v4 05/12] clk: qcom: Add MSM8960/APQ8064's HFPLLs
From: Rob Herring @ 2017-12-12 20:36 UTC (permalink / raw)
To: Sricharan R
Cc: mturquette, sboyd, devicetree, linux-pm, linux-arm-msm,
linux-kernel, viresh.kumar, linux-arm-kernel
In-Reply-To: <1512726150-7204-6-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 08, 2017 at 03:12:23PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> Describe the HFPLLs present on MSM8960 and APQ8064 devices.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> drivers/clk/qcom/gcc-msm8960.c | 172 +++++++++++++++++++++++++++
> include/dt-bindings/clock/qcom,gcc-msm8960.h | 2 +
For the binding,
Acked-by: Rob Herring <robh@kernel.org>
> 2 files changed, 174 insertions(+)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox