* Re: [RFC PATCH 2/2] phy: ti: j721e-wiz: Add SGMII support in WIZ driver for J784S4
From: Roger Quadros @ 2023-12-22 10:13 UTC (permalink / raw)
To: Chintan Vankar, Maxime Ripard, Uwe Kleine-König, Sinthu Raja,
Andrew Davis, Siddharth Vadapalli, Kishon Vijay Abraham I,
Vinod Koul
Cc: linux-kernel, linux-phy
In-Reply-To: <20231221102956.754617-2-c-vankar@ti.com>
On 21/12/2023 12:29, Chintan Vankar wrote:
> Enable full rate divider configuration support for J784S4_WIZ_10G
> for SGMII.
>
> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
--
cheers,
-roger
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RFC PATCH 1/2] phy: ti: gmii-sel: Enable SGMII mode for J784S4
From: Roger Quadros @ 2023-12-22 10:12 UTC (permalink / raw)
To: Chintan Vankar, Maxime Ripard, Uwe Kleine-König, Sinthu Raja,
Andrew Davis, Siddharth Vadapalli, Kishon Vijay Abraham I,
Vinod Koul
Cc: linux-kernel, linux-phy
In-Reply-To: <20231221102956.754617-1-c-vankar@ti.com>
On 21/12/2023 12:29, Chintan Vankar wrote:
> TI's J784S4 SoC supports SGMII mode with the CPSW9G instance of the CPSW
> Ethernet Switch. Thus, enable it by adding SGMII mode to the list of the
> corresponding extra_modes member.
>
> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
--
cheers,
-roger
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: cadence-torrent: Add USXGMII(156.25MHz) + SGMII/QSGMII(100MHz) multilink config for TI J7200
From: Roger Quadros @ 2023-12-22 10:11 UTC (permalink / raw)
To: Swapnil Jakhade, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, linux-kernel, devicetree
Cc: mparab, s-vadapalli
In-Reply-To: <20231221162051.2131202-6-sjakhade@cadence.com>
On 21/12/2023 18:20, Swapnil Jakhade wrote:
> Add a separate compatible and registers map table for TI J7200.
> TI J7200 uses Torrent SD0805 version which is a special version
> derived from Torrent SD0801 with some differences in register
> configurations.
>
> Add register sequences for USXGMII(156.25MHz) + SGMII/QSGMII(100MHz)
> multilink config for TI J7200. USXGMII uses PLL0 and SGMII/QSGMII
> uses PLL1.
>
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
--
cheers,
-roger
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 4/5] dt-bindings: phy: cadence-torrent: Add a separate compatible for TI J7200
From: Roger Quadros @ 2023-12-22 10:11 UTC (permalink / raw)
To: Swapnil Jakhade, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, linux-kernel, devicetree
Cc: mparab, s-vadapalli
In-Reply-To: <20231221162051.2131202-5-sjakhade@cadence.com>
On 21/12/2023 18:20, Swapnil Jakhade wrote:
> TI J7200 uses Torrent SD0805 version which is a special version derived
> from Torrent SD0801 with some differences in register configurations.
> Add a separate compatible for TI J7200 platforms.
>
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
--
cheers,
-roger
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/5] phy: cadence-torrent: Add USXGMII(156.25MHz) + SGMII/QSGMII(100MHz) multilink configuration
From: Roger Quadros @ 2023-12-22 10:11 UTC (permalink / raw)
To: Swapnil Jakhade, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, linux-kernel, devicetree
Cc: mparab, s-vadapalli
In-Reply-To: <20231221162051.2131202-4-sjakhade@cadence.com>
On 21/12/2023 18:20, Swapnil Jakhade wrote:
> Add register sequences for USXGMII(156.25MHz) + SGMII/QSGMII(100MHz)
> multilink configuration. USXGMII uses PLL0 and SGMII/QSGMII uses PLL1.
>
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
--
cheers,
-roger
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: cadence-torrent: Add optional input reference clock for PLL1
From: Roger Quadros @ 2023-12-22 10:10 UTC (permalink / raw)
To: Swapnil Jakhade, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, linux-kernel, devicetree
Cc: mparab, s-vadapalli
In-Reply-To: <20231221162051.2131202-2-sjakhade@cadence.com>
On 21/12/2023 18:20, Swapnil Jakhade wrote:
> Add a new optional input reference clock (pll1_refclk) for PLL1.
> Update bindings to support dual reference clock multilink configurations.
>
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
--
cheers,
-roger
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 2/5] phy: cadence-torrent: Add PCIe(100MHz) + USXGMII(156.25MHz) multilink configuration
From: Roger Quadros @ 2023-12-22 10:07 UTC (permalink / raw)
To: Swapnil Jakhade, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, linux-kernel, devicetree
Cc: mparab, s-vadapalli
In-Reply-To: <20231221162051.2131202-3-sjakhade@cadence.com>
Hi Swapnil,
On 21/12/2023 18:20, Swapnil Jakhade wrote:
> Torrent PHY can have separate input reference clocks for PLL0 and PLL1.
> Add support for dual reference clock multilink configurations.
>
> Add register sequences for PCIe(100MHz) + USXGMII(156.25MHz) multilink
> configuration. PCIe uses PLL0 and USXGMII uses PLL1.
>
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
> ---
> drivers/phy/cadence/phy-cadence-torrent.c | 194 +++++++++++++++++++++-
> 1 file changed, 191 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/cadence/phy-cadence-torrent.c b/drivers/phy/cadence/phy-cadence-torrent.c
> index a75c96385c57..18ec49c9a76e 100644
> --- a/drivers/phy/cadence/phy-cadence-torrent.c
> +++ b/drivers/phy/cadence/phy-cadence-torrent.c
> @@ -355,7 +355,9 @@ struct cdns_torrent_phy {
> struct reset_control *apb_rst;
> struct device *dev;
> struct clk *clk;
> + struct clk *clk1;
> enum cdns_torrent_ref_clk ref_clk_rate;
> + enum cdns_torrent_ref_clk ref_clk1_rate;
> struct cdns_torrent_inst phys[MAX_NUM_LANES];
> int nsubnodes;
> const struct cdns_torrent_data *init_data;
> @@ -2460,9 +2462,11 @@ int cdns_torrent_phy_configure_multilink(struct cdns_torrent_phy *cdns_phy)
> {
> const struct cdns_torrent_data *init_data = cdns_phy->init_data;
> struct cdns_torrent_vals *cmn_vals, *tx_ln_vals, *rx_ln_vals;
> + enum cdns_torrent_ref_clk ref_clk1 = cdns_phy->ref_clk1_rate;
> enum cdns_torrent_ref_clk ref_clk = cdns_phy->ref_clk_rate;
> struct cdns_torrent_vals *link_cmn_vals, *xcvr_diag_vals;
> enum cdns_torrent_phy_type phy_t1, phy_t2;
> + struct cdns_torrent_vals *phy_pma_cmn_vals;
> struct cdns_torrent_vals *pcs_cmn_vals;
> int i, j, node, mlane, num_lanes, ret;
> struct cdns_reg_pairs *reg_pairs;
> @@ -2489,6 +2493,7 @@ int cdns_torrent_phy_configure_multilink(struct cdns_torrent_phy *cdns_phy)
> * Get the array values as [phy_t2][phy_t1][ssc].
> */
> swap(phy_t1, phy_t2);
> + swap(ref_clk, ref_clk1);
> }
>
> mlane = cdns_phy->phys[node].mlane;
> @@ -2552,9 +2557,22 @@ int cdns_torrent_phy_configure_multilink(struct cdns_torrent_phy *cdns_phy)
> reg_pairs[i].val);
> }
>
> + /* PHY PMA common registers configurations */
> + phy_pma_cmn_vals = cdns_torrent_get_tbl_vals(&init_data->phy_pma_cmn_vals_tbl,
> + CLK_ANY, CLK_ANY,
> + phy_t1, phy_t2, ANY_SSC);
> + if (phy_pma_cmn_vals) {
> + reg_pairs = phy_pma_cmn_vals->reg_pairs;
> + num_regs = phy_pma_cmn_vals->num_regs;
> + regmap = cdns_phy->regmap_phy_pma_common_cdb;
> + for (i = 0; i < num_regs; i++)
> + regmap_write(regmap, reg_pairs[i].off,
> + reg_pairs[i].val);
> + }
> +
> /* PMA common registers configurations */
> cmn_vals = cdns_torrent_get_tbl_vals(&init_data->cmn_vals_tbl,
> - ref_clk, ref_clk,
> + ref_clk, ref_clk1,
> phy_t1, phy_t2, ssc);
> if (cmn_vals) {
> reg_pairs = cmn_vals->reg_pairs;
> @@ -2567,7 +2585,7 @@ int cdns_torrent_phy_configure_multilink(struct cdns_torrent_phy *cdns_phy)
>
> /* PMA TX lane registers configurations */
> tx_ln_vals = cdns_torrent_get_tbl_vals(&init_data->tx_ln_vals_tbl,
> - ref_clk, ref_clk,
> + ref_clk, ref_clk1,
> phy_t1, phy_t2, ssc);
> if (tx_ln_vals) {
> reg_pairs = tx_ln_vals->reg_pairs;
> @@ -2582,7 +2600,7 @@ int cdns_torrent_phy_configure_multilink(struct cdns_torrent_phy *cdns_phy)
>
> /* PMA RX lane registers configurations */
> rx_ln_vals = cdns_torrent_get_tbl_vals(&init_data->rx_ln_vals_tbl,
> - ref_clk, ref_clk,
> + ref_clk, ref_clk1,
> phy_t1, phy_t2, ssc);
> if (rx_ln_vals) {
> reg_pairs = rx_ln_vals->reg_pairs;
> @@ -2684,9 +2702,11 @@ static int cdns_torrent_reset(struct cdns_torrent_phy *cdns_phy)
> static int cdns_torrent_clk(struct cdns_torrent_phy *cdns_phy)
> {
> struct device *dev = cdns_phy->dev;
> + unsigned long ref_clk1_rate;
> unsigned long ref_clk_rate;
> int ret;
>
> + /* refclk: Input reference clock for PLL0 */
> cdns_phy->clk = devm_clk_get(dev, "refclk");
> if (IS_ERR(cdns_phy->clk)) {
> dev_err(dev, "phy ref clock not found\n");
> @@ -2725,7 +2745,54 @@ static int cdns_torrent_clk(struct cdns_torrent_phy *cdns_phy)
> return -EINVAL;
> }
>
> + /* refclk1: Input reference clock for PLL1 */
> + cdns_phy->clk1 = devm_clk_get_optional(dev, "pll1_refclk");
> + if (IS_ERR(cdns_phy->clk1)) {
> + dev_err(dev, "phy pll1 ref clock not found\n");
> + return PTR_ERR(cdns_phy->clk1);
Don't you need to disable cdns_phy->clk before exititing?
So
ret = PTR_ERR(cdns_phy->clk1);
goto disbale_clk;
> + }
> +
> + if (cdns_phy->clk1) {
> + ret = clk_prepare_enable(cdns_phy->clk1);
> + if (ret) {
> + dev_err(cdns_phy->dev, "Failed to prepare pll1 ref clock\n");
nit, pll should be all uppercase in error messages. so "PLL1"?
Do you wan't to dump the return error code as well so it is easier to report/debug?
> + clk_disable_unprepare(cdns_phy->clk);
> + return ret;
Instead of above 2 lines, just:
goto disable_clk.
> + }
> +
> + ref_clk1_rate = clk_get_rate(cdns_phy->clk1);
> + if (!ref_clk1_rate) {
> + dev_err(cdns_phy->dev, "Failed to get pll1 ref clock rate\n");
> + goto refclk1_err;
For consistency let's call this label disable_clk1
> + }
> +
> + switch (ref_clk1_rate) {
> + case REF_CLK_19_2MHZ:
> + cdns_phy->ref_clk1_rate = CLK_19_2_MHZ;
> + break;
> + case REF_CLK_25MHZ:
> + cdns_phy->ref_clk1_rate = CLK_25_MHZ;
> + break;
> + case REF_CLK_100MHZ:
> + cdns_phy->ref_clk1_rate = CLK_100_MHZ;
> + break;
> + case REF_CLK_156_25MHZ:
> + cdns_phy->ref_clk1_rate = CLK_156_25_MHZ;
> + break;
> + default:
> + dev_err(cdns_phy->dev, "Invalid pll1 ref clock rate\n");
> + goto refclk1_err;
> + }
> + } else {
> + cdns_phy->ref_clk1_rate = cdns_phy->ref_clk_rate;
> + }
> +
> return 0;
> +
> +refclk1_err:
> + clk_disable_unprepare(cdns_phy->clk1);
disable_clk:
> + clk_disable_unprepare(cdns_phy->clk);
> + return -EINVAL;
return ret. We need to preserve why the failure
happened so it is easier to debug.
> }
>
> static int cdns_torrent_phy_probe(struct platform_device *pdev)
> @@ -2981,6 +3048,7 @@ static int cdns_torrent_phy_probe(struct platform_device *pdev)
> of_node_put(child);
> reset_control_assert(cdns_phy->apb_rst);
> clk_disable_unprepare(cdns_phy->clk);
> + clk_disable_unprepare(cdns_phy->clk1);
No sure if it matters, but for symmetry sake should we disable clk1 before clk?
> clk_cleanup:
> cdns_torrent_clk_cleanup(cdns_phy);
> return ret;
> @@ -2999,6 +3067,7 @@ static void cdns_torrent_phy_remove(struct platform_device *pdev)
> }
>
> clk_disable_unprepare(cdns_phy->clk);
> + clk_disable_unprepare(cdns_phy->clk1);
Here too.
> cdns_torrent_clk_cleanup(cdns_phy);
> }
>
> @@ -3034,6 +3103,100 @@ static struct cdns_torrent_vals dp_usb_xcvr_diag_ln_vals = {
> .num_regs = ARRAY_SIZE(dp_usb_xcvr_diag_ln_regs),
> };
<snip>
--
cheers,
-roger
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RFC PATCH 2/2] dt-bindings: display: msm: mass-rename files
From: Aiqun Yu (Maria) @ 2023-12-22 8:58 UTC (permalink / raw)
To: Rob Herring, Dmitry Baryshkov
Cc: freedreno, Marijn Suijten, Daniel Vetter, Rob Clark,
Jonathan Marek, Vinod Koul, Konrad Dybcio, Stephen Boyd,
Sean Paul, Krzysztof Kozlowski, linux-phy, dri-devel, Andy Gross,
Krishna Manikandan, Kishon Vijay Abraham I, linux-arm-msm,
Bjorn Andersson, David Airlie, Rob Herring, devicetree,
Abhinav Kumar
In-Reply-To: <170319289437.96441.9965499072649831420.robh@kernel.org>
On 12/22/2023 5:08 AM, Rob Herring wrote:
>
> On Thu, 21 Dec 2023 12:25:06 +0200, Dmitry Baryshkov wrote:
>> Rename the Qualcomm MSM Display schemas to follow the main compatible
>> string instead of just using the block type. This follows the
>> established practice for YAML file names.
>>
>> Cc: Aiqun Yu (Maria) <quic_aiquny@quicinc.com>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> ---
>> .../bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} | 2 +-
>> .../bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} | 2 +-
>> .../bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} | 2 +-
>> .../bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml} | 2 +-
>> .../msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} | 2 +-
>> 5 files changed, 5 insertions(+), 5 deletions(-)
>> rename Documentation/devicetree/bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} (99%)
>> rename Documentation/devicetree/bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} (99%)
>> rename Documentation/devicetree/bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} (98%)
>> rename Documentation/devicetree/bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml} (97%)
>> rename Documentation/devicetree/bindings/display/msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} (99%)
>>
>
> Acked-by: Rob Herring <robh@kernel.org>
> Nice to see names get more unified!
--
Thx and BRs,
Aiqun(Maria) Yu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 09/10] phy: qualcomm: phy-qcom-qmp-ufs: Rectify SM8550 UFS HS-G4 PHY Settings
From: Can Guo @ 2023-12-22 7:41 UTC (permalink / raw)
To: Vinod Koul
Cc: bvanassche, mani, adrian.hunter, beanhuo, avri.altman,
junwoo80.lee, martin.petersen, linux-scsi, linux-arm-msm,
Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Dmitry Baryshkov, Abel Vesa, Johan Hovold,
open list:GENERIC PHY FRAMEWORK, open list
In-Reply-To: <ZYRyJU9klhZzLdni@matsya>
Hi Vinod,
On 12/22/2023 1:13 AM, Vinod Koul wrote:
> On 02-12-23, 04:36, Can Guo wrote:
>> The registers, which are being touched in current SM8550 UFS PHY settings,
>> and the values being programmed are mainly the ones working for HS-G4 mode,
>> meanwhile, there are also a few ones somehow taken from HS-G5 PHY settings.
>> However, even consider HS-G4 mode only, some of them are incorrect and some
>> are missing. Rectify the HS-G4 PHY settings by strictly aligning with the
>> SM8550 UFS PHY Hardware Programming Guide suggested HS-G4 PHY settings.
>
> This fails for me, as I have picked Abels offset series, can you please
> rebase these two patches and send
>
In v8, I rebased the two changes to linux-next. Is the ask there to
rebase the two changes to phy/next?
Thanks,
Can Guo.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 06/13] of: property: fw_devlink: Add support for "access-controller"
From: Rob Herring @ 2023-12-21 22:01 UTC (permalink / raw)
To: Gatien Chevallier
Cc: mchehab, rcsekar, olivier.moysan, Frank Rowand, dmaengine,
linux-crypto, jic23, lars, mkl, linux-kernel, linux-spi, davem,
conor+dt, fabrice.gasnier, pabeni, linux-media, catalin.marinas,
netdev, Oleksii_Moisieiev, linux-serial, hugues.fruchet,
linux-usb, linux-mmc, arnd, linux-iio, will, edumazet,
linux-stm32, krzysztof.kozlowski+dt, ulf.hansson,
alexandre.torgue, devicetree, linux-i2c, herbert, vkoul, robh+dt,
kuba, wg, lee, peng.fan, linux-phy, arnaud.pouliquen, gregkh,
richardcochran, linux-arm-kernel, andi.shyti, alsa-devel
In-Reply-To: <20231212152356.345703-7-gatien.chevallier@foss.st.com>
On Tue, 12 Dec 2023 16:23:49 +0100, Gatien Chevallier wrote:
> Allows tracking dependencies between devices and their access
> controller.
>
> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
> ---
>
> Changes in V6:
> - Renamed access-controller to access-controllers
>
> Changes in V5:
> - Rename feature-domain* to access-control*
>
> Patch not present in V1
>
> drivers/of/property.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RFC PATCH 2/2] dt-bindings: display: msm: mass-rename files
From: Rob Herring @ 2023-12-21 21:08 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: freedreno, Marijn Suijten, Daniel Vetter, Rob Clark,
Jonathan Marek, Vinod Koul, Konrad Dybcio, Stephen Boyd,
Sean Paul, Krzysztof Kozlowski, linux-phy, dri-devel, Andy Gross,
Krishna Manikandan, Kishon Vijay Abraham I, linux-arm-msm,
Bjorn Andersson, Aiqun Yu, David Airlie, Rob Herring, devicetree,
Abhinav Kumar
In-Reply-To: <20231221102506.18320-3-dmitry.baryshkov@linaro.org>
On Thu, 21 Dec 2023 12:25:06 +0200, Dmitry Baryshkov wrote:
> Rename the Qualcomm MSM Display schemas to follow the main compatible
> string instead of just using the block type. This follows the
> established practice for YAML file names.
>
> Cc: Aiqun Yu (Maria) <quic_aiquny@quicinc.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> .../bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} | 2 +-
> .../bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} | 2 +-
> .../bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} | 2 +-
> .../bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml} | 2 +-
> .../msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
> rename Documentation/devicetree/bindings/display/msm/{gmu.yaml => qcom,adreno-gmu.yaml} (99%)
> rename Documentation/devicetree/bindings/display/msm/{gpu.yaml => qcom,adreno.yaml} (99%)
> rename Documentation/devicetree/bindings/display/msm/{hdmi.yaml => qcom,hdmi-tx.yaml} (98%)
> rename Documentation/devicetree/bindings/display/msm/{mdp4.yaml => qcom,mdp4.yaml} (97%)
> rename Documentation/devicetree/bindings/display/msm/{dsi-controller-main.yaml => qcom,mdss-dsi-ctrl.yaml} (99%)
>
Acked-by: Rob Herring <robh@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: display: msm: move DSI PHY schema to bindings/phy
From: Rob Herring @ 2023-12-21 21:07 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Jonathan Marek, Marijn Suijten, linux-phy, Krishna Manikandan,
Vinod Koul, devicetree, Stephen Boyd, Rob Herring, Sean Paul,
Kishon Vijay Abraham I, Daniel Vetter, Abhinav Kumar, Andy Gross,
linux-arm-msm, dri-devel, Krzysztof Kozlowski, Bjorn Andersson,
Konrad Dybcio, Rob Clark, freedreno, David Airlie
In-Reply-To: <20231221102506.18320-2-dmitry.baryshkov@linaro.org>
On Thu, 21 Dec 2023 12:25:05 +0200, Dmitry Baryshkov wrote:
> While the DSI PHY schema files describe the display-related hardware,
> they still describe a PHY. Move all DSI PHY schema files to the phy/
> subdir.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> .../msm/dsi-phy-10nm.yaml => phy/qcom,dsi-phy-10nm.yaml} | 4 ++--
> .../msm/dsi-phy-14nm.yaml => phy/qcom,dsi-phy-14nm.yaml} | 4 ++--
> .../msm/dsi-phy-20nm.yaml => phy/qcom,dsi-phy-20nm.yaml} | 4 ++--
> .../msm/dsi-phy-28nm.yaml => phy/qcom,dsi-phy-28nm.yaml} | 4 ++--
> .../msm/dsi-phy-7nm.yaml => phy/qcom,dsi-phy-7nm.yaml} | 4 ++--
> .../msm/dsi-phy-common.yaml => phy/qcom,dsi-phy-common.yaml} | 2 +-
> 6 files changed, 11 insertions(+), 11 deletions(-)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-10nm.yaml => phy/qcom,dsi-phy-10nm.yaml} (96%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-14nm.yaml => phy/qcom,dsi-phy-14nm.yaml} (94%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-20nm.yaml => phy/qcom,dsi-phy-20nm.yaml} (93%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-28nm.yaml => phy/qcom,dsi-phy-28nm.yaml} (94%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-7nm.yaml => phy/qcom,dsi-phy-7nm.yaml} (94%)
> rename Documentation/devicetree/bindings/{display/msm/dsi-phy-common.yaml => phy/qcom,dsi-phy-common.yaml} (90%)
>
Acked-by: Rob Herring <robh@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: cadence-torrent: Add optional input reference clock for PLL1
From: Krzysztof Kozlowski @ 2023-12-21 20:35 UTC (permalink / raw)
To: Swapnil Jakhade, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, linux-kernel, devicetree
Cc: mparab, rogerq, s-vadapalli
In-Reply-To: <20231221162051.2131202-2-sjakhade@cadence.com>
On 21/12/2023 17:20, Swapnil Jakhade wrote:
> Add a new optional input reference clock (pll1_refclk) for PLL1.
> Update bindings to support dual reference clock multilink configurations.
>
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Acked-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
* Re: [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: fix path to header
From: Vinod Koul @ 2023-12-21 17:15 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Krzysztof Kozlowski
Cc: stable
In-Reply-To: <20231218130553.45893-1-krzysztof.kozlowski@linaro.org>
On Mon, 18 Dec 2023 14:05:53 +0100, Krzysztof Kozlowski wrote:
> Fix the path to bindings header in description.
>
>
Applied, thanks!
[1/1] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: fix path to header
commit: 21a1d02579ae75fd45555b84d20ba55632a14a19
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/7] phy: qcom: Add register offsets for v6 and v7
From: Vinod Koul @ 2023-12-21 17:16 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Dmitry Baryshkov, Abel Vesa
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <20231122-phy-qualcomm-v6-v6-20-v7-new-offsets-v3-0-dfd1c375ef61@linaro.org>
On Thu, 07 Dec 2023 14:19:09 +0200, Abel Vesa wrote:
> This patchset adds some missing register offsets for the v6 and v6.20,
> as well as the new v7 ones. These register offsets are used by the
> new Qualcomm Snapdragon X Elite (X1E80100) platform.
>
>
Applied, thanks!
[1/7] phy: qcom-qmp: qserdes-com: Add some more v6 register offsets
commit: 2226ec072ed3f1bd3f8dbe0cbf0e6cad699aedc2
[2/7] phy: qcom-qmp: qserdes-txrx: Add some more v6.20 register offsets
commit: a40542507b9045da03f4e013ab8562f6e6fe8aad
[3/7] phy: qcom-qmp: pcs: Add v7 register offsets
commit: 7b98cf0e9b5f8a05a7f0f0d06d3cfa130bb576e2
[4/7] phy: qcom-qmp: pcs-usb: Add v7 register offsets
commit: 8d4f9f801095b120e433d935b296baf0e3bdc6a0
[5/7] phy: qcom-qmp: qserdes-com: Add v7 register offsets
commit: bc546cc85c1d92d9ba7b278b77016b7d4334fafa
[6/7] phy: qcom-qmp: qserdes-txrx: Add V6 N4 register offsets
commit: 762c3565f3c8105603089eeaa0501e5089922221
[7/7] phy: qcom-qmp: qserdes-txrx: Add v7 register offsets
commit: ee6fcc0f337d6790b46838bab76c36e8bdd5658e
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: renesas: phy-rcar-gen2: use select for GENERIC_PHY
From: Vinod Koul @ 2023-12-21 17:16 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap; +Cc: Kishon Vijay Abraham I, linux-phy
In-Reply-To: <20231204234917.23509-1-rdunlap@infradead.org>
On Mon, 04 Dec 2023 15:49:17 -0800, Randy Dunlap wrote:
> Change the last "depends on GENERIC_PHY" to use select, like the
> other 170+ Kconfig users do. This can help prevent circular
> dependency issues.
>
>
Applied, thanks!
[1/1] phy: renesas: phy-rcar-gen2: use select for GENERIC_PHY
commit: 54c899f0d647e5724b02486243da40134dc91c45
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/2] phy: qcom: qmp-usb: Add support for X1E80100 USB3 PHY
From: Vinod Koul @ 2023-12-21 17:16 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold, Dmitry Baryshkov, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20231122-phy-qualcomm-usb3-uniphy-x1e80100-v3-0-273814c300f8@linaro.org>
On Thu, 07 Dec 2023 14:34:10 +0200, Abel Vesa wrote:
> This patchset adds support for USB3 PHYs instances found on X1E80100.
> It depends on the v7 register offsets added by the following patchset:
>
> https://lore.kernel.org/all/20231122-phy-qualcomm-v6-v6-20-v7-new-offsets-v3-0-dfd1c375ef61@linaro.org/
>
>
Applied, thanks!
[1/2] dt-bindings: phy: qcom,sc8280xp-qmp-usb3-uni: Add X1E80100 USB PHY binding
commit: c5ffffd714373e7c6b39d3b005dbfbaadbbb4d2d
[2/2] phy: qcom-qmp-usb: Add Qualcomm X1E80100 USB3 PHY support
commit: 2daa9555ba9858c29b9734b3a104c338b718feab
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/2] phy: qcom-qmp-combo: Add support for X1E80100 platform
From: Vinod Koul @ 2023-12-21 17:16 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Johan Hovold, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20231201-x1e80100-phy-combo-v1-0-6938ec41f3ac@linaro.org>
On Thu, 07 Dec 2023 15:16:40 +0200, Abel Vesa wrote:
> This patchset adds support for the USB/DP combo PHYs found on X1E80100
> platform and documents its compatible string.
>
> It depends on the v6 N4 register offsets added by the following patchset:
> https://lore.kernel.org/all/20231122-phy-qualcomm-v6-v6-20-v7-new-offsets-v3-0-dfd1c375ef61@linaro.org/
>
>
> [...]
Applied, thanks!
[1/2] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Document X1E80100 compatible
commit: f11aeb9d49632afc7abd9dfea6bcf5b3dd8addc1
[2/2] phy: qcom-qmp-combo: Add x1e80100 USB/DP combo phys
commit: d7b3579f84f74e0f7d88d180d4e15c679786b648
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: phy: qcom: snps-eusb2: Document the X1E80100 compatible
From: Vinod Koul @ 2023-12-21 17:16 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20231122-phy-qualcomm-eusb2-x1e80100-v2-1-3ba9a8e5ade4@linaro.org>
On Thu, 07 Dec 2023 14:49:10 +0200, Abel Vesa wrote:
> Add the X1E80100 compatible to the list of supported PHYs.
>
>
Applied, thanks!
[1/1] dt-bindings: phy: qcom: snps-eusb2: Document the X1E80100 compatible
commit: ec80c175c096eb752d581ef0aafb12ed46010b2a
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: phy: mediatek: tphy: add a property for force-mode switch
From: Vinod Koul @ 2023-12-21 17:15 UTC (permalink / raw)
To: Rob Herring, Chunfeng Yun
Cc: Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-arm-kernel, linux-mediatek,
linux-phy, devicetree, linux-kernel, Macpaul Lin
In-Reply-To: <20231211025624.28991-1-chunfeng.yun@mediatek.com>
On Mon, 11 Dec 2023 10:56:23 +0800, Chunfeng Yun wrote:
> Due to some old SoCs with shared t-phy between usb3 and pcie only support
> force-mode switch, and shared and non-shared t-phy may exist at the same
> time on a SoC, can't use compatible to distinguish between shared and
> non-shared t-phy, add a property to supported it.
> Currently, only support switch from default pcie mode to usb3 mode.
> But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: phy: mediatek: tphy: add a property for force-mode switch
commit: cc230a4cd8e91f64c90b5494dfd76848197418ed
[2/2] phy: mediatek: tphy: add support force phy mode switch
commit: 9b27303003f5af0d378f29ccccea57c7d65cc642
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: phy-can-transceiver: insert space after include
From: Vinod Koul @ 2023-12-21 17:15 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Kishon Vijay Abraham I,
linux-can, linux-phy, linux-kernel, Wang Jinchao
Cc: stone.xulei
In-Reply-To: <202312151407+0800-wangjinchao@xfusion.com>
On Fri, 15 Dec 2023 14:09:00 +0800, Wang Jinchao wrote:
> Maintain Consistent Formatting: Insert Space after #include
>
>
Applied, thanks!
[1/1] phy: phy-can-transceiver: insert space after include
commit: 57f31e911eaa5e682c0a03253f8b4348adee52cb
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 09/10] phy: qualcomm: phy-qcom-qmp-ufs: Rectify SM8550 UFS HS-G4 PHY Settings
From: Vinod Koul @ 2023-12-21 17:13 UTC (permalink / raw)
To: Can Guo
Cc: bvanassche, mani, adrian.hunter, beanhuo, avri.altman,
junwoo80.lee, martin.petersen, linux-scsi, linux-arm-msm,
Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Dmitry Baryshkov, Abel Vesa, Johan Hovold,
open list:GENERIC PHY FRAMEWORK, open list
In-Reply-To: <1701520577-31163-10-git-send-email-quic_cang@quicinc.com>
On 02-12-23, 04:36, Can Guo wrote:
> The registers, which are being touched in current SM8550 UFS PHY settings,
> and the values being programmed are mainly the ones working for HS-G4 mode,
> meanwhile, there are also a few ones somehow taken from HS-G5 PHY settings.
> However, even consider HS-G4 mode only, some of them are incorrect and some
> are missing. Rectify the HS-G4 PHY settings by strictly aligning with the
> SM8550 UFS PHY Hardware Programming Guide suggested HS-G4 PHY settings.
This fails for me, as I have picked Abels offset series, can you please
rebase these two patches and send
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RFC PATCH net-next v3 2/8] phy: add driver for MediaTek pextp 10GE SerDes PHY
From: Vinod Koul @ 2023-12-21 16:48 UTC (permalink / raw)
To: Daniel Golle
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun,
Kishon Vijay Abraham I, Felix Fietkau, John Crispin, Sean Wang,
Mark Lee, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Andrew Lunn, Heiner Kallweit,
Russell King, Alexander Couzens, Qingfang Deng, SkyLake Huang,
Philipp Zabel, netdev, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-phy
In-Reply-To: <a58dae1cce1b49093b0ae05159c784a9ec02f058.1702352117.git.daniel@makrotopia.org>
On 12-12-23, 03:46, Daniel Golle wrote:
> Add driver for MediaTek's pextp 10 Gigabit/s Ethernet SerDes PHY which
> can be found in the MT7988 SoC.
>
> The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> PHY_INTERFACE_MODE_* corresponding to the supported modes:
>
> * USXGMII
> * 10GBase-R
> * 5GBase-R
> * 2500Base-X
> * 1000Base-X
> * Cisco SGMII (MAC side)
>
> In order to work-around a performance issue present on the first of
> two PEXTP present in MT7988 special tuning is applied which can be
> selected by adding the mediatek,usxgmii-performance-errata property to
> the device tree node.
>
> There is no documentation what-so-ever for the pextp registers and
> this driver is based on a GPL licensed implementation found in
> MediaTek's SDK.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> MAINTAINERS | 1 +
> drivers/phy/mediatek/Kconfig | 11 +
> drivers/phy/mediatek/Makefile | 1 +
> drivers/phy/mediatek/phy-mtk-pextp.c | 361 +++++++++++++++++++++++++++
> 4 files changed, 374 insertions(+)
> create mode 100644 drivers/phy/mediatek/phy-mtk-pextp.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 98f7dd0499f17..b2772cfe2a704 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13510,6 +13510,7 @@ L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/phy/mediatek-ge-soc.c
> F: drivers/net/phy/mediatek-ge.c
> +F: drivers/phy/mediatek/phy-mtk-pextp.c
>
> MEDIATEK I2C CONTROLLER DRIVER
> M: Qii Wang <qii.wang@mediatek.com>
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index 3125ecb5d119f..a7749a6d96541 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -13,6 +13,17 @@ config PHY_MTK_PCIE
> callback for PCIe GEN3 port, it supports software efuse
> initialization.
>
> +config PHY_MTK_PEXTP
> + tristate "MediaTek PEXTP Driver"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on OF && OF_ADDRESS
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + help
> + Say 'Y' here to add support for MediaTek pextp PHY driver.
> + The driver provides access to the Ethernet SerDes PHY supporting
> + various 1GE, 2.5GE, 5GE and 10GE modes.
> +
> config PHY_MTK_TPHY
> tristate "MediaTek T-PHY Driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index c9a50395533eb..ca60c7b9b02ac 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE) += phy-mtk-pcie.o
> obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> +obj-$(CONFIG_PHY_MTK_PEXTP) += phy-mtk-pextp.o
alphabetically sorted please
>
> phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> diff --git a/drivers/phy/mediatek/phy-mtk-pextp.c b/drivers/phy/mediatek/phy-mtk-pextp.c
> new file mode 100644
> index 0000000000000..3ec48cf129105
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-pextp.c
> @@ -0,0 +1,361 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/* MediaTek 10GE SerDes PHY driver
> + *
> + * Copyright (c) 2023 Daniel Golle <daniel@makrotopia.org>
> + * based on mtk_usxgmii.c found in MediaTek's SDK released under GPL-2.0
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Henry Yen <henry.yen@mediatek.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/netdevice.h>
why do you need this header?
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/phy.h>
> +#include <linux/phy/phy.h>
> +
> +#define MTK_PEXTP_NUM_CLOCKS 2
> +
> +struct mtk_pextp_phy {
> + void __iomem *base;
> + struct device *dev;
> + struct reset_control *reset;
> + struct clk_bulk_data clocks[MTK_PEXTP_NUM_CLOCKS];
> + bool da_war;
> +};
> +
> +static bool mtk_interface_mode_is_xgmii(phy_interface_t interface)
> +{
> + switch (interface) {
> + case PHY_INTERFACE_MODE_INTERNAL:
> + case PHY_INTERFACE_MODE_USXGMII:
> + case PHY_INTERFACE_MODE_10GBASER:
> + case PHY_INTERFACE_MODE_5GBASER:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static void mtk_pextp_setup(struct mtk_pextp_phy *pextp, phy_interface_t interface)
> +{
> + bool is_10g = (interface == PHY_INTERFACE_MODE_10GBASER ||
> + interface == PHY_INTERFACE_MODE_USXGMII);
> + bool is_2p5g = (interface == PHY_INTERFACE_MODE_2500BASEX);
> + bool is_5g = (interface == PHY_INTERFACE_MODE_5GBASER);
> +
> + dev_dbg(pextp->dev, "setting up for mode %s\n", phy_modes(interface));
> +
> + /* Setup operation mode */
> + if (is_10g)
> + iowrite32(0x00c9071c, pextp->base + 0x9024);
> + else
> + iowrite32(0x00d9071c, pextp->base + 0x9024);
> +
> + if (is_5g)
> + iowrite32(0xaaa5a5aa, pextp->base + 0x2020);
> + else
> + iowrite32(0xaa8585aa, pextp->base + 0x2020);
> +
> + if (is_2p5g || is_5g || is_10g) {
> + iowrite32(0x0c020707, pextp->base + 0x2030);
> + iowrite32(0x0e050f0f, pextp->base + 0x2034);
> + iowrite32(0x00140032, pextp->base + 0x2040);
> + } else {
> + iowrite32(0x0c020207, pextp->base + 0x2030);
> + iowrite32(0x0e05050f, pextp->base + 0x2034);
> + iowrite32(0x00200032, pextp->base + 0x2040);
> + }
> +
> + if (is_2p5g || is_10g)
> + iowrite32(0x00c014aa, pextp->base + 0x50f0);
> + else if (is_5g)
> + iowrite32(0x00c018aa, pextp->base + 0x50f0);
> + else
> + iowrite32(0x00c014ba, pextp->base + 0x50f0);
> +
> + if (is_5g) {
> + iowrite32(0x3777812b, pextp->base + 0x50e0);
> + iowrite32(0x005c9cff, pextp->base + 0x506c);
> + iowrite32(0x9dfafafa, pextp->base + 0x5070);
> + iowrite32(0x273f3f3f, pextp->base + 0x5074);
> + iowrite32(0xa8883868, pextp->base + 0x5078);
> + iowrite32(0x14661466, pextp->base + 0x507c);
> + } else {
> + iowrite32(0x3777c12b, pextp->base + 0x50e0);
> + iowrite32(0x005f9cff, pextp->base + 0x506c);
> + iowrite32(0x9d9dfafa, pextp->base + 0x5070);
> + iowrite32(0x27273f3f, pextp->base + 0x5074);
> + iowrite32(0xa7883c68, pextp->base + 0x5078);
> + iowrite32(0x11661166, pextp->base + 0x507c);
> + }
> +
> + if (is_2p5g || is_10g) {
> + iowrite32(0x0e000aaf, pextp->base + 0x5080);
> + iowrite32(0x08080d0d, pextp->base + 0x5084);
> + iowrite32(0x02030909, pextp->base + 0x5088);
> + } else if (is_5g) {
> + iowrite32(0x0e001abf, pextp->base + 0x5080);
> + iowrite32(0x080b0d0d, pextp->base + 0x5084);
> + iowrite32(0x02050909, pextp->base + 0x5088);
> + } else {
> + iowrite32(0x0e000eaf, pextp->base + 0x5080);
> + iowrite32(0x08080e0d, pextp->base + 0x5084);
> + iowrite32(0x02030b09, pextp->base + 0x5088);
> + }
> +
> + if (is_5g) {
> + iowrite32(0x0c000000, pextp->base + 0x50e4);
> + iowrite32(0x04000000, pextp->base + 0x50e8);
> + } else {
> + iowrite32(0x0c0c0000, pextp->base + 0x50e4);
> + iowrite32(0x04040000, pextp->base + 0x50e8);
> + }
> +
> + if (is_2p5g || mtk_interface_mode_is_xgmii(interface))
> + iowrite32(0x0f0f0c06, pextp->base + 0x50eC);
ouch, why mixed case, make it small everwhere please
> + else
> + iowrite32(0x0f0f0606, pextp->base + 0x50eC);
> +
> + if (is_5g) {
> + iowrite32(0x50808c8c, pextp->base + 0x50a8);
> + iowrite32(0x18000000, pextp->base + 0x6004);
> + } else {
> + iowrite32(0x506e8c8c, pextp->base + 0x50a8);
> + iowrite32(0x18190000, pextp->base + 0x6004);
> + }
> +
> + if (is_10g)
> + iowrite32(0x01423342, pextp->base + 0x00f8);
> + else if (is_5g)
> + iowrite32(0x00a132a1, pextp->base + 0x00f8);
> + else if (is_2p5g)
> + iowrite32(0x009c329c, pextp->base + 0x00f8);
> + else
> + iowrite32(0x00fa32fa, pextp->base + 0x00f8);
> +
> + /* Force SGDT_OUT off and select PCS */
> + if (mtk_interface_mode_is_xgmii(interface))
> + iowrite32(0x80201f20, pextp->base + 0x00f4);
> + else
> + iowrite32(0x80201f21, pextp->base + 0x00f4);
> +
> + /* Force GLB_CKDET_OUT */
> + iowrite32(0x00050c00, pextp->base + 0x0030);
> +
> + /* Force AEQ on */
> + iowrite32(0x02002800, pextp->base + 0x0070);
> + ndelay(1020);
> +
> + /* Setup DA default value */
> + iowrite32(0x00000020, pextp->base + 0x30b0);
> + iowrite32(0x00008a01, pextp->base + 0x3028);
> + iowrite32(0x0000a884, pextp->base + 0x302c);
> + iowrite32(0x00083002, pextp->base + 0x3024);
> + if (mtk_interface_mode_is_xgmii(interface)) {
> + iowrite32(0x00022220, pextp->base + 0x3010);
> + iowrite32(0x0f020a01, pextp->base + 0x5064);
> + iowrite32(0x06100600, pextp->base + 0x50b4);
> + if (interface == PHY_INTERFACE_MODE_USXGMII)
> + iowrite32(0x40704000, pextp->base + 0x3048);
> + else
> + iowrite32(0x47684100, pextp->base + 0x3048);
> + } else {
> + iowrite32(0x00011110, pextp->base + 0x3010);
> + iowrite32(0x40704000, pextp->base + 0x3048);
> + }
> +
> + if (!mtk_interface_mode_is_xgmii(interface) && !is_2p5g)
> + iowrite32(0x0000c000, pextp->base + 0x3064);
> +
> + if (interface != PHY_INTERFACE_MODE_10GBASER) {
> + iowrite32(0xa8000000, pextp->base + 0x3050);
> + iowrite32(0x000000aa, pextp->base + 0x3054);
> + } else {
> + iowrite32(0x00000000, pextp->base + 0x3050);
> + iowrite32(0x00000000, pextp->base + 0x3054);
> + }
> +
> + if (mtk_interface_mode_is_xgmii(interface))
> + iowrite32(0x00000f00, pextp->base + 0x306c);
> + else if (is_2p5g)
> + iowrite32(0x22000f00, pextp->base + 0x306c);
> + else
> + iowrite32(0x20200f00, pextp->base + 0x306c);
> +
> + if (interface == PHY_INTERFACE_MODE_10GBASER && pextp->da_war)
> + iowrite32(0x0007b400, pextp->base + 0xa008);
> +
> + if (mtk_interface_mode_is_xgmii(interface))
> + iowrite32(0x00040000, pextp->base + 0xa060);
> + else
> + iowrite32(0x00050000, pextp->base + 0xa060);
> +
> + if (is_10g)
> + iowrite32(0x00000001, pextp->base + 0x90d0);
> + else if (is_5g)
> + iowrite32(0x00000003, pextp->base + 0x90d0);
> + else if (is_2p5g)
> + iowrite32(0x00000005, pextp->base + 0x90d0);
> + else
> + iowrite32(0x00000007, pextp->base + 0x90d0);
> +
> + /* Release reset */
> + iowrite32(0x0200e800, pextp->base + 0x0070);
> + usleep_range(150, 500);
> +
> + /* Switch to P0 */
> + iowrite32(0x0200c111, pextp->base + 0x0070);
> + ndelay(1020);
> + iowrite32(0x0200c101, pextp->base + 0x0070);
> + usleep_range(15, 50);
> +
> + if (mtk_interface_mode_is_xgmii(interface)) {
> + /* Switch to Gen3 */
> + iowrite32(0x0202c111, pextp->base + 0x0070);
> + } else {
> + /* Switch to Gen2 */
> + iowrite32(0x0201c111, pextp->base + 0x0070);
> + }
> + ndelay(1020);
> + if (mtk_interface_mode_is_xgmii(interface))
> + iowrite32(0x0202c101, pextp->base + 0x0070);
> + else
> + iowrite32(0x0201c101, pextp->base + 0x0070);
> + usleep_range(100, 500);
> + iowrite32(0x00000030, pextp->base + 0x30b0);
> + if (mtk_interface_mode_is_xgmii(interface))
> + iowrite32(0x80201f00, pextp->base + 0x00f4);
> + else
> + iowrite32(0x80201f01, pextp->base + 0x00f4);
> +
> + iowrite32(0x30000000, pextp->base + 0x3040);
> + usleep_range(400, 1000);
> +}
> +
> +static int mtk_pextp_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> + struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> + if (mode != PHY_MODE_ETHERNET)
> + return -EINVAL;
> +
> + switch (submode) {
> + case PHY_INTERFACE_MODE_1000BASEX:
> + case PHY_INTERFACE_MODE_2500BASEX:
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_5GBASER:
> + case PHY_INTERFACE_MODE_10GBASER:
> + case PHY_INTERFACE_MODE_USXGMII:
> + mtk_pextp_setup(pextp, submode);
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mtk_pextp_reset(struct phy *phy)
> +{
> + struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> + reset_control_assert(pextp->reset);
> + usleep_range(100, 500);
> + reset_control_deassert(pextp->reset);
> + usleep_range(1, 10);
> +
> + return 0;
> +}
> +
> +static int mtk_pextp_power_on(struct phy *phy)
> +{
> + struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> + return clk_bulk_prepare_enable(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
> +}
> +
> +static int mtk_pextp_power_off(struct phy *phy)
> +{
> + struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> + clk_bulk_disable_unprepare(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops mtk_pextp_ops = {
> + .power_on = mtk_pextp_power_on,
> + .power_off = mtk_pextp_power_off,
> + .set_mode = mtk_pextp_set_mode,
> + .reset = mtk_pextp_reset,
> + .owner = THIS_MODULE,
> +};
> +
> +static int mtk_pextp_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct phy_provider *phy_provider;
> + struct mtk_pextp_phy *pextp;
> + struct phy *phy;
> +
> + if (!np)
> + return -ENODEV;
> +
> + pextp = devm_kzalloc(&pdev->dev, sizeof(*pextp), GFP_KERNEL);
> + if (!pextp)
> + return -ENOMEM;
> +
> + pextp->base = devm_of_iomap(&pdev->dev, np, 0, NULL);
> + if (!pextp->base)
> + return -EIO;
> +
> + pextp->dev = &pdev->dev;
> +
> + pextp->clocks[0].id = "topxtal";
> + pextp->clocks[0].clk = devm_clk_get(&pdev->dev, pextp->clocks[0].id);
> + if (IS_ERR(pextp->clocks[0].clk))
> + return PTR_ERR(pextp->clocks[0].clk);
> +
> + pextp->clocks[1].id = "xfipll";
> + pextp->clocks[1].clk = devm_clk_get(&pdev->dev, pextp->clocks[1].id);
> + if (IS_ERR(pextp->clocks[1].clk))
> + return PTR_ERR(pextp->clocks[1].clk);
> +
> + pextp->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> + if (IS_ERR(pextp->reset))
> + return PTR_ERR(pextp->reset);
> +
> + pextp->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
> +
> + phy = devm_phy_create(&pdev->dev, NULL, &mtk_pextp_ops);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + phy_set_drvdata(phy, pextp);
> +
> + phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id mtk_pextp_match[] = {
> + { .compatible = "mediatek,mt7988-xfi-pextp", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, mtk_pextp_match);
> +
> +static struct platform_driver mtk_pextp_driver = {
> + .probe = mtk_pextp_probe,
> + .driver = {
> + .name = "mtk-pextp",
> + .of_match_table = mtk_pextp_match,
> + },
> +};
> +module_platform_driver(mtk_pextp_driver);
why is this driver in netdev series, it should not be dependent on rest
and can be send separately to phy ss
> +
> +MODULE_DESCRIPTION("MediaTek pextp SerDes PHY driver");
> +MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
> +MODULE_LICENSE("GPL");
> --
> 2.43.0
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] phy: Add PHY Embedded DisplayPort mode
From: Dmitry Baryshkov @ 2023-12-21 16:29 UTC (permalink / raw)
To: Abel Vesa
Cc: Vinod Koul, Kishon Vijay Abraham I, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Johan Hovold, linux-phy, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20231219-x1e80100-phy-edp-compatible-refactor-v1-2-f9e77752953d@linaro.org>
On Tue, 19 Dec 2023 at 22:55, Abel Vesa <abel.vesa@linaro.org> wrote:
>
> Add definition for Embedded DisplayPort (eDP) phy mode.
If we leave the DT property aside, is eDP a separate PHY mode, or a
submode? (in terms of phy_set_mode_ext).
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> ---
> include/linux/phy/phy.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index f6d607ef0e80..bea532711906 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -42,7 +42,8 @@ enum phy_mode {
> PHY_MODE_MIPI_DPHY,
> PHY_MODE_SATA,
> PHY_MODE_LVDS,
> - PHY_MODE_DP
> + PHY_MODE_DP,
> + PHY_MODE_EDP
> };
--
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 0/3] phy: qcom: edp: Add support for DT phy mode configuration
From: Dmitry Baryshkov @ 2023-12-21 16:27 UTC (permalink / raw)
To: Abel Vesa
Cc: Vinod Koul, Kishon Vijay Abraham I, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Johan Hovold, linux-phy, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20231219-x1e80100-phy-edp-compatible-refactor-v1-0-f9e77752953d@linaro.org>
On Tue, 19 Dec 2023 at 22:55, Abel Vesa <abel.vesa@linaro.org> wrote:
>
> Until now, all platform that supported both eDP and DP had different
> compatibles for each mode. Using different compatibles for basically
> the same IP block but for a different configuration is bad way all
> around. There is a new compute platform from Qualcomm that supports
> both eDP and DP with the same PHY. So instead of following the old
> method, we should allow the mode to be configured from devicetree.
>
> There has been an off-list discussion on what would be the right way
> to pass on the PHY mode information to the driver and it has been
> concluded that phy-cells is the way to go. This means that basically
> the controller will pass another value (that is, the PHY type) to
> its 'phys' DT property.
>
> For this, we need both the bindings value and the PHY mode value to be
> added as well.
>
> The controller part will follow shortly. But for now, lets see where
> this is going.
>
> There has been another attempt at this here:
> https://lore.kernel.org/all/20231122-phy-qualcomm-edp-x1e80100-v3-3-576fc4e9559d@linaro.org/
>
> Compared to that version, this one uses the phy-cells method and drops
> the X1E80100 support. The X1E80100 support will be a separate patchset.
After several back and forth discussions, I think that this approach
is not correct and not that easy to extend. Instead I'd like to
suggest adding a property to the DP controller, which enables eDP
behaviour (and thus makes DP driver call phy_set_mode()). Something
like this:
dp: displayport-controller@ae0000 {
compatible = "qcom,sm8000-dp";
/* reg, interrupts, etc */
edp-interface;
/* or simpler */
is-edp;
};
What do you think?
--
With best wishes
Dmitry
--
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