* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Josua Mayer @ 2024-03-28 9:46 UTC (permalink / raw)
To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <68fd00b8-d6f1-463b-9d0d-b77bf9364f7f@linaro.org>
Am 28.03.24 um 10:41 schrieb Krzysztof Kozlowski:
> On 28/03/2024 10:33, Josua Mayer wrote:
>>>> 2. 88F8215, SouthBridge Communication Processor, System on Chip
>>>> (only usable in combination with a CN9130)
>>>>
>>>> Now, in terms of compatible string, what happens when a board
>>>> has multiples of these?
>>> Multiple of CN9130? 2x CN9130?
>> this specifically is an academic question,
>> the main point is multiple southbridges to one CN9130.
> I did not know to what you refer.
>
>>> You <cut> should know what is this about and come
>>> with explanation to the community.
>> If I was to come up with something new, without looking at existing
>> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>> I would describe the hardware like this:
>>
>> SolidRun "CN9131" SolidWAN board is comptible with:
>> - solidrun,cn9131-solidwan:
>> name of the carrier board, and name of the complete product
>> includes one southbridge chip, but I don't need to mention it?
>> - solidrun,cn9130-sr-som:
>> just the som, including 1x CN9130 SoC
>> - marvell,cn9130:
>> this is the SoC, internally combining AP+CP
>> AP *could* be mentioned, but I don't see a reason
> With an explanation in commit msg about not using other compatible
> fallbacks, this looks good to me.
Great. So perhaps my next step will be a v2 with explanations.
>
>>> You<cut>r platform maintainers should know what is this about and come
>>> with explanation to the community.
>> Is there a way forward?
>> Would it be worth challenging the existing bindings by proposing (RFC)
>> specific changes in line with what I described above?
> It all depends on "what" and "why" you want to do. I don't know.
First priority is supporting the solidrun boards based on cn9130 soc,
which requires getting the bindings right (at least for these boards).
Changing the other bindings would only satisfy my desire for order,
but could get attention from other contributors to these platforms.
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: exynos: gs101: join lines close to 80 chars
From: Krzysztof Kozlowski @ 2024-03-28 9:49 UTC (permalink / raw)
To: Tudor Ambarus, Alim Akhtar, peter.griffin, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
andre.draszik, willmcvicker, kernel-team
In-Reply-To: <454b88d5-885d-4933-ae49-46eaee99d75d@linaro.org>
On 26/03/2024 15:48, Tudor Ambarus wrote:
>
>
> On 3/26/24 11:10, Alim Akhtar wrote:
>> Hi Tudor
>
> Hi, Alim!
>>
>>> -----Original Message-----
>>> From: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> Sent: Tuesday, March 26, 2024 4:06 PM
>>> To: peter.griffin@linaro.org; robh+dt@kernel.org;
>>> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org
>>> Cc: alim.akhtar@samsung.com; linux-arm-kernel@lists.infradead.org; linux-
>>> samsung-soc@vger.kernel.org; devicetree@vger.kernel.org; linux-
>>> kernel@vger.kernel.org; andre.draszik@linaro.org;
>>> willmcvicker@google.com; kernel-team@android.com; Tudor Ambarus
>>> <tudor.ambarus@linaro.org>
>>> Subject: [PATCH v2 3/4] arm64: dts: exynos: gs101: join lines close to 80
>> chars
>>>
>>> These lines fit 81 characters, which is pretty close to 80.
>>> Join the lines.
>>>
>> Does this breaks checkpatch flow?
>
> ./scripts/checkpatch --strict does not complain
Because checkpatch does not have limit of 80... Coding style has, but
for readability it is fine to stretch or even break this rule.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8250 compatible
From: Luca Weiss @ 2024-03-28 9:49 UTC (permalink / raw)
To: Luca Weiss, Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh,
Krishna Manikandan, Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel
In-Reply-To: <20240328-sm6350-dp-v1-1-215ca2b81c35@fairphone.com>
Stupid typo in subject, should of course be SM6350, not SM8250.
On Thu Mar 28, 2024 at 10:42 AM CET, Luca Weiss wrote:
> Add the compatible string for the DisplayPort controller on SM6350 which
> is compatible with the one on SM8350.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> index ae53cbfb2193..97993feda193 100644
> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> @@ -29,6 +29,7 @@ properties:
> - qcom,sm8650-dp
> - items:
> - enum:
> + - qcom,sm6350-dp
> - qcom,sm8150-dp
> - qcom,sm8250-dp
> - qcom,sm8450-dp
^ permalink raw reply
* [PATCH 0/5] qcom: x1e80100: Enable CPUFreq
From: Sibi Sankar @ 2024-03-28 9:50 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt
Cc: linux-kernel, linux-arm-msm, devicetree, quic_rgottimu,
quic_kshivnan, quic_sibis, conor+dt, quic_gkohli, quic_nkela,
quic_psodagud
This series enables CPUFreq support on the X1E SoC using the SCMI perf
protocol. This was originally part of the RFC: firmware: arm_scmi:
Qualcomm Vendor Protocol [1]. I've split it up so that this part can
land earlier.
RFC:
* Use x1e80100 as the fallback for future SoCs using the cpucp-mbox
controller. [Krzysztoff/Konrad/Rob]
* Use chan->lock and chan->cl to detect if the channel is no longer
Available. [Dmitry]
* Use BIT() instead of using manual shifts. [Dmitry]
* Don't use integer as a pointer value. [Dmitry]
* Allow it to default to of_mbox_index_xlate. [Dmitry]
* Use devm_of_iomap. [Dmitry]
* Use module_platform_driver instead of module init/exit. [Dmitry]
* Get channel number using mailbox core (like other drivers) and
further simplify the driver by dropping setup_mbox func.
[1]: https://lore.kernel.org/lkml/20240117173458.2312669-1-quic_sibis@quicinc.com/#r
Other relevant Links:
https://lore.kernel.org/lkml/be2e475a-349f-4e98-b238-262dd7117a4e@linaro.org/
Sibi Sankar (5):
dt-bindings: mailbox: qcom: Add CPUCP mailbox controller bindings
mailbox: Add support for QTI CPUCP mailbox controller
arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region
arm64: dts: qcom: x1e80100: Add cpucp mailbox and sram nodes
arm64: dts: qcom: x1e80100: Enable cpufreq
.../bindings/mailbox/qcom,cpucp-mbox.yaml | 49 +++++
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 55 ++++-
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/qcom-cpucp-mbox.c | 205 ++++++++++++++++++
5 files changed, 318 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
create mode 100644 drivers/mailbox/qcom-cpucp-mbox.c
--
2.34.1
^ permalink raw reply
* [PATCH 1/5] dt-bindings: mailbox: qcom: Add CPUCP mailbox controller bindings
From: Sibi Sankar @ 2024-03-28 9:50 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt
Cc: linux-kernel, linux-arm-msm, devicetree, quic_rgottimu,
quic_kshivnan, quic_sibis, conor+dt, quic_gkohli, quic_nkela,
quic_psodagud
In-Reply-To: <20240328095044.2926125-1-quic_sibis@quicinc.com>
Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox
controller.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
---
rfc:
* Use x1e80100 as the fallback for future SoCs using the cpucp-mbox
controller. [Krzysztoff/Konrad/Rob]
.../bindings/mailbox/qcom,cpucp-mbox.yaml | 49 +++++++++++++++++++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
new file mode 100644
index 000000000000..491b0a05e630
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/qcom,cpucp-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. CPUCP Mailbox Controller
+
+maintainers:
+ - Sibi Sankar <quic_sibis@qti.qualcomm.com>
+
+description:
+ The CPUSS Control Processor (CPUCP) mailbox controller enables communication
+ between AP and CPUCP by acting as a doorbell between them.
+
+properties:
+ compatible:
+ items:
+ - const: qcom,x1e80100-cpucp-mbox
+
+ reg:
+ items:
+ - description: CPUCP rx register region
+ - description: CPUCP tx register region
+
+ interrupts:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@17430000 {
+ compatible = "qcom,x1e80100-cpucp-mbox";
+ reg = <0x17430000 0x10000>, <0x18830000 0x10000>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 2/5] mailbox: Add support for QTI CPUCP mailbox controller
From: Sibi Sankar @ 2024-03-28 9:50 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt
Cc: linux-kernel, linux-arm-msm, devicetree, quic_rgottimu,
quic_kshivnan, quic_sibis, conor+dt, quic_gkohli, quic_nkela,
quic_psodagud
In-Reply-To: <20240328095044.2926125-1-quic_sibis@quicinc.com>
Add support for CPUSS Control Processor (CPUCP) mailbox controller,
this driver enables communication between AP and CPUCP by acting as
a doorbell between them.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
---
rfc:
* Use chan->lock and chan->cl to detect if the channel is no longer
Available. [Dmitry]
* Use BIT() instead of using manual shifts. [Dmitry]
* Don't use integer as a pointer value. [Dmitry]
* Allow it to default to of_mbox_index_xlate. [Dmitry]
* Use devm_of_iomap. [Dmitry]
* Use module_platform_driver instead of module init/exit. [Dmitry]
* Get channel number using mailbox core (like other drivers) and
further simplify the driver by dropping setup_mbox func.
drivers/mailbox/Kconfig | 8 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/qcom-cpucp-mbox.c | 205 ++++++++++++++++++++++++++++++
3 files changed, 215 insertions(+)
create mode 100644 drivers/mailbox/qcom-cpucp-mbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 42940108a187..23741a6f054e 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -273,6 +273,14 @@ config SPRD_MBOX
to send message between application processors and MCU. Say Y here if
you want to build the Spreatrum mailbox controller driver.
+config QCOM_CPUCP_MBOX
+ tristate "Qualcomm Technologies, Inc. CPUCP mailbox driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ help
+ Qualcomm Technologies, Inc. CPUSS Control Processor (CPUCP) mailbox
+ controller driver enables communication between AP and CPUCP. Say
+ Y here if you want to build this driver.
+
config QCOM_IPCC
tristate "Qualcomm Technologies, Inc. IPCC driver"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 18793e6caa2f..53b512800bde 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -59,4 +59,6 @@ obj-$(CONFIG_SUN6I_MSGBOX) += sun6i-msgbox.o
obj-$(CONFIG_SPRD_MBOX) += sprd-mailbox.o
+obj-$(CONFIG_QCOM_CPUCP_MBOX) += qcom-cpucp-mbox.o
+
obj-$(CONFIG_QCOM_IPCC) += qcom-ipcc.o
diff --git a/drivers/mailbox/qcom-cpucp-mbox.c b/drivers/mailbox/qcom-cpucp-mbox.c
new file mode 100644
index 000000000000..e27a258fe57a
--- /dev/null
+++ b/drivers/mailbox/qcom-cpucp-mbox.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2024, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/platform_device.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+
+#define APSS_CPUCP_IPC_CHAN_SUPPORTED 3
+#define APSS_CPUCP_MBOX_CMD_OFF 0x4
+
+/* Tx Registers */
+#define APSS_CPUCP_TX_MBOX_IDR 0
+#define APSS_CPUCP_TX_MBOX_CMD 0x100
+
+/* Rx Registers */
+#define APSS_CPUCP_RX_MBOX_IDR 0
+#define APSS_CPUCP_RX_MBOX_CMD 0x100
+#define APSS_CPUCP_RX_MBOX_MAP 0x4000
+#define APSS_CPUCP_RX_MBOX_STAT 0x4400
+#define APSS_CPUCP_RX_MBOX_CLEAR 0x4800
+#define APSS_CPUCP_RX_MBOX_EN 0x4C00
+#define APSS_CPUCP_RX_MBOX_CMD_MASK 0xFFFFFFFFFFFFFFFF
+
+/**
+ * struct qcom_cpucp_mbox - Holder for the mailbox driver
+ * @chans: The mailbox channel
+ * @mbox: The mailbox controller
+ * @tx_base: Base address of the CPUCP tx registers
+ * @rx_base: Base address of the CPUCP rx registers
+ * @dev: Device associated with this instance
+ * @irq: CPUCP to AP irq
+ */
+struct qcom_cpucp_mbox {
+ struct mbox_chan chans[APSS_CPUCP_IPC_CHAN_SUPPORTED];
+ struct mbox_controller mbox;
+ void __iomem *tx_base;
+ void __iomem *rx_base;
+ struct device *dev;
+ int irq;
+};
+
+static inline int channel_number(struct mbox_chan *chan)
+{
+ return chan - chan->mbox->chans;
+}
+
+static irqreturn_t qcom_cpucp_mbox_irq_fn(int irq, void *data)
+{
+ struct qcom_cpucp_mbox *cpucp = data;
+ struct mbox_chan *chan;
+ unsigned long flags;
+ u64 status;
+ u32 val;
+ int i;
+
+ status = readq(cpucp->rx_base + APSS_CPUCP_RX_MBOX_STAT);
+
+ for (i = 0; i < APSS_CPUCP_IPC_CHAN_SUPPORTED; i++) {
+ val = 0;
+ if (status & ((u64)1 << i)) {
+ val = readl(cpucp->rx_base + APSS_CPUCP_RX_MBOX_CMD + (i * 8) + APSS_CPUCP_MBOX_CMD_OFF);
+ chan = &cpucp->chans[i];
+ spin_lock_irqsave(&chan->lock, flags);
+ if (chan->cl)
+ mbox_chan_received_data(chan, &val);
+ spin_unlock_irqrestore(&chan->lock, flags);
+ writeq(status, cpucp->rx_base + APSS_CPUCP_RX_MBOX_CLEAR);
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int qcom_cpucp_mbox_startup(struct mbox_chan *chan)
+{
+ struct qcom_cpucp_mbox *cpucp = container_of(chan->mbox, struct qcom_cpucp_mbox, mbox);
+ unsigned long chan_id = channel_number(chan);
+ u64 val;
+
+ val = readq(cpucp->rx_base + APSS_CPUCP_RX_MBOX_EN);
+ val |= BIT(chan_id);
+ writeq(val, cpucp->rx_base + APSS_CPUCP_RX_MBOX_EN);
+
+ return 0;
+}
+
+static void qcom_cpucp_mbox_shutdown(struct mbox_chan *chan)
+{
+ struct qcom_cpucp_mbox *cpucp = container_of(chan->mbox, struct qcom_cpucp_mbox, mbox);
+ unsigned long chan_id = channel_number(chan);
+ u64 val;
+
+ val = readq(cpucp->rx_base + APSS_CPUCP_RX_MBOX_EN);
+ val &= ~BIT(chan_id);
+ writeq(val, cpucp->rx_base + APSS_CPUCP_RX_MBOX_EN);
+}
+
+static int qcom_cpucp_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct qcom_cpucp_mbox *cpucp = container_of(chan->mbox, struct qcom_cpucp_mbox, mbox);
+ unsigned long chan_id = channel_number(chan);
+ u32 *val = data;
+
+ writel(*val, cpucp->tx_base + APSS_CPUCP_TX_MBOX_CMD + (chan_id * 8) + APSS_CPUCP_MBOX_CMD_OFF);
+
+ return 0;
+}
+
+static const struct mbox_chan_ops qcom_cpucp_mbox_chan_ops = {
+ .startup = qcom_cpucp_mbox_startup,
+ .send_data = qcom_cpucp_mbox_send_data,
+ .shutdown = qcom_cpucp_mbox_shutdown
+};
+
+static int qcom_cpucp_mbox_probe(struct platform_device *pdev)
+{
+ struct qcom_cpucp_mbox *cpucp;
+ struct mbox_controller *mbox;
+ int ret;
+
+ cpucp = devm_kzalloc(&pdev->dev, sizeof(*cpucp), GFP_KERNEL);
+ if (!cpucp)
+ return -ENOMEM;
+
+ cpucp->dev = &pdev->dev;
+
+ cpucp->rx_base = devm_of_iomap(cpucp->dev, cpucp->dev->of_node, 0, NULL);
+ if (IS_ERR(cpucp->rx_base))
+ return PTR_ERR(cpucp->rx_base);
+
+ cpucp->tx_base = devm_of_iomap(cpucp->dev, cpucp->dev->of_node, 1, NULL);
+ if (IS_ERR(cpucp->tx_base))
+ return PTR_ERR(cpucp->tx_base);
+
+ writeq(0, cpucp->rx_base + APSS_CPUCP_RX_MBOX_EN);
+ writeq(0, cpucp->rx_base + APSS_CPUCP_RX_MBOX_CLEAR);
+ writeq(0, cpucp->rx_base + APSS_CPUCP_RX_MBOX_MAP);
+
+ cpucp->irq = platform_get_irq(pdev, 0);
+ if (cpucp->irq < 0) {
+ dev_err(&pdev->dev, "Failed to get the IRQ\n");
+ return cpucp->irq;
+ }
+
+ ret = devm_request_irq(&pdev->dev, cpucp->irq, qcom_cpucp_mbox_irq_fn,
+ IRQF_TRIGGER_HIGH, "apss_cpucp_mbox", cpucp);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to register the irq: %d\n", ret);
+ return ret;
+ }
+
+ writeq(APSS_CPUCP_RX_MBOX_CMD_MASK, cpucp->rx_base + APSS_CPUCP_RX_MBOX_MAP);
+
+ mbox = &cpucp->mbox;
+ mbox->dev = cpucp->dev;
+ mbox->num_chans = APSS_CPUCP_IPC_CHAN_SUPPORTED;
+ mbox->chans = cpucp->chans;
+ mbox->ops = &qcom_cpucp_mbox_chan_ops;
+ mbox->txdone_irq = false;
+ mbox->txdone_poll = false;
+
+ ret = mbox_controller_register(mbox);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to create mailbox\n");
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, cpucp);
+
+ return 0;
+}
+
+static int qcom_cpucp_mbox_remove(struct platform_device *pdev)
+{
+ struct qcom_cpucp_mbox *cpucp = platform_get_drvdata(pdev);
+
+ mbox_controller_unregister(&cpucp->mbox);
+
+ return 0;
+}
+
+static const struct of_device_id qcom_cpucp_mbox_of_match[] = {
+ { .compatible = "qcom,x1e80100-cpucp-mbox"},
+ {}
+};
+MODULE_DEVICE_TABLE(of, qcom_cpucp_mbox_of_match);
+
+static struct platform_driver qcom_cpucp_mbox_driver = {
+ .probe = qcom_cpucp_mbox_probe,
+ .remove = qcom_cpucp_mbox_remove,
+ .driver = {
+ .name = "qcom_cpucp_mbox",
+ .of_match_table = qcom_cpucp_mbox_of_match,
+ .suppress_bind_attrs = true,
+ },
+};
+module_platform_driver(qcom_cpucp_mbox_driver);
+
+MODULE_DESCRIPTION("QTI CPUCP MBOX Driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: qcom: x1e80100: Add cpucp mailbox and sram nodes
From: Sibi Sankar @ 2024-03-28 9:50 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt
Cc: linux-kernel, linux-arm-msm, devicetree, quic_rgottimu,
quic_kshivnan, quic_sibis, conor+dt, quic_gkohli, quic_nkela,
quic_psodagud
In-Reply-To: <20240328095044.2926125-1-quic_sibis@quicinc.com>
Add the cpucp mailbox and sram nodes required by SCMI perf protocol
on X1E80100 SoCs.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 28f65296781d..4e0ec859ed61 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -4974,6 +4974,13 @@ gic_its: msi-controller@17040000 {
};
};
+ cpucp_mbox: mailbox@17430000 {
+ compatible = "qcom,x1e80100-cpucp-mbox";
+ reg = <0 0x17430000 0 0x10000>, <0 0x18830000 0 0x10000>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
+
apps_rsc: rsc@17500000 {
compatible = "qcom,rpmh-rsc";
reg = <0 0x17500000 0 0x10000>,
@@ -5157,6 +5164,25 @@ frame@1780d000 {
};
};
+ sram: sram@18b4e000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x18b4e000 0x0 0x400>;
+ ranges = <0x0 0x0 0x18b4e000 0x400>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpu_scp_lpri0: scmi-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+ };
+
+ cpu_scp_lpri1: scmi-shmem@200 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x200 0x200>;
+ };
+ };
+
system-cache-controller@25000000 {
compatible = "qcom,x1e80100-llcc";
reg = <0 0x25000000 0 0x200000>,
--
2.34.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: qcom: x1e80100: Enable cpufreq
From: Sibi Sankar @ 2024-03-28 9:50 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt
Cc: linux-kernel, linux-arm-msm, devicetree, quic_rgottimu,
quic_kshivnan, quic_sibis, conor+dt, quic_gkohli, quic_nkela,
quic_psodagud
In-Reply-To: <20240328095044.2926125-1-quic_sibis@quicinc.com>
Enable cpufreq on X1E80100 SoCs through the SCMI perf protocol node.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 27 ++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 4e0ec859ed61..d1d232cd1f25 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -68,6 +68,7 @@ CPU0: cpu@0 {
compatible = "qcom,oryon";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
next-level-cache = <&L2_0>;
power-domains = <&CPU_PD0>;
power-domain-names = "psci";
@@ -85,6 +86,7 @@ CPU1: cpu@100 {
compatible = "qcom,oryon";
reg = <0x0 0x100>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
next-level-cache = <&L2_0>;
power-domains = <&CPU_PD1>;
power-domain-names = "psci";
@@ -96,6 +98,7 @@ CPU2: cpu@200 {
compatible = "qcom,oryon";
reg = <0x0 0x200>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
next-level-cache = <&L2_0>;
power-domains = <&CPU_PD2>;
power-domain-names = "psci";
@@ -107,6 +110,7 @@ CPU3: cpu@300 {
compatible = "qcom,oryon";
reg = <0x0 0x300>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
next-level-cache = <&L2_0>;
power-domains = <&CPU_PD3>;
power-domain-names = "psci";
@@ -118,6 +122,7 @@ CPU4: cpu@10000 {
compatible = "qcom,oryon";
reg = <0x0 0x10000>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 1>;
next-level-cache = <&L2_1>;
power-domains = <&CPU_PD4>;
power-domain-names = "psci";
@@ -135,6 +140,7 @@ CPU5: cpu@10100 {
compatible = "qcom,oryon";
reg = <0x0 0x10100>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 1>;
next-level-cache = <&L2_1>;
power-domains = <&CPU_PD5>;
power-domain-names = "psci";
@@ -146,6 +152,7 @@ CPU6: cpu@10200 {
compatible = "qcom,oryon";
reg = <0x0 0x10200>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 1>;
next-level-cache = <&L2_1>;
power-domains = <&CPU_PD6>;
power-domain-names = "psci";
@@ -157,6 +164,7 @@ CPU7: cpu@10300 {
compatible = "qcom,oryon";
reg = <0x0 0x10300>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 1>;
next-level-cache = <&L2_1>;
power-domains = <&CPU_PD7>;
power-domain-names = "psci";
@@ -168,6 +176,7 @@ CPU8: cpu@20000 {
compatible = "qcom,oryon";
reg = <0x0 0x20000>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 2>;
next-level-cache = <&L2_2>;
power-domains = <&CPU_PD8>;
power-domain-names = "psci";
@@ -185,6 +194,7 @@ CPU9: cpu@20100 {
compatible = "qcom,oryon";
reg = <0x0 0x20100>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 2>;
next-level-cache = <&L2_2>;
power-domains = <&CPU_PD9>;
power-domain-names = "psci";
@@ -196,6 +206,7 @@ CPU10: cpu@20200 {
compatible = "qcom,oryon";
reg = <0x0 0x20200>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 2>;
next-level-cache = <&L2_2>;
power-domains = <&CPU_PD10>;
power-domain-names = "psci";
@@ -207,6 +218,7 @@ CPU11: cpu@20300 {
compatible = "qcom,oryon";
reg = <0x0 0x20300>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 2>;
next-level-cache = <&L2_2>;
power-domains = <&CPU_PD11>;
power-domain-names = "psci";
@@ -309,6 +321,21 @@ scm: scm {
interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
};
+
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&cpucp_mbox 0>, <&cpucp_mbox 2>;
+ mbox-names = "tx", "rx";
+ shmem = <&cpu_scp_lpri0>, <&cpu_scp_lpri1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ scmi_dvfs: protocol@13 {
+ reg = <0x13>;
+ #clock-cells = <1>;
+ };
+ };
};
clk_virt: interconnect-0 {
--
2.34.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region
From: Sibi Sankar @ 2024-03-28 9:50 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt
Cc: linux-kernel, linux-arm-msm, devicetree, quic_rgottimu,
quic_kshivnan, quic_sibis, conor+dt, quic_gkohli, quic_nkela,
quic_psodagud
In-Reply-To: <20240328095044.2926125-1-quic_sibis@quicinc.com>
Resize the GICR register region as it currently seeps into the CPU Control
Processor mailbox RX region.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index f5a3b39ae70e..28f65296781d 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -4949,7 +4949,7 @@ apps_smmu: iommu@15000000 {
intc: interrupt-controller@17000000 {
compatible = "arm,gic-v3";
reg = <0 0x17000000 0 0x10000>, /* GICD */
- <0 0x17080000 0 0x480000>; /* GICR * 12 */
+ <0 0x17080000 0 0x380000>; /* GICR * 12 */
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
--
2.34.1
^ permalink raw reply related
* [PATCH v16 04/22] PCI: microchip: Add bridge_addr field to struct mc_pcie
From: Minda Chen @ 2024-03-28 9:18 UTC (permalink / raw)
To: Lorenzo Pieralisi, Conor Dooley, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Thomas Gleixner, Daire McNamara,
Emil Renner Berthing, Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-riscv, linux-pci, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Philipp Zabel, Mason Huo, Leyfoon Tan,
Kevin Xie, Minda Chen
In-Reply-To: <20240328091835.14797-1-minda.chen@starfivetech.com>
Bridge address base is common PLDA field, add this to struct mc_pcie
first.
INTx and MSI interrupt code will be changed to common code, so get
the bridge base address from port->bridge_addr instead of
axi_base_addr. axi_base_addr is Microchip its own data.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
.../pci/controller/plda/pcie-microchip-host.c | 23 ++++++++-----------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/controller/plda/pcie-microchip-host.c b/drivers/pci/controller/plda/pcie-microchip-host.c
index d9030d550482..c55ede80a6d0 100644
--- a/drivers/pci/controller/plda/pcie-microchip-host.c
+++ b/drivers/pci/controller/plda/pcie-microchip-host.c
@@ -195,6 +195,7 @@ struct mc_pcie {
struct irq_domain *event_domain;
raw_spinlock_t lock;
struct mc_msi msi;
+ void __iomem *bridge_addr;
};
struct cause {
@@ -339,8 +340,7 @@ static void mc_handle_msi(struct irq_desc *desc)
struct irq_chip *chip = irq_desc_get_chip(desc);
struct device *dev = port->dev;
struct mc_msi *msi = &port->msi;
- void __iomem *bridge_base_addr =
- port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ void __iomem *bridge_base_addr = port->bridge_addr;
unsigned long status;
u32 bit;
int ret;
@@ -365,8 +365,7 @@ static void mc_handle_msi(struct irq_desc *desc)
static void mc_msi_bottom_irq_ack(struct irq_data *data)
{
struct mc_pcie *port = irq_data_get_irq_chip_data(data);
- void __iomem *bridge_base_addr =
- port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ void __iomem *bridge_base_addr = port->bridge_addr;
u32 bitpos = data->hwirq;
writel_relaxed(BIT(bitpos), bridge_base_addr + ISTATUS_MSI);
@@ -488,8 +487,7 @@ static void mc_handle_intx(struct irq_desc *desc)
struct mc_pcie *port = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
struct device *dev = port->dev;
- void __iomem *bridge_base_addr =
- port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ void __iomem *bridge_base_addr = port->bridge_addr;
unsigned long status;
u32 bit;
int ret;
@@ -514,8 +512,7 @@ static void mc_handle_intx(struct irq_desc *desc)
static void mc_ack_intx_irq(struct irq_data *data)
{
struct mc_pcie *port = irq_data_get_irq_chip_data(data);
- void __iomem *bridge_base_addr =
- port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ void __iomem *bridge_base_addr = port->bridge_addr;
u32 mask = BIT(data->hwirq + PM_MSI_INT_INTX_SHIFT);
writel_relaxed(mask, bridge_base_addr + ISTATUS_LOCAL);
@@ -524,8 +521,7 @@ static void mc_ack_intx_irq(struct irq_data *data)
static void mc_mask_intx_irq(struct irq_data *data)
{
struct mc_pcie *port = irq_data_get_irq_chip_data(data);
- void __iomem *bridge_base_addr =
- port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ void __iomem *bridge_base_addr = port->bridge_addr;
unsigned long flags;
u32 mask = BIT(data->hwirq + PM_MSI_INT_INTX_SHIFT);
u32 val;
@@ -540,8 +536,7 @@ static void mc_mask_intx_irq(struct irq_data *data)
static void mc_unmask_intx_irq(struct irq_data *data)
{
struct mc_pcie *port = irq_data_get_irq_chip_data(data);
- void __iomem *bridge_base_addr =
- port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ void __iomem *bridge_base_addr = port->bridge_addr;
unsigned long flags;
u32 mask = BIT(data->hwirq + PM_MSI_INT_INTX_SHIFT);
u32 val;
@@ -896,8 +891,7 @@ static void mc_pcie_setup_window(void __iomem *bridge_base_addr, u32 index,
static int mc_pcie_setup_windows(struct platform_device *pdev,
struct mc_pcie *port)
{
- void __iomem *bridge_base_addr =
- port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ void __iomem *bridge_base_addr = port->bridge_addr;
struct pci_host_bridge *bridge = platform_get_drvdata(pdev);
struct resource_entry *entry;
u64 pci_addr;
@@ -1081,6 +1075,7 @@ static int mc_host_probe(struct platform_device *pdev)
mc_disable_interrupts(port);
bridge_base_addr = port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
+ port->bridge_addr = bridge_base_addr;
/* Allow enabling MSI by disabling MSI-X */
val = readl(bridge_base_addr + PCIE_PCI_IRQ_DW0);
--
2.17.1
^ permalink raw reply related
* [GIT PULL] Immutable branch between MFD and Regulator due for the v6.9 merge window:wq
From: Lee Jones @ 2024-03-28 9:56 UTC (permalink / raw)
To: Andre Przywara
Cc: Liam Girdwood, Mark Brown, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, Samuel Holland,
Jernej Skrabec, Chris Morgan, linux-kernel, linux-sunxi
In-Reply-To: <20240310010211.28653-1-andre.przywara@arm.com>
Enjoy!
The following changes since commit 4cece764965020c22cff7665b18a012006359095:
Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-regulator-v6.9
for you to fetch changes up to d2ac3df75c3a995064cfac0171e082a30d8c4c66:
regulator: axp20x: add support for the AXP717 (2024-03-28 09:51:03 +0000)
----------------------------------------------------------------
Immutable branch between MFD and Regulator due for the v6.9 merge window
----------------------------------------------------------------
Andre Przywara (4):
regulator: axp20x: fix typo-ed identifier
dt-bindings: mfd: x-powers,axp152: Document AXP717
mfd: axp20x: Add support for AXP717 PMIC
regulator: axp20x: add support for the AXP717
.../devicetree/bindings/mfd/x-powers,axp152.yaml | 2 +
drivers/mfd/axp20x-i2c.c | 2 +
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 90 ++++++++++++++++++++
drivers/regulator/axp20x-regulator.c | 94 +++++++++++++++++++--
include/linux/mfd/axp20x.h | 98 ++++++++++++++++++++--
6 files changed, 277 insertions(+), 10 deletions(-)
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 0/5] arm64: dts: exynos: gs101: define all PERIC USI nodes
From: Krzysztof Kozlowski @ 2024-03-28 9:58 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, conor+dt,
Tudor Ambarus
Cc: alim.akhtar, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, andre.draszik, willmcvicker, kernel-team
In-Reply-To: <20240326151301.348932-1-tudor.ambarus@linaro.org>
On Tue, 26 Mar 2024 15:12:56 +0000, Tudor Ambarus wrote:
> The series starts with some trivial cosmetics patches, then defines all
> the PERIC USI nodes.
>
> v3:
> - seems that Andre' already reordered the pinctrl properties, take his
> patch (first in the series) and rebase my series on top.
> - small updates on commit messages
> - collect R-b tags
>
> [...]
Applied, thanks!
[1/5] arm64: dts: exynos: gs101: reorder pinctrl-* properties
https://git.kernel.org/krzk/linux/c/7d7df014617ba8df7fbdacac54cafe0d13573dcb
[2/5] arm64: dts: exynos: gs101: move serial_0 pinctrl-0/names to dtsi
https://git.kernel.org/krzk/linux/c/73618dfa705dc8f993a6829c895eaf5af8402ceb
[3/5] arm64: dts: exynos: gs101: move pinctrl-* properties after clocks
https://git.kernel.org/krzk/linux/c/d978c70e8d4775c62db21f85947d12b4f874104a
[4/5] arm64: dts: exynos: gs101: join lines close to 80 chars
https://git.kernel.org/krzk/linux/c/028a87e91fcd8c485afcf8bd0d26ae34a0872438
[5/5] arm64: dts: exynos: gs101: define all PERIC USI nodes
https://git.kernel.org/krzk/linux/c/a45c3a9b1ef9571741d40bf10f22ce3c60bc5111
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
^ permalink raw reply
* Re: [PATCH v4 2/3] clk: qcom: add IPQ9574 interconnect clocks support
From: Varadarajan Narayanan @ 2024-03-28 10:00 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, djakov, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <CAA8EJpoFw3Qyq+NRffe5HBUbCfdYv03oWgoUwkB6pbdVrF6LEg@mail.gmail.com>
On Wed, Mar 27, 2024 at 10:49:56AM +0200, Dmitry Baryshkov wrote:
> On Wed, 27 Mar 2024 at 10:21, Varadarajan Narayanan
> <quic_varada@quicinc.com> wrote:
> >
> > 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>
> > ---
> > 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/Kconfig | 2 ++
> > drivers/clk/qcom/common.c | 34 ++++++++++++++++++++-
> > drivers/clk/qcom/common.h | 4 ++-
> > drivers/clk/qcom/gcc-ipq9574.c | 54 ++++++++++++++++++++++++++++++++++
Have addressed the comments and posted v5.
Kindly review.
Thanks
Varada
^ permalink raw reply
* Re: [PATCH v6 3/5] crypto: tegra: Add Tegra Security Engine driver
From: Herbert Xu @ 2024-03-28 10:05 UTC (permalink / raw)
To: Akhil R
Cc: davem, robh, krzysztof.kozlowski+dt, conor+dt, thierry.reding,
jonathanh, catalin.marinas, will, mperttunen, airlied, daniel,
linux-crypto, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, dri-devel
In-Reply-To: <20240319082306.34716-4-akhilrajeev@nvidia.com>
On Tue, Mar 19, 2024 at 01:53:04PM +0530, Akhil R wrote:
>
> + .alg.skcipher.op.do_one_request = tegra_aes_do_one_req,
> + .alg.skcipher.base = {
> + .init = tegra_aes_cra_init,
> + .exit = tegra_aes_cra_exit,
> + .setkey = tegra_aes_setkey,
> + .encrypt = tegra_aes_encrypt,
> + .decrypt = tegra_aes_decrypt,
> + .min_keysize = AES_MIN_KEY_SIZE,
> + .max_keysize = AES_MAX_KEY_SIZE,
> + .ivsize = AES_BLOCK_SIZE,
> + .base = {
> + .cra_name = "ofb(aes)",
> + .cra_driver_name = "ofb-aes-tegra",
> + .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER | CRYPTO_ALG_ASYNC,
> + .cra_blocksize = AES_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct tegra_aes_ctx),
> + .cra_alignmask = 0xf,
> + .cra_module = THIS_MODULE,
> + },
> + }
> + }, {
OFB no longer exists in the kernel. Please remove all traces of it
from your driver.
Also please ensure that yuor driver passes the extra fuzz tests.
Thanks,
--
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
^ permalink raw reply
* Re: [PATCH 00/18] Add audio support for the MediaTek Genio 350-evk board
From: Alexandre Mergnat @ 2024-03-28 10:09 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-sound, devicetree, Lee Jones, Mark Brown, Liam Girdwood,
Matthias Brugger, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
linux-kernel, Catalin Marinas, Christian König,
linux-arm-kernel, Takashi Iwai, Jaroslav Kysela, Flora Fu,
linux-mediatek, linux-media, dri-devel, linaro-mm-sig,
Nicolas Belin, Fabien Parent, Sumit Semwal, Will Deacon
In-Reply-To: <53671deb-9c11-43c1-8deb-93fe4708651a@collabora.com>
Hi Angelo
On 26/02/2024 15:54, AngeloGioacchino Del Regno wrote:
> Il 26/02/24 15:01, Alexandre Mergnat ha scritto:
>> This serie aim to add the following audio support for the Genio 350-evk:
>> - Playback
>> - 2ch Headset Jack (Earphone)
>> - 1ch Line-out Jack (Speaker)
>> - 8ch HDMI Tx
>> - Capture
>> - 1ch DMIC (On-board Digital Microphone)
>> - 1ch AMIC (On-board Analogic Microphone)
>> - 1ch Headset Jack (External Analogic Microphone)
>>
>> Of course, HDMI playback need the MT8365 display patches [1] and a DTS
>> change documented in "mediatek,mt8365-mt6357.yaml".
>>
>> [1]:
>> https://lore.kernel.org/all/20231023-display-support-v1-0-5c860ed5c33b@baylibre.com/
>>
>> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
>
> Actually, I am cooking a series (I'm finishing the testing....) that
> brings quite
> a bit of cleanups in MTK ASoC, including the commonization of the
> machine driver
> probe, with the dai-link DT nodes, and which also modernizes most of the
> existing
> drivers to use that instead.
>
> If you wait for a day or two, your mt8365-mt6357.c driver's probe
> function can be
> shrunk to ~3 lines or something like that.. very easily :-)
Just to inform you. I'm aware of your serie. Currently, I've fixed my
patches according to the comments. The next step will be to rebase my
serie over yours and do the changes to be aligned with your new
implementation.
I've planned to review your serie during my last task, but it seems
already approved and already (partially) merged into linux-next, sorry.
--
Regards,
Alexandre
^ permalink raw reply
* Re: [PATCH v5 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Lothar Rubusch @ 2024-03-28 9:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <9ab1fc70-fd01-437b-9020-49618924ab30@linaro.org>
On Thu, Mar 28, 2024 at 10:22 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 27/03/2024 23:03, Lothar Rubusch wrote:
> > Add spi-3wire because the device allows to be configured for spi 3-wire
> > communication.
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
>
> I don't understand why after my last message you still ignore my
> feedback, but fine. I'll ignore this patchset.
This is sad. I refrased the comment to the patch and tried to stress
more on the device instead of the driver. Wasn't this the point of
your criticism to the patch?
So, instead of answering to your last email, I posted the modified
patch as answer. I think I considered your feedback to the best of my
understanding. I'm sorry, it is certainly not my intention to ignore
you. I appreciate your direct feedback.
I'll write an answer to the last email right away.
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v6 3/5] crypto: tegra: Add Tegra Security Engine driver
From: Herbert Xu @ 2024-03-28 10:13 UTC (permalink / raw)
To: Akhil R
Cc: davem, robh, krzysztof.kozlowski+dt, conor+dt, thierry.reding,
jonathanh, catalin.marinas, will, mperttunen, airlied, daniel,
linux-crypto, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, dri-devel
In-Reply-To: <20240319082306.34716-4-akhilrajeev@nvidia.com>
On Tue, Mar 19, 2024 at 01:53:04PM +0530, Akhil R wrote:
>
> +struct tegra_sha_reqctx {
> + struct ahash_request fallback_req;
This doesn't work because ahash_request is dynamically sized.
So you'll end up clobbering the rest of the struct if a fallback
ends up being used.
You should place the fallback_req at the end of the reqctx and set
the reqsize based on the fallback reqsize.
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
^ permalink raw reply
* Re: [PATCH 17/23] dt-bindings: media: imx258: Rename to include vendor prefix
From: Conor Dooley @ 2024-03-28 10:15 UTC (permalink / raw)
To: Kieran Bingham
Cc: Conor Dooley, git, linux-media, 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: <171161592126.3072637.14564447281929105708@ping.linuxembedded.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]
On Thu, Mar 28, 2024 at 08:52:01AM +0000, Kieran Bingham wrote:
> Quoting git@luigi311.com (2024-03-28 00:57:34)
> > On 3/27/24 17:47, Conor Dooley wrote:
> > > On Wed, Mar 27, 2024 at 05:17:03PM -0600, git@luigi311.com wrote:
> > >> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > >>
> > >> imx258.yaml doesn't include the vendor prefix of sony, so
> > >> rename to add it.
> > >> Update the id entry and MAINTAINERS to match.
> > >>
> > >> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > >> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > This is a v1 with my ack, something has gone awry here. It's also
> > > missing your signoff. Did you pick up someone else's series?
> >
> > Yes, this is a continuation of Dave's work. I contacted him directly,
> > and he mentioned that he is unable to submit a v2 any time soon and
> > was open to someone else continuing it in his stead.
Ah okay. Unfortunately I see so many binding patches pass by that I
sometimes forget about what I already reviewed, and I did not
remember this one at all.
> > This is my first
> > time submitting a patch via a mailing list, so I'm not sure if I'm
> > missing something, but I only added my sign off for anything that
> > actually included work from my side and not just bringing his patch
> > forward to this patch series.
Right. The rules are that you need to add it when you send someone's
work, like chain of custody type of thing.
> Your cover letter states v2, but the individual patches do not.
>
> Add the '-v2' (or, rather, next it will be '-v3') to git format-patch
> when you save your series and it will add the version to each patch. You
> can also add '-s' to that command I believe to add your SoB to each
> patch.
or a rebase will do it with --signoff:
https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---signoff
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 09/11] regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators
From: Bhargav Raviprakash @ 2024-03-28 10:16 UTC (permalink / raw)
To: broonie
Cc: arnd, bhargav.r, conor+dt, devicetree, eblanc, gregkh, jpanis,
kristo, krzysztof.kozlowski+dt, lee, lgirdwood, linus.walleij,
linux-arm-kernel, linux-gpio, linux-kernel, m.nirmaladevi, nm,
robh+dt, vigneshr
In-Reply-To: <a3ec3c14-eed3-429d-b3f6-0764bcfb8dc4@sirena.org.uk>
Hi,
On Wed, 20 Mar 2024 16:38:20 +0000, Mark Brown wrote:
> On Wed, Mar 20, 2024 at 03:55:57PM +0530, Bhargav Raviprakash wrote:
>
> > +static struct tps6594_regulator_irq_type tps65224_buck1_irq_types[] = {
> > + { TPS65224_IRQ_NAME_BUCK1_UVOV, "BUCK1", "voltage out of range",
> > + REGULATOR_EVENT_OVER_VOLTAGE_WARN },
> > +};
>
> These all look like they should be _REGULATION_OUT given that the
> interrupt names are _UVOV which look like they could be either under or
> over voltage.
>
> Otherwise this all looks good.
Thanks for the feedback! We will fix it in the next version.
Regards,
Bhargav
^ permalink raw reply
* Re: [PATCH v5 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Lothar Rubusch @ 2024-03-28 10:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <9ab1fc70-fd01-437b-9020-49618924ab30@linaro.org>
On Thu, Mar 28, 2024 at 10:22 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 27/03/2024 23:03, Lothar Rubusch wrote:
> > Add spi-3wire because the device allows to be configured for spi 3-wire
> > communication.
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
>
> I don't understand why after my last message you still ignore my
> feedback, but fine. I'll ignore this patchset.
>
I'm sorry. I found it now. Please ignore my last v5. I'll repatch an
adjusted v6.
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: starfive: add Milkv Mars board device tree
From: Jisheng Zhang @ 2024-03-28 10:08 UTC (permalink / raw)
To: Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Emil Renner Berthing, linux-riscv, devicetree,
linux-kernel
In-Reply-To: <20240327-cotton-fang-37f6d8fde0e5@spud>
On Wed, Mar 27, 2024 at 06:06:58PM +0000, Conor Dooley wrote:
> Yo,
>
> On Tue, Feb 06, 2024 at 07:13:48PM +0000, Conor Dooley wrote:
> > On Wed, Jan 31, 2024 at 09:26:00PM +0800, Jisheng Zhang wrote:
> > > The Milkv Mars is a development board based on the Starfive JH7110 SoC.
> > > The board features:
> > >
> > > - JH7110 SoC
> > > - 1/2/4/8 GiB LPDDR4 DRAM
> > > - AXP15060 PMIC
> > > - 40 pin GPIO header
> > > - 3x USB 3.0 host port
> > > - 1x USB 2.0 host port
> > > - 1x M.2 E-Key
> > > - 1x eMMC slot
> > > - 1x MicroSD slot
> > > - 1x QSPI Flash
> > > - 1x 1Gbps Ethernet port
> > > - 1x HDMI port
> > > - 1x 2-lane DSI and 1x 4-lane DSI
> > > - 1x 2-lane CSI
> > >
> > > Add the devicetree file describing the currently supported features,
> > > namely PMIC, UART, I2C, GPIO, SD card, QSPI Flash, eMMC and Ethernet.
> > >
> > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> >
> > Got a dtbs_check issue in the patchwork CI:
> >
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rgmii-rxin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rmii-refin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> >
> > Can you fix that please? Also, I applied some patches the other day that
> > seem to conflict quite a bit with the common board dts patch. Would you
> > please do a rebase on top of that please?
>
> Been going through stuff on my todo list now that the merge window is
> closed. Could you please resend this with the rebase done?
Thanks for the reminding, I will rebase on 6.9-rc1 then send out the
patches.
>
> Thanks,
> Conor.
^ permalink raw reply
* [PATCH 2/4] drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
In-Reply-To: <20240328102746.17868-1-marex@denx.de>
The .bpc = 6 implies .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ,
add the missing bus_format. Add missing connector type and bus_flags
as well.
Documentation [1] 1.4 GENERAL SPECIFICATI0NS indicates this panel is
capable of both RGB 18bit/24bit panel, the current configuration uses
18bit mode, .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , .bpc = 6.
Support for the 24bit mode would require another entry in panel-simple
with .bus_format = MEDIA_BUS_FMT_RGB666_1X7X4_SPWG and .bpc = 8, which
is out of scope of this fix.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
Fixes: f8fa17ba812b ("drm/panel: simple: Add support for Innolux G121X1-L03")
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index d9ddef0e675a7..d4c30a86d15d6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2618,6 +2618,9 @@ static const struct panel_desc innolux_g121x1_l03 = {
.unprepare = 200,
.disable = 400,
},
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
};
static const struct display_timing innolux_g156hce_l01_timings = {
--
2.43.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: display: simple: Document support for Innolux G121XCE-L01
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
Document support for Innolux CheMei 12" G121XCE-L01 XGA LVDS display.
G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 4:3, 1024(H) x 768(V) screen and either
262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit.
All input signals are LVDS interface compatible.
Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are
effectively identical panels, use the former as RGB 6-bits variant and
document the later as RGB 8-bits variant.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
[2] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdf
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index e0f6aa9a025c4..931d98836e121 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -190,6 +190,8 @@ properties:
- innolux,g121i1-l01
# Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
- innolux,g121x1-l03
+ # Innolux Corporation 12.1" G121XCE-L01 XGA (1024x768) TFT LCD panel
+ - innolux,g121xce-l01
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bca-ea1
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] drm/panel: simple: Convert Innolux G121X1-L03 to display_timing
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
In-Reply-To: <20240328102746.17868-1-marex@denx.de>
Use display_timing instead of drm_display_mode to define a range of
possible display timings supported by this panel. This makes the panel
support more flexible and improves compatibility. No functional change
is expected.
The settings are picked from documentation [1] section 6.1 INPUT SIGNAL
TIMING SPECIFICATIONS.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index d4c30a86d15d6..737c78b3b8a23 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2592,22 +2592,22 @@ static const struct panel_desc innolux_g121i1_l01 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
-static const struct drm_display_mode innolux_g121x1_l03_mode = {
- .clock = 65000,
- .hdisplay = 1024,
- .hsync_start = 1024 + 0,
- .hsync_end = 1024 + 1,
- .htotal = 1024 + 0 + 1 + 320,
- .vdisplay = 768,
- .vsync_start = 768 + 38,
- .vsync_end = 768 + 38 + 1,
- .vtotal = 768 + 38 + 1 + 0,
- .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+static const struct display_timing innolux_g121x1_l03_timings = {
+ .pixelclock = { 57500000, 64900000, 74400000 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 90, 140, 190 },
+ .hback_porch = { 90, 140, 190 },
+ .hsync_len = { 36, 40, 60 },
+ .vactive = { 768, 768, 768 },
+ .vfront_porch = { 2, 15, 30 },
+ .vback_porch = { 2, 15, 30 },
+ .vsync_len = { 2, 8, 20 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
};
static const struct panel_desc innolux_g121x1_l03 = {
- .modes = &innolux_g121x1_l03_mode,
- .num_modes = 1,
+ .timings = &innolux_g121x1_l03_timings,
+ .num_timings = 1,
.bpc = 6,
.size = {
.width = 246,
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] drm/panel: simple: Add Innolux G121XCE-L01 LVDS display support
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
In-Reply-To: <20240328102746.17868-1-marex@denx.de>
G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 4:3, 1024(H) x 768(V) screen and either
262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit.
All input signals are LVDS interface compatible.
Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are
effectively identical panels, use the former as RGB 6-bits variant and
add the later as RGB 8-bits variant.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
[2] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdf
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 737c78b3b8a23..5acc9f2941909 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2623,6 +2623,24 @@ static const struct panel_desc innolux_g121x1_l03 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct panel_desc innolux_g121xce_l01 = {
+ .timings = &innolux_g121x1_l03_timings,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 246,
+ .height = 185,
+ },
+ .delay = {
+ .enable = 200,
+ .unprepare = 200,
+ .disable = 400,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing innolux_g156hce_l01_timings = {
.pixelclock = { 120000000, 141860000, 150000000 },
.hactive = { 1920, 1920, 1920 },
@@ -4596,6 +4614,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g121x1-l03",
.data = &innolux_g121x1_l03,
+ }, {
+ .compatible = "innolux,g121xce-l01",
+ .data = &innolux_g121xce_l01,
}, {
.compatible = "innolux,g156hce-l01",
.data = &innolux_g156hce_l01,
--
2.43.0
^ 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