[Pkg-Mali-devel] Debian mali pckaging status

[Sumit Garg]

On Wed, 18 Jul 2018 at 18:40, Guillaume Tucker
<guillaume.tucker at collabora.com> wrote:
>
> On 18/07/18 13:31, Wookey wrote:
> > On 2018-07-18 16:38 +0530, Sumit Garg wrote:
> >> On Wed, 18 Jul 2018 at 12:57, Guillaume Tucker <guillaume.tucker at collabora.com> wrote:
> >
> >>>> We have added support for GPU node in DTB present in EDK2 [1]. With
> >>>> this updated EDK2 firmware, I am able to run r12-bitfrost kernel
> >>>> driver (out-of-tree) with out-of-box Debian on hikey960. So I think we
> >>>> can move forward with mali-bitfrost-driver packaging in Debian.
> >
> > Hmm. Can someone explain to me how DTB info supplied by UEFI and/or
> > kernel works?  Does one override the other, do they get 'merged' (so
> > some devices supplied by firmward, some more by kernel?). Is
> > overriding/merging done on a per-device basis, or per-item? (sorry I
> > don't know the right terminology for dsicussing this in detail, but I
> > hope you understand what I mean).
>
> If I'm not mistaken, this is just the UEFI firmware loading the
> dtb in memory instead of say, U-Boot.  But it's not like on a PC
> where the information is read directly from UEFI - the driver
> won't know the difference.  So it's only a matter of where the
> dtb data is stored and how it's made available to the kernel.
>

Agree. In general, principle of DT is that there are agreed stable
bindings in kernel and that the system firmware should provide the DT
to the kernel. And in case of UEFI, dtb is part of firmware image, but
GRUB does provide an option to override the default dtb as following
entry in GRUB menu:

"devicetree /path/to/dtb"

> >>> This device tree node is not in the upstream kernel.  It needs to
> >>> be there in order to make a Debian package, as the Debian kernel
> >>> is based on upstream stable kernels.  Otherwise, the .dtb file
> >>> will not be part of the Debian packages.
> >>
> >> In case of hikey960, .dtb is part of edk2 (UEFI) firmware. I don't
> >> think we need to have it in Debian packages.
> >
> > A packaged kernel module could get its info from UEFI rather than the
> > kernel, however if I understand correctly we do not yet have agreement
> > on what info is actually supplied. The kernel module must work for
> > _all_ supported devices in debian so there has to be sufficient
> > consitency in the info. That means agreeing what mali bindings should
> > look like for the general case and using those. We can't sensibly have
> > different bodges coming from firmware on different boards.
>
> If I'm correct in what I explained above, then this shouldn't
> really be an issue as the same device tree bindings would be used
> regardless of where the dtb came from (U-Boot partition, UEFI
> firmware, built-in with kernel image...).
>

Agree. But in this particular case of out-of-tree Mali driver, I am
just trying to pitch an idea that if we can use bindings present in
Mali-ddk as generic for corresponding platforms. Like for
mali-bitfrost-r12 driver, we can use
"BX301A01B-SW-99002-r12p0-01rel0/driver/product/kernel/Documentation/devicetree/bindings/arm/mali-midgard.txt"
bindings. This also gives liberty to add additional feature specific
info in GPU node supported by corresponding Mali-ddk.

-Sumit

> >>> The first thing that needs to be done in order to upstream this
> >>> node is to add a new binding for mali-bifrost,
> >>
> >> After having conversation with people from ARM, it seems there are
> >> quite a bit feature-wise differences among upstream bindings and
> >> Mali-ddk bindings. Also there are platform specific bindings too in
> >> Mali-ddk which I am not sure will be acceptable upstream. So I think
> >> it won't be much value-add to upstream bindings until we have upstream
> >> Mali driver as we can't control these differences in bindings.
> >
> > We have to sort this out and agree one set of bindings. We can't have
> > the kernel and UEFI differing about it. How would the _generic_ kernel
> > module know which to use?
> >
> > I clearly need to understand these differences properly, but I agree
> > with Guillaume that the debian packaged module should use upstream
> > bindings. If I understand correctly these could be supplied by UEFI
> > rather than the kernel on some boards, but they must still match up
> > sufficiently. Some 'extra' platform-specific info could be provided by
> > firmware if need be (assuming that one can 'merge' sub-device info
> > from EUFI and kernel?)
>
> I know that UEFI on Juno overrides some device tree things, esp
> with memory regions ("mem" entries).  But I don't think anything
> like this is being done for the Mali GPU, is it?
>
> >>> Even if this board can have the .dtb as part of the
> >>> firmware (i.e. it's not technically needed to have it in Debian
> >>> itself), it follows the out-of-tree driver dt bindings and that's
> >>> not compatible with the package in Debian which follows the
> >>> upstream ones.
> >>
> >> AFAIK, earlier Mali packages in Debian are based on out-of-tree
> >> Mali-ddk (eg. r16-midgard). So these packages would be following
> >> bindings as per Mali-ddk. In similar manner out-of-tree bitfrost (eg.
> >> r13) could be packaged with platforms aligning to corresponding
> >> Mali-ddk bindings.
> >
> > No. The existing kernel module uses upstream kernel bindings. That's
> > obviously correct to me and we need to agree and upstream said
> > bindings.
> >
> > I am proposing a Connect session about the mali drivers, and it looks
> > like this bindings issue is one that needs to be discussed.
>
> I won't be there but will be watching on YouTube hopefully :)
>
> Guillaume