* [PATCH v2 8/9] ARM: dts: imx7-colibri: add MCP2515 CAN controller
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo, kernel
Cc: fabio.estevam, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel, Stefan Agner
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The Colibri Evaluation Carrier Board provides a MCP2515 CAN
controller connected via SPI. Note that the i.MX 7 provides
an internal CAN controller which is much better suited for CAN
operations. Using the MCP2515 with a Colibri iMX7 module is
mainly useful to test the SPI interface.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Changes since v1:
- Changed label and node name for MCP2515
- Drop num-cs from ecspi3
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 25 +++++++++++++++++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 13 ++++++++++++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 87c23b769a08..e2b99bb48250 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -45,6 +45,13 @@
stdout-path = "serial0:115200n8";
};
+ /* fixed crystal dedicated to mpc258x */
+ clk16m: clk16m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ };
+
panel: panel {
compatible = "edt,et057090dhu";
backlight = <&bl>;
@@ -99,6 +106,24 @@
status = "okay";
};
+&ecspi3 {
+ status = "okay";
+
+ mcp2515: can@0 {
+ compatible = "microchip,mcp2515";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can_int>;
+ reg = <0>;
+ clocks = <&clk16m>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <10000000>;
+ vdd-supply = <®_3v3>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+ };
+};
+
&fec1 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 689ff6822634..c28a483b786d 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -92,6 +92,12 @@
cpu-supply = <®_DCDC2>;
};
+&ecspi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
+ cs-gpios = <&gpio4 11 GPIO_ACTIVE_HIGH>;
+};
+
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
@@ -313,7 +319,6 @@
fsl,pins = <
MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x74 /* SODIMM 55 */
MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x74 /* SODIMM 63 */
- MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0x14 /* SODIMM 77 */
MX7D_PAD_EPDC_DATA09__GPIO2_IO9 0x14 /* SODIMM 89 */
MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x74 /* SODIMM 91 */
@@ -400,6 +405,12 @@
>;
};
+ pinctrl_can_int: can-int-grp {
+ fsl,pins = <
+ MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
+ >;
+ };
+
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_ENET1_CRS__GPIO7_IO14 0x14
--
2.15.1
^ permalink raw reply related
* [PATCH v2 7/9] ARM: dts: imx7-colibri: specify backlight GPIO
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo, kernel
Cc: fabio.estevam, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel, Stefan Agner
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The Colibri standard defines SODIMM 71 as backlight enable
GPIO. Assign the GPIO to the backlight node in the module
level device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index d623ef0f6e3e..689ff6822634 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -43,7 +43,10 @@
/ {
bl: backlight {
compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_bl_on>;
pwms = <&pwm1 0 5000000 0>;
+ enable-gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
};
reg_module_3v3: regulator-module-3v3 {
@@ -360,7 +363,6 @@
fsl,pins = <
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14 /* SODIMM 65 */
MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x74 /* SODIMM 69 */
- MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
MX7D_PAD_I2C4_SDA__GPIO4_IO15 0x14 /* SODIMM 75 */
MX7D_PAD_ECSPI1_MISO__GPIO4_IO18 0x14 /* SODIMM 79 */
MX7D_PAD_I2C3_SCL__GPIO4_IO12 0x14 /* SODIMM 81 */
@@ -436,6 +438,12 @@
>;
};
+ pinctrl_gpio_bl_on: gpio-bl-on {
+ fsl,pins = <
+ MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
+ >;
+ };
+
pinctrl_gpmi_nand: gpmi-nand-grp {
fsl,pins = <
MX7D_PAD_SD3_CLK__NAND_CLE 0x71
--
2.15.1
^ permalink raw reply related
* [PATCH v2 6/9] ARM: dts: imx7-colibri: specify usdhc1 supplies
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo, kernel
Cc: fabio.estevam, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel, Stefan Agner
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The usdhc1 controller instance is used to provide the default
SD/MMC capabilities of the Colibri standard. The IO pins are
supplied to the SoC on the module whereas the SD-card is powered
by the Carrier Board supply.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 1 +
arch/arm/boot/dts/imx7-colibri.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 5ecb3a858c5a..87c23b769a08 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -158,5 +158,6 @@
&usdhc1 {
keep-power-in-suspend;
wakeup-source;
+ vmmc-supply = <®_3v3>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 6498c1136ef1..d623ef0f6e3e 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -299,6 +299,7 @@
no-1-8-v;
cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
disable-wp;
+ vqmmc-supply = <®_LDO2>;
};
&iomuxc {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 5/9] ARM: dts: imx7-colibri: specify cpu-supply
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo, kernel
Cc: mark.rutland, devicetree, linux-kernel, Stefan Agner, robh+dt,
fabio.estevam, linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
Specify CPU supply using the "cpu-supply" property instead of
the invalid "arm-supply" property.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index f61041af026a..6498c1136ef1 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -86,7 +86,7 @@
};
&cpu0 {
- arm-supply = <®_DCDC2>;
+ cpu-supply = <®_DCDC2>;
};
&fec1 {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 4/9] ARM: dts: imx7-colibri: use NAND_CE1 as GPIO
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo, kernel
Cc: mark.rutland, devicetree, linux-kernel, Stefan Agner, robh+dt,
fabio.estevam, linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
All Colibri iMX7 SKUs use either single-die NAND or eMMC, hence
NAND_CE1 is not used on the module and can be used as a GPIO by
carrier boards.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index e4e32aa786f4..f61041af026a 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -329,6 +329,7 @@
MX7D_PAD_EPDC_SDCE2__GPIO2_IO22 0x14 /* SODIMM 127 */
MX7D_PAD_UART3_RTS_B__GPIO4_IO6 0x14 /* SODIMM 131 */
MX7D_PAD_EPDC_GDRL__GPIO2_IO26 0x14 /* SODIMM 133 */
+ MX7D_PAD_SAI1_RX_DATA__GPIO6_IO12 0x14 /* SODIMM 169 */
MX7D_PAD_SAI1_RX_BCLK__GPIO6_IO17 0x14 /* SODIMM 24 */
MX7D_PAD_SD2_DATA2__GPIO5_IO16 0x14 /* SODIMM 100 */
MX7D_PAD_SD2_DATA3__GPIO5_IO17 0x14 /* SODIMM 102 */
@@ -439,7 +440,6 @@
MX7D_PAD_SD3_CLK__NAND_CLE 0x71
MX7D_PAD_SD3_CMD__NAND_ALE 0x71
MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B 0x71
- MX7D_PAD_SAI1_RX_DATA__NAND_CE1_B 0x71
MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
MX7D_PAD_SD3_STROBE__NAND_RE_B 0x71
MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/9] ARM: dts: imx7-colibri: mux pull-ups where appropriate
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo, kernel
Cc: fabio.estevam, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel, Stefan Agner
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
Use pull-ups instead of pull-downs for the pins which are already
pulled-up externally.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index dae6b561145b..e4e32aa786f4 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -307,17 +307,17 @@
pinctrl_gpio1: gpio1-grp {
fsl,pins = <
- MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x14 /* SODIMM 55 */
- MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x14 /* SODIMM 63 */
+ MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x74 /* SODIMM 55 */
+ MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x74 /* SODIMM 63 */
MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
- MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0X14 /* SODIMM 77 */
+ MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0x14 /* SODIMM 77 */
MX7D_PAD_EPDC_DATA09__GPIO2_IO9 0x14 /* SODIMM 89 */
- MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x14 /* SODIMM 91 */
+ MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x74 /* SODIMM 91 */
MX7D_PAD_LCD_RESET__GPIO3_IO4 0x14 /* SODIMM 93 */
MX7D_PAD_EPDC_DATA13__GPIO2_IO13 0x14 /* SODIMM 95 */
MX7D_PAD_ENET1_RGMII_TXC__GPIO7_IO11 0x14 /* SODIMM 99 */
- MX7D_PAD_EPDC_DATA10__GPIO2_IO10 0x14 /* SODIMM 105 */
- MX7D_PAD_EPDC_DATA15__GPIO2_IO15 0x14 /* SODIMM 107 */
+ MX7D_PAD_EPDC_DATA10__GPIO2_IO10 0x74 /* SODIMM 105 */
+ MX7D_PAD_EPDC_DATA15__GPIO2_IO15 0x74 /* SODIMM 107 */
MX7D_PAD_EPDC_DATA00__GPIO2_IO0 0x14 /* SODIMM 111 */
MX7D_PAD_EPDC_DATA01__GPIO2_IO1 0x14 /* SODIMM 113 */
MX7D_PAD_EPDC_DATA02__GPIO2_IO2 0x14 /* SODIMM 115 */
@@ -333,7 +333,7 @@
MX7D_PAD_SD2_DATA2__GPIO5_IO16 0x14 /* SODIMM 100 */
MX7D_PAD_SD2_DATA3__GPIO5_IO17 0x14 /* SODIMM 102 */
MX7D_PAD_EPDC_GDSP__GPIO2_IO27 0x14 /* SODIMM 104 */
- MX7D_PAD_EPDC_BDR0__GPIO2_IO28 0x14 /* SODIMM 106 */
+ MX7D_PAD_EPDC_BDR0__GPIO2_IO28 0x74 /* SODIMM 106 */
MX7D_PAD_EPDC_BDR1__GPIO2_IO29 0x14 /* SODIMM 110 */
MX7D_PAD_EPDC_PWR_COM__GPIO2_IO30 0x14 /* SODIMM 112 */
MX7D_PAD_EPDC_SDCLK__GPIO2_IO16 0x14 /* SODIMM 114 */
@@ -357,7 +357,7 @@
pinctrl_gpio2: gpio2-grp { /* On X22 Camera interface */
fsl,pins = <
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14 /* SODIMM 65 */
- MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x14 /* SODIMM 69 */
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x74 /* SODIMM 69 */
MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
MX7D_PAD_I2C4_SDA__GPIO4_IO15 0x14 /* SODIMM 75 */
MX7D_PAD_ECSPI1_MISO__GPIO4_IO18 0x14 /* SODIMM 79 */
@@ -378,8 +378,8 @@
MX7D_PAD_LCD_DATA19__GPIO3_IO24 0x14 /* SODIMM 138 */
MX7D_PAD_LCD_DATA20__GPIO3_IO25 0x14 /* SODIMM 140 */
MX7D_PAD_LCD_DATA21__GPIO3_IO26 0x14 /* SODIMM 142 */
- MX7D_PAD_LCD_DATA22__GPIO3_IO27 0x14 /* SODIMM 146 */
- MX7D_PAD_LCD_DATA23__GPIO3_IO28 0x14 /* SODIMM 148 */
+ MX7D_PAD_LCD_DATA22__GPIO3_IO27 0x74 /* SODIMM 144 */
+ MX7D_PAD_LCD_DATA23__GPIO3_IO28 0x74 /* SODIMM 146 */
>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/9] ARM: dts: imx7-colibri: make sure multiplexed pins are not active
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo, kernel
Cc: fabio.estevam, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel, Stefan Agner
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The Colibri pins PWM<A> and <D> are multiplexed on the module, make
sure the secondary SoC pin is not active.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 60ea7557d8c9..dae6b561145b 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -507,6 +507,7 @@
pinctrl_pwm1: pwm1-grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO08__PWM1_OUT 0x79
+ MX7D_PAD_ECSPI2_MOSI__GPIO4_IO21 0x4
>;
};
@@ -525,6 +526,7 @@
pinctrl_pwm4: pwm4-grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO11__PWM4_OUT 0x79
+ MX7D_PAD_ECSPI2_SCLK__GPIO4_IO20 0x4
>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 1/9] ARM: dts: imx7-colibri: move and rename USB Host power regulator
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: fabio.estevam-3arQi8VN3Tc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Agner
The Colibri default which enables USB Host power is not necessarily
tied to the OTG2 controller, some carrier board use the pin to
control USB power for both controllers. Hence name the pinctrl
group more generic.
Also move the regulator to the generic eval-v3 device tree since
the regulator is always on the carrier board. In the Colibri iMX7S
case the regulator is just not used. This allows to reuse the
regulator in a upcoming SKU Colibri iMX7D 1GB with eMMC.
Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
---
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 11 +++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
arch/arm/boot/dts/imx7d-colibri-eval-v3.dts | 13 +------------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 18bebd6d8d47..5ecb3a858c5a 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -70,6 +70,17 @@
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
+
+ reg_usbh_vbus: regulator-usbh-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh_reg>;
+ regulator-name = "VCC_USB[1-4]";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 7 GPIO_ACTIVE_LOW>;
+ vin-supply = <®_5v0>;
+ };
};
&bl {
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index bb5bf94f1a32..60ea7557d8c9 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -559,7 +559,7 @@
>;
};
- pinctrl_usbotg2_reg: gpio-usbotg2-vbus {
+ pinctrl_usbh_reg: gpio-usbh-vbus {
fsl,pins = <
MX7D_PAD_UART3_CTS_B__GPIO4_IO7 0x14 /* SODIMM 129 USBH PEN */
>;
diff --git a/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts b/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
index a608a14d8c85..136e11ab4893 100644
--- a/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
@@ -48,20 +48,9 @@
model = "Toradex Colibri iMX7D on Colibri Evaluation Board V3";
compatible = "toradex,colibri-imx7d-eval-v3", "toradex,colibri-imx7d",
"fsl,imx7d";
-
- reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usbotg2_reg>;
- regulator-name = "VCC_USB[1-4]";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio4 7 GPIO_ACTIVE_LOW>;
- vin-supply = <®_5v0>;
- };
};
&usbotg2 {
- vbus-supply = <®_usb_otg2_vbus>;
+ vbus-supply = <®_usbh_vbus>;
status = "okay";
};
--
2.15.1
--
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
* Re: [PATCH 2/9] ARM: dts: imx7-colibri: make sure multiplexed pins are not active
From: Stefan Agner @ 2017-12-17 20:02 UTC (permalink / raw)
To: Fabio Estevam
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAOMZO5AD6bDEMStEWY8hRG_8gh0RAD_66zboTsKd-cFkPtiLKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2017-12-16 15:01, Fabio Estevam wrote:
> On Wed, Dec 6, 2017 at 1:29 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
>> The Colibri pins PWM<A> and <D> are multiplexed on the module, make
>> sure the secondary SoC pin is not active.
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>
> I haven't really understood the commit message, but this is probably
> because I don't have access to the schematics.
It means that the modules pins are connected to two SoC pads. It is also
mentioned in the Colibri iMX7 datasheet.
This allows to use the module pin for a different purpose, but we mux it
such that it is usable for the primary purpose (which is PWM).
>
> Anyway:
>
> Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Thanks!
--
Stefan
--
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 v4 3/4] cpufreq: Add DVFS support for Armada 37xx
From: Rafael J. Wysocki @ 2017-12-17 18:12 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Viresh Kumar, linux-pm-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antoine Tenart,
Miquèl Raynal, Nadav Haklai, Victor Gu, Marcin Wojtas,
Wilson Ding, Hua Jing, Neta Zur Hershkovits, Evan Wang,
Andre Heider
In-Reply-To: <2201504.Sp2n0UgIp2-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org>
On Sunday, December 17, 2017 7:08:53 PM CET Rafael J. Wysocki wrote:
> On Thursday, December 14, 2017 4:36:31 PM CET Viresh Kumar wrote:
> > On 14-12-17, 16:00, Gregory CLEMENT wrote:
> > > This patch adds DVFS support for the Armada 37xx SoCs
> > >
> > > There are up to four CPU frequency loads for Armada 37xx controlled by
> > > the hardware.
> > >
> > > This driver associates the CPU load level to a frequency, then the
> > > hardware will switch while selecting a load level.
> > >
> > > The hardware also can associate a voltage for each level (AVS support)
> > > but it is not yet supported
> > >
> > > Tested-by: Andre Heider <a.heider-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > ---
> > > drivers/cpufreq/Kconfig.arm | 7 +
> > > drivers/cpufreq/Makefile | 1 +
> > > drivers/cpufreq/armada-37xx-cpufreq.c | 241 ++++++++++++++++++++++++++++++++++
> > > 3 files changed, 249 insertions(+)
> > > create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
> >
> > Thanks for taking care of very minor review comments I had. All the
> > patches look good now to me :)
>
> All applied, thanks!
>
Actually, all except for the [4/4] as you applied it earlier.
Thanks!
--
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 0/2] cpufreq: Sort Kconfig and Makefile
From: Rafael J. Wysocki @ 2017-12-17 18:10 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Viresh Kumar, linux-pm-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antoine Tenart,
Miquèl Raynal, Nadav Haklai, Victor Gu, Marcin Wojtas,
Wilson Ding, Hua Jing, Neta Zur Hershkovits, Evan Wang,
Andre Heider
In-Reply-To: <20171213170536.28238-1-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wednesday, December 13, 2017 6:05:34 PM CET Gregory CLEMENT wrote:
> Hi,
>
> The patch of this series was originally part of the series "Add CPU
> Frequency scaling support on Armada 37xx" [1].
>
> As requested by Rafael J. Wysocki, these 2 patches are extracted in a
> independent series, in the meantime, Viresh Kumar gave his acked-by
> that I added to the patches.
>
> In this second version only the 1st patch had been modified, see the
> changelog for the details.
>
> Thanks,
>
> Gregory
>
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/546709.html
>
> Changelog:
> v1 -> v2:
>
> - Fixed tab vs space issue in KConfig, suggested by Randy Dunlap
> - Removed unneeded "default n" in KConfig, suggested by Randy Dunlap
>
> Gregory CLEMENT (2):
> cpufreq: ARM: sort the Kconfig menu
> cpufreq: sort the drivers in ARM part
>
> drivers/cpufreq/Kconfig.arm | 81 ++++++++++++++++++++++-----------------------
> drivers/cpufreq/Makefile | 8 ++---
> 2 files changed, 44 insertions(+), 45 deletions(-)
>
>
Both applied, thanks!
--
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 v4 3/4] cpufreq: Add DVFS support for Armada 37xx
From: Rafael J. Wysocki @ 2017-12-17 18:08 UTC (permalink / raw)
To: Viresh Kumar, Gregory CLEMENT
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antoine Tenart,
Miquèl Raynal, Nadav Haklai, Victor Gu, Marcin Wojtas,
Wilson Ding, Hua Jing, Neta Zur Hershkovits, Evan Wang,
Andre Heider
In-Reply-To: <20171214153631.GZ3322@vireshk-i7>
On Thursday, December 14, 2017 4:36:31 PM CET Viresh Kumar wrote:
> On 14-12-17, 16:00, Gregory CLEMENT wrote:
> > This patch adds DVFS support for the Armada 37xx SoCs
> >
> > There are up to four CPU frequency loads for Armada 37xx controlled by
> > the hardware.
> >
> > This driver associates the CPU load level to a frequency, then the
> > hardware will switch while selecting a load level.
> >
> > The hardware also can associate a voltage for each level (AVS support)
> > but it is not yet supported
> >
> > Tested-by: Andre Heider <a.heider-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > drivers/cpufreq/Kconfig.arm | 7 +
> > drivers/cpufreq/Makefile | 1 +
> > drivers/cpufreq/armada-37xx-cpufreq.c | 241 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 249 insertions(+)
> > create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
>
> Thanks for taking care of very minor review comments I had. All the
> patches look good now to me :)
All applied, thanks!
--
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 v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes
From: Rafael J. Wysocki @ 2017-12-17 18:05 UTC (permalink / raw)
To: Matthias Brugger
Cc: Viresh Kumar, Andrew-sh Cheng, mark.rutland-5wv7dgnIgG8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a68c5382-2a9c-6c3c-ea67-99db46bdff1a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tuesday, December 12, 2017 10:34:42 AM CET Matthias Brugger wrote:
> Hi,
>
> On 12/12/2017 08:26 AM, Viresh Kumar wrote:
> > On 12-12-17, 02:17, Rafael J. Wysocki wrote:
> >> On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
> >>> On 08-12-17, 14:07, Andrew-sh Cheng wrote:
> >>>> Add opp v2 information,
> >>>> and also add clocks, regulators and opp information into cpu nodes
> >>>>
> >>>> Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>> ---
> >>>> arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++++++++++++
> >>>> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 57 +++++++++++++++++++++++++++++
> >>>> 2 files changed, 84 insertions(+)
> >>>
> >>> Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>
> >> Of course, DT bindings require ACKs from DT maintainers to be applied.
> >
> > I didn't knew that we need Acks from DT maintainers for dts files as well? Yeah,
> > its very much required while defining new bindings for sure.
> >
>
> I will take the dts parts through the Mediatek SoC tree, so you don't have to
> worry about them.
>
> Please let me know when you take patch 1 and 2.
Applied now, thanks!
Do you need the branch containing them to be exposed?
Thanks,
Rafael
--
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 v5 0/4] NVIDIA Tegra video decoder driver
From: Dmitry Osipenko @ 2017-12-17 18:03 UTC (permalink / raw)
To: Thierry Reding
Cc: Jonathan Hunter, Stephen Warren, Greg Kroah-Hartman,
Mauro Carvalho Chehab, Hans Verkuil, Vladimir Zapolskiy,
Rob Herring, Dan Carpenter, linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1513038011.git.digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12.12.2017 03:26, Dmitry Osipenko wrote:
> VDE driver provides accelerated video decoding to NVIDIA Tegra SoC's,
> it is a result of reverse-engineering efforts. Driver has been tested on
> Toshiba AC100 and Acer A500, it should work on any Tegra20 device.
>
> In userspace this driver is utilized by libvdpau-tegra [0] that implements
> VDPAU interface, so any video player that supports VDPAU can provide
> accelerated video decoding on Tegra20 on Linux.
>
> [0] https://github.com/grate-driver/libvdpau-tegra
Thierry, driver has been approved by media maintainers and should appear in 4.16
(it is already in -next). Please schedule the DT patches for 4.16, thanks.
^ permalink raw reply
* Re: Distress Call Please don't ignore
From: Sandra Younes @ 2017-12-17 17:46 UTC (permalink / raw)
Good Day,
Forgive my indignation if this message comes to you as a surprise and may offend your personality for contacting you without your prior consent and writing through this channel.
I came across your name and contact on the course of my personal searching when i was searching for a foreign reliable partner. I was assured of your capability and reliability after going true your profile.
I'm (Miss. Sandra) from Benghazi libya, My father of blessed memory by name late General Abdel Fattah Younes who was shot death by Islamist-linked militia within the anti-Gaddafi forces on 28th July, 2011 and after two days later my mother with my two brothers was killed one early morning by the rebels as result of civil war that is going on in my country Libya, then after the burial of my parents, my uncles conspired and sold my father's properties and left nothing for me. On a faithful morning, I opened my father's briefcase and discover a document which he has deposited ($6.250M USD) in a bank in a Turkish Bank which has a small branch in Canada with my name as the legitimate/next of kin. Meanwhile i have located the bank,and have also discussed the possiblity of transfering the fund. M
y father left a clause to the bank that i must introduce a trusted foreign partner who would be my trustee to help me invest this fund; hence the need for your assistance,i request that you be my t
rustee and assist me in e
You will also be responsible for the investment and management of the fund for me and also you will help me get a good school where i will further my education.
I agreed to give you 40% of the $6.250M once the transfer is done. this is my true life story, I will be glad to receive your respond soonest for more details to enable us start and champion the transfer less than 14 banking days as i was informed by the bank manager.
Thanks for giving me your attention,
Yours sincerely,
Miss. Sandra Younes
--
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 v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
From: Randy Dunlap @ 2017-12-17 17:40 UTC (permalink / raw)
To: Dhaval Rajeshbhai Shah, arnd-r2nGTMty4D4@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org, Hyun Kwon
In-Reply-To: <BY2PR0201MB1879AFE10931133E229C0849C1090-xQ6P1Lmehamr4PZSg9VoqRrHTHEw16jenBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On 12/16/2017 10:07 PM, Dhaval Rajeshbhai Shah wrote:
> Hi Randy,
>
> Thanks a lot for the review.
>
>> -----Original Message-----
>> From: Randy Dunlap [mailto:rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org]
>> Sent: Saturday, December 16, 2017 2:18 PM
>> To: Dhaval Rajeshbhai Shah <DSHAH-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>; arnd-r2nGTMty4D4@public.gmane.org;
>> gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>> michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org; Hyun Kwon <hyunk-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>; Dhaval Rajeshbhai
>> Shah <DSHAH-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>> Subject: Re: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP
>> init driver
>>
>> On 12/14/2017 11:24 PM, Dhaval Shah wrote:
>>> Xilinx ZYNQMP logicoreIP Init driver is based on the new LogiCoreIP
>>> design created. This driver provides the processing system and
>>> programmable logic isolation. Set the frequency based on the clock
>>> information get from the logicoreIP register set.
>>>
>>> It is put in drivers/misc as there is no subsystem for this logicoreIP.
>>>
>>> Signed-off-by: Dhaval Shah <dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>
>>> drivers/misc/Kconfig | 15 ++
>>> drivers/misc/Makefile | 1 +
>>> drivers/misc/xlnx_vcu.c | 631
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 647 insertions(+)
>>> create mode 100644 drivers/misc/xlnx_vcu.c
>>
>>> diff --git a/drivers/misc/xlnx_vcu.c b/drivers/misc/xlnx_vcu.c new
>>> file mode 100644 index 0000000..f489d34
>>> --- /dev/null
>>> +++ b/drivers/misc/xlnx_vcu.c
>>> @@ -0,0 +1,631 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Xilinx VCU Init
>>> + *
>>> + * Copyright (C) 2016 - 2017 Xilinx, Inc.
>>> + *
>>> + * Contacts Dhaval Shah <dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>> + */
>>> +#include <linux/clk.h>
>>> +#include <linux/device.h>
>>> +#include <linux/errno.h>
>>> +#include <linux/io.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_platform.h>
>>> +#include <linux/platform_device.h>
>>
>> [snip]
>>
>>
>>> +/**
>>> + * xvcu_set_vcu_pll_info - Set the VCU PLL info
>>> + * @xvcu: Pointer to the xvcu_device structure
>>> + *
>>> + * Programming the VCU PLL based on the user configuration
>>> + * (ref clock freq, core clock freq, mcu clock freq).
>>> + * Core clock frequency has higher priority than mcu clock frequency
>>> + * Errors in following cases
>>> + * - When mcu or clock clock get from logicoreIP is 0
>>> + * - When VCU PLL DIV related bits value other than 1
>>> + * - When proper data not found for given data
>>> + * - When sis570_1 clocksource related operation failed
>>> + *
>>> + * Return: Returns status, either success or error+reason
>>> + */
>>> +static int xvcu_set_vcu_pll_info(struct xvcu_device *xvcu) {
>>> + u32 refclk, coreclk, mcuclk, inte, deci;
>>> + u32 divisor_mcu, divisor_core, fvco;
>>> + u32 clkoutdiv, vcu_pll_ctrl, pll_clk;
>>> + u32 cfg_val, mod, ctrl;
>>> + int ret;
>>> + unsigned int i;
>>> + const struct xvcu_pll_cfg *found = NULL;
>>> +
>>> + inte = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK);
>>> + deci = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK_DEC);
>>> + coreclk = xvcu_read(xvcu->logicore_reg_ba, VCU_CORE_CLK) * MHZ;
>>> + mcuclk = xvcu_read(xvcu->logicore_reg_ba, VCU_MCU_CLK) * MHZ;
>>> + if (!mcuclk || !coreclk) {
>>> + dev_err(xvcu->dev, "Invalid mcu and core clock data\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + refclk = (inte * MHZ) + (deci * (MHZ / FRAC));
>>> + dev_dbg(xvcu->dev, "Ref clock from logicoreIP is %uHz\n", refclk);
>>> + dev_dbg(xvcu->dev, "Core clock from logicoreIP is %uHz\n", coreclk);
>>> + dev_dbg(xvcu->dev, "Mcu clock from logicoreIP is %uHz\n", mcuclk);
>>> +
>>> + clk_disable_unprepare(xvcu->pll_ref);
>>> + ret = clk_set_rate(xvcu->pll_ref, refclk);
>>> + if (ret)
>>> + dev_warn(xvcu->dev, "failed to set logicoreIP refclk rate\n");
>>> +
>>> + ret = clk_prepare_enable(xvcu->pll_ref);
>>> + if (ret) {
>>> + dev_err(xvcu->dev, "failed to enable pll_ref clock source\n");
>>> + return ret;
>>> + }
>>> +
>>> + refclk = clk_get_rate(xvcu->pll_ref);
>>> +
>>> + /*
>>> + * The divide-by-2 should be always enabled (==1)
>>> + * to meet the timing in the design.
>>> + * Otherwise, it's an error
>>> + */
>>> + vcu_pll_ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_CTRL);
>>> + clkoutdiv = vcu_pll_ctrl >> VCU_PLL_CTRL_CLKOUTDIV_SHIFT;
>>> + clkoutdiv = clkoutdiv && VCU_PLL_CTRL_CLKOUTDIV_MASK;
>>> + if (clkoutdiv != 1) {
>>> + dev_err(xvcu->dev, "clkoutdiv value is invalid\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + for (i = ARRAY_SIZE(xvcu_pll_cfg) - 1; i > 0; i--) {
>>
>> When does that for loop terminate?
>>
> This loop will terminate either it reach to i =0 and one other case is when it find the proper expected value. Break statement is used to exit in that case.
Hm, well, I did mis-read it, but I think that there is still an off-by-one problem.
Consider the case of the value is not found in the array.
If ARRAY_SIZE(xvcu_pll_cfg) is 5:
for (i = ARRAY_SIZE(xvcu_pll_cfg) - 1; i > 0; i--) {
i == 4:
check xvcu_pll_cfg[4]
i--;
i == 3:
check xvcu_pll_cfg[3]
i--;
i == 2;
check xvcu_pll_cfg[2]
i--;
i == 1:
check xvcu_pll_cfg[1]
i--;
i == 0;
terminate for-loop;
xvcu_pll_cfg[0] is never checked;
Is this clear?
>>> + const struct xvcu_pll_cfg *cfg = &xvcu_pll_cfg[i];
>>> +
>>> + fvco = cfg->fbdiv * refclk;
>>> + if (fvco >= FVCO_MIN && fvco <= FVCO_MAX) {
>>> + pll_clk = fvco / VCU_PLL_DIV2;
>>> + if (fvco % VCU_PLL_DIV2 != 0)
>>> + pll_clk++;
>>> + mod = pll_clk % coreclk;
>>> + if (mod < LIMIT) {
>>> + divisor_core = pll_clk / coreclk;
>>> + } else if (coreclk - mod < LIMIT) {
>>> + divisor_core = pll_clk / coreclk;
>>> + divisor_core++;
>>> + } else {
>>> + continue;
>>> + }
>>> + if (divisor_core >= DIVISOR_MIN &&
>>> + divisor_core <= DIVISOR_MAX) {
>>> + found = cfg;
>>> + divisor_mcu = pll_clk / mcuclk;
>>> + mod = pll_clk % mcuclk;
>>> + if (mcuclk - mod < LIMIT)
>>> + divisor_mcu++;
>>> + break;
> This is the break statement to exit when proper value is find.
>>> + }
>>> + }
>>> + }
>>> +
>>> + if (!found) {
>>> + dev_err(xvcu->dev, "Invalid clock combination.\n");
>>> + return -EINVAL;
>>> + }
>>
>> [snip]
--
~Randy
--
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 00/13] MIPS: add support for the Microsemi MIPS SoCs
From: PrasannaKumar Muralidharan @ 2017-12-17 16:59 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Ralf Baechle, linux-mips, open list, Rob Herring, devicetree,
Thomas Gleixner, Jason Cooper, Linus Walleij, linux-gpio,
Sebastian Reichel, linux-pm
In-Reply-To: <20171208154618.20105-1-alexandre.belloni@free-electrons.com>
Hi Alexandre,
With very small amount of code in arch/mips this series looks really nice.
On 8 December 2017 at 21:16, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> Hi,
>
> This patch series adds initial support for the Microsemi MIPS SoCs. It
> is currently focusing on the Microsemi Ocelot (VSC7513, VSC7514).
>
> It adds support for the IRQ controller, pinmux and gpio controller and
> reset control.
>
> This produces a kernel that can boot to the console.
>
> This is a single series for reference but it can also be taken
> separately by each maintainer as each drivers are independant.
>
> Changes in v2:
> - removed the wildcard in MAINAINERS
> - corrected the Cc list
> - added proper documentation for both syscons
> - removed the mscc,cpucontrol property
> - updated the ranges property in the ocelot dtsi
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-gpio@vger.kernel.org
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: linux-pm@vger.kernel.org
>
>
> Alexandre Belloni (13):
> dt-bindings: Add vendor prefix for Microsemi Corporation
> dt-bindings: interrupt-controller: Add binding for the Microsemi
> Ocelot interrupt controller
> irqchip: Add a driver for the Microsemi Ocelot controller
> dt-bindings: pinctrl: Add bindings for Microsemi Ocelot
> pinctrl: Add Microsemi Ocelot SoC driver
> dt-bindings: mips: Add bindings for Microsemi SoCs
> dt-bindings: power: reset: Document ocelot-reset binding
> power: reset: Add a driver for the Microsemi Ocelot reset
> MIPS: mscc: Add initial support for Microsemi MIPS SoCs
> MIPS: mscc: add ocelot dtsi
> MIPS: mscc: add ocelot PCB123 device tree
> MIPS: defconfigs: add a defconfig for Microsemi SoCs
> MAINTAINERS: Add entry for Microsemi MIPS SoCs
>
> .../interrupt-controller/mscc,ocelot-icpu-intr.txt | 22 +
> Documentation/devicetree/bindings/mips/mscc.txt | 46 ++
> .../bindings/pinctrl/mscc,ocelot-pinctrl.txt | 39 ++
> .../bindings/power/reset/ocelot-reset.txt | 17 +
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> MAINTAINERS | 7 +
> arch/mips/Kbuild.platforms | 1 +
> arch/mips/Kconfig | 24 +
> arch/mips/boot/dts/Makefile | 1 +
> arch/mips/boot/dts/mscc/Makefile | 6 +
> arch/mips/boot/dts/mscc/ocelot.dtsi | 115 +++++
> arch/mips/boot/dts/mscc/ocelot_pcb123.dts | 27 ++
> arch/mips/configs/mscc_defconfig | 84 ++++
> arch/mips/mscc/Makefile | 11 +
> arch/mips/mscc/Platform | 12 +
> arch/mips/mscc/setup.c | 106 +++++
> drivers/irqchip/Kconfig | 5 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-mscc-ocelot.c | 109 +++++
> drivers/pinctrl/Kconfig | 10 +
> drivers/pinctrl/Makefile | 1 +
> drivers/pinctrl/pinctrl-ocelot.c | 505 +++++++++++++++++++++
> drivers/power/reset/Kconfig | 7 +
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/ocelot-reset.c | 86 ++++
> 25 files changed, 1244 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
> create mode 100644 Documentation/devicetree/bindings/mips/mscc.txt
> create mode 100644 Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
> create mode 100644 Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> create mode 100644 arch/mips/boot/dts/mscc/Makefile
> create mode 100644 arch/mips/boot/dts/mscc/ocelot.dtsi
> create mode 100644 arch/mips/boot/dts/mscc/ocelot_pcb123.dts
> create mode 100644 arch/mips/configs/mscc_defconfig
> create mode 100644 arch/mips/mscc/Makefile
> create mode 100644 arch/mips/mscc/Platform
> create mode 100644 arch/mips/mscc/setup.c
> create mode 100644 drivers/irqchip/irq-mscc-ocelot.c
> create mode 100644 drivers/pinctrl/pinctrl-ocelot.c
> create mode 100644 drivers/power/reset/ocelot-reset.c
>
> --
> 2.15.1
>
>
Except for irqchip driver and pinctrl driver other parts of the series is
Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Regards,
PrasannaKumar
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: can: mcp2517fd: document device tree bindings
From: kernel-TqfNSX0MhmxHKSADF0wUEw @ 2017-12-17 14:34 UTC (permalink / raw)
To: Patrick Menschel; +Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, devicetree
In-Reply-To: <d79ee9eb-8b36-0086-8d76-ec6bca224fe5-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
Hi Patrick!
So I started implementing the GPIO_LIB implementation but
I have hit an issue where I would like to get some feedback.
So in principle the gpiolib works, but only if the device is
not asleep and the clock is enabled, which at this very moment means
that the can interface has to be up and running.
So at this very moment the only option that I see would be to
disable the sleep mode which the device enters after probing until
the can-network interface is enabled (which enables the clock and
start the oscillator) - with SLEEP enabled when GPIOLIB support
is disabled.
This is obviously not optimal from the power perspective…
The other option would be starting the clock and oscillator
as soon as a set_direction* (or reques/free) function is called.
(where I would need to start using locks to avoid race conditions
as well as clock usage counters...).
Which of the above is the preferred solution? Are there other ideas
how I could solve this dilemma?
Martin
> On 05.12.2017, at 19:28, Patrick Menschel <menschel.p-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org> wrote:
>
> Hi Martin,
>
> it depends on the daily usage of those alternate functions.
> I just took a quick glimpse on the datasheet and if you check appendix B table 9-1 , you'll see that some functions are optional because ISO suggested them, not because there is a practical reason for it.
>
> CLKO/SOF does make little to no sense with a higher grade embedded system. CLKO is meant to share the osc with the microcontroller.
>> The CLKO pin provides the clock to the
>> microcontroller.
> SOF makes sense for testing in lab configuration, not for regular operation.
>
> TXCAN also does make little sense as you can only use it in the lab.
>> TXCANOD: TXCAN can be configured as Push-
>> Pull or as Open Drain out
>> put. Open Drain outputs
>> allows the user to connect multiple controllers
>> together to build a CAN network without using a
>> transceiver.
>
> INTOD is initialized as Push/Pull. Configuring it open drain would be processor specific when the microcontroller has limited options for pin-ctrl, e.g. some PICs.
>> INTOD:
>> Interrupt pins Open Drain Mode
>> 1
>> = Open Drain Output
>> 0
>> = Push/Pull Output
>
> To sum it up, I would drop:
> - CLKO/SOF
> - TXCAN
> - INTOD
>
> I would implement higher level functions in a second step for INT0/GPIO0/XSTBY and INT1/GPIO1.
> Such functions can be:
> - power saving via XSTBY
> - RX / TX LEDs via INT0 / INT1
>
> Actually this second step would wait until a request for feature arises.
>
> Regards,
> Patrick
>
> Am 05.12.2017 um 11:26 schrieb Martin Sperl:
>> Hi Patrick!
>>
>>
>> I had a quick look starting to implement gpiolib,
>>
>> but I believe I would need to implement pin-ctrl on top to
>>
>> make the Alternate functions work propperly.
>>
>> I wonder if this effort is really worth it.
>>
>> Martin
>>
--
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 v9 13/13] ASoC: stm32: add DFSDM DAI support
From: Jonathan Cameron @ 2017-12-17 12:59 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: <1513241885-32079-14-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
On Thu, 14 Dec 2017 09:58:05 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:
> Add driver to handle DAI interface for PDM microphones connected
> to Digital Filter for Sigma Delta Modulators IP.
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
For the IIO parts (I'm not knowledgeable enough about the sound side to
offer a proper review!)
Reviewed-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
So Mark, over to you. I'm happy if you want to do the immutable branch
once any issue you find are fixed, or I can do it. I'm just looking
for acks or a pull request now.
Jonathan
> ---
> sound/soc/stm/Kconfig | 11 ++
> sound/soc/stm/Makefile | 3 +
> sound/soc/stm/stm32_adfsdm.c | 347 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 361 insertions(+)
> create mode 100644 sound/soc/stm/stm32_adfsdm.c
>
> diff --git a/sound/soc/stm/Kconfig b/sound/soc/stm/Kconfig
> index 3398e6c..a78f770 100644
> --- a/sound/soc/stm/Kconfig
> +++ b/sound/soc/stm/Kconfig
> @@ -28,4 +28,15 @@ config SND_SOC_STM32_SPDIFRX
> help
> Say Y if you want to enable S/PDIF capture for STM32
>
> +config SND_SOC_STM32_DFSDM
> + tristate "SoC Audio support for STM32 DFSDM"
> + depends on (ARCH_STM32 && OF && STM32_DFSDM_ADC) || COMPILE_TEST
> + depends on SND_SOC
> + select SND_SOC_GENERIC_DMAENGINE_PCM
> + select SND_SOC_DMIC
> + select IIO_BUFFER_CB
> + help
> + Select this option to enable the STM32 Digital Filter
> + for Sigma Delta Modulators (DFSDM) driver used
> + in various STM32 series for digital microphone capture.
> endmenu
> diff --git a/sound/soc/stm/Makefile b/sound/soc/stm/Makefile
> index 4ed22e6..53e90e6 100644
> --- a/sound/soc/stm/Makefile
> +++ b/sound/soc/stm/Makefile
> @@ -12,3 +12,6 @@ obj-$(CONFIG_SND_SOC_STM32_I2S) += snd-soc-stm32-i2s.o
> # SPDIFRX
> snd-soc-stm32-spdifrx-objs := stm32_spdifrx.o
> obj-$(CONFIG_SND_SOC_STM32_SPDIFRX) += snd-soc-stm32-spdifrx.o
> +
> +#DFSDM
> +obj-$(CONFIG_SND_SOC_STM32_DFSDM) += stm32_adfsdm.o
> diff --git a/sound/soc/stm/stm32_adfsdm.c b/sound/soc/stm/stm32_adfsdm.c
> new file mode 100644
> index 0000000..af50891
> --- /dev/null
> +++ b/sound/soc/stm/stm32_adfsdm.c
> @@ -0,0 +1,347 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * This file is part of STM32 DFSDM ASoC DAI driver
> + *
> + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
> + * Authors: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
> + * Olivier Moysan <olivier.moysan-qxv4g6HH51o@public.gmane.org>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/consumer.h>
> +#include <linux/iio/adc/stm32-dfsdm-adc.h>
> +
> +#include <sound/pcm.h>
> +#include <sound/soc.h>
> +
> +#define STM32_ADFSDM_DRV_NAME "stm32-adfsdm"
> +
> +#define DFSDM_MAX_PERIOD_SIZE (PAGE_SIZE / 2)
> +#define DFSDM_MAX_PERIODS 6
> +
> +struct stm32_adfsdm_priv {
> + struct snd_soc_dai_driver dai_drv;
> + struct snd_pcm_substream *substream;
> + struct device *dev;
> +
> + /* IIO */
> + struct iio_channel *iio_ch;
> + struct iio_cb_buffer *iio_cb;
> + bool iio_active;
> +
> + /* PCM buffer */
> + unsigned char *pcm_buff;
> + unsigned int pos;
> +};
> +
> +static const struct snd_pcm_hardware stm32_adfsdm_pcm_hw = {
> + .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
> + SNDRV_PCM_INFO_PAUSE,
> + .formats = SNDRV_PCM_FMTBIT_S32_LE,
> +
> + .rate_min = 8000,
> + .rate_max = 32000,
> +
> + .channels_min = 1,
> + .channels_max = 1,
> +
> + .periods_min = 2,
> + .periods_max = DFSDM_MAX_PERIODS,
> +
> + .period_bytes_max = DFSDM_MAX_PERIOD_SIZE,
> + .buffer_bytes_max = DFSDM_MAX_PERIODS * DFSDM_MAX_PERIOD_SIZE
> +};
> +
> +static void stm32_adfsdm_shutdown(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + struct stm32_adfsdm_priv *priv = snd_soc_dai_get_drvdata(dai);
> +
> + if (priv->iio_active) {
> + iio_channel_stop_all_cb(priv->iio_cb);
> + priv->iio_active = false;
> + }
> +}
> +
> +static int stm32_adfsdm_dai_prepare(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + struct stm32_adfsdm_priv *priv = snd_soc_dai_get_drvdata(dai);
> + int ret;
> +
> + ret = iio_write_channel_attribute(priv->iio_ch,
> + substream->runtime->rate, 0,
> + IIO_CHAN_INFO_SAMP_FREQ);
> + if (ret < 0) {
> + dev_err(dai->dev, "%s: Failed to set %d sampling rate\n",
> + __func__, substream->runtime->rate);
> + return ret;
> + }
> +
> + if (!priv->iio_active) {
> + ret = iio_channel_start_all_cb(priv->iio_cb);
> + if (!ret)
> + priv->iio_active = true;
> + else
> + dev_err(dai->dev, "%s: IIO channel start failed (%d)\n",
> + __func__, ret);
> + }
> +
> + return ret;
> +}
> +
> +static int stm32_adfsdm_set_sysclk(struct snd_soc_dai *dai, int clk_id,
> + unsigned int freq, int dir)
> +{
> + struct stm32_adfsdm_priv *priv = snd_soc_dai_get_drvdata(dai);
> + ssize_t size;
> + char str_freq[10];
> +
> + dev_dbg(dai->dev, "%s: Enter for freq %d\n", __func__, freq);
> +
> + /* Set IIO frequency if CODEC is master as clock comes from SPI_IN */
> +
> + snprintf(str_freq, sizeof(str_freq), "%d\n", freq);
> + size = iio_write_channel_ext_info(priv->iio_ch, "spi_clk_freq",
> + str_freq, sizeof(str_freq));
> + if (size != sizeof(str_freq)) {
> + dev_err(dai->dev, "%s: Failed to set SPI clock\n",
> + __func__);
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +static const struct snd_soc_dai_ops stm32_adfsdm_dai_ops = {
> + .shutdown = stm32_adfsdm_shutdown,
> + .prepare = stm32_adfsdm_dai_prepare,
> + .set_sysclk = stm32_adfsdm_set_sysclk,
> +};
> +
> +static const struct snd_soc_dai_driver stm32_adfsdm_dai = {
> + .capture = {
> + .channels_min = 1,
> + .channels_max = 1,
> + .formats = SNDRV_PCM_FMTBIT_S32_LE,
> + .rates = (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 |
> + SNDRV_PCM_RATE_32000),
> + },
> + .ops = &stm32_adfsdm_dai_ops,
> +};
> +
> +static const struct snd_soc_component_driver stm32_adfsdm_dai_component = {
> + .name = "stm32_dfsdm_audio",
> +};
> +
> +static int stm32_afsdm_pcm_cb(const void *data, size_t size, void *private)
> +{
> + struct stm32_adfsdm_priv *priv = private;
> + struct snd_soc_pcm_runtime *rtd = priv->substream->private_data;
> + u8 *pcm_buff = priv->pcm_buff;
> + u8 *src_buff = (u8 *)data;
> + unsigned int buff_size = snd_pcm_lib_buffer_bytes(priv->substream);
> + unsigned int period_size = snd_pcm_lib_period_bytes(priv->substream);
> + unsigned int old_pos = priv->pos;
> + unsigned int cur_size = size;
> +
> + dev_dbg(rtd->dev, "%s: buff_add :%p, pos = %d, size = %zu\n",
> + __func__, &pcm_buff[priv->pos], priv->pos, size);
> +
> + if ((priv->pos + size) > buff_size) {
> + memcpy(&pcm_buff[priv->pos], src_buff, buff_size - priv->pos);
> + cur_size -= buff_size - priv->pos;
> + priv->pos = 0;
> + }
> +
> + memcpy(&pcm_buff[priv->pos], &src_buff[size - cur_size], cur_size);
> + priv->pos = (priv->pos + cur_size) % buff_size;
> +
> + if (cur_size != size || (old_pos && (old_pos % period_size < size)))
> + snd_pcm_period_elapsed(priv->substream);
> +
> + return 0;
> +}
> +
> +static int stm32_adfsdm_trigger(struct snd_pcm_substream *substream, int cmd)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct stm32_adfsdm_priv *priv =
> + snd_soc_dai_get_drvdata(rtd->cpu_dai);
> +
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_START:
> + case SNDRV_PCM_TRIGGER_RESUME:
> + priv->pos = 0;
> + return stm32_dfsdm_get_buff_cb(priv->iio_ch->indio_dev,
> + stm32_afsdm_pcm_cb, priv);
> + case SNDRV_PCM_TRIGGER_SUSPEND:
> + case SNDRV_PCM_TRIGGER_STOP:
> + return stm32_dfsdm_release_buff_cb(priv->iio_ch->indio_dev);
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int stm32_adfsdm_pcm_open(struct snd_pcm_substream *substream)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct stm32_adfsdm_priv *priv = snd_soc_dai_get_drvdata(rtd->cpu_dai);
> + int ret;
> +
> + ret = snd_soc_set_runtime_hwparams(substream, &stm32_adfsdm_pcm_hw);
> + if (!ret)
> + priv->substream = substream;
> +
> + return ret;
> +}
> +
> +static int stm32_adfsdm_pcm_close(struct snd_pcm_substream *substream)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct stm32_adfsdm_priv *priv =
> + snd_soc_dai_get_drvdata(rtd->cpu_dai);
> +
> + snd_pcm_lib_free_pages(substream);
> + priv->substream = NULL;
> +
> + return 0;
> +}
> +
> +static snd_pcm_uframes_t stm32_adfsdm_pcm_pointer(
> + struct snd_pcm_substream *substream)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct stm32_adfsdm_priv *priv =
> + snd_soc_dai_get_drvdata(rtd->cpu_dai);
> +
> + return bytes_to_frames(substream->runtime, priv->pos);
> +}
> +
> +static int stm32_adfsdm_pcm_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct stm32_adfsdm_priv *priv =
> + snd_soc_dai_get_drvdata(rtd->cpu_dai);
> + int ret;
> +
> + ret = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params));
> + if (ret < 0)
> + return ret;
> + priv->pcm_buff = substream->runtime->dma_area;
> +
> + return iio_channel_cb_set_buffer_watermark(priv->iio_cb,
> + params_period_size(params));
> +}
> +
> +static int stm32_adfsdm_pcm_hw_free(struct snd_pcm_substream *substream)
> +{
> + snd_pcm_lib_free_pages(substream);
> +
> + return 0;
> +}
> +
> +static struct snd_pcm_ops stm32_adfsdm_pcm_ops = {
> + .open = stm32_adfsdm_pcm_open,
> + .close = stm32_adfsdm_pcm_close,
> + .hw_params = stm32_adfsdm_pcm_hw_params,
> + .hw_free = stm32_adfsdm_pcm_hw_free,
> + .trigger = stm32_adfsdm_trigger,
> + .pointer = stm32_adfsdm_pcm_pointer,
> +};
> +
> +static int stm32_adfsdm_pcm_new(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_pcm *pcm = rtd->pcm;
> + struct stm32_adfsdm_priv *priv =
> + snd_soc_dai_get_drvdata(rtd->cpu_dai);
> + unsigned int size = DFSDM_MAX_PERIODS * DFSDM_MAX_PERIOD_SIZE;
> +
> + return snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
> + priv->dev, size, size);
> +}
> +
> +static void stm32_adfsdm_pcm_free(struct snd_pcm *pcm)
> +{
> + struct snd_pcm_substream *substream;
> + struct snd_soc_pcm_runtime *rtd;
> + struct stm32_adfsdm_priv *priv;
> +
> + substream = pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream;
> + if (substream) {
> + rtd = substream->private_data;
> + priv = snd_soc_dai_get_drvdata(rtd->cpu_dai);
> +
> + snd_pcm_lib_preallocate_free_for_all(pcm);
> + }
> +}
> +
> +static struct snd_soc_platform_driver stm32_adfsdm_soc_platform = {
> + .ops = &stm32_adfsdm_pcm_ops,
> + .pcm_new = stm32_adfsdm_pcm_new,
> + .pcm_free = stm32_adfsdm_pcm_free,
> +};
> +
> +static const struct of_device_id stm32_adfsdm_of_match[] = {
> + {.compatible = "st,stm32h7-dfsdm-dai"},
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, stm32_adfsdm_of_match);
> +
> +static int stm32_adfsdm_probe(struct platform_device *pdev)
> +{
> + struct stm32_adfsdm_priv *priv;
> + int ret;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = &pdev->dev;
> + priv->dai_drv = stm32_adfsdm_dai;
> +
> + dev_set_drvdata(&pdev->dev, priv);
> +
> + ret = devm_snd_soc_register_component(&pdev->dev,
> + &stm32_adfsdm_dai_component,
> + &priv->dai_drv, 1);
> + if (ret < 0)
> + return ret;
> +
> + /* Associate iio channel */
> + priv->iio_ch = devm_iio_channel_get_all(&pdev->dev);
> + if (IS_ERR(priv->iio_ch))
> + return PTR_ERR(priv->iio_ch);
> +
> + priv->iio_cb = iio_channel_get_all_cb(&pdev->dev, NULL, NULL);
> + if (IS_ERR(priv->iio_cb))
> + return PTR_ERR(priv->iio_ch);
> +
> + ret = devm_snd_soc_register_platform(&pdev->dev,
> + &stm32_adfsdm_soc_platform);
> + if (ret < 0)
> + dev_err(&pdev->dev, "%s: Failed to register PCM platform\n",
> + __func__);
> +
> + return ret;
> +}
> +
> +static struct platform_driver stm32_adfsdm_driver = {
> + .driver = {
> + .name = STM32_ADFSDM_DRV_NAME,
> + .of_match_table = stm32_adfsdm_of_match,
> + },
> + .probe = stm32_adfsdm_probe,
> +};
> +
> +module_platform_driver(stm32_adfsdm_driver);
> +
> +MODULE_DESCRIPTION("stm32 DFSDM DAI driver");
> +MODULE_AUTHOR("Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:" STM32_ADFSDM_DRV_NAME);
^ permalink raw reply
* Re: [PATCH v9 10/13] IIO: ADC: add stm32 DFSDM support for PDM microphone
From: Jonathan Cameron @ 2017-12-17 12:54 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: <1513241885-32079-11-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
On Thu, 14 Dec 2017 09:58:02 +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>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Looks good ;)
> ---
> V8 to V9
> - Create stm32_dfsdm_dma_request
> - Replace devm_of_platform_populate by of_platform_populate.
> - Reorder probe and remove sequences.
>
> .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 16 +
> drivers/iio/adc/stm32-dfsdm-adc.c | 502 ++++++++++++++++++++-
> include/linux/iio/adc/stm32-dfsdm-adc.h | 18 +
> 3 files changed, 529 insertions(+), 7 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..b03ca3f 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -6,19 +6,23 @@
> * 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/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 +62,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 +367,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 +434,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 +485,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 +765,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 +832,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 +880,70 @@ 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 void stm32_dfsdm_dma_release(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(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);
> + }
> +}
> +
> +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 = {
> + .src_addr = (dma_addr_t)adc->dfsdm->phys_base +
> + DFSDM_RDATAR(adc->fl_id),
> + .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
> + };
> + 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;
> + }
> +
> + 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 +964,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 +978,39 @@ 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;
> +
> + indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
> + indio_dev->setup_ops = &stm32_dfsdm_buffer_setup_ops;
> +
> + 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");
> + return ret;
> + }
> + 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 stm32_dfsdm_dma_request(indio_dev);
> +}
> +
> static int stm32_dfsdm_adc_init(struct iio_dev *indio_dev)
> {
> struct iio_chan_spec *ch;
> @@ -612,11 +1063,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 +1127,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 +1165,27 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> - return iio_device_register(iio);
> + ret = iio_device_register(iio);
> + if (ret < 0)
> + goto err_cleanup;
> +
> + dev_err(dev, "of_platform_populate\n");
> + if (dev_data->type == DFSDM_AUDIO) {
> + ret = of_platform_populate(np, NULL, NULL, dev);
> + if (ret < 0) {
> + dev_err(dev, "Failed to find an audio DAI\n");
> + goto err_unregister;
> + }
> + }
> +
> + return 0;
> +
> +err_unregister:
> + iio_device_unregister(iio);
> +err_cleanup:
> + stm32_dfsdm_dma_release(iio);
> +
> + return ret;
> }
>
> static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
> @@ -708,7 +1193,10 @@ static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
> struct stm32_dfsdm_adc *adc = platform_get_drvdata(pdev);
> struct iio_dev *indio_dev = iio_priv_to_dev(adc);
>
> + if (adc->dev_data->type == DFSDM_AUDIO)
> + of_platform_depopulate(&pdev->dev);
> iio_device_unregister(indio_dev);
> + stm32_dfsdm_dma_release(indio_dev);
>
> 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
--
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/RFC] DT: leds: Fix 'label' property description and add 'colour' property
From: Jacek Anaszewski @ 2017-12-17 12:49 UTC (permalink / raw)
To: Rob Herring, Pavel Machek
Cc: Linux LED Subsystem,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Sakari Ailus, Dan Murphy,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <82dc0ed3-f4fe-d8a2-65ea-4212770b78e7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
cc devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
On 12/14/2017 10:35 PM, Jacek Anaszewski wrote:
> On 12/11/2017 05:27 PM, Rob Herring wrote:
>> On Mon, Dec 4, 2017 at 4:43 AM, Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:
>>> Hi!
>>>
>>>> Label property was imposed a uniqueness requirement, which was erroneous,
>>>> since ePAPR defines it to "a human readable string describing a device".
>>
>> But it still needs to be unique to be useful. It's just unique from a
>
> This patch is a follow-up of your following statement from [0]:
>
>>>>>>>>
> I really dislike how this naming convention is used for label. label is
> supposed to be the phyically identifiable name. Having the devicename
> defeats that. Perhaps color, too. We'd be better off with a color
> property. It seems we're overloading the naming with too many things.
> Now we're adding device association.
> <<<<<<<
>
>
> In effect, I intended to remove the uniqueness requirement for the
> label since the label alone doesn't make a LED class device name
> in case of many current LED class drivers.
>
> Instead I inferred from your message that label should contain only
> LED function. Therefore I'm splitting colour (maybe color would fit
> better here, but adopted the spelling from
> Documentation/leds/leds-class.txt, to be decided which one fits better.)
>
> But see below.
>
>> different perspective. Ideally, if you had a block diagram level
>> drawing of a device or board showing LEDs (and displays with
>> backlights), you would simply take the labels from that drawing.
>>
>>>> Also the binding description misleadingly suggested direct usage of label
>>>> for LED class device name, whereas it should only define a LED function.
>>>>
>>>> Therefore an additional 'colour' property is being introduced, which together
>>>> with the parent DT node name used for devicename shall be used for naming LED
>>>> class device according to the patterh
>>>> <devicename>:<colour>:<function>.
>>>
>>>
>>>> -- label : The label for this LED. If omitted, the label is taken from the node
>>>> - name (excluding the unit address). It has to uniquely identify
>>>> - a device, i.e. no other LED class device can be assigned the same
>>>> - label.
>>>> +- label : The label for this LED. It should describe its function. If omitted,
>>>> + the label is taken from the node name (excluding the unit address).
>>>
>>> So the label contains "as1235:green:capslock"? I guess it might be
>>> nice to mention that. Or just the "capslock" part?
>>>
>>> Also.. it would be good to start pushing for more consistency in the
>>> labels: I have these on the thinkpad:
>>>
>>> input5::scrolllock/ tpacpi::dock_status2/ tpacpi::unknown_led/
>>> mmc0::/ tpacpi:green:batt/ tpacpi::unknown_led2/
>>> phy0-led/ tpacpi:orange:batt/ tpacpi::unknown_led3/
>>> tpacpi::bay_active/ tpacpi::power/
>>>
>>> On embedded system, I'd like to see <devicename> to corespond
>>> to.. device the led belongs to, as opposed to name of the chip that
>>> drives the led. Maybe we should do 'main_camera:white:flash' instead of
>>> 'as4132:white:flash' because userspace already has information on what
>>> chip it is (sysfs paths), but can not easily figure out to which
>>> device the flash belongs.
>>
>> A couple of points:
>>
>> I already mentioned DT node naming policies in the lm3692x thread, so
>> I won't repeat here.
>>
>> Using the node name is not going to guarantee uniqueness in the names.
>> Even if you added the unit address it would still not. I can easily
>> have 2 or more LED driver chips at the same I2C address on different
>> buses. The only guaranteed unique name is the full DT path. Once
>> you've added some OS specific numbering to make device names unique,
>> then I'm not sure there's a lot of value in naming things after what
>> drives them. You can walk the sysfs hierarchy to determine that
>> anyway.
>>
>> A case I care about is I have a family of boards that all have a
>> common defined set of 4 LEDs. They could be driven by anything, but I
>> want the same interface presented to userspace across boards.
>
> In effect it looks like we should drop devicename section from
> the LED class devicename pattern, label should describe only
> LED function and additional color property could be introduced,
> to be concatenated with LED function as a final LED class device
> name.
>
>
> [0] https://www.mail-archive.com/linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg119473.html
>
--
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 v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
From: Dhaval Rajeshbhai Shah @ 2017-12-17 6:07 UTC (permalink / raw)
To: Randy Dunlap, arnd-r2nGTMty4D4@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org, Hyun Kwon
In-Reply-To: <d9e263f9-827c-656d-77fd-bbbb2b172040-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Hi Randy,
Thanks a lot for the review.
> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap@infradead.org]
> Sent: Saturday, December 16, 2017 2:18 PM
> To: Dhaval Rajeshbhai Shah <DSHAH@xilinx.com>; arnd@arndb.de;
> gregkh@linuxfoundation.org; robh+dt@kernel.org; mark.rutland@arm.com
> Cc: devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> michal.simek@xilinx.com; Hyun Kwon <hyunk@xilinx.com>; Dhaval Rajeshbhai
> Shah <DSHAH@xilinx.com>
> Subject: Re: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP
> init driver
>
> On 12/14/2017 11:24 PM, Dhaval Shah wrote:
> > Xilinx ZYNQMP logicoreIP Init driver is based on the new LogiCoreIP
> > design created. This driver provides the processing system and
> > programmable logic isolation. Set the frequency based on the clock
> > information get from the logicoreIP register set.
> >
> > It is put in drivers/misc as there is no subsystem for this logicoreIP.
> >
> > Signed-off-by: Dhaval Shah <dshah@xilinx.com>
> > ---
> >
> > drivers/misc/Kconfig | 15 ++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/xlnx_vcu.c | 631
> > ++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 647 insertions(+)
> > create mode 100644 drivers/misc/xlnx_vcu.c
>
> > diff --git a/drivers/misc/xlnx_vcu.c b/drivers/misc/xlnx_vcu.c new
> > file mode 100644 index 0000000..f489d34
> > --- /dev/null
> > +++ b/drivers/misc/xlnx_vcu.c
> > @@ -0,0 +1,631 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Xilinx VCU Init
> > + *
> > + * Copyright (C) 2016 - 2017 Xilinx, Inc.
> > + *
> > + * Contacts Dhaval Shah <dshah@xilinx.com>
> > + */
> > +#include <linux/clk.h>
> > +#include <linux/device.h>
> > +#include <linux/errno.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
>
> [snip]
>
>
> > +/**
> > + * xvcu_set_vcu_pll_info - Set the VCU PLL info
> > + * @xvcu: Pointer to the xvcu_device structure
> > + *
> > + * Programming the VCU PLL based on the user configuration
> > + * (ref clock freq, core clock freq, mcu clock freq).
> > + * Core clock frequency has higher priority than mcu clock frequency
> > + * Errors in following cases
> > + * - When mcu or clock clock get from logicoreIP is 0
> > + * - When VCU PLL DIV related bits value other than 1
> > + * - When proper data not found for given data
> > + * - When sis570_1 clocksource related operation failed
> > + *
> > + * Return: Returns status, either success or error+reason
> > + */
> > +static int xvcu_set_vcu_pll_info(struct xvcu_device *xvcu) {
> > + u32 refclk, coreclk, mcuclk, inte, deci;
> > + u32 divisor_mcu, divisor_core, fvco;
> > + u32 clkoutdiv, vcu_pll_ctrl, pll_clk;
> > + u32 cfg_val, mod, ctrl;
> > + int ret;
> > + unsigned int i;
> > + const struct xvcu_pll_cfg *found = NULL;
> > +
> > + inte = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK);
> > + deci = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK_DEC);
> > + coreclk = xvcu_read(xvcu->logicore_reg_ba, VCU_CORE_CLK) * MHZ;
> > + mcuclk = xvcu_read(xvcu->logicore_reg_ba, VCU_MCU_CLK) * MHZ;
> > + if (!mcuclk || !coreclk) {
> > + dev_err(xvcu->dev, "Invalid mcu and core clock data\n");
> > + return -EINVAL;
> > + }
> > +
> > + refclk = (inte * MHZ) + (deci * (MHZ / FRAC));
> > + dev_dbg(xvcu->dev, "Ref clock from logicoreIP is %uHz\n", refclk);
> > + dev_dbg(xvcu->dev, "Core clock from logicoreIP is %uHz\n", coreclk);
> > + dev_dbg(xvcu->dev, "Mcu clock from logicoreIP is %uHz\n", mcuclk);
> > +
> > + clk_disable_unprepare(xvcu->pll_ref);
> > + ret = clk_set_rate(xvcu->pll_ref, refclk);
> > + if (ret)
> > + dev_warn(xvcu->dev, "failed to set logicoreIP refclk rate\n");
> > +
> > + ret = clk_prepare_enable(xvcu->pll_ref);
> > + if (ret) {
> > + dev_err(xvcu->dev, "failed to enable pll_ref clock source\n");
> > + return ret;
> > + }
> > +
> > + refclk = clk_get_rate(xvcu->pll_ref);
> > +
> > + /*
> > + * The divide-by-2 should be always enabled (==1)
> > + * to meet the timing in the design.
> > + * Otherwise, it's an error
> > + */
> > + vcu_pll_ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_CTRL);
> > + clkoutdiv = vcu_pll_ctrl >> VCU_PLL_CTRL_CLKOUTDIV_SHIFT;
> > + clkoutdiv = clkoutdiv && VCU_PLL_CTRL_CLKOUTDIV_MASK;
> > + if (clkoutdiv != 1) {
> > + dev_err(xvcu->dev, "clkoutdiv value is invalid\n");
> > + return -EINVAL;
> > + }
> > +
> > + for (i = ARRAY_SIZE(xvcu_pll_cfg) - 1; i > 0; i--) {
>
> When does that for loop terminate?
>
This loop will terminate either it reach to i =0 and one other case is when it find the proper expected value. Break statement is used to exit in that case.
> > + const struct xvcu_pll_cfg *cfg = &xvcu_pll_cfg[i];
> > +
> > + fvco = cfg->fbdiv * refclk;
> > + if (fvco >= FVCO_MIN && fvco <= FVCO_MAX) {
> > + pll_clk = fvco / VCU_PLL_DIV2;
> > + if (fvco % VCU_PLL_DIV2 != 0)
> > + pll_clk++;
> > + mod = pll_clk % coreclk;
> > + if (mod < LIMIT) {
> > + divisor_core = pll_clk / coreclk;
> > + } else if (coreclk - mod < LIMIT) {
> > + divisor_core = pll_clk / coreclk;
> > + divisor_core++;
> > + } else {
> > + continue;
> > + }
> > + if (divisor_core >= DIVISOR_MIN &&
> > + divisor_core <= DIVISOR_MAX) {
> > + found = cfg;
> > + divisor_mcu = pll_clk / mcuclk;
> > + mod = pll_clk % mcuclk;
> > + if (mcuclk - mod < LIMIT)
> > + divisor_mcu++;
> > + break;
This is the break statement to exit when proper value is find.
> > + }
> > + }
> > + }
> > +
> > + if (!found) {
> > + dev_err(xvcu->dev, "Invalid clock combination.\n");
> > + return -EINVAL;
> > + }
>
> [snip]
>
> --
> ~Randy
^ permalink raw reply
* [PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000
From: Jonathan Neuschäfer @ 2017-12-17 2:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Jonathan Neuschäfer, Lucas Stach, Thierry Reding,
David Airlie, Rob Herring, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The compatible string for this panel was specified as
toshiba,lt089ac29000.txt. I believe this is a mistake.
Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000")
Cc: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
---
.../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
index 4c0caaf246c9..89826116628c 100644
--- a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
+++ b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
@@ -1,7 +1,7 @@
Toshiba 8.9" WXGA (1280x768) TFT LCD panel
Required properties:
-- compatible: should be "toshiba,lt089ac29000.txt"
+- compatible: should be "toshiba,lt089ac29000"
- power-supply: as specified in the base binding
This binding is compatible with the simple-panel binding, which is specified
--
2.15.0
--
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] ARM: dts: sun8i-a83t-tbs-a711: Add missing axp813 compatible
From: megous via linux-sunxi @ 2017-12-17 1:27 UTC (permalink / raw)
To: dev-3kdeTeqwOZ9EV1b7eY7vFQ
Cc: Ondrej Jirman, Rob Herring, Mark Rutland, Russell King,
Maxime Ripard, Chen-Yu Tsai,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list
From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
Without this the AXP813 PMIC fails to probe on TBS A711.
Signed-off-by: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index e6b00b3774e3..76be9d43f906 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -479,6 +479,7 @@
status = "okay";
axp81x: pmic@3a3 {
+ compatible = "x-powers,axp813";
reg = <0x3a3>;
interrupt-parent = <&r_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v14 0/5] ZII RAVE platform driver
From: Guenter Roeck @ 2017-12-17 0:42 UTC (permalink / raw)
To: Andrey Smirnov, Lee Jones
Cc: Pavel Machek, Greg Kroah-Hartman, cphealy-Re5JQEeQqe8AvxtiuMwx3w,
Andy Shevchenko, Lucas Stach, Nikita Yushchenko, Rob Herring,
Mark Rutland, Johan Hovold, devicetree-u79uwXL29TY76Z2rM5mHXA,
Sebastian Reichel, Andrew Morton
In-Reply-To: <20171207162735.25873-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/07/2017 08:27 AM, Andrey Smirnov wrote:
> Lee:
>
> This patch set has been marinating out there for a while now and
> yours, I belive, is that last signature I need to start pushing it for
> inclusion. I'd really appreciate if you could spare some of your time
> to give it a look. Thanks!
>
> Everyone:
>
> This patch series is v14 of the driver for supervisory processor found
> on RAVE series of devices from ZII. Supervisory processor is a PIC
> microcontroller connected to various electrical subsystems on RAVE
> devices whose firmware implements protocol to command/qery them.
>
> NOTE:
>
> * This driver dependends on crc_ccitt_false(), added by
> 2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
> was pulled in by Andrew Morton and is currently avaiting users, so
> this series might have to go in through Andrew's tree
>
Strictly speaking, the solution would be for Andrew to provide an immutable
branch with the above, for Rob to provide an immutable branch based on Andrew's
branch, adding the serdev drivers, for Lee to provide yet another immutable
branch with all those plus the mfd driver, and for Wim to pick it all up
into the watchdog tree.
That seems to be a bit complicated. I would suggest for Lee to pick it all up.
If Lee is busy and ok with it, I'll be happy to pick it all up and submit to
Linus as a separate pull request during the next commit window.
Lee, Andrew, any thoughts/comments ?
Thanks,
Guenter
> Changes since [v13]:
>
> - Fixed incorrect MFD driver menuconfig entry placement
>
> Changes since [v12]:
>
> - Minor comment inconsistencies fixes in rave-sp.c
>
> Changes since [v11]:
>
> - Fix incorrect include in rave-sp-wdt.c as uncovered by kernel
> test robot
>
> Changes since [v10]:
>
> - Collected Acked-by from Rob and Reviewed-by from Guenter
>
> - Incorporated watchdog driver feedback from Gunter and Johan
>
> - Incorporated Johan's feedback for the rest of the code
>
> Changes since [v9]:
>
> - Converted watchdog driver to use watchdog_active() instead of
> watchdog_hw_running() and replaced WARN_ON with a regular error
> message as per feedback from Guenter
>
> - Changed rave_sp_wdt_start() to set WDOG_HW_RUNNING only if
> communicating with hardware was sucessful
>
> - Collected Reviewd-by from Sebastian (for serdev related patches)
>
> - Collected Acked-by from Rob (for watchdog DT bindings)
>
> Changes since [v8]:
>
> - Driver moved from drivers/platform to drivers/mfd
>
> - Collected Reviewed-by from Guenter (for patches 1, 2 and 3)
>
> - Incorporated feedback from Guenter into watchdog driver
>
> - Incorporated feedback from Rob into watchdog DT bindings
>
> - Removed struct rave_sp_rsp_status, which was a leftover from v5
> -> v6 code removal.
>
> - Fixed minor problems reported by checkpatch
>
> Changes since [v7]:
>
> - Added watchdog driver to the patchset, so it would be easier to
> understand how parent/children drivers are tied together
>
> - Added serdev patches to implement devm_serdev_device_open() and make .remove optional
>
> - "Added" missing serdev_device_close() by converting the driver
> to use devm_serdev_device_open()
>
> - Converted the driver to use devm_of_platform_populate()
>
> - Removed needless dependency on MFD_CORE
>
> - Removed dependency on SERIAL_DEV_CTRL_TTYPORT
>
> Changes since [v6]:
>
> - Patch 2/2 has been applied by Lee so it is no longer a part of the series
>
> - Removed all sysfs and debugfs attribute to reduce the scope of
> the driver propsed for inclusion. This is not a critical to have
> feature and can be added/discussed later.
>
> Changes since [v5]:
>
> - Fixed a build break, introduced by a last minute change in [v5]
>
> - Moved majority of attributes that were exposed over sysfs to debugfs
>
> - Document remaining sysfs attributes in Documentation/ABI/testing/sysfs-platform-rave-sp
>
> Changes since [v4]:
>
> - Replaced usage of DEVICE_ATTR with DEVICE_ATTR_RW
>
> - Fixed a number of warnings produces by sparse tool
>
> - Incorporated event more feedback from Andy Shevchenko
>
> - Collected Reviewed-by from Andy
>
> Changes since [v3]:
>
> - Re-collected lost Acked-by from Rob
>
> - Incorporated further feedback from Andy Shevchenko
>
> - Dropped useless change (stray newline) to drivers/mfd/Makefile
>
> Changes since [v2]:
>
> - Fixed swapped command codes in rave_sp_common_get_boot_source()
> and rave_sp_common_set_boot_source() revealed by further testing
> of the code
>
> - Incorporated feedback from Andy Shevchenko
>
> Changes since [v1]:
>
> - Updated wording in DT-bindings as per Rob's request.
>
> - Collected Rob's Acked-by for patch 2/2
>
> Feedback is greatly appreciated!
>
> Thanks,
> Andrey Smirnov
>
> [v13] lkml.kernel.org/r/20171204161118.19558-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v12] lkml.kernel.org/r/20171109160556.17018-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v11] lkml.kernel.org/r/20171106152935.16920-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v10] lkml.kernel.org/r/20171031163656.24552-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v9] lkml.kernel.org/r/20171025190421.18415-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v8] lkml.kernel.org/r/20171018170136.12347-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v7] lkml.kernel.org/r/20171013061321.31252-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v6] lkml.kernel.org/r/20170828163131.24815-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v5] lkml.kernel.org/r/20170728142704.11156-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v4] lkml.kernel.org/r/20170725184450.13171-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> [v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>
> Andrey Smirnov (5):
> serdev: Make .remove in struct serdev_device_driver optional
> serdev: Introduce devm_serdev_device_open()
> mfd: Add driver for RAVE Supervisory Processor
> watchdog: Add RAVE SP watchdog driver
> dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver
>
> .../bindings/watchdog/zii,rave-sp-wdt.txt | 39 ++
> Documentation/driver-model/devres.txt | 3 +
> drivers/mfd/Kconfig | 8 +
> drivers/mfd/Makefile | 2 +
> drivers/mfd/rave-sp.c | 660 +++++++++++++++++++++
> drivers/tty/serdev/core.c | 31 +-
> drivers/watchdog/Kconfig | 7 +
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/rave-sp-wdt.c | 357 +++++++++++
> include/linux/mfd/rave-sp.h | 56 ++
> include/linux/serdev.h | 1 +
> 11 files changed, 1163 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
> create mode 100644 drivers/mfd/rave-sp.c
> create mode 100644 drivers/watchdog/rave-sp-wdt.c
> create mode 100644 include/linux/mfd/rave-sp.h
>
--
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
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