* [PATCH v8 3/4] phy: dt-bindings: cdns,dphy: add power-domains property
From: Pratyush Yadav @ 2022-01-21 9:38 UTC (permalink / raw)
To: Vinod Koul
Cc: Pratyush Yadav, Laurent Pinchart, Paul Kocialkowski,
Tomi Valkeinen, Vignesh Raghavendra, Kishon Vijay Abraham I,
Rob Herring, Swapnil Jakhade, devicetree, linux-kernel, linux-phy
In-Reply-To: <20220121093849.3218092-1-p.yadav@ti.com>
This property is needed on TI platforms to enable the PD of the DPHY
before it can be used.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---
(no changes since v3)
Changes in v3:
- Add Rob's Ack.
Changes in v2:
- Add power-domain to the example.
- Add Laurent's R-by.
- Re-order subject prefixes.
Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index b90a58773bf2..c50629bd1b51 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -30,6 +30,9 @@ properties:
"#phy-cells":
const: 0
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -41,11 +44,13 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
dphy0: phy@fd0e0000{
compatible = "cdns,dphy";
reg = <0xfd0e0000 0x1000>;
clocks = <&psm_clk>, <&pll_ref_clk>;
clock-names = "psm", "pll_ref";
+ power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
#phy-cells = <0>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH v8 2/4] phy: dt-bindings: Convert Cadence DPHY binding to YAML
From: Pratyush Yadav @ 2022-01-21 9:38 UTC (permalink / raw)
To: Vinod Koul
Cc: Pratyush Yadav, Laurent Pinchart, Paul Kocialkowski,
Tomi Valkeinen, Vignesh Raghavendra, Kishon Vijay Abraham I,
Rob Herring, Swapnil Jakhade, devicetree, linux-kernel, linux-phy
In-Reply-To: <20220121093849.3218092-1-p.yadav@ti.com>
Convert Cadence DPHY binding to YAML.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
(no changes since v3)
Changes in v3:
- Add Rob's R-by.
Changes in v2:
- Drop reg description.
- Add a description for each DPHY clock.
- Rename dphy@... to phy@... in example.
- Add Laurent's R-by.
- Re-order subject prefixes.
.../devicetree/bindings/phy/cdns,dphy.txt | 20 --------
.../devicetree/bindings/phy/cdns,dphy.yaml | 51 +++++++++++++++++++
2 files changed, 51 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
deleted file mode 100644
index 1095bc4e72d9..000000000000
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Cadence DPHY
-============
-
-Cadence DPHY block.
-
-Required properties:
-- compatible: should be set to "cdns,dphy".
-- reg: physical base address and length of the DPHY registers.
-- clocks: DPHY reference clocks.
-- clock-names: must contain "psm" and "pll_ref".
-- #phy-cells: must be set to 0.
-
-Example:
- dphy0: dphy@fd0e0000{
- compatible = "cdns,dphy";
- reg = <0x0 0xfd0e0000 0x0 0x1000>;
- clocks = <&psm_clk>, <&pll_ref_clk>;
- clock-names = "psm", "pll_ref";
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
new file mode 100644
index 000000000000..b90a58773bf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/cdns,dphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence DPHY Device Tree Bindings
+
+maintainers:
+ - Pratyush Yadav <p.yadav@ti.com>
+
+properties:
+ compatible:
+ items:
+ - const: cdns,dphy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: PMA state machine clock
+ - description: PLL reference clock
+
+ clock-names:
+ items:
+ - const: psm
+ - const: pll_ref
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+
+ dphy0: phy@fd0e0000{
+ compatible = "cdns,dphy";
+ reg = <0xfd0e0000 0x1000>;
+ clocks = <&psm_clk>, <&pll_ref_clk>;
+ clock-names = "psm", "pll_ref";
+ #phy-cells = <0>;
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v8 4/4] phy: dt-bindings: Add Cadence D-PHY Rx bindings
From: Pratyush Yadav @ 2022-01-21 9:38 UTC (permalink / raw)
To: Vinod Koul
Cc: Pratyush Yadav, Laurent Pinchart, Paul Kocialkowski,
Tomi Valkeinen, Vignesh Raghavendra, Kishon Vijay Abraham I,
Rob Herring, Swapnil Jakhade, devicetree, linux-kernel, linux-phy
In-Reply-To: <20220121093849.3218092-1-p.yadav@ti.com>
The Rx mode DPHY is different from Tx mode DPHY. Add a separate binding
for it.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes in v8:
- Add Rob and Laurent's R-by.
Changes in v6:
- Add a new binding for DPHY Rx.
.../devicetree/bindings/phy/cdns,dphy-rx.yaml | 42 +++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml
new file mode 100644
index 000000000000..07be031d82e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/cdns,dphy-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence DPHY Rx Device Tree Bindings
+
+maintainers:
+ - Pratyush Yadav <p.yadav@ti.com>
+
+properties:
+ compatible:
+ items:
+ - const: cdns,dphy-rx
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ dphy0: phy@4580000 {
+ compatible = "cdns,dphy-rx";
+ reg = <0x4580000 0x1100>;
+ #phy-cells = <0>;
+ power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v8 1/4] phy: cadence: Add Cadence D-PHY Rx driver
From: Pratyush Yadav @ 2022-01-21 9:38 UTC (permalink / raw)
To: Vinod Koul
Cc: Pratyush Yadav, Laurent Pinchart, Paul Kocialkowski,
Tomi Valkeinen, Vignesh Raghavendra, Kishon Vijay Abraham I,
Rob Herring, Swapnil Jakhade, devicetree, linux-kernel, linux-phy
In-Reply-To: <20220121093849.3218092-1-p.yadav@ti.com>
The Cadence D-PHY can be configured in Tx (DSI) mode or Rx (CSI) mode.
Both modes have a different programming sequence and share little among
them. In addition, a PHY configured in Tx mode cannot be used in Rx mode
and vice versa. For this reason, create a separate driver for the Rx
mode to make it easier to read and maintain.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes in v8:
- Move lanes check to start of configure sequence.
- Change MODULE_LICENSE() to "GPL".
- Add Laurent's R-by.
Changes in v7:
- Add spaces after { and before } in the bands table.
- Drop the wrapping around the for loop on cdns_dphy_rx_get_band_ctrl().
- Make cdns_dphy_rx_wait_for_bit() inline.
- Print an error message if registering PHY provider fails.
Changes in v6:
- Move to a separate driver.
Changes in v5:
- Use the new cdns_dphy_info to specify PHY ops.
- Re-order include in alphabetical order.
- Make bands const.
- Drop num_bands.
- Make i, lanes unsigned.
- Drop the maximum check in cdns_dphy_rx_get_band_ctrl(). Let the loop
complete and return -EOPNOTSUPP when we reach the end.
- Drop the "rate < bands[i].min_rate" check since the bands are in
ascending order.
- Move data_lane_ctrl to start of function and make it static const.
Changes in v4:
- Drop the submode parts. Use a different compatible for the Rx ops.
- Make bands and num_bands static.
Changes in v3:
- Use a table to select the band.
- Use a table to poll the data lane ready bits.
- Multiply the DPHY HS clock rate by 2 to get the bit rate since the
clock is DDR.
drivers/phy/cadence/Kconfig | 8 +
drivers/phy/cadence/Makefile | 1 +
drivers/phy/cadence/cdns-dphy-rx.c | 255 +++++++++++++++++++++++++++++
3 files changed, 264 insertions(+)
create mode 100644 drivers/phy/cadence/cdns-dphy-rx.c
diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
index a62910ff5591..1adde2d99ae7 100644
--- a/drivers/phy/cadence/Kconfig
+++ b/drivers/phy/cadence/Kconfig
@@ -22,6 +22,14 @@ config PHY_CADENCE_DPHY
system. If M is selected, the module will be called
cdns-dphy.
+config PHY_CADENCE_DPHY_RX
+ tristate "Cadence D-PHY Rx Support"
+ depends on HAS_IOMEM && OF
+ select GENERIC_PHY
+ select GENERIC_PHY_MIPI_DPHY
+ help
+ Support for Cadence D-PHY in Rx configuration.
+
config PHY_CADENCE_SIERRA
tristate "Cadence Sierra PHY Driver"
depends on OF && HAS_IOMEM && RESET_CONTROLLER
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
index 26e16bd34efe..e17f035ddece 100644
--- a/drivers/phy/cadence/Makefile
+++ b/drivers/phy/cadence/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_PHY_CADENCE_TORRENT) += phy-cadence-torrent.o
obj-$(CONFIG_PHY_CADENCE_DPHY) += cdns-dphy.o
+obj-$(CONFIG_PHY_CADENCE_DPHY_RX) += cdns-dphy-rx.o
obj-$(CONFIG_PHY_CADENCE_SIERRA) += phy-cadence-sierra.o
obj-$(CONFIG_PHY_CADENCE_SALVO) += phy-cadence-salvo.o
diff --git a/drivers/phy/cadence/cdns-dphy-rx.c b/drivers/phy/cadence/cdns-dphy-rx.c
new file mode 100644
index 000000000000..92de5d418cbb
--- /dev/null
+++ b/drivers/phy/cadence/cdns-dphy-rx.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/phy/phy.h>
+#include <linux/phy/phy-mipi-dphy.h>
+#include <linux/platform_device.h>
+
+#define DPHY_PMA_CMN(reg) (reg)
+#define DPHY_PCS(reg) (0xb00 + (reg))
+#define DPHY_ISO(reg) (0xc00 + (reg))
+
+#define DPHY_CMN_SSM DPHY_PMA_CMN(0x20)
+#define DPHY_CMN_RX_MODE_EN BIT(10)
+#define DPHY_CMN_RX_BANDGAP_TIMER_MASK GENMASK(8, 1)
+#define DPHY_CMN_SSM_EN BIT(0)
+
+#define DPHY_CMN_RX_BANDGAP_TIMER 0x14
+
+#define DPHY_BAND_CFG DPHY_PCS(0x0)
+#define DPHY_BAND_CFG_RIGHT_BAND GENMASK(9, 5)
+#define DPHY_BAND_CFG_LEFT_BAND GENMASK(4, 0)
+
+#define DPHY_POWER_ISLAND_EN_DATA DPHY_PCS(0x8)
+#define DPHY_POWER_ISLAND_EN_DATA_VAL 0xaaaaaaaa
+
+#define DPHY_POWER_ISLAND_EN_CLK DPHY_PCS(0xc)
+#define DPHY_POWER_ISLAND_EN_CLK_VAL 0xaa
+
+#define DPHY_ISO_CL_CTRL_L DPHY_ISO(0x10)
+#define DPHY_ISO_DL_CTRL_L0 DPHY_ISO(0x14)
+#define DPHY_ISO_DL_CTRL_L1 DPHY_ISO(0x20)
+#define DPHY_ISO_DL_CTRL_L2 DPHY_ISO(0x30)
+#define DPHY_ISO_DL_CTRL_L3 DPHY_ISO(0x3c)
+
+#define DPHY_ISO_LANE_READY_BIT 0
+#define DPHY_ISO_LANE_READY_TIMEOUT_MS 100UL
+
+#define DPHY_LANES_MIN 1
+#define DPHY_LANES_MAX 4
+
+struct cdns_dphy_rx {
+ void __iomem *regs;
+ struct device *dev;
+ struct phy *phy;
+};
+
+struct cdns_dphy_rx_band {
+ /* Rates are in Mbps. */
+ unsigned int min_rate;
+ unsigned int max_rate;
+};
+
+/* Order of bands is important since the index is the band number. */
+static const struct cdns_dphy_rx_band bands[] = {
+ { 80, 100 }, { 100, 120 }, { 120, 160 }, { 160, 200 }, { 200, 240 },
+ { 240, 280 }, { 280, 320 }, { 320, 360 }, { 360, 400 }, { 400, 480 },
+ { 480, 560 }, { 560, 640 }, { 640, 720 }, { 720, 800 }, { 800, 880 },
+ { 880, 1040 }, { 1040, 1200 }, { 1200, 1350 }, { 1350, 1500 },
+ { 1500, 1750 }, { 1750, 2000 }, { 2000, 2250 }, { 2250, 2500 }
+};
+
+static int cdns_dphy_rx_power_on(struct phy *phy)
+{
+ struct cdns_dphy_rx *dphy = phy_get_drvdata(phy);
+
+ /* Start RX state machine. */
+ writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
+ FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
+ DPHY_CMN_RX_BANDGAP_TIMER),
+ dphy->regs + DPHY_CMN_SSM);
+
+ return 0;
+}
+
+static int cdns_dphy_rx_power_off(struct phy *phy)
+{
+ struct cdns_dphy_rx *dphy = phy_get_drvdata(phy);
+
+ writel(0, dphy->regs + DPHY_CMN_SSM);
+
+ return 0;
+}
+
+static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
+{
+ unsigned int rate, i;
+
+ rate = hs_clk_rate / 1000000UL;
+ /* Since CSI-2 clock is DDR, the bit rate is twice the clock rate. */
+ rate *= 2;
+
+ if (rate < bands[0].min_rate)
+ return -EOPNOTSUPP;
+
+ for (i = 0; i < ARRAY_SIZE(bands); i++)
+ if (rate < bands[i].max_rate)
+ return i;
+
+ return -EOPNOTSUPP;
+}
+
+static inline int cdns_dphy_rx_wait_for_bit(void __iomem *addr,
+ unsigned int bit)
+{
+ u32 val;
+
+ return readl_relaxed_poll_timeout(addr, val, val & BIT(bit), 10,
+ DPHY_ISO_LANE_READY_TIMEOUT_MS * 1000);
+}
+
+static int cdns_dphy_rx_wait_lane_ready(struct cdns_dphy_rx *dphy,
+ unsigned int lanes)
+{
+ static const u32 data_lane_ctrl[] = {DPHY_ISO_DL_CTRL_L0,
+ DPHY_ISO_DL_CTRL_L1,
+ DPHY_ISO_DL_CTRL_L2,
+ DPHY_ISO_DL_CTRL_L3};
+ void __iomem *reg = dphy->regs;
+ unsigned int i;
+ int ret;
+
+ /* Clock lane */
+ ret = cdns_dphy_rx_wait_for_bit(reg + DPHY_ISO_CL_CTRL_L,
+ DPHY_ISO_LANE_READY_BIT);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < lanes; i++) {
+ ret = cdns_dphy_rx_wait_for_bit(reg + data_lane_ctrl[i],
+ DPHY_ISO_LANE_READY_BIT);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int cdns_dphy_rx_configure(struct phy *phy,
+ union phy_configure_opts *opts)
+{
+ struct cdns_dphy_rx *dphy = phy_get_drvdata(phy);
+ unsigned int reg, lanes = opts->mipi_dphy.lanes;
+ int band_ctrl, ret;
+
+ /* Data lanes. Minimum one lane is mandatory. */
+ if (lanes < DPHY_LANES_MIN || lanes > DPHY_LANES_MAX)
+ return -EINVAL;
+
+ band_ctrl = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
+ if (band_ctrl < 0)
+ return band_ctrl;
+
+ reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
+ FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
+ writel(reg, dphy->regs + DPHY_BAND_CFG);
+
+ /*
+ * Set the required power island phase 2 time. This is mandated by DPHY
+ * specs.
+ */
+ reg = DPHY_POWER_ISLAND_EN_DATA_VAL;
+ writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_DATA);
+ reg = DPHY_POWER_ISLAND_EN_CLK_VAL;
+ writel(reg, dphy->regs + DPHY_POWER_ISLAND_EN_CLK);
+
+ ret = cdns_dphy_rx_wait_lane_ready(dphy, lanes);
+ if (ret) {
+ dev_err(dphy->dev, "DPHY wait for lane ready timeout\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int cdns_dphy_rx_validate(struct phy *phy, enum phy_mode mode,
+ int submode, union phy_configure_opts *opts)
+{
+ int ret;
+
+ if (mode != PHY_MODE_MIPI_DPHY)
+ return -EINVAL;
+
+ ret = cdns_dphy_rx_get_band_ctrl(opts->mipi_dphy.hs_clk_rate);
+ if (ret < 0)
+ return ret;
+
+ return phy_mipi_dphy_config_validate(&opts->mipi_dphy);
+}
+
+static const struct phy_ops cdns_dphy_rx_ops = {
+ .power_on = cdns_dphy_rx_power_on,
+ .power_off = cdns_dphy_rx_power_off,
+ .configure = cdns_dphy_rx_configure,
+ .validate = cdns_dphy_rx_validate,
+};
+
+static int cdns_dphy_rx_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct phy_provider *provider;
+ struct cdns_dphy_rx *dphy;
+
+ dphy = devm_kzalloc(dev, sizeof(*dphy), GFP_KERNEL);
+ if (!dphy)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, dphy);
+ dphy->dev = dev;
+
+ dphy->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(dphy->regs))
+ return PTR_ERR(dphy->regs);
+
+ dphy->phy = devm_phy_create(dev, NULL, &cdns_dphy_rx_ops);
+ if (IS_ERR(dphy->phy)) {
+ dev_err(dev, "Failed to create PHY: %d\n", PTR_ERR(dphy->phy));
+ return PTR_ERR(dphy->phy);
+ }
+
+ phy_set_drvdata(dphy->phy, dphy);
+ provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ if (IS_ERR(provider)) {
+ dev_err(dev, "Failed to register PHY provider: %d\n",
+ PTR_ERR(provider));
+ return PTR_ERR(provider);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id cdns_dphy_rx_of_match[] = {
+ { .compatible = "cdns,dphy-rx" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, cdns_dphy_rx_of_match);
+
+static struct platform_driver cdns_dphy_rx_platform_driver = {
+ .probe = cdns_dphy_rx_probe,
+ .driver = {
+ .name = "cdns-mipi-dphy-rx",
+ .of_match_table = cdns_dphy_rx_of_match,
+ },
+};
+module_platform_driver(cdns_dphy_rx_platform_driver);
+
+MODULE_AUTHOR("Pratyush Yadav <p.yadav@ti.com>");
+MODULE_DESCRIPTION("Cadence D-PHY Rx Driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: renesas: ulcb-kf: add KF HDMI output
From: Geert Uytterhoeven @ 2022-01-21 10:07 UTC (permalink / raw)
To: Nikita Yushchenko
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List
In-Reply-To: <20211225115308.2152364-1-nikita.yoush@cogentembedded.com>
Hi Nikita,
On Sat, Dec 25, 2021 at 12:54 PM Nikita Yushchenko
<nikita.yoush@cogentembedded.com> wrote:
> This patch adds nodes needed to enable DRM video output over HDMI
> connector located on KF board.
>
> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> @@ -51,6 +51,31 @@ wlan_en: regulator-wlan_en {
> startup-delay-us = <70000>;
> enable-active-high;
> };
> +
> + hdmi_1v8: regulator-hdmi-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "hdmi-1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + hdmi_3v3: regulator-hdmi-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "hdmi-3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + hdmi1-out {
Sort order.
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi1_con: endpoint {
> + remote-endpoint = <&adv7513_out>;
> + };
> + };
> + };
> };
>
> &can0 {
> @@ -236,6 +313,10 @@ gpio_exp_77: gpio@77 {
> };
> };
>
> +&du_out_rgb {
Sort order.
> + remote-endpoint = <&adv7513_in>;
> +};
> +
> &ohci0 {
> dr_mode = "otg";
> status = "okay";
> @@ -289,6 +370,18 @@ usb0_pins: usb0 {
> groups = "usb0";
> function = "usb0";
> };
> +
> + hdmi1_pins: hdmi1 {
> + du {
More sort order.
> + groups = "du_rgb888", "du_sync", "du_clk_out_0", "du_disp";
> + function = "du";
> + };
> +
> + adv7513-interrupt {
> + pins = "GP_2_14";
> + bias-pull-up;
> + };
> + };
> };
The rest looks good to me.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.18 with the sort order fixed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 1/2] spi: Add spi driver for Sunplus SP7021
From: Andy Shevchenko @ 2022-01-21 10:09 UTC (permalink / raw)
To: Lh Kuo 郭力豪
Cc: Li-hao Kuo, Philipp Zabel, Mark Brown, Rob Herring, linux-spi,
devicetree, Linux Kernel Mailing List,
Wells Lu 呂芳騰
In-Reply-To: <ee5838c307f84bb99ace070292167a26@sphcmbx02.sunplus.com.tw>
On Fri, Jan 21, 2022 at 8:54 AM Lh Kuo 郭力豪 <lh.Kuo@sunplus.com> wrote:
>
> > > > > + if (xfer->tx_buf)
> > > > > + dma_unmap_single(dev, xfer->tx_dma, xfer->len, DMA_TO_DEVICE);
> > > > > + if (xfer->rx_buf)
> > > > > + dma_unmap_single(dev, xfer->rx_dma, xfer->len,
> > > > > + DMA_FROM_DEVICE);
> > > >
> > > > Why can't you use SPI core DMA mapping code?
> > >
> > > I didn't find the SPI core DMA mapping code for single maping.
> > > The method currently used is the general DMA single-map code usage method.
> >
> > Why do you need single page mapping?
> > What's wrong with SG mapping that SPI core provides?
>
> SP7021 SPI slave dma only supports single dma in one trigger.
> It is not suitable for using SG mapping.
> If the length of the transfer is larger than the length of the SG-mapping,
> Slave-mode will get error in the transfer.
Same story for SPI DesignWare on Intel Medfield, where no SG transfers
are supported by hardware. Nevertheless, the DMA driver takes care of
this and on each interrupt recharges a channel to continue. Why can't
the same be implemented here?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] dt-bindings: dmaengine: zynqmp_dma: Convert binding to YAML
From: Harini Katakam @ 2022-01-21 10:16 UTC (permalink / raw)
To: Michael Tretter
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel, dmaengine, Rob Herring, Michal Simek, kernel
In-Reply-To: <20220112151541.1328732-1-m.tretter@pengutronix.de>
Hi Michael,
On Thu, Jan 13, 2022 at 4:52 AM Michael Tretter
<m.tretter@pengutronix.de> wrote:
>
> Hi,
>
> This series converts the ZynqMP dma engine dt bindings to yaml and fixes the
> ZynqMP device tree following the stricter yaml bindings.
>
> The series is based on https://github.com/Xilinx/linux-xlnx/tree/zynqmp/dt to
> avoid conflicts when applying the patches to the zynqmp/dt tree.
>
> Patch 1 converts the binding to yaml, Patches 2 and 3 cleanup the dma engine
> nodes in the zynqmp.dtsi that is included by actual board device trees.
Thanks for the series Michael.
Reviewed-by: Harini Katakam <harini.katakam@xilinx.com>
Regards,
Harini
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: ulcb-kf: add KF HDMI output
From: Nikita Yushchenko @ 2022-01-21 10:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List
In-Reply-To: <CAMuHMdXdW=bCxBeEu81bRBwAs5=x_KZmPcXoMe=CmFdWz=rdfQ@mail.gmail.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-devel for v5.18 with the sort order fixed.
Thank you.
I have a question regarding defining regulators.
In case when drivers expect regulators to be define, but physically chips are just wired to VCC (or to
some non-programmable power logic), what is the policy regarding regulator-fixed objects?
Shall we define per-consumer regulator-fixed objects?
Or have a single regulator-fixed for each voltage?
Or not define regulators at all and let the code to create dummy regulators?
Or something else?
Nikita
^ permalink raw reply
* RE: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit ADC-DAC
From: Pop, Cristian @ 2022-01-21 10:24 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
robh+dt@kernel.org
In-Reply-To: <20220116115228.1f7b4728@jic23-huawei>
Hi Jonathan,
The additional functionality it is a little bit unclear to me.
> -----Original Message-----
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Sunday, January 16, 2022 1:52 PM
> To: Pop, Cristian <Cristian.Pop@analog.com>
> Cc: linux-iio@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; robh+dt@kernel.org
> Subject: Re: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit
> ADC-DAC
>
> [External]
>
> On Tue, 11 Jan 2022 13:59:19 +0200
> Cristian Pop <cristian.pop@analog.com> wrote:
>
> > This allows remote reading and writing of the GPIOs. This is useful in
> > application that run on another PC, at system level, where multiple
> > iio devices and GPIO devices are integrated together.
> Hi Cristian,
>
> So I fully understand why this can be useful, but it is a software only
> construction so I'm not convinced that it makes sense to necessarily
> configure it via device tree. A better fit may well be configfs.
> (note I always meant to add configfs controls for iio_hwmon but haven't
> found the time to do it yet...)
>
> As it currently stands, doing only polled / sysfs reads this driver doesn't do
> enough to justify its existence. You could just do all this in userspace using
> the existing gpio interfaces. So to be useful I'd expect it to at least do
> triggered buffer capture.
What do you mean by triggered buffer capture? Should I save previous GPIO
states into a buffer? What should I do with them?
A useful use case that I see:
- Is to register a function callback (in kernel space, maybe user space that
should be used by a different driver), and called in the interrupt handler
when the state of an input GPIO changes.
- Output to a GPIO from a buffer using a clock, obtaining a PWM like signal.
>
> When we have talked about handling digital signals int he past we discussed
> whether the IIO channel description would also benefit from tighter packing
> than the current minimum of a byte per channel. Perhaps we don't
> technically 'need' it here but if we do add it in future it will be hard to retrofit
> into this driver without big userspace ABI changes (i.e. breaking all existing
> users).
>
> I've not repeated stuff Andy got it in his review (assuming I remembered it
> was something Andy raised).
>
> Conclusion:
> 1) Creation interface needs a rethink or strong argument why it belongs in
> DT.
> 2) Driver needs to do more to justify it's existence.
>
> Jonathan
>
> >
> > Signed-off-by: Cristian Pop <cristian.pop@analog.com>
> > ---
> > drivers/iio/addac/Kconfig | 8 +
> > drivers/iio/addac/Makefile | 1 +
> > drivers/iio/addac/one-bit-adc-dac.c | 229
> > ++++++++++++++++++++++++++++
> > 3 files changed, 238 insertions(+)
> > create mode 100644 drivers/iio/addac/one-bit-adc-dac.c
> >
> > diff --git a/drivers/iio/addac/Kconfig b/drivers/iio/addac/Kconfig
> > index 138492362f20..5f311f4a747e 100644
> > --- a/drivers/iio/addac/Kconfig
> > +++ b/drivers/iio/addac/Kconfig
> > @@ -17,4 +17,12 @@ config AD74413R
> > To compile this driver as a module, choose M here: the
> > module will be called ad74413r.
> >
> > +config ONE_BIT_ADC_DAC
> > + tristate "ONE_BIT_ADC_DAC driver"
> > + help
> > + Say yes here to build support for ONE_BIT_ADC_DAC driver.
>
> Needs a lot more detail here. Though naming it to be explicitly about GPIO to
> IIO binding would help.
>
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called one-bit-adc-dac.
> > +
> > endmenu
> > diff --git a/drivers/iio/addac/Makefile b/drivers/iio/addac/Makefile
> > index cfd4bbe64ad3..0a33f0706b55 100644
> > --- a/drivers/iio/addac/Makefile
> > +++ b/drivers/iio/addac/Makefile
> > @@ -5,3 +5,4 @@
> >
> > # When adding new entries keep the list in alphabetical order
> > obj-$(CONFIG_AD74413R) += ad74413r.o
> > +obj-$(CONFIG_ONE_BIT_ADC_DAC) += one-bit-adc-dac.o
> > diff --git a/drivers/iio/addac/one-bit-adc-dac.c
> > b/drivers/iio/addac/one-bit-adc-dac.c
> > new file mode 100644
> > index 000000000000..5680de594429
> > --- /dev/null
> > +++ b/drivers/iio/addac/one-bit-adc-dac.c
> > @@ -0,0 +1,229 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> > +/*
> > + * one-bit-adc-dac
>
> Improve description here as well. It's really just a wrapper for a gpio in an IIO
> channel, so just say that. Fine to say the representation is 1 bit ADC or DAC
> channels as well, but I think the GPIO part will be more obvious to the casual
> reader.
>
> > + *
> > + * Copyright 2022 Analog Devices Inc.
> > + */
> > +
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/iio/iio.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/gpio/consumer.h>
> > +
> > +enum ch_direction {
> > + CH_IN,
> > + CH_OUT,
> > +};
> > +
> > +struct one_bit_adc_dac_state {
> > + int in_num_ch;
> > + int out_num_ch;
> > + struct platform_device *pdev;
>
> Not used after probe so don't keep it around.
>
> > + struct gpio_descs *in_gpio_descs;
> > + struct gpio_descs *out_gpio_descs;
> > + const char **labels;
> > +};
> > +
> > +static int one_bit_adc_dac_read_raw(struct iio_dev *indio_dev,
> > + const struct iio_chan_spec *chan, int *val, int *val2, long info) {
> > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > + struct gpio_descs *descs;
> > +
> > + switch (info) {
> > + case IIO_CHAN_INFO_RAW:
> > + if (chan->output)
> > + descs = st->out_gpio_descs;
> > + else
> > + descs = st->in_gpio_descs;
> > + *val = gpiod_get_value_cansleep(descs->desc[chan-
> >channel]);
> > +
> > + return IIO_VAL_INT;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static int one_bit_adc_dac_write_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int val,
> > + int val2,
> > + long info)
> > +{
> > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > + int channel = chan->channel;
> > +
> > + if (!chan->output)
> > + return 0;
>
> -EINVAL; It's an error that should be reported to userspace..
>
> > +
> > + switch (info) {
> > + case IIO_CHAN_INFO_RAW:
> > + gpiod_set_value_cansleep(st->out_gpio_descs-
> >desc[channel], val);
> > +
> > + return 0;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static int one_bit_adc_dac_read_label(struct iio_dev *indio_dev,
> > + const struct iio_chan_spec *chan, char *label) {
> > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > + int ch;
> > +
> > + if (chan->output)
> > + ch = chan->channel + st->in_num_ch;
> > + else
> > + ch = chan->channel;
> > +
> > + return sprintf(label, "%s\n", st->labels[ch]); }
> > +
> > +static const struct iio_info one_bit_adc_dac_info = {
> > + .read_raw = &one_bit_adc_dac_read_raw,
> > + .write_raw = &one_bit_adc_dac_write_raw,
> > + .read_label = &one_bit_adc_dac_read_label, };
> > +
> > +static int one_bit_adc_dac_set_ch(struct iio_chan_spec *channels,
> > + int num_ch,
> > + enum ch_direction direction)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < num_ch; i++) {
> > + channels[i].type = IIO_VOLTAGE;
> > + channels[i].indexed = 1;
> > + channels[i].channel = i;
> > + channels[i].info_mask_separate =
> BIT(IIO_CHAN_INFO_RAW);
> > + channels[i].output = direction;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int one_bit_adc_dac_set_channel_label(struct iio_dev *indio_dev,
> > + struct iio_chan_spec
> *channels,
> > + int num_channels)
> > +{
> > + struct device *device = indio_dev->dev.parent;
> > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > + struct fwnode_handle *fwnode;
> > + struct fwnode_handle *child;
> > + struct iio_chan_spec *chan;
> > + const char *label;
> > + int crt_ch = 0, child_num, i = 0;
> > +
> > + fwnode = dev_fwnode(device);
> > + child_num = device_get_child_node_count(device);
> > +
> > + st->labels = devm_kzalloc(device, sizeof(*st->labels) * child_num,
> GFP_KERNEL);
> > + if (!st->labels)
> > + return -ENOMEM;
> > +
> > + i = child_num;
> > + fwnode_for_each_child_node(fwnode, child) {
> > + if (fwnode_property_read_u32(child, "reg", &crt_ch))
> > + continue;
> > +
> > + if (crt_ch >= num_channels)
> > + continue;
> > +
> > + if (fwnode_property_read_string(child, "label", &label))
> > + continue;
> > +
> > + chan = &channels[crt_ch];
> ? Not used.
>
> > + st->labels[--i] = label;
>
> I've no idea how this works... Should be looking for the chan->channel value
> as that's what your read uses to index.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int one_bit_adc_dac_parse_dt(struct iio_dev *indio_dev) {
> > + struct one_bit_adc_dac_state *st = iio_priv(indio_dev);
> > + struct iio_chan_spec *channels;
> > + int ret, in_num_ch = 0, out_num_ch = 0;
> > +
> > + st->in_gpio_descs = devm_gpiod_get_array_optional(&st->pdev-
> >dev, "in", GPIOD_IN);
> > + if (IS_ERR(st->in_gpio_descs))
> > + return PTR_ERR(st->in_gpio_descs);
> > +
> > + if (st->in_gpio_descs)
> > + in_num_ch = st->in_gpio_descs->ndescs;
> > +
> > + st->out_gpio_descs = devm_gpiod_get_array_optional(&st->pdev-
> >dev, "out", GPIOD_OUT_LOW);
> > + if (IS_ERR(st->out_gpio_descs))
> > + return PTR_ERR(st->out_gpio_descs);
> > +
> > + if (st->out_gpio_descs)
> > + out_num_ch = st->out_gpio_descs->ndescs;
> > + st->in_num_ch = in_num_ch;
> > + st->out_num_ch = out_num_ch;
> > +
> > + channels = devm_kcalloc(indio_dev->dev.parent, in_num_ch +
> out_num_ch,
> > + sizeof(*channels), GFP_KERNEL);
> > + if (!channels)
> > + return -ENOMEM;
> > +
> > + ret = one_bit_adc_dac_set_ch(&channels[0], in_num_ch, CH_IN);
> > + if (ret)
> > + return ret;
> > +
> > + ret = one_bit_adc_dac_set_ch(&channels[in_num_ch],
> out_num_ch, CH_OUT);
> > + if (ret)
> > + return ret;
> > +
> > + ret = one_bit_adc_dac_set_channel_label(indio_dev, channels,
> in_num_ch + out_num_ch);
> > + if (ret)
> > + return ret;
> > +
> > + indio_dev->channels = channels;
> > + indio_dev->num_channels = in_num_ch + out_num_ch;
> > +
> > + return 0;
> > +}
> > +
> > +static int one_bit_adc_dac_probe(struct platform_device *pdev) {
> > + struct iio_dev *indio_dev;
> > + struct one_bit_adc_dac_state *st;
> > + int ret;
> > +
> > + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*st));
> > + if (!indio_dev)
> > + return -ENOMEM;
> > +
> > + st = iio_priv(indio_dev);
> > + st->pdev = pdev;
> > + indio_dev->name = "one-bit-adc-dac";
> > + indio_dev->modes = INDIO_DIRECT_MODE;
> > + indio_dev->info = &one_bit_adc_dac_info;
> > +
> > + ret = one_bit_adc_dac_parse_dt(indio_dev);
> > + if (ret)
> > + return ret;
> > +
> > + return devm_iio_device_register(indio_dev->dev.parent,
> indio_dev); }
> > +
> > +static const struct of_device_id one_bit_adc_dac_dt_match[] = {
> > + { .compatible = "one-bit-adc-dac" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, one_bit_adc_dac_dt_match);
> > +
> > +static struct platform_driver one_bit_adc_dac_driver = {
> > + .driver = {
> > + .name = "one-bit-adc-dac",
> > + .of_match_table = one_bit_adc_dac_dt_match,
> > + },
> > + .probe = one_bit_adc_dac_probe,
> > +};
> > +module_platform_driver(one_bit_adc_dac_driver);
> > +
> > +MODULE_AUTHOR("Cristian Pop <cristian.pop@analog.com>");
> > +MODULE_DESCRIPTION("One bit ADC DAC converter");
> MODULE_LICENSE("Dual
> > +BSD/GPL");
> > \ No newline at end of file
>
> Make sure to eyeball your patches before sending as this sort of thing should
> be caught at that stage...
>
^ permalink raw reply
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree
From: Zong Li @ 2022-01-21 10:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Palmer Dabbelt, Rob Herring, Paul Walmsley, Albert Ou,
Krzysztof Kozlowski, Conor Dooley, Bin Meng, Green Wan, Vinod,
dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org List, linux-riscv
In-Reply-To: <CAMuHMdVh_cXpbUeOmr_1K0dOJwGHSO0Ao=W43j5mpgvOiNyV9w@mail.gmail.com>
On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Zong, Palmer,
>
> On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote:
> > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote:
> > > > It currently assumes that there are always four channels, it would
> > > > cause the error if there is actually less than four channels. Change
> > > > that by getting number of channel from device tree.
> > > >
> > > > For backwards-compatible, it uses the default value (i.e. 4) when there
> > > > is no 'dma-channels' information in dts.
> > >
> > > Some of the same wording issues here as those I pointed out in the DT
> > > bindings patch.
> > >
> > > > Signed-off-by: Zong Li <zong.li@sifive.com>
>
> > > > --- a/drivers/dma/sf-pdma/sf-pdma.c
> > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c
> > > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma)
> > > > static int sf_pdma_probe(struct platform_device *pdev)
> > > > {
> > > > struct sf_pdma *pdma;
> > > > - struct sf_pdma_chan *chan;
> > > > struct resource *res;
> > > > - int len, chans;
> > > > int ret;
> > > > const enum dma_slave_buswidth widths =
> > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES |
> > > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev)
> > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES |
> > > > DMA_SLAVE_BUSWIDTH_64_BYTES;
> > > >
> > > > - chans = PDMA_NR_CH;
> > > > - len = sizeof(*pdma) + sizeof(*chan) * chans;
> > > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
> > > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL);
> > > > if (!pdma)
> > > > return -ENOMEM;
> > > >
> > > > - pdma->n_chans = chans;
> > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels",
> > > > + &pdma->n_chans);
> > > > + if (ret) {
> > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n");
> > > > + pdma->n_chans = PDMA_MAX_NR_CH;
> > > > + }
> > > > +
> > > > + if (pdma->n_chans > PDMA_MAX_NR_CH) {
> > > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n");
> > > > + return -EINVAL;
> > >
> > > Can we get away with just using only the number of channels the driver
> > > actually supports? ie, just never sending an op to the channels above
> > > MAX_NR_CH? That should leave us with nothing to track.
>
> In theory we can...
>
> > It might be a bit like when pdma->n_chans is bigger than the maximum,
> > set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we
> > don't access the channels above the maximum. If I understand
> > correctly, I gave the similar thought in the thread of v2 patch, and
> > there are some discussions on that, but this way seems to lead to
> > hard-to-track problems.
>
> ... but that would mean that when a new variant appears that supports
> more channels, no error is printed, and people might not notice
> immediately that the higher channels are never used.
>
I guess people might need to follow the dt-bindings, so they couldn't
specify the number of channels to the value which is more than
maximum. But as you mentioned, if people don't notice that and specify
it more than maximum, they wouldn't be aware that the higher channels
are never used. It seems to me that we could keep returning the error
there, or show a warning message and use PDMA_MAX_NR_CH in that
situation, both looks good to me.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 00/22] drm/rockchip: RK356x VOP2 support
From: Sascha Hauer @ 2022-01-21 10:32 UTC (permalink / raw)
To: Piotr Oniszczuk
Cc: dri-devel, linux-arm-kernel@lists.infradead.org, linux-rockchip,
devicetree@vger.kernel.org, kernel, Andy Yan, Benjamin Gaignard,
Michael Riesch, Sandy Huang, Heiko Stübner, Peter Geis
In-Reply-To: <AA3A26CB-6282-4A6B-99DC-8042DC8926BB@gmail.com>
Hi Piotr,
On Wed, Jan 19, 2022 at 12:29:49PM +0100, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 20.12.2021, o godz. 12:06:
> >
> >
> > Third round of patches and last one for this year. I hopefully integrated
> > all review feedback. Additionally the driver is now fully converted to
> > regmap, so no struct vop_reg necessary anymore.
> >
> > Sascha
> >
> > Changes since v2:
> > - Add pin names to HDMI supply pin description
> > - Add hclk support to HDMI driver
> > - Dual license rockchip-vop2 binding, update binding
> > - Add HDMI connector to board dts files
> > - drop unnecessary gamma_lut registers from vop2
> > - Update dclk_vop[012] clock handling, no longer hacks needed
> > - Complete regmap conversion
> >
>
> Sascha
>
> I'm using you VOP2 code on rk3566 tvbox (x96-x6) with very good results.
>
> I have just few questions:
>
> 1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?
I had to google what CEC actually is. We don't have plans supporting it.
It looks like this is a matter of the HDMI driver supporting this and
not bound to the rockchip driver.
>
> 2. VOP2 code works nice for me for x11/glamour and for EGLFS with EGL DMAbuf rendering by Mesa EGL_LINUX_DMA_BUF_EXT.
> I have issue however with app. rendering to DRM planes (GUI is DRM plane1, video is DRM pane2).
> My ppp starts/works without any errors in log - but screen stays with kernel messages content.
> (it looks to me like i.e. app renders to DRM plane but DRM display driver not pass it to CRTC. just wild guess here...).
You enabled the panfrost driver with other patches, right?
>
> 3. in kernel dmesg I have many:
>
> "rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".
This message is correct. This corresponds to
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
support this. I have a similar problem here with
weston-simple-dmabuf-egl. By default this uses DRM_FORMAT_XRGB8888
which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA. In
panfrost_afbc_format() we have:
/* Don't allow swizzled formats on v7 */
switch (format) {
case PIPE_FORMAT_B8G8R8A8_UNORM:
case PIPE_FORMAT_B8G8R8X8_UNORM:
case PIPE_FORMAT_A8R8G8B8_UNORM:
case PIPE_FORMAT_X8R8G8B8_UNORM:
case PIPE_FORMAT_X8B8G8R8_UNORM:
case PIPE_FORMAT_A8B8G8R8_UNORM:
case PIPE_FORMAT_B8G8R8_UNORM:
case PIPE_FORMAT_B5G6R5_UNORM:
if (dev->arch >= 7)
return PIPE_FORMAT_NONE;
break;
default:
break;
}
This means the driver won't do AFBC with that format and picks
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED instead. Now weston is
clever enough to not pass that into the VOP2 driver, apparently your
application is not and as a result you see that message.
In weston-simple-dmabuf-egl I can pass a suitable format on the command
line, in my case I use DRM_FORMAT_ABGR8888 (which becomes
PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
which then can be rendered in the VOP2 cluster window overlay.
>
> It comes from MESA i think - but i suspect because VOP2 provides
> unknown/wrong DRM modifier to mesa?
Nope, the modifiers the VOP2 driver propagates are correct. It doesn't
claim to support DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v12, 2/2] net: Add dm9051 driver
From: Andy Shevchenko @ 2022-01-21 10:37 UTC (permalink / raw)
To: Joseph CHAMG
Cc: David S . Miller, Jakub Kicinski, Rob Herring, joseph_chang,
netdev, devicetree, Linux Kernel Mailing List, Andrew Lunn,
Leon Romanovsky
In-Reply-To: <20220121041428.6437-3-josright123@gmail.com>
On Fri, Jan 21, 2022 at 6:15 AM Joseph CHAMG <josright123@gmail.com> wrote:
>
> v1-v4
>
> Add davicom dm9051 spi ethernet driver. The driver work for the
> device platform with spi master
>
> Test ok with raspberry pi 2 and pi 4, the spi configure used in
> my raspberry pi 4 is spi0.1, spi speed 31200000, and INT by pin 26.
>
> v5
>
> Work to eliminate the wrappers to be clear for read, swapped to
> phylib for phy connection tasks.
>
> Tested with raspberry pi 4. Test for netwroking function, CAT5
> cable unplug/plug and also ethtool detect for link state, and
> all are ok.
>
> v6
>
> remove the redundant code that phylib has support,
> adjust to be the reasonable sequence,
> fine tune comments, add comments for pause function support
>
> Tested with raspberry pi 4. Test for netwroking function, CAT5
> cable unplug/plug and also ethtool detect for link state, and
> all are ok.
>
> v7
>
> read/write registers must return error code to the callet,
> add to enable pause processing
>
> v8
>
> not parmanently set MAC by .ndo_set_mac_address
>
> correct rx function such as clear ISR,
> inblk avoid stack buffer,
> simple skb buffer process and
> easy use netif_rx_ni.
>
> simplely queue init and wake the queues,
> limit the start_xmit function use netif_stop_queue.
>
> descript that schedule delay is essential
> for tx_work and rxctrl_work
>
> eliminate ____cacheline_aligned and
> add static int msg_enable.
>
> v9
>
> use phylib, no need 'select MII' in Kconfig,
> make it clear in dm9051_xfer when using spi_sync,
> improve the registers read/write so that error code
> return as far as possible up the call stack.
>
> v10
>
> use regmap APIs for SPI and MDIO,
> modify to correcting such as include header files
> and program check styles
>
> v11
>
> eliminate the redundant code for struct regmap_config data
> use regmap_read_poll_timeout
> use corresponding regmap APIs, i.e. MDIO, SPI
> all read/write registers by regmap
> all read/write registers with mutex lock by regmap
> problem: regmap MDIO and SPI has no .reg_update_bits, I write it
> in the driver
> problem: this chip can support bulk read/write to rx/tx data, but
> can not support bulk read/write to continue registers, so need
> read/write register one by one
>
> v12
>
> correctly use regmap bulk read/write/update_bits APIs
> use mdiobus to work to phylib and to this driver
> fine tune to arrange the source code to better usage
This is not tagged properly. Also, I specifically removed everything
else to point out, please, read finally the article [1] and write a
proper commit message. And move changelog under the cutter '--- '
line. Without doing these two things nobody can do anything with your
contribution.
[1]: https://cbea.ms/git-commit/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v12, 2/2] net: Add dm9051 driver
From: Andy Shevchenko @ 2022-01-21 10:41 UTC (permalink / raw)
To: Joseph CHAMG
Cc: David S . Miller, Jakub Kicinski, Rob Herring, joseph_chang,
netdev, devicetree, Linux Kernel Mailing List, Andrew Lunn,
Leon Romanovsky
In-Reply-To: <CAHp75Vc9pJMNfW2roUbdrcxCSvyGboTsJC0oTDCcTAS5bmF08w@mail.gmail.com>
On Fri, Jan 21, 2022 at 12:37 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Jan 21, 2022 at 6:15 AM Joseph CHAMG <josright123@gmail.com> wrote:
...
> > correctly use regmap bulk read/write/update_bits APIs
> > use mdiobus to work to phylib and to this driver
> > fine tune to arrange the source code to better usage
>
> This is not tagged properly. Also, I specifically removed everything
> else to point out, please, read finally the article [1] and write a
> proper commit message. And move changelog under the cutter '--- '
> line. Without doing these two things nobody can do anything with your
> contribution.
Next comment, remove all those `unlickely()` calls. Otherwise you have
to justify their appearance.
> [1]: https://cbea.ms/git-commit/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint
From: AngeloGioacchino Del Regno @ 2022-01-21 11:46 UTC (permalink / raw)
To: Nícolas F. R. A. Prado, Rob Herring, Matthias Brugger,
Robert Foss, Xin Ji
Cc: devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
kernel
In-Reply-To: <20220120224204.773117-1-nfraprado@collabora.com>
Il 20/01/22 23:42, Nícolas F. R. A. Prado ha scritto:
> mt8183-kukui-jacuzzi has an anx7625 bridge connected to the output of
> its DSI host. However, after fd0310b6fe7d ("drm/bridge: anx7625: add
> MIPI DPI input feature"), a bus-type property started being required in
> the endpoint node by the driver to indicate whether it is DSI or DPI.
>
> Add the missing bus-type property and set it to 5
> (V4L2_FWNODE_BUS_TYPE_PARALLEL) so that the driver has its input
> configured to DSI and the display pipeline can probe correctly.
>
> While at it, also set the data-lanes property that was also introduced
> in that same commit, so that we don't rely on the default value.
>
> Fixes: fd0310b6fe7d ("drm/bridge: anx7625: add MIPI DPI input feature")
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> index 8f7bf33f607d..e8f133dc96b9 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> @@ -171,6 +171,8 @@ port@0 {
>
> anx7625_in: endpoint {
> remote-endpoint = <&dsi_out>;
> + bus-type = <5>;
> + data-lanes = <0 1 2 3>;
> };
> };
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] media: dt-bindings: media: Document RZ/G2L CSI-2 block
From: Lad, Prabhakar @ 2022-01-21 11:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lad Prabhakar, Niklas Söderlund, Jacopo Mondi, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Laurent Pinchart,
Sakari Ailus, Hans Verkuil, Linux Media Mailing List,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Biju Das
In-Reply-To: <CAMuHMdWnTxxXz-aBL10nSiQt67bm93yXHbSvFtrs3Yme9ZQcpg@mail.gmail.com>
Hi Geert,
On Fri, Jan 21, 2022 at 9:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Fri, Jan 21, 2022 at 2:06 AM Lad Prabhakar
> <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > Document the CSI-2 block which is part of CRU found in Renesas
> > RZ/G2L SoC.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Thanks for your patch!
>
> > ---
> > Hi Geert/All,
> >
> > vclk and pclk clocks are shared with CRU both CSI and CRU driver are using
> > pm_runtime. pclk clock is necessary for register access where as vclk clock
> > is only used for calculations. So would you suggest passing vclk as part of
>
> What do you mean by "calculations"?
To set the CSI2nMCT2 register bits (FRRSKW/FRRCLK), vclk clock rate is used.
> The bindings say this is the main clock?
>
That is because the RZG2L_clock_list_r02_02.xlsx mentions it as the main clock.
> > clocks (as currently implemented) or pass the vclk clock rate as a dt property.
>
> Please do not specify clock rates in DT, but always pass clock
> specifiers instead.
> The clock subsystem handles sharing of clocks just fine.
>
Agreed.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH v8 1/4] phy: cadence: Add Cadence D-PHY Rx driver
From: kernel test robot @ 2022-01-21 11:53 UTC (permalink / raw)
To: Pratyush Yadav, Vinod Koul
Cc: kbuild-all, Pratyush Yadav, Laurent Pinchart, Paul Kocialkowski,
Tomi Valkeinen, Vignesh Raghavendra, Kishon Vijay Abraham I,
Rob Herring, Swapnil Jakhade, devicetree
In-Reply-To: <20220121093849.3218092-2-p.yadav@ti.com>
Hi Pratyush,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master v5.16 next-20220121]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Pratyush-Yadav/Rx-mode-support-for-Cadence-DPHY/20220121-174104
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20220121/202201211916.mtjEWmKi-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/a27020695f773ffff7f462e53f7ff7ca39109cd0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Pratyush-Yadav/Rx-mode-support-for-Cadence-DPHY/20220121-174104
git checkout a27020695f773ffff7f462e53f7ff7ca39109cd0
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=m68k SHELL=/bin/bash drivers/phy/cadence/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from include/linux/device.h:15,
from include/linux/phy/phy.h:15,
from drivers/phy/cadence/cdns-dphy-rx.c:11:
drivers/phy/cadence/cdns-dphy-rx.c: In function 'cdns_dphy_rx_probe':
>> drivers/phy/cadence/cdns-dphy-rx.c:223:30: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
223 | dev_err(dev, "Failed to create PHY: %d\n", PTR_ERR(dphy->phy));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:144:56: note: in expansion of macro 'dev_fmt'
144 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
drivers/phy/cadence/cdns-dphy-rx.c:223:17: note: in expansion of macro 'dev_err'
223 | dev_err(dev, "Failed to create PHY: %d\n", PTR_ERR(dphy->phy));
| ^~~~~~~
drivers/phy/cadence/cdns-dphy-rx.c:223:54: note: format string is defined here
223 | dev_err(dev, "Failed to create PHY: %d\n", PTR_ERR(dphy->phy));
| ~^
| |
| int
| %ld
In file included from include/linux/device.h:15,
from include/linux/phy/phy.h:15,
from drivers/phy/cadence/cdns-dphy-rx.c:11:
drivers/phy/cadence/cdns-dphy-rx.c:230:30: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
230 | dev_err(dev, "Failed to register PHY provider: %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:144:56: note: in expansion of macro 'dev_fmt'
144 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
drivers/phy/cadence/cdns-dphy-rx.c:230:17: note: in expansion of macro 'dev_err'
230 | dev_err(dev, "Failed to register PHY provider: %d\n",
| ^~~~~~~
drivers/phy/cadence/cdns-dphy-rx.c:230:65: note: format string is defined here
230 | dev_err(dev, "Failed to register PHY provider: %d\n",
| ~^
| |
| int
| %ld
vim +223 drivers/phy/cadence/cdns-dphy-rx.c
203
204 static int cdns_dphy_rx_probe(struct platform_device *pdev)
205 {
206 struct device *dev = &pdev->dev;
207 struct phy_provider *provider;
208 struct cdns_dphy_rx *dphy;
209
210 dphy = devm_kzalloc(dev, sizeof(*dphy), GFP_KERNEL);
211 if (!dphy)
212 return -ENOMEM;
213
214 dev_set_drvdata(dev, dphy);
215 dphy->dev = dev;
216
217 dphy->regs = devm_platform_ioremap_resource(pdev, 0);
218 if (IS_ERR(dphy->regs))
219 return PTR_ERR(dphy->regs);
220
221 dphy->phy = devm_phy_create(dev, NULL, &cdns_dphy_rx_ops);
222 if (IS_ERR(dphy->phy)) {
> 223 dev_err(dev, "Failed to create PHY: %d\n", PTR_ERR(dphy->phy));
224 return PTR_ERR(dphy->phy);
225 }
226
227 phy_set_drvdata(dphy->phy, dphy);
228 provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
229 if (IS_ERR(provider)) {
230 dev_err(dev, "Failed to register PHY provider: %d\n",
231 PTR_ERR(provider));
232 return PTR_ERR(provider);
233 }
234
235 return 0;
236 }
237
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v9 12/15] media: mtk-vcodec: enc: Remove mtk_vcodec_release_enc_pm
From: Hans Verkuil @ 2022-01-21 11:56 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Yong Wu,
Joerg Roedel, Rob Herring, Krzysztof Kozlowski, David Airlie,
Mauro Carvalho Chehab
Cc: Dafna Hirschfeld, Chun-Kuang Hu, Will Deacon, dri-devel, yf.wang,
anthony.huang, youlin.pei, Irui Wang, Evan Green, Eizan Miyamoto,
Matthias Kaehlcke, linux-arm-kernel, mingyuan.ma, linux-media,
devicetree, Philipp Zabel, libo.kang, yi.kuo, linux-mediatek,
Hsin-Yi Wang, Tiffany Lin, anan.sun, srv_heupstream, acourbot,
linux-kernel, Tomasz Figa, iommu, Daniel Vetter, Robin Murphy
In-Reply-To: <e940d705-2057-4d5e-0a21-8464ca04caaf@gmail.com>
Hi Matthias,
On 1/13/22 17:10, Matthias Brugger wrote:
> Hi Hans,
>
> On 13/01/2022 11:15, Hans Verkuil wrote:
>> On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
>>> Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
>>>> Il 12/11/21 11:55, Yong Wu ha scritto:
>>>>> After this patchset, mtk_vcodec_release_enc_pm has only one line.
>>>>> then remove that function, use pm_runtime_disable instead.
>>>>>
>>>>> meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
>>>>> rename it from the _pm to _clk.
>>>>>
>>>>> No functional change.
>>>>>
>>>>> CC: Tiffany Lin <tiffany.lin@mediatek.com>
>>>>> CC: Irui Wang <irui.wang@mediatek.com>
>>>>> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
>>>>
>>>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>>>
>>>
>>> Hello Yong,
>>> the mtk-vcodec patches were merged in Yunfei's vcodec patch series and Hans has
>>> scheduled that for v5.18.
>>>
>>> Can you please send a v10 and drop patches 10/15, 11/15, 12/15 (all of the
>>> media: mtk-vcodec: *) from this series?
>>>
>>> For the records, I think that after sending v10 this series is ready to be merged,
>>> as it was well reviewed and also tested on many MTK platforms.
>>
>> Good to know. When I have the v10 I'll try to prioritize reviewing it and running
>> my usual tests.
>>
>> Yong, please make sure you run 'checkpatch.pl --strict' over the v10 patches and fix
>> any issues (using common sense).
>>
>
> Can you please take me in the look when you take the patches. I'll take the DTS related as soon as you queue up the others.
This just got merged into our tree.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes
From: AngeloGioacchino Del Regno @ 2022-01-21 11:58 UTC (permalink / raw)
To: Moudy Ho, Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
Maoguang Meng, daoyuan huang, Ping-Hsun Wu, menghui.lin, sj.huang,
allen-kh.cheng, randy.wu, jason-jh.lin, roy-cw.yeh, river.cheng,
srv_heupstream
In-Reply-To: <20220105093758.6850-3-moudy.ho@mediatek.com>
Il 05/01/22 10:37, Moudy Ho ha scritto:
> Add device nodes for Media Data Path 3 (MDP3) modules.
>
> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 108 ++++++++++++++++++++++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index ba4584faca5a..b872ef1ff6b3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1325,6 +1325,79 @@
> mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
> };
>
> + mdp3_rdma0: mdp3_rdma0@14001000 {
> + compatible = "mediatek,mt8183-mdp3",
> + "mediatek,mt8183-mdp3-rdma0";
> + mediatek,scp = <&scp>;
> + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
> + "mediatek,mt8183-mdp3-dl2",
> + "mediatek,mt8183-mdp3-path1",
> + "mediatek,mt8183-mdp3-path2",
> + "mediatek,mt8183-mdp3-imgi",
> + "mediatek,mt8183-mdp3-exto";
> + reg = <0 0x14001000 0 0x1000>,
> + <0 0x14000000 0 0x1000>,
> + <0 0x14005000 0 0x1000>,
> + <0 0x14006000 0 0x1000>,
> + <0 0x15020000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>,
> + <&gce SUBSYS_1400XXXX 0 0x1000>,
> + <&gce SUBSYS_1400XXXX 0x5000 0x1000>,
> + <&gce SUBSYS_1400XXXX 0x6000 0x1000>,
> + <&gce SUBSYS_1502XXXX 0 0x1000>;
> + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> + <&mmsys CLK_MM_MDP_RSZ1>,
> + <&mmsys CLK_MM_MDP_DL_TXCK>,
> + <&mmsys CLK_MM_MDP_DL_RX>,
> + <&mmsys CLK_MM_IPU_DL_TXCK>,
> + <&mmsys CLK_MM_IPU_DL_RX>;
> + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> + mediatek,mmsys = <&mmsys>;
> + mediatek,mm-mutex = <&mutex>;
> + mediatek,mailbox-gce = <&gce>;
> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>,
> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
Hello Moudy,
the mboxes for gce 21, 22, 23 are missing the third cell. Please fix.
Regards,
Angelo
> + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> + <&gce 0x14010000 SUBSYS_1401XXXX>,
> + <&gce 0x14020000 SUBSYS_1402XXXX>,
> + <&gce 0x15020000 SUBSYS_1502XXXX>;
> + };
> +
^ permalink raw reply
* Re: [PATCH 0/3] dt-bindings: dmaengine: zynqmp_dma: Convert binding to YAML
From: Michal Simek @ 2022-01-21 11:58 UTC (permalink / raw)
To: Michael Tretter, devicetree, linux-arm-kernel, dmaengine
Cc: robh+dt, michal.simek, kernel
In-Reply-To: <20220112151541.1328732-1-m.tretter@pengutronix.de>
On 1/12/22 16:15, Michael Tretter wrote:
> Hi,
>
> This series converts the ZynqMP dma engine dt bindings to yaml and fixes the
> ZynqMP device tree following the stricter yaml bindings.
>
> The series is based on https://github.com/Xilinx/linux-xlnx/tree/zynqmp/dt to
> avoid conflicts when applying the patches to the zynqmp/dt tree.
>
> Patch 1 converts the binding to yaml, Patches 2 and 3 cleanup the dma engine
> nodes in the zynqmp.dtsi that is included by actual board device trees.
>
> Michael
>
> Michael Tretter (3):
> dt-bindings: dmaengine: zynqmp_dma: convert to yaml
> arm64: zynqmp: Add missing #dma-cells property
> arm64: zynqmp: Rename dma to dma-controller
>
> .../dma/xilinx/xlnx,zynqmp-dma-1.0.yaml | 85 +++++++++++++++++++
> .../bindings/dma/xilinx/zynqmp_dma.txt | 26 ------
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 48 +++++++----
> 3 files changed, 117 insertions(+), 42 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml
> delete mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>
Rob/Vinod:
Not sure how you want to split it but feel free to take 2/3 and 3/3 via your
tree with my ack.
Acked-by: Michal Simek <michal.simek@xilinx.com>
If you want to take just 1/3 I will take the rest via my soc tree.
Thanks,
Michal
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] media: dt-bindings: media: Document RZ/G2L CSI-2 block
From: Geert Uytterhoeven @ 2022-01-21 12:06 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Lad Prabhakar, Niklas Söderlund, Jacopo Mondi, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Laurent Pinchart,
Sakari Ailus, Hans Verkuil, Linux Media Mailing List,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Biju Das
In-Reply-To: <CA+V-a8v1to4w0yw17DgbQic2nkX4s+W3ZxPEdp89=9SLxwvBMg@mail.gmail.com>
Hi Prabhakar,
On Fri, Jan 21, 2022 at 12:52 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
> On Fri, Jan 21, 2022 at 9:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, Jan 21, 2022 at 2:06 AM Lad Prabhakar
> > <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > > Document the CSI-2 block which is part of CRU found in Renesas
> > > RZ/G2L SoC.
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Thanks for your patch!
> >
> > > ---
> > > Hi Geert/All,
> > >
> > > vclk and pclk clocks are shared with CRU both CSI and CRU driver are using
> > > pm_runtime. pclk clock is necessary for register access where as vclk clock
> > > is only used for calculations. So would you suggest passing vclk as part of
> >
> > What do you mean by "calculations"?
> To set the CSI2nMCT2 register bits (FRRSKW/FRRCLK), vclk clock rate is used.
Ah, clock rate calculations. I (mis)understood that vclk clocked
a hardware calculation block, and was wondering what kind of heavy
calculations were involved ;-)
> > The bindings say this is the main clock?
> >
> That is because the RZG2L_clock_list_r02_02.xlsx mentions it as the main clock.
>
> > > clocks (as currently implemented) or pass the vclk clock rate as a dt property.
> >
> > Please do not specify clock rates in DT, but always pass clock
> > specifiers instead.
> > The clock subsystem handles sharing of clocks just fine.
> >
> Agreed.
So doing clk_get_rate() is fine.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: ulcb-kf: add KF HDMI output
From: Geert Uytterhoeven @ 2022-01-21 12:07 UTC (permalink / raw)
To: Nikita Yushchenko
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Mark Brown
In-Reply-To: <f49794a0-096a-1f27-a250-5a74a9ed6ba6@cogentembedded.com>
Hi Nikita,
CC Mark.
On Fri, Jan 21, 2022 at 11:18 AM Nikita Yushchenko
<nikita.yoush@cogentembedded.com> wrote:
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > i.e. will queue in renesas-devel for v5.18 with the sort order fixed.
>
> Thank you.
>
> I have a question regarding defining regulators.
>
> In case when drivers expect regulators to be define, but physically chips are just wired to VCC (or to
> some non-programmable power logic), what is the policy regarding regulator-fixed objects?
>
> Shall we define per-consumer regulator-fixed objects?
> Or have a single regulator-fixed for each voltage?
> Or not define regulators at all and let the code to create dummy regulators?
> Or something else?
That's a good question. I don't know if there is a policy. Mark?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 net 2/4] dt-bindings: net: Document fsl,erratum-a009885
From: Tobias Waldekranz @ 2022-01-21 12:30 UTC (permalink / raw)
To: Rob Herring
Cc: davem, kuba, netdev, Andrew Lunn, Madalin Bucur, devicetree,
linux-kernel
In-Reply-To: <YeoVlBEWWlqDf7NG@robh.at.kernel.org>
On Thu, Jan 20, 2022 at 20:08, Rob Herring <robh@kernel.org> wrote:
> On Tue, Jan 18, 2022 at 10:50:51PM +0100, Tobias Waldekranz wrote:
>> Update FMan binding documentation with the newly added workaround for
>> erratum A-009885.
>>
>> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
>> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>> ---
>> Documentation/devicetree/bindings/net/fsl-fman.txt | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt
>> index c00fb0d22c7b..020337f3c05f 100644
>> --- a/Documentation/devicetree/bindings/net/fsl-fman.txt
>> +++ b/Documentation/devicetree/bindings/net/fsl-fman.txt
>> @@ -410,6 +410,15 @@ PROPERTIES
>> The settings and programming routines for internal/external
>> MDIO are different. Must be included for internal MDIO.
>>
>> +- fsl,erratum-a009885
>
> Adding errata properties doesn't work because then you have to update
> your dtb to fix the issue where as if you use the compatible property
> (specific to the SoC) you can fix the issue with just a (stable) kernel
> update.
>
> Yes, I see we already have some, but doesn't mean we need more of them.
I agree. Unfortunately all users of the driver also use the same
compatible string, so there was no way I could think of that would not
involve rebuilding DTBs anyway. Given that situation, I chose to just
extend what was already there.
^ permalink raw reply
* [PATCH v4 00/11] media: atmel: atmel-isc: implement media controller
From: Eugen Hristev @ 2022-01-21 13:14 UTC (permalink / raw)
To: robh+dt, linux-media, devicetree, linux-kernel, linux-arm-kernel,
jacopo+renesas, hverkuil-cisco
Cc: nicolas.ferre, sakari.ailus, laurent.pinchart, Eugen Hristev
This series is the v4 series that attempts to support media controller in the
atmel ISC and XISC drivers.
The CSI2DC driver was accepted thus removed from the patch series, together with
other patches.
Important note: this series applies on top of current media_staging tree, as it
relies on previous patches in the series which were accepted.
Changes in v4:
-> as reviewed by Hans, added new patch to remove the 'stop' variable and reworked
one patch that was using it
-> as reviewed by Jacopo, reworked some parts of the media controller implementation
Thanks to everyone who reviewed my work !
Eugen
Previous cover letter from v3:
This series is the v3 of the series that attempts to support media controller
in the atmel ISC and XISC drivers.
This series also includes the csi2dc driver which was previously sent in a
separate series:
https://www.spinics.net/lists/linux-media/msg181042.html
https://www.spinics.net/lists/linux-media/msg181044.html
The driver now addresses comments received in latest v5 series from last year.
The series includes some minor changes and fixes that improve the isc common
code base, like removing the enum frameintervals VIDIOC, fixing bytesperline
for planar formats, etc.
Many thanks to folks from libcamera who helped a lot with understanding
how a media controller driver should behave.
Feedback is welcome !
Changes in v3:
- change in bindings, small fixes in csi2dc driver and conversion to mc
for the isc-base.
- removed some MAINTAINERS patches and used patterns in MAINTAINERS
Changes in v2:
- integrated many changes suggested by Jacopo in the review of the v1 series.
- add a few new patches
Eugen Hristev (11):
media: atmel: atmel-isc: replace 'stop' variable with vb2 calls
media: atmel: atmel-isc-base: use streaming status when queueing
buffers
media: atmel: atmel-isc: implement media controller
media: atmel: atmel-sama5d2-isc: fix wrong mask in YUYV format check
media: atmel: atmel-isc-base: use mutex to lock awb workqueue from
streaming
media: atmel: atmel-isc: compact the controller formats list
media: atmel: atmel-isc: change format propagation to subdev into only
verification
dt-bindings: media: microchip,xisc: add bus-width of 14
ARM: dts: at91: sama7g5: add nodes for video capture
ARM: configs: at91: sama7: add xisc and csi2dc
ARM: multi_v7_defconfig: add atmel video pipeline modules
.../bindings/media/microchip,xisc.yaml | 2 +-
arch/arm/boot/dts/sama7g5.dtsi | 49 ++
arch/arm/configs/multi_v7_defconfig | 3 +
arch/arm/configs/sama7_defconfig | 2 +
drivers/media/platform/atmel/Makefile | 2 +-
drivers/media/platform/atmel/atmel-isc-base.c | 455 +++++++++++-------
.../media/platform/atmel/atmel-isc-scaler.c | 250 ++++++++++
drivers/media/platform/atmel/atmel-isc.h | 43 +-
.../media/platform/atmel/atmel-sama5d2-isc.c | 67 ++-
.../media/platform/atmel/atmel-sama7g5-isc.c | 72 ++-
10 files changed, 694 insertions(+), 251 deletions(-)
create mode 100644 drivers/media/platform/atmel/atmel-isc-scaler.c
--
2.25.1
^ permalink raw reply
* [PATCH v4 01/11] media: atmel: atmel-isc: replace 'stop' variable with vb2 calls
From: Eugen Hristev @ 2022-01-21 13:14 UTC (permalink / raw)
To: robh+dt, linux-media, devicetree, linux-kernel, linux-arm-kernel,
jacopo+renesas, hverkuil-cisco
Cc: nicolas.ferre, sakari.ailus, laurent.pinchart, Eugen Hristev,
Hans Verkuil
In-Reply-To: <20220121131416.603972-1-eugen.hristev@microchip.com>
The stop variable is redundant as the state of the streaming can be obtained
by calling vb2_start_streaming_called(&isc->vb2_vidq) or by calling
vb2_is_busy(&isc->vb2_vidq).
Thus, remove the stop variable completely.
Suggested-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v4:
- new patch
drivers/media/platform/atmel/atmel-isc-base.c | 12 +++++-------
drivers/media/platform/atmel/atmel-isc.h | 2 --
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index db15770d5b88..9c62d0ae7887 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -362,7 +362,6 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
spin_lock_irqsave(&isc->dma_queue_lock, flags);
isc->sequence = 0;
- isc->stop = false;
reinit_completion(&isc->comp);
isc->cur_frm = list_first_entry(&isc->dma_queue,
@@ -403,8 +402,6 @@ static void isc_stop_streaming(struct vb2_queue *vq)
v4l2_ctrl_activate(isc->do_wb_ctrl, false);
- isc->stop = true;
-
/* Wait until the end of the current frame */
if (isc->cur_frm && !wait_for_completion_timeout(&isc->comp, 5 * HZ))
v4l2_err(&isc->v4l2_dev,
@@ -1029,7 +1026,7 @@ static int isc_s_fmt_vid_cap(struct file *file, void *priv,
{
struct isc_device *isc = video_drvdata(file);
- if (vb2_is_streaming(&isc->vb2_vidq))
+ if (vb2_is_busy(&isc->vb2_vidq))
return -EBUSY;
return isc_set_fmt(isc, f);
@@ -1236,7 +1233,8 @@ irqreturn_t isc_interrupt(int irq, void *dev_id)
isc->cur_frm = NULL;
}
- if (!list_empty(&isc->dma_queue) && !isc->stop) {
+ if (!list_empty(&isc->dma_queue) &&
+ vb2_start_streaming_called(&isc->vb2_vidq)) {
isc->cur_frm = list_first_entry(&isc->dma_queue,
struct isc_buffer, list);
list_del(&isc->cur_frm->list);
@@ -1244,7 +1242,7 @@ irqreturn_t isc_interrupt(int irq, void *dev_id)
isc_start_dma(isc);
}
- if (isc->stop)
+ if (!vb2_start_streaming_called(&isc->vb2_vidq))
complete(&isc->comp);
ret = IRQ_HANDLED;
@@ -1398,7 +1396,7 @@ static void isc_awb_work(struct work_struct *w)
int ret;
/* streaming is not active anymore */
- if (isc->stop)
+ if (!vb2_start_streaming_called(&isc->vb2_vidq))
return;
if (ctrls->hist_stat != HIST_ENABLED)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 07fa6dbf8460..5fbf52a9080b 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -201,7 +201,6 @@ struct isc_reg_offsets {
* @dma_queue: the queue for dma buffers
* @cur_frm: current isc frame/buffer
* @sequence: current frame number
- * @stop: true if isc is not streaming, false if streaming
* @comp: completion reference that signals frame completion
*
* @fmt: current v42l format
@@ -276,7 +275,6 @@ struct isc_device {
struct list_head dma_queue;
struct isc_buffer *cur_frm;
unsigned int sequence;
- bool stop;
struct completion comp;
struct v4l2_format fmt;
--
2.25.1
^ permalink raw reply related
* [PATCH v4 02/11] media: atmel: atmel-isc-base: use streaming status when queueing buffers
From: Eugen Hristev @ 2022-01-21 13:14 UTC (permalink / raw)
To: robh+dt, linux-media, devicetree, linux-kernel, linux-arm-kernel,
jacopo+renesas, hverkuil-cisco
Cc: nicolas.ferre, sakari.ailus, laurent.pinchart, Eugen Hristev
In-Reply-To: <20220121131416.603972-1-eugen.hristev@microchip.com>
During experiments with libcamera, it looks like vb2_is_streaming returns
true before our start streaming is called.
Order of operations is streamon -> queue -> start_streaming
ISC would have started the DMA immediately when a buffer is being added
to the vbqueue if the queue is streaming.
It is more safe to start the DMA after the start streaming of the driver is
called.
Thus, even if vb2queue is streaming, add the buffer to the dma queue of the
driver instead of actually starting the DMA process, if the start streaming
has not been called yet.
Tho achieve this, we have to use vb2_start_streaming_called instead of
vb2_is_streaming.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v4:
- changed to using vb2_start_streaming_called instead of stop variable
drivers/media/platform/atmel/atmel-isc-base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 9c62d0ae7887..6b0005987a17 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -439,7 +439,7 @@ static void isc_buffer_queue(struct vb2_buffer *vb)
spin_lock_irqsave(&isc->dma_queue_lock, flags);
if (!isc->cur_frm && list_empty(&isc->dma_queue) &&
- vb2_is_streaming(vb->vb2_queue)) {
+ vb2_start_streaming_called(vb->vb2_queue)) {
isc->cur_frm = buf;
isc_start_dma(isc);
} else
@@ -1532,7 +1532,7 @@ static int isc_s_awb_ctrl(struct v4l2_ctrl *ctrl)
isc_update_awb_ctrls(isc);
- if (vb2_is_streaming(&isc->vb2_vidq)) {
+ if (vb2_start_streaming_called(&isc->vb2_vidq)) {
/*
* If we are streaming, we can update profile to
* have the new settings in place.
@@ -1549,7 +1549,7 @@ static int isc_s_awb_ctrl(struct v4l2_ctrl *ctrl)
/* if we have autowhitebalance on, start histogram procedure */
if (ctrls->awb == ISC_WB_AUTO &&
- vb2_is_streaming(&isc->vb2_vidq) &&
+ vb2_start_streaming_called(&isc->vb2_vidq) &&
ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code))
isc_set_histogram(isc, true);
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox