Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1471470 > unrolled thread

[git pull] drm fixes for rc4 or 5

Started byDave Airlie <airlied@linux.ie>
First post2016-08-28 23:10 +0200
Last post2016-08-28 23:40 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [git pull] drm fixes for rc4 or 5 Dave Airlie <airlied@linux.ie> - 2016-08-28 23:10 +0200
    Re: [git pull] drm fixes for rc4 or 5 Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-28 23:40 +0200
      Re: [git pull] drm fixes for rc4 or 5 Dave Airlie <airlied@gmail.com> - 2016-08-29 01:30 +0200
    Re: [git pull] drm fixes for rc4 or 5 Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-28 23:40 +0200

#1471470 — [git pull] drm fixes for rc4 or 5

FromDave Airlie <airlied@linux.ie>
Date2016-08-28 23:10 +0200
Subject[git pull] drm fixes for rc4 or 5
Message-ID<sbfv4-6Ra-23@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hi,

I probably missed -rc4 by minutes, but maybe pointless GPL enforcement 
debates are distracting you enough!

Anyways, a bunch of fixes covering i915, amdgpu, one tegra and some
core DRM ones. Nothing too strange at this point.

Dave.

The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:

  Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-4.8-rc4

for you to fetch changes up to add1fa75101263ab4d74240f93000998d4325624:

  drm/atomic: Don't potentially reset color_mgmt_changed on successive property updates. (2016-08-29 06:55:47 +1000)

----------------------------------------------------------------
Alex Deucher (2):
      drm/amdgpu: avoid a possible array overflow
      drm/amdgpu: skip TV/CV in display parsing

Chris Wilson (1):
      drm/i915: Unconditionally flush any chipset buffers before execbuf

Christian König (6):
      drm/radeon: only apply the SS fractional workaround to RS[78]80
      drm/radeon: fix radeon_move_blit on 32bit systems
      drm/amdgpu: fix amdgpu_move_blit on 32bit systems
      drm/amdgpu: fix sdma_v2_4_ring_test_ib
      drm/amdgpu: fix timeout value check in amd_sched_job_recovery
      drm/amdgpu: fix lru size grouping v2

Daniel Vetter (2):
      drm: Reject page_flip for !DRIVER_MODESET
      drm: Protect fb_defio in drivers with CONFIG_KMS_FBDEV_EMULATION

Dave Airlie (3):
      Merge tag 'drm/tegra/for-4.8-rc4' of git://anongit.freedesktop.org/tegra/linux into drm-fixes
      Merge branch 'drm-fixes-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
      Merge tag 'drm-intel-fixes-2016-08-25' of git://anongit.freedesktop.org/drm-intel into drm-fixes

Dave Gordon (1):
      drm/i915: Reattach comment, complete type specification

Lyude (3):
      drm/i915/gen6+: Interpret mailbox error flags
      drm/i915/skl: Add support for the SAGV, fix underrun hangs
      drm/i915/skl: Ensure pipes with changed wms get added to the state

Maarten Lankhorst (1):
      drm/i915: Fix botched merge that downgrades CSR versions.

Mario Kleiner (1):
      drm/atomic: Don't potentially reset color_mgmt_changed on successive property updates.

Matt Roper (3):
      drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization (v2)
      drm/i915/gen9: Drop invalid WARN() during data rate calculation
      drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

Thierry Reding (1):
      drm/tegra: dsi: Enhance runtime power management

 drivers/gpu/drm/amd/amdgpu/amdgpu.h           |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c  |  13 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c       |  12 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c        |   2 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c |   2 +-
 drivers/gpu/drm/drm_atomic.c                  |   6 +-
 drivers/gpu/drm/drm_crtc.c                    |   3 +
 drivers/gpu/drm/i915/i915_drv.h               |  13 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c    |  13 +-
 drivers/gpu/drm/i915/i915_reg.h               |  13 ++
 drivers/gpu/drm/i915/intel_csr.c              |   8 +-
 drivers/gpu/drm/i915/intel_display.c          |  11 ++
 drivers/gpu/drm/i915/intel_drv.h              |   3 +
 drivers/gpu/drm/i915/intel_pm.c               | 270 +++++++++++++++++++++++++-
 drivers/gpu/drm/qxl/qxl_fb.c                  |   4 +
 drivers/gpu/drm/radeon/atombios_crtc.c        |   4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c           |   4 +-
 drivers/gpu/drm/tegra/dsi.c                   |  43 +++-
 drivers/gpu/drm/udl/udl_fb.c                  |   4 +
 drivers/gpu/host1x/mipi.c                     |  63 +++---
 include/linux/host1x.h                        |   2 +
 21 files changed, 424 insertions(+), 71 deletions(-)

[toc] | [next] | [standalone]


#1471474

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-08-28 23:40 +0200
Message-ID<sbfY5-70x-3@gated-at.bofh.it>
In reply to#1471470
On Sun, Aug 28, 2016 at 2:31 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Anyway, the real problem was that this was in my spam-box. Which I've
> learnt to check religiously, so I noticed almost immediately.

Btw, on a totally unrelated issue: you make thes pull points tags
(good), but they are just plain simple tags with no message and in
particular no pgp signature.

I guess freedesktop.org is fairly well managed, but still - would you
mind using signed tags? It's not *that* much extra work: use "git tag
-s". You can write the description into the tag message, or you can
just make the message be something useless and continue to write the
description in the email itself, but now it would have that nice
cryptographic signature showing it's really you..

           Linus

[toc] | [prev] | [next] | [standalone]


#1471492

FromDave Airlie <airlied@gmail.com>
Date2016-08-29 01:30 +0200
Message-ID<sbhGx-87g-1@gated-at.bofh.it>
In reply to#1471474
On 29 August 2016 at 07:35, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Aug 28, 2016 at 2:31 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Anyway, the real problem was that this was in my spam-box. Which I've
>> learnt to check religiously, so I noticed almost immediately.
>
> Btw, on a totally unrelated issue: you make thes pull points tags
> (good), but they are just plain simple tags with no message and in
> particular no pgp signature.
>
> I guess freedesktop.org is fairly well managed, but still - would you
> mind using signed tags? It's not *that* much extra work: use "git tag
> -s". You can write the description into the tag message, or you can
> just make the message be something useless and continue to write the
> description in the email itself, but now it would have that nice
> cryptographic signature showing it's really you..

See when I failed to use capital letters, you knew it was definitely me,
no need for crypto.

The main reason I've avoided signed tags is I currently don't have my pgp key
sitting on the machine where I build and generate, because I'm lazy, and I
don't usually propogate my pgp key to other machines like my other laptops
when I have to do a pull request from the shower or wherever.

I'll try and integrate signed tags a bit better.

I think it's probably spam because of sending @linux.ie from a server that
isn't definitely a linux.ie email server, I'll probably just move to using gmail
for sending pull requests, though the UI kinda sucks for pasting in things.

Dave.

[toc] | [prev] | [next] | [standalone]


#1471475

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-08-28 23:40 +0200
Message-ID<sbfY5-70x-5@gated-at.bofh.it>
In reply to#1471470
On Sun, Aug 28, 2016 at 2:00 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> I probably missed -rc4 by minutes, but maybe pointless GPL enforcement
> debates are distracting you enough!

Hey, they must be good for _something_.

Anyway, the real problem was that this was in my spam-box. Which I've
learnt to check religiously, so I noticed almost immediately.

It had no major reason for it, gmail just says that it "looks like
other spam". So I don't know if there is anything to be done for it
apart from me having marked it as non-spam again. Hmm.

                   Linus

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web