[PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R

[Marek Vasut]

On 1/29/20 5:51 PM, Patrick DELAUNAY wrote:
> Hi Marek,

Hi,

>> From: Marek Vasut <marex at denx.de>
>> Sent: mardi 28 janvier 2020 13:16
>>
>> On 1/28/20 10:11 AM, Patrick Delaunay wrote:
>>> From: Antonio Borneo <antonio.borneo at st.com>
>>>
>>> LTDC modifies the clock frequency to adapt it to the display. Such
>>> frequency change is not detected by the FDCAN driver that instead
>>> cache the value at probe and pretend to use it later.
>>>
>>> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
>>
>> Now this looks like a grisly workaround. Can you fix the LTDC driver to do
>> something sane on boards which didn't update bootloader yet ?
> 
> In fact it more a issue in the initial clock-tree used when I upstream the ST board the first time... based on our delivery v1.0.0
> 
> It is already corrected in downstream on v1.1.0:
> + For U-Boot = https://github.com/STMicroelectronics/u-boot/commit/d62f14dece32e41c2854b9ff44aca7b8384aa8a0
> + For TF-A = https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a24ceda6c3ba060d9acf2b26d069fedde9f0807
> 
> The LTDC/DSI need to set the pixel clock according the panel configuration and settings: it is normal and needed.
> 
> But If the pixel clock is shared with FDCAN, which expects that its input clock is fixed, an issue occur when the pixel clock change.

I understand the problem you are trying to solve.

What I think you are missing is that not everyone will update
ATF/U-Boot/Linux in lockstep. That is the problem you need to deal with
here.