* Re: [PATCH v2 4/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
From: Krzysztof Kozlowski @ 2026-02-17 7:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun,
Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Jitao Shi, Fabien Parent, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <66fbd5dd3604ffc4fda45022c1db68e4e0be6714.1771258407.git.l.scorcia@gmail.com>
On Mon, Feb 16, 2026 at 04:22:15PM +0000, Luca Leonardo Scorcia wrote:
> Add support for the MediaTek mt8167 SoC: the DSI PHY found
> in this chip is fully compatible with the one found in the mt2701 SoC.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
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 v2 3/6] dt-bindings: display: mediatek: Correct compatibility for mt8167-dsi
From: Krzysztof Kozlowski @ 2026-02-17 7:58 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Jitao Shi, Fabien Parent, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <ff920a7cc94f2b0c03d4bb55142030fded30d07c.1771258407.git.l.scorcia@gmail.com>
On Mon, Feb 16, 2026 at 04:22:14PM +0000, Luca Leonardo Scorcia wrote:
> Remove the dedicated "mediatek,mt8167-dsi" compatible from the device list and
> describe it as compatible with mt2701 instead. It is safe to do so because:
You are not doing what you wrote. The dedicated mediatek,mt8167-dsi is
still there. And if you want to describe mediatek,mt8167-dsi with OTHER
compatible (mt2701), it is a NAK. It is wrong and not allowed by writing
bindings doc.
You just added fallback, didn't you?
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
>
> - Bootloader doesn't rely on this single compatible; and
Does not matter. You still CANNOT remove a compatible. If bootloader
starts to rely on this single compatible, you add it back? No.
> - There was never any upstreamed devicetree using this single compatible; and
> - The MT8167 DSI Controller is fully compatible with the one found in MT2701.
>
> Fixes: 8867c4b39361 ("dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC")
>
There is never a blank line between tags.
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
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 v2 3/6] dt-bindings: display: mediatek: Correct compatibility for mt8167-dsi
From: AngeloGioacchino Del Regno @ 2026-02-17 9:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luca Leonardo Scorcia
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
Jitao Shi, Fabien Parent, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <20260217-stereotyped-dazzling-loon-f06e18@quoll>
Il 17/02/26 08:58, Krzysztof Kozlowski ha scritto:
> On Mon, Feb 16, 2026 at 04:22:14PM +0000, Luca Leonardo Scorcia wrote:
>> Remove the dedicated "mediatek,mt8167-dsi" compatible from the device list and
>> describe it as compatible with mt2701 instead. It is safe to do so because:
>
> You are not doing what you wrote. The dedicated mediatek,mt8167-dsi is
> still there.
>
> And if you want to describe mediatek,mt8167-dsi with OTHER
> compatible (mt2701), it is a NAK. It is wrong and not allowed by writing
> bindings doc.
Sorry, that was my apparently very-bad advice - and I recognize that, as a
maintainer, I should have given different advices.
Still, check below the (bad, and not enough) reasons why I said that....
>
> You just added fallback, didn't you?
>
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
>
>>
>> - Bootloader doesn't rely on this single compatible; and
>
> Does not matter. You still CANNOT remove a compatible. If bootloader
> starts to rely on this single compatible, you add it back? No.
>
The issue here is that "mediatek,mt8167-dsi" was never used anywhere, and that
alone makes zero sense as it is - by hardware - identical to mt2701.
That, leaving alone the fact that nothing anywhere can make use of a node with
just `compatible = "mediatek,mt8167-dsi"`.
If it is not acceptable to remove something that was never used and should've never
been there "alone" without fallbacks, it's ok. I'm sure that avoiding to delete the
one line is not a big deal there.
Also remember that we are talking about an old SoC that will never see a bootchain
overhaul, nor will it see new bootloaders.
Though, just a small note - please please please: when we see new contributors,
especially when they're community ones, can we try and encourage them to do the
right things, and follow the right processes, without being harsh in any way?
And P.S.: Yeah I know you haven't been as harsh as you can (rightfully) be, so
thanks for that.
Luca, I'm sorry again, at this point - it would be great if you could please send
a v3 without the removal of that line. Just add the fallback and that's it :-)
>> - There was never any upstreamed devicetree using this single compatible; and
>> - The MT8167 DSI Controller is fully compatible with the one found in MT2701.
>>
>> Fixes: 8867c4b39361 ("dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC")
>>
>
> There is never a blank line between tags.
Yeah, agreed.
Cheers,
Angelo
>
>> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
>> ---
>> .../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> 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 v2 2/6] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: AngeloGioacchino Del Regno @ 2026-02-17 9:03 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Krzysztof Kozlowski, Chun-Kuang Hu, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
Jitao Shi, Fabien Parent, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <8f86f229e564723b424b4d621244cfbe158c0f08.1771258407.git.l.scorcia@gmail.com>
Il 16/02/26 17:22, Luca Leonardo Scorcia ha scritto:
> Add compatibles for various display-related blocks of MediaTek mt8167.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
From: AngeloGioacchino Del Regno @ 2026-02-17 9:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, Jitao Shi, Fabien Parent,
dri-devel, devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <66fbd5dd3604ffc4fda45022c1db68e4e0be6714.1771258407.git.l.scorcia@gmail.com>
Il 16/02/26 17:22, Luca Leonardo Scorcia ha scritto:
> Add support for the MediaTek mt8167 SoC: the DSI PHY found
> in this chip is fully compatible with the one found in the mt2701 SoC.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] arm64: dts: mediatek: mt8167: Add DRM nodes
From: AngeloGioacchino Del Regno @ 2026-02-17 9:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, Jitao Shi, Fabien Parent,
dri-devel, devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <1e9cc053a4e80acfea492aaa186ed493115f318b.1771258407.git.l.scorcia@gmail.com>
Il 16/02/26 17:22, Luca Leonardo Scorcia ha scritto:
> Add all the DRM nodes required to get DSI to work on MT8167 SoC.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] gpu: drm: mediatek: ovl: add specific entry for mt8167
From: AngeloGioacchino Del Regno @ 2026-02-17 9:05 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Val Packett, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
Jitao Shi, Fabien Parent, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <ee6bb10f8beb4a9d0d2bf49d5b053c7395ad6b50.1771258407.git.l.scorcia@gmail.com>
Il 16/02/26 17:22, Luca Leonardo Scorcia ha scritto:
> From: Val Packett <val@packett.cool>
>
> From: Val Packett <val@packett.cool>
Whoops, for some reason, you got the From line twice here.
Something to note for the next time.
>
> While this configuration is otherwise identical to mt8173, according
> to Android kernel sources, this SoC does need smi_id_en.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cheers,
Angelo
--
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: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-02-17 10:40 UTC (permalink / raw)
To: Johan Hovold
Cc: Vladimir Oltean, vkoul, kishon, linux-arm-msm, linux-phy,
dmitry.baryshkov, neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <aZL12oyiLumpf39e@hovoldconsulting.com>
On Mon, Feb 16, 2026 at 11:48 AM Johan Hovold <johan@kernel.org> wrote:
>
> On Fri, Feb 13, 2026 at 10:15:50PM +0200, Vladimir Oltean wrote:
>
> > Another comment upon reviewing this driver's runtime PM use (although
> > this is at most something that may result in a patch for "next"):
> >
> > This driver uses hsphy->phy_initialized to make sure qcom_snps_hsphy_suspend()
> > isn't called unless qcom_snps_hsphy_init() was called.
> >
> > Don't we achieve the same behaviour by replacing "hsphy->phy_initialized = true"
> > with pm_runtime_get_sync(dev) and "hsphy->phy_initialized = false" with
> > pm_runtime_put(dev)?
>
> No, the device can still suspend before phy_init() is called.
>
> What would work, and which should probably be preferred over adding
> these phy_initialized flags, is to increment the pm usage counter before
> enabling runtime pm and decrementing it after the PHY has been created.
Ok, yes, using the usual pm_runtime_get_noresume() before enabling
runtime PM would work as well. This is conceptually similar to this
change, which instead relies on pm_runtime_forbid(). However, I agree
that forbid provides no guarantee about when runtime PM may be
re-enabled by a user...
Regards,
Loic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: display: mediatek: Correct compatibility for mt8167-dsi
From: Vladimir Oltean @ 2026-02-17 14:05 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Jitao Shi, Fabien Parent, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260217135828.4hgbyhnz5nuzm6p7@skbuf>
On Tue, 17 Feb 2026 at 15:58, Vladimir Oltean <olteanv@gmail.com> wrote:
> To help the build test automation select the proper base branch, you can
> use the "phy-next" or "phy-fixes" git subject prefixes when generating
> your patches.
Ah, sorry, I missed the fact that only patch 4/6 touches linux-phy.
What is the merge strategy for this set?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [bug report] phy: qcom: qmp-usbc: Add QCS615 USB/DP PHY config and DP mode support
From: Konrad Dybcio @ 2026-02-17 15:27 UTC (permalink / raw)
To: Dan Carpenter, Xiangxu Yin
Cc: Neil Armstrong, linux-arm-msm, linux-phy, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <aYXvBGVdwXTrJNio@stanley.mountain>
On 2/6/26 2:39 PM, Dan Carpenter wrote:
> [ Smatch checking is paused while we raise funding. #SadFace
> https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]
>
> Hello Xiangxu Yin,
>
> Commit 81791c45c8e0 ("phy: qcom: qmp-usbc: Add QCS615 USB/DP PHY
> config and DP mode support") from Dec 15, 2025 (linux-next), leads to
> the following Smatch static checker warning:
>
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c:803 qmp_v2_configure_dp_swing()
> index hardmax out of bounds '(*cfg->swing_tbl)[v_level]' size=4 max='4' rl='0-4'
>
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> 777 static int qmp_v2_configure_dp_swing(struct qmp_usbc *qmp)
> 778 {
> 779 const struct qmp_phy_cfg *cfg = qmp->cfg;
> 780 const struct phy_configure_opts_dp *dp_opts = &qmp->dp_opts;
> 781 void __iomem *tx = qmp->dp_tx;
> 782 void __iomem *tx2 = qmp->dp_tx2;
> 783 unsigned int v_level = 0, p_level = 0;
> 784 u8 voltage_swing_cfg, pre_emphasis_cfg;
> 785 int i;
> 786
> 787 if (dp_opts->lanes > 4) {
> 788 dev_err(qmp->dev, "Invalid lane_num(%d)\n", dp_opts->lanes);
> 789 return -EINVAL;
> 790 }
> 791
> 792 for (i = 0; i < dp_opts->lanes; i++) {
> 793 v_level = max(v_level, dp_opts->voltage[i]);
> 794 p_level = max(p_level, dp_opts->pre[i]);
> 795 }
> 796
> 797 if (v_level > 4 || p_level > 4) {
>
> These should be >= 4 instead of >.
>
> 798 dev_err(qmp->dev, "Invalid v(%d) | p(%d) level)\n",
> 799 v_level, p_level);
> 800 return -EINVAL;
> 801 }
> 802
> --> 803 voltage_swing_cfg = (*cfg->swing_tbl)[v_level][p_level];
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is a 4x4 array.
Thanks Dan for the report
Xiangxu, are you planning to send a patch to address that?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: display: mediatek: Correct compatibility for mt8167-dsi
From: Vladimir Oltean @ 2026-02-17 13:58 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Jitao Shi, Fabien Parent, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <ff920a7cc94f2b0c03d4bb55142030fded30d07c.1771258407.git.l.scorcia@gmail.com>
Hi Luca,
On Mon, Feb 16, 2026 at 04:22:14PM +0000, Luca Leonardo Scorcia wrote:
> Remove the dedicated "mediatek,mt8167-dsi" compatible from the device list and
> describe it as compatible with mt2701 instead. It is safe to do so because:
>
> - Bootloader doesn't rely on this single compatible; and
> - There was never any upstreamed devicetree using this single compatible; and
> - The MT8167 DSI Controller is fully compatible with the one found in MT2701.
>
> Fixes: 8867c4b39361 ("dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC")
Not sure which direction this patch will go in the next revision, but
(if this patch remains in this form, and intended as a bug fix) please
do not mix fixes for the current (and stable) kernel with new development
for the next kernel in the same series. They are supposed to be applied
to
https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/log/?h=next
and
https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/log/?h=fixes
respectively.
(also see Documentation/process/stable-kernel-rules.rst for what is
generally considered to be a bug fix. We don't use the word "fix" very
lightly, there needs to be a user-visible impact.)
To help the build test automation select the proper base branch, you can
use the "phy-next" or "phy-fixes" git subject prefixes when generating
your patches.
You can send fixes at any time, but please send new development for the
next kernel only when the merge window isn't open (unless it is marked
as RFC, then it can also be sent any time).
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: display: mediatek: Correct compatibility for mt8167-dsi
From: Luca Leonardo Scorcia @ 2026-02-17 16:37 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Jitao Shi, Fabien Parent, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260217135828.4hgbyhnz5nuzm6p7@skbuf>
Hello Vladimir,
thank you for the reply and explanation. As a new contributor it is
greatly appreciated.
Those patches are definitely intended for next since as far as
I know there is no mt8167 device using upstream kernels out there.
As for the Fixes tag, the rationale for it was that it's ultimately
not coherent with both its original author's intended usage [1] nor
with the current code as it's not present in [2], possibly due to the
fact that at the time of the original contribution bindings were text
only and less accurate, so I described is as a "Fix". I understand now
that the Fixes tag has a special meaning in the merge process so I
will just remove it in v3, it does not add much information anyway.
Also thanks about the git commit prefix suggestion, I didn't know about it!
I apologize for the confusion and I appreciate all guidance from maintainers.
I really want to do stuff The Right Way, it's just a matter of moving
along the learning curve.
[1] https://lore.kernel.org/linux-mediatek/20210406113631.2675029-3-fparent@baylibre.com/
[2] https://github.com/torvalds/linux/blob/9702969978695d9a699a1f34771580cdbb153b33/drivers/gpu/drm/mediatek/mtk_dsi.c#L13061
Il giorno mar 17 feb 2026 alle ore 16:35 Vladimir Oltean
<olteanv@gmail.com> ha scritto:
>
> Hi Luca,
>
> On Mon, Feb 16, 2026 at 04:22:14PM +0000, Luca Leonardo Scorcia wrote:
> > Remove the dedicated "mediatek,mt8167-dsi" compatible from the device list and
> > describe it as compatible with mt2701 instead. It is safe to do so because:
> >
> > - Bootloader doesn't rely on this single compatible; and
> > - There was never any upstreamed devicetree using this single compatible; and
> > - The MT8167 DSI Controller is fully compatible with the one found in MT2701.
> >
> > Fixes: 8867c4b39361 ("dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC")
>
> Not sure which direction this patch will go in the next revision, but
> (if this patch remains in this form, and intended as a bug fix) please
> do not mix fixes for the current (and stable) kernel with new development
> for the next kernel in the same series. They are supposed to be applied
> to
> https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/log/?h=next
> and
> https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/log/?h=fixes
> respectively.
>
> (also see Documentation/process/stable-kernel-rules.rst for what is
> generally considered to be a bug fix. We don't use the word "fix" very
> lightly, there needs to be a user-visible impact.)
>
> To help the build test automation select the proper base branch, you can
> use the "phy-next" or "phy-fixes" git subject prefixes when generating
> your patches.
>
> You can send fixes at any time, but please send new development for the
> next kernel only when the merge window isn't open (unless it is marked
> as RFC, then it can also be sent any time).
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: display: mediatek: Correct compatibility for mt8167-dsi
From: Luca Leonardo Scorcia @ 2026-02-17 17:05 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Krzysztof Kozlowski, linux-mediatek, Chun-Kuang Hu, Philipp Zabel,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
Jitao Shi, Fabien Parent, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <04a3d18b-80cc-4d1d-8657-cb35c4b5b797@collabora.com>
Thank you all for your feedback! As I just learnt about the
merge-window patch-freeze
period I'll wait until next Monday before submitting v3 including the
suggested changes.
Mmmh. Now I'm wondering if I should have added a Fixes tag to [1],
that's actually an
user-visible issue...
[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20260209090516.14369-1-l.scorcia@gmail.com/
Il giorno mar 17 feb 2026 alle ore 10:03 AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> ha scritto:
>
> Il 17/02/26 08:58, Krzysztof Kozlowski ha scritto:
> > On Mon, Feb 16, 2026 at 04:22:14PM +0000, Luca Leonardo Scorcia wrote:
> >> Remove the dedicated "mediatek,mt8167-dsi" compatible from the device list and
> >> describe it as compatible with mt2701 instead. It is safe to do so because:
> >
> > You are not doing what you wrote. The dedicated mediatek,mt8167-dsi is
> > still there.
> >
> > And if you want to describe mediatek,mt8167-dsi with OTHER
> > compatible (mt2701), it is a NAK. It is wrong and not allowed by writing
> > bindings doc.
>
> Sorry, that was my apparently very-bad advice - and I recognize that, as a
> maintainer, I should have given different advices.
>
> Still, check below the (bad, and not enough) reasons why I said that....
>
> >
> > You just added fallback, didn't you?
> >
> > Please wrap commit message according to Linux coding style / submission
> > process (neither too early nor over the limit):
> > https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> >
> > Please run scripts/checkpatch.pl on the patches and fix reported
> > warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> > patches and (probably) fix more warnings. Some warnings can be ignored,
> > especially from --strict run, but the code here looks like it needs a
> > fix. Feel free to get in touch if the warning is not clear.
> >
> >>
> >> - Bootloader doesn't rely on this single compatible; and
> >
> > Does not matter. You still CANNOT remove a compatible. If bootloader
> > starts to rely on this single compatible, you add it back? No.
> >
>
> The issue here is that "mediatek,mt8167-dsi" was never used anywhere, and that
> alone makes zero sense as it is - by hardware - identical to mt2701.
>
> That, leaving alone the fact that nothing anywhere can make use of a node with
> just `compatible = "mediatek,mt8167-dsi"`.
>
> If it is not acceptable to remove something that was never used and should've never
> been there "alone" without fallbacks, it's ok. I'm sure that avoiding to delete the
> one line is not a big deal there.
> Also remember that we are talking about an old SoC that will never see a bootchain
> overhaul, nor will it see new bootloaders.
>
> Though, just a small note - please please please: when we see new contributors,
> especially when they're community ones, can we try and encourage them to do the
> right things, and follow the right processes, without being harsh in any way?
>
> And P.S.: Yeah I know you haven't been as harsh as you can (rightfully) be, so
> thanks for that.
>
> Luca, I'm sorry again, at this point - it would be great if you could please send
> a v3 without the removal of that line. Just add the fallback and that's it :-)
>
> >> - There was never any upstreamed devicetree using this single compatible; and
> >> - The MT8167 DSI Controller is fully compatible with the one found in MT2701.
> >>
> >> Fixes: 8867c4b39361 ("dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC")
> >>
> >
> > There is never a blank line between tags.
>
> Yeah, agreed.
>
> Cheers,
> Angelo
>
> >
> >> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> >> ---
> >> .../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > Best regards,
> > Krzysztof
> >
>
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 02/14] net: stmmac: qcom-ethqos: convert to set_clk_tx_rate() method
From: Mohd Ayaan Anwar @ 2026-02-17 18:51 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Maxime Chevallier,
Maxime Coquelin, Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <E1vjDr6-00000005fQ9-3RUD@rmk-PC.armlinux.org.uk>
Hello Russell,
On Fri, Jan 23, 2026 at 09:53:28AM +0000, Russell King (Oracle) wrote:
> Set the RGMII link clock using the set_clk_tx_rate() method rather than
> coding it into the .fix_mac_speed() method. This simplifies ethqos's
> ethqos_fix_mac_speed().
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
No issues found when I tested this patch along with "net: stmmac:
qcom-ethqos: cleanups and re-organise SerDes handling" on the QCS615
Ride board with the KSZ9031 RGMII PHY (see [0][1]).
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Ayaan
---
[0] https://lore.kernel.org/netdev/20250819-qcs615_eth-v4-6-5050ed3402cb@oss.qualcomm.com/t/#ma85cac924488d580b971e6477e7df30dc7e48045
[1] Ethernet is not yet enabled for this board in the upstream kernel.
The changes from [0] were applied locally to test this series. I am
trying to figure out how the board deals with RGMII delays so that I
can revive the series.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: qcom: m31-eusb2: clear PLL_EN during init
From: Elson Serrao @ 2026-02-17 20:11 UTC (permalink / raw)
To: Vinod Koul, Konrad Dybcio, Neil Armstrong, Wesley Cheng,
Johan Hovold, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
The driver currently sets bit 0 of USB_PHY_CFG1 (PLL_EN) during PHY
initialization. According to the M31 EUSB2 PHY hardware documentation,
this bit is intended only for test/debug scenarios and does not control
mission mode operation. Keeping PLL_EN asserted causes the PHY to draw
additional current during USB bus suspend. Clearing this bit results in
lower suspend power consumption without affecting normal operation.
Update the driver to leave PLL_EN cleared as recommended by the hardware
documentation.
Fixes: 9c8504861cc4 ("phy: qcom: Add M31 based eUSB2 PHY driver")
Cc: stable@vger.kernel.org
Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-m31-eusb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
index 95cd3175926d..68f1ba8fec4a 100644
--- a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
@@ -83,7 +83,7 @@ static const struct m31_phy_tbl_entry m31_eusb2_setup_tbl[] = {
M31_EUSB_PHY_INIT_CFG(USB_PHY_CFG0, UTMI_PHY_CMN_CTRL_OVERRIDE_EN, 1),
M31_EUSB_PHY_INIT_CFG(USB_PHY_UTMI_CTRL5, POR, 1),
M31_EUSB_PHY_INIT_CFG(USB_PHY_HS_PHY_CTRL_COMMON0, PHY_ENABLE, 1),
- M31_EUSB_PHY_INIT_CFG(USB_PHY_CFG1, PLL_EN, 1),
+ M31_EUSB_PHY_INIT_CFG(USB_PHY_CFG1, PLL_EN, 0),
M31_EUSB_PHY_INIT_CFG(USB_PHY_FSEL_SEL, FSEL_SEL, 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
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: Cristian Ciocaltea @ 2026-02-18 0:52 UTC (permalink / raw)
To: dubito, Vinod Koul, Neil Armstrong, Heiko Stuebner, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, regressions
In-Reply-To: <4544ec4ccfa49cbdffee098878df7806223935a0.camel@online.de>
Hi Thomas,
On 2/16/26 12:48 PM, Thomas Niederprüm wrote:
> Hi Cristian,
>
> Am Montag, dem 16.02.2026 um 03:18 +0200 schrieb Cristian Ciocaltea:
>> Hi Thomas,
>>
>> On 2/14/26 12:00 AM, Thomas Niederprüm wrote:
>>> Hi Cristian,
>>>
>>>
>>> Am Freitag, dem 13.02.2026 um 00:04 +0200 schrieb Cristian Ciocaltea:
>>>> Hi Thomas,
>>>>
>>>> On 2/11/26 11:20 PM, Thomas Niederprüm wrote:
>>>>> Hi,
>>>>>
>>>>> I'm running a Radxa Rock 5B (rk3588) on a 10+ year old Samsung TV screen
>>>>> connected via HDMI. This worked flawlessly in 6.18.7 but does not work
>>>>> on
>>>>> linux-
>>>>> next. I bisected the problem and identified commit 3481fc04 to be the
>>>>> first
>>>>> bad
>>>>> commit. This points to the phy PLL clock rate calculation to be the
>>>>> problem
>>>>> in
>>>>> connection with my monitor. As it seems relevant, I attached the EDID of
>>>>> my
>>>>> monitor.
>>>>>
>>>>> I'm booting the kernel out of EDK2 after which efifb is correctly taking
>>>>> over
>>>>> the initialized display and I can see the initial kernel boot messages
>>>>> on
>>>>> the
>>>>> HDMI output. After the drm/kms in the kernel takes over the screen
>>>>> shortly
>>>>> turns
>>>>> black, changes resolution, and then correctly displays on 6.18.7.
>>>>> However,
>>>>> in
>>>>> linux-next the screen remains black after kms took over. I cannot see
>>>>> any
>>>>> obvious differences in the boot logs but I attached two boot logs, one
>>>>> for
>>>>> the
>>>>> working 6.18.7 kernel and one for the non-working linux-next kernel.
>>>>>
>>>>> When reverting 3481fc04..de5dba83 (i.e. the faulty commit and the ones
>>>>> that
>>>>> followed in the HDMI 2.1 FRL series) I can build a working kernel from
>>>>> linux-
>>>>> next.
>>>>>
>>>>> I don't know where to dig from here but I'm happy to run any test
>>>>> necessary
>>>>> to
>>>>> track down the problem.
>>>>
>>>> It'd be helpful if you could resend the logs after booting both kernels
>>>> with
>>>> the
>>>> following params (requires CONFIG_DYNAMIC_DEBUG=y):
>>>>
>>>> rockchipdrm.dyndbg=+p dw_hdmi_qp.dyndbg=+p
>>>> phy_rockchip_samsung_hdptx.dyndbg=+p
>>>>
>>>> As well as running the command below before connecting your display/TV:
>>>>
>>>> $ echo 0x4 > /sys/module/drm/parameters/debug
>>>>
>>>> I've noticed you're forcing "video=HDMI-A-1:1920x1080M@60", which should
>>>> be
>>>> anyway the preferred mode (according to the EDID).
>>>
>>> I dumped the kernel messages for a freshly built v6.19 and a linux-next
>>> image.
>>> For each kernel I booted with the suggested debug options and forcing the
>>> modes
>>> 1920x1080@60, 1920x1080@50, 1920x1080@30. The boot logs are attached. For
>>> v6.19
>>> all modes work. Running linux-next, 1920x1080@60 and 1920x1080@50 don't work
>>> but
>>> 1920x1080@30 works.
>>>
>>>> Did you try choosing a different one, e.g. 1920x1080@50 or 1920x1080@30
>>>> (they
>>>> are supported according to the listing in CTA-861 Extension Block). That's
>>>> more
>>>> a test to confirm the issue affects a particular modeline, or is more
>>>> general.
>>>>
>>>
>>> As stated above, if I force 1920x1080@30 the screen turns on in linux-next.
>>> 1920x1080@60 and 1920x1080@50 don't work. This points to something specific
>>> to
>>> the modeline.
>>>
>>> By diff'ing the relevant part of the logs between kernels one can see that
>>> in
>>> the cases where the screen stays black the log lacks the following lines:
>>>
>>> rockchip-hdptx-phy fed60000.phy: rk_hdptx_ropll_tmds_cmn_config
>>> rate=185625000 mdiv=155 sdiv=4 sdm_en=1 k_sign=1 k=16 lc=62
>>> rockchip-hdptx-phy fed60000.phy: PHY clk ready
>>>
>>> So obviously the PHY clock never gets ready.
>>>
>>> I also attached the diffs I made.
>>
>> Thanks for checking this out! The behavior is really unexpected and I'm still
>> unable to reproduce on my end, i.e. even tested with a Samsung TV, which is
>> almost as old as yours:
>>
>> # Mine
>> Vendor & Product Identification:
>> Manufacturer: SAM
>> Model: 2685
>> Serial Number: 1 (0x00000001)
>> Made in: week 46 of 2012
>>
>> # Yours
>> Vendor & Product Identification:
>> Manufacturer: SAM
>> Model: 1641
>> Serial Number: 1 (0x00000001)
>> Made in: week 47 of 2009
>>
>> I added some more debug information, hence could you please apply commit [1]
>> on
>> your next-20260213 kernel and share the logs after testing again the
>> 1920x1080@50 and 1920x1080@30 modes?
>>
>> [1]
>> https://gitlab.collabora.com/cristicc/linux-next/-/commit/2ce4b1fb60fc601068abbe9131c05c4f09f1380c
>>
>>
>
> Please find the logs attached.
Sorry, I somehow missed the following warning message, though it has been
already present in all the logs you've sent to me so far:
rockchip-hdptx-phy fed60000.phy: PLL locked by unknown consumer!
That indicates the PHY has been preconfigured by an external component (e.g. the
bootloader), which is actually a scenario that I didn't verify.
However, this just another way to expose a limitation of the current approach
for managing the TMDS character rate: done via the Common Clock Framework API
instead of the HDMI PHY configuration API.
As a matter of fact, it was actually an item on my TODOs list for quite a while,
but blocked until recently due to several dependencies waiting to be merged
upstream.
Hence I took the opportunity to finalize this task - please give the following
commits in my rk3588-hdmi-debug branch [2] a try:
07b579f28fe0 ("phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc")
ef714855512a ("phy: rockchip: samsung-hdptx: Exclusively use PHY config API for PLL changes")
In case further debugging is necessary, you may also pick:
1cddea39cd92 ("[DEBUG] drm/rockchip: Add HDMI verbose logging")
In the meantime, I'll do some more testing on my end. Moreover, I'm going to
prepare a couple of additional cleanup patches (unrelated to this issue) before
sending the series out.
Regards,
Cristian
[2] https://gitlab.collabora.com/cristicc/linux-next/-/commits/rk3588-hdmi-debug
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: Cristian Ciocaltea @ 2026-02-18 1:22 UTC (permalink / raw)
To: dubito, Vinod Koul, Neil Armstrong, Heiko Stuebner, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, regressions
In-Reply-To: <08369c90-fbab-477d-9ac6-388deddfd3b1@collabora.com>
On 2/18/26 2:52 AM, Cristian Ciocaltea wrote:
> Hi Thomas,
[...]
>
> Sorry, I somehow missed the following warning message, though it has been
> already present in all the logs you've sent to me so far:
>
> rockchip-hdptx-phy fed60000.phy: PLL locked by unknown consumer!
>
> That indicates the PHY has been preconfigured by an external component (e.g. the
> bootloader), which is actually a scenario that I didn't verify.
>
> However, this just another way to expose a limitation of the current approach
> for managing the TMDS character rate: done via the Common Clock Framework API
> instead of the HDMI PHY configuration API.
>
> As a matter of fact, it was actually an item on my TODOs list for quite a while,
> but blocked until recently due to several dependencies waiting to be merged
> upstream.
>
> Hence I took the opportunity to finalize this task - please give the following
> commits in my rk3588-hdmi-debug branch [2] a try:
I've just realized I introduced a regression while doing some cleanup work, hence
please ignore this until further notice.
Cristian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
From: Martin K. Petersen @ 2026-02-18 2:33 UTC (permalink / raw)
To: Luca Weiss
Cc: Martin K. Petersen, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Alim Akhtar,
Avri Altman, Bart Van Assche, Vinod Koul, Neil Armstrong,
Konrad Dybcio, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, linux-crypto, devicetree, linux-kernel, linux-scsi,
linux-phy, Krzysztof Kozlowski
In-Reply-To: <DGDW69W84LJ1.2GHM2WU31VANR@fairphone.com>
Luca,
> I've added you to this email now since you seem to pick up most
> patches for these files. Could you take this one please to unblock
> Milos UFS dts?
Sure. Once the merge window is closed...
--
Martin K. Petersen
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qcom: m31-eusb2: clear PLL_EN during init
From: Konrad Dybcio @ 2026-02-18 10:58 UTC (permalink / raw)
To: Elson Serrao, Vinod Koul, Konrad Dybcio, Neil Armstrong,
Wesley Cheng, Johan Hovold, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260217201130.2804550-1-elson.serrao@oss.qualcomm.com>
On 2/17/26 9:11 PM, Elson Serrao wrote:
> The driver currently sets bit 0 of USB_PHY_CFG1 (PLL_EN) during PHY
> initialization. According to the M31 EUSB2 PHY hardware documentation,
> this bit is intended only for test/debug scenarios and does not control
> mission mode operation. Keeping PLL_EN asserted causes the PHY to draw
> additional current during USB bus suspend. Clearing this bit results in
> lower suspend power consumption without affecting normal operation.
>
> Update the driver to leave PLL_EN cleared as recommended by the hardware
> documentation.
>
> Fixes: 9c8504861cc4 ("phy: qcom: Add M31 based eUSB2 PHY driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Russell King (Oracle) @ 2026-02-18 13:15 UTC (permalink / raw)
To: Vinod Koul
Cc: Vladimir Oltean, Neil Armstrong, Jonathan Corbet, linux-doc,
linux-phy
In-Reply-To: <aY1f48Db7KeYRR87@vaman>
On Thu, Feb 12, 2026 at 10:36:43AM +0530, Vinod Koul wrote:
> On 11-02-26, 17:48, Vladimir Oltean wrote:
> > On Thu, Feb 05, 2026 at 02:56:15PM +0000, Russell King (Oracle) wrote:
> > > Update the generic PHY documentation as a result of the discussion for
> > > the s32g submission.
> > >
> > > Link: https://lore.kernel.org/r/aXtvDn_-pCuKPrnf@vaman
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > > ---
> > > I didn't get any replies to my follow-up question to Vinod:
>
> Sorry to have missed that...
>
> > > Please also indicate in the documentation whether changing the submode
> > > of the serdes (particularly for ethernet) is permitted without doing a
> > > phy_power_down()..phy_power_up() dance around the phy_set_mode_ext()
> > > call.
> >
> > There's certainly nothing *not* permitting that call sequence.
>
> I agree on that. The documentation can be update to reflect that. Common
> logic would say that we should set things up before powering up, that
> should be the guidance here as well.
This is what my documentation patch does. It adds the possibility of
calling phy_set_mode*() before phy_power_on(), and recommends calling
phy_set_mode*() at that point, rather than the current situation where
the recommendation is after phy_power_on(). It leaves the possibility
of calling phy_set_mode*() afterwards in place.
It isn't clear to me what is required here - it seems that there is
disagreement between Vladimir and yourself, so I'm not planning to
submit an updated patch. Someone who knows what they're doing with
the generic phy stuff needs to propose a patch, and that ain't me.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: pci: xilinx-nwl: Add resets
From: Manivannan Sadhasivam @ 2026-02-18 16:36 UTC (permalink / raw)
To: Sean Anderson
Cc: Pandey, Radhey Shyam, Laurent Pinchart, Vinod Koul,
linux-phy@lists.infradead.org, Krzysztof Wilczyński,
Lorenzo Pieralisi, linux-kernel@vger.kernel.org, Simek, Michal,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
Neil Armstrong, Rob Herring, Havalige, Thippeswamy, Bjorn Helgaas,
Conor Dooley, Krzysztof Kozlowski, devicetree@vger.kernel.org
In-Reply-To: <89516358-7b13-43ad-b303-1731f61d72e7@linux.dev>
On Thu, Feb 05, 2026 at 10:47:21AM -0500, Sean Anderson wrote:
> On 2/4/26 03:32, Pandey, Radhey Shyam wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> >> -----Original Message-----
> >> From: Sean Anderson <sean.anderson@linux.dev>
> >> Sent: Tuesday, February 3, 2026 5:51 AM
> >> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Vinod Koul
> >> <vkoul@kernel.org>; linux-phy@lists.infradead.org
> >> Cc: Krzysztof Wilczyński <kwilczynski@kernel.org>; Lorenzo Pieralisi
> >> <lpieralisi@kernel.org>; Pandey, Radhey Shyam
> >> <radhey.shyam.pandey@amd.com>; linux-kernel@vger.kernel.org; Simek, Michal
> >> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> >> pci@vger.kernel.org; Neil Armstrong <neil.armstrong@linaro.org>; Rob Herring
> >> <robh@kernel.org>; Havalige, Thippeswamy <thippeswamy.havalige@amd.com>;
> >> Manivannan Sadhasivam <mani@kernel.org>; Bjorn Helgaas
> >> <bhelgaas@google.com>; Sean Anderson <sean.anderson@linux.dev>; Conor
> >> Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> >> devicetree@vger.kernel.org
> >> Subject: [PATCH 1/8] dt-bindings: pci: xilinx-nwl: Add resets
> >>
> >> Add resets so we can hold the bridge in reset while we perform phy calibration.
> >
> > Seems like this should a required property?
>
> It's optional as it does not exist in previous versions of the
> devicetree. In the past I have received pushback against making these
> sort of properties required.
>
> If the resets don't exist we just don't assert them and assume the
> bootloader has deasserted them.
>
If the resets are pretty much required for the hardware functionality, we can
mark them as required in the binding and accept the ABI breakage. This scenario
keeps coming with devicetree as the initial devicetree bindings lacked full
hardware description in most of the cases.
- Mani
> --Sean
>
> > Rest looks fine to me.
> >
> >>
> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> >> ---
> >>
> >> .../devicetree/bindings/pci/xlnx,nwl-pcie.yaml | 17 +++++++++++++++++
> >> 1 file changed, 17 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
> >> b/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
> >> index 9de3c09efb6e..7efb3dd9955f 100644
> >> --- a/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
> >> +++ b/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
> >> @@ -69,6 +69,18 @@ properties:
> >> power-domains:
> >> maxItems: 1
> >>
> >> + resets:
> >> + maxItems: 3
> >> +
> >> + reset-names:
> >> + items:
> >> + - description: APB register block reset
> >> + const: cfg
> >> + - description: AXI-PCIe bridge reset
> >> + const: bridge
> >> + - description: PCIe MAC reset
> >> + const: ctrl
> >> +
> >> iommus:
> >> maxItems: 1
> >>
> >> @@ -117,6 +129,7 @@ examples:
> >> #include <dt-bindings/interrupt-controller/irq.h>
> >> #include <dt-bindings/phy/phy.h>
> >> #include <dt-bindings/power/xlnx-zynqmp-power.h>
> >> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h>
> >> soc {
> >> #address-cells = <2>;
> >> #size-cells = <2>;
> >> @@ -146,6 +159,10 @@ examples:
> >> msi-parent = <&nwl_pcie>;
> >> phys = <&psgtr 0 PHY_TYPE_PCIE 0 0>;
> >> power-domains = <&zynqmp_firmware PD_PCIE>;
> >> + resets = <&zynqmp_reset ZYNQMP_RESET_PCIE_CFG>,
> >> + <&zynqmp_reset ZYNQMP_RESET_PCIE_BRIDGE>,
> >> + <&zynqmp_reset ZYNQMP_RESET_PCIE_CTRL>;
> >> + reset-names = "cfg", "bridge", "ctrl";
> >> iommus = <&smmu 0x4d0>;
> >> pcie_intc: legacy-interrupt-controller {
> >> interrupt-controller;
> >> --
> >> 2.35.1.1320.gc452695387.dirty
> >
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 7/8] PCI: xilinx-nwl: Reset the core during probe
From: Manivannan Sadhasivam @ 2026-02-18 16:42 UTC (permalink / raw)
To: Sean Anderson, Radhey Shyam Pandey, Michal Simek,
Thippeswamy Havalige
Cc: Laurent Pinchart, Vinod Koul, linux-phy,
Krzysztof Wilczyński, Lorenzo Pieralisi, linux-kernel,
linux-arm-kernel, linux-pci, Neil Armstrong, Rob Herring,
Bjorn Helgaas
In-Reply-To: <20260203002128.935842-8-sean.anderson@linux.dev>
On Mon, Feb 02, 2026 at 07:21:27PM -0500, Sean Anderson wrote:
> The PCIe core must be held in reset when initializing phys.
> Assert/deassert the appropriate resets.
>
> Resetting the core also resets the PCIe attributes to their default
> values, so initialize those too. For the most part the defaults are
> fine, but there are many attributes that default to an endpoint
> configuration and must be reprogrammed to function as a root device.
> We generally follow the controller programming sequence from UG1085.
>
> Xilinx was extremely imaginative and named all the registers ATTR_1,
> ATTR_2 etc. (with the fields organized in alphabetical order) so we
> follow the same convention. Only the fields are named, but sometimes a
> field is split across multiple registers. All the BARs are unused but
> some are repurposed as bridge registers when used as a root port.
>
Can someone from AMD/Xilinx review this patch?
- Mani
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
> drivers/pci/controller/pcie-xilinx-nwl.c | 177 +++++++++++++++++++++++
> 1 file changed, 177 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
> index 7cfdc21e6f40..b78fbad1efa5 100644
> --- a/drivers/pci/controller/pcie-xilinx-nwl.c
> +++ b/drivers/pci/controller/pcie-xilinx-nwl.c
> @@ -22,6 +22,7 @@
> #include <linux/pci-ecam.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/reset.h>
> #include <linux/irqchip/chained_irq.h>
>
> #include "../pci.h"
> @@ -133,6 +134,54 @@
> #define CFG_DMA_REG_BAR GENMASK(2, 0)
> #define CFG_PCIE_CACHE GENMASK(7, 0)
>
> +#define PCIE_ATTR2_AER_CAP_PERMIT_ROOTERR_UPDATE BIT(0)
> +
> +#define PCIE_ATTR25_CPL_TIMEOUT_DISABLE_SUPPORTED BIT(9)
> +#define PCIE_ATTR25_INTX_IMPLEMENTED BIT(8)
> +#define PCIE_ATTR25_CLASS_CODE GENMASK(7, 0)
> +
> +#define PCIE_ATTR27_DEV_CAP_ENDPOINT_L1_LATENCY GENMASK(5, 3)
> +
> +#define PCIE_ATTR34_HEADER_TYPE GENMASK(7, 0)
> +
> +#define PCIE_ATTR35_LINK_CAP_DLL_ACTIVE_REPORTING BIT(15)
> +
> +#define PCIE_ATTR37_LINK_CAP_MAX_LINK_SPEED GENMASK(13, 10)
> +#define PCIE_ATTR37_LINK_CAP_MAX_LINK_SPEED_2_5 1
> +#define PCIE_ATTR37_LINK_CAP_MAX_LINK_SPEED_5_0 2
> +#define PCIE_ATTR37_LINK_CAP_BANDWIDTH_NOTIFICATION BIT(9)
> +
> +#define PCIE_ATTR50_CAP_DEVICE_PORT_TYPE GENMASK(7, 4)
> +#define PCIE_ATTR50_CAP_NEXTPTR GENMASK(15, 8)
> +
> +#define PCIE_ATTR53_CAP_NEXTPTR GENMASK(7, 0)
> +
> +#define PCIE_ATTR93_LL_REPLAY_TIMEOUT_EN BIT(15)
> +
> +#define PCIE_ATTR97_LTSSM_MAX_LINK_WIDTH GENMASK(11, 6)
> +#define PCIE_ATTR97_LINK_CAP_MAX_LINK_WIDTH GENMASK(5, 0)
> +
> +#define PCIE_ATTR100_UPSTREAM_FACING BIT(6)
> +
> +#define PCIE_ATTR101_EN_MSG_ROUTE GENMASK(15, 5)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_PME_TURN_OFF BIT(15)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_UNLOCK BIT(14)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_PME_TO_ACK BIT(13)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_PM_PME BIT(12)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_INTD BIT(11)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_INTC BIT(10)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_INTB BIT(9)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_INTA BIT(8)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_ERR_FATAL BIT(7)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_ERR_NONFATAL BIT(6)
> +#define PCIE_ATTR101_EN_MSG_ROUTE_ERR_COR BIT(5)
> +#define PCIE_ATTR101_DISABLE_BAR_FILTERING BIT(1)
> +
> +#define PCIE_ATTR106_VC0_TOTAL_CREDITS_NPH GENMASK(13, 7)
> +#define PCIE_ATTR106_VC0_TOTAL_CREDITS_CH GENMASK(6, 0)
> +
> +#define PCIE_ATTR109_VC0_TOTAL_CREDITS_PH GENMASK(6, 0)
> +
> #define INT_PCI_MSI_NR (2 * 32)
>
> /* Readin the PS_LINKUP */
> @@ -159,6 +208,7 @@ struct nwl_pcie {
> void __iomem *pcireg_base;
> void __iomem *ecam_base;
> struct phy *phy[4];
> + struct reset_control *ctrl_reset;
> phys_addr_t phys_breg_base; /* Physical Bridge Register Base */
> phys_addr_t phys_pcie_reg_base; /* Physical PCIe Controller Base */
> phys_addr_t phys_ecam_base; /* Physical Configuration Base */
> @@ -173,6 +223,115 @@ struct nwl_pcie {
> raw_spinlock_t leg_mask_lock;
> };
>
> +static void nwl_pcie_write_attr(struct nwl_pcie *pcie, u32 attr, u16 val)
> +{
> + writel(val, pcie->pcireg_base + attr * 4);
> +}
> +
> +static void nwl_pcie_modify_attr(struct nwl_pcie *pcie, u32 attr, u16 clear,
> + u16 set)
> +{
> + u32 val = readl(pcie->pcireg_base + attr * 4);
> +
> + nwl_pcie_write_attr(pcie, attr, (val & ~clear) | set);
> +}
> +
> +static void nwl_pcie_attr_init(struct nwl_pcie *pcie)
> +{
> + unsigned int width;
> +
> + for (width = ARRAY_SIZE(pcie->phy); width; width--)
> + if (pcie->phy[width - 1])
> + break;
> +
> + /* Set TLP header to type-1 */
> + nwl_pcie_modify_attr(pcie, 34, PCIE_ATTR34_HEADER_TYPE, PCI_HEADER_TYPE_BRIDGE);
> + nwl_pcie_modify_attr(pcie, 100, PCIE_ATTR100_UPSTREAM_FACING, 0);
> +
> + /* Disable BAR0/1 */
> + nwl_pcie_write_attr(pcie, 7, 0);
> + nwl_pcie_write_attr(pcie, 8, 0);
> + nwl_pcie_write_attr(pcie, 9, 0);
> + nwl_pcie_write_attr(pcie, 10, 0);
> + /* Enable primary/secondary/subordinate busses, disable latency timer */
> + nwl_pcie_write_attr(pcie, 11, 0xffff);
> + nwl_pcie_write_attr(pcie, 12, 0x00ff);
> + nwl_pcie_write_attr(pcie, 13, 0x0000); /* Disable I/O window */
> + nwl_pcie_write_attr(pcie, 14, 0x0000); /* Enable secondary status */
> + /* Enable memory window */
> + nwl_pcie_write_attr(pcie, 15, (u16)PCI_MEMORY_RANGE_MASK);
> + nwl_pcie_write_attr(pcie, 16, (u16)PCI_MEMORY_RANGE_MASK);
> + /* Enable 64-bit prefetchable window */
> + nwl_pcie_write_attr(pcie, 17,
> + (u16)PCI_PREF_RANGE_MASK | PCI_PREF_RANGE_TYPE_64);
> + nwl_pcie_write_attr(pcie, 18,
> + (u16)PCI_PREF_RANGE_MASK | PCI_PREF_RANGE_TYPE_64);
> + nwl_pcie_modify_attr(pcie, 101, 0, PCIE_ATTR101_DISABLE_BAR_FILTERING);
> +
> + /* Set class code to PCI_CLASS_BRIDGE_PCI_NORMAL */
> + nwl_pcie_write_attr(pcie, 24, PCI_CLASS_BRIDGE_PCI_NORMAL & 0xffff);
> + nwl_pcie_modify_attr(pcie, 25, PCIE_ATTR25_CLASS_CODE,
> + PCIE_ATTR25_CPL_TIMEOUT_DISABLE_SUPPORTED |
> + PCI_BASE_CLASS_BRIDGE);
> +
> + /* Enable PCIe capability */
> + nwl_pcie_modify_attr(pcie, 53, PCIE_ATTR53_CAP_NEXTPTR, 0x60);
> + nwl_pcie_modify_attr(pcie, 50,
> + PCIE_ATTR50_CAP_NEXTPTR |
> + PCIE_ATTR50_CAP_DEVICE_PORT_TYPE,
> + FIELD_PREP(PCIE_ATTR50_CAP_DEVICE_PORT_TYPE,
> + PCI_EXP_TYPE_ROOT_PORT));
> +
> + /* Disable MSI(-X) capability */
> + nwl_pcie_write_attr(pcie, 41, 0);
> + nwl_pcie_write_attr(pcie, 43, 0);
> + nwl_pcie_write_attr(pcie, 44, 0);
> + nwl_pcie_write_attr(pcie, 45, 0);
> + nwl_pcie_write_attr(pcie, 46, 0);
> + nwl_pcie_write_attr(pcie, 48, 0);
> +
> + /* Disable DSN capability */
> + nwl_pcie_write_attr(pcie, 31, 0);
> + nwl_pcie_write_attr(pcie, 82, PCI_CFG_SPACE_SIZE);
> +
> + /* Enable AER */
> + nwl_pcie_modify_attr(pcie, 2, 0,
> + PCIE_ATTR2_AER_CAP_PERMIT_ROOTERR_UPDATE);
> +
> + /* Disable L1 latency for root port */
> + nwl_pcie_modify_attr(pcie, 27,
> + PCIE_ATTR27_DEV_CAP_ENDPOINT_L1_LATENCY, 0);
> +
> + /* Enable bandwidth notification */
> + nwl_pcie_modify_attr(pcie, 37, 0,
> + PCIE_ATTR37_LINK_CAP_BANDWIDTH_NOTIFICATION);
> +
> + /* Set max link width */
> + nwl_pcie_write_attr(pcie, 97,
> + FIELD_PREP(PCIE_ATTR97_LTSSM_MAX_LINK_WIDTH, width) |
> + FIELD_PREP(PCIE_ATTR97_LINK_CAP_MAX_LINK_WIDTH, width));
> +
> + /* Route misc. TLPs to controller */
> + nwl_pcie_modify_attr(pcie, 101, PCIE_ATTR101_EN_MSG_ROUTE,
> + PCIE_ATTR101_EN_MSG_ROUTE_INTA |
> + PCIE_ATTR101_EN_MSG_ROUTE_INTB |
> + PCIE_ATTR101_EN_MSG_ROUTE_INTC |
> + PCIE_ATTR101_EN_MSG_ROUTE_INTD |
> + PCIE_ATTR101_EN_MSG_ROUTE_PM_PME |
> + PCIE_ATTR101_EN_MSG_ROUTE_PME_TO_ACK |
> + PCIE_ATTR101_EN_MSG_ROUTE_UNLOCK |
> + PCIE_ATTR101_EN_MSG_ROUTE_PME_TURN_OFF);
> +
> + /* Initialize completion credits */
> + nwl_pcie_write_attr(pcie, 105, 205); /* CD */
> + nwl_pcie_write_attr(pcie, 106,
> + FIELD_PREP(PCIE_ATTR106_VC0_TOTAL_CREDITS_NPH, 12) |
> + FIELD_PREP(PCIE_ATTR106_VC0_TOTAL_CREDITS_CH, 36));
> + nwl_pcie_write_attr(pcie, 107, 24); /* NPD */
> + nwl_pcie_write_attr(pcie, 108, 181); /* PD */
> + nwl_pcie_modify_attr(pcie, 109, PCIE_ATTR109_VC0_TOTAL_CREDITS_PH, 32);
> +}
> +
> static inline u32 nwl_bridge_readl(struct nwl_pcie *pcie, u32 off)
> {
> return readl(pcie->breg_base + off);
> @@ -806,6 +965,9 @@ static int nwl_pcie_parse_dt(struct nwl_pcie *pcie,
> irq_set_chained_handler_and_data(pcie->irq_intx,
> nwl_pcie_leg_handler, pcie);
>
> + pcie->ctrl_reset = devm_reset_control_get_optional(dev, "ctrl");
> + if (IS_ERR(pcie->ctrl_reset))
> + return PTR_ERR(pcie->ctrl_reset);
>
> for (i = 0; i < ARRAY_SIZE(pcie->phy); i++) {
> pcie->phy[i] = devm_of_phy_get_by_index(dev, dev->of_node, i);
> @@ -852,6 +1014,12 @@ static int nwl_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(pcie->clk))
> return PTR_ERR(pcie->clk);
>
> + err = reset_control_assert(pcie->ctrl_reset);
> + if (err) {
> + dev_err(dev, "could not enter reset\n");
> + return err;
> + }
> +
> err = clk_prepare_enable(pcie->clk);
> if (err) {
> dev_err(dev, "can't enable PCIe ref clock\n");
> @@ -864,6 +1032,15 @@ static int nwl_pcie_probe(struct platform_device *pdev)
> goto err_clk;
> }
>
> + if (pcie->ctrl_reset)
> + nwl_pcie_attr_init(pcie);
> +
> + err = reset_control_deassert(pcie->ctrl_reset);
> + if (err) {
> + dev_err(dev, "could not release from reset\n");
> + goto err_phy_init;
> + }
> +
> err = nwl_pcie_phy_power_on(pcie);
> if (err) {
> dev_err(dev, "could not power on PHYs\n");
> --
> 2.35.1.1320.gc452695387.dirty
>
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: Cristian Ciocaltea @ 2026-02-18 20:15 UTC (permalink / raw)
To: dubito, Vinod Koul, Neil Armstrong, Heiko Stuebner, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, regressions
In-Reply-To: <26e31b3b-484f-433b-833f-c639ee437f63@collabora.com>
On 2/18/26 3:22 AM, Cristian Ciocaltea wrote:
> On 2/18/26 2:52 AM, Cristian Ciocaltea wrote:
>> Hi Thomas,
> [...]
>
>>
>> Sorry, I somehow missed the following warning message, though it has been
>> already present in all the logs you've sent to me so far:
>>
>> rockchip-hdptx-phy fed60000.phy: PLL locked by unknown consumer!
>>
>> That indicates the PHY has been preconfigured by an external component (e.g. the
>> bootloader), which is actually a scenario that I didn't verify.
>>
>> However, this just another way to expose a limitation of the current approach
>> for managing the TMDS character rate: done via the Common Clock Framework API
>> instead of the HDMI PHY configuration API.
>>
>> As a matter of fact, it was actually an item on my TODOs list for quite a while,
>> but blocked until recently due to several dependencies waiting to be merged
>> upstream.
>>
>> Hence I took the opportunity to finalize this task - please give the following
>> commits in my rk3588-hdmi-debug branch [2] a try:
>
> I've just realized I introduced a regression while doing some cleanup work, hence
> please ignore this until further notice.
I think I got this working properly now, at least it passes all the tests I
could run. The updated commits in [2] are:
fa7cd1e75aaa ("phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc")
8048db5544da ("phy: rockchip: samsung-hdptx: Exclusively use PHY config API for PLL changes")
0085a382dfd0 ("[DEBUG] drm/rockchip: Add HDMI verbose logging")
Regards,
Cristian
[2] https://gitlab.collabora.com/cristicc/linux-next/-/commits/rk3588-hdmi-debug
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: 1und1 @ 2026-02-18 20:43 UTC (permalink / raw)
To: Cristian Ciocaltea, Vinod Koul, Neil Armstrong, Heiko Stuebner,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
regressions
In-Reply-To: <03b5f3d1-6db4-4835-b2a5-c22c1aa63825@collabora.com>
Hi Cristian,
Am Mittwoch, dem 18.02.2026 um 22:15 +0200 schrieb Cristian Ciocaltea:
> On 2/18/26 3:22 AM, Cristian Ciocaltea wrote:
> > On 2/18/26 2:52 AM, Cristian Ciocaltea wrote:
> > > Hi Thomas,
> > [...]
> >
> > >
> > > Sorry, I somehow missed the following warning message, though it has been
> > > already present in all the logs you've sent to me so far:
> > >
> > > rockchip-hdptx-phy fed60000.phy: PLL locked by unknown consumer!
> > >
> > > That indicates the PHY has been preconfigured by an external component
> > > (e.g. the
> > > bootloader), which is actually a scenario that I didn't verify.
> > >
> > > However, this just another way to expose a limitation of the current
> > > approach
> > > for managing the TMDS character rate: done via the Common Clock Framework
> > > API
> > > instead of the HDMI PHY configuration API.
> > >
> > > As a matter of fact, it was actually an item on my TODOs list for quite a
> > > while,
> > > but blocked until recently due to several dependencies waiting to be
> > > merged
> > > upstream.
> > >
> > > Hence I took the opportunity to finalize this task - please give the
> > > following
> > > commits in my rk3588-hdmi-debug branch [2] a try:
> >
> > I've just realized I introduced a regression while doing some cleanup work,
> > hence
> > please ignore this until further notice.
>
> I think I got this working properly now, at least it passes all the tests I
> could run. The updated commits in [2] are:
>
> fa7cd1e75aaa ("phy: rockchip: samsung-hdptx: Fix rate recalculation for high
> bpc")
> 8048db5544da ("phy: rockchip: samsung-hdptx: Exclusively use PHY config API
> for PLL changes")
> 0085a382dfd0 ("[DEBUG] drm/rockchip: Add HDMI verbose logging")
>
applying these commits solves my problems. I tested 1920x1080@60, 1920x1080@50
and 1920x1080@30. All work now. Thanks for the quick fix! And the positive side
effect seems to be that you can now take one of your old todos from your list.
Best regards,
Thomas
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: Cristian Ciocaltea @ 2026-02-18 20:56 UTC (permalink / raw)
To: dubito, Vinod Koul, Neil Armstrong, Heiko Stuebner, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, regressions
In-Reply-To: <a3c3964e9e13c82d944fa1ee0acbb1a7806dd382.camel@online.de>
Hi Thomas,
On 2/18/26 10:43 PM, 1und1 wrote:
> Hi Cristian,
>
>
> Am Mittwoch, dem 18.02.2026 um 22:15 +0200 schrieb Cristian Ciocaltea:
>> On 2/18/26 3:22 AM, Cristian Ciocaltea wrote:
>>> On 2/18/26 2:52 AM, Cristian Ciocaltea wrote:
>>>> Hi Thomas,
>>> [...]
>>>
>>>>
>>>> Sorry, I somehow missed the following warning message, though it has been
>>>> already present in all the logs you've sent to me so far:
>>>>
>>>> rockchip-hdptx-phy fed60000.phy: PLL locked by unknown consumer!
>>>>
>>>> That indicates the PHY has been preconfigured by an external component
>>>> (e.g. the
>>>> bootloader), which is actually a scenario that I didn't verify.
>>>>
>>>> However, this just another way to expose a limitation of the current
>>>> approach
>>>> for managing the TMDS character rate: done via the Common Clock Framework
>>>> API
>>>> instead of the HDMI PHY configuration API.
>>>>
>>>> As a matter of fact, it was actually an item on my TODOs list for quite a
>>>> while,
>>>> but blocked until recently due to several dependencies waiting to be
>>>> merged
>>>> upstream.
>>>>
>>>> Hence I took the opportunity to finalize this task - please give the
>>>> following
>>>> commits in my rk3588-hdmi-debug branch [2] a try:
>>>
>>> I've just realized I introduced a regression while doing some cleanup work,
>>> hence
>>> please ignore this until further notice.
>>
>> I think I got this working properly now, at least it passes all the tests I
>> could run. The updated commits in [2] are:
>>
>> fa7cd1e75aaa ("phy: rockchip: samsung-hdptx: Fix rate recalculation for high
>> bpc")
>> 8048db5544da ("phy: rockchip: samsung-hdptx: Exclusively use PHY config API
>> for PLL changes")
>> 0085a382dfd0 ("[DEBUG] drm/rockchip: Add HDMI verbose logging")
>>
>
> applying these commits solves my problems. I tested 1920x1080@60, 1920x1080@50
> and 1920x1080@30. All work now. Thanks for the quick fix!
Thanks for the quick test!
I can add you to cc: when I submit the series, so that you may provide your
Tested-by tag if you'd like to.
> And the positive side> effect seems to be that you can now take one of your
> old todos from your list.
Indeed. :-)
Regards,
Cristian
--
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