07:05 <macc24> mmind00: why px30 has custom 'rockchip,px30-mali' compatible instead of using 'arm,mali-bifrost' when 'rockchip.....' is not defined in panfrost_drv.c ?

07:15 <mmind00> macc24: as you see it's compatible = "rockchip,px30-mali", "arm,mali-bifrost"; ... meaning that this is a fallback and the kernel will go through them from left to right till it finds a match ... the generic bifrost one in this case

07:16 <mmind00> macc24: the devicetree of a device is supposed to be stable and this is a safeguard if later quirks are found

07:18 <mmind00> macc24: i.e. a "mali-bifrost" is not a static PCIe card, but instead only an IP definition that the soc vendor integrates in their SoC in some form, so the "px30-mali" is an implementation of "mali-bifrost" and therefore issues can occur with the integration

07:30 <macc24> mmind00: afaik it's just a regular mali g31 and there are no quirks

07:30 <mmind00> macc24: still the established way to go is to have both

07:31 <macc24> ok ¯\_(ツ)_/¯

07:31 <mmind00> especially as it is the Rockchip implementation of a bifrost-mali in their px30-soc

07:32 <macc24> are you implying that because it's rockchip it will have hacks or what?

07:33 <mmind00> macc24: that isn't specific to Rockchip at all ... all soc vendors will implement the licensed IPs in some way

07:33 <mmind00> macc24: and the integration into the soc _can_ have effects ... so this is also a better-safe-than-sorry thing

07:34 <macc24> mmind00: ok

07:34 <mmind00> macc24: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml#n19 ;-)

07:34 <mmind00> macc24: or https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml

07:36 <mmind00> macc24: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml#n90 ... for an example of soc-vendor doing something different in their implementation (stericsson in this case)

07:38 <macc24> mmind00: sure i get it now

07:38 <mmind00> macc24: ok :-D

07:38 <macc24> i'm not that dense

07:38 <mmind00> macc24: didn't mean to imply that ;-)

07:40 <mmind00> macc24: I guess I might overshoot sometimes when trying to explain the why, trying to not fall into the "it just is done that way" case

07:43 <macc24> mmind00: i'm well aware that soc vendors do some random hacks thanks to mediatek *starts sobbing* i don't have devfreq on mali g72

14:55 <mrjay> guys what is the difference between OPTEE and ATF?? Do they do same the thing?

14:59 <arnd> mrjay: TF-A runs at the highest privilege level (EL3) and is fairly limited. op-tee is an OS that (normally) runs in secure-EL1 side-by-side with a non-secure OS like Linux, see https://developer.arm.com/documentation/102418/0100/TrustZone-in-the-processor for the various exception levels

15:00 <arnd> you can often find TF-A and op-tee running in the same system, but there are some other alternatives

15:22 <mrjay> arnd: so they differ in privilege level. Is it ARM64 thingy or older socs like cortex a7 rk3066 should add support for optee? digging into optee commit list it does things like secondary cpus bringup, suspend hardware config

15:23 <mrjay> r/a7/a9

15:34 <mmind00> mrjay: there is a big difference between arm32 and arm64 ... arm64 has a level more ... the secure monitor mediates between non-secure and secure world ... and does the psci-stuff as well ... so on arm64 it's: kernel -> smcc -> atf -> (smc either handled locally or transferred to tee)

15:34 <mmind00> mrjay: so on arm64 it's always atf + tee

15:36 <mmind00> mrjay: arm32 is different ... there is the variant of optee being standalone (like the rk322x currently implemented there) or bound to a arm32 atf build ... but still there is no separate secure monitor, so that stuff is was tighter integrated ... I did atf (+psci) for rk3288 quite some time ago, though never really tried the optee integration there

15:54 <mrjay> mmind00: a lot of new terms for me to look into.

15:54 <mrjay> :)