[meta-xilinx] [PATCH] zynqmp: Make the MALI recommendation machine-specific

[Manjukumar Harthikote Matha]

Hi Nathan/Mike,

> -----Original Message-----
> From: Nathan Rossi [mailto:nathan at nathanrossi.com]
> Sent: Sunday, August 07, 2016 6:54 AM
> To: Mike Looijmans
> Cc: Manjukumar Harthikote Matha; meta-xilinx at lists.yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH] zynqmp: Make the MALI recommendation
> machine-specific
>
> On Fri, Aug 5, 2016 at 2:40 AM, Mike Looijmans <mike.looijmans at topic.nl> wrote:
> > On 04-08-16 17:02, Nathan Rossi wrote:
> >>
> >> On Tue, Aug 2, 2016 at 4:49 AM, Manjukumar Harthikote Matha
> >> <manjukumar.harthikote-matha at xilinx.com> wrote:
> >>>
> >>> Hi Nathan,
> >>>
> >>>
> >>> On 07/31/2016 06:17 AM, Nathan Rossi wrote:
> >>>>
> >>>>
> >>>> On Sat, Jul 30, 2016 at 4:46 AM, Manjukumar Harthikote Matha
> >>>> <manjukumar.harthikote-matha at xilinx.com> wrote:
> >>>>>
> >>>>>
> >>>>> Hi Mike,
> >>>>>
> >>>>> On 07/26/2016 03:59 AM, Mike Looijmans wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Not all zynqmp SoCs have a MALI GPU built in. Thus recommending
> >>>>>> kernel-module-mali for all zynqmp machines is incorrect. Move the
> >>>>>> recommendation to the board config.
> >>>>>>
> >>>>>> This also makes for a nicer syntax, having less-specific platform
> >>>>>> overrides for machine-specific variables just doesn't look right.
> >>>>>>
> >>>>>> Signed-off-by: Mike Looijmans <mike.looijmans at topic.nl>
> >>>>>> ---
> >>>>>>   conf/machine/include/machine-xilinx-default.inc | 4 ----
> >>>>>>   conf/machine/zcu102-zynqmp.conf                 | 3 +++
> >>>>>>   2 files changed, 3 insertions(+), 4 deletions(-)
> >>>>>>
> >>>>> <...>
> >>>>> Yes this is true, after the road map has been made clear with CG
> >>>>> parts, however please see my previous comments on mali-modules,
> >>>>> once resolved we should move it to board-specific
> >>>>
> >>>>
> >>>>
> >>>> It appears that the product table is public showing CG, EG and EV
> >>>> parts respectively.
> >>>>
> >>>>
> >>>>
> >>>> http://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-
> >>>> mpsoc.html#productTable
> >>>>
> >>>> Is it worth having three separate includes for the CG/EG/EV parts?
> >>>> So that this sort of config can be easily included for
> >>>> machines/boards that use the specified part? This would allow
> >>>> additional configuration that would only be relevant to those variants as well.
> >>>>
> >>> Can we use MACHINE_FEATURES and enable appropriate configs? Do you
> >>> think it is a good idea? We can have one include instead of 3 or
> >>> more.
> >>
> >>
> >> That is a definitely a better solution, then all that is needed is
> >> the two feature flags 'zynqmp-mali' (or just mali?) and 'zynqmp-venc'
> >> (or something similar). And most of the conditional selection can be
> >> done with bb.utils.contains.
> >
> >
> > For mali maybe you could use an existing machine feature like "opengl"?
>
> That would work fine too, assuming of course that the mali module does not provide
> any api's other than those needed for the user-space opengl support. But even then
> the contains_any can handle checking if the machine provides multiple features
> where the mali module is needed.
>
> Manju if you are good with using the "opengl" machine feature flag for this we can
> handle the video encoder naming seperately.
>
MALI user-space binaries provide gles1, gles2 and egl. For the entire stack you would still need Mesa providing gl. Is it better if we just use "mali" and "vcu" ?

Also, I have seen "opengl" being used as distro features very often.

Thanks
Manju


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.