drivers: clk: stm32h7: Endless loop of dead in driver probe function

[Johannes (krjdev) Krottmayer]

Hi Patrice!

On 09.03.22 08:43, Patrice CHOTARD wrote:
> Hi johannes
> 
> On 3/9/22 08:24, Johannes (krjdev) Krottmayer wrote:
>> Hi Patrick!
>>
>> Sorry, for my late response. :(
>>
>> On 08.03.22 10:00, Patrick DELAUNAY wrote:> Yes, the current clock
>> driver for STM32 MCU is not perfect,> > as the all U-Boot and the
>> Linux support on STM32 MCU.>
>>>
>>> For information, in the other driver based on a other version of RCC for 
>>> STM32 MPU
>>>
>>> STM32MP1 = clk_stm32mp1.c, it is correctly managed in
>>>
>>> stm32mp1_osc_wait(1, rcc, RCC_OCRDYR, RCC_OCRDYR_HSERDY);
>>>
>>> by using readl_poll_timeout() function.
>>>
>>>
>>>> My possible fixes:
>>>> At a timeout when reading the register and if the timeout is
>>>> elapsed, print an error message and return with ETIMEDOUT, so
>>>> the dm manger can call the hang() function.
>>>
>>> I agree, it is a correct management: at least indicate this hardware issue
>>>
>>> even if the rdy bit can't be stay at 0 in normal use case when HSE is
>>>
>>> present.>
>>> => replace all while() in the RCC clock driver with readl_poll_timeout
>>>
>>>
>>> but to call readl_poll_timeout(), the arch timer need to ready
>>>
>>> (timer_init() already called) when RCC clokc driver probe is executed.
>>>
>>>
>>> An issue the I encounters on STM32MP need to be checked in MCU driver:
>>>
>>> the timer can't dependant of RCC probe when polling function is used.
>>>
>>>
>>> This issue was solved in STM32MP by using the generic armv7 timer
>>>
>>> (only dependant of Cortex core) and call the initialization in
>>>
>>> arch/arm/mach-stm32mp/cpu.c:
>>>
>>> int arch_cpu_init(void)
>>> {
>>> ....
>>>
>>>      /* early armv7 timer init: needed for polling */
>>>      timer_init();
>>>
>>>      return 0;
>>> }
>>
>> Is there any reason why not use the ARMv7-M SysTick Timer? There
>> exists an initialization routine in the U-Boot source tree:
> 
> Simply because when i introduced stm32h7 board, i didn't need it ;-)
> 
>>
>> arch/arm/cpu/armv4m/systick-timer.c
>>
>> The routines should work for Cortex-M3/M4/M7.
>>
>> timer_init() and all required functions for mdelay() which are will
>> be called by the polling functions are implemented.
>>
>> Don't looked into other TRM's, other than for STM32H745/STM32H747 and
>> STM32H755/STM32H757 yet, but according the TRM, the SysTick timer for
>> the core Cortex-M7 should run at 8MHz, after reset:
>>
>> - HSI should be selected as system clock (sys_ck), running at 64MHz
>> - Domain 1 prescaler (D1CPRE) with scale 1
>> - SysTick timer at default configuration (external source) which
>>   has a fixed prescale from 8, according the block schematic in
>>   TRM.
>>
>> Correct me please, if I'm wrong.
>>
>>> The timer management on MCU need to be check before any patch.
>>
>> Yes, but I can currently only test the correct behavior on a
>> STM32H747I-DISCO board. Currently creating the device-tree for
>> the SoC.
>>
>>> Can you propose something ?
>>
>> I would use the SysTick Timer on the other devices from the STM32H7
>> series too, so I would change the current code.
>>
>> Before I release a patch series here in the official mailing list,
>> I would suggest, if some other developers or users can verify my
>> modification on their real hardware.
>>
>> My GitHub repo:
>> https://github.com/krjdev/stm32_u-boot
>> (branch stm32h747_disco)
>>
>> That I can offer. :)
> 
> I have a stm21h7xxi-disco (MB1248) i can give it a try this week.
> I will keep you in touch.

Please can you give me some additional time for this? The device-tree
needs some fixes. Missing clocks and resets for the required driver.

I will create a git tag, when I'm ready and I have tested to run
U-Boot on my board. :)

Working since sunday on the device-trees...Maybe tommorrow. :)

> Thanks
> Patrice
> 
>>
>> Kind regards,
>>
>> Johannes

Kind regards

Johannes