On 12-07-19 11:25 AM, Kamble, Nitin A wrote:
-----Original Message-----
From: Zanussi, Tom
Sent: Thursday, July 19, 2012 8:27 PM
To: Kamble, Nitin A
Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com
Subject: RE: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver
On Thu, 2012-07-19 at 07:39 -0700, Kamble, Nitin A wrote:
-----Original Message-----
From: Zanussi, Tom
Sent: Thursday, July 19, 2012 8:57 AM
To: Kamble, Nitin A
Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com
Subject: RE: [PATCH 0/1] meta: update crownbay.scc for newer emgd
driver
On Wed, 2012-07-18 at 19:58 -0700, Kamble, Nitin A wrote:
-----Original Message-----
From: Zanussi, Tom
Sent: Wednesday, July 18, 2012 7:43 PM
To: Kamble, Nitin A
Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com
Subject: Re: [PATCH 0/1] meta: update crownbay.scc for newer
emgd driver
On Mon, 2012-07-16 at 22:57 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble<nitin.a.kam...@intel.com>
This commit changes emgd kernel driver for crownbay bsp to the
emgd-
1.14.
Nitin,
Doesn't switching this over in the kenrnel require emgd-1.14
userspace recipe updates to work? Did I miss those?
Tom
Tom,
I am holding the emgd 1.14 userspace commits until the kernel
repository
change goes upstream. The kernel recipe will need new SRCREV (with
emgd
1.14 kernel parts) for the user level emgd 1.14 parts to work. And
that dependency will get satisfied once this commit is in.
Yeah, I understand, the crownbay is typically the most complicated
update for all of those reasons - simultaneous new kernel
version/recipe, new emgd branch, and new emgd userspace recipe all at
the same time.
In the past I've submitted them all at the same time for
simultaneous review and some coordination with Bruce - once the
kernel parts are in, the kernel recipe and the userspace parts can
then be pulled in along with a simple follow-on patch to update the
SRCREVs Bruce give us.
The thing is that if Bruce pulls in the patch to switch to emgd-1.14
and only at that point do you post the userspace recipe, and it ends
up needing some rework, in the meantime the graphics remain
non-functional (I know, they already are, thanks to the package
re-ordering patches breaking the current recipe, but hopefully the
1.14 changes will be in and we don't have to worry about it any more.).
Does that make sense, and can you just post the userspace and kernel
recipe parts before we give Bruce the go-ahead in making the kernel
changes? (I'd also like to try it out myself as well...).
Tom,
Until the crownbay bsp's Linux-yocto kernel recipe's meta SRCREV is
updated, these kernel repo changes have no effect in the build process.
Right ? So as I see, this commit does not make anything worst (or better).
I am sending the userland recipe commits anyway; So that you can also test
it out.
Right, but what if we have to update the meta SRCREV for a different reason
in the meantime (like we did last week for instance). We're then forced to
take the emgd commit as well.
I see the issue now. And I don't see a perfect solution to the issue. Because
of commits in two different repos there always going to be this kind of a sync
issue. The best is pull the commits in both repositories at the same time.
FYI: everything is staged and I have a SRCREV commit prepared for this.
When I hear a clear "yes" on the userspace changes, I can send the pull
request immediately.
Cheers,
Bruce
Thanks,
Nitin
In any case, it's your BSP so it's up to you how you want to manage it, I'm just
trying to save you and the users some headaches. It always made sense to
me to do it all at the same time, all else being equal...
Tom
Thanks,
Nitin
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
