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

[Marek Vasut]

On 4/22/22 14:35, Patrice CHOTARD wrote:
> 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 ... ;-)

Larger change is coming, you are on CC.