On 1/29/20 5:51 PM, Patrick DELAUNAY wrote:
Hi Marek,
Hi,
From: Marek Vasut marex@denx.de Sent: mardi 28 janvier 2020 13:16
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
From: Antonio Borneo antonio.borneo@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/d62f14dece32e41c2854b9ff...
- For TF-A = https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a24ceda6c...
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.