On 7/11/25 15:57, Bryan O'Donoghue wrote:
v7:
- Reimagine the PHYs as individual nodes.
A v1 of the schmea and driver for the CSI PHY has been published with
some review feedback from Rob Herring and Konrad Dybcio
https://lore.kernel.org/r/20250710-x1e-csi2-phy-v1-0-74acbb5b162b@xxxxxxxxxx
Both the clock name changes from Rob and OPP changes suggested by Konrad
are _not_ yet present in this submission however stipulating to those
changes, I think publishing this v7 of the CAMSS/DT changes is warranted.
Its important to publish a whole view of changes for reviewers without
necessarily munging everything together in one sprawling series.
TL;DR I moved the PHY driver to its own series review comments there
are not reflected here yet but "shouldn't" have a big impact here.
- Having separate nodes in the DT for the PHYS allows for switching on PHYs
as we do for just about every other PHYs.
&csiphyX {
status = "okay";
};
We just list phys = <> in the core dtsi and enable the PHYs we want in
the platform dts.
- The level of code change in CAMSS itself turns out to be quite small.
Adding the PHY structure to the CSIPHY device
Differentiating the existing camss.c -> camss-csiphy.c init functions
A few new function pointers to facilitate parallel support of legacy
and new PHY interfaces.
- A key goal of this updated series is both to introduce a new PHY method
to CAMSS but to do it _only_ for a new SoC while taking care to ensure
that legacy CAMSS-PHY and legacy DT ABI continues to work.
This is a key point coming from the DT people which I've slowly imbibed
and hopefully succeeded in implementing.
- In addition to the CRD both T14s and Slim7x are supported.
I have the Inspirion14 working and the XPS but since we haven't landed
the Inspirion upstream yet, I've chosen to hold off on the XPS too.
- There is another proposal on the list to make PHY devices as sub-devices
I believe having those separate like most of our other PHYs
is the more appropriate way to go.
Similarly there is less code change to the CAMSS driver with this change.
Finally I believe we should contine to have endpoints go from the sensor
to CAMSS not the PHY as CAMSS' CSI decoder is the consumer of the data
not the PHY.
1. This is an incorrect assumption, unfortunately it was not discussed
previously for whatever reason, good news now it gets a discussion under
drivers/phy changeset.
2. The whole new changes for legacy/new CSIPHY support is not present
in v1-v6 of this changeset, it just appears out of nowhere in the v7,
and since it is broken it should be removed from v8 expectedly.
It's a pity to realize that instead of providing any review comments
for the CSIPHY support series sent to you one month ago a lot of time
is wastefully burnt on a broken by design change development.
--
Best wishes,
Vladimir
