From: Andrew Davis <afd@ti.com>
To: Denys Dmytriyenko <denis@denix.org>
Cc: Darren Etheridge <detheridge@ti.com>,
<meta-ti@lists.yoctoproject.org>, <reatmon@ti.com>
Subject: Re: [meta-ti][dunfell][PATCH v2] ti-graphics: gpu enable and move all platforms to ddk 1.15
Date: Fri, 25 Mar 2022 17:36:47 -0500 [thread overview]
Message-ID: <29965fda-5ada-3a75-e142-ed84e7dbf524@ti.com> (raw)
In-Reply-To: <16DFC054FC61A9B3.21339@lists.yoctoproject.org>
On 3/25/22 5:30 PM, Andrew F. Davis via lists.yoctoproject.org wrote:
> On 3/25/22 5:06 PM, Denys Dmytriyenko wrote:
>> On Fri, Mar 25, 2022 at 04:54:56PM -0500, Andrew F. Davis via lists.yoctoproject.org wrote:
>>> On 3/25/22 4:38 PM, Denys Dmytriyenko wrote:
>>>> On Fri, Mar 25, 2022 at 04:21:38PM -0500, Andrew Davis wrote:
>>>>> On 3/25/22 3:10 PM, Denys Dmytriyenko wrote:
>>>>>> On Wed, Mar 23, 2022 at 02:37:07PM -0500, Darren Etheridge wrote:
>>>>>>> Enable the GPU for am62xx and j721s2 and use IMG DDK 1.15
>>>>>>>
>>>>>>> Migrate Imagination DDK 1.13 to DDK 1.15 for J721e
>>>>>>
>>>>>> Overall looks good, please see inline below.
>>>>>>
>>>>>>
>>>>>>> Signed-off-by: Darren Etheridge <detheridge@ti.com>
>>>>>>> ---
>>>>>>>
>>>>>>> rename from recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.13.5776728.bb
>>>>>>> rename to recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.15.6133109.bb
>>>>>>> index a05de0f2..fbff6c51 100644
>>>>>>> --- a/recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.13.5776728.bb
>>>>>>> +++ b/recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.15.6133109.bb
>>>>>>> @@ -7,17 +7,17 @@ inherit module features_check
>>>>>>> REQUIRED_MACHINE_FEATURES = "gpu"
>>>>>>> -MACHINE_KERNEL_PR_append = "b"
>>>>>>> +MACHINE_KERNEL_PR_append = "a"
>>>>>>> PR = "${MACHINE_KERNEL_PR}"
>>>>>>> PACKAGE_ARCH = "${MACHINE_ARCH}"
>>>>>>> -COMPATIBLE_MACHINE = "j7"
>>>>>>> +COMPATIBLE_MACHINE = "j7-evm|j721s2-evm|am62xx"
>>>>>>> DEPENDS = "virtual/kernel"
>>>>>>> PROVIDES = "virtual/gpudriver"
>>>>>>> -BRANCH = "1.13-5776728/linux-k5.10"
>>>>>>> +BRANCH = "linuxws/dunfell/k5.10/${PV}"
>>>>>>> SRC_URI = " \
>>>>>>> git://git.ti.com/graphics/ti-img-rogue-driver.git;branch=${BRANCH} \
>>>>>>> @@ -26,15 +26,19 @@ SRC_URI = " \
>>>>>>> S = "${WORKDIR}/git"
>>>>>>> -SRCREV = "35a25875ae8738f82c7cabc6b077ef992b0cca84"
>>>>>>> +SRCREV = "ee0674adccac16f5b2f7cb8d5d05948706080cb5"
>>>>>>> -PVR_SOC = "j721e_linux"
>>>>>>
>>>>>> I was actually thinking of keeping PVR_SOC variable and moving it to
>>>>>> corresponding machine configs.
>>>>>>
>>>>>
>>>>>
>>>>> PVR_SOC is a bit of a legacy name, especially since PVR is now IMG.
>>>>
>>>> PVR or PowerVR name is still used as an overall umbrella for all of
>>>> Imagination's graphics, vision and AI chips, including SGX and Rogue/RGX:
>>>> https://en.wikipedia.org/wiki/PowerVR
>>>>
>>>
>>>
>>> On the wiki page:
>>>
>>>> These GPUs are no longer called PowerVR, they are called IMG.[58]
>>>
>>> For their next gen GPUs they are distancing themselves from the PVR name,
>>> the GPU in AM62xx is one such next gen GPU, so it's already not correct here
>>> as is.
>>
>> So, then why AM62xx is being added to Rogue driver/DDK? Should there be a
>> separate Albiorix driver and DDK then?
>>
>
>
> We asked IMG very nicely to not fork the DDK for each new gen of device (like
> what happened with SGX -> Rogue), so now we have he same driver code base
> supporting multiple generations of GPU. The name "Rogue" just stuck around.
> We should probably rename some of this stuff to also be more generic.
>
>
>>
>>>>> Thinking on this, the mapping between SoC family and the internal names
>>>>> like "RGX_BVNC" and "TARGET_PRODUCT" are specific to the version of this
>>>>> driver. For instance in the next DDK I may want the target name to
>>>>> go from "am62_linux" to "axb_128_linux", I would have to
>>>>> change things here (update the SRCREV) AND in the machine config.
>>>>
>>>> 1. I totally agree that "axb_128_linux" makes more sense than "am62_linux".
>>>> 2. Changes like that happen very rarely.
>>>> 3. You can call it PVR_MODEL or PVR_PRODUCT if you want, instead of PVR_SOC.
>>>>
>>>>
>>>>> Mapping here feels like the right spot to me. I'd even argue the same
>>>>> for OPTEEMACHINE and the like, should go in the optee.bbappends with the
>>>>> rest of our platform specific recipe fixups, etc.
>>>>
>>>> The number of overrides in the recipe will keep on growing, as each new
>>>> platform will need to add own config. That's the whole point of the machine
>>>> configuration file to have those defined centrally.
>>>>
>>>> The goal is to have a recipe as machine-agnostic and clean, as possible. Do
>>>> not overwhelm it with tons of conditionals like that - any machine-specific
>>>> configuration should be set in the machine config file.
>>>>
>>>
>>>
>>> Having all the fixups related to a package inside that package's definition sounds
>>> more central to me, and easier to reason about. But I can see the argument both
>>> ways.
>>>
>>> Maybe the better solution would be to splitup this(and the SGX) recipe. So we
>>> get a package per GPU type. It's already how the bins are organized/shipped. Then
>>> we just pick the right GPU package for our SoC in arago-prefs.inc. (again like
>>> we already do to select between SGX/RGX)
>>
>> Yeah, I think keeping each series of GPU (SGX, Rogue, Albiorix) in their own
>> separate recipes would be fine. Or are you suggesting splitting even further
>> into separate recipes for SGX530 vs SGX540, etc?
>>
>
>
> I'm suggesting even further. The driver/package for SGX530 is not compatible
> and conflicts with the driver package for SGX540. So lets not have a single named
> package (ti-sgx-ddk-um) that can have very different contents, that's just confusing.
>
Oh, and not separate recipes, separate packages, they can all be provided
by the same one or two recipes.
ti-sgx-530-um
ti-sgx-544-um
ti-axe1-16m-um
etc..
Then:
PREFERRED_PROVIDER_virtual/libgles2:am62xx = "ti-axe1-16m-um"
...
Andrew
> Andrew
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#14562): https://lists.yoctoproject.org/g/meta-ti/message/14562
> Mute This Topic: https://lists.yoctoproject.org/mt/89983769/3619733
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [afd@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
next prev parent reply other threads:[~2022-03-25 22:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 19:37 [meta-ti][dunfell][PATCH v2] ti-graphics: gpu enable and move all platforms to ddk 1.15 Darren Etheridge
2022-03-25 20:10 ` Denys Dmytriyenko
2022-03-25 21:21 ` Andrew Davis
2022-03-25 21:38 ` Denys Dmytriyenko
2022-03-25 21:54 ` Andrew Davis
2022-03-25 22:06 ` Denys Dmytriyenko
2022-03-25 22:30 ` Andrew Davis
[not found] ` <16DFC054FC61A9B3.21339@lists.yoctoproject.org>
2022-03-25 22:36 ` Andrew Davis [this message]
2022-03-29 5:28 ` Denys Dmytriyenko
2022-03-29 21:48 ` Etheridge, Darren
2022-03-29 23:26 ` Denys Dmytriyenko
2022-03-30 12:40 ` Ryan Eatmon
2022-03-29 5:21 ` Denys Dmytriyenko
2022-04-30 18:02 ` Denys Dmytriyenko
[not found] ` <16EABE932EA7F3D7.11702@lists.yoctoproject.org>
2022-05-02 2:57 ` Denys Dmytriyenko
2022-05-02 2:58 ` Denys Dmytriyenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29965fda-5ada-3a75-e142-ed84e7dbf524@ti.com \
--to=afd@ti.com \
--cc=denis@denix.org \
--cc=detheridge@ti.com \
--cc=meta-ti@lists.yoctoproject.org \
--cc=reatmon@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).