Hi Linus,
This feels larger than I'd like but its for three reasons.
a) amdkfd finalising the API more, this is a new feature introduced last merge window, and I'd prefer to make the tweaks to the API before it first gets into a stable release.
b) radeon regression required splitting an internal API to fix properly, so it just changed a few more lines
c) vmwgfx fix changes a lock from a mutex->spin lock, this is fallout from the new sleep checking.
Otherwise there is just some tda998x fixes.
Dave.
The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce:
Linux 3.19-rc6 (2015-01-25 20:04:41 -0800)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
for you to fetch changes up to 5159571ceb44eba9bf9f9a34ec625386d421de9c:
Merge branch 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2015-01-27 09:56:13 +1000)
----------------------------------------------------------------
Andrew Jackson (1): drm/i2c: tda998x: set the CEC I2C address based on the slave I2C address
Ben Goz (1): drm/amdkfd: PQM handle queue creation fault
Dave Airlie (5): Merge branch 'vmwgfx-fixes-3.19' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge branch 'drm-tda998x-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into drm-fixes Merge tag 'v3.19-rc6' into drm-fixes Merge tag 'drm-amdkfd-fixes-2015-01-26' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes Merge branch 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Jean-Francois Moine (2): drm: tda998x: Protect the page register drm: tda998x: Fix EDID read timeout on HDMI connect
Michel Dänzer (3): drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry drm/radeon: Restore GART table contents after pinning it in VRAM v3 drm/radeon: Remove rdev->gart.pages_addr array
Oded Gabbay (4): drm/amdkfd: Allow user to limit only queues per device drm/radeon: Don't increment pipe_id in kgd_init_pipeline drm/amdkfd: Fix bug in pipelines initialization drm/amdkfd: Fix bug in call to init_pipelines()
Thomas Hellstrom (1): drm/vmwgfx: Replace the hw mutex with a hw spinlock
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 78 +++++++++++++++++++++- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 1 + drivers/gpu/drm/amd/amdkfd/kfd_module.c | 27 +++----- drivers/gpu/drm/amd/amdkfd/kfd_pasid.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 17 +++-- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 12 ++-- drivers/gpu/drm/i2c/tda998x_drv.c | 52 ++++++++++++--- drivers/gpu/drm/radeon/cik_sdma.c | 1 - drivers/gpu/drm/radeon/ni_dma.c | 1 - drivers/gpu/drm/radeon/r100.c | 10 ++- drivers/gpu/drm/radeon/r300.c | 16 +++-- drivers/gpu/drm/radeon/radeon.h | 9 ++- drivers/gpu/drm/radeon/radeon_asic.c | 24 +++++++ drivers/gpu/drm/radeon/radeon_asic.h | 12 ++-- drivers/gpu/drm/radeon/radeon_device.c | 2 + drivers/gpu/drm/radeon/radeon_gart.c | 54 +++++++++------ drivers/gpu/drm/radeon/radeon_kfd.c | 2 +- drivers/gpu/drm/radeon/radeon_vm.c | 6 +- drivers/gpu/drm/radeon/rs400.c | 14 ++-- drivers/gpu/drm/radeon/rs600.c | 14 ++-- drivers/gpu/drm/radeon/si_dma.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 28 ++------ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 25 +++++-- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 18 +---- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 36 +++++----- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 8 +-- drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 25 +++---- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 - 29 files changed, 315 insertions(+), 188 deletions(-)
On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie airlied@linux.ie wrote:
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
No they aren't, actually, because you've screwed up your repository.
It looks like you were using an alternates that has gone away:
remote: error: object directory /srv/anongit.freedesktop.org/git/nouveau/linux-2.6/objects does not exist; check .git/objects/info/alternates. remote: error: Could not read fe06a892edbcd0cd42ea5928e4492a337e3bd90c remote: fatal: bad tree object fe06a892edbcd0cd42ea5928e4492a337e3bd90c remote: aborting due to possible repository corruption on the remote side.
it really looks like you started your repo by doing a shared clone from an insane source (ie the nouveau tree), and then the nouveau tree got renamed or deleted (perhaps somebody decided that the whole "linux-2.6" naming doesn't make sense any more, since we haven't been at 2.6 for years). So now your repository depends on another repo that is gone.
It's should be trivially fixable by just editing the git "alternates" file to point to the proper base again, since that fe06a892edbc object is definitely part of my base kernel, but basically you shouldn't do shared clones unless you know you can really *rely* on the clone you're sharing from. Doing it from some random side project like the nouveau tree sounds like a bad bad idea.
Linus
On 28 January 2015 at 04:04, Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie airlied@linux.ie wrote:
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
No they aren't, actually, because you've screwed up your repository.
It looks like you were using an alternates that has gone away:
remote: error: object directory /srv/anongit.freedesktop.org/git/nouveau/linux-2.6/objects does not exist; check .git/objects/info/alternates. remote: error: Could not read fe06a892edbcd0cd42ea5928e4492a337e3bd90c remote: fatal: bad tree object fe06a892edbcd0cd42ea5928e4492a337e3bd90c remote: aborting due to possible repository corruption on the remote side.
it really looks like you started your repo by doing a shared clone from an insane source (ie the nouveau tree), and then the nouveau tree got renamed or deleted (perhaps somebody decided that the whole "linux-2.6" naming doesn't make sense any more, since we haven't been at 2.6 for years). So now your repository depends on another repo that is gone.
It's should be trivially fixable by just editing the git "alternates" file to point to the proper base again, since that fe06a892edbc object is definitely part of my base kernel, but basically you shouldn't do shared clones unless you know you can really *rely* on the clone you're sharing from. Doing it from some random side project like the nouveau tree sounds like a bad bad idea.
Actually everything was there, just one tree is NFS mounted from somewhere else, and fd.o got rebooted and the mount didn't come back up automatically, fixed it now.
But yes I'll reorganise my tree to be a clean copy, I built it years ago temporarily and it kinda ended up permanent, and I forgot where I cloned it from.
Dave.
dri-devel@lists.freedesktop.org
-
Dave Airlie -
Dave Airlie -
Linus Torvalds