* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Neil Armstrong @ 2026-03-19 16:08 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Bryan O'Donoghue,
Dmitry Baryshkov
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
linux-media, devicetree, linux-kernel
In-Reply-To: <f3c62284-ac78-42c6-a4f0-cd984b7124cd@linaro.org>
On 3/19/26 16:18, Bryan O'Donoghue wrote:
> On 19/03/2026 14:56, Vladimir Zapolskiy wrote:
>>> There's no reason to remove that from CAMSS - it would be an ABI break
>>> in user-space anyway.
>>
>> If technically CAMSS CSIPHY could be excluded from the list of CAMSS media
>> subdevices, then for the sake of simplification it should be done for all
>> supported platforms in advance, such a change will be independent from this
>> particular phy series, and vice versa, this CAMSS only driver change will
>> prepare a ground for media-less CAMSS CSIPHY device drivers, hence it shall
>> precede this particular CAMSS CSIPHY series.
>>
>> For backward compatibility with userspace a noop stub will be good enough,
>> it's not an issue at all.
>
> The standalone PHY driver doesn't require removing the CSIPHY media
> entity from CAMSS. They serve different purposes and coexist - its important to have a NOP from user-space perspective for legacy and indeed for new implementations.
>
> How the PHY gets represented in the kernel is of zero interest to user-sapce.
>
> That said, stubbing out the media entity is independent work that can happen in any order and IMO is a separate debate. Whether or not CSIPHY init sequences live inside of a monolithic CAMSS driver or live inside off a discrete csiphy driver is not related to the media graph.
>
> Happy to have that debate - and if indicated, carefully apply patches separately.
So what does this actually solves ?
Neil
>
> ---
> bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-03-19 15:18 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Dmitry Baryshkov,
Neil Armstrong
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
linux-media, devicetree, linux-kernel
In-Reply-To: <d6616fc0-75fb-47e2-96cd-ae81fa1a8e82@linaro.org>
On 19/03/2026 14:56, Vladimir Zapolskiy wrote:
>> There's no reason to remove that from CAMSS - it would be an ABI break
>> in user-space anyway.
>
> If technically CAMSS CSIPHY could be excluded from the list of CAMSS media
> subdevices, then for the sake of simplification it should be done for all
> supported platforms in advance, such a change will be independent from this
> particular phy series, and vice versa, this CAMSS only driver change will
> prepare a ground for media-less CAMSS CSIPHY device drivers, hence it shall
> precede this particular CAMSS CSIPHY series.
>
> For backward compatibility with userspace a noop stub will be good enough,
> it's not an issue at all.
The standalone PHY driver doesn't require removing the CSIPHY media
entity from CAMSS. They serve different purposes and coexist - its
important to have a NOP from user-space perspective for legacy and
indeed for new implementations.
How the PHY gets represented in the kernel is of zero interest to
user-sapce.
That said, stubbing out the media entity is independent work that can
happen in any order and IMO is a separate debate. Whether or not CSIPHY
init sequences live inside of a monolithic CAMSS driver or live inside
off a discrete csiphy driver is not related to the media graph.
Happy to have that debate - and if indicated, carefully apply patches
separately.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-03-19 15:06 UTC (permalink / raw)
To: Neil Armstrong, Vladimir Zapolskiy, Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <4d376a1b-37d7-4d37-8579-a0053f7b91f2@linaro.org>
On 19/03/2026 14:05, Neil Armstrong wrote:
>> There's no reason to remove that from CAMSS - it would be an ABI break in user-space anyway.
>>
>> The media entity in CAMSS msm_csiphyX handles format negotiation and pipeline routing. The PHY driver handles electrical configuration. They don't conflict and there multiple cited examples of this upstream already.
> If csiphy component was only handling electrical configuration, the only code handling csiphy would be phy API calls, not be part of the pipeline configuration. Today, it's a media element
>
> The whole CAMSS architecture is wrong, it should be modular, each hardware module should be an independent driver and all be connected via port/endpoint and configured with the media controller API.
>
> If you_really_ want to move the "electrical configuration" part of the CSPIPHY out of camss frankendriver, fine, then first just create an internal PHY device as an aux device, then continue migrating_all_ CAMSS components into independent driver modules, then in the end re-architecture the whole DT description by adding a node per component with a proper port/endpoint representation to be configured via the media controller API.
>
> Neil
Re-architecting the whole driver without breaking legacy code is well
out of scope.
I'd note making a standalone CSIPHY driver 100% fits in with such a
goal. I don't think I've seen one good reason why CAMSS needs an aux
device and can't follow established upstream paradigms for Cadence and
Rockchip.
Anyway I take the feedback on polarities and will in v5 of this patch
address.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Vladimir Zapolskiy @ 2026-03-19 14:56 UTC (permalink / raw)
To: Bryan O'Donoghue, Dmitry Baryshkov, Neil Armstrong
Cc: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <9578400d-30ac-4d8c-9295-ee4ec8af3b2c@kernel.org>
On 3/19/26 15:17, Bryan O'Donoghue wrote:
> On 19/03/2026 13:08, Vladimir Zapolskiy wrote:
>>> Why do you want a media driver? Isn't PHY driver enough?
>>>
>> As for today CAMSS CSIPHY are already media devices, and a user applies media
>> specific properties to them, for instance media bus format, resolution etc.
>> Technically this might be removed from CAMSS, but if so, then it should be
>> done before this new PHY driver model is applied.
>>
>> --
>> Best wishes,
>
> There's no reason to remove that from CAMSS - it would be an ABI break
> in user-space anyway.
If technically CAMSS CSIPHY could be excluded from the list of CAMSS media
subdevices, then for the sake of simplification it should be done for all
supported platforms in advance, such a change will be independent from this
particular phy series, and vice versa, this CAMSS only driver change will
prepare a ground for media-less CAMSS CSIPHY device drivers, hence it shall
precede this particular CAMSS CSIPHY series.
For backward compatibility with userspace a noop stub will be good enough,
it's not an issue at all.
> The media entity in CAMSS msm_csiphyX handles format negotiation and
> pipeline routing. The PHY driver handles electrical configuration. They
> don't conflict and there multiple cited examples of this upstream already.
>
--
Best wishes,
Vladimir
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Conor Dooley @ 2026-03-19 14:37 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <37396c094c7124169ca376cf6aea5350971aec54.camel@ew.tq-group.com>
[-- Attachment #1.1: Type: text/plain, Size: 1504 bytes --]
On Thu, Mar 19, 2026 at 09:55:24AM +0100, Nora Schiffer wrote:
> On Wed, 2026-03-18 at 17:35 +0000, Conor Dooley wrote:
> > On Wed, Mar 18, 2026 at 03:05:25PM +0100, Nora Schiffer wrote:
> > > The J722S CPSW3G is mostly identical to the AM64's, but additionally
> > > supports SGMII.
> > >
> > > Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> > > ---
> > > Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> > > index a959c1d7e643a..9ab8237c7f79e 100644
> > > --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> > > +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> > > @@ -59,6 +59,7 @@ properties:
> > > - ti,j7200-cpswxg-nuss
> > > - ti,j721e-cpsw-nuss
> > > - ti,j721e-cpswxg-nuss
> > > + - ti,j722s-cpsw-nuss
> >
> > For all these bindings, why is a fallback not suitable? Seems like it'd
> > be possible here, since there's just a new feature. Is there some other
> > programming model difference?
>
> I think a fallback makes sense, I didn't add one because other variants derived
> from the AM64 don't have one either. I can include a fallback in v2 (for all 3
> bindings in this series).
Unless someones got a good reason not to, I think you should do so.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 12/61] quota: Prefer IS_ERR_OR_NULL over manual NULL check
From: Jan Kara @ 2026-03-19 14:13 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Jan Kara
In-Reply-To: <20260310-b4-is_err_or_null-v1-12-bd63b656022d@avm.de>
On Tue 10-03-26 12:48:38, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Jan Kara <jack@suse.com>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Thanks for the patch but frankly I find the original variant clearer wrt
what is going on. So I prefer to keep the code as is.
Honza
> ---
> fs/quota/quota.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> index 33bacd70758007129e0375bab44d7431195ec441..2e09fc247d0cf45b9e83a4f8a0be7ea694c8c2a1 100644
> --- a/fs/quota/quota.c
> +++ b/fs/quota/quota.c
> @@ -965,7 +965,7 @@ SYSCALL_DEFINE4(quotactl, unsigned int, cmd, const char __user *, special,
> else
> drop_super_exclusive(sb);
> out:
> - if (pathp && !IS_ERR(pathp))
> + if (!IS_ERR_OR_NULL(pathp))
> path_put(pathp);
> return ret;
> }
>
> --
> 2.43.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Neil Armstrong @ 2026-03-19 14:05 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <9578400d-30ac-4d8c-9295-ee4ec8af3b2c@kernel.org>
On 3/19/26 14:17, Bryan O'Donoghue wrote:
> On 19/03/2026 13:08, Vladimir Zapolskiy wrote:
>>> Why do you want a media driver? Isn't PHY driver enough?
>>>
>> As for today CAMSS CSIPHY are already media devices, and a user applies media
>> specific properties to them, for instance media bus format, resolution etc.
>> Technically this might be removed from CAMSS, but if so, then it should be
>> done before this new PHY driver model is applied.
>>
>> --
>> Best wishes,
>
> There's no reason to remove that from CAMSS - it would be an ABI break in user-space anyway.
>
> The media entity in CAMSS msm_csiphyX handles format negotiation and pipeline routing. The PHY driver handles electrical configuration. They don't conflict and there multiple cited examples of this upstream already.
If csiphy component was only handling electrical configuration, the only code handling csiphy would be phy API calls, not be part of the pipeline configuration. Today, it's a media element
The whole CAMSS architecture is wrong, it should be modular, each hardware module should be an independent driver and all be connected via port/endpoint and configured with the media controller API.
If you _really_ want to move the "electrical configuration" part of the CSPIPHY out of camss frankendriver, fine, then first just create an internal PHY device as an aux device, then continue migrating _all_ CAMSS components into independent driver modules, then in the end re-architecture the whole DT description by adding a node per component with a proper port/endpoint representation to be configured via the media controller API.
Neil
>
> --
> bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Tobias Heider @ 2026-03-19 13:50 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Andersson, Bjorn Helgaas, Ziyue Zhang, konradybcio, robh,
krzk+dt, conor+dt, jingoohan1, lpieralisi, kwilczynski, bhelgaas,
johan+linaro, vkoul, kishon, neil.armstrong, abel.vesa, kw,
linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <4byysnjodmlphwcevw5gb2asxbwwwlf526mtpwpkfi6crjxoqb@vyuktezfu2wu>
Resending because the previous mail ended up being HTML (sorry)
On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > >
> > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > to the port nodes.
> > > > > > >
> > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > - x1-hp-omnibook-x14
> > > > > > > - x1-microsoft-denali
> > > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > > - x1-asus-zenbook-a14
> > > > > > > - x1-crd
> > > > > > > - x1-dell-thena
> > > > > > >
> > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > >
> > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > the old style with them described in the Root Complex node.
> > > > > >
> > > > >
> > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > combinations, so it fails correctly so.
> > > > >
> > > >
> > > > Are you saying that above listed machines has broken PCIe support in
> > > > v7.0-rc?
> > > >
> > >
> > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > >
> >
> > In line with Bjorn's request, we shouldn't have to guess.
> >
> > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > fixing that change, or is it only applicable once some other changes are
> > > > applied?
> > > >
> > >
> > > This change is fixing the issue in the respective board DTS and is a standalone
> > > fix on top of v7.0-rc1.
> > >
> >
> > So 960609b22be5 was broken when I merged it?
> >
>
> Broken on the machines mentioned in the commit message, not for all Hamoa
> platforms.
>
> > The commit message says that the commit was incomplete, in that it
> > didn't fully convert from the old to the new style, so it sounds like
> > the offending commit was incomplete - but I believe the offending commit
> > was a workaround for the new solution not being in place and this commit
> > mostly reverts the changes in the offending commit.
> >
>
> So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> new for greater good, but it apparently decided to do so only for a subset of
> the platforms for some reason which don't know. But the problem arises due to
> 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> platform DTS to also be changed to the new binding. If we only have either dtsi
> or dts converted and not both to the new binding, the driver will get confused
> and fail. And this is what exactly happended for below machines:
>
> - x1-hp-omnibook-x14
> - x1-microsoft-denali
> - x1e80100-lenovo-yoga-slim7x
> - x1e80100-medion-sprchrgd-14-s1
> - x1p42100-lenovo-thinkbook-16
> - x1-asus-zenbook-a14
> - x1-crd
> - x1-dell-thena
I can confirm the breakage for (some of) the listed devices on Ubuntu.
We are experimenting with 7.0-rcs ahead of our 26.04 release.
I'll try to collect some test feedback for the fix.
I'd certainly appreciate this being included as an rc fix since
currently half of
the x1 laptop devices are broken.
>
> > In other words, it's not clear to me, from the commit message, why this
> > change is a -rc fix. Perhaps the author of the offending commit tricked
> > me to merge that one, and that's what's being fixed?
> >
>
> I wouldn't say that the author has tricked, but he was unaware of the fact that
> changing SoC dtsi warrants change in all platforms, not a subset. I wanted to
> catch these kind of issues with DT binding validation, so I sent out a series
> earlier [1], but it got stuck. I'll push it forward.
>
> [1] https://lore.kernel.org/linux-pci/20251106-pci-binding-v2-0-bebe9345fc4b@oss.qualcomm.com
>
> > Also, is the lack of Tested-by telling us that nobody has tested any of
> > the v7.0-rc on the 8 listed Hamoa devices?
> >
>
> Exactly. Otherwise, they would've seen the failure so obviously.
>
> >
> >
> > If it's actually needed, can we please have the commit message improved
> > so that we can merge it into -rc?
> >
>
> Sure. I'll work with Ziyue to reword it properly.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-03-19 13:17 UTC (permalink / raw)
To: Vladimir Zapolskiy, Dmitry Baryshkov, Neil Armstrong
Cc: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <65e06b2e-eeb9-45af-97ac-4ae60f652361@linaro.org>
On 19/03/2026 13:08, Vladimir Zapolskiy wrote:
>> Why do you want a media driver? Isn't PHY driver enough?
>>
> As for today CAMSS CSIPHY are already media devices, and a user applies media
> specific properties to them, for instance media bus format, resolution etc.
> Technically this might be removed from CAMSS, but if so, then it should be
> done before this new PHY driver model is applied.
>
> --
> Best wishes,
There's no reason to remove that from CAMSS - it would be an ABI break
in user-space anyway.
The media entity in CAMSS msm_csiphyX handles format negotiation and
pipeline routing. The PHY driver handles electrical configuration. They
don't conflict and there multiple cited examples of this upstream already.
--
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Krzysztof Kozlowski @ 2026-03-19 13:12 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bjorn Helgaas
Cc: Ziyue Zhang, andersson, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-phy, qiang.yu,
quic_krichai, quic_vbadigan
In-Reply-To: <f5vqy4tfhfxeu4li33qffjzrlgqgbflidds35qdni3trdoues2@kvuzjxenrdff>
On 19/03/2026 06:28, Manivannan Sadhasivam wrote:
>> If it only affects developers who generated DTs based
>> on 960609b22be5 for internal testing, we should say that so it's clear
>> that no end users will see any regressions or boot failures.
>>
>
> Whoever have included commit 960609b22be5 in their kernel and using the above
> mentioned machines will see the failure. But looks like no one really tested
> v7.0-rcS on these machines as we haven't gotten any reports so far.
>
>> Is there some way to verify that after this patch, none of the
>> generated DTBs are in this half-baked situation? Some kind of
>> automated DTB checker?
>
> I sent out a DT binding series [1] that was supposed to catch these issues
> during DTB validation phase, but unfortunately it got stuck in the review. I'll
> try to stir things up.
>
What about other projects which use this DTB directly (e.g. OpenBSD)?
Are they considered broken with 960609b22be5?
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 v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Vladimir Zapolskiy @ 2026-03-19 13:08 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong
Cc: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <ulenfus552ggobis4gmi7eh27tikdaxbgm2oj63b5l2vemlfxc@ib5f2xaqurj6>
On 3/18/26 17:27, Dmitry Baryshkov wrote:
> On Wed, Mar 18, 2026 at 04:07:39PM +0100, Neil Armstrong wrote:
>> On 3/18/26 14:17, Bryan O'Donoghue wrote:
>>> On 18/03/2026 10:15, Neil Armstrong wrote:
>>>>> + /*
>>>>> + * phy_configure_opts_mipi_dphy.lanes starts from zero to
>>>>> + * the maximum number of enabled lanes.
>>>>> + *
>>>>> + * TODO: add support for bitmask of enabled lanes and polarities
>>>>> + * of those lanes to the phy_configure_opts_mipi_dphy struct.
>>>>> + * For now take the polarities as zero and the position as fixed
>>>>> + * this is fine as no current upstream implementation maps otherwise.
>>>>> + */
>>>>
>>>> This is wrong since you loose the lanes mapping defined in DT, which is still in CAMSS
>>>> but is a PHY property. The lanes layout is not a property of the CSI controller,
>>>> CSI controller only need to know the lanes count, and not the layout.
>>>
>>> Lane layout is a PHY concern but, the PHY API gives us phy_configure_opts_mipi_dphy which should be extended to provide layout and polarity. This would then be of benefit to more than just qcom/camss.
>>
>> Why ? the only concern between a controller and a PHY is the lane count to calculate the bandwidth, the actual pin layout is certainly not a controller concern.
>
> I think that the DT should be providing the information about the
> connection of the lanes and their number on the board. Then the CSI host
> might want to limit this further for whatever reasons. But I don't think
> that the properties of the lanes should be configurable between the
> controller and the PHY.
>
>>
>>>
>>> Right now none of the CAMSS users for this driver depend on any other mapping and I propose a separate series to fix phy_configure_opts_mipi_dphy rather than introduce data-lanes to DPHY.
>>
>> None of the upstream users of camss.
>>
>> The problem is even larger, as you replied in [1], the csiphy is still exposed as a media element from the CAMSS driver, this means this driver is not complete,
>> it should be a media driver entirely with eventually an internal PHY aux driver, but this would be entirely implementation specific.
>>
>> Either the PHY is standalone and the PHY consumer only calls phy_open/init/configure/power_on/power_off/exit, otherwise it's not a fully standaline PHY but a composite device like here.
>>
>> I propose that you write a proper media driver for the qcom csiphy, which eventually spins a PHY driver as an aux device.
>
> Why do you want a media driver? Isn't PHY driver enough?
>
As for today CAMSS CSIPHY are already media devices, and a user applies media
specific properties to them, for instance media bus format, resolution etc.
Technically this might be removed from CAMSS, but if so, then it should be
done before this new PHY driver model is applied.
--
Best wishes,
Vladimir
--
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: Add Eliza QMP PHY
From: Krzysztof Kozlowski @ 2026-03-19 9:29 UTC (permalink / raw)
To: Abel Vesa
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260318-eliza-bindings-qmp-phy-v1-1-96a0d529ad2d@oss.qualcomm.com>
On Wed, Mar 18, 2026 at 11:54:36AM +0200, Abel Vesa wrote:
> Document the compatible for the USB QMP PHY found on the Qualcomm Eliza
> SoC.
>
> It is fully compatible with the one found on Qualcomm SM8650, so add it
> with the SM8650 as fallback.
Reviewed-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 v5 4/4] phy: qualcomm: add MSM8974 HDMI PHY support
From: Konrad Dybcio @ 2026-03-19 9:24 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong, linux-kernel, linux-arm-msm,
dri-devel, freedreno, linux-phy, Dmitry Baryshkov
In-Reply-To: <dpzq6o4qdttbmgtpgit2atjghu2kwrcj36ko3rnvwaehbkvjrk@lr4ms7mi6aiz>
On 3/18/26 6:15 PM, Dmitry Baryshkov wrote:
> On Wed, Mar 18, 2026 at 10:22:08AM +0100, Konrad Dybcio wrote:
>> On 3/14/26 6:06 AM, Dmitry Baryshkov wrote:
>>> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>
>>> Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
>>>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
[...]
>> I don't know if it's a good direction, but maybe:
>>
>> const unsigned long max_rate = HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV;
>>
>> clamp(req->rate, max_rate / 6, max_rate)
>
> Note, it is clamp (min_rate / 6, max_rate)
see, indeed confusing ;)
But I suppose we don't have a better way of specifying that so whatevs
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Nora Schiffer @ 2026-03-19 8:55 UTC (permalink / raw)
To: Conor Dooley
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <20260318-sustained-reshuffle-eaf180729a9c@spud>
On Wed, 2026-03-18 at 17:35 +0000, Conor Dooley wrote:
> On Wed, Mar 18, 2026 at 03:05:25PM +0100, Nora Schiffer wrote:
> > The J722S CPSW3G is mostly identical to the AM64's, but additionally
> > supports SGMII.
> >
> > Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> > ---
> > Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> > index a959c1d7e643a..9ab8237c7f79e 100644
> > --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> > +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> > @@ -59,6 +59,7 @@ properties:
> > - ti,j7200-cpswxg-nuss
> > - ti,j721e-cpsw-nuss
> > - ti,j721e-cpswxg-nuss
> > + - ti,j722s-cpsw-nuss
>
> For all these bindings, why is a fallback not suitable? Seems like it'd
> be possible here, since there's just a new feature. Is there some other
> programming model difference?
I think a fallback makes sense, I didn't add one because other variants derived
from the AM64 don't have one either. I can include a fallback in v2 (for all 3
bindings in this series).
Best,
Nora
>
> > - ti,j784s4-cpswxg-nuss
> >
> > reg:
> > --
> > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > Amtsgericht München, HRB 105018
> > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > https://www.tq-group.com/
> >
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 6/7] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-19 8:52 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <4cc3dd9fab460d35215c8f97496b9ae16c5bcb22.1773751309.git.nora.schiffer@ew.tq-group.com>
On Wed, 2026-03-18 at 15:05 +0100, Nora Schiffer wrote:
> The J722S CPSW3G is mostly identical to the AM64's, but additionally
> supports SGMII.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index d9400599e80a4..fc57d5e6edf4c 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -3468,6 +3468,13 @@ static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
> .fdqring_mode = K3_RINGACC_RING_MODE_RING,
> };
>
> +static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
> + .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ | AM64_CPSW_QUIRK_CUT_THRU,
Ah, I just realized that I sent the wrong version of this patch,
AM64_CPSW_QUIRK_CUT_THRU only exists in the TI vendor kernel... sorry about
this, will fix in v2.
Can someone from TI answer if AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ is needed for the
J722S?
Best,
Nora
> + .ale_dev_id = "am64-cpswxg",
> + .fdqring_mode = K3_RINGACC_RING_MODE_RING,
> + .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
> +};
> +
> static const struct am65_cpsw_pdata j7200_cpswxg_pdata = {
> .quirks = 0,
> .ale_dev_id = "am64-cpswxg",
> @@ -3495,6 +3502,7 @@ static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
> { .compatible = "ti,am654-cpsw-nuss", .data = &am65x_sr1_0},
> { .compatible = "ti,j721e-cpsw-nuss", .data = &j721e_pdata},
> { .compatible = "ti,am642-cpsw-nuss", .data = &am64x_cpswxg_pdata},
> + { .compatible = "ti,j722s-cpsw-nuss", .data = &j722s_cpswxg_pdata},
> { .compatible = "ti,j7200-cpswxg-nuss", .data = &j7200_cpswxg_pdata},
> { .compatible = "ti,j721e-cpswxg-nuss", .data = &j721e_cpswxg_pdata},
> { .compatible = "ti,j784s4-cpswxg-nuss", .data = &j784s4_cpswxg_pdata},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2] phy: renesas: phy-rzg3e-usb3: Fix malformed MODULE_AUTHOR string
From: Biju @ 2026-03-19 6:32 UTC (permalink / raw)
To: Vinod Koul
Cc: Biju Das, Neil Armstrong, Geert Uytterhoeven, linux-phy,
linux-kernel, Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc,
Pavel Machek
From: Biju Das <biju.das.jz@bp.renesas.com>
Fix a malformed MODULE_AUTHOR macro in the RZ/G3E USB3.0 PHY driver where
the author's name and opening angle bracket were missing, leaving only the
email address with a stray closing >. Correct it to the standard Name
<email> format.
Reported-by: Pavel Machek <pavel@nabladev.com>
Closes: https://lore.kernel.org/all/abp4KprlYyU+jMPu@duo.ucw.cz/
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Updated lore link to make it shorter
* Collected tag
---
drivers/phy/renesas/phy-rzg3e-usb3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/renesas/phy-rzg3e-usb3.c b/drivers/phy/renesas/phy-rzg3e-usb3.c
index 6b3453ea0004..030c600a53e6 100644
--- a/drivers/phy/renesas/phy-rzg3e-usb3.c
+++ b/drivers/phy/renesas/phy-rzg3e-usb3.c
@@ -256,4 +256,4 @@ module_platform_driver(rzg3e_phy_usb3_driver);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Renesas RZ/G3E USB3.0 PHY Driver");
-MODULE_AUTHOR("biju.das.jz@bp.renesas.com>");
+MODULE_AUTHOR("Biju Das <biju.das.jz@bp.renesas.com>");
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Manivannan Sadhasivam @ 2026-03-19 5:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Helgaas, Ziyue Zhang, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-phy, qiang.yu,
quic_krichai, quic_vbadigan
In-Reply-To: <abtgaXSv-zRysJqO@baldur>
On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > >
> > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > to the port nodes.
> > > > > >
> > > > > > This fixes probe failures seen on the following platforms:
> > > > > > - x1-hp-omnibook-x14
> > > > > > - x1-microsoft-denali
> > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > - x1-asus-zenbook-a14
> > > > > > - x1-crd
> > > > > > - x1-dell-thena
> > > > > >
> > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > >
> > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > the old style with them described in the Root Complex node.
> > > > >
> > > >
> > > > This is not related to the driver change. The driver correctly parses all Root
> > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > combinations, so it fails correctly so.
> > > >
> > >
> > > Are you saying that above listed machines has broken PCIe support in
> > > v7.0-rc?
> > >
> >
> > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> >
>
> In line with Bjorn's request, we shouldn't have to guess.
>
> > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > fixing that change, or is it only applicable once some other changes are
> > > applied?
> > >
> >
> > This change is fixing the issue in the respective board DTS and is a standalone
> > fix on top of v7.0-rc1.
> >
>
> So 960609b22be5 was broken when I merged it?
>
Broken on the machines mentioned in the commit message, not for all Hamoa
platforms.
> The commit message says that the commit was incomplete, in that it
> didn't fully convert from the old to the new style, so it sounds like
> the offending commit was incomplete - but I believe the offending commit
> was a workaround for the new solution not being in place and this commit
> mostly reverts the changes in the offending commit.
>
So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
new for greater good, but it apparently decided to do so only for a subset of
the platforms for some reason which don't know. But the problem arises due to
960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
platform DTS to also be changed to the new binding. If we only have either dtsi
or dts converted and not both to the new binding, the driver will get confused
and fail. And this is what exactly happended for below machines:
- x1-hp-omnibook-x14
- x1-microsoft-denali
- x1e80100-lenovo-yoga-slim7x
- x1e80100-medion-sprchrgd-14-s1
- x1p42100-lenovo-thinkbook-16
- x1-asus-zenbook-a14
- x1-crd
- x1-dell-thena
> In other words, it's not clear to me, from the commit message, why this
> change is a -rc fix. Perhaps the author of the offending commit tricked
> me to merge that one, and that's what's being fixed?
>
I wouldn't say that the author has tricked, but he was unaware of the fact that
changing SoC dtsi warrants change in all platforms, not a subset. I wanted to
catch these kind of issues with DT binding validation, so I sent out a series
earlier [1], but it got stuck. I'll push it forward.
[1] https://lore.kernel.org/linux-pci/20251106-pci-binding-v2-0-bebe9345fc4b@oss.qualcomm.com
> Also, is the lack of Tested-by telling us that nobody has tested any of
> the v7.0-rc on the 8 listed Hamoa devices?
>
Exactly. Otherwise, they would've seen the failure so obviously.
>
>
> If it's actually needed, can we please have the commit message improved
> so that we can merge it into -rc?
>
Sure. I'll work with Ziyue to reword it properly.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Manivannan Sadhasivam @ 2026-03-19 5:28 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Ziyue Zhang, andersson, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-phy, qiang.yu,
quic_krichai, quic_vbadigan
In-Reply-To: <20260317171319.GA90412@bhelgaas>
On Tue, Mar 17, 2026 at 12:13:19PM -0500, Bjorn Helgaas wrote:
> On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > Wake GPIOs in the PCIe root port nodes.
> > > >
> > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > to the port nodes.
> > > >
> > > > This fixes probe failures seen on the following platforms:
> > > > - x1-hp-omnibook-x14
> > > > - x1-microsoft-denali
> > > > - x1e80100-lenovo-yoga-slim7x
> > > > - x1e80100-medion-sprchrgd-14-s1
> > > > - x1p42100-lenovo-thinkbook-16
> > > > - x1-asus-zenbook-a14
> > > > - x1-crd
> > > > - x1-dell-thena
> > > >
> > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > >
> > > Are you saying that DTs in the field broke because of some kernel
> > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > the old style with them described in the Root Complex node.
> >
> > This is not related to the driver change. The driver correctly
> > parses all Root Port properties either in the Root Complex node (old
> > binding) or Root Port node (new binding). But commit 960609b22be5,
> > left converting mentioned board DTS to the new binding, leaving
> > those affected platforms in a half baked state i.e., some properties
> > in RC node and some in Root Port node. Driver cannot parse such
> > combinations, so it fails correctly so.
>
> The commit log mentions probe failures on some machines. I'd like it
> to be more clear about who is affected and what they need to do to fix
> their machines.
There is already a list of affected machines mentioned in the commit message.
And for fix, they just need to apply this patch. Or once this patch gets merged
into v7.0-rcS, v7.0 will have no issue.
> If it only affects developers who generated DTs based
> on 960609b22be5 for internal testing, we should say that so it's clear
> that no end users will see any regressions or boot failures.
>
Whoever have included commit 960609b22be5 in their kernel and using the above
mentioned machines will see the failure. But looks like no one really tested
v7.0-rcS on these machines as we haven't gotten any reports so far.
> Is there some way to verify that after this patch, none of the
> generated DTBs are in this half-baked situation? Some kind of
> automated DTB checker?
I sent out a DT binding series [1] that was supposed to catch these issues
during DTB validation phase, but unfortunately it got stuck in the review. I'll
try to stir things up.
- Mani
[1] https://lore.kernel.org/linux-pci/20251106-pci-binding-v2-0-bebe9345fc4b@oss.qualcomm.com
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v6 4/4] phy: qualcomm: add MSM8974 HDMI PHY support
From: Dmitry Baryshkov @ 2026-03-19 3:48 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260319-fd-hdmi-phy-v6-0-cefc08a55470@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 299 ++++++++++++++++++++++++++++-
1 file changed, 290 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
index db7fa2df1a36..f48f81403de5 100644
--- a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
+++ b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
@@ -6,10 +6,12 @@
* Author: Rob Clark <robdclark@gmail.com>
*/
+#include <linux/bitfield.h>
#include <linux/delay.h>
#include <linux/iopoll.h>
#include "phy-qcom-hdmi-preqmp.h"
+#include "phy-qcom-uniphy.h"
#define REG_HDMI_8x74_ANA_CFG0 0x00000000
#define REG_HDMI_8x74_ANA_CFG1 0x00000004
@@ -31,23 +33,301 @@
#define REG_HDMI_8x74_BIST_PATN3 0x00000048
#define REG_HDMI_8x74_STATUS 0x0000005c
+#define HDMI_8974_VCO_MAX_FREQ 1800000000UL
+#define HDMI_8974_VCO_MIN_FREQ 600000000UL
+
+#define HDMI_8974_COMMON_DIV 5
+
+static inline void write16(u16 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel(val >> 8, reg + 4);
+}
+
+static inline void write24(u32 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel((val >> 8) & 0xff, reg + 4);
+ writel(val >> 16, reg + 8);
+}
+
+static inline u32 read24(void __iomem *reg)
+{
+ u32 val = readl(reg);
+
+ val |= readl(reg + 4) << 8;
+ val |= readl(reg + 8) << 16;
+
+ return val;
+}
+
+static void qcom_uniphy_setup(void __iomem *base, unsigned int ref_freq,
+ bool sdm_mode,
+ bool ref_freq_mult_2,
+ bool dither,
+ unsigned int refclk_div,
+ unsigned int vco_freq)
+{
+ unsigned int int_ref_freq = ref_freq * (ref_freq_mult_2 ? 2 : 1);
+ unsigned int div_in_freq = vco_freq / refclk_div;
+ unsigned int dc_offset = div_in_freq / int_ref_freq - 1;
+ unsigned int sdm_freq_seed;
+ unsigned int val;
+ unsigned int remain = div_in_freq - (dc_offset + 1) * int_ref_freq;
+
+ sdm_freq_seed = mult_frac(remain, 0x10000, int_ref_freq);
+
+ val = FIELD_PREP(UNIPHY_PLL_REFCLK_DBLR, ref_freq_mult_2) |
+ FIELD_PREP(UNIPHY_PLL_REFCLK_DIV, refclk_div - 1);
+ writel(val, base + UNIPHY_PLL_REFCLK_CFG);
+
+ if (sdm_mode) {
+ writel(0, base + UNIPHY_PLL_SDM_CFG0);
+ writel(FIELD_PREP(UNIPHY_PLL_SDM_DITHER_EN, dither) | dc_offset,
+ base + UNIPHY_PLL_SDM_CFG1);
+ write24(sdm_freq_seed, base + UNIPHY_PLL_SDM_CFG2);
+ } else {
+ writel(UNIPHY_PLL_SDM_BYP | dc_offset, base + UNIPHY_PLL_SDM_CFG0);
+ writel(0, base + UNIPHY_PLL_SDM_CFG1);
+ write24(0, base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ write16(mult_frac(ref_freq, 5, 1000), base + UNIPHY_PLL_CAL_CFG8);
+ write16(vco_freq / 16, base + UNIPHY_PLL_CAL_CFG10);
+}
+
+static unsigned long qcom_uniphy_recalc(void __iomem *base, unsigned long parent_rate)
+{
+ unsigned long rate;
+ u32 refclk_cfg;
+ u32 dc_offset;
+ u64 fraq_n;
+ u32 val;
+
+ refclk_cfg = readl(base + UNIPHY_PLL_REFCLK_CFG);
+ if (refclk_cfg & UNIPHY_PLL_REFCLK_DBLR)
+ parent_rate *= 2;
+
+ val = readl(base + UNIPHY_PLL_SDM_CFG0);
+ if (FIELD_GET(UNIPHY_PLL_SDM_BYP, val)) {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_BYP_DIV, val);
+ fraq_n = 0;
+ } else {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_DC_OFFSET,
+ readl(base + UNIPHY_PLL_SDM_CFG1));
+ fraq_n = read24(base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ rate = (dc_offset + 1) * parent_rate;
+ rate += mult_frac(fraq_n, parent_rate, 0x10000);
+
+ rate *= FIELD_GET(UNIPHY_PLL_REFCLK_DIV, refclk_cfg) + 1;
+
+ return rate;
+}
+
+static const unsigned int qcom_hdmi_8974_divs[] = {1, 2, 4, 6};
+
+static unsigned long qcom_hdmi_8974_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct qcom_hdmi_preqmp_phy *hdmi_phy = hw_clk_to_phy(hw);
+ u32 div_idx = readl(hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+ unsigned long rate = qcom_uniphy_recalc(hdmi_phy->pll_reg, parent_rate);
+
+ return rate / HDMI_8974_COMMON_DIV / qcom_hdmi_8974_divs[div_idx & 0x3];
+}
+
+static int qcom_hdmi_8974_pll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ unsigned long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ unsigned long max_freq = HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV;
+
+ req->rate = clamp(req->rate, min_freq / 6, max_freq);
+
+ return 0;
+}
+
+static const struct clk_ops qcom_hdmi_8974_pll_ops = {
+ .recalc_rate = qcom_hdmi_8974_pll_recalc_rate,
+ .determine_rate = qcom_hdmi_8974_pll_determine_rate,
+};
+
+static int qcom_hdmi_msm8974_phy_find_div(unsigned long long pixclk)
+{
+ unsigned long long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ int i;
+
+ if (pixclk > HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(qcom_hdmi_8974_divs); i++) {
+ if (pixclk >= min_freq / qcom_hdmi_8974_divs[i])
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_set_rate(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ unsigned long long pixclk = hdmi_phy->hdmi_opts.tmds_char_rate;
+ unsigned long vco_rate;
+ unsigned int div;
+ int div_idx = 0;
+
+ div_idx = qcom_hdmi_msm8974_phy_find_div(pixclk);
+ if (WARN_ON(div_idx < 0))
+ return div_idx;
+
+ div = qcom_hdmi_8974_divs[div_idx];
+ vco_rate = pixclk * HDMI_8974_COMMON_DIV * div;
+
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ writel(0x19, hdmi_phy->pll_reg + UNIPHY_PLL_VCOLPF_CFG);
+ writel(0x0e, hdmi_phy->pll_reg + UNIPHY_PLL_LPFR_CFG);
+ writel(0x20, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC1_CFG);
+ writel(0x0d, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC2_CFG);
+
+ qcom_uniphy_setup(hdmi_phy->pll_reg, 19200000, true, true, true, 1, vco_rate);
+
+ writel(0x10, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG0);
+ writel(0x1a, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG1);
+ writel(0x05, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG2);
+
+ writel(div_idx,
+ hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV2_CFG);
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV3_CFG);
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_CAL_CFG2);
+
+ writel(0x1f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(50);
+
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL1);
+ writel(0x10, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0xdb, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
+ writel(0x43, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
+ if (pixclk == 297000) {
+ writel(0x06, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x03, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else if (pixclk == 268500) {
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else {
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ }
+
+ writel(0x04, hdmi_phy->pll_reg + UNIPHY_PLL_VREG_CFG);
+
+ writel(0xd0, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG0);
+ writel(0x1a, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG1);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG0);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG1);
+
+ if (pixclk == 268500)
+ writel(0x11, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+ else
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG3);
+ udelay(200);
+
+ return 0;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_enable(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ int ret;
+ unsigned long status;
+
+ /* Global enable */
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ /* Power up power gen */
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+
+ /* Power up PLL LDO */
+ writel(0x03, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* Poll for PLL ready status */
+ ret = readl_poll_timeout(hdmi_phy->pll_reg + UNIPHY_PLL_STATUS,
+ status, status & BIT(0),
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PLL not ready\n");
+ goto err;
+ }
+
+ udelay(350);
+
+ /* Poll for PHY ready status */
+ ret = readl_poll_timeout(hdmi_phy->phy_reg + REG_HDMI_8x74_STATUS,
+ status, status & BIT(0),
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PHY not ready\n");
+ goto err;
+ }
+
+ return 0;
+
+err:
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ return ret;
+}
+
static int qcom_hdmi_msm8974_phy_power_on(struct qcom_hdmi_preqmp_phy *hdmi_phy)
{
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_ANA_CFG0, 0x1b);
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_ANA_CFG1, 0xf2);
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_BIST_CFG0, 0x0);
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_BIST_PATN0, 0x0);
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_BIST_PATN1, 0x0);
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_BIST_PATN2, 0x0);
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_BIST_PATN3, 0x0);
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_PD_CTRL1, 0x20);
+ int ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_set_rate(hdmi_phy);
+ if (ret)
+ return ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_enable(hdmi_phy);
+ if (ret)
+ return ret;
+
+ writel(0x1b, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
+ writel(0xf2, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
+ writel(0x0, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_CFG0);
+ writel(0x0, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_PATN0);
+ writel(0x0, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_PATN1);
+ writel(0x0, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_PATN2);
+ writel(0x0, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_PATN3);
+ writel(0x20, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL1);
return 0;
}
static int qcom_hdmi_msm8974_phy_power_off(struct qcom_hdmi_preqmp_phy *hdmi_phy)
{
- hdmi_phy_write(hdmi_phy, REG_HDMI_8x74_PD_CTRL0, 0x7f);
+ writel(0x7f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
return 0;
}
@@ -67,5 +347,6 @@ const struct qcom_hdmi_preqmp_cfg msm8974_hdmi_phy_cfg = {
.power_on = qcom_hdmi_msm8974_phy_power_on,
.power_off = qcom_hdmi_msm8974_phy_power_off,
+ .pll_ops = &qcom_hdmi_8974_pll_ops,
.pll_parent = &msm8974_hdmi_pll_parent,
};
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 3/4] phy: qcom-uniphy: add more registers from display PHYs
From: Dmitry Baryshkov @ 2026-03-19 3:48 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260319-fd-hdmi-phy-v6-0-cefc08a55470@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Import register definitions from 28nm DSI and HDMI PHYs, adding more UNI
PHY registers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-uniphy.h | 42 ++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
index e5b79a4dc270..ba9d14aae682 100644
--- a/drivers/phy/qualcomm/phy-qcom-uniphy.h
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -8,10 +8,30 @@
/* PHY registers */
#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_REFCLK_DBLR BIT(0)
+#define UNIPHY_PLL_REFCLK_DIV GENMASK(3, 2)
+
+#define UNIPHY_PLL_POSTDIV1_CFG 0x004
+#define UNIPHY_PLL_CHGPUMP_CFG 0x008
+#define UNIPHY_PLL_VCOLPF_CFG 0x00c
+#define UNIPHY_PLL_VREG_CFG 0x010
#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_DMUX_CFG 0x018
+#define UNIPHY_PLL_AMUX_CFG 0x01c
#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_POSTDIV2_CFG 0x024
+#define UNIPHY_PLL_POSTDIV3_CFG 0x028
+#define UNIPHY_PLL_LPFR_CFG 0x02c
+#define UNIPHY_PLL_LPFC1_CFG 0x030
+#define UNIPHY_PLL_LPFC2_CFG 0x034
#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_BYP BIT(6)
+#define UNIPHY_PLL_SDM_BYP_DIV GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_DITHER_EN BIT(6)
+#define UNIPHY_PLL_SDM_DC_OFFSET GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG2 0x040
#define UNIPHY_PLL_SDM_CFG3 0x044
#define UNIPHY_PLL_SDM_CFG4 0x048
@@ -22,11 +42,33 @@
#define UNIPHY_PLL_LKDET_CFG0 0x05c
#define UNIPHY_PLL_LKDET_CFG1 0x060
#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_TEST_CFG 0x068
#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG1 0x070
+#define UNIPHY_PLL_CAL_CFG2 0x074
+#define UNIPHY_PLL_CAL_CFG3 0x078
+#define UNIPHY_PLL_CAL_CFG4 0x07c
+#define UNIPHY_PLL_CAL_CFG5 0x080
+#define UNIPHY_PLL_CAL_CFG6 0x084
+#define UNIPHY_PLL_CAL_CFG7 0x088
#define UNIPHY_PLL_CAL_CFG8 0x08c
#define UNIPHY_PLL_CAL_CFG9 0x090
#define UNIPHY_PLL_CAL_CFG10 0x094
#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_EFUSE_CFG 0x09c
+#define UNIPHY_PLL_DEBUG_BUS_SEL 0x0a0
+#define UNIPHY_PLL_CTRL_42 0x0a4
+#define UNIPHY_PLL_CTRL_43 0x0a8
+#define UNIPHY_PLL_CTRL_44 0x0ac
+#define UNIPHY_PLL_CTRL_45 0x0b0
+#define UNIPHY_PLL_CTRL_46 0x0b4
+#define UNIPHY_PLL_CTRL_47 0x0b8
+#define UNIPHY_PLL_CTRL_48 0x0bc
#define UNIPHY_PLL_STATUS 0x0c0
+#define UNIPHY_PLL_DEBUG_BUS0 0x0c4
+#define UNIPHY_PLL_DEBUG_BUS1 0x0c8
+#define UNIPHY_PLL_DEBUG_BUS2 0x0cc
+#define UNIPHY_PLL_DEBUG_BUS3 0x0d0
+#define UNIPHY_PLL_CTRL_54 0x0d4
#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 2/4] phy: qcom: apq8064-sata: extract UNI PLL register defines
From: Dmitry Baryshkov @ 2026-03-19 3:48 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260319-fd-hdmi-phy-v6-0-cefc08a55470@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
The "uni" PLL is shared between several PHYS: APQ8064's SATA,
MSM8974/APQ8084 HDMI, MSM8916 DSI, MSM8974/APQ8084 DSI. Extract the
common register names to a separate header with the hope of later having
the common code to handle PLL in those PHYs.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +-------------------
drivers/phy/qualcomm/phy-qcom-uniphy.h | 32 ++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
index cae290a6e19f..dd9929429f9a 100644
--- a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
+++ b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
@@ -15,28 +15,7 @@
#include <linux/platform_device.h>
#include <linux/phy/phy.h>
-/* PHY registers */
-#define UNIPHY_PLL_REFCLK_CFG 0x000
-#define UNIPHY_PLL_PWRGEN_CFG 0x014
-#define UNIPHY_PLL_GLB_CFG 0x020
-#define UNIPHY_PLL_SDM_CFG0 0x038
-#define UNIPHY_PLL_SDM_CFG1 0x03C
-#define UNIPHY_PLL_SDM_CFG2 0x040
-#define UNIPHY_PLL_SDM_CFG3 0x044
-#define UNIPHY_PLL_SDM_CFG4 0x048
-#define UNIPHY_PLL_SSC_CFG0 0x04C
-#define UNIPHY_PLL_SSC_CFG1 0x050
-#define UNIPHY_PLL_SSC_CFG2 0x054
-#define UNIPHY_PLL_SSC_CFG3 0x058
-#define UNIPHY_PLL_LKDET_CFG0 0x05C
-#define UNIPHY_PLL_LKDET_CFG1 0x060
-#define UNIPHY_PLL_LKDET_CFG2 0x064
-#define UNIPHY_PLL_CAL_CFG0 0x06C
-#define UNIPHY_PLL_CAL_CFG8 0x08C
-#define UNIPHY_PLL_CAL_CFG9 0x090
-#define UNIPHY_PLL_CAL_CFG10 0x094
-#define UNIPHY_PLL_CAL_CFG11 0x098
-#define UNIPHY_PLL_STATUS 0x0C0
+#include "phy-qcom-uniphy.h"
#define SATA_PHY_SER_CTRL 0x100
#define SATA_PHY_TX_DRIV_CTRL0 0x104
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
new file mode 100644
index 000000000000..e5b79a4dc270
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef PHY_QCOM_UNIPHY_H
+#define PHY_QCOM_UNIPHY_H
+
+/* PHY registers */
+#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_CFG2 0x040
+#define UNIPHY_PLL_SDM_CFG3 0x044
+#define UNIPHY_PLL_SDM_CFG4 0x048
+#define UNIPHY_PLL_SSC_CFG0 0x04c
+#define UNIPHY_PLL_SSC_CFG1 0x050
+#define UNIPHY_PLL_SSC_CFG2 0x054
+#define UNIPHY_PLL_SSC_CFG3 0x058
+#define UNIPHY_PLL_LKDET_CFG0 0x05c
+#define UNIPHY_PLL_LKDET_CFG1 0x060
+#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG8 0x08c
+#define UNIPHY_PLL_CAL_CFG9 0x090
+#define UNIPHY_PLL_CAL_CFG10 0x094
+#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_STATUS 0x0c0
+
+#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 0/4] drm/msm/hdmi & phy: use generic PHY framework
From: Dmitry Baryshkov @ 2026-03-19 3:48 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov, Konrad Dybcio
The MSM HDMI PHYs have been using the ad-hoc approach / API instead of
using the generic API framework. Move MSM HDMI PHY drivers to
drivers/phy/qualcomm and rework them to use generic PHY framework. This
way all the QMP-related code is kept at the same place.
Also MSM8974 HDMI PHY, 28nm DSI PHY and apq8964 SATA PHY now can use
common helpers for the UNI PLL.
This also causes some design changes. Currently on MSM8996 the HDMI PLL
implements clock's set_rate(), while other HDMI PHY drivers used the
ad-hoc PHY API for setting the PLL rate (this includes in-tree MSM8960
driver and posted, but not merged, MSM8974 driver). This might result in
the PLL being set to one rate, while the rest of the PHY being tuned to
work at another rate. Adopt the latter idea and always use
phy_configure() to tune the PHY and set the PLL rate.
Merge strategy: cross-tree merge via the immutable tag.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Changes in v6:
- Changed MSM8974 HDMI PHY driver to use FIELD_PREP / FIELD_GET (Konrad)
- Fixed rate recalculation for MSM8974 HDMI PHY (Konrad)
- Dropped register read/write wrappers
- Link to v5: https://lore.kernel.org/r/20260314-fd-hdmi-phy-v5-0-58122ae96d3b@oss.qualcomm.com
Changes in v5:
- Kept only a single place which handles extp clk (after PHY power on,
before PHY power off) (Neil)
- Inlined pm_runtime calls in the HDMI TX driver, replaced
pm_runtime_resume_and_get() with pm_runtime_get_sync(), since
atomic_pre_enable() can not fail.
- Renamed registers defines to drop the REG_ prefix.
- Link to v4: https://lore.kernel.org/r/20250520-fd-hdmi-phy-v4-0-fcbaa652ad75@oss.qualcomm.com
Changes in v3-v4:
- Rebased on top of linux-next, solving conflicts
- Squashed add-and-remove patches into a single git mv patch
- Dropped HDMI PHY header patch (merged upstream)
Changes in v2:
- Changed msm8960 / apq8064 to calculate register data instead of using
fixed tables. This extends the list of supported modes.
(Implementation is based on mdss-hdmi-pll-28lpm.c from msm-4.14).
- Fixed the reprogramming of PLL rate on apq8064.
- Merged all non-QMP HDMI PHY drivers into a common PHY_QCOM_HDMI
driver (suggested by Rob Clark)
---
Dmitry Baryshkov (4):
drm/msm/hdmi: switch to generic PHY subsystem
phy: qcom: apq8064-sata: extract UNI PLL register defines
phy: qcom-uniphy: add more registers from display PHYs
phy: qualcomm: add MSM8974 HDMI PHY support
drivers/gpu/drm/msm/Makefile | 7 -
drivers/gpu/drm/msm/hdmi/hdmi.c | 58 +-
drivers/gpu/drm/msm/hdmi/hdmi.h | 80 +--
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 80 ++-
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 225 -------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 51 --
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 761 ----------------------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c | 765 -----------------------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 141 -----
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 44 --
drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c | 460 --------------
drivers/gpu/drm/msm/registers/display/hdmi.xml | 537 ----------------
drivers/phy/qualcomm/Kconfig | 24 +
drivers/phy/qualcomm/Makefile | 14 +
drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +-
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 352 +++++++++++
drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c | 462 ++++++++++++++
drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c | 186 ++++++
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 212 +++++++
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 59 ++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c | 185 ++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c | 443 +++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8998.c | 496 +++++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h | 77 +++
drivers/phy/qualcomm/phy-qcom-uniphy.h | 74 +++
25 files changed, 2628 insertions(+), 3188 deletions(-)
---
base-commit: 95bcfacccdad8a76e02a8eaa92baaf09c879877e
change-id: 20240109-fd-hdmi-phy-44b8319fbcc7
Best regards,
--
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 v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Bjorn Andersson @ 2026-03-19 2:42 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Ziyue Zhang, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-phy, qiang.yu,
quic_krichai, quic_vbadigan
In-Reply-To: <kqpgjzcxnazjohiop27exget6qrv37wn3csmixt5nmc6d5dkbg@n7qjo6flaabn>
On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > Wake GPIOs in the PCIe root port nodes.
> > > > >
> > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > to the port nodes.
> > > > >
> > > > > This fixes probe failures seen on the following platforms:
> > > > > - x1-hp-omnibook-x14
> > > > > - x1-microsoft-denali
> > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > - x1p42100-lenovo-thinkbook-16
> > > > > - x1-asus-zenbook-a14
> > > > > - x1-crd
> > > > > - x1-dell-thena
> > > > >
> > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > >
> > > > Are you saying that DTs in the field broke because of some kernel
> > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > the old style with them described in the Root Complex node.
> > > >
> > >
> > > This is not related to the driver change. The driver correctly parses all Root
> > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > combinations, so it fails correctly so.
> > >
> >
> > Are you saying that above listed machines has broken PCIe support in
> > v7.0-rc?
> >
>
> I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
>
In line with Bjorn's request, we shouldn't have to guess.
> > It seems this is a (partial) revert of 960609b22be5, is this actually
> > fixing that change, or is it only applicable once some other changes are
> > applied?
> >
>
> This change is fixing the issue in the respective board DTS and is a standalone
> fix on top of v7.0-rc1.
>
So 960609b22be5 was broken when I merged it?
The commit message says that the commit was incomplete, in that it
didn't fully convert from the old to the new style, so it sounds like
the offending commit was incomplete - but I believe the offending commit
was a workaround for the new solution not being in place and this commit
mostly reverts the changes in the offending commit.
In other words, it's not clear to me, from the commit message, why this
change is a -rc fix. Perhaps the author of the offending commit tricked
me to merge that one, and that's what's being fixed?
Also, is the lack of Tested-by telling us that nobody has tested any of
the v7.0-rc on the 8 listed Hamoa devices?
If it's actually needed, can we please have the commit message improved
so that we can merge it into -rc?
Regards,
Bjorn
> > Where should this be merged?
> >
>
> Qcom tree for 7.0-rcX.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Conor Dooley @ 2026-03-18 17:35 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <1382fed198246f1563dea091478757aebc4e4948.1773751309.git.nora.schiffer@ew.tq-group.com>
[-- Attachment #1.1: Type: text/plain, Size: 1294 bytes --]
On Wed, Mar 18, 2026 at 03:05:25PM +0100, Nora Schiffer wrote:
> The J722S CPSW3G is mostly identical to the AM64's, but additionally
> supports SGMII.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> index a959c1d7e643a..9ab8237c7f79e 100644
> --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> @@ -59,6 +59,7 @@ properties:
> - ti,j7200-cpswxg-nuss
> - ti,j721e-cpsw-nuss
> - ti,j721e-cpswxg-nuss
> + - ti,j722s-cpsw-nuss
For all these bindings, why is a fallback not suitable? Seems like it'd
be possible here, since there's just a new feature. Is there some other
programming model difference?
> - ti,j784s4-cpswxg-nuss
>
> reg:
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> https://www.tq-group.com/
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 4/4] phy: qualcomm: add MSM8974 HDMI PHY support
From: Dmitry Baryshkov @ 2026-03-18 17:15 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong, linux-kernel, linux-arm-msm,
dri-devel, freedreno, linux-phy, Dmitry Baryshkov
In-Reply-To: <5a464fca-7be5-44a6-b124-7b80ea859a9e@oss.qualcomm.com>
On Wed, Mar 18, 2026 at 10:22:08AM +0100, Konrad Dybcio wrote:
> On 3/14/26 6:06 AM, Dmitry Baryshkov wrote:
> > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >
> > Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
>
> [...]
>
> > + sdm_freq_seed = mult_frac(remain, 0x10000, int_ref_freq);
> > +
> > + val = (ref_freq_mult_2 ? BIT(0) : 0) |
> > + ((refclk_div - 1) << 2);
> > + writel(val, base + UNIPHY_PLL_REFCLK_CFG);
> > +
> > + writel(sdm_mode ? 0 : 0x40 + dc_offset, base + UNIPHY_PLL_SDM_CFG0);
> > +
> > + writel(dither ? 0x40 + dc_offset : 0, base + UNIPHY_PLL_SDM_CFG1);
> > +
> > + writel(sdm_freq_seed & 0xff, base + UNIPHY_PLL_SDM_CFG2);
>
> Some beautification (BIT(), FIELD_..(), defined magic values) would be
> really nice to see.. although I'm not sure how much you can do with the
> PLL registers..
I can try doing a bit of it, but not that much. The HDMI PHY is mostly
unspecified for that platform. The code here is mostly based on the
study of the existing values in downstream and corresponding DSI PHY
(which uses the same UNIPHY core).
>
> [...]
>
> > + ref_freq = ref_freq * 5 / 1000;
>
> mult_frac()
ack
>
> [...]
>
> > + rate = (dc_offset + 1) * parent_rate;
> > + rate += mult_frac(fraq_n, parent_rate, 0x10000);
> > +
> > + rate *= (refclk_cfg >> 2) * 0x3 + 1;
>
> Really strange calculation, but in the end this is (n * 0.75)+1 -
> mult_frac()?
It might be based on some other dividers which I didn't recognize.
Anyway, yes, mult_frac() would work.
>
> > +
> > + return rate;
> > +}
> > +
> > +static const unsigned int qcom_hdmi_8974_divs[] = {1, 2, 4, 6};
> > +
> > +static unsigned long qcom_hdmi_8974_pll_recalc_rate(struct clk_hw *hw,
> > + unsigned long parent_rate)
> > +{
> > + struct qcom_hdmi_preqmp_phy *hdmi_phy = hw_clk_to_phy(hw);
> > + u32 div_idx = hdmi_pll_read(hdmi_phy, UNIPHY_PLL_POSTDIV1_CFG);
> > + unsigned long rate = qcom_uniphy_recalc(hdmi_phy->pll_reg, parent_rate);
> > +
> > + return rate / HDMI_8974_COMMON_DIV / qcom_hdmi_8974_divs[div_idx & 0x3];
>
> nit: double space
>
>
> > +}
> > +
> > +static int qcom_hdmi_8974_pll_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > +{
> > + req->rate = clamp(req->rate,
> > + HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV / 6,
> > + HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV / 1);
>
> I don't know if it's a good direction, but maybe:
>
> const unsigned long max_rate = HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV;
>
> clamp(req->rate, max_rate / 6, max_rate)
Note, it is clamp (min_rate / 6, max_rate)
>
> ?
>
> [...]
>
> > +static int qcom_hdmi_msm8974_phy_find_div(unsigned long long pixclk)
> > +{
> > + int i;
> > + unsigned long long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
>
> reverse-Christmas-tree?
>
> > +
> > + if (pixclk > HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV)
> > + return -E2BIG;
>
> include/uapi/asm-generic/errno-base.h
> 11:#define E2BIG 7 /* Argument list too long */
>
> -EINVAL?
Ok
>
> Konrad
--
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