From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 647FEC433F5 for ; Wed, 9 Mar 2022 07:25:11 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AAA4F8380F; Wed, 9 Mar 2022 08:25:08 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="kdUP9H+S"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2073D83829; Wed, 9 Mar 2022 08:25:06 +0100 (CET) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 99BB3837C7 for ; Wed, 9 Mar 2022 08:25:01 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=krjdev@gmail.com Received: by mail-ed1-x52b.google.com with SMTP id y12so1626056edc.13 for ; Tue, 08 Mar 2022 23:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=4x1bPhtsU3Vtre89cQnVa6bdpHS7lCbOmlbNt0Y4Y64=; b=kdUP9H+S0jB4HkE1cQl7VLgpDXUYWVmCWkmAd4p5QN2Oz2tMsa5XDg86gtpNHjmkv1 WbOKxUOIjlq/+zYwvPFStYA04VrkY/9Skf+XFzAnSRaZs+C9AS3X8kvj8g1WX8R2JZtw Mxir19393luKoyEsj20jZqo7bvGnKzLW9gwfkHRyoLYTUjCRF1GVKeF0wbQ2ffilpW19 TWzeU4xgg4JqrNbiuOUymvopYss+R6eXuJzdL/wiv7X0bZuXdKCk23HbCdKgZg3VK+QH WCmLkf5bWZqzpGR9A/qzqxBkq+jK1rLyNmihSjlz6oUcVbw/IY7XPURe6BQBQwABO788 E6WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=4x1bPhtsU3Vtre89cQnVa6bdpHS7lCbOmlbNt0Y4Y64=; b=36CBYLhySCBU/soXqwFexo2seKWgG1g8eL1+ENG2VQbiRCHS8TKcWZ9eyPh2CV0PXl GBA1dTN1eZU1aSZUpDfLLuWNE31oPyiUNLAcpxVjCAc+fPYOAEinCxCT5+23WvTTohIH SkbpjkOJ8GpfAg4EQIxZQuXKn5ksUrWuKsmr40mF7TR/Nh+7HPZYTxPG2N2aFBDg5qff XRESZOZVXlx0jtNtNKi/4Fm4m30Fe0kkHgDuKl0+yCcEg2tQmU92SmcmCzetAgUoE7xF tMGY5slk2laYUsiOwUM7PbrfoQNaLDeH0zzJmswo6wbA0fGmjkrjFQEYThIgXYXfDv9s jvgw== X-Gm-Message-State: AOAM5322F5AsEAlEsMMBPSQUqw5JVn/sYpvO9ubmPP/VK3bg7CmPLEMe axkjbf0krvliCY1VCY+NRGxIdEHRhII= X-Google-Smtp-Source: ABdhPJzOlQlmT9a4RZnuSzq/TiZVFFcE5g38bX2mY4aBs1ux00C82rz46evP3aFwYZeXk8pEPPs3qg== X-Received: by 2002:a05:6402:1341:b0:407:cece:49f8 with SMTP id y1-20020a056402134100b00407cece49f8mr19909177edw.152.1646810700956; Tue, 08 Mar 2022 23:25:00 -0800 (PST) Received: from [10.42.42.166] (212-197-176-189.adsl.highway.telekom.at. [212.197.176.189]) by smtp.gmail.com with ESMTPSA id u3-20020a17090657c300b006d01de78926sm377195ejr.22.2022.03.08.23.25.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 23:25:00 -0800 (PST) Message-ID: <6bab2e77-3827-dbc0-8592-39da1a51d187@gmail.com> Date: Wed, 9 Mar 2022 08:24:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: drivers: clk: stm32h7: Endless loop of dead in driver probe function Content-Language: en-US To: Patrick DELAUNAY , u-boot@lists.denx.de, dillon.minfei@gmail.com, patrice.chotard@foss.st.com References: <5affc0c0-f2e8-5dd7-54b1-cb7f30168ed5@foss.st.com> From: "Johannes (krjdev) Krottmayer" In-Reply-To: <5affc0c0-f2e8-5dd7-54b1-cb7f30168ed5@foss.st.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean 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