Hi Linus,
Dave is on vacation at the moment, so please pull these fixes directly. Just a few minor things for 4.2: - add a new radeon pci id - fix a power management regression in amdgpu - fix HEVC command buffer validation in amdgpu
The following changes since commit 58ccab91342c1cc1fe08da9b198ac5d763706c2e:
Merge tag 'localmodconfig-v4.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-kconfig (2015-08-11 15:13:41 -0700)
are available in the git repository at:
git://people.freedesktop.org/~agd5f/linux drm-fixes-4.2
for you to fetch changes up to e037239e5e7b61007763984aa35a8329596d8c88:
drm/radeon: add new OLAND pci id (2015-08-12 12:24:05 -0400)
---------------------------------------------------------------- Alex Deucher (2): Revert "drm/amdgpu: Configure doorbell to maximum slots" drm/radeon: add new OLAND pci id
Boyuan Zhang (1): drm/amdgpu: add context buffer size check for HEVC
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 17 ++++++++++++++--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +- include/drm/drm_pciids.h | 1 + 3 files changed, 16 insertions(+), 4 deletions(-)
On Wed, Aug 12, 2015 at 10:46 AM, Alex Deucher alexdeucher@gmail.com wrote:
Dave is on vacation at the moment, so please pull these fixes directly. Just a few minor things for 4.2:
So I've pulled this, but I'm noticing a very alarming pattern in your pull requests: the commits are clearly generated just before the request, and have presumably had basically no testing at all. S
Gaah. I should have marked some of my longer emails on best git practices. Maybe somebody else bookmarked them>
Are you constantly rebasing? If so, why?
I presume that this is your normal behavior, and it's just that Dave has never tried to correct that workflow. I've written about a million emails about proper git flow, so I'm only exposed to this directly now that Dave is on vacation. I notice that the whole "commits generated just before pull request" seems to have been true for the last pull request too (tip of your tree: Wed Aug 5 14:26:50 2015, email asking me to pull: Wed, 5 Aug 2015 16:42:21).
Maybe these commits had testing somewhere else. It's definitely not obvious from the pull requests and the git history, though.
Linus
On Wed, Aug 12, 2015 at 2:52 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Aug 12, 2015 at 10:46 AM, Alex Deucher alexdeucher@gmail.com wrote:
Dave is on vacation at the moment, so please pull these fixes directly. Just a few minor things for 4.2:
So I've pulled this, but I'm noticing a very alarming pattern in your pull requests: the commits are clearly generated just before the request, and have presumably had basically no testing at all. S
Gaah. I should have marked some of my longer emails on best git practices. Maybe somebody else bookmarked them>
Are you constantly rebasing? If so, why?
I presume that this is your normal behavior, and it's just that Dave has never tried to correct that workflow. I've written about a million emails about proper git flow, so I'm only exposed to this directly now that Dave is on vacation. I notice that the whole "commits generated just before pull request" seems to have been true for the last pull request too (tip of your tree: Wed Aug 5 14:26:50 2015, email asking me to pull: Wed, 5 Aug 2015 16:42:21).
Maybe these commits had testing somewhere else. It's definitely not obvious from the pull requests and the git history, though.
I always rebase my pull requests against Dave's drm-fixes tree before I send a pull request. Since he's out of town I rebased against your tree. I didn't realize that was not the preferred model. I thought it was preferred to fix up any possible conflicts that may arise from other changes in the subsystem tree (although are pretty unlikely).
Alex
On Wed, Aug 12, 2015 at 12:10 PM, Alex Deucher alexdeucher@gmail.com wrote:
I always rebase my pull requests against Dave's drm-fixes tree before I send a pull request. Since he's out of town I rebased against your tree. I didn't realize that was not the preferred model. I thought it was preferred to fix up any possible conflicts that may arise from other changes in the subsystem tree (although are pretty unlikely).
Yes, absolutely not. Rebasing generally doesn't fix up any conflicts, it just means that you're moving to a new base and throwing away a lot of the testing you did.
Generally, the preferred model is:
- strive to base your development on a well-characterized base (for example, a previous release), and _stay_ on that base (ie don't get distracted by what other unrelated development projects are doing).
- do *not* rebase of pull from upstream (Dave or me), particularly durign the merge window, since all you are doing is just bringing in development work that is entirely irrelevant to _your_ development work, and potential instabilities from other sources.
The only real reason to ever rebase is if your code and testing is being impacted by bugs or lack of features that the rebasing fixes - iow you actively need the rebase in order to make progress on development and testing. Otherwise, rebasing only hurts.
You do generally want to make sure you don't stay *too* far behind, of course, and rebasing can be the solution to that, but that's very much not a "before sending a pull request" thing, because now you've lost the "this has been tested extensively" advantage (which I obviously _hope_ you had at some point). And "too far behind" is more about to "two releases behind" than "yesterday's tree" kind of behind.
So by all means rebase, but rebase to clean up ugly history, or to get a better base for development. Both of which are good things. But when you do that, realize that it means you are cleaning up and to some degree starting from scratch, so it's now a *new* base for testing and development, not a "let's send this upstream immediately".
I hate pulling stuff that I can see has not been well tested. I want to at least be able to fool myself into thinking that downstream has really worked hard at validating what they send me.
Yeah, yeah, I realize that not everything I get is well tested. I'm not _entirely_ delusional. But please let me at least have that small hope that what I pulled saw some testing, ok?
And like always: there are very few totally black-and-white rules. Sometimes rebasing before sending stuff to me is valid: you realize there was some bad problem you want to fix up, and the downsides of rebasing are smaller than the upsides. But while rebasing before sending things upstream _can_ be valid, it definitely shouldn't be the "normal development model".
Linus
On Wed, Aug 12, 2015 at 3:35 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Aug 12, 2015 at 12:10 PM, Alex Deucher alexdeucher@gmail.com wrote:
I always rebase my pull requests against Dave's drm-fixes tree before I send a pull request. Since he's out of town I rebased against your tree. I didn't realize that was not the preferred model. I thought it was preferred to fix up any possible conflicts that may arise from other changes in the subsystem tree (although are pretty unlikely).
Yes, absolutely not. Rebasing generally doesn't fix up any conflicts, it just means that you're moving to a new base and throwing away a lot of the testing you did.
Generally, the preferred model is:
- strive to base your development on a well-characterized base (for
example, a previous release), and _stay_ on that base (ie don't get distracted by what other unrelated development projects are doing).
- do *not* rebase of pull from upstream (Dave or me), particularly
durign the merge window, since all you are doing is just bringing in development work that is entirely irrelevant to _your_ development work, and potential instabilities from other sources.
The only real reason to ever rebase is if your code and testing is being impacted by bugs or lack of features that the rebasing fixes - iow you actively need the rebase in order to make progress on development and testing. Otherwise, rebasing only hurts.
You do generally want to make sure you don't stay *too* far behind, of course, and rebasing can be the solution to that, but that's very much not a "before sending a pull request" thing, because now you've lost the "this has been tested extensively" advantage (which I obviously _hope_ you had at some point). And "too far behind" is more about to "two releases behind" than "yesterday's tree" kind of behind.
So by all means rebase, but rebase to clean up ugly history, or to get a better base for development. Both of which are good things. But when you do that, realize that it means you are cleaning up and to some degree starting from scratch, so it's now a *new* base for testing and development, not a "let's send this upstream immediately".
I hate pulling stuff that I can see has not been well tested. I want to at least be able to fool myself into thinking that downstream has really worked hard at validating what they send me.
Yeah, yeah, I realize that not everything I get is well tested. I'm not _entirely_ delusional. But please let me at least have that small hope that what I pulled saw some testing, ok?
And like always: there are very few totally black-and-white rules. Sometimes rebasing before sending stuff to me is valid: you realize there was some bad problem you want to fix up, and the downsides of rebasing are smaller than the upsides. But while rebasing before sending things upstream _can_ be valid, it definitely shouldn't be the "normal development model".
Ok, thanks. I'll keep that in mind going forward. Any yes, these patches have been tested fairly extensively inside AMD.
Alex
On Wed, Aug 12, 2015 at 12:35 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
Generally, the preferred model is:
- strive to base your development on a well-characterized base (for
example, a previous release), and _stay_ on that base (ie don't get distracted by what other unrelated development projects are doing).
- do *not* rebase of pull from upstream (Dave or me), particularly
durign the merge window, since all you are doing is just bringing in development work that is entirely irrelevant to _your_ development work, and potential instabilities from other sources.
Just to clarify: in many ways, rebasing and "back merges" (ie downstream developers pulling from upstream) are almost indistinguishable wrt the downsides. Both bring random upstream development into a downstream project. Both should be done very carefully, and there should always be a very clear _reason_ for why a rebase or back-merge is done and why that particular upstream point was rebased upon or back-merged (and in the case of a back-merge, please _document_ that reason in the merge message itself).
Back-merges have their own set of problems - they can make the history much harder to read, and having multiple merge bases can result in interesting effects (like making the diff statistics for "git request-pull" be garbage). Of course, rebasing - while generally keeping the history cleaner - has its own problems too, and makes it hard or impossible for people to work together if you have some shared development. So rebasing and back merging are very different, but at the same time they do share some of the same problems, and generally it's better the less of either that a development tree needs.
Linus
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Linus Torvalds