[PATCH 20/26] arm: mach-k3: do board config for PM and RM only if supported

[Tero Kristo]

On 17/11/2020 11:22, Tero Kristo wrote:
> On 17/11/2020 08:14, Lokesh Vutla wrote:
>>
>>
>> On 16/11/20 5:57 pm, Tero Kristo wrote:
>>> On 16/11/2020 06:23, Lokesh Vutla wrote:
>>>>
>>>>
>>>> On 10/11/20 2:35 pm, Tero Kristo wrote:
>>>>> If the raw PM support is built in, we are operating in the split
>>>>> firmware approach mode where RM and PM support is not available. In 
>>>>> this
>>>>> case, skip the board config for these two.
>>>>>
>>>>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>>>>> ---
>>>>>    arch/arm/mach-k3/sysfw-loader.c | 4 ++++
>>>>>    1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/mach-k3/sysfw-loader.c 
>>>>> b/arch/arm/mach-k3/sysfw-loader.c
>>>>> index 78c158c63f..154d2df049 100644
>>>>> --- a/arch/arm/mach-k3/sysfw-loader.c
>>>>> +++ b/arch/arm/mach-k3/sysfw-loader.c
>>>>> @@ -158,11 +158,13 @@ static void k3_sysfw_configure_using_fit(void 
>>>>> *fit,
>>>>>                  ret);
>>>>>          /* Apply power/clock (PM) specific configuration to SYSFW */
>>>>> +#ifdef CONFIG_CLK_TI_SCI
>>>>
>>>> IMHO, using CONFIG_CLK_TI_SCI is hack here. Can we showhow derive this
>>>> information based on the images loaded in FIT?
>>>
>>> At this point we have only loaded the sysfw image. DM image against 
>>> which we
>>
>> This sysfw.itb contains all the board configurations?
>> If yes, then we are adding board configurations in sysfw.itb that does 
>> not
>> belong here.
>>
>> If no, then can we check for the entries before loading?
> 
> Technically feasible yes, let me check with Dave offline what we can 
> craft for this (the image generation part was done by him); the firmware 
> image generator does something along these lines already, basically 
> splitting the cfg portions to different images.

Ok, after some offline discussions, we ended up with a solution that for 
the sysfw_loader portion at least we have to use a config option, as 
otherwise the build process becomes completely broken with multiple 
cross dependencies towards/between external build tools etc... To make 
things a bit more clear though, I'll add a new config option called 
CONFIG_TI_DM_FW, which would indicate that we are using a separate DM 
firmware image in the system. This avoids overloading the 
CONFIG_CLK_TI_SCI or something else, even if these two effectively 
follow each other in their value.

I'll re-work the relevant patches around this and re-post.

-Tero

> 
> -Tero
> 
>>
>> Thanks and regards,
>> Lokesh
>>
>>> could check this will only be loaded during A72 SPL FIT loading 
>>> process, and it
>>> will only happen later.
>>>
>>> -Tero
>>>
>>>>
>>>> Thanks and regards,
>>>> Lokesh
>>>>
>>>>>        ret = board_ops->board_config_pm(ti_sci,
>>>>>                         (u64)(u32)cfg_fragment_addr,
>>>>>                         (u32)cfg_fragment_size);
>>>>>        if (ret)
>>>>>            panic("Failed to set board PM configuration (%d)\n", ret);
>>>>> +#endif
>>>>>          /* Extract resource management (RM) specific configuration 
>>>>> from FIT */
>>>>>        ret = fit_get_data_by_name(fit, images, SYSFW_CFG_RM,
>>>>> @@ -171,12 +173,14 @@ static void k3_sysfw_configure_using_fit(void 
>>>>> *fit,
>>>>>            panic("Error accessing %s node in FIT (%d)\n", 
>>>>> SYSFW_CFG_RM,
>>>>>                  ret);
>>>>>    +#ifdef CONFIG_CLK_TI_SCI
>>>>>        /* Apply resource management (RM) configuration to SYSFW */
>>>>>        ret = board_ops->board_config_rm(ti_sci,
>>>>>                         (u64)(u32)cfg_fragment_addr,
>>>>>                         (u32)cfg_fragment_size);
>>>>>        if (ret)
>>>>>            panic("Failed to set board RM configuration (%d)\n", ret);
>>>>> +#endif
>>>>>          /* Extract security specific configuration from FIT */
>>>>>        ret = fit_get_data_by_name(fit, images, SYSFW_CFG_SEC,
>>>>>
>>>
>>> -- 
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki