* Re: [PATCH v3 02/11] thermal: armada: Use msleep for long delays
From: Gregory CLEMENT @ 2017-12-14 10:51 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree, Baruch Siach, linux-pm,
Antoine Tenart, Nadav Haklai, David Sniatkiwicz, linux-arm-kernel
In-Reply-To: <20171214103011.24713-3-miquel.raynal@free-electrons.com>
Hi Miquel,
On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> From: Baruch Siach <baruch@tkos.co.il>
>
> Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
> All delays are called from the probe routine, where scheduling is
> allowed.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks,
Gregory
> ---
> drivers/thermal/armada_thermal.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 706d74798cbe..6c4af2622d4f 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
> reg &= ~PMU_TDC0_START_CAL_MASK;
> writel(reg, priv->control);
>
> - mdelay(10);
> + msleep(10);
> }
>
> static void armada375_init_sensor(struct platform_device *pdev,
> @@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
> reg &= ~A375_HW_RESETn;
>
> writel(reg, priv->control + 4);
> - mdelay(20);
> + msleep(20);
>
> reg |= A375_HW_RESETn;
> writel(reg, priv->control + 4);
> - mdelay(50);
> + msleep(50);
> }
>
> static void armada380_init_sensor(struct platform_device *pdev,
> @@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
> if (!(reg & A380_HW_RESET)) {
> reg |= A380_HW_RESET;
> writel(reg, priv->control);
> - mdelay(10);
> + msleep(10);
> }
> }
>
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit
From: Gregory CLEMENT @ 2017-12-14 10:52 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree, Baruch Siach, linux-pm,
Antoine Tenart, Nadav Haklai, David Sniatkiwicz, linux-arm-kernel
In-Reply-To: <20171214103011.24713-4-miquel.raynal@free-electrons.com>
Hi Miquel,
On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> All Armada SoCs use one bit to declare if the sensor values are valid.
> This bit moves across the versions of the IP.
>
> The method until then was to do both a shift and compare with an useless
> flag of "0x1". It is clearer and quicker to directly save the value that
> must be ANDed instead of the bit position and do a single bitwise AND
> operation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks,
Gregory
> ---
> drivers/thermal/armada_thermal.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 6c4af2622d4f..26698f2d3ca7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -24,8 +24,6 @@
> #include <linux/of_device.h>
> #include <linux/thermal.h>
>
> -#define THERMAL_VALID_MASK 0x1
> -
> /* Thermal Manager Control and Status Register */
> #define PMU_TDC0_SW_RST_MASK (0x1 << 1)
> #define PMU_TM_DISABLE_OFFS 0
> @@ -67,7 +65,7 @@ struct armada_thermal_data {
> /* Register shift and mask to access the sensor temperature */
> unsigned int temp_shift;
> unsigned int temp_mask;
> - unsigned int is_valid_shift;
> + unsigned int is_valid_bit;
> };
>
> static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
> {
> unsigned long reg = readl_relaxed(priv->sensor);
>
> - return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
> + return reg & priv->data->is_valid_bit;
> }
>
> static int armada_get_temp(struct thermal_zone_device *thermal,
> @@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
> static const struct armada_thermal_data armada370_data = {
> .is_valid = armada_is_valid,
> .init_sensor = armada370_init_sensor,
> - .is_valid_shift = 9,
> + .is_valid_bit = BIT(9),
> .temp_shift = 10,
> .temp_mask = 0x1ff,
> .coef_b = 3153000000UL,
> @@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
> static const struct armada_thermal_data armada375_data = {
> .is_valid = armada_is_valid,
> .init_sensor = armada375_init_sensor,
> - .is_valid_shift = 10,
> + .is_valid_bit = BIT(10),
> .temp_shift = 0,
> .temp_mask = 0x1ff,
> .coef_b = 3171900000UL,
> @@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
> static const struct armada_thermal_data armada380_data = {
> .is_valid = armada_is_valid,
> .init_sensor = armada380_init_sensor,
> - .is_valid_shift = 10,
> + .is_valid_bit = BIT(10),
> .temp_shift = 0,
> .temp_mask = 0x3ff,
> .coef_b = 1172499100UL,
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator
From: Mauro Carvalho Chehab @ 2017-12-14 10:55 UTC (permalink / raw)
To: Takiguchi, Yasunari
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-media@vger.kernel.org,
tbird20d@gmail.com, frowand.list@gmail.com, Yamamoto, Masayuki,
Nozawa, Hideki (STWN), Yonezawa, Kota, Matsumoto, Toshihiko,
Watanabe, Satoshi (SSS), Bird, Timothy
In-Reply-To: <02699364973B424C83A42A84B04FDA85431742@JPYOKXMS113.jp.sony.com>
Em Thu, 14 Dec 2017 09:59:32 +0000
"Takiguchi, Yasunari" <Yasunari.Takiguchi@sony.com> escreveu:
> Dear Mauro
>
> Thanks for your review.
>
> We will refer to your comments and consider how to respond for them.
> I want to confirm one thing about SPDX license text
>
> We will add SPDX license text to our files,
> Is it necessary to add SPDX not only .c .h Makefile but also Kconfig?
> When I checked current files in driver/media, there is no Kconfig file which has SPDX.
SPDX is a new requirement that started late on Kernel 4.14 development
cycle (and whose initial changes were merged directly at Linus tree).
Not all existing files have it yet, as identifying the right license
on existing files is a complex task, but if you do a:
$ git grep SPDX $(find . -name Makefile) $(find . -name Kconfig)
You'll see that lot of such files have it already.
So, yes, please add it to both Makefile and Kconfig.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses
From: Gregory CLEMENT @ 2017-12-14 10:55 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree-u79uwXL29TY76Z2rM5mHXA,
Baruch Siach, linux-pm-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
Nadav Haklai, David Sniatkiwicz,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171214103011.24713-5-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Miquel,
On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
>
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks,
Gregory
> ---
> drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
> 1 file changed, 55 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 26698f2d3ca7..e5b184cee79b 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
> #define A375_HW_RESETn BIT(8)
> #define A380_HW_RESET BIT(8)
>
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN 0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET 0x0
> +#define CONTROL0_OFFSET 0x0
> +#define CONTROL1_OFFSET 0x4
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> struct armada_thermal_priv {
> - void __iomem *sensor;
> - void __iomem *control;
> + void __iomem *status;
> + void __iomem *control0;
> + void __iomem *control1;
> struct armada_thermal_data *data;
> };
>
> @@ -71,45 +80,45 @@ struct armada_thermal_data {
> static void armadaxp_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl_relaxed(priv->control);
> + reg = readl_relaxed(priv->control1);
> reg |= PMU_TDC0_OTF_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reference calibration value */
> reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reset the sensor */
> - reg = readl_relaxed(priv->control);
> - writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> + reg = readl_relaxed(priv->control1);
> + writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Enable the sensor */
> - reg = readl_relaxed(priv->sensor);
> + reg = readl_relaxed(priv->status);
> reg &= ~PMU_TM_DISABLE_MASK;
> - writel(reg, priv->sensor);
> + writel(reg, priv->status);
> }
>
> static void armada370_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl_relaxed(priv->control);
> + reg = readl_relaxed(priv->control1);
> reg |= PMU_TDC0_OTF_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reference calibration value */
> reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> reg &= ~PMU_TDC0_START_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> msleep(10);
> }
> @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
> static void armada375_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl(priv->control + 4);
> + reg = readl(priv->control1);
> reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
> reg &= ~A375_READOUT_INVERT;
> reg &= ~A375_HW_RESETn;
>
> - writel(reg, priv->control + 4);
> + writel(reg, priv->control1);
> msleep(20);
>
> reg |= A375_HW_RESETn;
> - writel(reg, priv->control + 4);
> + writel(reg, priv->control1);
> msleep(50);
> }
>
> static void armada380_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg = readl_relaxed(priv->control);
> + u32 reg = readl_relaxed(priv->control1);
>
> /* Reset hardware once */
> if (!(reg & A380_HW_RESET)) {
> reg |= A380_HW_RESET;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
> msleep(10);
> }
> }
>
> static bool armada_is_valid(struct armada_thermal_priv *priv)
> {
> - unsigned long reg = readl_relaxed(priv->sensor);
> + u32 reg = readl_relaxed(priv->status);
>
> return reg & priv->data->is_valid_bit;
> }
> @@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> int *temp)
> {
> struct armada_thermal_priv *priv = thermal->devdata;
> - unsigned long reg;
> + u32 reg;
> unsigned long m, b, div;
>
> /* Valid check */
> @@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> return -EIO;
> }
>
> - reg = readl_relaxed(priv->sensor);
> + reg = readl_relaxed(priv->status);
> reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>
> /* Get formula coeficients */
> @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>
> static int armada_thermal_probe(struct platform_device *pdev)
> {
> + void __iomem *control = NULL;
> struct thermal_zone_device *thermal;
> const struct of_device_id *match;
> struct armada_thermal_priv *priv;
> @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(priv->sensor))
> - return PTR_ERR(priv->sensor);
> + priv->status = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->status))
> + return PTR_ERR(priv->status);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - priv->control = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(priv->control))
> - return PTR_ERR(priv->control);
> + control = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(control))
> + return PTR_ERR(control);
> +
> + /*
> + * Legacy DT bindings only described "control1" register (also referred
> + * as "control MSB" on old documentation). New bindings cover
> + * "control0/control LSB" and "control1/control MSB" registers within
> + * the same resource, which is then of size 8 instead of 4.
> + */
> + if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> + /* ->control0 unavailable in this configuration */
> + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> + } else {
> + priv->control0 = control + CONTROL0_OFFSET;
> + priv->control1 = control + CONTROL1_OFFSET;
> + }
>
> priv->data = (struct armada_thermal_data *)match->data;
> priv->data->init_sensor(pdev, priv);
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/6] Add PWM and TPU support to r8a7743
From: Fabrizio Castro @ 2017-12-14 10:56 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland, Russell King,
Laurent Pinchart, Geert Uytterhoeven, Linus Walleij
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, Chris Paterson,
Biju Das, linux-pwm, devicetree, linux-renesas-soc,
linux-arm-kernel, linux-gpio
Dear All,
this series includes all that is required to add PWM and TPU SoC specific
support for the r8a7743.
Thanks,
Fabrizio Castro (6):
ARM: shmobile: defconfig: Enable PWM
dt-bindings: pwm: rcar: Document r8a774[35] PWM bindings
ARM: dts: r8a7743: Add PWM SoC support
dt-bindings: pwm: renesas-tpu: Document r8a774[35] support
pinctrl: sh-pfc: r8a7791: Add tpu groups and function
ARM: dts: r8a7743: Add TPU support
.../devicetree/bindings/pwm/renesas,pwm-rcar.txt | 10 ++-
.../devicetree/bindings/pwm/renesas,tpu-pwm.txt | 4 +-
arch/arm/boot/dts/r8a7743.dtsi | 87 ++++++++++++++++++++++
arch/arm/configs/shmobile_defconfig | 1 +
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 42 ++++++++++-
5 files changed, 138 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/6] dt-bindings: pwm: rcar: Document r8a774[35] PWM bindings
From: Fabrizio Castro @ 2017-12-14 10:56 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-pwm, devicetree, linux-renesas-soc
In-Reply-To: <1513248976-26700-1-git-send-email-fabrizio.castro@bp.renesas.com>
This patch adds compatible strings specific to r8a774[35], no driver
change is needed as the fallback compatible string will activate the
right code. Also, this patch replaces the example with a DT snippet used
for adding PWM0 support to an r8a7743 based platform.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
Dear All,
the reason for replacing the example with one of a different SoC is that
the new example refers to recent code from a real use case. I hope that's ok.
Thanks,
Fabrizio
Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
index 74c1180..f3bba59 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
+++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
@@ -2,6 +2,8 @@
Required Properties:
- compatible: should be "renesas,pwm-rcar" and one of the following.
+ - "renesas,pwm-r8a7743": for RZ/G1M
+ - "renesas,pwm-r8a7745": for RZ/G1E
- "renesas,pwm-r8a7778": for R-Car M1A
- "renesas,pwm-r8a7779": for R-Car H1
- "renesas,pwm-r8a7790": for R-Car H2
@@ -17,13 +19,15 @@ Required Properties:
- pinctrl-0: phandle, referring to a default pin configuration node.
- pinctrl-names: Set to "default".
-Example: R8A7790 (R-Car H2) PWM Timer node
+Example: R8A7743 (RZ/G1M) PWM Timer node
pwm0: pwm@e6e30000 {
- compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar";
+ compatible = "renesas,pwm-r8a7743", "renesas,pwm-rcar";
reg = <0 0xe6e30000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
#pwm-cells = <2>;
- clocks = <&mstp5_clks R8A7790_CLK_PWM>;
pinctrl-0 = <&pwm0_pins>;
pinctrl-names = "default";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/6] ARM: dts: r8a7743: Add PWM SoC support
From: Fabrizio Castro @ 2017-12-14 10:56 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Fabrizio Castro, Simon Horman, Geert Uytterhoeven, Magnus Damm,
Chris Paterson, Biju Das, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513248976-26700-1-git-send-email-fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Add the definitions for pwm[0123456] to the SoC .dtsi.
Signed-off-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
---
arch/arm/boot/dts/r8a7743.dtsi | 77 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index e056bc5..6766c76 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1080,6 +1080,83 @@
status = "disabled";
};
+ pwm0: pwm@e6e30000 {
+ compatible = "renesas,pwm-r8a7743",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e30000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@e6e31000 {
+ compatible = "renesas,pwm-r8a7743",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e31000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@e6e32000 {
+ compatible = "renesas,pwm-r8a7743",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e32000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@e6e33000 {
+ compatible = "renesas,pwm-r8a7743",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e33000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@e6e34000 {
+ compatible = "renesas,pwm-r8a7743",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e34000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@e6e35000 {
+ compatible = "renesas,pwm-r8a7743",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e35000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@e6e36000 {
+ compatible = "renesas,pwm-r8a7743",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e36000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
sdhi0: sd@ee100000 {
compatible = "renesas,sdhi-r8a7743",
"renesas,rcar-gen2-sdhi";
--
2.7.4
--
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 4/6] dt-bindings: pwm: renesas-tpu: Document r8a774[35] support
From: Fabrizio Castro @ 2017-12-14 10:56 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513248976-26700-1-git-send-email-fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Document r8a774[35] specific compatible strings. No driver change is
needed as the fallback compatible string "renesas,tpu" activates the
right code in the driver.
Signed-off-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
---
Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
index 1aadc80..16e5748 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
@@ -5,8 +5,10 @@ Required Properties:
- compatible: should be one of the following.
- "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller.
- "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller.
+ - "renesas,tpu-r8a7743": for R8A7743 (RZ/G1M) compatible PWM controller.
+ - "renesas,tpu-r8a7745": for R8A7745 (RZ/G1E) compatible PWM controller.
- "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller.
- - "renesas,tpu": for generic R-Car TPU PWM controller.
+ - "renesas,tpu": for generic R-Car and RZ/G1 TPU PWM controller.
- reg: Base address and length of each memory resource used by the PWM
controller hardware module.
--
2.7.4
--
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 6/6] ARM: dts: r8a7743: Add TPU support
From: Fabrizio Castro @ 2017-12-14 10:56 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Fabrizio Castro, Simon Horman, Geert Uytterhoeven, Magnus Damm,
Chris Paterson, Biju Das, devicetree, linux-renesas-soc,
linux-arm-kernel
In-Reply-To: <1513248976-26700-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add TPU support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 6766c76..861e76d 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1157,6 +1157,16 @@
status = "disabled";
};
+ tpu: pwm@e60f0000 {
+ compatible = "renesas,tpu-r8a7743", "renesas,tpu";
+ reg = <0 0xe60f0000 0 0x148>;
+ clocks = <&cpg CPG_MOD 304>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 304>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
sdhi0: sd@ee100000 {
compatible = "renesas,sdhi-r8a7743",
"renesas,rcar-gen2-sdhi";
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] Add PWM and TPU support to r8a7745
From: Fabrizio Castro @ 2017-12-14 10:57 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Laurent Pinchart,
Geert Uytterhoeven, Linus Walleij
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, linux-renesas-soc,
devicetree, linux-arm-kernel, linux-gpio, Chris Paterson,
Biju Das
Dear All,
this series includes all that is required to add PWM and TPU SoC specific
support for the r8a7745.
Thanks,
Fabrizio Castro (4):
pinctrl: sh-pfc: r8a7794: Add PWM[0123456] support
ARM: dts: r8a7745: Add PWM SoC support
pinctrl: sh-pfc: r8a7794: Add tpu groups and function
ARM: dts: r8a7745: Add TPU support
arch/arm/boot/dts/r8a7745.dtsi | 87 ++++++++++++
drivers/pinctrl/sh-pfc/pfc-r8a7794.c | 266 +++++++++++++++++++++++++++++++++++
2 files changed, 353 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH 2/4] ARM: dts: r8a7745: Add PWM SoC support
From: Fabrizio Castro @ 2017-12-14 10:57 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, linux-renesas-soc,
devicetree, linux-arm-kernel, Geert Uytterhoeven, Chris Paterson,
Biju Das
In-Reply-To: <1513249026-26759-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add the definitions for pwm[0123456] to the SoC .dtsi.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
This patch depends on:
* "dt-bindings: pwm: rcar: Document r8a774[35] PWM bindings"
arch/arm/boot/dts/r8a7745.dtsi | 77 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 765a80d..b945300 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -966,6 +966,83 @@
status = "disabled";
};
+ pwm0: pwm@e6e30000 {
+ compatible = "renesas,pwm-r8a7745",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e30000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@e6e31000 {
+ compatible = "renesas,pwm-r8a7745",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e31000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@e6e32000 {
+ compatible = "renesas,pwm-r8a7745",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e32000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@e6e33000 {
+ compatible = "renesas,pwm-r8a7745",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e33000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@e6e34000 {
+ compatible = "renesas,pwm-r8a7745",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e34000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@e6e35000 {
+ compatible = "renesas,pwm-r8a7745",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e35000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@e6e36000 {
+ compatible = "renesas,pwm-r8a7745",
+ "renesas,pwm-rcar";
+ reg = <0 0xe6e36000 0 0x8>;
+ clocks = <&cpg CPG_MOD 523>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 523>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
sdhi0: sd@ee100000 {
compatible = "renesas,sdhi-r8a7745",
"renesas,rcar-gen2-sdhi";
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: r8a7745: Add TPU support
From: Fabrizio Castro @ 2017-12-14 10:57 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, linux-renesas-soc,
devicetree, linux-arm-kernel, Geert Uytterhoeven, Chris Paterson,
Biju Das
In-Reply-To: <1513249026-26759-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add TPU support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
This patch depends on:
* "dt-bindings: pwm: renesas-tpu: Document r8a774[35]"
arch/arm/boot/dts/r8a7745.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index b945300..85f7875 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -1043,6 +1043,16 @@
status = "disabled";
};
+ tpu: pwm@e60f0000 {
+ compatible = "renesas,tpu-r8a7745", "renesas,tpu";
+ reg = <0 0xe60f0000 0 0x148>;
+ clocks = <&cpg CPG_MOD 304>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 304>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
sdhi0: sd@ee100000 {
compatible = "renesas,sdhi-r8a7745",
"renesas,rcar-gen2-sdhi";
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 05/11] thermal: armada: Add support for Armada AP806
From: Gregory CLEMENT @ 2017-12-14 11:05 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree-u79uwXL29TY76Z2rM5mHXA,
Baruch Siach, linux-pm-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
Nadav Haklai, David Sniatkiwicz,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171214103011.24713-6-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Miquel,
On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>
> The AP806 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> The thermal sensor sample field on the status register is a signed
> value. Extend armada_get_temp() to handle signed values.
>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Maybe you should mention that you have made some changes at least to be
able to use the previous modification you have done.
> ---
> drivers/thermal/armada_thermal.c | 51 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index e5b184cee79b..279d01937bb8 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -47,6 +47,11 @@
> #define CONTROL0_OFFSET 0x0
> #define CONTROL1_OFFSET 0x4
>
> +/* TSEN refers to the temperature sensors within the AP */
> +#define CONTROL0_TSEN_START BIT(0)
> +#define CONTROL0_TSEN_RESET BIT(1)
> +#define CONTROL0_TSEN_ENABLE BIT(2)
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -70,6 +75,7 @@ struct armada_thermal_data {
> unsigned long coef_m;
> unsigned long coef_div;
> bool inverted;
> + bool signed_sample;
>
> /* Register shift and mask to access the sensor temperature */
> unsigned int temp_shift;
> @@ -154,6 +160,24 @@ static void armada380_init_sensor(struct platform_device *pdev,
> }
> }
>
> +static void armada_ap806_init_sensor(struct platform_device *pdev,
> + struct armada_thermal_priv *priv)
> +{
> + u32 reg;
> +
> + if (!priv->control0) {
> + dev_err(&pdev->dev,
> + "Cannot access to control0 (control LSB) register\n");
> + return;
> + }
> +
> + reg = readl_relaxed(priv->control0);
> + reg &= ~CONTROL0_TSEN_RESET;
> + reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> + writel(reg, priv->control0);
> + msleep(10);
> +}
> +
> static bool armada_is_valid(struct armada_thermal_priv *priv)
> {
> u32 reg = readl_relaxed(priv->status);
> @@ -167,6 +191,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> struct armada_thermal_priv *priv = thermal->devdata;
> u32 reg;
> unsigned long m, b, div;
> + int sample;
>
> /* Valid check */
> if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> @@ -177,6 +202,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>
> reg = readl_relaxed(priv->status);
> reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
> + if (priv->data->signed_sample)
> + /* The most significant bit is the sign bit */
> + sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
> + else
> + sample = reg;
>
> /* Get formula coeficients */
> b = priv->data->coef_b;
> @@ -184,9 +214,9 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> div = priv->data->coef_div;
>
> if (priv->data->inverted)
> - *temp = ((m * reg) - b) / div;
> + *temp = ((m * sample) - b) / div;
> else
> - *temp = (b - (m * reg)) / div;
> + *temp = (b - (m * sample)) / div;
> return 0;
> }
>
> @@ -237,6 +267,19 @@ static const struct armada_thermal_data armada380_data = {
> .inverted = true,
> };
>
> +static const struct armada_thermal_data armada_ap806_data = {
> + .is_valid = armada_is_valid,
> + .init_sensor = armada_ap806_init_sensor,
> + .is_valid_bit = BIT(16),
> + .temp_shift = 0,
> + .temp_mask = 0x3ff,
> + .coef_b = -150000,
Don't you expect any side effect by storing a negative value in a
unsigned variable?
Thanks,
Gregory
> + .coef_m = 423UL,
> + .coef_div = 1,
> + .inverted = true,
> + .signed_sample = true,
> +};
> +
> static const struct of_device_id armada_thermal_id_table[] = {
> {
> .compatible = "marvell,armadaxp-thermal",
> @@ -255,6 +298,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
> .data = &armada380_data,
> },
> {
> + .compatible = "marvell,armada-ap806-thermal",
> + .data = &armada_ap806_data,
> + },
> + {
> /* sentinel */
> },
> };
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Matthias Brugger @ 2017-12-14 11:10 UTC (permalink / raw)
To: Michael Turquette, linux-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: sboyd-sgV2jX0FEOL9JmXXK+q4OQ, sean.wang-NuS5LvNUpcJWk0Htik3J/w,
chen.zhong-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171201120708.30129-1-matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Stephen, Michael,
On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> The ethsys registers a reset controller, so we need to specify a
> reset cell. This patch fixes the documentation.
>
> Signed-off-by: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> index 7aa3fa167668..6cc7840ff37a 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> @@ -20,4 +20,5 @@ ethsys: clock-controller@1b000000 {
> compatible = "mediatek,mt2701-ethsys", "syscon";
> reg = <0 0x1b000000 0 0x1000>;
> #clock-cells = <1>;
> + #reset-cells = <1>;
> };
>
Will you take this patch through the clk tree, or shall I take it through my SoC
tree?
Regards,
Matthias
--
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 v3 06/11] thermal: armada: Add support for Armada CP110
From: Gregory CLEMENT @ 2017-12-14 11:11 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree-u79uwXL29TY76Z2rM5mHXA,
Baruch Siach, linux-pm-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
Nadav Haklai, David Sniatkiwicz,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171214103011.24713-7-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Miquel,
On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>
> The CP110 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: renamed the register pointers]
Actually you did more thant this see below
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/thermal/armada_thermal.c | 30 ++++++++++++++++++++++++------
> 1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 279d01937bb8..f5c911524656 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -37,7 +37,6 @@
> #define A375_UNIT_CONTROL_MASK 0x7
> #define A375_READOUT_INVERT BIT(15)
> #define A375_HW_RESETn BIT(8)
> -#define A380_HW_RESET BIT(8)
>
> /* Legacy bindings */
> #define LEGACY_CONTROL_MEM_LEN 0x4
> @@ -52,6 +51,10 @@
> #define CONTROL0_TSEN_RESET BIT(1)
> #define CONTROL0_TSEN_ENABLE BIT(2)
>
> +/* EXT_TSEN refers to the external temperature sensors, out of the AP */
> +#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
> +#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
You added or rename these values
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
> u32 reg = readl_relaxed(priv->control1);
>
> /* Reset hardware once */
> - if (!(reg & A380_HW_RESET)) {
> - reg |= A380_HW_RESET;
> - writel(reg, priv->control1);
> - msleep(10);
> - }
> + reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> + reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> + writel(reg, priv->control1);
And here you modified the behavior of this function.
Did you checked that it is valid for Armada 38x?
Given the comment we had, I thought we should not do anything if
CONTROL1_EXT_TSEN_HW_RESETn was not set.
By the way, if the new sequence is valid, this comment should be removed
or at least updated.
Gregory
> + msleep(10);
> }
>
> static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -280,6 +282,18 @@ static const struct armada_thermal_data armada_ap806_data = {
> .signed_sample = true,
> };
>
> +static const struct armada_thermal_data armada_cp110_data = {
> + .is_valid = armada_is_valid,
> + .init_sensor = armada380_init_sensor,
> + .is_valid_bit = BIT(10),
> + .temp_shift = 0,
> + .temp_mask = 0x3ff,
> + .coef_b = 1172499100UL,
> + .coef_m = 2000096UL,
> + .coef_div = 4201,
> + .inverted = true,
> +};
> +
> static const struct of_device_id armada_thermal_id_table[] = {
> {
> .compatible = "marvell,armadaxp-thermal",
> @@ -302,6 +316,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
> .data = &armada_ap806_data,
> },
> {
> + .compatible = "marvell,armada-cp110-thermal",
> + .data = &armada_cp110_data,
> + },
> + {
> /* sentinel */
> },
> };
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 v3 07/11] thermal: armada: Update Kconfig and module description
From: Gregory CLEMENT @ 2017-12-14 11:13 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree-u79uwXL29TY76Z2rM5mHXA,
Baruch Siach, linux-pm-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
Nadav Haklai, David Sniatkiwicz,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171214103011.24713-8-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Miquel,
On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Update Armada thermal driver Kconfig entry as well as the driver's
> MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
> eg. Armada 7K and Armada 8K.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/thermal/Kconfig | 4 ++--
> drivers/thermal/armada_thermal.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 315ae2926e20..44cad046f272 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -301,13 +301,13 @@ config DB8500_THERMAL
> thermal zone if trip points reached.
>
> config ARMADA_THERMAL
> - tristate "Armada 370/XP thermal management"
> + tristate "Armada 370/XP/7K/8K thermal management"
if you want to be exhaustive you should also add Armada 375 and 38x.
> depends on ARCH_MVEBU || COMPILE_TEST
> depends on HAS_IOMEM
> depends on OF
> help
> Enable this option if you want to have support for thermal management
> - controller present in Armada 370 and Armada XP SoC.
> + controller present in Armada 370, Armada XP, Armada 7K/8K
> SoCs.
here as well.
Gregory
>
> config DA9062_THERMAL
> tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index f5c911524656..da58a8961a37 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -403,5 +403,5 @@ static struct platform_driver armada_thermal_driver = {
> module_platform_driver(armada_thermal_driver);
>
> MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
> -MODULE_DESCRIPTION("Armada 370/XP thermal driver");
> +MODULE_DESCRIPTION("Armada SoCs thermal driver");
> MODULE_LICENSE("GPL v2");
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC
From: Matthias Brugger @ 2017-12-14 11:16 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w, Ulf Hansson,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4f06b509e1e3d4cf5578841cfcf7ec966afd2d48.1512628593.git.sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hi Ulf,
On 12/07/2017 07:43 AM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 72d2a73..9b80176 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -12,6 +12,8 @@ Required properties:
> "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> + "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
> +
> - reg: physical base address of the controller and length
> - interrupts: Should contain MSDC interrupt number
> - clocks: Should contain phandle for the clock feeding the MMC controller
>
Are you fine to take this patch through your branch, or shall I take it through
mine?
@Sean it seems you forgot to send this patch to Ulf as well. In the future
please take care to send the patch to all relevant people and mailinglist.
Thanks,
Matthias
--
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 v3 07/11] thermal: armada: Update Kconfig and module description
From: Miquel RAYNAL @ 2017-12-14 11:17 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree-u79uwXL29TY76Z2rM5mHXA,
Baruch Siach, linux-pm-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
Nadav Haklai, David Sniatkiwicz,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <87po7ho93k.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Gregory,
On Thu, 14 Dec 2017 12:13:51 +0100
Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Miquel,
>
> On jeu., déc. 14 2017, Miquel Raynal
> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > Update Armada thermal driver Kconfig entry as well as the driver's
> > MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
> > eg. Armada 7K and Armada 8K.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > drivers/thermal/Kconfig | 4 ++--
> > drivers/thermal/armada_thermal.c | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index 315ae2926e20..44cad046f272 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
> > thermal zone if trip points reached.
> >
> > config ARMADA_THERMAL
> > - tristate "Armada 370/XP thermal management"
> > + tristate "Armada 370/XP/7K/8K thermal management"
> if you want to be exhaustive you should also add Armada 375 and 38x.
That is right, both are missing from the description, but wouldn't it
be better to just state "Armada SoCs" instead of patching that file
everythime a new SoC reuses this IP?
Thanks,
Miquèl
--
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 3/3] arm: dts: mt2701: Add reset-cells
From: Matthias Brugger @ 2017-12-14 11:17 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux
Cc: sboyd, sean.wang, chen.zhong, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20171201120708.30129-3-matthias.bgg@gmail.com>
On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> The hifsys and ethsys needs the definition of the reset-cells
> property. Fix this.
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 965ddfbc9953..05557fce0f1d 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -604,6 +604,7 @@
> compatible = "mediatek,mt2701-hifsys", "syscon";
> reg = <0 0x1a000000 0 0x1000>;
> #clock-cells = <1>;
> + #reset-cells = <1>;
> };
>
> usb0: usb@1a1c0000 {
> @@ -688,6 +689,7 @@
> compatible = "mediatek,mt2701-ethsys", "syscon";
> reg = <0 0x1b000000 0 0x1000>;
> #clock-cells = <1>;
> + #reset-cells = <1>;
> };
>
> eth: ethernet@1b100000 {
>
2 and 3 pushed to v4.15-next/dts32
Thanks!
^ permalink raw reply
* Re: [PATCH v2 3/3] arm: dts: mt7623: fix card detection issue on bananapi-r2
From: Matthias Brugger @ 2017-12-14 11:17 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e71b755467ce9a1f8bf78e2b6cd2e1b63e8338cd.1512628593.git.sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On 12/07/2017 07:43 AM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Fix that bananapi-r2 booting from SD-card would fail since incorrect
> polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.
>
> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Tested-by: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index 688a863..7bf5aa2 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -204,7 +204,7 @@
> bus-width = <4>;
> max-frequency = <50000000>;
> cap-sd-highspeed;
> - cd-gpios = <&pio 261 0>;
> + cd-gpios = <&pio 261 GPIO_ACTIVE_LOW>;
> vmmc-supply = <&mt6323_vmch_reg>;
> vqmmc-supply = <&mt6323_vio18_reg>;
> };
>
2 and 3 pushed to v4.15-next/dts32
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] PCI: qcom: add missing supplies required for msm8996
From: Srinivas Kandagatla @ 2017-12-14 11:19 UTC (permalink / raw)
To: Stanimir Varbanov, stanimir.varbanov, linux-pci, bhelgaas
Cc: linux-arm-msm, linux-kernel, robh+dt, devicetree, Bjorn Helgaas
In-Reply-To: <4fd5f3e7-73f6-ad63-c961-47f1f0fac149@mm-sol.com>
On 14/12/17 10:06, Stanimir Varbanov wrote:
> Hi Srini,
>
> On 12/08/2017 11:20 AM, srinivas.kandagatla@linaro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>
>> This patch adds supplies that are required for msm8996. Two of them vdda
>> and vdda-1p8 are analog supplies that go in to controller, and the rest
>
> According to the msm8996 device specification there are two pins related
> to the PCIe power: VDD_PCIE_CORE (power for PCIe core circuitry) and
> VDD_PCIE_1P8 (power for PCIe I/O circuitry). Thus I think it is clear
> that VDD_PCIE_CORE is vdda and VDD_PCIE_1P8 should be part of PCIe phy
> driver DT binding (and this is the case currently [1]). So I don't think
> we need vdda-1p8 regulator DT binding for that in pcie-qcom.
Sure I will remove it.
>
>> of the two vddpe's are supplies to PCIe endpoints.
>
> For this part I'm still not sure. On first sight it looks that these
> vdd's should be part of endpoint drivers, on the other hand we have
> mPCIe connector (on db820c) which has two power rails 3p3v and 1p5v
> which should be controlled/enabled as well.
>
Yes, these would be populated in DT as part of vddpe supplies for that lane.
> So I'd like to hear more opinions on that, i.e. how this is solved by
> the other PCIe bridge drivers.
I would be keen on knowing more options to solve this neatly too!!
This is only problem with DT and PCIE device discovery to start with!!
We are in catch 22 situation, where in we can not enumerate device
without it actually powering up.
All the other controllers like SDIO, MMC use something similar to enable
these regulators. SDIO actually uses pwrseq to do this.
There was attempt to generalize pwrseq to other subsystems, not sure
where it landed.
As of today, the only way to power up endpoint in sync with reset is via
controller driver, all other ways we would end up doing reset out of
sync with power which are error prone.
>
>> - phys:
>> Usage: required for apq8084
>> @@ -205,6 +219,8 @@
>> Value type: <prop-encoded-array>
>> Definition: List of phandle and GPIO specifier pairs. Should contain
>> - "perst-gpios" PCIe endpoint reset signal line
>> + - "pe_en-gpios" PCIe endpoint enable signal line
>> + - "pe_en1-gpios" PCIe endpoint enable1 signal line
>
> those two shouldn't be here, instead they should be part of regulator DT
> node, so please drop them.
Yes, I can drop them for now!
>
>> - "wake-gpios" PCIe endpoint wake signal line
>>
>> * Example for ipq/apq8064
>> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
>> index 952a4fc4bf3c..01488f90da31 100644
>> --- a/drivers/pci/dwc/pcie-qcom.c
>> +++ b/drivers/pci/dwc/pcie-qcom.c
>> @@ -109,13 +109,15 @@ struct qcom_pcie_resources_1_0_0 {
>> struct reset_control *core;
>> struct regulator *vdda;
>> };
>> -
>> +#define QCOM_PCIE_MAX_SUPPLY 4
>> struct qcom_pcie_resources_2_3_2 {
>> struct clk *aux_clk;
>> struct clk *master_clk;
>> struct clk *slave_clk;
>> struct clk *cfg_clk;
>> struct clk *pipe_clk;
>> + int num_supplies;
>> + struct regulator_bulk_data supplies[QCOM_PCIE_MAX_SUPPLY];
>> };
>>
>> struct qcom_pcie_resources_2_4_0 {
>> @@ -529,6 +531,17 @@ static int qcom_pcie_get_resources_2_3_2(struct qcom_pcie *pcie)
>> struct qcom_pcie_resources_2_3_2 *res = &pcie->res.v2_3_2;
>> struct dw_pcie *pci = pcie->pci;
>> struct device *dev = pci->dev;
>> + int ret;
>> +
>> + res->supplies[0].supply = "vdda";
>> + res->supplies[1].supply = "vdda-1p8";
>> + res->supplies[2].supply = "vddpe";
>> + res->supplies[3].supply = "vddpe1";
>> + res->num_supplies = QCOM_PCIE_MAX_SUPPLY;
>> + ret = devm_regulator_bulk_get(dev, QCOM_PCIE_MAX_SUPPLY,
>> + res->supplies);
>
> If we decide to go on this direction we need to replace this with
> devm_regulator_bulk_get_optional (yes I know there is no such regulator
> API yet) because they are optional in the DT binding.
I think the api name is misleading here, actually
devm_regulator_bulk_get() will return dummy regulators if the regulators
are not present, so code as it is Okay. On the other hand *_optonal api
would fail.
thanks,
srini
>
> <snip>
>
^ permalink raw reply
* [PATCH v5] i2c: Add support for NXP PCA984x family.
From: Adrian Fiergolski @ 2017-12-14 11:20 UTC (permalink / raw)
To: peda-koto5C5qi+TLoDKTGw+V6w
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Adrian Fiergolski
In-Reply-To: <990e4a1f-a9ac-c899-0075-ae3211ff9475-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
This patch extends the current i2c-mux-pca954x driver and adds support for
a newer PCA984x family of the I2C switches and multiplexers from NXP.
Signed-off-by: Adrian Fiergolski <adrian.fiergolski-vJEk5272eHo@public.gmane.org>
---
I have applied recent Peter's comments.
I am waiting for comments from device-tree folks regarding compatibles.
.../devicetree/bindings/i2c/i2c-mux-pca954x.txt | 5 ++-
drivers/i2c/muxes/Kconfig | 6 ++--
drivers/i2c/muxes/i2c-mux-pca954x.c | 36 +++++++++++++++++++---
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index aa097045a10e..b428bc0d81b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -1,10 +1,13 @@
* NXP PCA954x I2C bus switch
+The driver supports NXP PCA954x and PCA984x I2C mux/switch devices.
+
Required Properties:
- compatible: Must contain one of the following.
"nxp,pca9540", "nxp,pca9542", "nxp,pca9543", "nxp,pca9544",
- "nxp,pca9545", "nxp,pca9546", "nxp,pca9547", "nxp,pca9548"
+ "nxp,pca9545", "nxp,pca9546", "nxp,pca9547", "nxp,pca9548",
+ "nxp,pca9846", "nxp,pca9847", "nxp,pca9848", "nxp,pca9849"
- reg: The I2C address of the device.
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 0f5c8fc36625..52a4a922e7e6 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -64,11 +64,11 @@ config I2C_MUX_PCA9541
will be called i2c-mux-pca9541.
config I2C_MUX_PCA954x
- tristate "Philips PCA954x I2C Mux/switches"
+ tristate "NXP PCA954x and PCA984x I2C Mux/switches"
depends on GPIOLIB || COMPILE_TEST
help
- If you say yes here you get support for the Philips PCA954x
- I2C mux/switch devices.
+ If you say yes here you get support for the NXP PCA954x
+ and PCA984x I2C mux/switch devices.
This driver can also be built as a module. If so, the module
will be called i2c-mux-pca954x.
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 2ca068d8b92d..9796bd7d61d5 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -4,11 +4,11 @@
* Copyright (c) 2008-2009 Rodolfo Giometti <giometti-k2GhghHVRtY@public.gmane.org>
* Copyright (c) 2008-2009 Eurotech S.p.A. <info-ymFC7zkAqBI1GQ1Ptb7lUw@public.gmane.org>
*
- * This module supports the PCA954x series of I2C multiplexer/switch chips
- * made by Philips Semiconductors.
+ * This module supports the PCA954x and PCA954x series of I2C multiplexer/switch
+ * chips made by NXP Semiconductors.
* This includes the:
- * PCA9540, PCA9542, PCA9543, PCA9544, PCA9545, PCA9546, PCA9547
- * and PCA9548.
+ * PCA9540, PCA9542, PCA9543, PCA9544, PCA9545, PCA9546, PCA9547,
+ * PCA9548, PCA9846, PCA9847, PCA9848 and PCA9849.
*
* These chips are all controlled via the I2C bus itself, and all have a
* single 8-bit register. The upstream "parent" bus fans out to two,
@@ -63,6 +63,10 @@ enum pca_type {
pca_9546,
pca_9547,
pca_9548,
+ pca_9846,
+ pca_9847,
+ pca_9848,
+ pca_9849,
};
struct chip_desc {
@@ -129,6 +133,22 @@ static const struct chip_desc chips[] = {
.nchans = 8,
.muxtype = pca954x_isswi,
},
+ [pca_9846] = {
+ .nchans = 4,
+ .muxtype = pca954x_isswi,
+ },
+ [pca_9847] = {
+ .nchans = 8,
+ .muxtype = pca954x_ismux,
+ },
+ [pca_9848] = {
+ .nchans = 8,
+ .muxtype = pca954x_isswi,
+ },
+ [pca_9849] = {
+ .nchans = 4,
+ .muxtype = pca954x_ismux,
+ },
};
static const struct i2c_device_id pca954x_id[] = {
@@ -140,6 +160,10 @@ static const struct i2c_device_id pca954x_id[] = {
{ "pca9546", pca_9546 },
{ "pca9547", pca_9547 },
{ "pca9548", pca_9548 },
+ { "pca9846", pca_9846 },
+ { "pca9847", pca_9847 },
+ { "pca9848", pca_9848 },
+ { "pca9849", pca_9849 },
{ }
};
MODULE_DEVICE_TABLE(i2c, pca954x_id);
@@ -154,6 +178,10 @@ static const struct of_device_id pca954x_of_match[] = {
{ .compatible = "nxp,pca9546", .data = &chips[pca_9546] },
{ .compatible = "nxp,pca9547", .data = &chips[pca_9547] },
{ .compatible = "nxp,pca9548", .data = &chips[pca_9548] },
+ { .compatible = "nxp,pca9846", .data = &chips[pca_9846] },
+ { .compatible = "nxp,pca9847", .data = &chips[pca_9847] },
+ { .compatible = "nxp,pca9848", .data = &chips[pca_9848] },
+ { .compatible = "nxp,pca9849", .data = &chips[pca_9849] },
{}
};
MODULE_DEVICE_TABLE(of, pca954x_of_match);
--
2.14.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 v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback
From: Gregory CLEMENT @ 2017-12-14 11:23 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree, Baruch Siach, linux-pm,
Antoine Tenart, Nadav Haklai, David Sniatkiwicz, linux-arm-kernel
In-Reply-To: <20171214103011.24713-10-miquel.raynal@free-electrons.com>
Hi Miquel,
On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> The thermal core will check for sensors validity right after the
> initialization callback has returned. As the initialization routine make
> a reset, the sensors are not ready immediately and the core spawns an
> error in the dmesg. Avoid this annoying situation by polling on the
> validity bit before exiting from these routines. This also avoid the use
> of blind sleeps.
You only modified the armada 380 and ap806 init function. Does it means
that this feature is not supported on the other variant?
Gregory
>
> Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index be141ca53e83..1c4122f7377c 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -23,6 +23,7 @@
> #include <linux/platform_device.h>
> #include <linux/of_device.h>
> #include <linux/thermal.h>
> +#include <linux/iopoll.h>
>
> /* Thermal Manager Control and Status Register */
> #define PMU_TDC0_SW_RST_MASK (0x1 << 1)
> @@ -59,6 +60,9 @@
> #define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
> #define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
>
> +#define STATUS_POLL_PERIOD_US 1000
> +#define STATUS_POLL_TIMEOUT_US 100000
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -154,6 +158,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
> msleep(50);
> }
>
> +static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
> +{
> + u32 reg;
> +
> + readl_relaxed_poll_timeout(priv->status, reg,
> + reg & priv->data->is_valid_bit,
> + STATUS_POLL_PERIOD_US,
> + STATUS_POLL_TIMEOUT_US);
> +}
> +
> static void armada380_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> @@ -163,7 +177,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
> reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> writel(reg, priv->control1);
> - msleep(10);
>
> /* Set Tsen Tc Trim to correct default value (errata #132698) */
> if (priv->control0) {
> @@ -171,8 +184,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
> reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
> reg |= CONTROL0_TSEN_TC_TRIM_VAL;
> writel(reg, priv->control0);
> - msleep(10);
> }
> +
> + /* Wait the sensors to be valid or the core will warn the user */
> + armada_wait_sensor_validity(priv);
> }
>
> static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -190,7 +205,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
> reg &= ~CONTROL0_TSEN_RESET;
> reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> writel(reg, priv->control0);
> - msleep(10);
> +
> + /* Wait the sensors to be valid or the core will warn the user */
> + armada_wait_sensor_validity(priv);
> }
>
> static bool armada_is_valid(struct armada_thermal_priv *priv)
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback
From: Miquel RAYNAL @ 2017-12-14 11:27 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree, Baruch Siach, linux-pm,
Antoine Tenart, Nadav Haklai, David Sniatkiwicz, linux-arm-kernel
In-Reply-To: <87ind9o8o0.fsf@free-electrons.com>
On Thu, 14 Dec 2017 12:23:11 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Miquel,
>
> On jeu., déc. 14 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
>
> > The thermal core will check for sensors validity right after the
> > initialization callback has returned. As the initialization routine
> > make a reset, the sensors are not ready immediately and the core
> > spawns an error in the dmesg. Avoid this annoying situation by
> > polling on the validity bit before exiting from these routines.
> > This also avoid the use of blind sleeps.
>
> You only modified the armada 380 and ap806 init function. Does it
> means that this feature is not supported on the other variant?
I can't tell for other boards, It does not seem they actually need it
so I did not hacked their init callback. Should I? IMOH, if there is
not problem, there is no fix to add neither.
Miquèl
^ permalink raw reply
* Re: [PATCH v3 07/11] thermal: armada: Update Kconfig and module description
From: Gregory CLEMENT @ 2017-12-14 11:30 UTC (permalink / raw)
To: Miquel RAYNAL
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree, Baruch Siach, linux-pm,
Antoine Tenart, Nadav Haklai, David Sniatkiwicz, linux-arm-kernel
In-Reply-To: <20171214121706.529f9652@xps13>
Hi Miquel,
On jeu., déc. 14 2017, Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:
> Hi Gregory,
>
> On Thu, 14 Dec 2017 12:13:51 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
>> Hi Miquel,
>>
>> On jeu., déc. 14 2017, Miquel Raynal
>> <miquel.raynal@free-electrons.com> wrote:
>>
>> > Update Armada thermal driver Kconfig entry as well as the driver's
>> > MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
>> > eg. Armada 7K and Armada 8K.
>> >
>> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
>> > ---
>> > drivers/thermal/Kconfig | 4 ++--
>> > drivers/thermal/armada_thermal.c | 2 +-
>> > 2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> > index 315ae2926e20..44cad046f272 100644
>> > --- a/drivers/thermal/Kconfig
>> > +++ b/drivers/thermal/Kconfig
>> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
>> > thermal zone if trip points reached.
>> >
>> > config ARMADA_THERMAL
>> > - tristate "Armada 370/XP thermal management"
>> > + tristate "Armada 370/XP/7K/8K thermal management"
>> if you want to be exhaustive you should also add Armada 375 and 38x.
>
> That is right, both are missing from the description, but wouldn't it
> be better to just state "Armada SoCs" instead of patching that file
> everythime a new SoC reuses this IP?
Unfortunately Armada SoCs is more that just these SoC!
Have a look on Documentation/arm/Marvell/README to see how the Marvell
marketing guys had been creative :)
Some kirkwood are called Armada 300 and Armada 310.
The Dove is also called Armada 510.
Some PXA are called Armada too such as Armada 168 or Armada 610.
And finally the Berlin also use Aramda as code name: Armada 1000 or
Aramda 1500
Gregory
>
> Thanks,
> Miquèl
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ 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