On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote:
> Quoting Elliot Berman (2021-03-05 10:18:09)
> > On 3/3/2021 10:14 PM, Stephen Boyd wrote:
> > > Quoting Elliot Berman (2021-03-03 19:35:08)
> > >>
> > >> On 2/23/2021 1:45 PM, Stephen Boyd wrote:
> > >>> These scm calls are never used outside of legacy ARMv7 based platforms.
> > >>> That's because PSCI, mandated on arm64, implements them for modern SoCs
> > >>> via the PSCI spec. Let's move them to the legacy file and only compile
> > >>> the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
> > >>> stubs and fail the calls. This saves a little bit of space in an
> > >>> arm64 allmodconfig >
> > >>> $ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> > >>> add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
> > >>> Function old new delta
> > >>> __qcom_scm_set_dload_mode.constprop 312 452 +140
> > >>> qcom_scm_qsmmu500_wait_safe_toggle 288 416 +128
> > >>> qcom_scm_io_writel 288 408 +120
> > >>> qcom_scm_io_readl 376 492 +116
> > >>> __param_str_download_mode 23 28 +5
> > >>> __warned 4327 4326 -1
> > >>> qcom_iommu_init 272 268 -4
> > >>> e843419@0b3f_00010432_324 8 - -8
> > >>> qcom_scm_call 228 208 -20
> > >>> CSWTCH 5925 5877 -48
> > >>> _sub_I_65535_1 163100 163040 -60
> > >>> _sub_D_65535_0 163100 163040 -60
> > >>> qcom_scm_wb 64 - -64
> > >>> qcom_scm_lock 320 160 -160
> > >>> qcom_scm_call_atomic 212 - -212
> > >>> qcom_scm_cpu_power_down 308 - -308
> > >>> scm_legacy_call_atomic 520 - -520
> > >>> qcom_scm_set_warm_boot_addr 720 - -720
> > >>> qcom_scm_set_cold_boot_addr 728 - -728
> > >>> scm_legacy_call 1492 - -1492
> > >>> Total: Before=66737642, After=66733746, chg -0.01%
> > >>>
> > >>> Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
> > >>> legacy conventions") didn't mention any motivating factors for keeping
> > >>> the legacy code around on arm64 kernels, i.e. presumably that commit
> > >>> wasn't trying to support these legacy APIs on arm64 kernels.
> > >>
> > >> There are arm targets which support SMCCC convention and use some of
> > >> these removed functions. Can these functions be kept in qcom-scm.c and
> > >> wrapped with #if IS_ENABLED(CONFIG_ARM)?
> > >>
> > >
> > > It can be wrapped in qcom-scm.c, but why? It's all the same object file
> > > so I'm lost why it matters. I suppose it would make it so the struct
> > > doesn't have to be moved around and declared in the header? Any other
> > > reason? I moved it to the legacy file so that it was very obvious that
> > > the API wasn't to be used except for "legacy" platforms that don't use
> > > PSCI.
> > >
> >
> > There are "legacy" arm platforms that use the SMCCC (scm_smc_call) and
> > use the qcom_scm_set_{warm,cold}_boot_addr and qcom_scm_cpu_power_down
> > functions.
>
> Ah ok. Weird, but I get it. Amazing that SMCCC was adopted there but
> PSCI wasn't!
>
> >
> > > + desc.args[0] = flags;
> > > + desc.args[1] = virt_to_phys(entry);
> > > +
> > > + return scm_legacy_call_atomic(NULL, &desc, NULL);
> > > +}
> > > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr);
> >
> > This should still be qcom_scm_call.
>
> You mean s/scm_legacy_call_atomic/qcom_scm_call/ right?
>
> I don't really want to resend the rest of the patches if this last one
> is the only one that needs an update. This was a semi-RFC anyway so
> maybe it's fine if the first 5 patches get merged and then I can resend
> this one? Otherwise I will resend this again next week or so with less
> diff for this patch.
I'm fine with merging the first 5, but was hoping that Elliot could
provide either a "Reviewed-by" or at least an "Acked-by" on these.
Regards,
Bjorn
