[PATCH] led: Configure LED default-state on boot

[Patrice CHOTARD]

Hi Marek

On 4/22/22 13:41, Marek Vasut wrote:
> On 4/22/22 11:02, Marek Vasut wrote:
>> On 4/22/22 09:09, Patrice CHOTARD wrote:
>>> Hi Sean
>>>
>>> On 4/22/22 02:06, Sean Anderson wrote:
>>>> On 4/21/22 11:26 AM, Patrice CHOTARD wrote:
>>>>>
>>>>>
>>>>> On 4/21/22 17:18, Marek Vasut wrote:
>>>>>> On 4/21/22 17:09, Patrice CHOTARD wrote:
>>>>>>> Hi Marek
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> I tested the current U-Boot master branch (22bfaa1f673ab5442dfb9778eea4c9a18dee42d0)
>>>>>>> This patch is breaking the boot sequence on stm32mp157c-dk2.
>>>>>>
>>>>>> Breaking it ... how ? What happens, hang ?
>>>>>
>>>>> Here is the boot log :
>>>>>
>>>>> U-Boot SPL 2022.04-00827-g22bfaa1f67 (Apr 21 2022 - 17:22:47 +0200)
>>>>> RAM: DDR3-DDR3L 16bits 533000kHz
>>>>> WDT:   Started watchdog at 5a002000 with servicing (32s timeout)
>>>>>
>>>>>
>>>>> U-Boot 2022.04-00827-g22bfaa1f67 (Apr 21 2022 - 17:22:47 +0200)
>>>>>
>>>>> CPU: STM32MP157CAC Rev.B
>>>>> Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
>>>>> Board: stm32mp1 in basic mode (st,stm32mp157c-dk2)
>>>>> Board: MB1272 Var2.0 Rev.C-01
>>>>> DRAM:  512 MiB
>>>>> Clocks:
>>>>> - MPU : 0 MHz
>>>>> - MCU : 0 MHz
>>>>> - AXI : 0 MHz
>>>>> - PER : 0 MHz
>>>>> - DDR : 0 MHz
>>>>> clock rate is 0
>>>>> clock rate is 0
>>>>> clock rate is 0
>>>>> clock rate is 0
>>>>> clock rate is 0
>>>>> cloc
>>>>>
>>>>> What worried me is that all clocks are set to 0 (MPU/MCU/AXI ....)...no direct link with the led-uclass update.
>>>>> For information, if i comment the device_probe(dev) in led_post_bind(), it avoid the hang.
>>>>
>>>> Can you try applying the LED patch on top of 2022.04?
>>>> I made some clock changes recently, so it could be an interaction with that.
>>>>
>>>
>>> Thanks for the tips, but unfortunately, i have the same issue when applying this patch on top of v2022.04.
>>> I am still investigating ..... ;-)
>>
>> Maybe the clk_* in gpio_stm32 is the problem, is the gpio driver for mp1 probed by the time the led post_bind is called ? If not, maybe that's an issue.
>>
>> I'll have a look too.
> 
> Try this patch, does it "fix" it for you ?
> 
> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
> index 5a2be007586..ec5cddfcf98 100644
> --- a/arch/arm/dts/stm32mp151.dtsi
> +++ b/arch/arm/dts/stm32mp151.dtsi
> @@ -70,7 +70,7 @@
>                 interrupt-parent = <&intc>;
>         };
> 
> -       clocks {
> +//     clocks {
>                 clk_hse: clk-hse {
>                         #clock-cells = <0>;
>                         compatible = "fixed-clock";
> @@ -100,7 +100,7 @@
>                         compatible = "fixed-clock";
>                         clock-frequency = <4000000>;
>                 };
> -       };
> +//     };
> 
>         thermal-zones {
>                 cpu_thermal: cpu-thermal {
> 
> If so, we need to figure out why.

With this patch, the board is booting fine 

The "led patch" is changing the order of probing of some early drivers (led, clock, gpio, pinctrl....) ..... to be continued ... ;-)


Thanks
Patrice