On 12/12/2018 13:31, Thierry Reding wrote:
> On Wed, Dec 12, 2018 at 11:47:32AM +0000, Jon Hunter wrote:
>>
>> On 11/12/2018 17:21, Stephen Boyd wrote:
>>> Quoting Arnd Bergmann (2018-12-11 06:35:07)
>>>> When CONFIG_SMP is disabled, the tegra clk driver now fails to build:
>>>>
>>>> drivers/clk/tegra/clk-tegra30.c: In function 'tegra30_cpu_rail_off_ready':
>>>> drivers/clk/tegra/clk-tegra30.c:1151:19: error: implicit declaration of function 'tegra_pmc_cpu_is_powered'; did you mean 'tegra_powergate_is_powered'? [-Werror=implicit-function-declaration]
>>>> cpu_pwr_status = tegra_pmc_cpu_is_powered(1) ||
>>>>
>>>> I don't know if tegra works without CONFIG_SMP, but we can get it to
>>>> build by making the calls conditional, and removing the pointless
>>>> ifdef around the declaration. The assumption now is that in a
>>>> non-SMP system, the secondary CPUs are always disabled.
>>>>
>>>> Fixes: 61866523ed6e ("clk: tegra30: Use Tegra CPU powergate helper function")
>>>> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
>>>> ---
>>>> Not sure if this is the best solution. If you think it's not, please
>>>> submit a different fix.
>>>
>>> Hmm.. Is there any reason why the implementation of
>>> tegra_pmc_cpu_is_powered() is under an ifdef CONFIG_SMP? I'd rather not
>>> have to think about SMP or not in this clk code and have the
>>> tegra_pmc_cpu_is_powered() function do the UP vs SMP code optimization.
>>
>> Not that I know of. I just think that the function should/would not be
>> used for non-SMP.
>>
>> I was actually thinking that we could just leave the clk code as it is
>> and simply drop the CONFIG_SMP from pmc.h. That would be fine with me.
>
> Yeah, I'd be fine keeping that code around whether or not we enable SMP.
> Chances are people won't disable it anyway. If they do, then most likely
> only for testing purposes, in which case I'm sure they won't mind the
> extra couple of bytes.
>
> I think if we remove CONFIG_SMP from pmc.h we also need to remove it
> from drivers/soc/tegra/pmc.c to make sure these functions are available,
> otherwise we'll likely run into linker errors.
>
> Jon, is that something I can interest you in? If not, I can easily do
> that myself.
Yes I can do it (tomorrow).
Cheers
Jon
--
nvpublic
