* [PATCH v7 0/7] Add PCIe support for Qualcomm IPQ5332
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
Patch series adds support for enabling the PCIe controller and
UNIPHY found on Qualcomm IPQ5332 platform. PCIe0 is Gen3 X1 and
PCIe1 is Gen3 X2 are added.
This series combines [1] and [2]. [1] introduces IPQ5018 PCIe
support and [2] depends on [1] to introduce IPQ5332 PCIe support.
Since the community was interested in [2] (please see [3]), tried
to revive IPQ5332's PCIe support with v2 of this patch series.
v2 of this series pulled in the phy driver from [1] tried to
address comments/feedback given in both [1] and [2].
1. Enable IPQ5018 PCI support (Nitheesh Sekar) - https://lore.kernel.org/all/20231003120846.28626-1-quic_nsekar@quicinc.com/
2. Add PCIe support for Qualcomm IPQ5332 (Praveenkumar I) - https://lore.kernel.org/linux-arm-msm/20231214062847.2215542-1-quic_ipkumar@quicinc.com/
3. Community interest - https://lore.kernel.org/linux-arm-msm/20240310132915.GE3390@thinkpad/
v7: phy bindings:
* Include data type definition to 'num-lanes'
controller bindings:
* Split the ipq9574 and ipq5332 changes into separate patches
dtsi:
* Add root port definitions
v6: phy bindings:
* Fix num-lanes definition
phy driver:
* Fix num-lanes handling in probe to use generally followed pattern
controller bindings:
* Give more info in commit log
dtsi:
* Add assigned-clocks & assigned-clock-rates to controller nodes
* Add num-lanes to pcie0_phy
v5: phy bindings:
* Drop '3x1' & '3x2' from compatible string
* Use 'num-lanes' to differentiate instead of '3x1' or '3x2'
in compatible string
* Describe clocks and resets instead of just maxItems
phy driver:
* Get num-lanes from DTS
* Drop compatible specific init data as there is only one
compatible string
controller bindings:
* Re-arrange 5332 and 9574 compatibles to handle fallback usage in dts
dtsi:
* Add 'num-lanes' to "pcie1_phy: phy@4b1000"
* Make ipq5332 as main and ipq9574 as fallback compatible
* Sort controller nodes per address
misc:
Add R-B tag from Konrad to dts and dtsi patches
v4: * phy bindings - Create ipq5332 compatible instead of reusing ipq9574 for bindings
* phy bindings - Remove reset-names as the resets are handled with bulk APIs
* phy bindings - Fix order in the 'required' section
* phy bindings - Remove clock-output-names
* dtsi - Add missing reset for pcie1_phy
* dtsi - Convert 'reg-names' to a vertical list
* dts - Fix nodes sort order
* dts - Use property-n followed by property-names
v3: * Update the cover letter with the sources of the patches
* Rename the dt-bindings yaml file similar to other phys
* Drop ipq5332 specific pcie controllor bindings and reuse
ipq9574 pcie controller bindings for ipq5332
* Please see patches for specific changes
* Set GPL license for phy-qcom-uniphy-pcie-28lp.c
v2: Address review comments from V1
Drop the 'required clocks' change that would break ABI (in dt-binding, dts, gcc-ipq5332.c)
Include phy driver from the dependent series
v1: https://lore.kernel.org/linux-arm-msm/20231214062847.2215542-1-quic_ipkumar@quicinc.com/
Nitheesh Sekar (2):
dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy
phy: qcom: Introduce PCIe UNIPHY 28LP driver
Praveenkumar I (2):
arm64: dts: qcom: ipq5332: Add PCIe related nodes
arm64: dts: qcom: ipq5332-rdp441: Enable PCIe phys and controllers
Varadarajan Narayanan (3):
dt-bindings: PCI: qcom: Use sdx55 reg description for ipq9574
arm64: dts: qcom: ipq9574: Reorder reg and reg-names
dt-bindings: PCI: qcom: Document the IPQ5332 PCIe controller
.../devicetree/bindings/pci/qcom,pcie.yaml | 15 +-
.../phy/qcom,ipq5332-uniphy-pcie-phy.yaml | 76 +++++
arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts | 76 +++++
arch/arm64/boot/dts/qcom/ipq5332.dtsi | 268 +++++++++++++++-
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 52 ++--
drivers/phy/qualcomm/Kconfig | 12 +
drivers/phy/qualcomm/Makefile | 1 +
.../phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c | 286 ++++++++++++++++++
8 files changed, 763 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml
create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
base-commit: 37136bf5c3a6f6b686d74f41837a6406bec6b7bc
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v7 1/7] dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
In-Reply-To: <20250122063411.3503097-1-quic_varada@quicinc.com>
From: Nitheesh Sekar <quic_nsekar@quicinc.com>
Document the Qualcomm UNIPHY PCIe 28LP present in IPQ5332.
Signed-off-by: Nitheesh Sekar <quic_nsekar@quicinc.com>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: * Add data type definition to 'num-lanes'
v6: * Fix num-lanes definition
* Make it mandatory
v5: * Drop '3x1' & '3x2' from compatible string
* Use 'num-lanes' to differentiate instead of '3x1' or '3x2'
in compatible string
* Describe clocks and resets instead of just maxItems
v4: Remove reset-names as the resets are not used individually
Remove clock-output-names as its usage is removed from driver
Fix order in the 'required' section
v3: Fix compatible string to be similar to other phys and rename file accordingly
Fix clocks minItems -> maxItems
Change one of the maintainer from Sricharan to Varadarajan
v2: Rename the file to match the compatible
Drop 'driver' from title
Dropped 'clock-names'
Fixed 'reset-names'
---
.../phy/qcom,ipq5332-uniphy-pcie-phy.yaml | 76 +++++++++++++++++++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml
new file mode 100644
index 000000000000..e39168d55d23
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,ipq5332-uniphy-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm UNIPHY PCIe 28LP PHY
+
+maintainers:
+ - Nitheesh Sekar <quic_nsekar@quicinc.com>
+ - Varadarajan Narayanan <quic_varada@quicinc.com>
+
+description:
+ PCIe and USB combo PHY found in Qualcomm IPQ5332 SoC
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5332-uniphy-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: pcie pipe clock
+ - description: pcie ahb clock
+
+ resets:
+ items:
+ - description: phy reset
+ - description: ahb reset
+ - description: cfg reset
+
+ "#phy-cells":
+ const: 0
+
+ "#clock-cells":
+ const: 0
+
+ num-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - "#phy-cells"
+ - "#clock-cells"
+ - num-lanes
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq5332-gcc.h>
+
+ pcie0_phy: phy@4b0000 {
+ compatible = "qcom,ipq5332-uniphy-pcie-phy";
+ reg = <0x004b0000 0x800>;
+
+ clocks = <&gcc GCC_PCIE3X1_0_PIPE_CLK>,
+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK>;
+
+ resets = <&gcc GCC_PCIE3X1_0_PHY_BCR>,
+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK_ARES>,
+ <&gcc GCC_PCIE3X1_0_PHY_PHY_BCR>;
+
+ #clock-cells = <0>;
+
+ #phy-cells = <0>;
+
+ num-lanes = <1>;
+ };
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 2/7] phy: qcom: Introduce PCIe UNIPHY 28LP driver
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
In-Reply-To: <20250122063411.3503097-1-quic_varada@quicinc.com>
From: Nitheesh Sekar <quic_nsekar@quicinc.com>
Add Qualcomm PCIe UNIPHY 28LP driver support present
in Qualcomm IPQ5332 SoC and the phy init sequence.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Nitheesh Sekar <quic_nsekar@quicinc.com>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v6: Use generally followed pattern for getting num-lanes from DT
v5: * Use 'num-lanes' to differentiate instead of '3x1' or '3x2'
in compatible string
* Drop compatible specific init data as there is only one
compatible string
* Fix header file order
v4: Fix uppercase hex digit
Use phy->id for pipe clock source
v3: Added 'Reviewed-by: Dmitry Baryshkov' and made following updates
s/unsigned int/u32/g
Fix 'lane_offset' comments
Fix #define tab -> space
Fix mixed case hex numbers
Fix licensing & owner
Change for-loop pointer to use [] instead of ->
Use 'less than max' instead of 'not equal to max' in termination condition
Smatch and Coccinelle passed
v2: Drop IPQ5018 related code and data
Use uniform prefix for struct names
Place "}, {", on the same line
In qcom_uniphy_pcie_init(), use for-loop instead of while
Swap reset and clock disable order in qcom_uniphy_pcie_power_off
Add reset assert to qcom_uniphy_pcie_power_on's error path
Use macros for usleep duration
Inlined qcom_uniphy_pcie_get_resources & use devm_platform_get_and_ioremap_resource
Drop 'clock-output-names' from phy_pipe_clk_register
---
drivers/phy/qualcomm/Kconfig | 12 +
drivers/phy/qualcomm/Makefile | 1 +
.../phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c | 286 ++++++++++++++++++
3 files changed, 299 insertions(+)
create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 846f8c99547f..a6b71fda1b9c 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -154,6 +154,18 @@ config PHY_QCOM_M31_USB
management. This driver is required even for peripheral only or
host only mode configurations.
+config PHY_QCOM_UNIPHY_PCIE_28LP
+ bool "PCIE UNIPHY 28LP PHY driver"
+ depends on ARCH_QCOM
+ depends on HAS_IOMEM
+ depends on OF
+ select GENERIC_PHY
+ help
+ Enable this to support the PCIe UNIPHY 28LP phy transceiver that
+ is used with PCIe controllers on Qualcomm IPQ5332 chips. It
+ handles PHY initialization, clock management required after
+ resetting the hardware and power management.
+
config PHY_QCOM_USB_HS
tristate "Qualcomm USB HS PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index eb60e950ad53..42038bc30974 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_QCOM_QMP_USB_LEGACY) += phy-qcom-qmp-usb-legacy.o
obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
obj-$(CONFIG_PHY_QCOM_SNPS_EUSB2) += phy-qcom-snps-eusb2.o
obj-$(CONFIG_PHY_QCOM_EUSB2_REPEATER) += phy-qcom-eusb2-repeater.o
+obj-$(CONFIG_PHY_QCOM_UNIPHY_PCIE_28LP) += phy-qcom-uniphy-pcie-28lp.o
obj-$(CONFIG_PHY_QCOM_USB_HS) += phy-qcom-usb-hs.o
obj-$(CONFIG_PHY_QCOM_USB_HSIC) += phy-qcom-usb-hsic.o
obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c b/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
new file mode 100644
index 000000000000..d44dc769af6f
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2025, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+#define RST_ASSERT_DELAY_MIN_US 100
+#define RST_ASSERT_DELAY_MAX_US 150
+#define PIPE_CLK_DELAY_MIN_US 5000
+#define PIPE_CLK_DELAY_MAX_US 5100
+#define CLK_EN_DELAY_MIN_US 30
+#define CLK_EN_DELAY_MAX_US 50
+#define CDR_CTRL_REG_1 0x80
+#define CDR_CTRL_REG_2 0x84
+#define CDR_CTRL_REG_3 0x88
+#define CDR_CTRL_REG_4 0x8c
+#define CDR_CTRL_REG_5 0x90
+#define CDR_CTRL_REG_6 0x94
+#define CDR_CTRL_REG_7 0x98
+#define SSCG_CTRL_REG_1 0x9c
+#define SSCG_CTRL_REG_2 0xa0
+#define SSCG_CTRL_REG_3 0xa4
+#define SSCG_CTRL_REG_4 0xa8
+#define SSCG_CTRL_REG_5 0xac
+#define SSCG_CTRL_REG_6 0xb0
+#define PCS_INTERNAL_CONTROL_2 0x2d8
+
+#define PHY_CFG_PLLCFG 0x220
+#define PHY_CFG_EIOS_DTCT_REG 0x3e4
+#define PHY_CFG_GEN3_ALIGN_HOLDOFF_TIME 0x3e8
+
+#define PHY_MODE_FIXED 0x1
+
+enum qcom_uniphy_pcie_type {
+ PHY_TYPE_PCIE = 1,
+ PHY_TYPE_PCIE_GEN2,
+ PHY_TYPE_PCIE_GEN3,
+};
+
+struct qcom_uniphy_pcie_regs {
+ u32 offset;
+ u32 val;
+};
+
+struct qcom_uniphy_pcie_data {
+ int lane_offset; /* offset between the lane register bases */
+ u32 phy_type;
+ const struct qcom_uniphy_pcie_regs *init_seq;
+ u32 init_seq_num;
+ u32 pipe_clk_rate;
+};
+
+struct qcom_uniphy_pcie {
+ struct phy phy;
+ struct device *dev;
+ const struct qcom_uniphy_pcie_data *data;
+ struct clk_bulk_data *clks;
+ int num_clks;
+ struct reset_control *resets;
+ void __iomem *base;
+ int lanes;
+};
+
+#define phy_to_dw_phy(x) container_of((x), struct qca_uni_pcie_phy, phy)
+
+static const struct qcom_uniphy_pcie_regs ipq5332_regs[] = {
+ {
+ .offset = PHY_CFG_PLLCFG,
+ .val = 0x30,
+ }, {
+ .offset = PHY_CFG_EIOS_DTCT_REG,
+ .val = 0x53ef,
+ }, {
+ .offset = PHY_CFG_GEN3_ALIGN_HOLDOFF_TIME,
+ .val = 0xcf,
+ },
+};
+
+static const struct qcom_uniphy_pcie_data ipq5332_data = {
+ .lane_offset = 0x800,
+ .phy_type = PHY_TYPE_PCIE_GEN3,
+ .init_seq = ipq5332_regs,
+ .init_seq_num = ARRAY_SIZE(ipq5332_regs),
+ .pipe_clk_rate = 250000000,
+};
+
+static void qcom_uniphy_pcie_init(struct qcom_uniphy_pcie *phy)
+{
+ const struct qcom_uniphy_pcie_data *data = phy->data;
+ const struct qcom_uniphy_pcie_regs *init_seq;
+ void __iomem *base = phy->base;
+ int lane, i;
+
+ for (lane = 0; lane < phy->lanes; lane++) {
+ init_seq = data->init_seq;
+
+ for (i = 0; i < data->init_seq_num; i++)
+ writel(init_seq[i].val, base + init_seq[i].offset);
+
+ base += data->lane_offset;
+ }
+}
+
+static int qcom_uniphy_pcie_power_off(struct phy *x)
+{
+ struct qcom_uniphy_pcie *phy = phy_get_drvdata(x);
+
+ clk_bulk_disable_unprepare(phy->num_clks, phy->clks);
+
+ return reset_control_assert(phy->resets);
+}
+
+static int qcom_uniphy_pcie_power_on(struct phy *x)
+{
+ struct qcom_uniphy_pcie *phy = phy_get_drvdata(x);
+ int ret;
+
+ ret = reset_control_assert(phy->resets);
+ if (ret) {
+ dev_err(phy->dev, "reset assert failed (%d)\n", ret);
+ return ret;
+ }
+
+ usleep_range(RST_ASSERT_DELAY_MIN_US, RST_ASSERT_DELAY_MAX_US);
+
+ ret = reset_control_deassert(phy->resets);
+ if (ret) {
+ dev_err(phy->dev, "reset deassert failed (%d)\n", ret);
+ return ret;
+ }
+
+ usleep_range(PIPE_CLK_DELAY_MIN_US, PIPE_CLK_DELAY_MAX_US);
+
+ ret = clk_bulk_prepare_enable(phy->num_clks, phy->clks);
+ if (ret) {
+ dev_err(phy->dev, "clk prepare and enable failed %d\n", ret);
+ return ret;
+ }
+
+ usleep_range(CLK_EN_DELAY_MIN_US, CLK_EN_DELAY_MAX_US);
+
+ qcom_uniphy_pcie_init(phy);
+ return 0;
+}
+
+static inline int qcom_uniphy_pcie_get_resources(struct platform_device *pdev,
+ struct qcom_uniphy_pcie *phy)
+{
+ struct resource *res;
+
+ phy->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+ if (IS_ERR(phy->base))
+ return PTR_ERR(phy->base);
+
+ phy->num_clks = devm_clk_bulk_get_all(phy->dev, &phy->clks);
+ if (phy->num_clks < 0)
+ return phy->num_clks;
+
+ phy->resets = devm_reset_control_array_get_exclusive(phy->dev);
+ if (IS_ERR(phy->resets))
+ return PTR_ERR(phy->resets);
+
+ return 0;
+}
+
+/*
+ * Register a fixed rate pipe clock.
+ *
+ * The <s>_pipe_clksrc generated by PHY goes to the GCC that gate
+ * controls it. The <s>_pipe_clk coming out of the GCC is requested
+ * by the PHY driver for its operations.
+ * We register the <s>_pipe_clksrc here. The gcc driver takes care
+ * of assigning this <s>_pipe_clksrc as parent to <s>_pipe_clk.
+ * Below picture shows this relationship.
+ *
+ * +---------------+
+ * | PHY block |<<---------------------------------------+
+ * | | |
+ * | +-------+ | +-----+ |
+ * I/P---^-->| PLL |---^--->pipe_clksrc--->| GCC |--->pipe_clk---+
+ * clk | +-------+ | +-----+
+ * +---------------+
+ */
+static inline int phy_pipe_clk_register(struct qcom_uniphy_pcie *phy, int id)
+{
+ const struct qcom_uniphy_pcie_data *data = phy->data;
+ struct clk_hw *hw;
+ char name[64];
+
+ snprintf(name, sizeof(name), "phy%d_pipe_clk_src", id);
+ hw = devm_clk_hw_register_fixed_rate(phy->dev, name, NULL, 0,
+ data->pipe_clk_rate);
+ if (IS_ERR(hw))
+ return dev_err_probe(phy->dev, PTR_ERR(hw),
+ "Unable to register %s\n", name);
+
+ return devm_of_clk_add_hw_provider(phy->dev, of_clk_hw_simple_get, hw);
+}
+
+static const struct of_device_id qcom_uniphy_pcie_id_table[] = {
+ {
+ .compatible = "qcom,ipq5332-uniphy-pcie-phy",
+ .data = &ipq5332_data,
+ }, {
+ /* Sentinel */
+ },
+};
+MODULE_DEVICE_TABLE(of, qcom_uniphy_pcie_id_table);
+
+static const struct phy_ops pcie_ops = {
+ .power_on = qcom_uniphy_pcie_power_on,
+ .power_off = qcom_uniphy_pcie_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int qcom_uniphy_pcie_probe(struct platform_device *pdev)
+{
+ struct phy_provider *phy_provider;
+ struct device *dev = &pdev->dev;
+ struct qcom_uniphy_pcie *phy;
+ struct phy *generic_phy;
+ int ret;
+
+ phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, phy);
+ phy->dev = &pdev->dev;
+
+ phy->data = of_device_get_match_data(dev);
+ if (!phy->data)
+ return -EINVAL;
+
+ phy->lanes = 1;
+ if (of_property_read_u32(dev_of_node(dev), "num-lanes", &phy->lanes))
+ dev_info(dev, "Not able to get num-lanes. Assuming 1\n");
+
+ ret = qcom_uniphy_pcie_get_resources(pdev, phy);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to get resources: %d\n", ret);
+
+ generic_phy = devm_phy_create(phy->dev, NULL, &pcie_ops);
+ if (IS_ERR(generic_phy))
+ return PTR_ERR(generic_phy);
+
+ phy_set_drvdata(generic_phy, phy);
+
+ ret = phy_pipe_clk_register(phy, generic_phy->id);
+ if (ret)
+ dev_err(&pdev->dev, "failed to register phy pipe clk\n");
+
+ phy_provider = devm_of_phy_provider_register(phy->dev,
+ of_phy_simple_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ return 0;
+}
+
+static struct platform_driver qcom_uniphy_pcie_driver = {
+ .probe = qcom_uniphy_pcie_probe,
+ .driver = {
+ .name = "qcom-uniphy-pcie",
+ .of_match_table = qcom_uniphy_pcie_id_table,
+ },
+};
+
+module_platform_driver(qcom_uniphy_pcie_driver);
+
+MODULE_DESCRIPTION("PCIE QCOM UNIPHY driver");
+MODULE_LICENSE("GPL");
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 3/7] dt-bindings: PCI: qcom: Use sdx55 reg description for ipq9574
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
In-Reply-To: <20250122063411.3503097-1-quic_varada@quicinc.com>
All DT entries except "reg" is similar between ipq5332 and
ipq9574. ipq9574 has 5 registers while ipq5332 has 6. MHI is the
additional (i.e. sixth entry). Since this matches with the
sdx55's "reg" definition which allows for 5 or 6 registers,
combine ipq9574 with sdx55.
This change is to prepare ipq9574 to be used as ipq5332's
fallback compatible.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
Documentation/devicetree/bindings/pci/qcom,pcie.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index bd87f6b49d68..413c6b76c26c 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -165,7 +165,6 @@ allOf:
enum:
- qcom,pcie-ipq6018
- qcom,pcie-ipq8074-gen3
- - qcom,pcie-ipq9574
then:
properties:
reg:
@@ -206,6 +205,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pcie-ipq9574
- qcom,pcie-sdx55
then:
properties:
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 4/7] arm64: dts: qcom: ipq9574: Reorder reg and reg-names
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
In-Reply-To: <20250122063411.3503097-1-quic_varada@quicinc.com>
The 'reg' & 'reg-names' constraints used in the bindings and dtsi
are different resulting in dt_bindings_check errors. Re-order
them to address following errors.
arch/arm64/boot/dts/qcom/ipq9574-rdp449.dtb: pcie@20000000: reg-names:0: 'parf' was expected
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 52 +++++++++++++++++----------
1 file changed, 34 insertions(+), 18 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
index 942290028972..d27c55c7f6e4 100644
--- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
@@ -876,12 +876,16 @@ frame@b128000 {
pcie1: pcie@10000000 {
compatible = "qcom,pcie-ipq9574";
- reg = <0x10000000 0xf1d>,
- <0x10000f20 0xa8>,
- <0x10001000 0x1000>,
- <0x000f8000 0x4000>,
- <0x10100000 0x1000>;
- reg-names = "dbi", "elbi", "atu", "parf", "config";
+ reg = <0x000f8000 0x4000>,
+ <0x10000000 0xf1d>,
+ <0x10000f20 0xa8>,
+ <0x10001000 0x1000>,
+ <0x10100000 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config";
device_type = "pci";
linux,pci-domain = <1>;
bus-range = <0x00 0xff>;
@@ -956,12 +960,16 @@ pcie1: pcie@10000000 {
pcie3: pcie@18000000 {
compatible = "qcom,pcie-ipq9574";
- reg = <0x18000000 0xf1d>,
- <0x18000f20 0xa8>,
- <0x18001000 0x1000>,
- <0x000f0000 0x4000>,
- <0x18100000 0x1000>;
- reg-names = "dbi", "elbi", "atu", "parf", "config";
+ reg = <0x000f0000 0x4000>,
+ <0x18000000 0xf1d>,
+ <0x18000f20 0xa8>,
+ <0x18001000 0x1000>,
+ <0x18100000 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config";
device_type = "pci";
linux,pci-domain = <3>;
bus-range = <0x00 0xff>;
@@ -1036,12 +1044,16 @@ pcie3: pcie@18000000 {
pcie2: pcie@20000000 {
compatible = "qcom,pcie-ipq9574";
- reg = <0x20000000 0xf1d>,
+ reg = <0x00088000 0x4000>,
+ <0x20000000 0xf1d>,
<0x20000f20 0xa8>,
<0x20001000 0x1000>,
- <0x00088000 0x4000>,
<0x20100000 0x1000>;
- reg-names = "dbi", "elbi", "atu", "parf", "config";
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config";
device_type = "pci";
linux,pci-domain = <2>;
bus-range = <0x00 0xff>;
@@ -1116,12 +1128,16 @@ pcie2: pcie@20000000 {
pcie0: pci@28000000 {
compatible = "qcom,pcie-ipq9574";
- reg = <0x28000000 0xf1d>,
+ reg = <0x00080000 0x4000>,
+ <0x28000000 0xf1d>,
<0x28000f20 0xa8>,
<0x28001000 0x1000>,
- <0x00080000 0x4000>,
<0x28100000 0x1000>;
- reg-names = "dbi", "elbi", "atu", "parf", "config";
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config";
device_type = "pci";
linux,pci-domain = <0>;
bus-range = <0x00 0xff>;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 5/7] dt-bindings: PCI: qcom: Document the IPQ5332 PCIe controller
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
In-Reply-To: <20250122063411.3503097-1-quic_varada@quicinc.com>
Document the PCIe controller on IPQ5332 platform. IPQ5332 will
use IPQ9574 as the fall back compatible.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: Moved ipq9574 related changes to a separate patch
Add 'global' interrupt
v6: Commit message update only. Add info regarding the moving of
ipq9574 from 5 "reg" definition to 5 or 6 reg definition.
v5: Re-arrange 5332 and 9574 compatibles to handle fallback usage in dts
v4: * v3 reused ipq9574 bindings for ipq5332. Instead add one for ipq5332
* DTS uses ipq9574 compatible as fallback. Hence move ipq9574 to be able
to use the 'reg' section for both ipq5332 and ipq9574. Else, dtbs_check
and dt_binding_check flag errors.
---
.../devicetree/bindings/pci/qcom,pcie.yaml | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index 413c6b76c26c..ead97286fd41 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -34,6 +34,10 @@ properties:
- items:
- const: qcom,pcie-msm8998
- const: qcom,pcie-msm8996
+ - items:
+ - enum:
+ - qcom,pcie-ipq5332
+ - const: qcom,pcie-ipq9574
reg:
minItems: 4
@@ -45,11 +49,11 @@ properties:
interrupts:
minItems: 1
- maxItems: 8
+ maxItems: 9
interrupt-names:
minItems: 1
- maxItems: 8
+ maxItems: 9
iommu-map:
minItems: 1
@@ -205,6 +209,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pcie-ipq5332
- qcom,pcie-ipq9574
- qcom,pcie-sdx55
then:
@@ -407,6 +412,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pcie-ipq5332
- qcom,pcie-ipq9574
then:
properties:
@@ -439,6 +445,7 @@ allOf:
interrupts:
minItems: 8
interrupt-names:
+ minItems: 8
items:
- const: msi0
- const: msi1
@@ -448,6 +455,7 @@ allOf:
- const: msi5
- const: msi6
- const: msi7
+ - const: global
- if:
properties:
@@ -555,6 +563,7 @@ allOf:
enum:
- qcom,pcie-apq8064
- qcom,pcie-ipq4019
+ - qcom,pcie-ipq5332
- qcom,pcie-ipq8064
- qcom,pcie-ipq8064v2
- qcom,pcie-ipq8074
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 6/7] arm64: dts: qcom: ipq5332: Add PCIe related nodes
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
Cc: Praveenkumar I, Konrad Dybcio
In-Reply-To: <20250122063411.3503097-1-quic_varada@quicinc.com>
From: Praveenkumar I <quic_ipkumar@quicinc.com>
Add phy and controller nodes for pcie0_x1 and pcie1_x2.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: * Fix IO 'ranges' entry
* Add root port definitions
* Not adding 'dma-coherent' as the controller doesn't have that support
* Remove 'bus-range' as it has default values
* Group root complex related entries and root port related entries
separately
v6: * Add 'num-lanes' to "pcie0_phy: phy@4b0000"
* Earlier, some related clock rates were set in U-Boot. In
recent versions of U-Boot this has been removed resulting
in the phy link not coming up. To remove boot loader
dependency add assigned-clocks and assigned-clock-rates to
the controller nodes.
* Not sure if 'Reviewed-by' should be dropped.
v5: Add 'num-lanes' to "pcie1_phy: phy@4b1000"
Make ipq5332 as main and ipq9574 as fallback compatible
Move controller nodes per address
Having Konrad's Reviewed-By
v4: Remove 'reset-names' as driver uses bulk APIs
Remove 'clock-output-names' as driver uses bulk APIs
Add missing reset for pcie1_phy
Convert 'reg-names' to a vertical list
Move 'msi-map' before interrupts
v3: Fix compatible string for phy nodes
Use ipq9574 as backup compatible instead of new compatible for ipq5332
Fix mixed case hex addresses
Add "mhi" space
Removed unnecessary comments and stray blank lines
v2: Fix nodes' location per address
---
arch/arm64/boot/dts/qcom/ipq5332.dtsi | 268 +++++++++++++++++++++++++-
1 file changed, 266 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
index ca3da95730bd..e5c920c21974 100644
--- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
@@ -186,6 +186,46 @@ rng: rng@e3000 {
clock-names = "core";
};
+ pcie0_phy: phy@4b0000 {
+ compatible = "qcom,ipq5332-uniphy-pcie-phy";
+ reg = <0x004b0000 0x800>;
+
+ clocks = <&gcc GCC_PCIE3X1_0_PIPE_CLK>,
+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK>;
+
+ resets = <&gcc GCC_PCIE3X1_0_PHY_BCR>,
+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK_ARES>,
+ <&gcc GCC_PCIE3X1_0_PHY_PHY_BCR>;
+
+ #clock-cells = <0>;
+
+ #phy-cells = <0>;
+
+ num-lanes = <1>;
+
+ status = "disabled";
+ };
+
+ pcie1_phy: phy@4b1000 {
+ compatible = "qcom,ipq5332-uniphy-pcie-phy";
+ reg = <0x004b1000 0x1000>;
+
+ clocks = <&gcc GCC_PCIE3X2_PIPE_CLK>,
+ <&gcc GCC_PCIE3X2_PHY_AHB_CLK>;
+
+ resets = <&gcc GCC_PCIE3X2_PHY_BCR>,
+ <&gcc GCC_PCIE3X2_PHY_AHB_CLK_ARES>,
+ <&gcc GCC_PCIE3X2PHY_PHY_BCR>;
+
+ #clock-cells = <0>;
+
+ #phy-cells = <0>;
+
+ num-lanes = <2>;
+
+ status = "disabled";
+ };
+
tlmm: pinctrl@1000000 {
compatible = "qcom,ipq5332-tlmm";
reg = <0x01000000 0x300000>;
@@ -212,8 +252,8 @@ gcc: clock-controller@1800000 {
#interconnect-cells = <1>;
clocks = <&xo_board>,
<&sleep_clk>,
- <0>,
- <0>,
+ <&pcie1_phy>,
+ <&pcie0_phy>,
<0>;
};
@@ -479,6 +519,230 @@ frame@b128000 {
status = "disabled";
};
};
+
+ pcie1: pcie@18000000 {
+ compatible = "qcom,pcie-ipq5332", "qcom,pcie-ipq9574";
+ reg = <0x00088000 0x3000>,
+ <0x18000000 0xf1d>,
+ <0x18000f20 0xa8>,
+ <0x18001000 0x1000>,
+ <0x18100000 0x1000>,
+ <0x0008b000 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config",
+ "mhi";
+ device_type = "pci";
+ linux,pci-domain = <1>;
+ num-lanes = <2>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x01000000 0x0 0x00000000 0x18200000 0x0 0x00100000>,
+ <0x02000000 0x0 0x18300000 0x18300000 0x0 0x07d00000>;
+
+ msi-map = <0x0 &v2m0 0x0 0xffd>;
+
+ interrupts = <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 411 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 412 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 413 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 414 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 415 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_PCIE3X2_AXI_M_CLK>,
+ <&gcc GCC_PCIE3X2_AXI_S_CLK>,
+ <&gcc GCC_PCIE3X2_AXI_S_BRIDGE_CLK>,
+ <&gcc GCC_PCIE3X2_RCHG_CLK>,
+ <&gcc GCC_PCIE3X2_AHB_CLK>,
+ <&gcc GCC_PCIE3X2_AUX_CLK>;
+ clock-names = "axi_m",
+ "axi_s",
+ "axi_bridge",
+ "rchng",
+ "ahb",
+ "aux";
+
+ assigned-clocks = <&gcc GCC_PCIE3X2_AUX_CLK>,
+ <&gcc GCC_PCIE3X2_AXI_M_CLK>,
+ <&gcc GCC_PCIE3X2_AXI_S_BRIDGE_CLK>,
+ <&gcc GCC_PCIE3X2_AXI_S_CLK>,
+ <&gcc GCC_PCIE3X2_RCHG_CLK>;
+
+ assigned-clock-rates = <2000000>,
+ <266666666>,
+ <240000000>,
+ <240000000>,
+ <100000000>;
+
+ resets = <&gcc GCC_PCIE3X2_PIPE_ARES>,
+ <&gcc GCC_PCIE3X2_CORE_STICKY_ARES>,
+ <&gcc GCC_PCIE3X2_AXI_S_STICKY_ARES>,
+ <&gcc GCC_PCIE3X2_AXI_S_CLK_ARES>,
+ <&gcc GCC_PCIE3X2_AXI_M_STICKY_ARES>,
+ <&gcc GCC_PCIE3X2_AXI_M_CLK_ARES>,
+ <&gcc GCC_PCIE3X2_AUX_CLK_ARES>,
+ <&gcc GCC_PCIE3X2_AHB_CLK_ARES>;
+ reset-names = "pipe",
+ "sticky",
+ "axi_s_sticky",
+ "axi_s",
+ "axi_m_sticky",
+ "axi_m",
+ "aux",
+ "ahb";
+
+ phys = <&pcie1_phy>;
+ phy-names = "pciephy";
+
+ interconnects = <&gcc MASTER_SNOC_PCIE3_2_M &gcc SLAVE_SNOC_PCIE3_2_M>,
+ <&gcc MASTER_ANOC_PCIE3_2_S &gcc SLAVE_ANOC_PCIE3_2_S>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ status = "disabled";
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
+
+ pcie0: pcie@20000000 {
+ compatible = "qcom,pcie-ipq5332", "qcom,pcie-ipq9574";
+ reg = <0x00080000 0x3000>,
+ <0x20000000 0xf1d>,
+ <0x20000f20 0xa8>,
+ <0x20001000 0x1000>,
+ <0x20100000 0x1000>,
+ <0x00083000 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config",
+ "mhi";
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x01000000 0x0 0x00000000 0x20200000 0x0 0x00100000>,
+ <0x02000000 0x0 0x20300000 0x20300000 0x0 0x0fd00000>;
+
+ msi-map = <0x0 &v2m0 0x0 0xffd>;
+
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 35 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 36 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 37 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 38 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_PCIE3X1_0_AXI_M_CLK>,
+ <&gcc GCC_PCIE3X1_0_AXI_S_CLK>,
+ <&gcc GCC_PCIE3X1_0_AXI_S_BRIDGE_CLK>,
+ <&gcc GCC_PCIE3X1_0_RCHG_CLK>,
+ <&gcc GCC_PCIE3X1_0_AHB_CLK>,
+ <&gcc GCC_PCIE3X1_0_AUX_CLK>;
+ clock-names = "axi_m",
+ "axi_s",
+ "axi_bridge",
+ "rchng",
+ "ahb",
+ "aux";
+
+ assigned-clocks = <&gcc GCC_PCIE3X1_0_AUX_CLK>,
+ <&gcc GCC_PCIE3X1_0_AXI_M_CLK>,
+ <&gcc GCC_PCIE3X1_0_AXI_S_BRIDGE_CLK>,
+ <&gcc GCC_PCIE3X1_0_AXI_S_CLK>,
+ <&gcc GCC_PCIE3X1_0_RCHG_CLK>;
+
+ assigned-clock-rates = <2000000>,
+ <240000000>,
+ <240000000>,
+ <240000000>,
+ <100000000>;
+
+ resets = <&gcc GCC_PCIE3X1_0_PIPE_ARES>,
+ <&gcc GCC_PCIE3X1_0_CORE_STICKY_ARES>,
+ <&gcc GCC_PCIE3X1_0_AXI_S_STICKY_ARES>,
+ <&gcc GCC_PCIE3X1_0_AXI_S_CLK_ARES>,
+ <&gcc GCC_PCIE3X1_0_AXI_M_STICKY_ARES>,
+ <&gcc GCC_PCIE3X1_0_AXI_M_CLK_ARES>,
+ <&gcc GCC_PCIE3X1_0_AUX_CLK_ARES>,
+ <&gcc GCC_PCIE3X1_0_AHB_CLK_ARES>;
+ reset-names = "pipe",
+ "sticky",
+ "axi_s_sticky",
+ "axi_s",
+ "axi_m_sticky",
+ "axi_m",
+ "aux",
+ "ahb";
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ interconnects = <&gcc MASTER_SNOC_PCIE3_1_M &gcc SLAVE_SNOC_PCIE3_1_M>,
+ <&gcc MASTER_ANOC_PCIE3_1_S &gcc SLAVE_ANOC_PCIE3_1_S>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ status = "disabled";
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
};
timer {
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 7/7] arm64: dts: qcom: ipq5332-rdp441: Enable PCIe phys and controllers
From: Varadarajan Narayanan @ 2025-01-22 6:34 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, quic_varada, linux-arm-msm,
linux-pci, devicetree, linux-kernel, linux-phy
Cc: Praveenkumar I, Konrad Dybcio
In-Reply-To: <20250122063411.3503097-1-quic_varada@quicinc.com>
From: Praveenkumar I <quic_ipkumar@quicinc.com>
Enable the PCIe controller and PHY nodes for RDP 441.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v5: Add 'Reviewed-by: Konrad Dybcio'
v4: Fix nodes sort order
Use property-n followed by property-names
v3: Reorder nodes alphabetically
Fix commit subject
---
arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts | 76 +++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts b/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts
index 846413817e9a..79ec77cfe552 100644
--- a/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts
+++ b/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts
@@ -32,6 +32,34 @@ &sdhc {
status = "okay";
};
+&pcie0 {
+ pinctrl-0 = <&pcie0_default>;
+ pinctrl-names = "default";
+
+ perst-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 39 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ status = "okay";
+};
+
+&pcie1 {
+ pinctrl-0 = <&pcie1_default>;
+ pinctrl-names = "default";
+
+ perst-gpios = <&tlmm 47 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 48 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ status = "okay";
+};
+
&tlmm {
i2c_1_pins: i2c-1-state {
pins = "gpio29", "gpio30";
@@ -40,6 +68,54 @@ i2c_1_pins: i2c-1-state {
bias-pull-up;
};
+ pcie0_default: pcie0-default-state {
+ clkreq-n-pins {
+ pins = "gpio37";
+ function = "pcie0_clk";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio38";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ output-low;
+ };
+
+ wake-n-pins {
+ pins = "gpio39";
+ function = "pcie0_wake";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+ };
+
+ pcie1_default: pcie1-default-state {
+ clkreq-n-pins {
+ pins = "gpio46";
+ function = "pcie1_clk";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio47";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ output-low;
+ };
+
+ wake-n-pins {
+ pins = "gpio48";
+ function = "pcie1_wake";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+ };
+
sdc_default_state: sdc-default-state {
clk-pins {
pins = "gpio13";
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH] phy: rockchip: fix Kconfig dependency more
From: Arnd Bergmann @ 2025-01-22 6:52 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Arnd Bergmann
Cc: Cristian Ciocaltea, Zhang Yubing, Sebastian Reichel, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
A previous patch ensured that USB Type C connector support is enabled,
but it is still possible to build the phy driver without enabling
CONFIG_USB (host support) or CONFIG_USB_GADGET (device support), and
in that case the common helper functions are unavailable:
aarch64-linux-ld: drivers/phy/rockchip/phy-rockchip-usbdp.o: in function `rk_udphy_probe':
phy-rockchip-usbdp.c:(.text+0xe74): undefined reference to `usb_get_maximum_speed'
Select CONFIG_USB_COMMON directly here, like we do in some other phy
drivers, to make sure this is available even when actual USB support
is disabled or in a loadable module that cannot be reached from a
built-in phy driver.
Fixes: 9c79b779643e ("phy: rockchip: fix CONFIG_TYPEC dependency")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/phy/rockchip/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 2f7a05f21dc5..dcb8e1628632 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -125,6 +125,7 @@ config PHY_ROCKCHIP_USBDP
depends on ARCH_ROCKCHIP && OF
depends on TYPEC
select GENERIC_PHY
+ select USB_COMMON
help
Enable this to support the Rockchip USB3.0/DP combo PHY with
Samsung IP block. This is required for USB3 support on RK3588.
--
2.39.5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add PHY register retention support
From: Wenbin Yao (Consultant) @ 2025-01-22 7:17 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: vkoul, kishon, p.zabel, abel.vesa, quic_qianyu, neil.armstrong,
manivannan.sadhasivam, quic_devipriy, konrad.dybcio,
linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <CAA8EJppXQpDrdXzJsTE7HWs=POt7yFAw0JVZFabN6Ks3fhZiWQ@mail.gmail.com>
On 1/21/2025 6:36 PM, Dmitry Baryshkov wrote:
> On Tue, 21 Jan 2025 at 11:43, Wenbin Yao <quic_wenbyao@quicinc.com> wrote:
>> From: Qiang Yu <quic_qianyu@quicinc.com>
>>
>> Currently, BCR reset and PHY register setting are mandatory for every port
>> before link training. However, some QCOM PCIe PHYs support no_csr reset.
>> Different than BCR reset that is used to reset entire PHY including
>> hardware and register, once no_csr reset is toggled, only PHY hardware will
>> be reset but PHY registers will be retained,
> I'm sorry, I can't parse this.
The difference between no_csr reset and bcr reset is that no_csr reset
doesn't reset the phy registers. If a phy is enabled in UEFI, its registers
are programed. After Linux boot up, the registers will not be reset but
keep the value programmed by UEFI if we only do no_csr reset, so we can
skip phy setting.
>
>> which means PHY setting can
>> be skipped during PHY init if PCIe link was enabled in booltloader and only
>> no_csr is toggled after that.
>>
>> Hence, determine whether the PHY has been enabled in bootloader by
>> verifying QPHY_START_CTRL register. If it is programmed and no_csr reset is
>> present, skip BCR reset and PHY register setting, so that PCIe link can be
>> established with no_csr reset only.
> This doesn't tell us why we want to do so. The general rule is not to
> depend on the bootloaders at all. The reason is pretty simple: it is
> hard to update bootloaders, while it is relatively easy to update the
> kernel. If the hardware team issues any kind of changes to the
> programming tables, the kernel will get them earlier than the
> bootloader.
With this change, we don't need to upstream phy setting for all phys
support no_csr reset, this will save a great deal of efforts and simplify
the phy driver. Our goal is to remove proprietary PCIe firmware operations
from kernel. PHY is just the start and will be followed by controller,
clocks, regulators, etc. If program table need to be changed, the place to
do that will be UEFI.
>
>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 91 +++++++++++++++---------
>> 1 file changed, 58 insertions(+), 33 deletions(-)
>>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 11/20] drm/bridge: analogix_dp: Add support to get panel from the DP AUX bus
From: Damon Ding @ 2025-01-22 8:06 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: heiko, robh, krzk+dt, conor+dt, rfoss, vkoul, sebastian.reichel,
cristian.ciocaltea, l.stach, andy.yan, hjc, algea.cao, kever.yang,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, linux-phy
In-Reply-To: <v3is3v3fpx42i2eh2qrfkx3qx3z7iema3honi544qoc4j2whdo@h6ajv5h53gry>
Hi Dmitry,
On 2025/1/9 20:45, Dmitry Baryshkov wrote:
> On Thu, Jan 09, 2025 at 11:27:16AM +0800, Damon Ding wrote:
>> The main modification is moving the DP AUX initialization from function
>> analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of
>> eDP panel during probing, it is also needed to advance PM operaions to
>> ensure that eDP controller and phy are prepared for AUX transmission.
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> ---
>>
>> Changes in v4:
>> - Use done_probing() to call drm_of_find_panel_or_bridge() and
>> component_add() when getting panel from the DP AUX bus
>>
>> Changes in v5:
>> - Advance PM operations to make eDP AUX work well
>> ---
>> .../drm/bridge/analogix/analogix_dp_core.c | 62 ++++++++++---------
>> 1 file changed, 34 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 8251adfce2f9..78e78fb474d3 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1548,6 +1548,18 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux *aux,
>> return ret;
>> }
>>
>> +static void analogix_dp_runtime_disable(void *data)
>> +{
>> + struct analogix_dp_device *dp = (struct analogix_dp_device *)data;
>> +
>> + if (IS_ENABLED(CONFIG_PM)) {
>> + pm_runtime_dont_use_autosuspend(dp->dev);
>> + pm_runtime_disable(dp->dev);
>> + } else {
>> + analogix_dp_suspend(dp);
>> + }
>> +}
>> +
>> struct analogix_dp_device *
>> analogix_dp_probe(struct device *dev, struct analogix_dp_plat_data *plat_data)
>> {
>> @@ -1658,8 +1670,29 @@ analogix_dp_probe(struct device *dev, struct analogix_dp_plat_data *plat_data)
>> }
>> disable_irq(dp->irq);
>>
>> + dp->aux.name = "DP-AUX";
>> + dp->aux.transfer = analogix_dpaux_transfer;
>> + dp->aux.dev = dp->dev;
>> + drm_dp_aux_init(&dp->aux);
>> +
>> + if (IS_ENABLED(CONFIG_PM)) {
>> + pm_runtime_use_autosuspend(dp->dev);
>> + pm_runtime_set_autosuspend_delay(dp->dev, 100);
>> + pm_runtime_enable(dp->dev);
>> + } else {
>> + ret = analogix_dp_resume(dp);
>> + if (ret)
>> + goto err_disable_clk;
>> + }
>> +
>> + ret = devm_add_action_or_reset(dev, analogix_dp_runtime_disable, dp);
>
> This looks like a local version of devm_pm_runtime_enable()
>
Indeed, it is better to use devm_pm_runtime_enable() instead.
>> + if (ret)
>> + goto err_disable_pm_runtime;
>> +
>> return dp;
>>
>> +err_disable_pm_runtime:
>> + analogix_dp_runtime_disable((void *)dp);
>> err_disable_clk:
>> clk_disable_unprepare(dp->clock);
>> return ERR_PTR(ret);
>> @@ -1708,25 +1741,12 @@ int analogix_dp_bind(struct analogix_dp_device *dp, struct drm_device *drm_dev)
>> dp->drm_dev = drm_dev;
>> dp->encoder = dp->plat_data->encoder;
>>
>> - if (IS_ENABLED(CONFIG_PM)) {
>> - pm_runtime_use_autosuspend(dp->dev);
>> - pm_runtime_set_autosuspend_delay(dp->dev, 100);
>> - pm_runtime_enable(dp->dev);
>> - } else {
>> - ret = analogix_dp_resume(dp);
>> - if (ret)
>> - return ret;
>> - }
>> -
>> - dp->aux.name = "DP-AUX";
>> - dp->aux.transfer = analogix_dpaux_transfer;
>> - dp->aux.dev = dp->dev;
>> dp->aux.drm_dev = drm_dev;
>>
>> ret = drm_dp_aux_register(&dp->aux);
>> if (ret) {
>> DRM_ERROR("failed to register AUX (%d)\n", ret);
>> - goto err_disable_pm_runtime;
>> + return ret;
>> }
>>
>> ret = analogix_dp_create_bridge(drm_dev, dp);
>> @@ -1739,13 +1759,6 @@ int analogix_dp_bind(struct analogix_dp_device *dp, struct drm_device *drm_dev)
>>
>> err_unregister_aux:
>> drm_dp_aux_unregister(&dp->aux);
>> -err_disable_pm_runtime:
>> - if (IS_ENABLED(CONFIG_PM)) {
>> - pm_runtime_dont_use_autosuspend(dp->dev);
>> - pm_runtime_disable(dp->dev);
>> - } else {
>> - analogix_dp_suspend(dp);
>> - }
>>
>> return ret;
>> }
>> @@ -1762,13 +1775,6 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
>> }
>>
>> drm_dp_aux_unregister(&dp->aux);
>> -
>> - if (IS_ENABLED(CONFIG_PM)) {
>> - pm_runtime_dont_use_autosuspend(dp->dev);
>> - pm_runtime_disable(dp->dev);
>> - } else {
>> - analogix_dp_suspend(dp);
>> - }
>> }
>> EXPORT_SYMBOL_GPL(analogix_dp_unbind);
>>
>> --
>> 2.34.1
>>
>
Best regards,
Damon
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 12/20] drm/rockchip: analogix_dp: Add support to get panel from the DP AUX bus
From: Damon Ding @ 2025-01-22 8:17 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: heiko, robh, krzk+dt, conor+dt, rfoss, vkoul, sebastian.reichel,
cristian.ciocaltea, l.stach, andy.yan, hjc, algea.cao, kever.yang,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, linux-phy
In-Reply-To: <d7zpv6qt52mhny54dejw4yqlp2k2c437op7qmepqe27pufplqk@64xvohrz7h2q>
Hi Dmitry,
On 2025/1/9 20:48, Dmitry Baryshkov wrote:
> On Thu, Jan 09, 2025 at 11:27:17AM +0800, Damon Ding wrote:
>> Move drm_of_find_panel_or_bridge() a little later and combine it with
>> component_add() into a new function rockchip_dp_link_panel(). The function
>> will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
>> aiding to support for obtaining the eDP panel via the DP AUX bus.
>>
>> If failed to get the panel from the DP AUX bus, it will then try the other
>> way to get panel information through the platform bus.
>>
>> In addition, use dev_err() instead of drm_err() in rockchip_dp_poweron()
>> , which will be called before rockchip_dp_bind().
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> ---
>>
>> Changes in v4:
>> - Use done_probing() to call drm_of_find_panel_or_bridge() and
>> component_add() when getting panel from the DP AUX bus
>>
>> Changes in v5:
>> - Use the functions exported by the Analogix side to get the pointers of
>> struct analogix_dp_plat_data and struct drm_dp_aux.
>> - Use dev_err() instead of drm_err() in rockchip_dp_poweron().
>>
>> ---
>> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 41 ++++++++++++++-----
>> 1 file changed, 30 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> index 0957d3c5d31d..3ae01b870f49 100644
>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> @@ -124,13 +124,13 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
>>
>> ret = clk_prepare_enable(dp->pclk);
>> if (ret < 0) {
>> - drm_err(dp->drm_dev, "failed to enable pclk %d\n", ret);
>> + dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>
>
> why?
>
The &rockchip_dp_device.drm_dev will be assigned in rockchip_dp_bind(),
which is called after probing process. The PM operations have been
advanced to the probing for the AUX transmission, so the dev_err() may
be better than drm_err().
>> return ret;
>> }
>>
>> ret = rockchip_dp_pre_init(dp);
>> if (ret < 0) {
>> - drm_err(dp->drm_dev, "failed to dp pre init %d\n", ret);
>> + dev_err(dp->dev, "failed to dp pre init %d\n", ret);
>> clk_disable_unprepare(dp->pclk);
>> return ret;
>> }
>
Best regards
Damon
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 05/20] drm/rockchip: analogix_dp: Replace DRM_...() functions with drm_...() or dev_...()
From: Damon Ding @ 2025-01-22 8:46 UTC (permalink / raw)
To: Andy Yan
Cc: heiko, robh, krzk+dt, conor+dt, rfoss, vkoul, sebastian.reichel,
cristian.ciocaltea, l.stach, dmitry.baryshkov, andy.yan, hjc,
algea.cao, kever.yang, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-phy
In-Reply-To: <40b09942.533e.19449c023a1.Coremail.andyshrk@163.com>
Hi Andy,
On 2025/1/9 14:28, Andy Yan wrote:
>
> Hi Damon,
>
> At 2025-01-09 11:27:10, "Damon Ding" <damon.ding@rock-chips.com> wrote:
>> According to the comments in include/drm/drm_print.h, the DRM_...()
>> functions are deprecated in favor of drm_...() or dev_...() functions.
>>
>> Use drm_err()/drm_dbg_core()/drm_dbg_kms() instead of
>> DRM_DEV_ERROR()/DRM_ERROR()/DRM_DEV_DEBUG()/DRM_DEBUG_KMS() after
>> rockchip_dp_bind() is called, and replace DRM_DEV_ERROR() with dev_err()
>> before calling it.
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>> ---
>> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 29 ++++++++++---------
>> 1 file changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> index 546d13f19f9b..8114c3238609 100644
>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> @@ -100,13 +100,13 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
>>
>> ret = clk_prepare_enable(dp->pclk);
>> if (ret < 0) {
>> - DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
>> + drm_err(dp->drm_dev, "failed to enable pclk %d\n", ret);
>
> You just need to pass dp here:
> drm_err(dp, "failed to enable pclk %d\n", ret);
>
I see. It is really better to pass dp instead of dp->drm_dev. I will
update all relevant logs in the next version.
>> return ret;
>> }
>>
>> ret = rockchip_dp_pre_init(dp);
>> if (ret < 0) {
>> - DRM_DEV_ERROR(dp->dev, "failed to dp pre init %d\n", ret);
>> + drm_err(dp->drm_dev, "failed to dp pre init %d\n", ret);
>> clk_disable_unprepare(dp->pclk);
>> return ret;
>> }
>> @@ -126,12 +126,13 @@ static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
>> static int rockchip_dp_get_modes(struct analogix_dp_plat_data *plat_data,
>> struct drm_connector *connector)
>> {
>> + struct rockchip_dp_device *dp = pdata_encoder_to_dp(plat_data);
>> struct drm_display_info *di = &connector->display_info;
>> /* VOP couldn't output YUV video format for eDP rightly */
>> u32 mask = DRM_COLOR_FORMAT_YCBCR444 | DRM_COLOR_FORMAT_YCBCR422;
>>
>> if ((di->color_formats & mask)) {
>> - DRM_DEBUG_KMS("Swapping display color format from YUV to RGB\n");
>> + drm_dbg_kms(dp->drm_dev, "Swapping display color format from YUV to RGB\n");
>> di->color_formats &= ~mask;
>> di->color_formats |= DRM_COLOR_FORMAT_RGB444;
>> di->bpc = 8;
>> @@ -201,17 +202,17 @@ static void rockchip_dp_drm_encoder_enable(struct drm_encoder *encoder,
>> else
>> val = dp->data->lcdsel_big;
>>
>> - DRM_DEV_DEBUG(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
>> + drm_dbg_core(dp->drm_dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
>>
>> ret = clk_prepare_enable(dp->grfclk);
>> if (ret < 0) {
>> - DRM_DEV_ERROR(dp->dev, "failed to enable grfclk %d\n", ret);
>> + drm_err(dp->drm_dev, "failed to enable grfclk %d\n", ret);
>> return;
>> }
>>
>> ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
>> if (ret != 0)
>> - DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
>> + drm_err(dp->drm_dev, "Could not write to GRF: %d\n", ret);
>>
>> clk_disable_unprepare(dp->grfclk);
>> }
>> @@ -236,7 +237,7 @@ static void rockchip_dp_drm_encoder_disable(struct drm_encoder *encoder,
>>
>> ret = rockchip_drm_wait_vact_end(crtc, PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
>> if (ret)
>> - DRM_DEV_ERROR(dp->dev, "line flag irq timed out\n");
>> + drm_err(dp->drm_dev, "line flag irq timed out\n");
>> }
>>
>> static int
>> @@ -277,7 +278,7 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
>>
>> dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
>> if (IS_ERR(dp->grf)) {
>> - DRM_DEV_ERROR(dev, "failed to get rockchip,grf property\n");
>> + dev_err(dev, "failed to get rockchip,grf property\n");
>> return PTR_ERR(dp->grf);
>> }
>>
>> @@ -287,19 +288,19 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
>> } else if (PTR_ERR(dp->grfclk) == -EPROBE_DEFER) {
>> return -EPROBE_DEFER;
>> } else if (IS_ERR(dp->grfclk)) {
>> - DRM_DEV_ERROR(dev, "failed to get grf clock\n");
>> + dev_err(dev, "failed to get grf clock\n");
>> return PTR_ERR(dp->grfclk);
>> }
>>
>> dp->pclk = devm_clk_get(dev, "pclk");
>> if (IS_ERR(dp->pclk)) {
>> - DRM_DEV_ERROR(dev, "failed to get pclk property\n");
>> + dev_err(dev, "failed to get pclk property\n");
>> return PTR_ERR(dp->pclk);
>> }
>>
>> dp->rst = devm_reset_control_get(dev, "dp");
>> if (IS_ERR(dp->rst)) {
>> - DRM_DEV_ERROR(dev, "failed to get dp reset control\n");
>> + dev_err(dev, "failed to get dp reset control\n");
>> return PTR_ERR(dp->rst);
>> }
>>
>> @@ -315,12 +316,12 @@ static int rockchip_dp_drm_create_encoder(struct rockchip_dp_device *dp)
>>
>> encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
>> dev->of_node);
>> - DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
>> + drm_dbg_kms(drm_dev, "possible_crtcs = 0x%x\n", encoder->possible_crtcs);
>>
>> ret = drm_simple_encoder_init(drm_dev, encoder,
>> DRM_MODE_ENCODER_TMDS);
>> if (ret) {
>> - DRM_ERROR("failed to initialize encoder with drm\n");
>> + drm_err(drm_dev, "failed to initialize encoder with drm\n");
>> return ret;
>> }
>>
>> @@ -340,7 +341,7 @@ static int rockchip_dp_bind(struct device *dev, struct device *master,
>>
>> ret = rockchip_dp_drm_create_encoder(dp);
>> if (ret) {
>> - DRM_ERROR("failed to create drm encoder\n");
>> + drm_err(drm_dev, "failed to create drm encoder\n");
>> return ret;
>> }
>>
>> --
>> 2.34.1
>>
Best regards,
Damon
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 20/20] arm64: dts: rockchip: Enable eDP0 display on RK3588S EVB1 board
From: Damon Ding @ 2025-01-22 9:05 UTC (permalink / raw)
To: Andy Yan
Cc: heiko, robh, krzk+dt, conor+dt, rfoss, vkoul, sebastian.reichel,
cristian.ciocaltea, l.stach, dmitry.baryshkov, andy.yan, hjc,
algea.cao, kever.yang, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-phy
In-Reply-To: <8927876.291e.19454e86e8f.Coremail.andyshrk@163.com>
Hi Andy,
On 2025/1/11 18:28, Andy Yan wrote:
>
> Hi Damon,
>
> At 2025-01-09 11:27:25, "Damon Ding" <damon.ding@rock-chips.com> wrote:
>> Add the necessary DT changes to enable eDP0 on RK3588S EVB1 board:
>> - Set pinctrl of pwm12 for backlight
>> - Enable edp0/hdptxphy0/vp2
>> - Add aux-bus/panel nodes
>>
>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> ---
>>
>> Changes in v2:
>> - Remove brightness-levels and default-brightness-level properties in
>> backlight node.
>> - Add the detail DT changes to commit message.
>>
>> Changes in v3:
>> - Use aux-bus instead of platform bus for edp-panel.
>>
>> Changes in v4:
>> - Add comments related to the use of panel compatible "lg,lp079qx1-sp0v"
>> in the commit message.
>>
>> Changes in v5:
>> - Use "edp-panel" instead of "lg,lp079qx1-sp0v"
>> - Remove unnecessary comments in commit message
>> - Assign the parent of DCLK_VOP2_SRC to PLL_V0PLL
>> ---
>> .../boot/dts/rockchip/rk3588s-evb1-v10.dts | 54 +++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588s-evb1-v10.dts
>> index bc4077575beb..a8c151b41e21 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588s-evb1-v10.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-evb1-v10.dts
>> @@ -9,6 +9,7 @@
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/input/input.h>
>> #include <dt-bindings/pinctrl/rockchip.h>
>> +#include <dt-bindings/soc/rockchip,vop2.h>
>> #include <dt-bindings/usb/pd.h>
>> #include "rk3588s.dtsi"
>>
>> @@ -238,6 +239,41 @@ &combphy2_psu {
>> status = "okay";
>> };
>>
>> +&edp0 {
>> + force-hpd;
>> + status = "okay";
>> +
>> + aux-bus {
>> + panel {
>> + compatible = "edp-panel";
>> + backlight = <&backlight>;
>> + power-supply = <&vcc3v3_lcd_edp>;
>> +
>> + port {
>> + panel_in_edp: endpoint {
>> + remote-endpoint = <&edp_out_panel>;
>> + };
>> + };
>> + };
>> + };
>> +};
>> +
>> +&edp0_in {
>> + edp0_in_vp2: endpoint {
>> + remote-endpoint = <&vp2_out_edp0>;
>> + };
>> +};
>> +
>> +&edp0_out {
>> + edp_out_panel: endpoint {
>> + remote-endpoint = <&panel_in_edp>;
>> + };
>> +};
>> +
>> +&hdptxphy0 {
>> + status = "okay";
>> +};
>> +
>> &i2c3 {
>> status = "okay";
>>
>> @@ -399,6 +435,7 @@ usbc0_int: usbc0-int {
>> };
>>
>> &pwm12 {
>> + pinctrl-0 = <&pwm12m1_pins>;
>> status = "okay";
>> };
>>
>> @@ -1168,3 +1205,20 @@ usbdp_phy0_dp_altmode_mux: endpoint@1 {
>> };
>> };
>> };
>> +
>> +&vop_mmu {
>> + status = "okay";
>> +};
>> +
>> +&vop {
>> + assigned-clocks = <&cru DCLK_VOP2_SRC>;
>> + assigned-clock-parents = <&cru PLL_V0PLL>;
>
> It's necessary to explain why we need to assign V0PLL for DCLK_VOP2_SRC in commit message.
>
>
I will add relevant explainations in next version.
>> + status = "okay";
>> +};
>> +
>> +&vp2 {
>> + vp2_out_edp0: endpoint@ROCKCHIP_VOP2_EP_EDP0 {
>> + reg = <ROCKCHIP_VOP2_EP_EDP0>;
>> + remote-endpoint = <&edp0_in_vp2>;
>> + };
>> +};
>> --
>> 2.34.1
>>
Best regards,
Damon
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 12/20] drm/rockchip: analogix_dp: Add support to get panel from the DP AUX bus
From: Damon Ding @ 2025-01-22 9:37 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: heiko, robh, krzk+dt, conor+dt, rfoss, vkoul, sebastian.reichel,
cristian.ciocaltea, l.stach, andy.yan, hjc, algea.cao, kever.yang,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, linux-phy
In-Reply-To: <330041c4-aaee-4b41-8ccd-e2807415c709@rock-chips.com>
Hi Dmitry,
On 2025/1/22 16:17, Damon Ding wrote:
> Hi Dmitry,
>
> On 2025/1/9 20:48, Dmitry Baryshkov wrote:
>> On Thu, Jan 09, 2025 at 11:27:17AM +0800, Damon Ding wrote:
>>> Move drm_of_find_panel_or_bridge() a little later and combine it with
>>> component_add() into a new function rockchip_dp_link_panel(). The
>>> function
>>> will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
>>> aiding to support for obtaining the eDP panel via the DP AUX bus.
>>>
>>> If failed to get the panel from the DP AUX bus, it will then try the
>>> other
>>> way to get panel information through the platform bus.
>>>
>>> In addition, use dev_err() instead of drm_err() in rockchip_dp_poweron()
>>> , which will be called before rockchip_dp_bind().
>>>
>>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>>
>>> ---
>>>
>>> Changes in v4:
>>> - Use done_probing() to call drm_of_find_panel_or_bridge() and
>>> component_add() when getting panel from the DP AUX bus
>>>
>>> Changes in v5:
>>> - Use the functions exported by the Analogix side to get the pointers of
>>> struct analogix_dp_plat_data and struct drm_dp_aux.
>>> - Use dev_err() instead of drm_err() in rockchip_dp_poweron().
>>>
>>> ---
>>> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 41 ++++++++++++++-----
>>> 1 file changed, 30 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 0957d3c5d31d..3ae01b870f49 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -124,13 +124,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> - drm_err(dp->drm_dev, "failed to enable pclk %d\n", ret);
>>> + dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>
>>
>> why?
>>
>
> The &rockchip_dp_device.drm_dev will be assigned in rockchip_dp_bind(),
> which is called after probing process. The PM operations have been
> advanced to the probing for the AUX transmission, so the dev_err() may
> be better than drm_err().
>
Using drm_...() uniformly may be better [0].
>>> return ret;
>>> }
>>> ret = rockchip_dp_pre_init(dp);
>>> if (ret < 0) {
>>> - drm_err(dp->drm_dev, "failed to dp pre init %d\n", ret);
>>> + dev_err(dp->dev, "failed to dp pre init %d\n", ret);
>>> clk_disable_unprepare(dp->pclk);
>>> return ret;
>>> }
>>
Best regards,
Damon
[0]https://patchwork.kernel.org/project/linux-rockchip/patch/20250109032725.1102465-6-damon.ding@rock-chips.com/#26209891
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add PHY register retention support
From: Dmitry Baryshkov @ 2025-01-22 9:43 UTC (permalink / raw)
To: Wenbin Yao (Consultant)
Cc: vkoul, kishon, p.zabel, abel.vesa, quic_qianyu, neil.armstrong,
manivannan.sadhasivam, quic_devipriy, konrad.dybcio,
linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <a2cc5a5a-6cbd-7564-a8df-8af2a652de2f@quicinc.com>
On Wed, Jan 22, 2025 at 03:17:39PM +0800, Wenbin Yao (Consultant) wrote:
> On 1/21/2025 6:36 PM, Dmitry Baryshkov wrote:
> > On Tue, 21 Jan 2025 at 11:43, Wenbin Yao <quic_wenbyao@quicinc.com> wrote:
> > > From: Qiang Yu <quic_qianyu@quicinc.com>
> > >
> > > Currently, BCR reset and PHY register setting are mandatory for every port
> > > before link training. However, some QCOM PCIe PHYs support no_csr reset.
> > > Different than BCR reset that is used to reset entire PHY including
> > > hardware and register, once no_csr reset is toggled, only PHY hardware will
> > > be reset but PHY registers will be retained,
> > I'm sorry, I can't parse this.
> The difference between no_csr reset and bcr reset is that no_csr reset
> doesn't reset the phy registers. If a phy is enabled in UEFI, its registers
> are programed. After Linux boot up, the registers will not be reset but
> keep the value programmed by UEFI if we only do no_csr reset, so we can
> skip phy setting.
Please fix capitalization of the abbreviations (PHY, BCR) and add
similar text to the commit message.
> >
> > > which means PHY setting can
> > > be skipped during PHY init if PCIe link was enabled in booltloader and only
> > > no_csr is toggled after that.
> > >
> > > Hence, determine whether the PHY has been enabled in bootloader by
> > > verifying QPHY_START_CTRL register. If it is programmed and no_csr reset is
> > > present, skip BCR reset and PHY register setting, so that PCIe link can be
> > > established with no_csr reset only.
> > This doesn't tell us why we want to do so. The general rule is not to
> > depend on the bootloaders at all. The reason is pretty simple: it is
> > hard to update bootloaders, while it is relatively easy to update the
> > kernel. If the hardware team issues any kind of changes to the
> > programming tables, the kernel will get them earlier than the
> > bootloader.
> With this change, we don't need to upstream phy setting for all phys
> support no_csr reset, this will save a great deal of efforts and simplify
> the phy driver. Our goal is to remove proprietary PCIe firmware operations
> from kernel. PHY is just the start and will be followed by controller,
> clocks, regulators, etc. If program table need to be changed, the place to
> do that will be UEFI.
Well, that sounds like a very bad idea. Please don't do that. Linux
kernel drivers should not depend on the UEFI or a bootloader. Unless
there is a good reason for that, Linux should continue to be able to
reset and program the PCIe PHY (as well as all other hw blocks).
> >
> > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
> > > Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
> > > ---
> > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 91 +++++++++++++++---------
> > > 1 file changed, 58 insertions(+), 33 deletions(-)
> > >
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2] phy: tegra: xusb: reset VBUS & ID OVERRIDE
From: Henry Lin @ 2025-01-22 10:59 UTC (permalink / raw)
To: JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Thierry Reding,
Jonathan Hunter, Henry Lin
Cc: linux-phy, linux-tegra, linux-kernel, BH Hsieh, stable
From: BH Hsieh <bhsieh@nvidia.com>
Observed VBUS_OVERRIDE & ID_OVERRIDE might be programmed
with unexpected value prior to XUSB PADCTL driver, this
could also occur in virtualization scenario.
For example, UEFI firmware programs ID_OVERRIDE=GROUNDED to set
a type-c port to host mode and keeps the value to kernel.
If the type-c port is connected a usb host, below errors can be
observed right after usb host mode driver gets probed. The errors
would keep until usb role class driver detects the type-c port
as device mode and notifies usb device mode driver to set both
ID_OVERRIDE and VBUS_OVERRIDE to correct value by XUSB PADCTL
driver.
[ 173.765814] usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
[ 173.765837] usb usb3-port2: config error
Taking virtualization into account, asserting XUSB PADCTL
reset would break XUSB functions used by other guest OS,
hence only reset VBUS & ID OVERRIDE of the port in
utmi_phy_init.
Fixes: bbf711682cd5 ("phy: tegra: xusb: Add Tegra186 support")
Cc: stable@vger.kernel.org
Change-Id: Ic63058d4d49b4a1f8f9ab313196e20ad131cc591
Signed-off-by: BH Hsieh <bhsieh@nvidia.com>
Signed-off-by: Henry Lin <henryl@nvidia.com>
---
V1 -> V2: Only reset VBUS/ID OVERRIDE for otg/peripheral port
drivers/phy/tegra/xusb-tegra186.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index 0f60d5d1c167..fae6242aa730 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -928,6 +928,7 @@ static int tegra186_utmi_phy_init(struct phy *phy)
unsigned int index = lane->index;
struct device *dev = padctl->dev;
int err;
+ u32 reg;
port = tegra_xusb_find_usb2_port(padctl, index);
if (!port) {
@@ -935,6 +936,16 @@ static int tegra186_utmi_phy_init(struct phy *phy)
return -ENODEV;
}
+ if (port->mode == USB_DR_MODE_OTG ||
+ port->mode == USB_DR_MODE_PERIPHERAL) {
+ /* reset VBUS&ID OVERRIDE */
+ reg = padctl_readl(padctl, USB2_VBUS_ID);
+ reg &= ~VBUS_OVERRIDE;
+ reg &= ~ID_OVERRIDE(~0);
+ reg |= ID_OVERRIDE_FLOATING;
+ padctl_writel(padctl, reg, USB2_VBUS_ID);
+ }
+
if (port->supply && port->mode == USB_DR_MODE_HOST) {
err = regulator_enable(port->supply);
if (err) {
--
2.17.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 7/7] arm64: dts: qcom: sm8750: Add USB support to SM8750 platforms
From: Krzysztof Kozlowski @ 2025-01-22 11:10 UTC (permalink / raw)
To: Melody Olvera, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Greg Kroah-Hartman, Philipp Zabel, Catalin Marinas, Will Deacon,
Bjorn Andersson, Konrad Dybcio, Satya Durga Srinivasu Prabhala,
Trilok Soni
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
linux-arm-kernel
In-Reply-To: <20250113-sm8750_usb_master-v1-7-09afe1dc2524@quicinc.com>
On 13/01/2025 22:52, Melody Olvera wrote:
> From: Wesley Cheng <quic_wcheng@quicinc.com>
>
> Enable USB support on SM8750 MTP and QRD variants. SM8750 has a QMP combo
> PHY for the SSUSB path, and a M31 eUSB2 PHY for the HSUSB path.
>
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
This does not apply on next. Way you combine series and split DTS into 5
different patchsets is not making it easier. I say it makes it close to
impossible to actually test your patches, especially considering no
cross references at all.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 03/12] pinctrl: sunxi: add driver for Allwinner V853.
From: Linus Walleij @ 2025-01-22 13:30 UTC (permalink / raw)
To: Andre Przywara
Cc: Andras Szemzo, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Philipp Zabel, Maxime Ripard, Vinod Koul,
Kishon Vijay Abraham I, Ulf Hansson, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Uwe Kleine-König,
Florian Fainelli, linux-clk, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-phy, linux-gpio, linux-pm,
linux-riscv
In-Reply-To: <20250117145228.2fc8a64e@donnerap.manchester.arm.com>
On Fri, Jan 17, 2025 at 3:52 PM Andre Przywara <andre.przywara@arm.com> wrote:
> That is actually a good argument: At the moment I am happy with my
> proposal (the allwinner,pinmux = <number>; property), but that seems like
> standard #15 then.
> So would biting the bullet and adopting the Apple/STM32 way then be more
> sustainable?
I suppose...
> On the other hand: the allwinner,pinmux solution has the advantage of being
> already written and proven working, also it stays very close to the
> existing description/binding - so implementations like U-Boot could just
> keep on using the "function" string.
>
> I am a bit torn here... I don't think I will find the solitude to
> implement this "Apple" approach in the next few weeks.
I think whatever the Allwinner maintainers agree is the best should
be what you go for. It is a lot of hobbyist maintainers in this space
and for them the bar should be lower.
If you have buy-in from the other maintainers, then go for that
solution.
Yours,
Linus Walleij
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 12/20] drm/rockchip: analogix_dp: Add support to get panel from the DP AUX bus
From: Dmitry Baryshkov @ 2025-01-22 18:56 UTC (permalink / raw)
To: Damon Ding
Cc: heiko, robh, krzk+dt, conor+dt, rfoss, vkoul, sebastian.reichel,
cristian.ciocaltea, l.stach, andy.yan, hjc, algea.cao, kever.yang,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, linux-phy
In-Reply-To: <ba369b98-9a2a-421a-9251-4db3c1dcedd9@rock-chips.com>
On Wed, Jan 22, 2025 at 05:37:53PM +0800, Damon Ding wrote:
> Hi Dmitry,
>
> On 2025/1/22 16:17, Damon Ding wrote:
> > Hi Dmitry,
> >
> > On 2025/1/9 20:48, Dmitry Baryshkov wrote:
> > > On Thu, Jan 09, 2025 at 11:27:17AM +0800, Damon Ding wrote:
> > > > Move drm_of_find_panel_or_bridge() a little later and combine it with
> > > > component_add() into a new function rockchip_dp_link_panel().
> > > > The function
> > > > will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
> > > > aiding to support for obtaining the eDP panel via the DP AUX bus.
> > > >
> > > > If failed to get the panel from the DP AUX bus, it will then try
> > > > the other
> > > > way to get panel information through the platform bus.
> > > >
> > > > In addition, use dev_err() instead of drm_err() in rockchip_dp_poweron()
> > > > , which will be called before rockchip_dp_bind().
> > > >
> > > > Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> > > >
> > > > ---
> > > >
> > > > Changes in v4:
> > > > - Use done_probing() to call drm_of_find_panel_or_bridge() and
> > > > component_add() when getting panel from the DP AUX bus
> > > >
> > > > Changes in v5:
> > > > - Use the functions exported by the Analogix side to get the pointers of
> > > > struct analogix_dp_plat_data and struct drm_dp_aux.
> > > > - Use dev_err() instead of drm_err() in rockchip_dp_poweron().
> > > >
> > > > ---
> > > > .../gpu/drm/rockchip/analogix_dp-rockchip.c | 41 ++++++++++++++-----
> > > > 1 file changed, 30 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/
> > > > drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > > > index 0957d3c5d31d..3ae01b870f49 100644
> > > > --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > > > +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > > > @@ -124,13 +124,13 @@ static int rockchip_dp_poweron(struct
> > > > analogix_dp_plat_data *plat_data)
> > > > ret = clk_prepare_enable(dp->pclk);
> > > > if (ret < 0) {
> > > > - drm_err(dp->drm_dev, "failed to enable pclk %d\n", ret);
> > > > + dev_err(dp->dev, "failed to enable pclk %d\n", ret);
> > >
> > >
> > > why?
> > >
> >
> > The &rockchip_dp_device.drm_dev will be assigned in rockchip_dp_bind(),
> > which is called after probing process. The PM operations have been
> > advanced to the probing for the AUX transmission, so the dev_err() may
> > be better than drm_err().
> >
>
> Using drm_...() uniformly may be better [0].
Yes
>
> > > > return ret;
> > > > }
> > > > ret = rockchip_dp_pre_init(dp);
> > > > if (ret < 0) {
> > > > - drm_err(dp->drm_dev, "failed to dp pre init %d\n", ret);
> > > > + dev_err(dp->dev, "failed to dp pre init %d\n", ret);
> > > > clk_disable_unprepare(dp->pclk);
> > > > return ret;
> > > > }
> > >
>
> Best regards,
> Damon
>
> [0]https://patchwork.kernel.org/project/linux-rockchip/patch/20250109032725.1102465-6-damon.ding@rock-chips.com/#26209891
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: rockchip: fix Kconfig dependency more
From: Sebastian Reichel @ 2025-01-22 22:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Arnd Bergmann,
Cristian Ciocaltea, Zhang Yubing, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20250122065249.1390081-1-arnd@kernel.org>
Hi,
On Wed, Jan 22, 2025 at 07:52:44AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> A previous patch ensured that USB Type C connector support is enabled,
> but it is still possible to build the phy driver without enabling
> CONFIG_USB (host support) or CONFIG_USB_GADGET (device support), and
> in that case the common helper functions are unavailable:
>
> aarch64-linux-ld: drivers/phy/rockchip/phy-rockchip-usbdp.o: in function `rk_udphy_probe':
> phy-rockchip-usbdp.c:(.text+0xe74): undefined reference to `usb_get_maximum_speed'
>
> Select CONFIG_USB_COMMON directly here, like we do in some other phy
> drivers, to make sure this is available even when actual USB support
> is disabled or in a loadable module that cannot be reached from a
> built-in phy driver.
>
> Fixes: 9c79b779643e ("phy: rockchip: fix CONFIG_TYPEC dependency")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Thanks,
-- Sebastian
> drivers/phy/rockchip/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
> index 2f7a05f21dc5..dcb8e1628632 100644
> --- a/drivers/phy/rockchip/Kconfig
> +++ b/drivers/phy/rockchip/Kconfig
> @@ -125,6 +125,7 @@ config PHY_ROCKCHIP_USBDP
> depends on ARCH_ROCKCHIP && OF
> depends on TYPEC
> select GENERIC_PHY
> + select USB_COMMON
> help
> Enable this to support the Rockchip USB3.0/DP combo PHY with
> Samsung IP block. This is required for USB3 support on RK3588.
> --
> 2.39.5
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 05/12] clk: sunxi-ng: add CCU drivers for V853
From: Jeff Johnson @ 2025-01-22 23:23 UTC (permalink / raw)
To: Andras Szemzo, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Linus Walleij, Philipp Zabel, Maxime Ripard
Cc: Vinod Koul, Kishon Vijay Abraham I, Ulf Hansson, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Uwe Kleine-König,
Florian Fainelli, linux-clk, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-phy, linux-gpio, linux-pm,
linux-riscv
In-Reply-To: <20250110123923.270626-6-szemzo.andras@gmail.com>
On 1/10/25 04:39, Andras Szemzo wrote:> +module_platform_driver(sun8i_v853_r_ccu_driver);
> +
> +MODULE_IMPORT_NS("SUNXI_CCU");
> +MODULE_LICENSE("GPL");
Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the
description is missing"), a module without a MODULE_DESCRIPTION() will
result in a warning with make W=1. Please add a MODULE_DESCRIPTION()
to avoid this warning in all of your new modules.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add support for USB controllers on QCS615
From: Krishna Kurapati @ 2025-01-23 7:00 UTC (permalink / raw)
To: Vinod Koul
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Konrad Dybcio, Johan Hovold,
Manivannan Sadhasivam, linux-kernel, linux-arm-msm, linux-phy,
Dmitry Baryshkov
In-Reply-To: <318620fc-e174-4ef3-808a-69fe1d4e1df5@oss.qualcomm.com>
On 12/25/2024 2:01 PM, Krishna Kurapati wrote:
>
>
> On 12/25/2024 1:12 AM, Vinod Koul wrote:
>> On 24-12-24, 21:33, Dmitry Baryshkov wrote:
>>> On Wed, Dec 25, 2024 at 12:49:07AM +0530, Vinod Koul wrote:
>>>> On 24-12-24, 17:38, Dmitry Baryshkov wrote:
>>>>> On Tue, Dec 24, 2024 at 08:55:18PM +0530, Vinod Koul wrote:
>>>>>>
>>>>>> On Tue, 24 Dec 2024 14:16:18 +0530, Krishna Kurapati wrote:
>>>>>>> This series aims at enabling USB on QCS615 which has 2 USB
>>>>>>> controllers.
>>>>>>> The primary controller is SuperSpeed capable and secondary one is
>>>>>>> High Speed only capable. The High Speed Phy is a QUSB2 phy and the
>>>>>>> SuperSpeed Phy is a QMP Uni Phy which supports non-concurrent DP.
>>>>>>>
>>>>>>> Link to v1:
>>>>>>> https://lore.kernel.org/all/20241014084432.3310114-1-quic_kriskura@quicinc.com/
>>>>>>>
>>>>>>> [...]
>>>>>>
>>>>>> Applied, thanks!
>>>>>>
>>>>>> [2/3] phy: qcom-qusb2: Add support for QCS615
>>>>>> commit: 8adbf20e05025f588d68fb5b0fbbdab4e9a6f97ecommit
>>>>>> e1b2772ea957c91694aa91b90e4c0a1d7b0fb144
> Author: Krishna Kurapati <quic_kriskura@quicinc.com>
> Date: Mon Oct 14 14:14:30 2024 +0530
>
> dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for QCS615
>
>
>>>>>
>>>>> Is there any issue with the two remaining patches?
>>>>
>>>> Something wrong with b4... I have applied 2 & 3
>>>> Patch 1 should go thru USB tree
>>>
>>> Hmm, strange. But then, please excuse my ignorance, do we have bindings
>>> for these two patches?
>>
>> I see to have missed one!
>>
>> This one is documented see:
>> d146d384222e dt-bindings: phy: qcom,qusb2: Add bindings for QCS615
>>
>> but, the third patch is sadly not... I am dropping the third patch
>>
>
> Hi Dmitry, Vinod,
>
> I see the bindings for QMP PHY in linux next as follows:
>
> commit e1b2772ea957c91694aa91b90e4c0a1d7b0fb144
> Author: Krishna Kurapati <quic_kriskura@quicinc.com>
> Date: Mon Oct 14 14:14:30 2024 +0530
>
> dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for QCS615
>
> As mentioned in the cover letter, the bindings of phy have been merged
> from v1.
Hi Vinod,
Can you help in taking in the patch-3. As mentioned in previous mail,
the bindings are merged and present in linux-next.
Regards,
Krishna,
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add support for USB controllers on QCS615
From: Dmitry Baryshkov @ 2025-01-23 7:23 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Vinod Koul, Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Konrad Dybcio, Johan Hovold,
Manivannan Sadhasivam, linux-kernel, linux-arm-msm, linux-phy
In-Reply-To: <f607aa9b-018c-4df6-9921-725693353f65@oss.qualcomm.com>
On Thu, 23 Jan 2025 at 09:00, Krishna Kurapati
<krishna.kurapati@oss.qualcomm.com> wrote:
>
>
>
> On 12/25/2024 2:01 PM, Krishna Kurapati wrote:
> >
> >
> > On 12/25/2024 1:12 AM, Vinod Koul wrote:
> >> On 24-12-24, 21:33, Dmitry Baryshkov wrote:
> >>> On Wed, Dec 25, 2024 at 12:49:07AM +0530, Vinod Koul wrote:
> >>>> On 24-12-24, 17:38, Dmitry Baryshkov wrote:
> >>>>> On Tue, Dec 24, 2024 at 08:55:18PM +0530, Vinod Koul wrote:
> >>>>>>
> >>>>>> On Tue, 24 Dec 2024 14:16:18 +0530, Krishna Kurapati wrote:
> >>>>>>> This series aims at enabling USB on QCS615 which has 2 USB
> >>>>>>> controllers.
> >>>>>>> The primary controller is SuperSpeed capable and secondary one is
> >>>>>>> High Speed only capable. The High Speed Phy is a QUSB2 phy and the
> >>>>>>> SuperSpeed Phy is a QMP Uni Phy which supports non-concurrent DP.
> >>>>>>>
> >>>>>>> Link to v1:
> >>>>>>> https://lore.kernel.org/all/20241014084432.3310114-1-quic_kriskura@quicinc.com/
> >>>>>>>
> >>>>>>> [...]
> >>>>>>
> >>>>>> Applied, thanks!
> >>>>>>
> >>>>>> [2/3] phy: qcom-qusb2: Add support for QCS615
> >>>>>> commit: 8adbf20e05025f588d68fb5b0fbbdab4e9a6f97ecommit
> >>>>>> e1b2772ea957c91694aa91b90e4c0a1d7b0fb144
> > Author: Krishna Kurapati <quic_kriskura@quicinc.com>
> > Date: Mon Oct 14 14:14:30 2024 +0530
> >
> > dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for QCS615
> >
> >
> >>>>>
> >>>>> Is there any issue with the two remaining patches?
> >>>>
> >>>> Something wrong with b4... I have applied 2 & 3
> >>>> Patch 1 should go thru USB tree
> >>>
> >>> Hmm, strange. But then, please excuse my ignorance, do we have bindings
> >>> for these two patches?
> >>
> >> I see to have missed one!
> >>
> >> This one is documented see:
> >> d146d384222e dt-bindings: phy: qcom,qusb2: Add bindings for QCS615
> >>
> >> but, the third patch is sadly not... I am dropping the third patch
> >>
> >
> > Hi Dmitry, Vinod,
> >
> > I see the bindings for QMP PHY in linux next as follows:
> >
> > commit e1b2772ea957c91694aa91b90e4c0a1d7b0fb144
> > Author: Krishna Kurapati <quic_kriskura@quicinc.com>
> > Date: Mon Oct 14 14:14:30 2024 +0530
> >
> > dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for QCS615
> >
> > As mentioned in the cover letter, the bindings of phy have been merged
> > from v1.
>
> Hi Vinod,
>
> Can you help in taking in the patch-3. As mentioned in previous mail,
> the bindings are merged and present in linux-next.
We are currently in the merge window, no new patches can be accepted.
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 1/7] dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy
From: Krzysztof Kozlowski @ 2025-01-23 7:54 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: bhelgaas, lpieralisi, kw, manivannan.sadhasivam, robh, krzk+dt,
conor+dt, vkoul, kishon, andersson, konradybcio, p.zabel,
dmitry.baryshkov, quic_nsekar, linux-arm-msm, linux-pci,
devicetree, linux-kernel, linux-phy
In-Reply-To: <20250122063411.3503097-2-quic_varada@quicinc.com>
On Wed, Jan 22, 2025 at 12:04:05PM +0530, Varadarajan Narayanan wrote:
> From: Nitheesh Sekar <quic_nsekar@quicinc.com>
>
> Document the Qualcomm UNIPHY PCIe 28LP present in IPQ5332.
>
> Signed-off-by: Nitheesh Sekar <quic_nsekar@quicinc.com>
> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> ---
> v7: * Add data type definition to 'num-lanes'
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox