Hi Okash
Your use-case is reasonable, but I'm a bit concerned about imposing the runtime cost of a platform call on all platforms to cater for the subset of platforms that support this mode. Can this be wrapped in a build flag (off by default)?
Also, I wonder if something more generically useful could be done here? E.g. is there some mode detection logic in your plat_can_cmo implementation that can be brought into generic code? I'm not familiar enough with this feature to know if that's possible.
Regards
Dan.
-----Original Message----- From: Okash Khawaja via TF-A tf-a@lists.trustedfirmware.org Sent: 31 October 2022 18:11 To: Bipin Ravi Bipin.Ravi@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Conditional CMOs
Hi Bipin,
Thanks for your feedback. I was thinking of something quite simple. E.g. in each of the assembly routines in lib/aarch64/cache_helpers.S (flush_dcache_range, clean_dcache_range, inv_dcache_range etc), add a call to following macro right at the beginning:
.macro check_plat mov x2, x0 bl plat_can_cmo cbnz x0, 1f ret 1: mov x0, x2 .endm
Each platform can implement plat_can_cmo. Otherwise a default weak implementation will be chosen, such as
func plat_can_cmo mov x0, #1 ret endfunc plat_can_cmo
Then it's up to the platform to determine whether they want cache clean or invalidates depending upon their specific conditions, which might well be checking CPU debug/recovery mode. What do you think?
Best regards, Okash
On Mon, Oct 31, 2022 at 5:35 PM Bipin Ravi via TF-A <tf- a@lists.trustedfirmware.org> wrote:
Hi Okash,
From an initial scan of the CPU TRMs, the caches (L1 I-Cache/D-Cache
and/or L2 Cache) supported for "Direct access to internal memory" under this feature could be different for different CPUs. So, it is reasonable to have platform hook to do this and take of this for the caches required/applicable per the platform config and convert the "unconditional cleans and invalidates caches" that TF-A does, to something conditional to the "core power mode not equal to Debug Recovery".
We would be happy to help review any patch for this.
--Bipin
TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org