On Wed, Dec 11, 2024 at 01:06:58PM +0530, Pavan Kondeti wrote: > +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. > > From this discussion, I understand that it is recommended to provide > HW+FW view in dT correctly instead of doing runtime checks in the > kernel. We can take this as a requirement to the bootloader. > > I would like to check how we should proceed with overlay. Should we > submit dtso upstream and let bootloader apply the overlay at runtime or > this whole overlay needs to be maintained in the bootloader. Also, > Should we build all board dtb for EL2 as well or just leave it at compiling > the EL2 dtbo (one per SoC)? It doesn't have to be a dtbo. Instead you might just patch the DT (Ideally via the https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL). I think the bootloader already changes the DT (by fixing memory sizes, etc), so enabling or disabling ZAP & fixing several other bits and pieces sounds logical. -- With best wishes Dmitry
