[PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Siddharth Heroor]

* Override SRC_URI to use TI's tree at https://git.ti.com/glsdk/libdrm
  This tree includes patches on top of the upstream libdrm for
  omap5 and dra7xx class of devices.

Signed-off-by: Mrinmayee Hingolikar <mrinmayee@ti.com>
Signed-off-by: Siddharth Heroor <heroor@ti.com>
---
 recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)
 create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb

diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-graphics/drm/libdrm_2.4.41.bb
new file mode 100644
index 0000000..31f7cee
--- /dev/null
+++ b/recipes-graphics/drm/libdrm_2.4.41.bb
@@ -0,0 +1,15 @@
+require recipes-graphics/drm/libdrm.inc
+
+COMPATIBLE_MACHINE = "omap-a15"
+
+DEFAULT_PREFERENCE = "-1"
+
+EXTRA_OECONF += "--enable-omap-experimental-api"
+
+SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
+SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
+
+# Append to the PR so that a new SRCREV will cause a rebuild
+PR_append = "a+gitr${SRCPV}"
+
+S = "${WORKDIR}/git"
-- 
1.7.0.4

Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Maupin, Chase]

>-----Original Message-----
>From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>bounces@yoctoproject.org] On Behalf Of Heroor, Siddharth
>Sent: Thursday, June 27, 2013 12:17 PM
>To: meta-ti@yoctoproject.org
>Subject: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree
>for omap-a15
>
>* Override SRC_URI to use TI's tree at
>https://git.ti.com/glsdk/libdrm
>  This tree includes patches on top of the upstream libdrm for
>  omap5 and dra7xx class of devices.
>
>Signed-off-by: Mrinmayee Hingolikar <mrinmayee@ti.com>
>Signed-off-by: Siddharth Heroor <heroor@ti.com>
>---
> recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
> create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb
>
>diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-
>graphics/drm/libdrm_2.4.41.bb
>new file mode 100644
>index 0000000..31f7cee
>--- /dev/null
>+++ b/recipes-graphics/drm/libdrm_2.4.41.bb

I thought you were going to bbappend this instead of overlaying the whole recipe.

>@@ -0,0 +1,15 @@
>+require recipes-graphics/drm/libdrm.inc
>+
>+COMPATIBLE_MACHINE = "omap-a15"
>+
>+DEFAULT_PREFERENCE = "-1"
>+
>+EXTRA_OECONF += "--enable-omap-experimental-api"
>+
>+SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
>+SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
>+
>+# Append to the PR so that a new SRCREV will cause a rebuild
>+PR_append = "a+gitr${SRCPV}"

I always had issue with this.  I'm not sure that this statement holds true because whether a new SRCREV will cause a rebuild would depend on whether that SRCREV sorts higher than the old one.  Unless something else has changed.  This is useful though if you want to know what SRCREV was used for a build.

That being said if you were going to overlay this recipe the PR should be something like

PR = "${INC_PR}.0"

Right now you are appending to the default since PR is not defined.  With a bbappend you should append a -arago flag.

So this comes back to why no bbappend?  Is it because the base version in oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git version of the recipe and update the PV appropriately?

>+
>+S = "${WORKDIR}/git"
>--
>1.7.0.4
>
>_______________________________________________
>meta-ti mailing list
>meta-ti@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/meta-ti

Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Denys Dmytriyenko]

On Thu, Jun 27, 2013 at 05:46:43PM +0000, Maupin, Chase wrote:
> >-----Original Message-----
> >From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
> >bounces@yoctoproject.org] On Behalf Of Heroor, Siddharth
> >Sent: Thursday, June 27, 2013 12:17 PM
> >To: meta-ti@yoctoproject.org
> >Subject: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree
> >for omap-a15
> >
> >* Override SRC_URI to use TI's tree at
> >https://git.ti.com/glsdk/libdrm
> >  This tree includes patches on top of the upstream libdrm for
> >  omap5 and dra7xx class of devices.
> >
> >Signed-off-by: Mrinmayee Hingolikar <mrinmayee@ti.com>
> >Signed-off-by: Siddharth Heroor <heroor@ti.com>
> >---
> > recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
> > 1 files changed, 15 insertions(+), 0 deletions(-)
> > create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb
> >
> >diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-
> >graphics/drm/libdrm_2.4.41.bb
> >new file mode 100644
> >index 0000000..31f7cee
> >--- /dev/null
> >+++ b/recipes-graphics/drm/libdrm_2.4.41.bb
> 
> I thought you were going to bbappend this instead of overlaying the whole 
> recipe.

I was confused at first as well, but I guess it should be fine, considering 
there's no 2.4.41 version to bbapend anyway.


> >@@ -0,0 +1,15 @@
> >+require recipes-graphics/drm/libdrm.inc
> >+
> >+COMPATIBLE_MACHINE = "omap-a15"
> >+
> >+DEFAULT_PREFERENCE = "-1"
> >+
> >+EXTRA_OECONF += "--enable-omap-experimental-api"
> >+
> >+SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
> >+SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
> >+
> >+# Append to the PR so that a new SRCREV will cause a rebuild
> >+PR_append = "a+gitr${SRCPV}"
> 
> I always had issue with this.  I'm not sure that this statement holds true 
> because whether a new SRCREV will cause a rebuild would depend on whether 
> that SRCREV sorts higher than the old one.  Unless something else has 
> changed.  This is useful though if you want to know what SRCREV was used for 
> a build.

Well, if every time you update SRCREV you also increment the first letter, it 
will work as expected - so the comment is kind of correct... :)


> That being said if you were going to overlay this recipe the PR should be 
> something like
> 
> PR = "${INC_PR}.0"
> 
> Right now you are appending to the default since PR is not defined.  With a 
> bbappend you should append a -arago flag.
> 
> So this comes back to why no bbappend?  Is it because the base version in 
> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git version of 
> the recipe and update the PV appropriately?
> 
> >+
> >+S = "${WORKDIR}/git"
> >--
> >1.7.0.4
> >
> >_______________________________________________
> >meta-ti mailing list
> >meta-ti@yoctoproject.org
> >https://lists.yoctoproject.org/listinfo/meta-ti
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Siddharth Heroor]

On 6/28/2013 12:47 AM, Denys Dmytriyenko wrote:
> On Thu, Jun 27, 2013 at 05:46:43PM +0000, Maupin, Chase wrote:
>>> -----Original Message-----
>>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>>> bounces@yoctoproject.org] On Behalf Of Heroor, Siddharth
>>> Sent: Thursday, June 27, 2013 12:17 PM
>>> To: meta-ti@yoctoproject.org
>>> Subject: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree
>>> for omap-a15
>>>
>>> * Override SRC_URI to use TI's tree at
>>> https://git.ti.com/glsdk/libdrm
>>>  This tree includes patches on top of the upstream libdrm for
>>>  omap5 and dra7xx class of devices.
>>>
>>> Signed-off-by: Mrinmayee Hingolikar <mrinmayee@ti.com>
>>> Signed-off-by: Siddharth Heroor <heroor@ti.com>
>>> ---
>>> recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
>>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>> create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb
>>>
>>> diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-
>>> graphics/drm/libdrm_2.4.41.bb
>>> new file mode 100644
>>> index 0000000..31f7cee
>>> --- /dev/null
>>> +++ b/recipes-graphics/drm/libdrm_2.4.41.bb
>>
>> I thought you were going to bbappend this instead of overlaying the whole 
>> recipe.
> 
> I was confused at first as well, but I guess it should be fine, considering 
> there's no 2.4.41 version to bbapend anyway.

Sorry about that. The original code we were working on was a .bbappend
to override recipes-graphics/drm/libdrm_git. However, the latest version
in oe-core on danny is 2.4.39 and master is 2.4.45. I chose to use
libdrm_2.4.41.bb because that's easier to read for me :-)

> 
> 
>>> @@ -0,0 +1,15 @@
>>> +require recipes-graphics/drm/libdrm.inc
>>> +
>>> +COMPATIBLE_MACHINE = "omap-a15"
>>> +
>>> +DEFAULT_PREFERENCE = "-1"
>>> +
>>> +EXTRA_OECONF += "--enable-omap-experimental-api"
>>> +
>>> +SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
>>> +SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
>>> +
>>> +# Append to the PR so that a new SRCREV will cause a rebuild
>>> +PR_append = "a+gitr${SRCPV}"
>>
>> I always had issue with this.  I'm not sure that this statement holds true 
>> because whether a new SRCREV will cause a rebuild would depend on whether 
>> that SRCREV sorts higher than the old one.  Unless something else has 
>> changed.  This is useful though if you want to know what SRCREV was used for 
>> a build.
> 
> Well, if every time you update SRCREV you also increment the first letter, it 
> will work as expected - so the comment is kind of correct... :)
>

Right, I just followed the existing kernel recipes for convention. Would
the convention change between a kernel recipe (like
recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both SRCPV
and the first letter, compared to userspace recipes which point to git
trees for versions?


> 
>> That being said if you were going to overlay this recipe the PR should be 
>> something like
>>
>> PR = "${INC_PR}.0"
>>
>> Right now you are appending to the default since PR is not defined.  With a 
>> bbappend you should append a -arago flag.
>>
>> So this comes back to why no bbappend?  Is it because the base version in 
>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git version of 
>> the recipe and update the PV appropriately?
>>

That's also possible but the question I have is what's the preferred
convention?

All the GLSDK trees are on git. The choice really is between having a
since .bbappend for each of the trees with an explicit PV and bump the
PV everytime we update to latest on upstream *OR* have a recipe for the
version and submit a new recipe when we update to latest.

I can submit a v2 once I understand the expected convention to be followed.

>>> +
>>> +S = "${WORKDIR}/git"
>>> --
>>> 1.7.0.4
>>>
>>> _______________________________________________
>>> meta-ti mailing list
>>> meta-ti@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-ti
>> _______________________________________________
>> meta-ti mailing list
>> meta-ti@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-ti

Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Siddharth Heroor]

On 6/28/2013 2:46 PM, Siddharth Heroor wrote:
> On 6/28/2013 12:47 AM, Denys Dmytriyenko wrote:
>> On Thu, Jun 27, 2013 at 05:46:43PM +0000, Maupin, Chase wrote:
>>>> -----Original Message-----
>>>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>>>> bounces@yoctoproject.org] On Behalf Of Heroor, Siddharth
>>>> Sent: Thursday, June 27, 2013 12:17 PM
>>>> To: meta-ti@yoctoproject.org
>>>> Subject: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree
>>>> for omap-a15
>>>>
>>>> * Override SRC_URI to use TI's tree at
>>>> https://git.ti.com/glsdk/libdrm
>>>>  This tree includes patches on top of the upstream libdrm for
>>>>  omap5 and dra7xx class of devices.
>>>>
>>>> Signed-off-by: Mrinmayee Hingolikar <mrinmayee@ti.com>
>>>> Signed-off-by: Siddharth Heroor <heroor@ti.com>
>>>> ---
>>>> recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
>>>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>>> create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb
>>>>
>>>> diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-
>>>> graphics/drm/libdrm_2.4.41.bb
>>>> new file mode 100644
>>>> index 0000000..31f7cee
>>>> --- /dev/null
>>>> +++ b/recipes-graphics/drm/libdrm_2.4.41.bb
>>>
>>> I thought you were going to bbappend this instead of overlaying the whole 
>>> recipe.
>>
>> I was confused at first as well, but I guess it should be fine, considering 
>> there's no 2.4.41 version to bbapend anyway.
> 
> Sorry about that. The original code we were working on was a .bbappend
> to override recipes-graphics/drm/libdrm_git. However, the latest version
> in oe-core on danny is 2.4.39 and master is 2.4.45. I chose to use
> libdrm_2.4.41.bb because that's easier to read for me :-)
> 
>>
>>
>>>> @@ -0,0 +1,15 @@
>>>> +require recipes-graphics/drm/libdrm.inc
>>>> +
>>>> +COMPATIBLE_MACHINE = "omap-a15"
>>>> +
>>>> +DEFAULT_PREFERENCE = "-1"
>>>> +
>>>> +EXTRA_OECONF += "--enable-omap-experimental-api"
>>>> +
>>>> +SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
>>>> +SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
>>>> +
>>>> +# Append to the PR so that a new SRCREV will cause a rebuild
>>>> +PR_append = "a+gitr${SRCPV}"
>>>
>>> I always had issue with this.  I'm not sure that this statement holds true 
>>> because whether a new SRCREV will cause a rebuild would depend on whether 
>>> that SRCREV sorts higher than the old one.  Unless something else has 
>>> changed.  This is useful though if you want to know what SRCREV was used for 
>>> a build.
>>
>> Well, if every time you update SRCREV you also increment the first letter, it 
>> will work as expected - so the comment is kind of correct... :)
>>
> 
> Right, I just followed the existing kernel recipes for convention. Would
> the convention change between a kernel recipe (like
> recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both SRCPV
> and the first letter, compared to userspace recipes which point to git
> trees for versions?
> 
> 
>>
>>> That being said if you were going to overlay this recipe the PR should be 
>>> something like
>>>
>>> PR = "${INC_PR}.0"
>>>
>>> Right now you are appending to the default since PR is not defined.  With a 
>>> bbappend you should append a -arago flag.
>>>
>>> So this comes back to why no bbappend?  Is it because the base version in 
>>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git version of 
>>> the recipe and update the PV appropriately?
>>>
> 
> That's also possible but the question I have is what's the preferred
> convention?
> 
> All the GLSDK trees are on git. The choice really is between having a
> since .bbappend for each of the trees with an explicit PV and bump the
> PV everytime we update to latest on upstream *OR* have a recipe for the
> version and submit a new recipe when we update to latest.

Sorry. My typing went haywire...

What I mean is I can resubmit _git.bbappend. Its really whatever
convention you would suggest we follow. All the recipes that we have are
on git (except for a couple of binary blobs).

Do you think we should use _git.bbappend (or _git.bb as the case maybe)?
In that case, we only 1 recipe to maintain per software package and we
fix the PV in it.

> 
> I can submit a v2 once I understand the expected convention to be followed.
> 

Let me know the approach to take, I'll submit new patches if required.

>>>> +
>>>> +S = "${WORKDIR}/git"
>>>> --
>>>> 1.7.0.4
>>>>
>>>> _______________________________________________
>>>> meta-ti mailing list
>>>> meta-ti@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-ti
>>> _______________________________________________
>>> meta-ti mailing list
>>> meta-ti@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-ti
> 

Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Maupin, Chase]

>-----Original Message-----
>From: Heroor, Siddharth
>Sent: Friday, June 28, 2013 4:17 AM
>To: Dmytriyenko, Denys
>Cc: Maupin, Chase; meta-ti@yoctoproject.org
>Subject: Re: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging
>tree for omap-a15
>
>On 6/28/2013 12:47 AM, Denys Dmytriyenko wrote:
>> On Thu, Jun 27, 2013 at 05:46:43PM +0000, Maupin, Chase wrote:
>>>> -----Original Message-----
>>>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>>>> bounces@yoctoproject.org] On Behalf Of Heroor, Siddharth
>>>> Sent: Thursday, June 27, 2013 12:17 PM
>>>> To: meta-ti@yoctoproject.org
>>>> Subject: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging
>tree
>>>> for omap-a15
>>>>
>>>> * Override SRC_URI to use TI's tree at
>>>> https://git.ti.com/glsdk/libdrm
>>>>  This tree includes patches on top of the upstream libdrm for
>>>>  omap5 and dra7xx class of devices.
>>>>
>>>> Signed-off-by: Mrinmayee Hingolikar <mrinmayee@ti.com>
>>>> Signed-off-by: Siddharth Heroor <heroor@ti.com>
>>>> ---
>>>> recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
>>>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>>> create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb
>>>>
>>>> diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-
>>>> graphics/drm/libdrm_2.4.41.bb
>>>> new file mode 100644
>>>> index 0000000..31f7cee
>>>> --- /dev/null
>>>> +++ b/recipes-graphics/drm/libdrm_2.4.41.bb
>>>
>>> I thought you were going to bbappend this instead of overlaying
>the whole
>>> recipe.
>>
>> I was confused at first as well, but I guess it should be fine,
>considering
>> there's no 2.4.41 version to bbapend anyway.
>
>Sorry about that. The original code we were working on was a
>.bbappend
>to override recipes-graphics/drm/libdrm_git. However, the latest
>version
>in oe-core on danny is 2.4.39 and master is 2.4.45. I chose to use
>libdrm_2.4.41.bb because that's easier to read for me :-)
>
>>
>>
>>>> @@ -0,0 +1,15 @@
>>>> +require recipes-graphics/drm/libdrm.inc
>>>> +
>>>> +COMPATIBLE_MACHINE = "omap-a15"
>>>> +
>>>> +DEFAULT_PREFERENCE = "-1"
>>>> +
>>>> +EXTRA_OECONF += "--enable-omap-experimental-api"
>>>> +
>>>> +SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
>>>> +SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
>>>> +
>>>> +# Append to the PR so that a new SRCREV will cause a rebuild
>>>> +PR_append = "a+gitr${SRCPV}"
>>>
>>> I always had issue with this.  I'm not sure that this statement
>holds true
>>> because whether a new SRCREV will cause a rebuild would depend
>on whether
>>> that SRCREV sorts higher than the old one.  Unless something
>else has
>>> changed.  This is useful though if you want to know what SRCREV
>was used for
>>> a build.
>>
>> Well, if every time you update SRCREV you also increment the
>first letter, it
>> will work as expected - so the comment is kind of correct... :)
>>
>
>Right, I just followed the existing kernel recipes for convention.
>Would
>the convention change between a kernel recipe (like
>recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both
>SRCPV
>and the first letter, compared to userspace recipes which point to
>git
>trees for versions?

The kernel ones were to append the MACHINE_KERNEL_PR that was set with the letter.  The SRCPV use was also nice to make it easier to know which commitid was being used during the kernel build.

>
>
>>
>>> That being said if you were going to overlay this recipe the PR
>should be
>>> something like
>>>
>>> PR = "${INC_PR}.0"
>>>
>>> Right now you are appending to the default since PR is not
>defined.  With a
>>> bbappend you should append a -arago flag.
>>>
>>> So this comes back to why no bbappend?  Is it because the base
>version in
>>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git
>version of
>>> the recipe and update the PV appropriately?
>>>
>
>That's also possible but the question I have is what's the
>preferred
>convention?
>
>All the GLSDK trees are on git. The choice really is between
>having a
>since .bbappend for each of the trees with an explicit PV and bump
>the
>PV everytime we update to latest on upstream *OR* have a recipe
>for the
>version and submit a new recipe when we update to latest.
>
>I can submit a v2 once I understand the expected convention to be
>followed.

I get your point on clarity so I'm OK with a version specific addition.  You may have answered this before but what is the difference between your libdrm and the libdrm upstream?  Are your patches going upstream to the main libdrm so that going forward you can drop this recipe for a new version?

Denys, refresh my memory if we are doing a version but we are also changing things in our trees don't we normally do this as something like ti-libdrm and set the PROVIDES, etc for libdrm?  This was to distinguish between libdrv 2.4.41 for example and what TI is calling 2.4.41 right?  Or do you just want to do 2.4.41+?  What is your preferrence? 

Sidd, going the non _git route see my other input then about PR, etc.

>
>>>> +
>>>> +S = "${WORKDIR}/git"
>>>> --
>>>> 1.7.0.4
>>>>
>>>> _______________________________________________
>>>> meta-ti mailing list
>>>> meta-ti@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-ti
>>> _______________________________________________
>>> meta-ti mailing list
>>> meta-ti@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-ti

Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Siddharth Heroor]

On 6/28/2013 4:55 PM, Maupin, Chase wrote:
> 
>> -----Original Message-----
>> From: Heroor, Siddharth
>> Sent: Friday, June 28, 2013 4:17 AM
>> To: Dmytriyenko, Denys
>> Cc: Maupin, Chase; meta-ti@yoctoproject.org
>> Subject: Re: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging
>> tree for omap-a15
>>
>> On 6/28/2013 12:47 AM, Denys Dmytriyenko wrote:
>>> On Thu, Jun 27, 2013 at 05:46:43PM +0000, Maupin, Chase wrote:
>>>>> -----Original Message-----
>>>>> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
>>>>> bounces@yoctoproject.org] On Behalf Of Heroor, Siddharth
>>>>> Sent: Thursday, June 27, 2013 12:17 PM
>>>>> To: meta-ti@yoctoproject.org
>>>>> Subject: [meta-ti] [PATCH] libdrm: Add GLSDK specific staging
>> tree
>>>>> for omap-a15
>>>>>
>>>>> * Override SRC_URI to use TI's tree at
>>>>> https://git.ti.com/glsdk/libdrm
>>>>>  This tree includes patches on top of the upstream libdrm for
>>>>>  omap5 and dra7xx class of devices.
>>>>>
>>>>> Signed-off-by: Mrinmayee Hingolikar <mrinmayee@ti.com>
>>>>> Signed-off-by: Siddharth Heroor <heroor@ti.com>
>>>>> ---
>>>>> recipes-graphics/drm/libdrm_2.4.41.bb |   15 +++++++++++++++
>>>>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>>>> create mode 100644 recipes-graphics/drm/libdrm_2.4.41.bb
>>>>>
>>>>> diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-
>>>>> graphics/drm/libdrm_2.4.41.bb
>>>>> new file mode 100644
>>>>> index 0000000..31f7cee
>>>>> --- /dev/null
>>>>> +++ b/recipes-graphics/drm/libdrm_2.4.41.bb
>>>>
>>>> I thought you were going to bbappend this instead of overlaying
>> the whole
>>>> recipe.
>>>
>>> I was confused at first as well, but I guess it should be fine,
>> considering
>>> there's no 2.4.41 version to bbapend anyway.
>>
>> Sorry about that. The original code we were working on was a
>> .bbappend
>> to override recipes-graphics/drm/libdrm_git. However, the latest
>> version
>> in oe-core on danny is 2.4.39 and master is 2.4.45. I chose to use
>> libdrm_2.4.41.bb because that's easier to read for me :-)
>>
>>>
>>>
>>>>> @@ -0,0 +1,15 @@
>>>>> +require recipes-graphics/drm/libdrm.inc
>>>>> +
>>>>> +COMPATIBLE_MACHINE = "omap-a15"
>>>>> +
>>>>> +DEFAULT_PREFERENCE = "-1"
>>>>> +
>>>>> +EXTRA_OECONF += "--enable-omap-experimental-api"
>>>>> +
>>>>> +SRC_URI = "git://git.ti.com/glsdk/libdrm.git;protocol=git"
>>>>> +SRCREV = "3cb5405084111193cedb8796d259b56560b088f0"
>>>>> +
>>>>> +# Append to the PR so that a new SRCREV will cause a rebuild
>>>>> +PR_append = "a+gitr${SRCPV}"
>>>>
>>>> I always had issue with this.  I'm not sure that this statement
>> holds true
>>>> because whether a new SRCREV will cause a rebuild would depend
>> on whether
>>>> that SRCREV sorts higher than the old one.  Unless something
>> else has
>>>> changed.  This is useful though if you want to know what SRCREV
>> was used for
>>>> a build.
>>>
>>> Well, if every time you update SRCREV you also increment the
>> first letter, it
>>> will work as expected - so the comment is kind of correct... :)
>>>
>>
>> Right, I just followed the existing kernel recipes for convention.
>> Would
>> the convention change between a kernel recipe (like
>> recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both
>> SRCPV
>> and the first letter, compared to userspace recipes which point to
>> git
>> trees for versions?
> 
> The kernel ones were to append the MACHINE_KERNEL_PR that was set with the letter.  The SRCPV use was also nice to make it easier to know which commitid was being used during the kernel build.
> 
>>
>>
>>>
>>>> That being said if you were going to overlay this recipe the PR
>> should be
>>>> something like
>>>>
>>>> PR = "${INC_PR}.0"
>>>>
>>>> Right now you are appending to the default since PR is not
>> defined.  With a
>>>> bbappend you should append a -arago flag.
>>>>
>>>> So this comes back to why no bbappend?  Is it because the base
>> version in
>>>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git
>> version of
>>>> the recipe and update the PV appropriately?
>>>>
>>
>> That's also possible but the question I have is what's the
>> preferred
>> convention?
>>
>> All the GLSDK trees are on git. The choice really is between
>> having a
>> since .bbappend for each of the trees with an explicit PV and bump
>> the
>> PV everytime we update to latest on upstream *OR* have a recipe
>> for the
>> version and submit a new recipe when we update to latest.
>>
>> I can submit a v2 once I understand the expected convention to be
>> followed.
> 
> I get your point on clarity so I'm OK with a version specific addition.  You may have answered this before but what is the difference between your libdrm and the libdrm upstream?  Are your patches going upstream to the main libdrm so that going forward you can drop this recipe for a new version?

We should. It's on the backlog ;-)

Right now the focus is to have our software on meta-ti.

> 
> Denys, refresh my memory if we are doing a version but we are also changing things in our trees don't we normally do this as something like ti-libdrm and set the PROVIDES, etc for libdrm?  This was to distinguish between libdrv 2.4.41 for example and what TI is calling 2.4.41 right?  Or do you just want to do 2.4.41+?  What is your preferrence? 
> 
> Sidd, going the non _git route see my other input then about PR, etc.

Agreed. I'll send v2 with PR = "${INC_PR}.0".

> 
>>
>>>>> +
>>>>> +S = "${WORKDIR}/git"
>>>>> --
>>>>> 1.7.0.4
>>>>>
>>>>> _______________________________________________
>>>>> meta-ti mailing list
>>>>> meta-ti@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/meta-ti
>>>> _______________________________________________
>>>> meta-ti mailing list
>>>> meta-ti@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-ti
> 

Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Denys Dmytriyenko]

On Fri, Jun 28, 2013 at 07:25:04AM -0400, Maupin, Chase wrote:
> 
> >> Well, if every time you update SRCREV you also increment the
> >first letter, it
> >> will work as expected - so the comment is kind of correct... :)
> >>
> >
> >Right, I just followed the existing kernel recipes for convention.
> >Would
> >the convention change between a kernel recipe (like
> >recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both
> >SRCPV
> >and the first letter, compared to userspace recipes which point to
> >git
> >trees for versions?
> 
> The kernel ones were to append the MACHINE_KERNEL_PR that was set with the 
> letter.  The SRCPV use was also nice to make it easier to know which 
> commitid was being used during the kernel build.
> 
> >>> That being said if you were going to overlay this recipe the PR
> >should be
> >>> something like
> >>>
> >>> PR = "${INC_PR}.0"
> >>>
> >>> Right now you are appending to the default since PR is not
> >defined.  With a
> >>> bbappend you should append a -arago flag.
> >>>
> >>> So this comes back to why no bbappend?  Is it because the base
> >version in
> >>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git
> >version of
> >>> the recipe and update the PV appropriately?
> >>>
> >
> >That's also possible but the question I have is what's the
> >preferred
> >convention?
> >
> >All the GLSDK trees are on git. The choice really is between
> >having a
> >since .bbappend for each of the trees with an explicit PV and bump
> >the
> >PV everytime we update to latest on upstream *OR* have a recipe
> >for the
> >version and submit a new recipe when we update to latest.
> >
> >I can submit a v2 once I understand the expected convention to be
> >followed.
> 
> I get your point on clarity so I'm OK with a version specific addition.  You 
> may have answered this before but what is the difference between your libdrm 
> and the libdrm upstream?  Are your patches going upstream to the main libdrm 
> so that going forward you can drop this recipe for a new version?
> 
> Denys, refresh my memory if we are doing a version but we are also changing 
> things in our trees don't we normally do this as something like ti-libdrm 
> and set the PROVIDES, etc for libdrm?  This was to distinguish between 
> libdrv 2.4.41 for example and what TI is calling 2.4.41 right?  Or do you 
> just want to do 2.4.41+?  What is your preferrence?

From my past discussions with Nicolas, TI's libdrm is quite close to the 
upstream and the patches are meant to be upstreamed eventually. So, 
technically it's not a complete fork and having a full replacement like 
ti-libdrm is not really necessary here. I'm fine with providing own 
libdrm-2.4.41 recipe for now.

-- 
Denys