[Mesa-stable] [pull 10.2] backport more freedreno fixes plus on xa fix

[Rob Clark]

On Fri, Jul 4, 2014 at 12:42 AM, Carl Worth <cworth at cworth.org> wrote:
> Rob Clark <robdclark at gmail.com> writes:
>> Backport last round of piglit fixes to 10.2.  These have been soaking
>> on master for a couple weeks, and I've not found any regression yet.
>> And they get us from 80% pass up to nearly 83% pass, so a bit more
>> progress in the right direction.  (For reference, at end of Feb we
>> were at 50% pass ;-))
>>
>> Also, one XA patch to fix a segfault (also been on master for a
>> while).
>
> Thanks, Rob!
>
> I've now pushed my own version of all of these out to the 10.2 branch.
>
> I didn't pull in your branch directly, since that's not the way we
> generally do things with the stable branch.
>
> Instead, what we like to do is to cherry-pick each change over from the
> master branch. (That's likely what you had done in each case, but you
> didn't have the "cherry picked from" text that we get with "git
> cherry-pick -x").
>
> Anyway, so what I did here was to match each commit from your branch
> with the corresponding commit on master, and I ran "git cherry-pick -x"
> on each of those. (In the one case where a commit didn't pick cleanly, I
> used the version from your branch, but still left the "cherry picked
> from" text in the commit message).
>
> So, in the future, it will probably be easier for both of us if you can
> just email a list of commit IDs of patches on master that should be
> cherry-picked. (Or, of course, you can use the CC syntax in the commit
> message to automatically nominate things for the stable branch).

sure, I can send a list of commit-id's instead..  I generally like to
let things soak on master for at least a week or two to be safe,
before sending for stable branch

> Finally, we do like to keep the stable branches cleanly as
> one-commit-per-bug-fix. We'll even go out of our way to squash together
> a couple of commits from the master branch, (for example, when one
> commit is a bug fix, and then subsequently there's a fix for that fix,
> etc.).
>
> The several commits you have for "update generated headers" violate that
> rule, (since none of these commits are bug fixes). I was tempted to
> squash these into other patches, but I wasn't sure I would get the
> dependencies right, (would it be the preceding commit in every case?).

yeah, at least on master I'd been keeping the auto-generated updates
separate (since they are easy to re-do if conflict or whatever).  The
only human intervention on those patches is if something needed to
keep things compiling (like if a register or bitfield was renamed).

If you wanted to squash, then it would be the following patch to
squash them into.

> I am more willing to bend the stable branch rules for a series of
> commits that only touch the code within one driver. So that's what I've
> done here. But it would be even nicer not to have to do this in the
> future.

ok, well now that I know what to do..

I guess next time if there is much squashing needed, I can give you a
branch, otherwise a list of commit-ids?  Or you would you just prefer
list of commit-ids plus instructions about what to squash?

> What is the header-generation step about? Would there be a reasonable
> way to make that a part of the build process so that these files
> wouldn't be in git and we wouldn't have these commits in the future?

Well, it would introduce a dependency on envytools stuff..  and at the
moment, a slightly different envytools from nouveau.  I kinda suspect
making it part of the build process would be annoying for others.
Plus, occasionally there might be small tweaks needed.

BR,
-R

> That's maybe something to think about at least.
>
> So take a look at what I just pushed to the 10.2 branch and please let
> me know if I botched anything.
>
> -Carl
>
> --
> carl.d.worth at intel.com