U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Johannes (krjdev) Krottmayer" <krjdev@gmail.com>
To: Patrick DELAUNAY <patrick.delaunay@foss.st.com>,
	u-boot@lists.denx.de, dillon.minfei@gmail.com,
	patrice.chotard@foss.st.com
Subject: Re: drivers: clk: stm32h7: Endless loop of dead in driver probe function
Date: Wed, 9 Mar 2022 08:24:59 +0100	[thread overview]
Message-ID: <6bab2e77-3827-dbc0-8592-39da1a51d187@gmail.com> (raw)
In-Reply-To: <5affc0c0-f2e8-5dd7-54b1-cb7f30168ed5@foss.st.com>

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:

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. :)

Kind regards,

Johannes

  reply	other threads:[~2022-03-09  7:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02 17:00 drivers: clk: stm32h7: Endless loop of dead in driver probe function Johannes (krjdev) Krottmayer
2022-03-08  9:00 ` Patrick DELAUNAY
2022-03-09  7:24   ` Johannes (krjdev) Krottmayer [this message]
2022-03-09  7:43     ` Patrice CHOTARD
2022-03-09  8:02       ` Johannes (krjdev) Krottmayer
2022-03-09  8:08         ` Patrice CHOTARD
2022-03-09 11:38           ` Johannes (krjdev) Krottmayer
2022-03-10  8:04             ` Patrice CHOTARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6bab2e77-3827-dbc0-8592-39da1a51d187@gmail.com \
    --to=krjdev@gmail.com \
    --cc=dillon.minfei@gmail.com \
    --cc=patrice.chotard@foss.st.com \
    --cc=patrick.delaunay@foss.st.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox