[GDP][PATCH 0/2] Enable multimedia acceleration by default

Stephen Lawrence stephen.lawrence at renesas.com
Mon Jan 11 15:03:27 EST 2016

Hi Tom,

> -----Original Message-----
> From: Tom Pollard [mailto:tom.pollard at codethink.co.uk]
> Sent: 11 January 2016 15:33
> To: Stephen Lawrence <stephen.lawrence at renesas.com>
> Cc: genivi-projects at lists.genivi.org
> Subject: Re: [GDP][PATCH 0/2] Enable multimedia acceleration by default
> Hi Stephen, hope you had a good break.

Yes great thanks.

> On 08/01/16 17:33, Stephen Lawrence wrote:


> >
> > Any response to this patch series?
> I've managed to deploy the build today, and with a fresh build env I
> didn't get the same warnings as I posted last time (the pastebin has
> timed out now).

I had a quick look at the email history before posting, but now I see I was only looking at the 0/2 patch :)
I see I replied to you but as you say the pastebin is gone. From what I wrote it looks like it was a GDP build-dep
warning. If you have the warnings still around send them on and I will keep an eye out.

> I'm happy to push this, unless anyone can provide a reason not to?
> Will you also be providing a matching patchset specific for Koelsch?

I have not finally decided yet. The eval licensing for Koelsch and the other "Pro" Evaluation boards means
there is some advantages to sticking with gfx acceleration only by default,  as you have the option of using 
the gfx from the low cost board click-through licensing. It is not so clear cut for the multimedia.
So as GDP doesn't yet make much use of multimedia acceleration I may keep it off for the Eval boards by default 
until projects like GAAP make it more of a necessity. If a dev has the multimedia for the Evaluation boards then its straight 
forward to enable anyway. That said the reverse is also true :)

For the M2 Porter and E2 Silk Low Cost boards, then yes definitely gfx and multimedia enabled by default. 

> >
> > I'm ready to upstream GDP on the Renesas R-Car E2 Silk low cost board and it
> would be useful to know if there is any feedback.
> Awesome, I presume as another branch to GDP? I look forward to trying
> it! The only feedback I have in this case is that if the Silk for some
> reason requires changes to meta-genivi-demo.git, is that the patches as
> such allow the same commit to be built on all branches. This allows each
> branch of GDP to point to the HEAD of meta-genivi-demo and helps in
> maintenance.

Yes I'll create a branch. What have you found worked best when doing a variant if something
close to it is already available? Branch from the existing branch, make the needed changes and push 
the new branch, or start blank and add the submodules in? Obviously either is possible I just
wonder if you found submodules have some peculiarity that favours one over the other?

The only source change for GDP on Silk is a couple of lines to generalise the image package list
that currently references the Porter and Koelsch MACHINE to be for all R-Car Gen 2 boards.
That's a patch to meta-genivi-demo I will send first, but yes the same commit can be used by all.
Completely agree with the maintenance point.

It will be nice when we start tracking the HEADs. It can seem a bit of an anti-pattern sometimes
updating the git submodules step by step. Although that may in part be me getting more used to it.



More information about the genivi-projects mailing list