On 1/29/20 5:51 PM, Patrick DELAUNAY wrote: > Hi Marek, Hi,
>> From: Marek Vasut <ma...@denx.de> >> Sent: mardi 28 janvier 2020 13:16 >> >> On 1/28/20 10:11 AM, Patrick Delaunay wrote: >>> From: Antonio Borneo <antonio.bor...@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.
