[pull] radeon and amdgpu drm-fixes-4.2

[pull] radeon and amdgpu drm-fixes-4.2

[Alex Deucher]

Hi Dave,

radeon and amdgpu fixes for 4.2.  All over the place:
- fix cursor corruption on resume and re-enable no VT switch on suspend
- vblank fixes
- fix gpuvm error messages
- misc other fixes

The following changes since commit d6ac4ffc61ace6ed6f183e9fd7f207c0ddafb897:

  Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm (2015-07-07 15:19:09 -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 355c822847fa70fa1df6a7451b7ecf76116efcd2:

  drm/radeon: disable vce init on cayman (v2) (2015-07-09 11:40:12 -0400)

----------------------------------------------------------------
Alex Deucher (2):
      Revert "Revert "drm/radeon: dont switch vt on suspend""
      drm/radeon: disable vce init on cayman (v2)

Christian König (3):
      drm/radeon: allways add the VM clear duplicate
      drm/radeon: check if BO_VA is set before adding it to the invalidation list
      drm/amdgpu: fix timeout calculation

Dan Carpenter (1):
      drm/radeon: fix underflow in r600_cp_dispatch_texture()

Grigori Goronzy (4):
      drm/radeon: use RCU query for GEM_BUSY syscall
      drm/radeon: fix HDP flushing
      drm/radeon: default to 2048 MB GART size on SI+
      drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2)

Mario Kleiner (2):
      drm/radeon: Handle irqs only based on irq ring, not irq status regs.
      drm/amdgpu: Handle irqs only based on irq ring, not irq status regs.

Michel Dänzer (2):
      drm/radeon: Clean up reference counting and pinning of the cursor BOs
      drm/radeon: Fold radeon_set_cursor() into radeon_show_cursor()

 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  22 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  22 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  22 +-
 drivers/gpu/drm/radeon/cik.c            | 336 +++++++++++++++------------
 drivers/gpu/drm/radeon/evergreen.c      | 392 ++++++++++++++++++--------------
 drivers/gpu/drm/radeon/ni.c             |  25 +-
 drivers/gpu/drm/radeon/r600.c           | 155 +++++++------
 drivers/gpu/drm/radeon/r600_cp.c        |   2 +-
 drivers/gpu/drm/radeon/radeon_cursor.c  | 109 ++++-----
 drivers/gpu/drm/radeon/radeon_device.c  |  66 ++++--
 drivers/gpu/drm/radeon/radeon_fb.c      |   1 +
 drivers/gpu/drm/radeon/radeon_gem.c     |  12 +-
 drivers/gpu/drm/radeon/radeon_mode.h    |   1 -
 drivers/gpu/drm/radeon/radeon_vm.c      |  40 ++--
 drivers/gpu/drm/radeon/si.c             | 336 +++++++++++++++------------
 16 files changed, 871 insertions(+), 672 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon and amdgpu drm-fixes-4.2

[Linus Torvalds]

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 mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon and amdgpu drm-fixes-4.2

[Alex Deucher]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon and amdgpu drm-fixes-4.2

[Linus Torvalds]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon and amdgpu drm-fixes-4.2

[Alex Deucher]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon and amdgpu drm-fixes-4.2

[Linus Torvalds]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon and amdgpu drm-fixes-4.2

[Alex Deucher]

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(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon and amdgpu drm-fixes-4.2

[Alex Deucher]

Hi Dave,

More radeon and amdgpu fixes for 4.2.  Mostly amdgpu bug fixes.

The following changes since commit 3aa20508a6fe386c2a893027ef4c4ef78ee4eac2:

  Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (2015-07-15 18:38:24 -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 1002d71841d52b2390c82c2bc18922ac21fbd090:

  drm/amdgpu/dce8: Re-set VBLANK interrupt state when enabling a CRTC (2015-07-16 12:39:44 -0400)

----------------------------------------------------------------
Alex Deucher (8):
      drm/radeon: add a dpm quirk for Sapphire Radeon R9 270X 2GB GDDR5
      drm/amdgpu: disable the IP module if early_init returns -ENOENT (v2)
      drm/amdgpu: set proper index/data pair for smc regs on CZ (v2)
      drm/amdgpu: remove bogus check in gfx8 rb setup
      drm/amdgpu/cz: unforce dpm levels before forcing to low/high
      drm/amdgpu/cz: store the forced dpm level
      drm/amdgpu/cz: silence some dpm debug output
      drm/radeon/ci: silence a harmless PCC warning

Christian König (3):
      drm/radeon: fix user ptr race condition
      drm/amdgpu: validate the context id in the dependencies
      drm/amdgpu: stop context leak in the error path

Michel Dänzer (2):
      drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL
      drm/amdgpu/dce8: Re-set VBLANK interrupt state when enabling a CRTC

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c     | 19 +++++++++++++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  9 ++++++--
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c        | 16 ++++++++++----
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c      |  4 ++++
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c      |  5 +----
 drivers/gpu/drm/amd/amdgpu/vi.c            | 35 ++++++++++++++++++++++++++++--
 drivers/gpu/drm/radeon/ci_dpm.c            |  2 +-
 drivers/gpu/drm/radeon/radeon_gart.c       | 12 ++++++----
 drivers/gpu/drm/radeon/radeon_gem.c        |  1 +
 drivers/gpu/drm/radeon/radeon_object.c     |  1 -
 drivers/gpu/drm/radeon/si_dpm.c            |  1 +
 11 files changed, 84 insertions(+), 21 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel