Re: [meta-ti][wrynose/master][PATCH V2] mesa-pvr: Migration from v24.0.1 -> v25.2.8

[Denys Dmytriyenko <denis@denix.org>]

On Thu, Jun 11, 2026 at 11:30:42AM -0500, Antonios Christidis via lists.yoctoproject.org wrote:
> 
> On 6/11/26 8:23 AM, Denys Dmytriyenko wrote:
> >On Wed, Jun 10, 2026 at 09:17:37PM -0500, Ryan Eatmon via lists.yoctoproject.org wrote:
> >>
> >>On 6/10/2026 5:58 PM, Antonios Christidis wrote:
> >>>Dear Ryan Denys,
> >>>
> >>>
> >>>Let me know your thoughts on the overall patch. I am particularly
> >>>interested on your opinions on the following change:
> >>>
> >>>On 6/10/26 5:51 PM, Antonios Christidis via lists.yoctoproject.org wrote:
> >>>>BSP_MESA_PVR_VERSION:bsp-ti-6_18: = "2%"
> >>So... I think what this does is establish the pattern for which
> >>version it will match to.  And then from that pattern it will pick
> >>the highest version.
> >>
> >>So for ALL 6_18 builds it will probably choose 25 and never 24.
> >>Which is not what you want.
> >>
> >>... I think ...
> >>
> >>We have never tried to mix versions like this in the past, so I'm
> >>not 100% sure what the best course is.
> >>
> >>Likely a mixture of the override based on machine needs to be in
> >>there. And for that I'm thinking you might need an extra variable.
> >>
> >>BSP_MESA_PVR_VERSION_6_18 ?= "25%"
> >>BSP_MESA_PVR_VERSION_6_18:am57 = "24%"
> >>BSP_MESA_PVR_VERSION_6_18:ti33 = "24%"
> >>etc...
> >>
> >>BSP_MESA_PVR_VERSION:bsp-ti-6_18 = "${BSP_MESA_PVR_VERSION_6_18}"
> >>
> >>
> >>Something along those lines?  That would be the most clear for
> >>people to follow as well.
> >It was done differently in this patch:
> >
> >mesa-pvr 24 was maked compatible only with SGX platforms, while mesa-pvr 25
> >was marked compatible with the rest of the platforms. Also not ideal though.
> >
> I think Ryan's idea is easier to follow, compared to the flow I have
> included in this series.
> 
> Another way of going about this (I'm not saying this is easier
> and/or a better method) would be to create 2 MACHINEOVERIDES. On a
> per platform level (ex: am62pxx.inc) to add ```MACHINEOVERRIDES =.
> "rogue-core:"```, then within ti-bsp
> ```BSP_MESA_PVR_VERSION:bsp-ti-6_18:rogue-core = "25%"``` picking
> the right version when paired against a sgx-core override.
> 
> An added benefit to this, the new overrides would cut down on the
> need for duplicate variables tracking Rogue vs SGX (examples:
> BSP_SGX_DRIVER_VERSION, BSP_ROGUE_DRIVER_VERSION).
> 
> A downside to this flow, tracking what is currently included
> within MACHINEOVERRIDES , describing what architecture of GPU core
> doesn't really fit well with pre-existing overrides.
> 
> 
> Let me know what you think?

FWIW, we used to have separate "sgx" and "rogue" flags in MACHINE_FEATURES 
years ago. Not exactly MACHINEOVERRIDES, but still easy to do conditionals.

But complaints were that all this needs to be unified and, first, both of 
those flags were merged into "gpu" MACHINE_FEATURES and eventually completely 
removed.

So, I'd argue if you do want to bump mesa-pvr version, it has to be done for 
all the platforms regardless of the graphics core, SGX or Rogue. We've already 
went through a lengthy period in kirkstone (2022 era) where SGX was completely 
broken and customers were sent back to use dunfell (2020 era) just to get SGX 
working at all...


> >>>I wish there was a way to use syntax like
> >>>"BSP_MESA_PVR_VERSION:bsp-ti-6_18 = "24%|25%" or even
> >>>"24.0.1|25.2.8". Is there a better way of enabling this logic ?
> >>>
> >>>Also already aware of the extra ":" post-pended to the variable, I
> >>>can send a v3 if that's all the feedback.
> >>>
> >>>
> >>>Kind Regards,
> >>>
> >>>Antonios
> >>>