On Mon 30 Aug 09:25 CDT 2021, Marijn Suijten wrote:

On Mon, Aug 30, 2021 at 05:18:37PM +0300, Dmitry Baryshkov wrote:

quoted

On Mon, 30 Aug 2021 at 17:14, Marijn Suijten
[off-list ref] wrote:

quoted

On Mon, Aug 30, 2021 at 04:24:58PM +0300, Dmitry Baryshkov wrote:

quoted

On Mon, 30 Aug 2021 at 11:28, Marijn Suijten
[off-list ref] wrote:

quoted

Hi Dmitry,

On 8/30/21 3:18 AM, Dmitry Baryshkov wrote:

quoted

On Sun, 29 Aug 2021 at 23:30, Marijn Suijten
[off-list ref] wrote:

quoted

The 28NM DSI PLL driver for msm8960 calculates with a 27MHz reference
clock and should hence use PXO, not CXO which runs at 19.2MHz.

Note that none of the DSI PHY/PLL drivers currently use this "ref"
clock; they all rely on (sometimes inexistant) global clock names and
usually function normally without a parent clock.  This discrepancy will
be corrected in a future patch, for which this change needs to be in
place first.

Cc: Dmitry Baryshkov <redacted>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>

Reviewed-by: Dmitry Baryshkov <redacted>

Checked the downstream driver, it always uses 27 MHz clock in calculations.

Given our concerns for msm8974 not updating DT in parallel with the
kernel (hence the need for a global-name fallback because "ref" is
missing from the DT), should we worry about the same for apq8064?  That
is, is there a chance that the kernel but not the firmware is upgraded
leading to the wrong parent clock being used?  The msm8960 variant of
the 28nm PLL driver uses parent_rate in a few places and might read
cxo's 19.2MHz erroneously instead of using pxo's 27MHz.

Checked the code. It uses .parent_names =  "pxo", so changing ref
clock should not matter. We'd need to fix ref clocks and after that we
can switch parent names to fw_name.

Correct, hence why this patch is ordered before the switch to .fw_name.
These patches can't go in the same series if apq8064 doesn't update its
firmware in parallel with the kernel just like msm8974.  Do you know if
this is the case?  If so, how much time do you think should be between
the DT fix (this patch) and migrating the drivers?

You can have parent_data with .fw_name and .name in it.  .name will be
used as a fallback if .fw_name doesn't match.

The problem is that it will always find the "ref" clock which references
&cxo_board until the DT is updated with this patch to use &pxo_board
instead.  Question is, will the kernel and DT usually/always be updated
in parallel?

Afaik these devices all boots off a boot.img, which means that it's
unlikely that a new kernel is installed on a device with an older DT.
None of them would boot mainline off the DT that shipped with the
original product.

As such, if I pick this patch up as a fix for 5.15 you can respin the
other two patches and they can land in 5.16 and I would be surprised if
anyone will run into any issues with it.


I.e. I've applied this patch.

Regards,
Bjorn