+devicetree On Tue, Dec 10, 2024 at 07:43:19PM -0800, Rob Clark wrote: > 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. > Thanks Rob and Bjorn for your inputs. At the moment, we don't have capability in our bootloader to apply a *specific* overlay when Linux kernel is starteed in EL, this is making GPU non-functional. This patch from Akhil fixes the problem without depending on the bootloader.
