* [PATCH v5 3/5] clk: qcom: common: Add interconnect clocks support
From: Varadarajan Narayanan @ 2024-03-28 7:59 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, djakov, dmitry.baryshkov,
quic_varada, quic_anusha, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm
In-Reply-To: <20240328075936.223461-1-quic_varada@quicinc.com>
Unlike MSM platforms that manage NoC related clocks and scaling
from RPM, IPQ SoCs dont involve RPM in managing NoC related
clocks and there is no NoC scaling.
However, there is a requirement to enable some NoC interface
clocks for accessing the peripheral controllers present on
these NoCs. Though exposing these as normal clocks would work,
having a minimalistic interconnect driver to handle these clocks
would make it consistent with other Qualcomm platforms resulting
in common code paths. This is similar to msm8996-cbf's usage of
icc-clk framework.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v5: Split changes in common.c to separate patch
Fix error handling
Use devm_icc_clk_register instead of icc_clk_register
v4: Use clk_hw instead of indices
Do icc register in qcom_cc_probe() call stream
Add icc clock info to qcom_cc_desc structure
v3: Use indexed identifiers here to avoid confusion
Fix error messages and move to common.c
v2: Move DTS to separate patch
Update commit log
Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK to fix build error
---
drivers/clk/qcom/common.c | 39 ++++++++++++++++++++++++++++++++++++++-
drivers/clk/qcom/common.h | 3 +++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index 75f09e6e057e..9fa271812373 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -8,6 +8,8 @@
#include <linux/regmap.h>
#include <linux/platform_device.h>
#include <linux/clk-provider.h>
+#include <linux/interconnect-clk.h>
+#include <linux/interconnect-provider.h>
#include <linux/reset-controller.h>
#include <linux/of.h>
@@ -234,6 +236,41 @@ static struct clk_hw *qcom_cc_clk_hw_get(struct of_phandle_args *clkspec,
return cc->rclks[idx] ? &cc->rclks[idx]->hw : NULL;
}
+#if IS_ENABLED(CONFIG_INTERCONNECT_CLK)
+static int qcom_cc_icc_register(struct device *dev,
+ const struct qcom_cc_desc *desc)
+{
+ struct icc_clk_data *icd;
+ int i;
+
+ if (!desc->icc_hws)
+ return 0;
+
+ icd = devm_kcalloc(dev, desc->num_icc_hws, sizeof(*icd), GFP_KERNEL);
+ if (!icd)
+ return -ENOMEM;
+
+ for (i = 0; i < desc->num_icc_hws; i++) {
+ icd[i].clk = devm_clk_hw_get_clk(dev, desc->icc_hws[i], "qcom");
+ if (IS_ERR(icd[i].clk))
+ return dev_err_probe(dev, PTR_ERR(icd[i].clk),
+ "get clock failed (%ld)\n",
+ PTR_ERR(icd[i].clk));
+
+ icd[i].name = clk_hw_get_name(desc->icc_hws[i]);
+ }
+
+ return PTR_ERR_OR_ZERO(devm_icc_clk_register(dev, desc->first_id,
+ desc->num_icc_hws, icd));
+}
+#else
+static int qcom_cc_icc_register(struct device *dev,
+ const struct qcom_cc_desc *desc)
+{
+ return 0;
+}
+#endif
+
int qcom_cc_really_probe(struct platform_device *pdev,
const struct qcom_cc_desc *desc, struct regmap *regmap)
{
@@ -303,7 +340,7 @@ int qcom_cc_really_probe(struct platform_device *pdev,
if (ret)
return ret;
- return 0;
+ return qcom_cc_icc_register(dev, desc);
}
EXPORT_SYMBOL_GPL(qcom_cc_really_probe);
diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
index 9c8f7b798d9f..d8ac26d83f3c 100644
--- a/drivers/clk/qcom/common.h
+++ b/drivers/clk/qcom/common.h
@@ -29,6 +29,9 @@ struct qcom_cc_desc {
size_t num_gdscs;
struct clk_hw **clk_hws;
size_t num_clk_hws;
+ struct clk_hw **icc_hws;
+ size_t num_icc_hws;
+ unsigned int first_id;
};
/**
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/5] interconnect: icc-clk: Add devm_icc_clk_register
From: Varadarajan Narayanan @ 2024-03-28 7:59 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, djakov, dmitry.baryshkov,
quic_varada, quic_anusha, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm
In-Reply-To: <20240328075936.223461-1-quic_varada@quicinc.com>
Wrap icc_clk_register to create devm_icc_clk_register to be
able to release the resources properly.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v5: Introduced devm_icc_clk_register
---
drivers/interconnect/icc-clk.c | 29 +++++++++++++++++++++++++++++
include/linux/interconnect-clk.h | 4 ++++
2 files changed, 33 insertions(+)
diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
index d787f2ea36d9..89f11fed8820 100644
--- a/drivers/interconnect/icc-clk.c
+++ b/drivers/interconnect/icc-clk.c
@@ -148,6 +148,35 @@ struct icc_provider *icc_clk_register(struct device *dev,
}
EXPORT_SYMBOL_GPL(icc_clk_register);
+static void devm_icc_release(struct device *dev, void *res)
+{
+ icc_clk_unregister(res);
+}
+
+struct icc_provider *devm_icc_clk_register(struct device *dev,
+ unsigned int first_id,
+ unsigned int num_clocks,
+ const struct icc_clk_data *data)
+{
+ struct icc_provider *prov, **provp;
+
+ provp = devres_alloc(devm_icc_release, sizeof(*provp), GFP_KERNEL);
+ if (!provp)
+ return ERR_PTR(-ENOMEM);
+
+ prov = icc_clk_register(dev, first_id, num_clocks, data);
+
+ if (!IS_ERR(prov)) {
+ *provp = prov;
+ devres_add(dev, provp);
+ } else {
+ devres_free(provp);
+ }
+
+ return prov;
+}
+EXPORT_SYMBOL_GPL(devm_icc_clk_register);
+
/**
* icc_clk_unregister() - unregister a previously registered clk interconnect provider
* @provider: provider returned by icc_clk_register()
diff --git a/include/linux/interconnect-clk.h b/include/linux/interconnect-clk.h
index 0cd80112bea5..cb7b648eb1c0 100644
--- a/include/linux/interconnect-clk.h
+++ b/include/linux/interconnect-clk.h
@@ -17,6 +17,10 @@ struct icc_provider *icc_clk_register(struct device *dev,
unsigned int first_id,
unsigned int num_clocks,
const struct icc_clk_data *data);
+struct icc_provider *devm_icc_clk_register(struct device *dev,
+ unsigned int first_id,
+ unsigned int num_clocks,
+ const struct icc_clk_data *data);
void icc_clk_unregister(struct icc_provider *provider);
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-03-28 7:59 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, djakov, dmitry.baryshkov,
quic_varada, quic_anusha, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm
Cc: Krzysztof Kozlowski
In-Reply-To: <20240328075936.223461-1-quic_varada@quicinc.com>
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.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
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 | 59 +++++++++++++++++++
2 files changed, 62 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..9c95fbd5dc46
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+#ifndef INTERCONNECT_QCOM_IPQ9574_H
+#define INTERCONNECT_QCOM_IPQ9574_H
+
+#define MASTER_ANOC_PCIE0_1 0
+#define SLAVE_ANOC_PCIE0_1 1
+#define MASTER_SNOC_PCIE0_1 2
+#define SLAVE_SNOC_PCIE0_1 3
+#define MASTER_ANOC_PCIE1_1 4
+#define SLAVE_ANOC_PCIE1_1 5
+#define MASTER_SNOC_PCIE1_1 6
+#define SLAVE_SNOC_PCIE1_1 7
+#define MASTER_ANOC_PCIE2_2 8
+#define SLAVE_ANOC_PCIE2_2 9
+#define MASTER_SNOC_PCIE2_2 10
+#define SLAVE_SNOC_PCIE2_2 11
+#define MASTER_ANOC_PCIE3_2 12
+#define SLAVE_ANOC_PCIE3_2 13
+#define MASTER_SNOC_PCIE3_2 14
+#define SLAVE_SNOC_PCIE3_2 15
+#define MASTER_USB 16
+#define SLAVE_USB 17
+#define MASTER_USB_AXI 18
+#define SLAVE_USB_AXI 19
+#define MASTER_NSSNOC_NSSCC 20
+#define SLAVE_NSSNOC_NSSCC 21
+#define MASTER_NSSNOC_SNOC 22
+#define SLAVE_NSSNOC_SNOC 23
+#define MASTER_NSSNOC_SNOC_1 24
+#define SLAVE_NSSNOC_SNOC_1 25
+#define MASTER_NSSNOC_PCNOC_1 26
+#define SLAVE_NSSNOC_PCNOC_1 27
+#define MASTER_NSSNOC_QOSGEN_REF 28
+#define SLAVE_NSSNOC_QOSGEN_REF 29
+#define MASTER_NSSNOC_TIMEOUT_REF 30
+#define SLAVE_NSSNOC_TIMEOUT_REF 31
+#define MASTER_NSSNOC_XO_DCD 32
+#define SLAVE_NSSNOC_XO_DCD 33
+#define MASTER_NSSNOC_ATB 34
+#define SLAVE_NSSNOC_ATB 35
+#define MASTER_MEM_NOC_NSSNOC 36
+#define SLAVE_MEM_NOC_NSSNOC 37
+#define MASTER_NSSNOC_MEMNOC 38
+#define SLAVE_NSSNOC_MEMNOC 39
+#define MASTER_NSSNOC_MEM_NOC_1 40
+#define SLAVE_NSSNOC_MEM_NOC_1 41
+
+#define MASTER_NSS_CC_NSSNOC_PPE 0
+#define SLAVE_NSS_CC_NSSNOC_PPE 1
+#define MASTER_NSS_CC_NSSNOC_PPE_CFG 2
+#define SLAVE_NSS_CC_NSSNOC_PPE_CFG 3
+#define MASTER_NSS_CC_NSSNOC_NSS_CSR 4
+#define SLAVE_NSS_CC_NSSNOC_NSS_CSR 5
+#define MASTER_NSS_CC_NSSNOC_IMEM_QSB 6
+#define SLAVE_NSS_CC_NSSNOC_IMEM_QSB 7
+#define MASTER_NSS_CC_NSSNOC_IMEM_AHB 8
+#define SLAVE_NSS_CC_NSSNOC_IMEM_AHB 9
+
+#endif /* INTERCONNECT_QCOM_IPQ9574_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/5] Add interconnect driver for IPQ9574 SoC
From: Varadarajan Narayanan @ 2024-03-28 7:59 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, djakov, dmitry.baryshkov,
quic_varada, quic_anusha, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm
MSM platforms manage NoC related clocks and scaling from RPM.
However, in IPQ SoCs, RPM is not involved in managing NoC
related clocks and there is no NoC scaling.
However, there is a requirement to enable some NoC interface
clocks for the accessing the peripherals present in the
system. Hence add a minimalistic interconnect driver that
establishes a path from the processor/memory to those peripherals
and vice versa.
---
v5:
Split gcc-ipq9574.c and common.c changes into separate patches
Introduce devm_icc_clk_register
Fix error handling
v4:
gcc-ipq9574.c
Use clk_hw instead of indices
common.c
Do icc register in qcom_cc_probe() call stream
common.h
Add icc clock info to qcom_cc_desc structure
v3:
qcom,ipq9574.h
Move 'first id' define to clock driver
gcc-ipq9574.c:
Use indexed identifiers here to avoid confusion
Fix error messages and move code to common.c as it can be
shared with future SoCs
v2:
qcom,ipq9574.h
Fix license identifier
Rename macros
qcom,ipq9574-gcc.yaml
Include interconnect-cells
gcc-ipq9574.c
Update commit log
Remove IS_ENABLED(CONFIG_INTERCONNECT) and auto select it from Kconfig
ipq9574.dtsi
Moved to separate patch
Include interconnect-cells to clock controller node
drivers/clk/qcom/Kconfig:
Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK
Varadarajan Narayanan (5):
dt-bindings: interconnect: Add Qualcomm IPQ9574 support
interconnect: icc-clk: Add devm_icc_clk_register
clk: qcom: common: Add interconnect clocks support
clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
arm64: dts: qcom: ipq9574: Add icc provider ability to gcc
.../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 2 +
drivers/clk/qcom/Kconfig | 2 +
drivers/clk/qcom/common.c | 39 +++++++++++-
drivers/clk/qcom/common.h | 3 +
drivers/clk/qcom/gcc-ipq9574.c | 54 +++++++++++++++++
drivers/interconnect/icc-clk.c | 29 +++++++++
.../dt-bindings/interconnect/qcom,ipq9574.h | 59 +++++++++++++++++++
include/linux/interconnect-clk.h | 4 ++
9 files changed, 194 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
--
2.34.1
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Krzysztof Kozlowski @ 2024-03-28 7:47 UTC (permalink / raw)
To: git, linux-media
Cc: dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240327231710.53188-19-git@luigi311.com>
On 28/03/2024 00:17, git@luigi311.com wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> There are a number of variants of the imx258 modules that can not
> be differentiated at runtime, so add compatible strings for them.
>
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Signed-off-by: Luigi311 <git@luigi311.com>
> ---
> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> index bee61a443b23..c7856de15ba3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> @@ -14,10 +14,14 @@ description: |-
> type stacked image sensor with a square pixel array of size 4208 x 3120. It
> is programmable through I2C interface. Image data is sent through MIPI
> CSI-2.
> + There are a number of variants of the sensor which cannot be detected at
> + runtime, so multiple compatible strings are required to differentiate these.
>
> properties:
> compatible:
> - const: sony,imx258
> + - enum:
> + - sony,imx258
Two people working on patch but no one tested it before sending. Do not
send untested code.
It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: qcom: pm6150: correct Type-C compatible
From: Krzysztof Kozlowski @ 2024-03-28 7:45 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Dmitry Baryshkov,
Danila Tikhonov, linux-arm-msm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
The first part of the compatible of Type-C node misses ending quote,
thus we have one long compatible consisting of two compatible strings
leading to dtbs_check warnings:
sc7180-idp.dtb: usb-vbus-regulator@1100: compatible:0: 'qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg' does not match '^[a-zA-Z0-9][a-zA-Z0-9,+\\-._/]+$'
sc7180-idp.dtb: /soc@0/spmi@c440000/pmic@0/usb-vbus-regulator@1100: failed to match any schema with compatible: ['qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg']
Reported-by: Rob Herring <robh@kernel.org>
Fixes: f81c2f01cad6 ("arm64: dts: qcom: pm6150: define USB-C related blocks")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
arch/arm64/boot/dts/qcom/pm6150.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/pm6150.dtsi b/arch/arm64/boot/dts/qcom/pm6150.dtsi
index 11158c2bd524..b20a639cddf3 100644
--- a/arch/arm64/boot/dts/qcom/pm6150.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm6150.dtsi
@@ -71,8 +71,8 @@ pm6150_vbus: usb-vbus-regulator@1100 {
};
pm6150_typec: typec@1500 {
- compatible = "qcom,pm6150-typec,
- qcom,pm8150b-typec";
+ compatible = "qcom,pm6150-typec",
+ "qcom,pm8150b-typec";
reg = <0x1500>, <0x1700>;
interrupts = <0x0 0x15 0x00 IRQ_TYPE_EDGE_RISING>,
<0x0 0x15 0x01 IRQ_TYPE_EDGE_BOTH>,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/2] phy: qcom-qmp-ufs: Add SM8475 support
From: Vinod Koul @ 2024-03-28 7:45 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Danila Tikhonov, andersson, kishon, robh, krzysztof.kozlowski+dt,
conor+dt, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <afcbb668-ab9e-4f97-9014-ecbd5170ab92@linaro.org>
On 27-03-24, 22:38, Konrad Dybcio wrote:
> On 27.03.2024 7:06 PM, Danila Tikhonov wrote:
> > Add the tables and constants for init sequences for UFS QMP phy found in
> > SM8475 SoC.
> >
> > Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
> > ---
>
> Worth mentioning that SM8475 is a respin of SM8450 on a different
> process node, which probably forced some electrical changes.
should the tables be resued from 8450 instead of 8550 as in this patch?
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4
From: Chen-Yu Tsai @ 2024-03-28 7:44 UTC (permalink / raw)
To: Folker Schwesinger
Cc: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dragan Simic,
Christopher Obbard, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <D05701GE187C.3VLOERXP8B3NR@folker-schwesinger.de>
On Thu, Mar 28, 2024 at 3:09 PM Folker Schwesinger
<dev@folker-schwesinger.de> wrote:
>
> On Thu Mar 28, 2024 at 6:39 AM CET, Chen-Yu Tsai wrote:
> > > @@ -648,7 +649,8 @@ &saradc {
> > > &sdhci {
> > > max-frequency <150000000>;
> > > bus-width <8>;
> > > - mmc-hs200-1_8v;
> >
> > Shouldn't this be kept around? The node should list all supported modes,
> > not just the highest one. Same for the other patch.
> >
>
> This is not necessary, mmc-hs400-1_8v implicitly activates the
> corresponding HS200 capability, see drivers/mmc/core/host.c:
>
> if (device_property_read_bool(dev, "mmc-hs200-1_8v"))
> host->caps2 | MMC_CAP2_HS200_1_8V_SDR;
> /* ... */
> if (device_property_read_bool(dev, "mmc-hs400-1_8v"))
> host->caps2 | MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR;
Looking at the initial commit for adding the hs400 properties,
it was also mentioned that hs400 support implies hs200 support.
It just wasn't explicitly spelled out in the bindings.
In that case, I think we're good here for this particular case.
> Kind regards
>
> Folker
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/23] v2: imx258 improvement series
From: Krzysztof Kozlowski @ 2024-03-28 7:43 UTC (permalink / raw)
To: git, linux-media
Cc: dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240327231710.53188-1-git@luigi311.com>
On 28/03/2024 00:16, git@luigi311.com wrote:
> From: Luigi311 <git@luigi311.com>
>
> Resend due to email message limits being exceeded.
>
> v2 changes:
Please mark your patches correctly. Use b4 or -v2 for format-patch.
Best regards,
Krzysztof
^ permalink raw reply
* 回复: [PATCH v9 0/3] Add timer driver for StarFive JH7110 RISC-V SoC
From: Ziv Xu @ 2024-03-28 7:27 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Philipp Zabel, Walker Chen, Xingyu Wu,
linux-kernel@vger.kernel.org, Conor Dooley, Thomas Gleixner,
Emil Renner Berthing, Christophe JAILLET
In-Reply-To: <20240318030649.10413-1-ziv.xu@starfivetech.com>
> This patch serises are to add timer driver for the StarFive JH7110 RISC-V SoC.
> The first patch adds documentation to describe device tree bindings. The
> subsequent patch adds timer driver and support
> JH7110 SoC. The last patch adds device node about timer in JH7110 dts.
>
> This timer has four free-running 32 bit counters and runs in 24MHz clock on
> StarFive JH7110 SoC. And each channel(counter) triggers an interrupt when
> timeout. They support one-shot mode and continuous-run mode.
>
> This timer is used as global timer and register clockevent for each CPU core
> after riscv-timer registration on the StarFive JH7110 SoC.
>
> Changes since v8:
> - Rebased on 6.8
> - Improved the cpu hot swap startup process of the timer.
> - Modified irq request timing to prevent sleep.
> - Deleted clockevent suspend and resume function and these
> operations are included in cpu hot swap operations.
> - Formated data structures.
>
> v8:
> https://lore.kernel.org/all/20231219145402.7879-1-xingyu.wu@starfivetech.co
> m/
>
> Changes since v7:
> - Rebased on 6.7-rc6.
> - Modified the Kconfig file and added selection in SOC_STARFIVE.
> - Used the timer as a global timer and registered as clockevent
> for each CPU core.
> - Dropped the timeout function in the interrupt handler callback.
> - Changed the way in the functions of jh7110_timer_tick_resume() and
> jh7110_timer_resume().
> - Dropped the registration of clocksource in the probe.
>
> v7:
> https://lore.kernel.org/all/20231019053501.46899-1-xingyu.wu@starfivetech.c
> om/
>
> Changes since v6:
> - Rebased on 6.6-rc6.
> - Used sizeof() instead of the numbers of characters about names.
> - Added devm_add_action_or_reset() to release the resets and
> clocksources in the case of remove or error in the probe.
> - Added flags to check each clocksource is suceessfully registered and
> used in the release function.
> - Dropped the variable of irq in the jh7110_clkevt struct.
> - Dropped the wrappers and used enum definitions and writel() calls
> directly.
>
> v6:
> https://lore.kernel.org/all/20231012081015.33121-1-xingyu.wu@starfivetech.c
> om/
>
> Changes since v5:
> - Rebased on 6.6-rc5.
> - Changed the number about characters of name.
> - Made the clkevt->periodic to a local variable.
> - Dropped the variables of device and base.
> - Used clkevt->evt.irq directly and dropped the extra copy of irq.
>
> V5:
> https://lore.kernel.org/all/20230907053742.250444-1-xingyu.wu@starfivetech.
> com/
>
> Changes since v4:
> - Rebased on 6.5.
> - Dropped the useless enum and used value directly when writing
> registers.
> - Modified the description in Kconfig.
> - Add the reviewed tag in patch 3.
>
> v4:
> https://lore.kernel.org/all/20230814101603.166951-1-xingyu.wu@starfivetech.
> com/
>
> Changes since v3:
> - Rebased on 6.5-rc6
> - Dropped the useless enum names like 'JH7110_TIMER_CH_0'.
> - Dropped the platform data about JH7110 and used the register offsets
> directly.
> - Drroped the useless functions of clk_disable_unprepare().
>
> v3:
> https://lore.kernel.org/all/20230627055313.252519-1-xingyu.wu@starfivetech.
> com/
>
> Changes since v2:
> - Rebased on 6.4-rc7.
> - Merged the header file into the c file.
> - Renamed the functions from 'starfive_' to 'jh7110_'
> - Used function 'clocksource_register_hz' instead of
> 'clocksource_mmio_init'.
>
> v2:
> https://lore.kernel.org/all/20230320135433.144832-1-xingyu.wu@starfivetech.
> com/
>
> Changes since v1:
> - Added description about timer and modified properties' description
> in dt-bindings.
> - Dropped the 'interrupt-names' and 'clock-frequency' in dt-bindings.
> - Renamed the functions and added 'starfive_'
> - Modified that the driver probe by platform bus.
>
> v1:
> https://lore.kernel.org/all/20221223094801.181315-1-xingyu.wu@starfivetech.
> com/
>
> Xingyu Wu (3):
> dt-bindings: timer: Add timer for StarFive JH7110 SoC
> clocksource: Add JH7110 timer driver
> riscv: dts: jh7110: starfive: Add timer node
>
> .../bindings/timer/starfive,jh7110-timer.yaml | 96 +++++
> MAINTAINERS | 7 +
> arch/riscv/boot/dts/starfive/jh7110.dtsi | 20 +
> drivers/clocksource/Kconfig | 11 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-jh7110.c | 345 ++++++++++++++++++
> include/linux/cpuhotplug.h | 1 +
> 7 files changed, 481 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/timer/starfive,jh7110-timer.yaml
> create mode 100644 drivers/clocksource/timer-jh7110.c
>
> --
> 2.17.1
Hi, Daniel
Could you please help to review this patch and give your comments if you have time?
Thanks.
Best Regards
Ziv Xu
^ permalink raw reply
* Re: [PATCH 01/23] media: i2c: imx258: Remove unused defines
From: Krzysztof Kozlowski @ 2024-03-28 7:42 UTC (permalink / raw)
To: git, linux-media
Cc: dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240327231710.53188-2-git@luigi311.com>
On 28/03/2024 00:16, git@luigi311.com wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> The IMX258_FLL_* defines are unused. Remove them.
>
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Your SoB is missing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Dmitry Baryshkov @ 2024-03-28 7:17 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <zsjzysb7h3wi3cfpaozl46l4jnsd7e3lxttzm5vptozjx24cqo@vqmyhl65q7ay>
On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
>
> On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > >
> > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > MDSS, DP controller and the PHY that drives this.
> > >
> > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > 1 file changed, 40 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > index 63ebe0774f1d..f90bf3518e98 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > @@ -39,6 +39,20 @@ chosen {
> > > stdout-path = "serial0:115200n8";
> > > };
> > >
> > > + dp-connector {
> > > + compatible = "dp-connector";
> > > + label = "DP";
> > > + type = "mini";
> > > +
> > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> >
> > Is it the standard hpd gpio? If so, is there any reason for using it
> > through dp-connector rather than as a native HPD signal?
> >
>
> I added it because you asked for it. That said, I do like having it
> clearly defined in the devicetree.
I asked for the dp-connector device, not for the HPD function change.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4
From: Folker Schwesinger @ 2024-03-28 7:08 UTC (permalink / raw)
To: wens
Cc: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dragan Simic,
Christopher Obbard, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <CAGb2v64cF2fuW7vKq_=AhY+ciAp8t=fxT23AFJWB1qOv1xWuNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
On Thu Mar 28, 2024 at 6:39 AM CET, Chen-Yu Tsai wrote:
> > @@ -648,7 +649,8 @@ &saradc {
> > &sdhci {
> > max-frequency = <150000000>;
> > bus-width = <8>;
> > - mmc-hs200-1_8v;
>
> Shouldn't this be kept around? The node should list all supported modes,
> not just the highest one. Same for the other patch.
>
This is not necessary, mmc-hs400-1_8v implicitly activates the
corresponding HS200 capability, see drivers/mmc/core/host.c:
if (device_property_read_bool(dev, "mmc-hs200-1_8v"))
host->caps2 |= MMC_CAP2_HS200_1_8V_SDR;
/* ... */
if (device_property_read_bool(dev, "mmc-hs400-1_8v"))
host->caps2 |= MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR;
Kind regards
Folker
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-28 7:03 UTC (permalink / raw)
To: krzysztof.kozlowski@linaro.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <c59f2f33-ad6b-469d-96be-9345920370b4@linaro.org>
On Wed, 2024-03-27 at 12:04 +0100, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote:
> > On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
> >>
> >> External email : Please do not click links or open attachments
> until
> >> you have verified the sender or the content.
> >> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
> >>>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I will double check the format of yaml for the next version,
> >> sorry
> >>>> for
> >>>>> inconvenience. But I did test it on mt8188 chromebook, the
> reason
> >>>> why
> >>>>
> >>>> How do you test a binding on chromebook?
> >>>>
> >>>>> power domain need larb node is that when mtcmos power on,
> signal
> >>>> glitch
> >>>>> may produce. Power domain driver must reset larb when this
> happen
> >>>> to
> >>>>> prevent dummy transaction on bus. That why I need larb node in
> >> dts.
> >>>>
> >>>> No one talks here about larb node...
> >>>
> >>> Sorry, May you elaborate on what information I need to provide to
> >> you
> >>> or it is just a syntax problem I need to fix?
> >>
> >> Please explain the purpose of this property (how is it going to be
> >> used by drivers)and what does it represent.
> >>
> >
> > It represent SMI LARB(Local ARBitration). In power domain driver
> when
> > power on power domain, It need to reset LARB to prevent potential
> power
> > glitch which may cause dummy transaction on bus. Without taking
> care of
> > this issue it often leads to camera hang in stress test.
>
> That sounds rather like missing resets... or something else
> connecting
> these devices. Maybe the explanation is just imprecise...
>
Maybe the term "reset" is misleading here. What power domain driver
trying to do is "set and then clr" the smi larb to clear potential
glitch signal that is already in there. And this step is strongly
related to power domain onf that why I want to add it in to power
domain node without depending larb driver to do the work to prevent
this setting missing.
> Best regards,
> Krzysztof
Best Regards,
yu-chang
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6sl: tolino-shine2hd: fix IRQ config of touchscreen
From: Shawn Guo @ 2024-03-28 6:50 UTC (permalink / raw)
To: Andreas Kemnade
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, Dmitry Torokhov
In-Reply-To: <20240225225622.3419104-1-andreas@kemnade.info>
On Sun, Feb 25, 2024 at 11:56:22PM +0100, Andreas Kemnade wrote:
> Correctly describe the interrupt as level low. Driver enforces that
> anyways, but do not rely on that in the devicetree.
>
> Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Applied, thanks!
^ permalink raw reply
* [PATCH] arm64: dts: renesas: rzg3s-smarc-som: Fix ethernet aliases
From: Claudiu @ 2024-03-28 6:57 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, claudiu.beznea
From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Fix typo in ethernet aliases. U-Boot uses ethernetX (X={0, 1, ..., N})
aliases to update the DTB of Linux with MAC addresses. The ethernetX or
ethX aliases are not used in Linux by ravb_driver.
Fixes: 932ff0c802c6 ("arm64: dts: renesas: rzg3s-smarc-som: Enable the Ethernet interfaces")
Suggested-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
index acac4666ae59..1f87150a2e0a 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
@@ -36,8 +36,8 @@ aliases {
#if SW_CONFIG3 == SW_OFF
mmc2 = &sdhi2;
#else
- eth0 = ð0;
- eth1 = ð1;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
#endif
};
--
2.39.2
^ permalink raw reply related
* Re: [PATCH] ARM: dts: imx6: fix IRQ config of RC5T619
From: Shawn Guo @ 2024-03-28 6:50 UTC (permalink / raw)
To: Andreas Kemnade
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240225225720.3419129-1-andreas@kemnade.info>
On Sun, Feb 25, 2024 at 11:57:20PM +0100, Andreas Kemnade wrote:
> Set interrupt type to level low to correctly describe the hardware and
> do not rely on the driver to do the right thing.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 0/2] add uSDHC and SCMI nodes to the S32G2 SoC
From: Shawn Guo @ 2024-03-28 6:37 UTC (permalink / raw)
To: Ghennadi Procopciuc
Cc: Chester Lin, Andreas Farber, Matthias Brugger, Shawn Guo,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, NXP S32 Linux Team,
Pengutronix Kernel Team, NXP Linux Team, linux-arm-kernel,
devicetree, linux-kernel, linux-clk, Ghennadi Procopciuc
In-Reply-To: <20240122140602.1006813-1-ghennadi.procopciuc@oss.nxp.com>
On Mon, Jan 22, 2024 at 04:05:59PM +0200, Ghennadi Procopciuc wrote:
> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>
> This patchset adds device tree support for S32G2 SCMI firmware and uSDHC
> node. The SCMI clock IDs are based on a downstream version of the TF-A
> stored on GitHub [0].
>
> I can send the patches individually if you prefer that instead of
> submitting them all at once.??
>
> [0] https://github.com/nxp-auto-linux/arm-trusted-firmware
>
> Changes in v2:
> - The SCMI clock bindings header has been removed.
>
> Ghennadi Procopciuc (2):
> arm64: dts: s32g: add SCMI firmware node
> arm64: dts: s32g: add uSDHC node
Applied both, thanks!
^ permalink raw reply
* Re: 回复: 回复: 回复: [PATCH v1 1/2] dt-bindings: media: starfive: Match driver and yaml property names
From: Conor Dooley @ 2024-03-28 6:28 UTC (permalink / raw)
To: Changhuang Liang
Cc: Conor Dooley, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Emil Renner Berthing,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Jack Zhu,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <SHXPR01MB0671EA5AED87CE14113148E7F23BA@SHXPR01MB0671.CHNPR01.prod.partner.outlook.cn>
On 28 March 2024 01:06:42 GMT, Changhuang Liang <changhuang.liang@starfivetech.com> wrote:
>Hi, Conor,
>
>> On Mon, Jan 22, 2024 at 08:24:51AM +0000, Conor Dooley wrote:
>[...]
>> > > > > > Do these clocks etc exist but are not used by the driver?
>> > > > > >
>> > > > > > Or do they not exist at all?
>> > > > > >
>> > > > > > The two are very different!
>> > > >
>> > > > > These clocks etc exist but are not used by the driver.
>> > > >
>> > > > That's not an acceptable reason for removing them from the
>> > > > binding. If they exist, they should be documented, regardless of
>> > > > whether the driver makes use of them. NAK.
>> > >
>> > > If so, how to avoid the warning of dtbs_check.
>> >
>> > By also adding the clocks, resets and interrupts to the dts.
>>
>> Going through patchwork stuff now that the merge window is done. I'm gonna
>> mark the dts patch as changes requeted. The binding (and dts) should
>> describe all of the clocks the hardware has, whether or not you choose to use
>> them all in software does not matter. Can you please resend the dts patch,
>> with all of the clocks, resets and interrupts present?
>>
>
>You have applied the dts patch.
>https://lore.kernel.org/all/20240219032741.18387-1-changhuang.liang@starfivetech.com/
Oh, sorry for the noise then. I guess I was
mislead by patchwork marking this as new :)
^ permalink raw reply
* [PATCH] arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery
From: carlos.song @ 2024-03-28 6:14 UTC (permalink / raw)
To: shawnguo, robh, krzysztof.kozlowski+dt, conor+dt
Cc: frank.li, linux-arm-kernel, devicetree, linux-kernel
From: Carlos Song <carlos.song@nxp.com>
I2C bus recovery need a pinmux and gpio. So i2c driver can switch
gpio mode to toggle scl to recovery bus.
Add pinctrl-single node to every i2c bus on fsl-ls2160 layerscape
platform.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Frank Li <frank.li@nxp.com>
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index e665c629e1a1..96055593204a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -748,7 +748,10 @@ i2c0: i2c@2000000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
- scl-gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c0_scl>;
+ pinctrl-1 = <&i2c0_scl_gpio>;
+ scl-gpios = <&gpio0 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -761,6 +764,10 @@ i2c1: i2c@2010000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c1_scl>;
+ pinctrl-1 = <&i2c1_scl_gpio>;
+ scl-gpios = <&gpio0 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -773,6 +780,10 @@ i2c2: i2c@2020000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c2_scl>;
+ pinctrl-1 = <&i2c2_scl_gpio>;
+ scl-gpios = <&gpio0 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -785,6 +796,10 @@ i2c3: i2c@2030000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c3_scl>;
+ pinctrl-1 = <&i2c3_scl_gpio>;
+ scl-gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -797,7 +812,10 @@ i2c4: i2c@2040000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
- scl-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c4_scl>;
+ pinctrl-1 = <&i2c4_scl_gpio>;
+ scl-gpios = <&gpio0 25 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -810,6 +828,10 @@ i2c5: i2c@2050000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c5_scl>;
+ pinctrl-1 = <&i2c5_scl_gpio>;
+ scl-gpios = <&gpio0 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -822,6 +844,10 @@ i2c6: i2c@2060000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c6_scl>;
+ pinctrl-1 = <&i2c6_scl_gpio>;
+ scl-gpios = <&gpio1 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -834,6 +860,10 @@ i2c7: i2c@2070000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c7_scl>;
+ pinctrl-1 = <&i2c7_scl_gpio>;
+ scl-gpios = <&gpio1 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -1669,6 +1699,80 @@ pcs18: ethernet-phy@0 {
};
};
+ pinmux_i2crv: pinmux@70010012c {
+ compatible = "pinctrl-single";
+ reg = <0x00000007 0x0010012c 0x0 0xc>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x7>;
+
+ i2c1_scl: i2c1-scl-pins {
+ pinctrl-single,bits = <0x0 0 0x7>;
+ };
+
+ i2c1_scl_gpio: i2c1-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 0x1 0x7>;
+ };
+
+ i2c2_scl: i2c2-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 3)>;
+ };
+
+ i2c2_scl_gpio: i2c2-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 3) (0x7 << 3)>;
+ };
+
+ i2c3_scl: i2c3-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 6)>;
+ };
+
+ i2c3_scl_gpio: i2c3-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 6) (0x7 << 6)>;
+ };
+
+ i2c4_scl: i2c4-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 9)>;
+ };
+
+ i2c4_scl_gpio: i2c4-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 9) (0x7 << 9)>;
+ };
+
+ i2c5_scl: i2c5-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 12)>;
+ };
+
+ i2c5_scl_gpio: i2c5-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 12) (0x7 << 12)>;
+ };
+
+ i2c6_scl: i2c6-scl-pins {
+ pinctrl-single,bits = <0x4 0x2 0x7>;
+ };
+
+ i2c6_scl_gpio: i2c6-scl-gpio-pins {
+ pinctrl-single,bits = <0x4 0x1 0x7>;
+ };
+
+ i2c7_scl: i2c7-scl-pins {
+ pinctrl-single,bits = <0x4 0x2 0x7>;
+ };
+
+ i2c7_scl_gpio: i2c7-scl-gpio-pins {
+ pinctrl-single,bits = <0x4 0x1 0x7>;
+ };
+
+ i2c0_scl: i2c0-scl-pins {
+ pinctrl-single,bits = <0x8 0 (0x7 << 10)>;
+ };
+
+ i2c0_scl_gpio: i2c0-scl-gpio-pins {
+ pinctrl-single,bits = <0x8 (0x1 << 10) (0x7 << 10)>;
+ };
+ };
+
fsl_mc: fsl-mc@80c000000 {
compatible = "fsl,qoriq-mc";
reg = <0x00000008 0x0c000000 0 0x40>,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-28 6:06 UTC (permalink / raw)
To: amergnat@baylibre.com, krzysztof.kozlowski@linaro.org
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
Project_Global_Chrome_Upstream_Group, robh@kernel.org,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org,
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
ulf.hansson@linaro.org, Fan Chen (陳凡),
angelogioacchino.delregno@collabora.com
In-Reply-To: <CAFGrd9qZhObQXvm2_abqaX83xMLqxjQETB2=wXpobDWU1CnvkA@mail.gmail.com>
On Wed, 2024-03-27 at 12:55 +0100, Alexandre Mergnat wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> Hello Yu-chang Lee,
>
> SMI LARB must have a power domain, according to "mediatek,smi-
> larb.yaml"
> Now you try to create a link from power domain to larb.
>
> Here is my understanding: when you enable/disable power domain, the
> larb linked to this power domain may have an issue. Then you want to
> retrieve de LARB linked to the power domain though the dts to manage
> the LARB.
Yes, this is what I am trying to do.
> IMHO, using the dts to have this information into the power
> driver isn't necessary and may introduce some bugs if the LARB node
> and power node in the DTS aren't aligned.
>
> It seems not implemented today but during the LARB probe, it should
> "subscribe" to the linked power domain. Then, when the power domain
> status is changing, it is able to "notify" (callback) the LARB, then
> implement the good stuff to handle this power domain status change
> into LARB driver.
>
The problem with this method and why "smi clamp" is in power domain
driver is that our HW designer gave us a programming guide strictly
states the sequence of what we need to do to power on/off power domain.
Using callback, this sequence is no longer guaranteed and the side
effect is unknown...
So I would like to stick with adding larbs just like smi into power
domain node.
> Regards,
> Alexandre
Best Regards,
Yu-chang
>
> On Wed, Mar 27, 2024 at 12:04 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote:
> > > On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
> > >>
> > >> External email : Please do not click links or open attachments
> until
> > >> you have verified the sender or the content.
> > >> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
> > >>>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> I will double check the format of yaml for the next version,
> > >> sorry
> > >>>> for
> > >>>>> inconvenience. But I did test it on mt8188 chromebook, the
> reason
> > >>>> why
> > >>>>
> > >>>> How do you test a binding on chromebook?
> > >>>>
> > >>>>> power domain need larb node is that when mtcmos power on,
> signal
> > >>>> glitch
> > >>>>> may produce. Power domain driver must reset larb when this
> happen
> > >>>> to
> > >>>>> prevent dummy transaction on bus. That why I need larb node
> in
> > >> dts.
> > >>>>
> > >>>> No one talks here about larb node...
> > >>>
> > >>> Sorry, May you elaborate on what information I need to provide
> to
> > >> you
> > >>> or it is just a syntax problem I need to fix?
> > >>
> > >> Please explain the purpose of this property (how is it going to
> be
> > >> used by drivers)and what does it represent.
> > >>
> > >
> > > It represent SMI LARB(Local ARBitration). In power domain driver
> when
> > > power on power domain, It need to reset LARB to prevent potential
> power
> > > glitch which may cause dummy transaction on bus. Without taking
> care of
> > > this issue it often leads to camera hang in stress test.
> >
> > That sounds rather like missing resets... or something else
> connecting
> > these devices. Maybe the explanation is just imprecise...
> >
> > Best regards,
> > Krzysztof
> >
> >
^ permalink raw reply
* Re: [PATCH v1 1/4] dt-bindings: input: Add Himax HX83102J touchscreen
From: Allen Lin @ 2024-03-28 6:05 UTC (permalink / raw)
To: Conor Dooley
Cc: Conor Dooley, Rob Herring, dmitry.torokhov,
krzysztof.kozlowski+dt, conor+dt, jikos, benjamin.tissoires,
linux-input, devicetree, linux-kernel
In-Reply-To: <20240327-pegboard-deodorize-17d8b0f1e31c@spud>
Conor Dooley <conor@kernel.org> 於 2024年3月28日 週四 上午12:44寫道:
>
> On Wed, Mar 27, 2024 at 03:48:48PM +0800, Allen Lin wrote:
> > Conor Dooley <conor@kernel.org> 於 2024年3月27日 週三 上午3:28寫道:
> > >
> > > On Tue, Mar 26, 2024 at 06:40:28PM +0800, Allen Lin wrote:
> > > > Conor Dooley <conor.dooley@microchip.com> 於 2024年3月26日 週二 下午4:48寫道:
> > > > >
> > > > > On Tue, Mar 26, 2024 at 01:46:56PM +0800, Allen Lin wrote:
> > > > > > Conor Dooley <conor@kernel.org> 於 2024年3月23日 週六 上午2:34寫道:
> > > > > > >
> > > > > > > On Fri, Mar 22, 2024 at 01:30:09PM -0500, Rob Herring wrote:
> > > > > > > > On Fri, Mar 22, 2024 at 05:54:08PM +0000, Conor Dooley wrote:
> > > > > > > > > On Fri, Mar 22, 2024 at 04:56:03PM +0800, Allen_Lin wrote:
> > > > > > > > > > Add the HX83102j touchscreen device tree bindings documents.
> > > > > > > > > > HX83102j is a Himax TDDI touchscreen controller.
> > > > > > > > > > It's power sequence should be bound with a lcm driver, thus it
> > > > > > > > > > needs to be a panel follower. Others are the same as normal SPI
> > > > > > > > > > touchscreen controller.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Allen_Lin <allencl_lin@hotmail.com>
> > > > > > > > >
> > > > > > > > > note to self/Krzysztof/Rob:
> > > > > > > > > There was a previous attempt at this kind of device. This version looks
> > > > > > > > > better but might be incomplete given there's a bunch more properties in
> > > > > > > > > that patchset:
> > > > > > > > > https://lore.kernel.org/all/20231017091900.801989-1-tylor_yang@himax.corp-partner.google.com/
> > > > > > > >
> > > > > > > > Those don't look like properties we want coming back.
> > > > > > >
> > > > > > > Oh, I don't want most of them coming back either. There are some
> > > > > > > supplies in there though that I think we would like to come back, no?
> > > > > > > Maybe this particular device doesn't have any supplies, but that doesn't
> > > > > > > really seem credible.
> > > > > >
> > > > > > We will use Firmware-name in Device Tree.
> > > > >
> > > > > > For power supply settings, because there may be other device using
> > > > > > same regulator.
> > > > >
> > > > > If there are other devices using the same regulator is it more
> > > > > important that you document it so that it doesn't get disabled by the
> > > > > other users.
> > > > >
> > > > > > We plan to define it as an optional property for user to control in
> > > > > > next release.
> > > > >
> > > > > I don't see how the regulator would not be required, the device doesn't
> > > > > function without power.
> > > > >
> > > > > Thanks,
> > > > > Conor.
> > > >
> > > > I will set power supply as required.
> > > > The description of power supply as below,
> > > >
> > > > properties:
> > > > vccd-supply:
> > > > description: A phandle for the regualtor supplying IO power. Should be own
> > > > by TPIC only.
> > >
> > > What does "owned by TPIC" only mean? Why would the vccd supply not be
> > > allowed to be shared with another device?
> > >
> > > > This works for TP digital IO only, main power is
> > > > given by display part VSP/VSN power source which is controlled
> > > > by lcm driver.
> > >
> > > What drivers control things doesn't really matter here, we're just
> > > describing the hardware. If there's another supply to the controller,
> > > then document it too please.
> > >
> >
> > Below is IC power sequence introduction.
> > https://github.com/HimaxSoftware/Doc/tree/main/Himax_Chipset_Power_Sequence
> >
> > TDDI IC, which means Touch and Display Driver is integrated in one IC,
> > So some power supplies will be controlled by Display driver.
>
> If someone was to turn off the supplies, would the touch component stop
> working? The document says that these supplies must be turned on before
> the touch supplies, so I'm going to assume that both are needed for the
> device to function.
>
> > In yaml Document, can we just list power supplies controlled by touch driver?
>
> If the touch part of this device needs the supplies to function, then
> you need to mention them, regardless of where they're controlled. All we
> are doing in the binding is describing the hardware. What drivers do
> what depends entirely on what software you're using.
>
OK, I will list all supplies required by the driver in the Yaml
document as shown below,
properties:
compatible:
const: himax,hx83102j
reg:
maxItems: 1
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
vccd-supply:
description: A phandle for the regualtor supplying IO power.
vsn-supply:
description: Negative supply regulator.
vsp-supply:
description: Positive supply regulator.
ddreset-gpios:
description: A phandle of gpio for display reset controlled by the
LCD driver.
required:
- compatible
- reg
- interrupts
- reset-gpios
- panel
- vccd-supply
- vsn-supply
- vsp-supply
- ddreset-gpios
Thanks,
Allen
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: qcom: Update DT bindings for multiple DT
From: Chen-Yu Tsai @ 2024-03-28 5:49 UTC (permalink / raw)
To: Doug Anderson, Amrit Anand
Cc: Conor Dooley, Caleb Connolly, robh, krzysztof.kozlowski+dt,
conor+dt, agross, andersson, konrad.dybcio, devicetree,
linux-kernel, linux-arm-msm, kernel, peter.griffin, linux-riscv,
chrome-platform, linux-mediatek, Simon Glass, Julius Werner,
Elliot Berman
In-Reply-To: <CAD=FV=VZB9Dqsw6+2WBdWxaQVA9NgK_W2n0okBOU0haDMSogPw@mail.gmail.com>
On Tue, Mar 19, 2024 at 5:36 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Sat, Mar 16, 2024 at 9:51 AM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Sat, Mar 16, 2024 at 04:20:03PM +0000, Conor Dooley wrote:
> > > On Thu, Mar 14, 2024 at 02:20:38PM +0000, Caleb Connolly wrote:
> > > > On 14/03/2024 12:11, Amrit Anand wrote:
> > > > 2. A top level board-id property that isn't namespaced implies that it
> > > > isn't vendor specific, but the proposed implementation doesn't even
> > > > pretend to be vendor agnostic.
> > >
> > > I pointed out previously that the Chromebook guys had some similar
> > > issues with dtb selection when the OEM varies parts but there does not
> > > seem to be any of them on CC here.
> >
> > That's maybe a bit harsh of me actually, I see that there's a
> > chrome-platform address on CC, but I don't know if that's gonna reach
> > the guys that work on these devices (Chen-Yu Tsai and Doug Anderson in
> > particular).
>
> Thanks for the CC. Yeah, I don't watch the "chrome-platform" list
> myself, though maybe I should...
>
> The Chromebook boot flow and how we've handled this so far is
> documented in the kernel [1]. This method is what we've been using
> (with slight modifications over the years) since the earlier ARM
> Chromebooks and is, I believe, supported in both the depthcharge
> loader (used in Chromebooks) and also in U-Boot, though it's possible
> (?) that the U-Boot rules might vary ever so slightly. I haven't tried
> using U-Boot to boot a Chromebook in years.
>
> The current way things work for Chromebooks involves a heavy amount of
> duplication. We bundle an entire "DTB" for every relevant
> board/rev/sku combination even though many of those DTBs are 99% the
> same as the other ones. The DTBs have been relatively small and we
> compress them so this hasn't been a massive deal, but it's always been
> on the TODO list to come up with a scheme to use DT overlays. We've
> also talked about bundling a device tree that has the superset of
> components and then using an in-kernel driver to set the status of
> some components to okay and there is some overlap there in the
> possible way to represent board variants. I think Chen-Yu is going to
> talk about a few of these topics next month at EOSS [2].
That's right. It's the last talk before the closing game on the last day.
Elliot is also presenting the board-id proposal at EOSS [3], which is the
last talk of day 2.
> In terms of looking at your specific proposal, it's definitely trying
> to factor in a lot more things than the current one that Chromebooks
> use. The Chromebook model was "simple" enough that we could just
> leverage the compatible string, though the way we leverage it has
> ended up controversial over the years. Yours is definitely too
> complicated to work the same way. It seems like device tree overlays
> would be a better fit? I'm not an expert so maybe this is already
> solved somewhere, but I'd imagine the hard part is getting everyone to
> agree on how to specify stuff in the DT overlay that allows the
> bootloader to know whether to overlay it or not...
I think qcom,board-id + qcom,oem-id maps to our board name + SKU ID + revision.
The difference is probably because we make our device codenames public? We
don't actually have integer identifiers for each board family, though I do
see the appeal of it.
So it looks like this proposal is more about identifying boards without
polluting (?) the compatible namespace with all sorts of combinations
and hacks like we have.
> [1] https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html
> [2] https://eoss24.sched.com/event/1aBGe/second-source-component-probing-on-device-tree-platforms-chen-yu-tsai-google-llc
[3] https://eoss24.sched.com/event/1aBFy/shipping-multiple-devicetrees-how-to-identify-which-dtb-is-for-my-board-elliot-berman-qualcomm
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4
From: Chen-Yu Tsai @ 2024-03-28 5:39 UTC (permalink / raw)
To: Folker Schwesinger
Cc: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dragan Simic,
Christopher Obbard, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <20240327192641.14220-2-dev@folker-schwesinger.de>
On Thu, Mar 28, 2024 at 4:33 AM Folker Schwesinger
<dev@folker-schwesinger.de> wrote:
>
> Commit 8b5c2b45b8f0 disabled the internal pull-down for the strobe line
> causing I/O errors in HS400 mode for various eMMC modules.
>
> Enable the internal strobe pull-down for ROCK Pi 4 boards. Also re-enable
> HS400 mode, that was replaced with HS200 mode as a workaround for the
> stability issues in:
> cee572756aa2 ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4").
>
> This was tested on ROCK 4SE and ROCK Pi 4B+.
>
> Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts")
> Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
> ---
> arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
> index 281a12180703..b9d6284bb804 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
> @@ -194,6 +194,7 @@ &cpu_b1 {
> };
>
> &emmc_phy {
> + rockchip,enable-strobe-pulldown;
> status = "okay";
> };
>
> @@ -648,7 +649,8 @@ &saradc {
> &sdhci {
> max-frequency = <150000000>;
> bus-width = <8>;
> - mmc-hs200-1_8v;
Shouldn't this be kept around? The node should list all supported modes,
not just the highest one. Same for the other patch.
ChenYu
> + mmc-hs400-1_8v;
> + mmc-hs400-enhanced-strobe;
> non-removable;
> status = "okay";
> };
> --
> 2.44.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: rohm-bd71828: Add power off functionality
From: Matti Vaittinen @ 2024-03-28 5:15 UTC (permalink / raw)
To: Andreas Kemnade
Cc: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, devicetree,
linux-kernel
In-Reply-To: <20240327230252.0535e895@aktux>
Morning Andreas,
On 3/28/24 00:02, Andreas Kemnade wrote:
> Hi Matti,
>
> On Wed, 27 Mar 2024 16:11:36 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>
>> On 3/27/24 15:04, Andreas Kemnade wrote:
>>> Hi,
>>>
>>> On Wed, 27 Mar 2024 09:32:29 +0200
>>> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>>>
>>>> It's worth noting that there is another PMIC, BD71879, which, from the
>>>> driver software point of view, should be (almost?) identical to the
>>>> BD71828. I believe the BD71828 drivers should work with it as well - if
>>>> not out of the box, at least with very minor modifications.
>>>> Unfortunately I don't know products where the BD71879 is used or if it
>>>> is sold via distributors - so I don't know if adding a DT
>>>> compatible/chip type define for it would be beneficial.
>>>
>>> yes, you already told we thet the BD71828 drivers are compatible with
>>> the BD71879 and I am using the latter.
>>> But that at least should be commented somewhere, so that
>>> people do not raise questions, like: Do I have some strange board revision,
>>> etc?
>>> The most terse form to comment it is a separate dt compatible so we are
>>> prepare any "almost identical" surprises.
>>
>> I agree. Reason why I haven't done this already is that I don't always
>> (like in this case) know which of the variant are eventually sold. So,
>> it's balancing dance between adding compatibles for ICs that will never
>> been seen by large audience, and missing compatibles for some of the
>> variants.
>>
>> This is also why I was interested in knowing which variant you had, and
>> where was it used.
>>
> I have found it in the Kobo Clara 2E ebook reader.
> Kobo seems to switch from RC5T619 to BD71879.
> The Kobo Nia rev C also has that one.
> Kobo Libra 2 has several hardware revs out in the wild, some of them
> with the BD71879.
Thanks for the info :) It's a shame we so rarely know where things we
work for are used. I always find news like this interesting.
>> But yes, I think that as the BD71879 has obviously been found by a
>> community linux kernel user - it would make sense to add a compatible
>> for it!
>>
>> Do you feel like adding the compatible 'rohm,bd71879' in
>> rohm,bd71828-pmic.yaml as part of this series(?)
>
> Do we want a separate chip_type now? Or do we want to add it later if
> we ever see a difference. My personal opinion is to wait until there is
> really a need.
Using the BD71828 chip_id for BD71879 in the MFD driver is fine to me. A
comment saying they seem "functionally equivalent" can be added to
explain this choice.
> If we do not need it, then it is a different series I think but sure
> I will produce such a patch.
Great, thanks! I think it's clearer to have it as own patch, but I think
it fits in the same series - what suits you best. (Don't know if Lee or
DT peeps have different opinion.)
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ 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