On Tue, Dec 10, 2024 at 7:08 PM Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> wrote: > > On 12/11/2024 6:43 AM, Bjorn Andersson wrote: > > On Tue, Dec 10, 2024 at 02:22:27AM +0530, Akhil P Oommen wrote: > >> On 12/10/2024 1:24 AM, Rob Clark wrote: > >>> On Mon, Dec 9, 2024 at 12:20 AM Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> wrote: > >>>> > >>>> When kernel is booted in EL2, SECVID registers are accessible to the > >>>> KMD. So we can use that to switch GPU's secure mode to avoid dependency > >>>> on Zap firmware. Also, we can't load a secure firmware without a > >>>> hypervisor that supports it. > >>> > >>> Shouldn't we do this based on whether zap node is in dtb (and not disabled)? > >> > >> This is better, isn't it? Otherwise, multiple overlays should be > >> maintained for each soc/board since EL2 can be toggled from bootloader. > >> And this feature is likely going to be more widely available. > >> > > > > The DeviceTree passed to the OS needs to describe the world that said OS > > is going to operate in. If you change the world you need to change the > > description. > > There are several other examples where this would be necessary > > (remoteproc and watchdog to name two examples from the Qualcomm upstream > > world). > > But basic things work without those changes, right? For eg: Desktop UI It isn't really so much about whether certain use-cases can work with a sub-optimal description of the hw (where in this case "hw" really means "hw plus how the fw allows things to look to the HLOS").. It is more about the hw/fw/whatever providing an accurate description of what things look like to the HLOS. I'm leaning more towards the hw+fw providing HLOS an accurate view... and the fact that that carries over into other areas of dtb (ie. it isn't the only thing that slbounce needs to patch, as I previously mentioned) reinforces my view there. This seems like a thing to fix in fw/bootloader tbh. BR, -R > > > > > So, if we can cover this by zap-shader being enabled or disabled, that > > sounds like a clean and scaleable solution. > > I think we are focusing too much on zap shader. If the driver can > determine itself about access to its register, shouldn't it be allowed > to use that? > > -Akhil > > > > > Regards, > > Bjorn >
