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

[Patrice CHOTARD]

Hi Marek

On 4/22/22 15:14, Marek Vasut wrote:
> 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.

Thanks, it fixes the issue ;-)