* [PATCH v3 1/9] spi: dt-bindings: cdns,qspi-nor: sort compatibles alphabetically
From: Théo Lebrun @ 2024-04-10 9:29 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vaishnav Achath, Thomas Bogendoerfer, Rob Herring
Cc: linux-spi, devicetree, linux-kernel, linux-mips,
Vladimir Kondratiev, Gregory CLEMENT, Thomas Petazzoni,
Tawfik Bayouk, Théo Lebrun, Krzysztof Kozlowski
In-Reply-To: <20240410-cdns-qspi-mbly-v3-0-7b7053449cf7@bootlin.com>
Compatibles are ordered by date of addition.
Switch to (deterministic) alphabetical ordering.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index cca81f89e252..b865d4cc25cc 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -68,12 +68,12 @@ properties:
- items:
- enum:
- amd,pensando-elba-qspi
- - ti,k2g-qspi
- - ti,am654-ospi
- intel,lgm-qspi
- - xlnx,versal-ospi-1.0
- intel,socfpga-qspi
- starfive,jh7110-qspi
+ - ti,am654-ospi
+ - ti,k2g-qspi
+ - xlnx,versal-ospi-1.0
- const: cdns,qspi-nor
- const: cdns,qspi-nor
--
2.44.0
^ permalink raw reply related
* [PATCH v3 2/9] spi: dt-bindings: cdns,qspi-nor: add mobileye,eyeq5-ospi compatible
From: Théo Lebrun @ 2024-04-10 9:29 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vaishnav Achath, Thomas Bogendoerfer, Rob Herring
Cc: linux-spi, devicetree, linux-kernel, linux-mips,
Vladimir Kondratiev, Gregory CLEMENT, Thomas Petazzoni,
Tawfik Bayouk, Théo Lebrun, Krzysztof Kozlowski
In-Reply-To: <20240410-cdns-qspi-mbly-v3-0-7b7053449cf7@bootlin.com>
Add Mobileye EyeQ5 compatible.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index b865d4cc25cc..587baf35e4e3 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -70,6 +70,7 @@ properties:
- amd,pensando-elba-qspi
- intel,lgm-qspi
- intel,socfpga-qspi
+ - mobileye,eyeq5-ospi
- starfive,jh7110-qspi
- ti,am654-ospi
- ti,k2g-qspi
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v12 4/7] drm/meson: gate px_clk when setting rate
From: Nicolas Belin @ 2024-04-10 9:41 UTC (permalink / raw)
To: Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-4-99ecdfdc87fc@linaro.org>
Le mer. 3 avr. 2024 à 09:46, Neil Armstrong
<neil.armstrong@linaro.org> a écrit :
>
> Disable the px_clk when setting the rate to recover a fully
> configured and correctly reset VCLK clock tree after the rate
> is set.
>
> Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> index a6bc1bdb3d0d..a10cff3ca1fe 100644
> --- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> @@ -95,6 +95,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> return ret;
> }
>
> + clk_disable_unprepare(mipi_dsi->px_clk);
> ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
>
> if (ret) {
> @@ -103,6 +104,12 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> return ret;
> }
>
> + ret = clk_prepare_enable(mipi_dsi->px_clk);
> + if (ret) {
> + dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret %d)\n", ret);
> + return ret;
> + }
> +
> switch (mipi_dsi->dsi_device->format) {
> case MIPI_DSI_FMT_RGB888:
> dpi_data_format = DPI_COLOR_24BIT;
>
> --
> 2.34.1
>
Looks good to me
Reviewed-by: Nicolas Belin <nbelin@baylibre.com>
^ permalink raw reply
* [PATCH 0/4] thermal: loongson2: Add Loongson-2K0500 and Loongson-2K2000 thermal support
From: Binbin Zhou @ 2024-04-10 9:48 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rafael J . Wysocki, Daniel Lezcano,
Amit Kucheria, Zhang Rui, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Huacai Chen, loongson-kernel, linux-pm, devicetree, Yinbo Zhu,
WANG Xuerui, loongarch, Binbin Zhou
Hi all:
This patchset introduce the Loongson-2K0500 and Loongson-2K2000
temperature sensors.
The temperature sensors of Loongson-2K series CPUs are similar, except
that the temperature reading method of the Loongson-2K2000 is
different.
Specifically, the temperature output register of the Loongson-2K2000 is
defined in the chip configuration domain. We need to define it in dts
and calculate it using different calculation methods.
Thanks.
Binbin Zhou (4):
thermal: loongson2: Trivial code style adjustment
dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500
compaible
dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible
definition
thermal: loongson2: Add Loongson-2K2000 support
.../thermal/loongson,ls2k-thermal.yaml | 23 +++-
drivers/thermal/loongson2_thermal.c | 111 +++++++++++-------
2 files changed, 92 insertions(+), 42 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/4] thermal: loongson2: Trivial code style adjustment
From: Binbin Zhou @ 2024-04-10 9:49 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rafael J . Wysocki, Daniel Lezcano,
Amit Kucheria, Zhang Rui, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Huacai Chen, loongson-kernel, linux-pm, devicetree, Yinbo Zhu,
WANG Xuerui, loongarch, Binbin Zhou
In-Reply-To: <cover.1712733065.git.zhoubinbin@loongson.cn>
Here are some minor code style adjustment. Such as fix whitespace code
style; align function call arguments to opening parenthesis, and add
devm_thermal_add_hwmon_sysfs() return value checking.
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
drivers/thermal/loongson2_thermal.c | 69 +++++++++++++++--------------
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/thermal/loongson2_thermal.c b/drivers/thermal/loongson2_thermal.c
index 0f475fe46bc9..d77d829c8b55 100644
--- a/drivers/thermal/loongson2_thermal.c
+++ b/drivers/thermal/loongson2_thermal.c
@@ -16,45 +16,49 @@
#include <linux/units.h>
#include "thermal_hwmon.h"
-#define LOONGSON2_MAX_SENSOR_SEL_NUM 3
+#define LOONGSON2_MAX_SENSOR_SEL_NUM 3
-#define LOONGSON2_THSENS_CTRL_HI_REG 0x0
-#define LOONGSON2_THSENS_CTRL_LOW_REG 0x8
-#define LOONGSON2_THSENS_STATUS_REG 0x10
-#define LOONGSON2_THSENS_OUT_REG 0x14
+#define LOONGSON2_THSENS_CTRL_HI_REG 0x0
+#define LOONGSON2_THSENS_CTRL_LOW_REG 0x8
+#define LOONGSON2_THSENS_STATUS_REG 0x10
+#define LOONGSON2_THSENS_OUT_REG 0x14
-#define LOONGSON2_THSENS_INT_LO BIT(0)
-#define LOONGSON2_THSENS_INT_HIGH BIT(1)
-#define LOONGSON2_THSENS_OUT_MASK 0xFF
+#define LOONGSON2_THSENS_INT_LO BIT(0)
+#define LOONGSON2_THSENS_INT_HIGH BIT(1)
+#define LOONGSON2_THSENS_INT_EN (LOONGSON2_THSENS_INT_LO | \
+ LOONGSON2_THSENS_INT_HIGH)
+#define LOONGSON2_THSENS_OUT_MASK 0xFF
struct loongson2_thermal_chip_data {
- unsigned int thermal_sensor_sel;
+ unsigned int thermal_sensor_sel;
};
struct loongson2_thermal_data {
- void __iomem *regs;
+ void __iomem *regs;
const struct loongson2_thermal_chip_data *chip_data;
};
-static int loongson2_thermal_set(struct loongson2_thermal_data *data,
- int low, int high, bool enable)
+static void loongson2_set_ctrl_regs(struct loongson2_thermal_data *data,
+ int ctrl_data, bool low, bool enable)
{
- u64 reg_ctrl = 0;
- int reg_off = data->chip_data->thermal_sensor_sel * 2;
+ int reg_ctrl = 0;
+ int reg_off = data->chip_data->thermal_sensor_sel * 2;
+ int ctrl_reg = low ? LOONGSON2_THSENS_CTRL_LOW_REG :
+ LOONGSON2_THSENS_CTRL_HI_REG;
+
+ reg_ctrl = ctrl_data + HECTO;
+ reg_ctrl |= enable ? 0x100 : 0;
+ writew(reg_ctrl, data->regs + ctrl_reg + reg_off);
+}
+static int loongson2_thermal_set(struct loongson2_thermal_data *data,
+ int low, int high, bool enable)
+{
low = clamp(-40, low, high);
high = clamp(125, low, high);
- low += HECTO;
- high += HECTO;
-
- reg_ctrl = low;
- reg_ctrl |= enable ? 0x100 : 0;
- writew(reg_ctrl, data->regs + LOONGSON2_THSENS_CTRL_LOW_REG + reg_off);
-
- reg_ctrl = high;
- reg_ctrl |= enable ? 0x100 : 0;
- writew(reg_ctrl, data->regs + LOONGSON2_THSENS_CTRL_HI_REG + reg_off);
+ loongson2_set_ctrl_regs(data, low, true, enable);
+ loongson2_set_ctrl_regs(data, high, false, enable);
return 0;
}
@@ -75,15 +79,15 @@ static irqreturn_t loongson2_thermal_irq_thread(int irq, void *dev)
struct thermal_zone_device *tzd = dev;
struct loongson2_thermal_data *data = thermal_zone_device_priv(tzd);
- writeb(LOONGSON2_THSENS_INT_LO | LOONGSON2_THSENS_INT_HIGH, data->regs +
- LOONGSON2_THSENS_STATUS_REG);
+ writeb(LOONGSON2_THSENS_INT_EN, data->regs + LOONGSON2_THSENS_STATUS_REG);
thermal_zone_device_update(tzd, THERMAL_EVENT_UNSPECIFIED);
return IRQ_HANDLED;
}
-static int loongson2_thermal_set_trips(struct thermal_zone_device *tz, int low, int high)
+static int loongson2_thermal_set_trips(struct thermal_zone_device *tz,
+ int low, int high)
{
struct loongson2_thermal_data *data = thermal_zone_device_priv(tz);
@@ -116,14 +120,13 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
- writeb(LOONGSON2_THSENS_INT_LO | LOONGSON2_THSENS_INT_HIGH, data->regs +
- LOONGSON2_THSENS_STATUS_REG);
+ writeb(LOONGSON2_THSENS_INT_EN, data->regs + LOONGSON2_THSENS_STATUS_REG);
loongson2_thermal_set(data, 0, 0, false);
for (i = 0; i <= LOONGSON2_MAX_SENSOR_SEL_NUM; i++) {
tzd = devm_thermal_of_zone_register(dev, i, data,
- &loongson2_of_thermal_ops);
+ &loongson2_of_thermal_ops);
if (!IS_ERR(tzd))
break;
@@ -135,13 +138,11 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
}
ret = devm_request_threaded_irq(dev, irq, NULL, loongson2_thermal_irq_thread,
- IRQF_ONESHOT, "loongson2_thermal", tzd);
+ IRQF_ONESHOT, "loongson2_thermal", tzd);
if (ret < 0)
return dev_err_probe(dev, ret, "failed to request alarm irq\n");
- devm_thermal_add_hwmon_sysfs(dev, tzd);
-
- return 0;
+ return devm_thermal_add_hwmon_sysfs(dev, tzd);
}
static const struct loongson2_thermal_chip_data loongson2_thermal_ls2k1000_data = {
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500 compaible
From: Binbin Zhou @ 2024-04-10 9:49 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rafael J . Wysocki, Daniel Lezcano,
Amit Kucheria, Zhang Rui, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Huacai Chen, loongson-kernel, linux-pm, devicetree, Yinbo Zhu,
WANG Xuerui, loongarch, Binbin Zhou
In-Reply-To: <cover.1712733065.git.zhoubinbin@loongson.cn>
The thermal on the Loongson-2K0500 shares the design with the
Loongson-2K1000. Define corresponding compatible string, having the
loongson,ls2k1000-thermal as a fallback.
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
.../devicetree/bindings/thermal/loongson,ls2k-thermal.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
index b634f57cd011..9748a479dcd4 100644
--- a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
@@ -20,6 +20,7 @@ properties:
- loongson,ls2k1000-thermal
- items:
- enum:
+ - loongson,ls2k0500-thermal
- loongson,ls2k2000-thermal
- const: loongson,ls2k1000-thermal
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition
From: Binbin Zhou @ 2024-04-10 9:49 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rafael J . Wysocki, Daniel Lezcano,
Amit Kucheria, Zhang Rui, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Huacai Chen, loongson-kernel, linux-pm, devicetree, Yinbo Zhu,
WANG Xuerui, loongarch, Binbin Zhou
In-Reply-To: <cover.1712733065.git.zhoubinbin@loongson.cn>
The temperature output register of the Loongson-2K2000 is defined in the
chip configuration domain, which is different from the Loongson-2K1000,
so it can't be fallbacked.
We need to use two groups of registers to describe it: the first group
is the high and low temperature threshold setting register; the second
group is the temperature output register.
It is true that this fix will cause ABI corruption, but it is necessary
otherwise the Loongson-2K2000 temperature sensor will not work properly.
Fixes: 72684d99a854 ("thermal: dt-bindings: add loongson-2 thermal")
Cc: Yinbo Zhu <zhuyinbo@loongson.cn>
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
.../thermal/loongson,ls2k-thermal.yaml | 22 +++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
index 9748a479dcd4..a25b42702788 100644
--- a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
@@ -18,14 +18,15 @@ properties:
oneOf:
- enum:
- loongson,ls2k1000-thermal
+ - loongson,ls2k2000-thermal
- items:
- enum:
- loongson,ls2k0500-thermal
- - loongson,ls2k2000-thermal
- const: loongson,ls2k1000-thermal
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
interrupts:
maxItems: 1
@@ -41,6 +42,23 @@ required:
unevaluatedProperties: false
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - loongson,ls2k2000-thermal
+
+then:
+ properties:
+ reg:
+ maxItems: 2
+
+else:
+ properties:
+ reg:
+ maxItems: 1
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] thermal: loongson2: Add Loongson-2K2000 support
From: Binbin Zhou @ 2024-04-10 9:49 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rafael J . Wysocki, Daniel Lezcano,
Amit Kucheria, Zhang Rui, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Huacai Chen, loongson-kernel, linux-pm, devicetree, Yinbo Zhu,
WANG Xuerui, loongarch, Binbin Zhou
In-Reply-To: <cover.1712733065.git.zhoubinbin@loongson.cn>
The Loongson-2K2000 and Loongson-2K1000 have similar thermal sensors,
except that the temperature is read differently.
In particular, the temperature output registers of the Loongson-2K2000
are defined in the chip configuration domain and are read in a different
way.
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
drivers/thermal/loongson2_thermal.c | 50 +++++++++++++++++++++++------
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/loongson2_thermal.c b/drivers/thermal/loongson2_thermal.c
index d77d829c8b55..d803b6bc35b7 100644
--- a/drivers/thermal/loongson2_thermal.c
+++ b/drivers/thermal/loongson2_thermal.c
@@ -29,12 +29,20 @@
LOONGSON2_THSENS_INT_HIGH)
#define LOONGSON2_THSENS_OUT_MASK 0xFF
+/*
+ * This flag is used to indicate the temperature reading
+ * method of the Loongson-2K2000
+ */
+#define LS2K2000_THSENS_OUT_FLAG BIT(0)
+
struct loongson2_thermal_chip_data {
unsigned int thermal_sensor_sel;
+ unsigned int flags;
};
struct loongson2_thermal_data {
- void __iomem *regs;
+ void __iomem *ctrl_reg;
+ void __iomem *temp_reg;
const struct loongson2_thermal_chip_data *chip_data;
};
@@ -48,7 +56,7 @@ static void loongson2_set_ctrl_regs(struct loongson2_thermal_data *data,
reg_ctrl = ctrl_data + HECTO;
reg_ctrl |= enable ? 0x100 : 0;
- writew(reg_ctrl, data->regs + ctrl_reg + reg_off);
+ writew(reg_ctrl, data->ctrl_reg + ctrl_reg + reg_off);
}
static int loongson2_thermal_set(struct loongson2_thermal_data *data,
@@ -65,11 +73,16 @@ static int loongson2_thermal_set(struct loongson2_thermal_data *data,
static int loongson2_thermal_get_temp(struct thermal_zone_device *tz, int *temp)
{
- u32 reg_val;
+ int val;
struct loongson2_thermal_data *data = thermal_zone_device_priv(tz);
- reg_val = readl(data->regs + LOONGSON2_THSENS_OUT_REG);
- *temp = ((reg_val & LOONGSON2_THSENS_OUT_MASK) - HECTO) * KILO;
+ if (data->chip_data->flags) {
+ val = readl(data->temp_reg);
+ *temp = ((val & 0xffff) * 820 / 0x4000 - 311) * KILO;
+ } else {
+ val = readl(data->ctrl_reg + LOONGSON2_THSENS_OUT_REG);
+ *temp = ((val & LOONGSON2_THSENS_OUT_MASK) - HECTO) * KILO;
+ }
return 0;
}
@@ -79,7 +92,7 @@ static irqreturn_t loongson2_thermal_irq_thread(int irq, void *dev)
struct thermal_zone_device *tzd = dev;
struct loongson2_thermal_data *data = thermal_zone_device_priv(tzd);
- writeb(LOONGSON2_THSENS_INT_EN, data->regs + LOONGSON2_THSENS_STATUS_REG);
+ writeb(LOONGSON2_THSENS_INT_EN, data->ctrl_reg + LOONGSON2_THSENS_STATUS_REG);
thermal_zone_device_update(tzd, THERMAL_EVENT_UNSPECIFIED);
@@ -112,15 +125,22 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
data->chip_data = device_get_match_data(dev);
- data->regs = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(data->regs))
- return PTR_ERR(data->regs);
+ data->ctrl_reg = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(data->ctrl_reg))
+ return PTR_ERR(data->ctrl_reg);
+
+ /* The temperature output register is separate for Loongson-2K2000 */
+ if (data->chip_data->flags) {
+ data->temp_reg = devm_platform_ioremap_resource(pdev, 1);
+ if (IS_ERR(data->temp_reg))
+ return PTR_ERR(data->temp_reg);
+ }
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
- writeb(LOONGSON2_THSENS_INT_EN, data->regs + LOONGSON2_THSENS_STATUS_REG);
+ writeb(LOONGSON2_THSENS_INT_EN, data->ctrl_reg + LOONGSON2_THSENS_STATUS_REG);
loongson2_thermal_set(data, 0, 0, false);
@@ -147,6 +167,12 @@ static int loongson2_thermal_probe(struct platform_device *pdev)
static const struct loongson2_thermal_chip_data loongson2_thermal_ls2k1000_data = {
.thermal_sensor_sel = 0,
+ .flags = 0,
+};
+
+static const struct loongson2_thermal_chip_data loongson2_thermal_ls2k2000_data = {
+ .thermal_sensor_sel = 0,
+ .flags = LS2K2000_THSENS_OUT_FLAG,
};
static const struct of_device_id of_loongson2_thermal_match[] = {
@@ -154,6 +180,10 @@ static const struct of_device_id of_loongson2_thermal_match[] = {
.compatible = "loongson,ls2k1000-thermal",
.data = &loongson2_thermal_ls2k1000_data,
},
+ {
+ .compatible = "loongson,ls2k2000-thermal",
+ .data = &loongson2_thermal_ls2k2000_data,
+ },
{ /* end */ }
};
MODULE_DEVICE_TABLE(of, of_loongson2_thermal_match);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: mediatek: mt8192: Add missing trip point in thermal zone
From: AngeloGioacchino Del Regno @ 2024-04-10 9:49 UTC (permalink / raw)
To: Hsin-Te Yuan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, Nícolas F. R. A. Prado,
Bernhard Rosenkränzer, Balsam CHIHI, Alexandre Mergnat
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240410-upstream-torvalds-master-v2-1-679777847b63@chromium.org>
Il 10/04/24 10:40, Hsin-Te Yuan ha scritto:
> According to Documentation/driver-api/thermal/power_allocator.rst, there
> should be two passive trip points. Adding the missing trip point to
> ensure that the governor works optimally.
>
> Fixes: c7a728051f4e ("arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones")
> Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
That's better - but while I can agree about setting a general temperature
for that, I still have a few questions and requests:
1. Why is this 68°C? Was that value provided by MediaTek, or was it calculated?
1b. If this was calculated, please, can you explain how?
2. The power allocator documentation also says that the governor works good
when a "sustainable dissipatable power" parameter is fed to it through the
`sustainable-power` devicetree property (with that being strictly board
specific and never SoC-global, as that depends on the form factor and on
the cooling method of the machine), can you please also add the right
sustainable power indication to the Chromebook devicetrees?
In the MT8192 specific case, that's mt8192-asurada.dtsi.
3. I just noticed that MT8192 is not the only one that would be affected by
the issue that you're describing in this commit; can you please perform a
similar change on the others, if parameters are known?
Thanks,
Angelo
> ---
> Changes in v2:
> - Clearify the reason of adding another passive trip point
> - Link to v1: https://lore.kernel.org/r/20240410-upstream-torvalds-master-v1-1-852e903f0cec@chromium.org
> ---
> arch/arm64/boot/dts/mediatek/mt8192.dtsi | 40 ++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> index 05e401670bced..08d8bccc84669 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> @@ -1959,6 +1959,11 @@ cpu0-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU0>;
>
> trips {
> + cpu0_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu0_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> @@ -1989,6 +1994,11 @@ cpu1-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU1>;
>
> trips {
> + cpu1_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu1_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> @@ -2019,6 +2029,11 @@ cpu2-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU2>;
>
> trips {
> + cpu2_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu2_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> @@ -2049,6 +2064,11 @@ cpu3-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU3>;
>
> trips {
> + cpu3_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu3_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> @@ -2079,6 +2099,11 @@ cpu4-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU0>;
>
> trips {
> + cpu4_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu4_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> @@ -2109,6 +2134,11 @@ cpu5-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU1>;
>
> trips {
> + cpu5_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu5_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> @@ -2139,6 +2169,11 @@ cpu6-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU2>;
>
> trips {
> + cpu6_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu6_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> @@ -2169,6 +2204,11 @@ cpu7-thermal {
> thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU3>;
>
> trips {
> + cpu7_thres: trip-point {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> cpu7_alert: trip-alert {
> temperature = <85000>;
> hysteresis = <2000>;
>
> ---
> base-commit: 20cb38a7af88dc40095da7c2c9094da3873fea23
> change-id: 20240410-upstream-torvalds-master-40aeff5416c7
>
> Best regards,
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] clk: meson: axg: move reset controller's code to separate module
From: Conor Dooley @ 2024-04-10 9:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: Jan Dakinevich, Jerome Brunet, Philipp Zabel, Neil Armstrong,
Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <dde59dd2ef4da81528e31f65844e0b3f.sboyd@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3835 bytes --]
On Tue, Apr 09, 2024 at 07:27:36PM -0700, Stephen Boyd wrote:
> Quoting Conor Dooley (2024-04-09 05:05:37)
> > On Mon, Apr 08, 2024 at 06:05:51PM +0100, Conor Dooley wrote:
> >
> > > > > Seconded, the clk-mpfs/reset-mpfs and clk-starfive-jh7110-sys/reset-
> > > > > starfive-jh7110 drivers are examples of this.
> > > > >
> > > > > > The auxiliary device creation function can also be in the
> > > > > > drivers/reset/ directory so that the clk driver calls some function
> > > > > > to create and register the device.
> > > > >
> > > > > I'm undecided about this, do you think mpfs_reset_controller_register()
> > > > > and jh7110_reset_controller_register() should rather live with the
> > > > > reset aux drivers in drivers/reset/ ?
> > > >
> > > > Yes, and also mpfs_reset_read() and friends. We should pass the base
> > > > iomem pointer and parent device to mpfs_reset_adev_alloc() instead and
> > > > then move all that code into drivers/reset with some header file
> > > > exported function to call. That way the clk driver hands over the data
> > > > without having to implement half the implementation.
> > >
> > > I'll todo list that :)
> >
> > Something like the below?
> >
> > -- >8 --
> > From a12f281d2cb869bcd9a6ffc45d0c6a0d3aa2e9e2 Mon Sep 17 00:00:00 2001
> > From: Conor Dooley <conor.dooley@microchip.com>
> > Date: Tue, 9 Apr 2024 11:54:34 +0100
> > Subject: [PATCH] clock, reset: microchip: move all mpfs reset code to the
> > reset subsystem
> >
> > <insert something here>
> >
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>
> Looks pretty good.
>
> > static const struct of_device_id mpfs_clk_of_match_table[] = {
> > diff --git a/drivers/reset/reset-mpfs.c b/drivers/reset/reset-mpfs.c
> > index 7f3fb2d472f4..27cd68b4ee81 100644
> > --- a/drivers/reset/reset-mpfs.c
> > +++ b/drivers/reset/reset-mpfs.c
> > @@ -137,9 +139,67 @@ static int mpfs_reset_probe(struct auxiliary_device *adev,
> > return devm_reset_controller_register(dev, rcdev);
> > }
> >
> > +static void mpfs_reset_unregister_adev(void *_adev)
> > +{
> > + struct auxiliary_device *adev = _adev;
> > +
> > + auxiliary_device_delete(adev);
> > + auxiliary_device_uninit(adev);
> > +}
> > +
> > +static void mpfs_reset_adev_release(struct device *dev)
> > +{
> > + struct auxiliary_device *adev = to_auxiliary_dev(dev);
> > +
> > + kfree(adev);
> > +}
> > +
> > +static struct auxiliary_device *mpfs_reset_adev_alloc(struct device *clk_dev)
> > +{
> > + struct auxiliary_device *adev;
> > + int ret;
> > +
> > + adev = kzalloc(sizeof(*adev), GFP_KERNEL);
> > + if (!adev)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + adev->name = "reset-mpfs";
> > + adev->dev.parent = clk_dev;
> > + adev->dev.release = mpfs_reset_adev_release;
> > + adev->id = 666u;
> > +
> > + ret = auxiliary_device_init(adev);
> > + if (ret) {
> > + kfree(adev);
> > + return ERR_PTR(ret);
> > + }
> > +
> > + return adev;
> > +}
> > +
> > +int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base)
> > +{
> > + struct auxiliary_device *adev;
> > + int ret;
> > +
> > + mpfs_reset_addr = base;
>
> Instead of a global this can be stashed in adev->dev.platform_data and
> grabbed in the driver probe?
I suppose, really I was just being "lazy" here and creating a global
rather than a `struct mpfs_reset` containing only the base address.
The test robot reported some issues with hexagon & COMPILE_TEST, so I'll
push it out again with this change and the fixes for the reported issues
and send the patch ones it gets the all clear.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition
From: Conor Dooley @ 2024-04-10 9:59 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Rafael J . Wysocki, Daniel Lezcano,
Amit Kucheria, Zhang Rui, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Huacai Chen, loongson-kernel, linux-pm, devicetree,
Yinbo Zhu, WANG Xuerui, loongarch
In-Reply-To: <217ce2745a8787c504bbda1d085daba7e9cb2f70.1712733065.git.zhoubinbin@loongson.cn>
[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]
On Wed, Apr 10, 2024 at 05:49:02PM +0800, Binbin Zhou wrote:
> The temperature output register of the Loongson-2K2000 is defined in the
> chip configuration domain, which is different from the Loongson-2K1000,
> so it can't be fallbacked.
>
> We need to use two groups of registers to describe it: the first group
> is the high and low temperature threshold setting register; the second
> group is the temperature output register.
>
> It is true that this fix will cause ABI corruption, but it is necessary
> otherwise the Loongson-2K2000 temperature sensor will not work properly.
>
> Fixes: 72684d99a854 ("thermal: dt-bindings: add loongson-2 thermal")
> Cc: Yinbo Zhu <zhuyinbo@loongson.cn>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
> .../thermal/loongson,ls2k-thermal.yaml | 22 +++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
> index 9748a479dcd4..a25b42702788 100644
> --- a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
> @@ -18,14 +18,15 @@ properties:
> oneOf:
> - enum:
> - loongson,ls2k1000-thermal
> + - loongson,ls2k2000-thermal
> - items:
> - enum:
> - loongson,ls2k0500-thermal
> - - loongson,ls2k2000-thermal
> - const: loongson,ls2k1000-thermal
>
> reg:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
>
> interrupts:
> maxItems: 1
> @@ -41,6 +42,23 @@ required:
>
> unevaluatedProperties: false
>
> +if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - loongson,ls2k2000-thermal
> +
> +then:
> + properties:
> + reg:
> + maxItems: 2
You need a minItems: 2 here also, so that providing only the original
reg is not allowed anymore.
Cheers,
Conor.
> +
> +else:
> + properties:
> + reg:
> + maxItems: 1
> +
> examples:
> - |
> #include <dt-bindings/interrupt-controller/irq.h>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-04-10 10:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_anusha, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <a0173a13-5f20-4e24-8417-afce5fdbda0e@kernel.org>
On Tue, Apr 09, 2024 at 02:20:12PM +0200, Krzysztof Kozlowski wrote:
> On 09/04/2024 13:03, Varadarajan Narayanan wrote:
> > On Tue, Apr 09, 2024 at 11:45:51AM +0200, Krzysztof Kozlowski wrote:
> >> On 09/04/2024 09:41, Varadarajan Narayanan wrote:
> >>> On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote:
> >>>> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote:
> >>>>> On 03/04/2024 12:42, Varadarajan Narayanan wrote:
> >>>>>> Add interconnect-cells to clock provider so that it can be
> >>>>>> used as icc provider.
> >>>>>>
> >>>>>> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
> >>>>>> interfaces. This will be used by the gcc-ipq9574 driver
> >>>>>> that will for providing interconnect services using the
> >>>>>> icc-clk framework.
> >>>>>>
> >>>>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> >>>>>> ---
> >>>>>> v7:
> >>>>>> Fix macro names to be consistent with other bindings
> >>>>>> v6:
> >>>>>> Removed Reviewed-by: Krzysztof Kozlowski
> >>>>>> Redefine the bindings such that driver and DT can share them
> >>>>>>
> >>>>>> v3:
> >>>>>> Squash Documentation/ and include/ changes into same patch
> >>>>>>
> >>>>>> qcom,ipq9574.h
> >>>>>> Move 'first id' to clock driver
> >>>>>>
> >>>>>> ---
> >>>>>> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
> >>>>>> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
> >>>>>> 2 files changed, 90 insertions(+)
> >>>>>> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> >>>>>> index 944a0ea79cd6..824781cbdf34 100644
> >>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> >>>>>> @@ -33,6 +33,9 @@ properties:
> >>>>>> - description: PCIE30 PHY3 pipe clock source
> >>>>>> - description: USB3 PHY pipe clock source
> >>>>>>
> >>>>>> + '#interconnect-cells':
> >>>>>> + const: 1
> >>>>>> +
> >>>>>> required:
> >>>>>> - compatible
> >>>>>> - clocks
> >>>>>> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h
> >>>>>> new file mode 100644
> >>>>>> index 000000000000..0b076b0cf880
> >>>>>> --- /dev/null
> >>>>>> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
> >>>>>> @@ -0,0 +1,87 @@
> >>>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> >>>>>> +#ifndef INTERCONNECT_QCOM_IPQ9574_H
> >>>>>> +#define INTERCONNECT_QCOM_IPQ9574_H
> >>>>>> +
> >>>>>> +#define ICC_ANOC_PCIE0 0
> >>>>>> +#define ICC_SNOC_PCIE0 1
> >>>>>> +#define ICC_ANOC_PCIE1 2
> >>>>>> +#define ICC_SNOC_PCIE1 3
> >>>>>> +#define ICC_ANOC_PCIE2 4
> >>>>>> +#define ICC_SNOC_PCIE2 5
> >>>>>> +#define ICC_ANOC_PCIE3 6
> >>>>>> +#define ICC_SNOC_PCIE3 7
> >>>>>> +#define ICC_SNOC_USB 8
> >>>>>> +#define ICC_ANOC_USB_AXI 9
> >>>>>> +#define ICC_NSSNOC_NSSCC 10
> >>>>>> +#define ICC_NSSNOC_SNOC_0 11
> >>>>>> +#define ICC_NSSNOC_SNOC_1 12
> >>>>>> +#define ICC_NSSNOC_PCNOC_1 13
> >>>>>> +#define ICC_NSSNOC_QOSGEN_REF 14
> >>>>>> +#define ICC_NSSNOC_TIMEOUT_REF 15
> >>>>>> +#define ICC_NSSNOC_XO_DCD 16
> >>>>>> +#define ICC_NSSNOC_ATB 17
> >>>>>> +#define ICC_MEM_NOC_NSSNOC 18
> >>>>>> +#define ICC_NSSNOC_MEMNOC 19
> >>>>>> +#define ICC_NSSNOC_MEM_NOC_1 20
> >>>>>> +
> >>>>>> +#define ICC_NSSNOC_PPE 0
> >>>>>> +#define ICC_NSSNOC_PPE_CFG 1
> >>>>>> +#define ICC_NSSNOC_NSS_CSR 2
> >>>>>> +#define ICC_NSSNOC_IMEM_QSB 3
> >>>>>> +#define ICC_NSSNOC_IMEM_AHB 4
> >>>>>> +
> >>>>>> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2)
> >>>>>> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1)
> >>>>>
> >>>>> Which existing Qualcomm platform has such code?
> >>>>
> >>>> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm
> >>>> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk.
> >>>>
> >>>> The icc_clk_register automatically creates master & slave nodes
> >>>> for each clk entry provided as input with the node-ids 'n' and
> >>>> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just
> >>>> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these
> >>>> calculations.
> >>>>
> >>>> However, ipq9574 gives an array of clock entries as input to
> >>>> icc_clk_register. To tie the order/sequence of these clock
> >>>> entries correctly with the node-ids, this calculation is needed.
> >>>>
> >>>>> This is the third time I am asking for consistent headers. Open
> >>>>> existing, recently added headers and look how it is done there. Why?
> >>>>> Because I am against such calculations and see no reason for them.
> >>>>
> >>>> Apologies. Regret that I have to trouble you.
> >>>>
> >>>> In this ipq9574 case, have to reconcile between the following
> >>>> feedbacks.
> >>>>
> >>>> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/
> >>>> We could probably use indexed identifiers here to avoid confusion:
> >>>> [ICC_BINDING_NAME] = CLK_BINDING_NAME
> >>>>
> >>>> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/
> >>>> Are these supposed to be in a dt-binding header?
> >>>>
> >>>> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/
> >>>> Do you use them as well in the DTS?
> >>>>
> >>>> Having the defines (with the calculations) seemed to to comply
> >>>> with the above three feedbacks.
> >>>>
> >>>> Please let me know if this can be handled in a different way that
> >>>> would be consistent with other Qualcomm platforms.
> >>>
> >>> Krzysztof,
> >>>
> >>> Is this ok? Can I post a new version addressing other review comments?
> >>
> >> I don't understand and you did not answered before, why you have to do
> >> it differently than all other Qualcomm interconnect providers. Maybe the
> >> code here needs it, maybe not, but I don't see any argument proving this.
> >
> > Other Qualcomm interconnect providers use the icc-rpm.
> >
> > 1. The SoC specific interconnect providers have control
> > over the master/slave id-numbers and is hard coded.
> >
> > 2. These id-numbers are used by the RPM firmware.
> >
> > IPQ9574 uses icc-clk.
> >
> > 1. The ipq9574 specific interconnect provider doesn't
> > have control over the master/slave id-numbers. The
> > icc-clk framework auto generates it in the order of
> > the clock entries given as input.
>
> Okay, so what happens if icc-clk way of generating them changes a bit?
> It can change, why not, driver implementation is not an ABI.
>
> >
> > 2. These auto-generated id-numbers have to be correctly
> > tied to the DT nodes. Else, the relevant clocks may
> > not get enabled.
>
> Sorry, I don't get, how auto generated ID number is tied to DT node.
> What DT node?
I meant the following usage for the 'interconnects' entry of the
consumer peripheral's node.
interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>,
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
<&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>;
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
> > Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and
> > one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in
> > the below array would create holes.
> >
> > static int icc_ipq9574_hws[] = {
> > [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK,
> > [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK,
> > [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK,
> > [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK,
> > . . .
> > };
> >
> > Other Qualcomm drivers don't have this issue and they can
> > directly use the MASTER/SLAVE_xxx macros.
>
> I understand, thanks, yet your last patch keeps adding fake IDs, means
> IDs which are not part of ABI.
>
> >
> > As the MASTER_xxx macros cannot be used, have to define a new set
> > of macros that can be used for indices in the above array. This
> > is the reason for the ICC_BINDING_NAME macros.
>
> Then maybe fix the driver, instead of adding something which is not an
> ABI to bindings and completely skipping the actual ABI.
Will remove the ICC_xxx defines from the header. And in the
driver will change the declaration as follows. Will that be
acceptable?
static int icc_ipq9574_hws[] = {
[MASTER_ANOC_PCIE0 / 2] = GCC_ANOC_PCIE0_1LANE_M_CLK,
[MASTER_SNOC_PCIE0 / 2] = GCC_SNOC_PCIE0_1LANE_S_CLK,
[MASTER_ANOC_PCIE1 / 2] = GCC_ANOC_PCIE1_1LANE_M_CLK,
[MASTER_SNOC_PCIE1 / 2] = GCC_SNOC_PCIE1_1LANE_S_CLK,
[MASTER_ANOC_PCIE2 / 2] = GCC_ANOC_PCIE2_2LANE_M_CLK,
[MASTER_SNOC_PCIE2 / 2] = GCC_SNOC_PCIE2_2LANE_S_CLK,
[MASTER_ANOC_PCIE3 / 2] = GCC_ANOC_PCIE3_2LANE_M_CLK,
[MASTER_SNOC_PCIE3 / 2] = GCC_SNOC_PCIE3_2LANE_S_CLK,
[MASTER_SNOC_USB / 2] = GCC_SNOC_USB_CLK,
[MASTER_ANOC_USB_AXI / 2] = GCC_ANOC_USB_AXI_CLK,
[MASTER_NSSNOC_NSSCC / 2] = GCC_NSSNOC_NSSCC_CLK,
[MASTER_NSSNOC_SNOC_0 / 2] = GCC_NSSNOC_SNOC_CLK,
[MASTER_NSSNOC_SNOC_1 / 2] = GCC_NSSNOC_SNOC_1_CLK,
[MASTER_NSSNOC_PCNOC_1 / 2] = GCC_NSSNOC_PCNOC_1_CLK,
[MASTER_NSSNOC_QOSGEN_REF / 2] = GCC_NSSNOC_QOSGEN_REF_CLK,
[MASTER_NSSNOC_TIMEOUT_REF / 2] = GCC_NSSNOC_TIMEOUT_REF_CLK,
[MASTER_NSSNOC_XO_DCD / 2] = GCC_NSSNOC_XO_DCD_CLK,
[MASTER_NSSNOC_ATB / 2] = GCC_NSSNOC_ATB_CLK,
[MASTER_MEM_NOC_NSSNOC / 2] = GCC_MEM_NOC_NSSNOC_CLK,
[MASTER_NSSNOC_MEMNOC / 2] = GCC_NSSNOC_MEMNOC_CLK,
[MASTER_NSSNOC_MEM_NOC_1 / 2] = GCC_NSSNOC_MEM_NOC_1_CLK,
};
Thanks
Varada
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Conor Dooley @ 2024-04-10 10:03 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
devicetree, linux-kernel
In-Reply-To: <3d5df067-ec94-42c6-bbd0-43ce8cd53e40@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
On Wed, Apr 10, 2024 at 10:57:08AM +0300, Matti Vaittinen wrote:
> On 4/4/24 22:54, Andreas Kemnade wrote:
> > As this chip was seen in several devices in the wild, add it.
> >
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
> > ---
> > .../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> > index 0b62f854bf6b..07f99738fcf6 100644
> > --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> > @@ -17,7 +17,12 @@ description: |
> > properties:
> > compatible:
> > - const: rohm,bd71828
> > + oneOf:
> > + - const: rohm,bd71828
> > +
> > + - items:
> > + - const: rohm,bd71879
> > + - const: rohm,bd71828
> > reg:
> > description:
>
> Am I correct, this reads as:
>
> Either
> compatible = rohm,bd71828
> or
> compatible = rohm,bd71879, rohm,bd71828
>
> but not compatible = rohm,bd71879?
Correct.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v4 1/2] clk: starfive: jh7110-sys: Add notifier for PLL clock
From: Xingyu Wu @ 2024-04-10 3:31 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Conor Dooley,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski
Cc: Emil Renner Berthing, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Hal Feng, Xingyu Wu, linux-kernel, linux-clk, linux-riscv,
devicetree
In-Reply-To: <20240410033148.213991-1-xingyu.wu@starfivetech.com>
Add notifier function for PLL clock. In the function, the cpu_root clock
should be operated by saving its current parent and setting a new safe
parent (osc clock) before setting the PLL clock rate. After setting PLL
rate, it should be switched back to the original parent clock.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
---
.../clk/starfive/clk-starfive-jh7110-sys.c | 31 ++++++++++++++++++-
drivers/clk/starfive/clk-starfive-jh71x0.h | 2 ++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-sys.c b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
index 8f5e5abfa178..adf62e4d94e4 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-sys.c
+++ b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
@@ -385,6 +385,32 @@ int jh7110_reset_controller_register(struct jh71x0_clk_priv *priv,
}
EXPORT_SYMBOL_GPL(jh7110_reset_controller_register);
+/*
+ * This clock notifier is called when the rate of PLL0 clock is to be change,
+ * The cpu_root clock should save curent parent clock and swicth its parent
+ * clock to osc before PLL0 rate will be changed. And switch its parent clock
+ * back after PLL rate finished.
+ */
+static int jh7110_pll_clk_notifier_cb(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct jh71x0_clk_priv *priv = container_of(nb, struct jh71x0_clk_priv, pll_clk_nb);
+ struct clk *cpu_root = priv->reg[JH7110_SYSCLK_CPU_ROOT].hw.clk;
+ int ret = 0;
+
+ if (action == PRE_RATE_CHANGE) {
+ struct clk *osc = clk_get(priv->dev, "osc");
+
+ priv->original_clk = clk_get_parent(cpu_root);
+ ret = clk_set_parent(cpu_root, osc);
+ clk_put(osc);
+ } else if (action == POST_RATE_CHANGE) {
+ ret = clk_set_parent(cpu_root, priv->original_clk);
+ }
+
+ return notifier_from_errno(ret);
+}
+
static int __init jh7110_syscrg_probe(struct platform_device *pdev)
{
struct jh71x0_clk_priv *priv;
@@ -413,7 +439,10 @@ static int __init jh7110_syscrg_probe(struct platform_device *pdev)
if (IS_ERR(priv->pll[0]))
return PTR_ERR(priv->pll[0]);
} else {
- clk_put(pllclk);
+ priv->pll_clk_nb.notifier_call = jh7110_pll_clk_notifier_cb;
+ ret = clk_notifier_register(pllclk, &priv->pll_clk_nb);
+ if (ret)
+ return ret;
priv->pll[0] = NULL;
}
diff --git a/drivers/clk/starfive/clk-starfive-jh71x0.h b/drivers/clk/starfive/clk-starfive-jh71x0.h
index 23e052fc1549..e3f441393e48 100644
--- a/drivers/clk/starfive/clk-starfive-jh71x0.h
+++ b/drivers/clk/starfive/clk-starfive-jh71x0.h
@@ -114,6 +114,8 @@ struct jh71x0_clk_priv {
spinlock_t rmw_lock;
struct device *dev;
void __iomem *base;
+ struct clk *original_clk;
+ struct notifier_block pll_clk_nb;
struct clk_hw *pll[3];
struct jh71x0_clk reg[];
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/3] arm64: dts: ti: k3-am62-main: Fix the reg-range for dma-controller
From: Kumar, Udit @ 2024-04-10 10:06 UTC (permalink / raw)
To: Jayesh Choudhary, nm, vigneshr, bb, devicetree
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel,
u-kumar1
In-Reply-To: <20240405085208.32227-2-j-choudhary@ti.com>
Thanks for this fix Jayesh
On 4/5/2024 2:22 PM, Jayesh Choudhary wrote:
> The TX Channel Realtime Registers region 'tchanrt' is 128KB and Ring
> Realtime Registers region 'ringrt' is 2MB as shown in memory map in
> the TRM[0]. So fix ranges for those reg-regions.
Minor one, but it will be better to say that you are fixing these
register ranges for PKTDMA .
Something like that
For PKTDMA, The TX Channel Realtime Registers region 'tchanrt' ....
Also, it will help reviewer if you can mention which section in TRM[0],
holding memory map .
If you are doing v2 then please take care of above in commit message.
rest for whole series
LGTM
> [0]: <https://www.ti.com/lit/pdf/spruiv7>
>
> Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes")
> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> index e9cffca073ef..e10cc9fc0b10 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> @@ -141,8 +141,8 @@ main_pktdma: dma-controller@485c0000 {
> compatible = "ti,am64-dmss-pktdma";
> reg = <0x00 0x485c0000 0x00 0x100>,
> <0x00 0x4a800000 0x00 0x20000>,
> - <0x00 0x4aa00000 0x00 0x40000>,
> - <0x00 0x4b800000 0x00 0x400000>,
> + <0x00 0x4aa00000 0x00 0x20000>,
> + <0x00 0x4b800000 0x00 0x200000>,
> <0x00 0x485e0000 0x00 0x10000>,
> <0x00 0x484a0000 0x00 0x2000>,
> <0x00 0x484c0000 0x00 0x2000>,
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: riscv: add Milk-V Duo S board compatibles
From: Inochi Amaoto @ 2024-04-10 10:17 UTC (permalink / raw)
To: Michael Opdenacker, Inochi Amaoto, Conor Dooley, Rob Herring,
Krzysztof Kozlowski, Chen Wang, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Chao Wei
Cc: linux-riscv, devicetree, linux-kernel
In-Reply-To: <115662f6-a390-497e-903e-5a9bbb15e08b@bootlin.com>
On Wed, Apr 10, 2024 at 09:55:17AM +0200, Michael Opdenacker wrote:
> Hi Inochi
>
> Thanks for the reviews!
>
> On 4/10/24 at 09:19, Inochi Amaoto wrote:
> > On Wed, Apr 10, 2024 at 08:22:53AM +0200, michael.opdenacker@bootlin.com wrote:
> > > From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> > >
> > > Document the compatible strings for the Milk-V Duo S board[1] which uses
> > > the SOPHGO SG2000 SoC, compatible with the SOPHGO CV1800B SoC[2].
> > >
> > > Link: https://milkv.io/duo-s [1]
> > > Link: https://en.sophgo.com/product/introduce/cv180xB.html [2]
> > >
> > > Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
> > > ---
> > > Documentation/devicetree/bindings/riscv/sophgo.yaml | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/riscv/sophgo.yaml b/Documentation/devicetree/bindings/riscv/sophgo.yaml
> > > index 9bc813dad098..1837bc550056 100644
> > > --- a/Documentation/devicetree/bindings/riscv/sophgo.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/sophgo.yaml
> > > @@ -21,6 +21,7 @@ properties:
> > > - items:
> > > - enum:
> > > - milkv,duo
> > > + - milkv,duos
> > > - const: sophgo,cv1800b
> > Why not adding sg2000 property? They are different series.
> > IIRC, it at least a cv1813h not cv1800b. I suggest checking
> > the vendor SDK to get the right board compatibles.
>
> Here's what there was in the vendor provided DTB, if I noted it correctly:
> compatible = "cvitek,cv181x";
>
> Cheers
> Michael
That's true, the chipcode can be only see in the build script or
the board dts. You can use this as a base. For example, sg2000
can be something like: "sophgo,sg2000", "sophgo,cv1813h".
But in fact, I do not prefer to add "sophgo,cv1813h". Because
sg2000 can also boot as an aarch64 board, but cv1813h can't.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Miquel Raynal @ 2024-04-10 10:23 UTC (permalink / raw)
To: Arseniy Krasnov
Cc: Richard Weinberger, Vignesh Raghavendra, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-mtd, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel, oxffffaa, kernel
In-Reply-To: <20240409181025.55504-2-avkrasnov@salutedevices.com>
Hi Arseniy,
avkrasnov@salutedevices.com wrote on Tue, 9 Apr 2024 21:10:24 +0300:
> Boot ROM code on Meson requires that some pages on NAND must be written
> in special mode: "short" ECC mode where each block is 384 bytes and
> scrambling mode is on. Such pages located with the specified interval
> within specified offset. Both interval and offset are located in the
> device tree and used by driver if 'nand-is-boot-medium' is set for
> NAND chip.
>
> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
> ---
> .../bindings/mtd/amlogic,meson-nand.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> index 57b6957c8415..b86a1953056b 100644
> --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> @@ -64,11 +64,25 @@ patternProperties:
> items:
> maximum: 0
>
> + amlogic,boot-page-last:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The NFC driver needs this information to select ECC
> + algorithms supported by the boot ROM.
Shall we have a length rather than the last page?
> +
> + amlogic,boot-page-step:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The NFC driver needs this information to select ECC
> + algorithms supported by the boot ROM (in pages).
> +
> unevaluatedProperties: false
>
> dependencies:
> nand-ecc-strength: [nand-ecc-step-size]
> nand-ecc-step-size: [nand-ecc-strength]
> + amlogic,boot-page-last: [nand-is-boot-medium, "amlogic,boot-page-step"]
> + amlogic,boot-page-step: [nand-is-boot-medium, "amlogic,boot-page-last"]
>
>
> required:
Thanks,
Miquèl
^ permalink raw reply
* Re: (subset) [PATCH RESEND v8 0/6] riscv: add initial support for Canaan Kendryte K230
From: Conor Dooley @ 2024-04-10 10:30 UTC (permalink / raw)
To: linux-riscv, Yangyu Chen
Cc: conor, Conor Dooley, Damien Le Moal, Rob Herring,
Krzysztof Kozlowski, Dan Carpenter, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren, devicetree, linux-kernel
In-Reply-To: <tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com>
From: Conor Dooley <conor.dooley@microchip.com>
On Mon, 08 Apr 2024 00:26:58 +0800, Yangyu Chen wrote:
> K230 is an ideal chip for RISC-V Vector 1.0 evaluation now. Add initial
> support for it to allow more people to participate in building drivers
> to mainline for it.
>
> This kernel has been tested upon factory SDK [1] with
> k230_evb_only_linux_defconfig and patched mainline opensbi [2] to skip
> locked pmp and successfully booted to busybox on initrd with this log [3].
>
> [...]
Applied to riscv-dt-for-next, thanks!
[1/6] dt-bindings: riscv: Add T-HEAD C908 compatible
https://git.kernel.org/conor/c/64cbc46bb854
[2/6] dt-bindings: add Canaan K230 boards compatible strings
https://git.kernel.org/conor/c/b065da13ea9c
[3/6] dt-bindings: timer: Add Canaan K230 CLINT
https://git.kernel.org/conor/c/b3ae796d0a4f
[4/6] dt-bindings: interrupt-controller: Add Canaan K230 PLIC
https://git.kernel.org/conor/c/db54fda11b13
[5/6] riscv: dts: add initial canmv-k230 and k230-evb dts
https://git.kernel.org/conor/c/5db2c4dc413e
6/6 intentionally missing, it goes on another branch.
Thanks,
Conor.
^ permalink raw reply
* Re: [PATCH v2 08/10] clk: renesas: rzg2l-cpg: Add suspend/resume support for power domains
From: claudiu beznea @ 2024-04-10 10:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: mturquette, sboyd, robh, krzysztof.kozlowski+dt, conor+dt,
magnus.damm, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, Claudiu Beznea
In-Reply-To: <CAMuHMdVdn9K1gKJAKyyDz8ObaJboknE_qqYfS_vyxNU+zhRWPA@mail.gmail.com>
Hi, Geert,
Sorry for replying that late to this one.
On 18.03.2024 18:48, Geert Uytterhoeven wrote:
> Hi Claudiu,
>
> On Thu, Mar 7, 2024 at 3:07 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> RZ/G3S supports deep sleep states that it can reach with the help of the
>> TF-A.
>>
>> RZ/G3S has a few power domains (e.g. GIC) that need to be always-on while
>> Linux is running. These domains are initialized (and powered on) when
>> clock driver is probed.
>>
>> As the TF-A takes control at the very last(suspend)/first(resume)
>> phase of configuring the deep sleep state, it can do it's own settings on
>> power domains.
>>
>> Thus, to restore the proper Linux state, add rzg2l_cpg_resume() which
>> powers on the always-on domains and rzg2l_cpg_complete() which activates
>> the power down mode for the IPs selected through CPG_PWRDN_IP{1, 2}.
>>
>> Along with it, added the suspend_check member to the RZ/G2L power domain
>> data structure whose purpose is to checks if a domain can be powered off
>> while the system is going to suspend. This is necessary for the serial
>> console domain which needs to be powered on if no_console_suspend is
>> available in bootargs.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>
>> Changes in v2:
>> - none; this patch is new
>
> Thanks for your patch!
>
>> --- a/drivers/clk/renesas/rzg2l-cpg.c
>> +++ b/drivers/clk/renesas/rzg2l-cpg.c
>> @@ -1700,6 +1719,8 @@ static int __init rzg2l_cpg_pd_setup(struct rzg2l_cpg_pd *pd, bool always_on)
>> } else {
>> pd->genpd.power_on = rzg2l_cpg_power_on;
>> pd->genpd.power_off = rzg2l_cpg_power_off;
>> + if (flags & RZG2L_PD_F_CONSOLE)
>
> I think this should be replaced by some dynamic check, cfr. my comments
> on PATCH 9/10.
I agree.
>
>> + pd->suspend_check = rzg2l_pd_suspend_check_console;
>> governor = &simple_qos_governor;
>> }
>>
>
>> @@ -1890,9 +1911,43 @@ static int __init rzg2l_cpg_probe(struct platform_device *pdev)
>> if (error)
>> return error;
>>
>> + dev_set_drvdata(dev, priv);
>> +
>> return 0;
>> }
>>
>> +static int rzg2l_cpg_resume(struct device *dev)
>> +{
>> + struct rzg2l_cpg_priv *priv = dev_get_drvdata(dev);
>> + const struct rzg2l_cpg_info *info = priv->info;
>> +
>> + /* Power on always ON domains. */
>> + for (unsigned int i = 0; i < info->num_pm_domains; i++) {
>> + if (info->pm_domains[i].flags & RZG2L_PD_F_ALWAYS_ON) {
>
> If you would check "priv-domains[i].flags & GENPD_FLAG_ALWAYS_ON"
> instead, I think you can make r9a08g045_pm_domains[] __initconst.
> You may need to make a copy of the name for pd->genpd.name, though.
I wanted to avoid this copy.
>
>> + int ret = rzg2l_cpg_power_on(priv->domains[i]);
>
> I assume you are sure none of these domains are enabled by TF/A after
> system resume, or by the pmdomain core code?
Out of TF-A the MSTOP and PWRDN bits for these ones are set and setting
CPG_PWRDN_MSTOP though rzg2l_cpg_complete() leads to system being blocked.
It is the same as in booting case exlained in cover letter.
"the DDR, TZCDDR, OTFDE_DDR were also added, to avoid system being blocked
due to the following lines of code from patch 6/10.
+ /* Prepare for power down the BUSes in power down mode. */
+ if (info->pm_domain_pwrdn_mstop)
+ writel(CPG_PWRDN_MSTOP_ENABLE, priv->base + CPG_PWRDN_MSTOP);
Domain IDs were added to all SoC specific bindings.
"
The PM domain core code doesn't touch these domains while resuming as of my
checkings.
Thank you,
Claudiu Beznea
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: [PATCH v2 07/10] clk: renesas: r9a08g045: Add support for power domains
From: claudiu beznea @ 2024-04-10 10:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: mturquette, sboyd, robh, krzysztof.kozlowski+dt, conor+dt,
magnus.damm, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, Claudiu Beznea
In-Reply-To: <CAMuHMdXQ=m2BJ3Tjt0m8Q_H6dLh62sXjd2EMBTc+kuAwtc5B7A@mail.gmail.com>
Hi, Geert,
On 14.03.2024 18:01, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2024 at 3:07 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> Instantiate power domains for the currently enabled IPs of R9A08G045 SoC.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>
>> Change in v2:
>> - used DEF_REG_CONF() to describe register offests and bits
>> - updated MSTOP bitmask for ddr domain
>> - updated MSTOP config for oftde_ddr
>> - kept the same description for gic as the CPG_BUS_ACPU_MSTOP register
>> documentation in the latest HW manual version is wrong and it will be
>> fixed; proper description for GIC is located in "Registers for Module
>> Standby Mode" table
>> - haven't added watchdog domain (was missing in v1, too, by mistake) as
>> the watchdog restart handler will fail w/o patch [1]; with this pm domain
>> support the watchdog will fail to probe; not sure what is the best
>> option until [1] will be integrated
>>
>> [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20240228083253.2640997-10-claudiu.beznea.uj@bp.renesas.com
>
> I guess we'll have to wait until that dependency is integrated,
I opt for this option to not break the reset support currently integrated.
I don't have any feedback from maintainers yet on [1], though. I don't know
how long it will take.
Thank you,
Claudiu Beznea
> or use an immutable branch?
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Jisheng Zhang @ 2024-04-10 10:24 UTC (permalink / raw)
To: Inochi Amaoto
Cc: Michael Opdenacker, Conor Dooley, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen Wang, Paul Walmsley,
Palmer Dabbelt, Albert Ou, devicetree, linux-riscv, linux-kernel
In-Reply-To: <IA1PR20MB4953CA04D33EA0C7902DFA3ABB062@IA1PR20MB4953.namprd20.prod.outlook.com>
On Wed, Apr 10, 2024 at 09:24:40AM +0800, Inochi Amaoto wrote:
> On Tue, Apr 09, 2024 at 03:08:17PM +0200, Michael Opdenacker wrote:
> > Hi Inochi
> >
> > On 4/9/24 at 14:27, Inochi Amaoto wrote:
> > > On Tue, Apr 09, 2024 at 01:13:32PM +0100, Conor Dooley wrote:
> > > > On Tue, Apr 09, 2024 at 03:17:35PM +0800, Inochi Amaoto wrote:
> > > > > On Tue, Apr 09, 2024 at 08:45:04AM +0200, michael.opdenacker@bootlin.com wrote:
> > > > > > From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> > > > > >
> > > > > > This adds initial support for the Milk-V Duo S board
> > > > > > (https://milkv.io/duo-s), enabling the serial port and
> > > > > > read-only SD card support, allowing to boot Linux to the
> > > > > > command line.
> > > > > >
> > > > > Hi Michael,
> > > > >
> > > > > I think your patch losts the board binding and have wrong compatiable.
> > > > > Also, the SD can have rw support with proper property. See link [1]
> > > > > (need 'disable-wp').
> > > > [1] doesn't go anywhere useful.
> > > >
> > > This is my fault, I copied the wrong url. The right patch is
> > > https://lore.kernel.org/r/20240217144826.3944-1-jszhang@kernel.org.
> >
> >
> > No problem, I found out.
> > I confirm that using the "disable-wp;" property does the trick to make the
> > MMC writable.
> >
> > However, it wasn't mentioned in the above URL...
> >
> > By the way, do I really need those under &sdhci0?
> >
> > + bus-width = <4>; + no-1-8-v; + no-mmc; + no-sdio;
> >
> > My board looks happy so far without them ;-)
setting the correct bus-width is necessary for better performance
no-1-8-v can be removed, but it doesn't harm anything because
the board doesn't supply 1.8v
no-mmc and no-sdio to make the probe a bit quicker
>
> FYI, Jisheng. Could you share some suggestions?
>
> > Thanks again for your help
> > Cheers
> > Michael.
> >
> > --
> > Michael Opdenacker, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
> >
^ permalink raw reply
* Re: [PATCH v6 11/23] drivers: crypto: meson: introduce hasher
From: Alexey Romanov @ 2024-04-10 10:39 UTC (permalink / raw)
To: Herbert Xu
Cc: neil.armstrong@linaro.org, clabbe@baylibre.com,
davem@davemloft.net, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
khilman@baylibre.com, jbrunet@baylibre.com,
martin.blumenstingl@googlemail.com, vadim.fedorenko@linux.dev,
linux-crypto@vger.kernel.org, linux-amlogic@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel
In-Reply-To: <Zg+gnrO/wX5S+zlw@gondor.apana.org.au>
Hello Herbert,
On Fri, Apr 05, 2024 at 02:56:30PM +0800, Herbert Xu wrote:
> On Tue, Mar 26, 2024 at 06:32:07PM +0300, Alexey Romanov wrote:
> > Introduce support for SHA1/SHA224/SHA256 hash algos.
> > Tested via tcrypt and custom tests.
> >
> > Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
> > ---
> > drivers/crypto/amlogic/Makefile | 2 +-
> > drivers/crypto/amlogic/amlogic-gxl-core.c | 25 +-
> > drivers/crypto/amlogic/amlogic-gxl-hasher.c | 460 ++++++++++++++++++++
> > drivers/crypto/amlogic/amlogic-gxl.h | 51 +++
> > 4 files changed, 536 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/crypto/amlogic/amlogic-gxl-hasher.c
>
> Where are the import/export functions?
Sorry, I miss understand you. What do you mean by "import/epxort
functions"?
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Thank you,
Alexey
^ permalink raw reply
* [PATCH 0/2] media: i2c: Add support for GT97xx VCM
From: Zhi Mao @ 2024-04-10 10:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Zhi Mao,
Philipp Zabel, Laurent Pinchart, Heiko Stuebner, Sakari Ailus,
Hans Verkuil, Hans de Goede, Tomi Valkeinen, Alain Volmat,
Paul Elder, Mehdi Djait, Andy Shevchenko, Bingbu Cao, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
shengnan.wang, yaya.chang, yunkec, 10572168
This series add YAML DT binding and V4L2 sub-device driver for Giantec's GT9768>9769.
GT9768>9769 is a 10-bit DAC with 100mA output current sink capability, designed
for voice coil motor(VCM) with I2C control bus.
This driver supports:
- support pm runtime function for suspend/resume
- support camera lens focus position by V4L2_CID_FOCUS_ABSOLUTE CMD
- used in camera features on ChromeOS application
This series is based on linux-next, tag: next-20240409
Thanks
Zhi Mao (2):
media: dt-bindings: i2c: add Giantec GT97xx VCM driver
media: i2c: Add GT97xx VCM driver
.../bindings/media/i2c/giantec,gt97xx.yaml | 91 +++
drivers/media/i2c/Kconfig | 13 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/gt97xx.c | 640 ++++++++++++++++++
4 files changed, 745 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml
create mode 100644 drivers/media/i2c/gt97xx.c
--
2.25.1
^ permalink raw reply
* [PATCH 1/2] media: dt-bindings: i2c: add Giantec GT97xx VCM driver
From: Zhi Mao @ 2024-04-10 10:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Zhi Mao,
Philipp Zabel, Laurent Pinchart, Heiko Stuebner, Sakari Ailus,
Hans Verkuil, Hans de Goede, Tomi Valkeinen, Alain Volmat,
Paul Elder, Mehdi Djait, Andy Shevchenko, Bingbu Cao, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
shengnan.wang, yaya.chang, yunkec, 10572168
In-Reply-To: <20240410104002.1197-1-zhi.mao@mediatek.com>
Add YAML device tree binding for GT97xx VCM driver,
and the relevant MAINTAINERS entries.
Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
---
.../bindings/media/i2c/giantec,gt97xx.yaml | 91 +++++++++++++++++++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml b/Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml
new file mode 100644
index 000000000000..8c9f1eb4dac8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/giantec,gt97xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Giantec Semiconductor, Crop. GT97xx Voice Coil Motor (VCM)
+
+maintainers:
+ - Zhi Mao <zhi.mao@mediatek.com>
+
+description: |-
+ The Giantec GT97xx is a 10-bit DAC with current sink capability.
+ The DAC is controlled via I2C bus that operates at clock rates up to 1MHz.
+ This chip integrates Advanced Actuator Control (AAC) technology
+ and is intended for driving voice coil lens in camera modules.
+
+properties:
+ compatible:
+ enum:
+ - giantec,gt9768 # for GT9768 VCM
+ - giantec,gt9769 # for GT9769 VCM
+
+ reg:
+ maxItems: 1
+
+ vin-supply: true
+
+ vdd-supply: true
+
+ giantec,aac-mode:
+ description:
+ Indication of AAC mode select.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 1 # AAC2 mode(operation time# 0.48 x Tvib)
+ - 2 # AAC3 mode(operation time# 0.70 x Tvib)
+ - 3 # AAC4 mode(operation time# 0.75 x Tvib)
+ - 5 # AAC8 mode(operation time# 1.13 x Tvib)
+ default: 2
+
+ giantec,aac-timing:
+ description:
+ Number of AAC Timing count that controlled by one 6-bit period of
+ vibration register AACT[5:0], the unit of which is 100 us.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x20
+ minimum: 0x00
+ maximum: 0x3f
+
+ giantec,clock-presc:
+ description:
+ Indication of VCM internal clock dividing rate select, as one multiple
+ factor to calculate VCM ring periodic time Tvib.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # Dividing Rate - 2
+ - 1 # Dividing Rate - 1
+ - 2 # Dividing Rate - 1/2
+ - 3 # Dividing Rate - 1/4
+ - 4 # Dividing Rate - 8
+ - 5 # Dividing Rate - 4
+ default: 1
+
+required:
+ - compatible
+ - reg
+ - vin-supply
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vcm@c {
+ compatible = "giantec,gt9768";
+ reg = <0x0c>;
+
+ vin-supply = <>97xx_vin>;
+ vdd-supply = <>97xx_vdd>;
+ giantec,aac-timing = <0x20>;
+ };
+ };
+
+...
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] media: i2c: Add GT97xx VCM driver
From: Zhi Mao @ 2024-04-10 10:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Zhi Mao,
Philipp Zabel, Laurent Pinchart, Heiko Stuebner, Sakari Ailus,
Hans Verkuil, Hans de Goede, Tomi Valkeinen, Alain Volmat,
Paul Elder, Mehdi Djait, Andy Shevchenko, Bingbu Cao, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
shengnan.wang, yaya.chang, yunkec, 10572168
In-Reply-To: <20240410104002.1197-1-zhi.mao@mediatek.com>
Add a V4L2 sub-device driver for Giantec GT97xx VCM.
Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
---
drivers/media/i2c/Kconfig | 13 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/gt97xx.c | 640 +++++++++++++++++++++++++++++++++++++
3 files changed, 654 insertions(+)
create mode 100644 drivers/media/i2c/gt97xx.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 56f276b920ab..fcb330cebfe0 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -759,6 +759,19 @@ config VIDEO_DW9807_VCM
capability. This is designed for linear control of
voice coil motors, controlled via I2C serial interface.
+config VIDEO_GT97XX
+ tristate "GT97xx lens voice coil support"
+ depends on I2C && VIDEO_DEV
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
+ select V4L2_CCI_I2C
+ help
+ This is a driver for the GT97xx camera lens voice coil.
+ GT97xx is a 10 bit DAC with 100mA output current sink
+ capability. It is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
endmenu
menu "Flash devices"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index dfbe6448b549..af36a7aa3d12 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
obj-$(CONFIG_VIDEO_GC0308) += gc0308.o
obj-$(CONFIG_VIDEO_GC2145) += gc2145.o
+obj-$(CONFIG_VIDEO_GT97XX) += gt97xx.o
obj-$(CONFIG_VIDEO_HI556) += hi556.o
obj-$(CONFIG_VIDEO_HI846) += hi846.o
obj-$(CONFIG_VIDEO_HI847) += hi847.o
diff --git a/drivers/media/i2c/gt97xx.c b/drivers/media/i2c/gt97xx.c
new file mode 100644
index 000000000000..d91314b872fa
--- /dev/null
+++ b/drivers/media/i2c/gt97xx.c
@@ -0,0 +1,640 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Giantec gt97xx VCM lens device
+ *
+ * Copyright 2024 MediaTek
+ *
+ * Zhi Mao <zhi.mao@mediatek.com>
+ */
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/container_of.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/pm_runtime.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/types.h>
+#include <linux/units.h>
+
+#include <media/v4l2-cci.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-event.h>
+#include <media/v4l2-fwnode.h>
+#include <media/v4l2-subdev.h>
+
+/* gt97xx chip info register and name */
+#define GT97XX_IC_INFO_REG CCI_REG8(0x00)
+#define GT9768_ID 0xE9
+#define GT9769_ID 0xE1
+#define GT97XX_NAME "gt97xx"
+
+/*
+ * Ring control and Power control register
+ * Bit[1] RING_EN
+ * 0: Direct mode
+ * 1: AAC mode (ringing control mode)
+ * Bit[0] PD
+ * 0: Normal operation mode
+ * 1: Power down mode
+ * gt97xx requires waiting time of Topr after PD reset takes place.
+ */
+#define GT97XX_RING_PD_CONTROL_REG CCI_REG8(0x02)
+#define GT97XX_PD_MODE_OFF 0x00
+#define GT97XX_PD_MODE_EN BIT(0)
+#define GT97XX_AAC_MODE_EN BIT(1)
+
+/*
+ * gt97xx separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ * DAC_MSB: D[9:8] (ADD: 0x03)
+ * DAC_LSB: D[7:0] (ADD: 0x04)
+ * D[9:0] DAC data input: positive output current = D[9:0] / 1023 * 100[mA]
+ */
+#define GT97XX_MSB_ADDR_REG CCI_REG16(0x03)
+
+/*
+ * AAC mode control & prescale register
+ * Bit[7:5] Namely AC[2:0], decide the VCM mode and operation time.
+ * 001 AAC2 0.48 x Tvib
+ * 010 AAC3 0.70 x Tvib
+ * 011 AAC4 0.75 x Tvib
+ * 101 AAC8 1.13 x Tvib
+ * Bit[2:0] Namely PRESC[2:0], set the internal clock dividing rate as follow.
+ * 000 2
+ * 001 1
+ * 010 1/2
+ * 011 1/4
+ * 100 8
+ * 101 4
+ */
+#define GT97XX_AAC_PRESC_REG CCI_REG8(0x06)
+#define GT97XX_AAC_MODE_SEL_MASK GENMASK(7, 5)
+#define GT97XX_CLOCK_PRE_SCALE_SEL_MASK GENMASK(2, 0)
+
+/*
+ * VCM period of vibration register
+ * Bit[5:0] Defined as VCM rising periodic time (Tvib) together with PRESC[2:0]
+ * Tvib = (6.3ms + AACT[5:0] * 0.1ms) * Dividing Rate
+ * Dividing Rate is the internal clock dividing rate that is defined at
+ * PRESCALE register (ADD: 0x06)
+ */
+#define GT97XX_AAC_TIME_REG CCI_REG8(0x07)
+
+/*
+ * gt97xx requires waiting time (delay time) of t_OPR after power-up,
+ * or in the case of PD reset taking place.
+ */
+#define GT97XX_T_OPR_US (1 * USEC_PER_MSEC)
+#define GT97XX_TVIB_MS_BASE10 (64 - 1)
+#define GT97XX_AAC_MODE_DEFAULT 2
+#define GT97XX_AAC_TIME_DEFAULT 0x20
+#define GT97XX_CLOCK_PRE_SCALE_DEFAULT 1
+
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define GT97XX_MOVE_STEPS 16
+#define GT97XX_MAX_FOCUS_POS (1024 - 1)
+
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position
+ */
+#define GT97XX_FOCUS_STEPS 1
+
+enum vcm_giantec_reg_desc {
+ GT_IC_INFO_REG,
+ GT_RING_PD_CONTROL_REG,
+ GT_MSB_ADDR_REG,
+ GT_AAC_PRESC_REG,
+ GT_AAC_TIME_REG,
+ GT_MAX_REG,
+};
+
+struct vcm_giantec_of_data {
+ unsigned int id;
+ unsigned int regs[GT_MAX_REG];
+};
+
+static const char *const gt97xx_supply_names[] = {
+ "vin", /* Digital I/O power */
+ "vdd", /* Digital core power */
+};
+
+/* gt97xx device structure */
+struct gt97xx {
+ struct v4l2_subdev sd;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(gt97xx_supply_names)];
+
+ struct v4l2_ctrl_handler ctrls;
+ struct v4l2_ctrl *focus;
+
+ u32 aac_mode;
+ u32 aac_timing;
+ u32 clock_presc;
+ u32 move_delay_us;
+
+ struct regmap *regmap;
+
+ const struct vcm_giantec_of_data *chip;
+};
+
+static inline struct gt97xx *sd_to_gt97xx(struct v4l2_subdev *subdev)
+{
+ return container_of(subdev, struct gt97xx, sd);
+}
+
+struct regval_list {
+ u8 reg_num;
+ u8 value;
+};
+
+struct gt97xx_aac_mode_ot_multi {
+ u32 aac_mode_enum;
+ u32 ot_multi_base100;
+};
+
+struct gt97xx_clk_presc_dividing_rate {
+ u32 clk_presc_enum;
+ u32 dividing_rate_base100;
+};
+
+static const struct gt97xx_aac_mode_ot_multi aac_mode_ot_multi[] = {
+ { 1, 48 },
+ { 2, 70 },
+ { 3, 75 },
+ { 5, 113 },
+};
+
+static const struct gt97xx_clk_presc_dividing_rate presc_dividing_rate[] = {
+ { 0, 200 }, { 1, 100 }, { 2, 50 }, { 3, 25 }, { 4, 800 }, { 5, 400 },
+};
+
+static u32 gt97xx_find_ot_multi(u32 aac_mode_param)
+{
+ u32 cur_ot_multi_base100 = 70;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(aac_mode_ot_multi); i++) {
+ if (aac_mode_ot_multi[i].aac_mode_enum == aac_mode_param) {
+ cur_ot_multi_base100 =
+ aac_mode_ot_multi[i].ot_multi_base100;
+ }
+ }
+
+ return cur_ot_multi_base100;
+}
+
+static u32 gt97xx_find_dividing_rate(u32 presc_param)
+{
+ u32 cur_clk_dividing_rate_base100 = 100;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(presc_dividing_rate); i++) {
+ if (presc_dividing_rate[i].clk_presc_enum == presc_param) {
+ cur_clk_dividing_rate_base100 =
+ presc_dividing_rate[i].dividing_rate_base100;
+ }
+ }
+
+ return cur_clk_dividing_rate_base100;
+}
+
+/*
+ * GT97xx_AAC_PRESC_REG & GT97xx_AAC_TIME_REG determine VCM operation time.
+ * For current VCM mode: AAC3, Operation Time would be 0.70 x Tvib.
+ * Tvib = (6.3ms + AACT[5:0] * 0.1MS) * Dividing Rate.
+ * Below is calculation of the operation delay for each step.
+ */
+static inline u32 gt97xx_cal_move_delay(u32 aac_mode_param, u32 presc_param,
+ u32 aac_timing_param)
+{
+ u32 tvib_us;
+ u32 ot_multi_base100;
+ u32 clk_dividing_rate_base100;
+
+ ot_multi_base100 = gt97xx_find_ot_multi(aac_mode_param);
+
+ clk_dividing_rate_base100 = gt97xx_find_dividing_rate(presc_param);
+
+ tvib_us = (GT97XX_TVIB_MS_BASE10 + aac_timing_param) *
+ clk_dividing_rate_base100;
+
+ return tvib_us * ot_multi_base100 / 100;
+}
+
+static int gt97xx_mod_reg(struct gt97xx *gt97xx, u32 reg, u8 mask, u8 val)
+{
+ u64 read_val;
+ int ret;
+
+ ret = cci_read(gt97xx->regmap, reg, &read_val, NULL);
+ if (ret < 0)
+ return ret;
+
+ val = ((unsigned char)read_val & ~mask) | (val & mask);
+
+ return cci_write(gt97xx->regmap, reg, val, NULL);
+}
+
+static int gt97xx_set_dac(struct gt97xx *gt97xx, u16 val)
+{
+ /* Write VCM position to registers */
+ return cci_write(gt97xx->regmap,
+ gt97xx->chip->regs[GT_MSB_ADDR_REG], val, NULL);
+}
+
+static int gt97xx_identify_module(struct gt97xx *gt97xx)
+{
+ int ret;
+ u64 ic_id;
+ struct i2c_client *client = v4l2_get_subdevdata(>97xx->sd);
+
+ ret = cci_read(gt97xx->regmap, gt97xx->chip->regs[GT_IC_INFO_REG],
+ &ic_id, NULL);
+ if (ret < 0)
+ return ret;
+
+ if (ic_id != gt97xx->chip->id) {
+ dev_err(&client->dev, "chip id mismatch: 0x%x!=0x%llx",
+ gt97xx->chip->id, ic_id);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int gt97xx_init(struct gt97xx *gt97xx)
+{
+ int ret, val;
+
+ ret = gt97xx_identify_module(gt97xx);
+ if (ret < 0)
+ return ret;
+
+ /* Reset GT97xx_RING_PD_CONTROL_REG to default status 0x00 */
+ ret = cci_write(gt97xx->regmap,
+ gt97xx->chip->regs[GT_RING_PD_CONTROL_REG],
+ GT97XX_PD_MODE_OFF, NULL);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * GT97xx requires waiting delay time of t_OPR
+ * after PD reset takes place.
+ */
+ fsleep(GT97XX_T_OPR_US);
+
+ /* Set GT97xx_RING_PD_CONTROL_REG to GT97xx_AAC_MODE_EN(0x01) */
+ ret = cci_write(gt97xx->regmap,
+ gt97xx->chip->regs[GT_RING_PD_CONTROL_REG],
+ GT97XX_AAC_MODE_EN, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Set AAC mode */
+ ret = gt97xx_mod_reg(gt97xx, gt97xx->chip->regs[GT_AAC_PRESC_REG],
+ GT97XX_AAC_MODE_SEL_MASK, gt97xx->aac_mode << 5);
+ if (ret < 0)
+ return ret;
+
+ /* Set clock presc */
+ if (gt97xx->clock_presc != GT97XX_CLOCK_PRE_SCALE_DEFAULT) {
+ ret = gt97xx_mod_reg(gt97xx,
+ gt97xx->chip->regs[GT_AAC_PRESC_REG],
+ GT97XX_CLOCK_PRE_SCALE_SEL_MASK,
+ gt97xx->clock_presc);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Set AAC Timing */
+ if (gt97xx->aac_timing != GT97XX_AAC_TIME_DEFAULT) {
+ ret = cci_write(gt97xx->regmap,
+ gt97xx->chip->regs[GT_AAC_TIME_REG],
+ gt97xx->aac_timing, NULL);
+ if (ret < 0)
+ return ret;
+ }
+
+ for (val = gt97xx->focus->val % GT97XX_MOVE_STEPS;
+ val <= gt97xx->focus->val; val += GT97XX_MOVE_STEPS) {
+ ret = gt97xx_set_dac(gt97xx, val);
+ if (ret)
+ return ret;
+
+ fsleep(gt97xx->move_delay_us);
+ }
+
+ return 0;
+}
+
+static int gt97xx_release(struct gt97xx *gt97xx)
+{
+ int ret, val;
+
+ val = round_down(gt97xx->focus->val, GT97XX_MOVE_STEPS);
+ for (; val >= 0; val -= GT97XX_MOVE_STEPS) {
+ ret = gt97xx_set_dac(gt97xx, val);
+ if (ret)
+ return ret;
+
+ fsleep(gt97xx->move_delay_us);
+ }
+
+ return 0;
+}
+
+static int gt97xx_power_on(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct gt97xx *gt97xx = sd_to_gt97xx(sd);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(gt97xx_supply_names),
+ gt97xx->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable regulators\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+static int gt97xx_power_off(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct gt97xx *gt97xx = sd_to_gt97xx(sd);
+ int ret;
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(gt97xx_supply_names),
+ gt97xx->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to disable regulators\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+static int gt97xx_runtime_suspend(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct gt97xx *gt97xx = sd_to_gt97xx(sd);
+
+ gt97xx_release(gt97xx);
+ gt97xx_power_off(dev);
+
+ return 0;
+}
+
+static int gt97xx_runtime_resume(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct gt97xx *gt97xx = sd_to_gt97xx(sd);
+ int ret;
+
+ ret = gt97xx_power_on(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to power_on\n");
+ return ret;
+ }
+
+ /*
+ * The datasheet refers to t_OPR that needs to be waited before sending
+ * I2C commands after power-up.
+ */
+ fsleep(GT97XX_T_OPR_US);
+
+ ret = gt97xx_init(gt97xx);
+ if (ret < 0)
+ goto disable_power;
+
+ return 0;
+
+disable_power:
+ gt97xx_power_off(dev);
+
+ return ret;
+}
+
+static int gt97xx_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct gt97xx *gt97xx =
+ container_of(ctrl->handler, struct gt97xx, ctrls);
+
+ if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
+ return gt97xx_set_dac(gt97xx, ctrl->val);
+
+ return 0;
+}
+
+static const struct v4l2_ctrl_ops gt97xx_ctrl_ops = {
+ .s_ctrl = gt97xx_set_ctrl,
+};
+
+static int gt97xx_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+ return pm_runtime_resume_and_get(sd->dev);
+}
+
+static int gt97xx_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+ return pm_runtime_put(sd->dev);
+}
+
+static const struct v4l2_subdev_internal_ops gt97xx_int_ops = {
+ .open = gt97xx_open,
+ .close = gt97xx_close,
+};
+
+static const struct v4l2_subdev_core_ops gt97xx_core_ops = {
+ .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
+ .unsubscribe_event = v4l2_event_subdev_unsubscribe,
+};
+
+static const struct v4l2_subdev_ops gt97xx_ops = {
+ .core = >97xx_core_ops,
+};
+
+static int gt97xx_init_controls(struct gt97xx *gt97xx)
+{
+ struct v4l2_ctrl_handler *hdl = >97xx->ctrls;
+ const struct v4l2_ctrl_ops *ops = >97xx_ctrl_ops;
+
+ v4l2_ctrl_handler_init(hdl, 1);
+
+ gt97xx->focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE, 0,
+ GT97XX_MAX_FOCUS_POS,
+ GT97XX_FOCUS_STEPS, 0);
+
+ if (hdl->error)
+ return hdl->error;
+
+ gt97xx->sd.ctrl_handler = hdl;
+
+ return 0;
+}
+
+static int gt97xx_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct gt97xx *gt97xx;
+ unsigned int i;
+ int ret;
+
+ gt97xx = devm_kzalloc(dev, sizeof(*gt97xx), GFP_KERNEL);
+ if (!gt97xx)
+ return -ENOMEM;
+
+ gt97xx->regmap = devm_cci_regmap_init_i2c(client, 8);
+ if (IS_ERR(gt97xx->regmap))
+ return dev_err_probe(dev, PTR_ERR(gt97xx->regmap),
+ "failed to init CCI\n");
+
+ /* Initialize subdev */
+ v4l2_i2c_subdev_init(>97xx->sd, client, >97xx_ops);
+
+ gt97xx->chip = of_device_get_match_data(dev);
+
+ gt97xx->aac_mode = GT97XX_AAC_MODE_DEFAULT;
+ gt97xx->aac_timing = GT97XX_AAC_TIME_DEFAULT;
+ gt97xx->clock_presc = GT97XX_CLOCK_PRE_SCALE_DEFAULT;
+
+ /* Optional indication of AAC mode select */
+ fwnode_property_read_u32(dev_fwnode(dev), "giantec,aac-mode",
+ >97xx->aac_mode);
+
+ /* Optional indication of clock pre-scale select */
+ fwnode_property_read_u32(dev_fwnode(dev), "giantec,clock-presc",
+ >97xx->clock_presc);
+
+ /* Optional indication of AAC Timing */
+ fwnode_property_read_u32(dev_fwnode(dev), "giantec,aac-timing",
+ >97xx->aac_timing);
+
+ gt97xx->move_delay_us = gt97xx_cal_move_delay(gt97xx->aac_mode,
+ gt97xx->clock_presc,
+ gt97xx->aac_timing);
+
+ for (i = 0; i < ARRAY_SIZE(gt97xx_supply_names); i++)
+ gt97xx->supplies[i].supply = gt97xx_supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(gt97xx_supply_names),
+ gt97xx->supplies);
+ if (ret < 0)
+ return dev_err_probe(dev, ret,
+ "failed to get regulators\n");
+
+ /* Initialize controls */
+ ret = gt97xx_init_controls(gt97xx);
+ if (ret)
+ goto err_free_handler;
+
+ /* Initialize subdev */
+ gt97xx->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ gt97xx->sd.internal_ops = >97xx_int_ops;
+ gt97xx->sd.entity.function = MEDIA_ENT_F_LENS;
+
+ ret = media_entity_pads_init(>97xx->sd.entity, 0, NULL);
+ if (ret < 0)
+ goto err_free_handler;
+
+ /*power on and Initialize hw*/
+ ret = gt97xx_runtime_resume(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to power on: %d\n", ret);
+ goto err_clean_entity;
+ }
+
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ pm_runtime_set_autosuspend_delay(dev, 1000);
+ pm_runtime_use_autosuspend(dev);
+ pm_runtime_idle(dev);
+
+ ret = v4l2_async_register_subdev(>97xx->sd);
+ if (ret < 0) {
+ dev_err(dev, "failed to register V4L2 subdev: %d", ret);
+ goto err_power_off;
+ }
+
+ return 0;
+
+err_power_off:
+ pm_runtime_disable(dev);
+err_clean_entity:
+ media_entity_cleanup(>97xx->sd.entity);
+err_free_handler:
+ v4l2_ctrl_handler_free(>97xx->ctrls);
+
+ return ret;
+}
+
+static void gt97xx_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct gt97xx *gt97xx = sd_to_gt97xx(sd);
+
+ v4l2_async_unregister_subdev(>97xx->sd);
+ v4l2_ctrl_handler_free(>97xx->ctrls);
+ media_entity_cleanup(>97xx->sd.entity);
+ pm_runtime_disable(&client->dev);
+ if (!pm_runtime_status_suspended(&client->dev))
+ gt97xx_runtime_suspend(&client->dev);
+ pm_runtime_set_suspended(&client->dev);
+}
+
+static DEFINE_RUNTIME_DEV_PM_OPS(gt97xx_pm_ops,
+ gt97xx_runtime_suspend,
+ gt97xx_runtime_resume,
+ NULL);
+
+static const struct vcm_giantec_of_data gt9768_data = {
+ .id = GT9768_ID,
+ .regs[GT_IC_INFO_REG] = GT97XX_IC_INFO_REG,
+ .regs[GT_RING_PD_CONTROL_REG] = GT97XX_RING_PD_CONTROL_REG,
+ .regs[GT_MSB_ADDR_REG] = GT97XX_MSB_ADDR_REG,
+ .regs[GT_AAC_PRESC_REG] = GT97XX_AAC_PRESC_REG,
+ .regs[GT_AAC_TIME_REG] = GT97XX_AAC_TIME_REG,
+};
+
+static const struct vcm_giantec_of_data gt9769_data = {
+ .id = GT9769_ID,
+ .regs[GT_IC_INFO_REG] = GT97XX_IC_INFO_REG,
+ .regs[GT_RING_PD_CONTROL_REG] = GT97XX_RING_PD_CONTROL_REG,
+ .regs[GT_MSB_ADDR_REG] = GT97XX_MSB_ADDR_REG,
+ .regs[GT_AAC_PRESC_REG] = GT97XX_AAC_PRESC_REG,
+ .regs[GT_AAC_TIME_REG] = GT97XX_AAC_TIME_REG,
+};
+
+static const struct of_device_id gt97xx_of_table[] = {
+ { .compatible = "giantec,gt9768", .data = >9768_data },
+ { .compatible = "giantec,gt9769", .data = >9769_data },
+ {}
+};
+MODULE_DEVICE_TABLE(of, gt97xx_of_table);
+
+static struct i2c_driver gt97xx_i2c_driver = {
+ .driver = {
+ .name = GT97XX_NAME,
+ .pm = pm_ptr(>97xx_pm_ops),
+ .of_match_table = gt97xx_of_table,
+ },
+ .probe = gt97xx_probe,
+ .remove = gt97xx_remove,
+};
+module_i2c_driver(gt97xx_i2c_driver);
+
+MODULE_AUTHOR("Zhi Mao <zhi.mao@mediatek.com>");
+MODULE_DESCRIPTION("GT97xx VCM driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related
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