[PATCH 00/23] kill drm cruft with fire
On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote: > > > > >> Testing this on via would be awesome! Iirc I haven't changed anything > > > >> in > > > >> the via specific patches, but if it's more convenient you can also > > > >> directly test my branch: > > > >> > > > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > > > > > > > Okay I tried the patches and it locked up the openchrome X server. I'm > > > > going to try your branch tonight to see if it makes any difference. If > > > > it > > > > still fails I will have to track down what the problem is. > > > > > > If you can bisect the issue, that would be awesome. Meanwhile my sis > > > card arrived, so I'm hopefully get around to test that part of the > > > series rsn. I'm traveling atm though, so response time will suffer a > > > bit. > > > > Any updates on testing results? > > Yes I do. I'm using the patches you posted. Patches 1 to 10 work with no > problems. Ist patch 11 that breaks the openchrome xorg driver. Have to > do some digging to find the exact problem. Thanks a lot for digging through these patches. As you've noted in patch 11, I don't set release_idlelock anywhere which results in the via driver deadlocking when clients close. The same holds for the equivalent sis patch. Updated patch series pushed to my kill-with-fire branch. Please test and yell at me if it's still broken. Yours, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Re: [PATCH 00/23] kill drm cruft with fire
On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote: > > > > >> Testing this on via would be awesome! Iirc I haven't changed anything > > > >> in > > > >> the via specific patches, but if it's more convenient you can also > > > >> directly test my branch: > > > >> > > > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > > > > > > > Okay I tried the patches and it locked up the openchrome X server. I'm > > > > going to try your branch tonight to see if it makes any difference. If > > > > it > > > > still fails I will have to track down what the problem is. > > > > > > If you can bisect the issue, that would be awesome. Meanwhile my sis > > > card arrived, so I'm hopefully get around to test that part of the > > > series rsn. I'm traveling atm though, so response time will suffer a > > > bit. > > > > Any updates on testing results? > > Yes I do. I'm using the patches you posted. Patches 1 to 10 work with no > problems. Ist patch 11 that breaks the openchrome xorg driver. Have to > do some digging to find the exact problem. Thanks a lot for digging through these patches. As you've noted in patch 11, I don't set release_idlelock anywhere which results in the via driver deadlocking when clients close. The same holds for the equivalent sis patch. Updated patch series pushed to my kill-with-fire branch. Please test and yell at me if it's still broken. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/23] kill drm cruft with fire
> > >> Testing this on via would be awesome! Iirc I haven't changed anything in > > >> the via specific patches, but if it's more convenient you can also > > >> directly test my branch: > > >> > > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > > > > > Okay I tried the patches and it locked up the openchrome X server. I'm > > > going to try your branch tonight to see if it makes any difference. If it > > > still fails I will have to track down what the problem is. > > > > If you can bisect the issue, that would be awesome. Meanwhile my sis > > card arrived, so I'm hopefully get around to test that part of the > > series rsn. I'm traveling atm though, so response time will suffer a > > bit. > > Any updates on testing results? Yes I do. I'm using the patches you posted. Patches 1 to 10 work with no problems. Ist patch 11 that breaks the openchrome xorg driver. Have to do some digging to find the exact problem.
Re: [PATCH 00/23] kill drm cruft with fire
> > >> Testing this on via would be awesome! Iirc I haven't changed anything in > > >> the via specific patches, but if it's more convenient you can also > > >> directly test my branch: > > >> > > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > > > > > Okay I tried the patches and it locked up the openchrome X server. I'm > > > going to try your branch tonight to see if it makes any difference. If it > > > still fails I will have to track down what the problem is. > > > > If you can bisect the issue, that would be awesome. Meanwhile my sis > > card arrived, so I'm hopefully get around to test that part of the > > series rsn. I'm traveling atm though, so response time will suffer a > > bit. > > Any updates on testing results? Yes I do. I'm using the patches you posted. Patches 1 to 10 work with no problems. Ist patch 11 that breaks the openchrome xorg driver. Have to do some digging to find the exact problem. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/23] kill drm cruft with fire
On Wed, Nov 16, 2011 at 05:17:12PM +0100, Daniel Vetter wrote: > On Mon, Nov 14, 2011 at 17:10, James Simmons > wrote: > >> > Should I test this set of patches for the VIA driver or wait until you > >> > have a second version of this patch? > >> > >> Testing this on via would be awesome! Iirc I haven't changed anything in > >> the via specific patches, but if it's more convenient you can also > >> directly test my branch: > >> > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > > > Okay I tried the patches and it locked up the openchrome X server. I'm > > going to try your branch tonight to see if it makes any difference. If it > > still fails I will have to track down what the problem is. > > If you can bisect the issue, that would be awesome. Meanwhile my sis > card arrived, so I'm hopefully get around to test that part of the > series rsn. I'm traveling atm though, so response time will suffer a > bit. Any updates on testing results? Yours, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Re: [PATCH 00/23] kill drm cruft with fire
On Wed, Nov 16, 2011 at 05:17:12PM +0100, Daniel Vetter wrote: > On Mon, Nov 14, 2011 at 17:10, James Simmons wrote: > >> > Should I test this set of patches for the VIA driver or wait until you > >> > have a second version of this patch? > >> > >> Testing this on via would be awesome! Iirc I haven't changed anything in > >> the via specific patches, but if it's more convenient you can also > >> directly test my branch: > >> > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > > > Okay I tried the patches and it locked up the openchrome X server. I'm > > going to try your branch tonight to see if it makes any difference. If it > > still fails I will have to track down what the problem is. > > If you can bisect the issue, that would be awesome. Meanwhile my sis > card arrived, so I'm hopefully get around to test that part of the > series rsn. I'm traveling atm though, so response time will suffer a > bit. Any updates on testing results? Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/23] kill drm cruft with fire
On Mon, Nov 14, 2011 at 17:10, James Simmons wrote: >> > Should I test this set of patches for the VIA driver or wait until you >> > have a second version of this patch? >> >> Testing this on via would be awesome! Iirc I haven't changed anything in >> the via specific patches, but if it's more convenient you can also >> directly test my branch: >> >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > Okay I tried the patches and it locked up the openchrome X server. I'm > going to try your branch tonight to see if it makes any difference. If it > still fails I will have to track down what the problem is. If you can bisect the issue, that would be awesome. Meanwhile my sis card arrived, so I'm hopefully get around to test that part of the series rsn. I'm traveling atm though, so response time will suffer a bit. -Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
Re: [PATCH 00/23] kill drm cruft with fire
On Mon, Nov 14, 2011 at 17:10, James Simmons wrote: >> > Should I test this set of patches for the VIA driver or wait until you >> > have a second version of this patch? >> >> Testing this on via would be awesome! Iirc I haven't changed anything in >> the via specific patches, but if it's more convenient you can also >> directly test my branch: >> >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > Okay I tried the patches and it locked up the openchrome X server. I'm > going to try your branch tonight to see if it makes any difference. If it > still fails I will have to track down what the problem is. If you can bisect the issue, that would be awesome. Meanwhile my sis card arrived, so I'm hopefully get around to test that part of the series rsn. I'm traveling atm though, so response time will suffer a bit. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/23] kill drm cruft with fire
> > Should I test this set of patches for the VIA driver or wait until you > > have a second version of this patch? > > Testing this on via would be awesome! Iirc I haven't changed anything in > the via specific patches, but if it's more convenient you can also > directly test my branch: > > http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire Okay I tried the patches and it locked up the openchrome X server. I'm going to try your branch tonight to see if it makes any difference. If it still fails I will have to track down what the problem is.
Re: [PATCH 00/23] kill drm cruft with fire
> > Should I test this set of patches for the VIA driver or wait until you > > have a second version of this patch? > > Testing this on via would be awesome! Iirc I haven't changed anything in > the via specific patches, but if it's more convenient you can also > directly test my branch: > > http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire Okay I tried the patches and it locked up the openchrome X server. I'm going to try your branch tonight to see if it makes any difference. If it still fails I will have to track down what the problem is. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/23] kill drm cruft with fire
On Fri, Nov 11, 2011 at 03:33:07PM +, James Simmons wrote: > > > Review, flames highly welcome. > > > > Cheers, Daniel > > > > Daniel Vetter (23): > > drm/sis: track obj->drm_fd relations in the driver > > drm/via: track obj->drm_fd relations in the driver > > drm/sman: kill owner tracking interface functions > > drm/sman: rip out owner tracking > > drm/via: track user->memblock mapping with idr > > drm/sis: track user->memblock mapping with idr > > drm/sman: kill user_hash_tab > > drm/via: use drm_mm instead of drm_sman > > drm/sis: use drm_mm instead of drm_sman > > drm: kill drm_sman > > > > drm/via: clean up reclaim_buffers > > drm/sis: clean up reclaim_buffers > > drm: kill reclaim_buffers_idlelocked functions > > drm/i810: cleanup reclaim_buffers > > drm: kill reclaim_buffers_locked > > drm/savage: clean up reclaim_buffers > > drm: kill reclaim_buffers callback > > Should I test this set of patches for the VIA driver or wait until you > have a second version of this patch? Testing this on via would be awesome! Iirc I haven't changed anything in the via specific patches, but if it's more convenient you can also directly test my branch: http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire Yours, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH 00/23] kill drm cruft with fire
> Review, flames highly welcome. > > Cheers, Daniel > > Daniel Vetter (23): > drm/sis: track obj->drm_fd relations in the driver > drm/via: track obj->drm_fd relations in the driver > drm/sman: kill owner tracking interface functions > drm/sman: rip out owner tracking > drm/via: track user->memblock mapping with idr > drm/sis: track user->memblock mapping with idr > drm/sman: kill user_hash_tab > drm/via: use drm_mm instead of drm_sman > drm/sis: use drm_mm instead of drm_sman > drm: kill drm_sman > > drm/via: clean up reclaim_buffers > drm/sis: clean up reclaim_buffers > drm: kill reclaim_buffers_idlelocked functions > drm/i810: cleanup reclaim_buffers > drm: kill reclaim_buffers_locked > drm/savage: clean up reclaim_buffers > drm: kill reclaim_buffers callback Should I test this set of patches for the VIA driver or wait until you have a second version of this patch?
Re: [PATCH 00/23] kill drm cruft with fire
On Fri, Nov 11, 2011 at 03:33:07PM +, James Simmons wrote: > > > Review, flames highly welcome. > > > > Cheers, Daniel > > > > Daniel Vetter (23): > > drm/sis: track obj->drm_fd relations in the driver > > drm/via: track obj->drm_fd relations in the driver > > drm/sman: kill owner tracking interface functions > > drm/sman: rip out owner tracking > > drm/via: track user->memblock mapping with idr > > drm/sis: track user->memblock mapping with idr > > drm/sman: kill user_hash_tab > > drm/via: use drm_mm instead of drm_sman > > drm/sis: use drm_mm instead of drm_sman > > drm: kill drm_sman > > > > drm/via: clean up reclaim_buffers > > drm/sis: clean up reclaim_buffers > > drm: kill reclaim_buffers_idlelocked functions > > drm/i810: cleanup reclaim_buffers > > drm: kill reclaim_buffers_locked > > drm/savage: clean up reclaim_buffers > > drm: kill reclaim_buffers callback > > Should I test this set of patches for the VIA driver or wait until you > have a second version of this patch? Testing this on via would be awesome! Iirc I haven't changed anything in the via specific patches, but if it's more convenient you can also directly test my branch: http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/23] kill drm cruft with fire
> Review, flames highly welcome. > > Cheers, Daniel > > Daniel Vetter (23): > drm/sis: track obj->drm_fd relations in the driver > drm/via: track obj->drm_fd relations in the driver > drm/sman: kill owner tracking interface functions > drm/sman: rip out owner tracking > drm/via: track user->memblock mapping with idr > drm/sis: track user->memblock mapping with idr > drm/sman: kill user_hash_tab > drm/via: use drm_mm instead of drm_sman > drm/sis: use drm_mm instead of drm_sman > drm: kill drm_sman > > drm/via: clean up reclaim_buffers > drm/sis: clean up reclaim_buffers > drm: kill reclaim_buffers_idlelocked functions > drm/i810: cleanup reclaim_buffers > drm: kill reclaim_buffers_locked > drm/savage: clean up reclaim_buffers > drm: kill reclaim_buffers callback Should I test this set of patches for the VIA driver or wait until you have a second version of this patch? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/23] kill drm cruft with fire
Hi all, It's that time of the year again when the weather gets crappy, people depressed and danvet wades through drm cruft. Not that any of this is related in any way. Actually I only wanted to port users of drm_mm to the new interfaces, completing a work I've started a while ago. It lead to a littel detour. Patches 1-10 kill drm_sman (hereby reducing the number of users of the old drm_mm interface by one). I don't have either sis or via hw but given - how lightly the dri1 removal went down - you can't really ebay this hw anymore (at least not here, I've tried) - and that no one really changes much in them anymore (last time was me a year ago, killing cruft) I think the risk is worth it. Worst case I expect to some oops-decoding because this doesn't change neither userspace nor hw facing code, only pure kernel book-keeping. Patches 11-17 clean the reclaim_buffers support by the drm core by moving everything into driver specific preclose functions. I've noticed this horrid stuff while writing the buffer tracking code for via/sis. Patches 18-20 rip out the dma queue code, which was totally unused. The two risky steps of that surgery are split out. Patches 21-23 finish this series by killing a few random smaller things I've noticed. Entire pile tested on my i810, that's the last fully working dri1 setup I still have. The reclaim_buffers rework actually improves things there. Two patches have a potential userspace abi impact, one is i810 specific (didn't break anything in testing), the other breaks libdrm that is older than 10 years (by killing proc). The drm fd release path looks now much less scary with this series (mostly due to the reclaim_buffers rework), but there's still the context support seemingly only used by via left. I might look into that as soon as I can get these images of horribly slaugthered kittens out of my brain ... Review, flames highly welcome. Cheers, Daniel Daniel Vetter (23): drm/sis: track obj->drm_fd relations in the driver drm/via: track obj->drm_fd relations in the driver drm/sman: kill owner tracking interface functions drm/sman: rip out owner tracking drm/via: track user->memblock mapping with idr drm/sis: track user->memblock mapping with idr drm/sman: kill user_hash_tab drm/via: use drm_mm instead of drm_sman drm/sis: use drm_mm instead of drm_sman drm: kill drm_sman drm/via: clean up reclaim_buffers drm/sis: clean up reclaim_buffers drm: kill reclaim_buffers_idlelocked functions drm/i810: cleanup reclaim_buffers drm: kill reclaim_buffers_locked drm/savage: clean up reclaim_buffers drm: kill reclaim_buffers callback drm: ditch strange DRIVER_DMA_QUEUE only error bail-out drm: kill dma queue support drm: unconditionally clean up dma buffers of closing clients drm: kill i915/i830 ids from drm_pciids.h drm: kill procfs support drm: kill a few unused remnants from drm_memory.c drivers/gpu/drm/Makefile |4 +- drivers/gpu/drm/drm_bufs.c| 16 +-- drivers/gpu/drm/drm_debugfs.c |1 - drivers/gpu/drm/drm_dma.c |5 - drivers/gpu/drm/drm_drv.c | 19 -- drivers/gpu/drm/drm_fops.c| 63 +-- drivers/gpu/drm/drm_info.c| 36 drivers/gpu/drm/drm_lock.c|6 +- drivers/gpu/drm/drm_memory.c | 19 -- drivers/gpu/drm/drm_proc.c| 221 - drivers/gpu/drm/drm_sman.c| 350 - drivers/gpu/drm/drm_stub.c| 25 +-- drivers/gpu/drm/i810/i810_dma.c | 17 +- drivers/gpu/drm/i810/i810_drv.c |3 +- drivers/gpu/drm/i810/i810_drv.h |6 +- drivers/gpu/drm/i915/i915_drv.c |1 - drivers/gpu/drm/mga/mga_drv.c |1 - drivers/gpu/drm/nouveau/nouveau_drv.c |1 - drivers/gpu/drm/r128/r128_drv.c |1 - drivers/gpu/drm/radeon/radeon_drv.c |2 - drivers/gpu/drm/savage/savage_bci.c |7 +- drivers/gpu/drm/savage/savage_drv.c |2 +- drivers/gpu/drm/sis/sis_drv.c | 36 +++- drivers/gpu/drm/sis/sis_drv.h |7 +- drivers/gpu/drm/sis/sis_mm.c | 210 drivers/gpu/drm/tdfx/tdfx_drv.c |1 - drivers/gpu/drm/via/via_drv.c | 29 +++- drivers/gpu/drm/via/via_drv.h |7 +- drivers/gpu/drm/via/via_map.c | 10 +- drivers/gpu/drm/via/via_mm.c | 145 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 - drivers/staging/gma500/psb_drv.c |1 - include/drm/drmP.h| 28 +--- include/drm/drm_pciids.h | 42 include/drm/drm_sman.h| 176 - include/drm/sis_drm.h |4 + include/drm/via_drm.h |4 + 37 files changed, 337 insertions(+), 1170 deletions(-) delete mode 100644 drivers/gpu/drm/drm_proc.c delete mode 100644 drivers/gpu/drm/drm_sman.c delete mode 1006
[PATCH 00/23] kill drm cruft with fire
Hi all, It's that time of the year again when the weather gets crappy, people depressed and danvet wades through drm cruft. Not that any of this is related in any way. Actually I only wanted to port users of drm_mm to the new interfaces, completing a work I've started a while ago. It lead to a littel detour. Patches 1-10 kill drm_sman (hereby reducing the number of users of the old drm_mm interface by one). I don't have either sis or via hw but given - how lightly the dri1 removal went down - you can't really ebay this hw anymore (at least not here, I've tried) - and that no one really changes much in them anymore (last time was me a year ago, killing cruft) I think the risk is worth it. Worst case I expect to some oops-decoding because this doesn't change neither userspace nor hw facing code, only pure kernel book-keeping. Patches 11-17 clean the reclaim_buffers support by the drm core by moving everything into driver specific preclose functions. I've noticed this horrid stuff while writing the buffer tracking code for via/sis. Patches 18-20 rip out the dma queue code, which was totally unused. The two risky steps of that surgery are split out. Patches 21-23 finish this series by killing a few random smaller things I've noticed. Entire pile tested on my i810, that's the last fully working dri1 setup I still have. The reclaim_buffers rework actually improves things there. Two patches have a potential userspace abi impact, one is i810 specific (didn't break anything in testing), the other breaks libdrm that is older than 10 years (by killing proc). The drm fd release path looks now much less scary with this series (mostly due to the reclaim_buffers rework), but there's still the context support seemingly only used by via left. I might look into that as soon as I can get these images of horribly slaugthered kittens out of my brain ... Review, flames highly welcome. Cheers, Daniel Daniel Vetter (23): drm/sis: track obj->drm_fd relations in the driver drm/via: track obj->drm_fd relations in the driver drm/sman: kill owner tracking interface functions drm/sman: rip out owner tracking drm/via: track user->memblock mapping with idr drm/sis: track user->memblock mapping with idr drm/sman: kill user_hash_tab drm/via: use drm_mm instead of drm_sman drm/sis: use drm_mm instead of drm_sman drm: kill drm_sman drm/via: clean up reclaim_buffers drm/sis: clean up reclaim_buffers drm: kill reclaim_buffers_idlelocked functions drm/i810: cleanup reclaim_buffers drm: kill reclaim_buffers_locked drm/savage: clean up reclaim_buffers drm: kill reclaim_buffers callback drm: ditch strange DRIVER_DMA_QUEUE only error bail-out drm: kill dma queue support drm: unconditionally clean up dma buffers of closing clients drm: kill i915/i830 ids from drm_pciids.h drm: kill procfs support drm: kill a few unused remnants from drm_memory.c drivers/gpu/drm/Makefile |4 +- drivers/gpu/drm/drm_bufs.c| 16 +-- drivers/gpu/drm/drm_debugfs.c |1 - drivers/gpu/drm/drm_dma.c |5 - drivers/gpu/drm/drm_drv.c | 19 -- drivers/gpu/drm/drm_fops.c| 63 +-- drivers/gpu/drm/drm_info.c| 36 drivers/gpu/drm/drm_lock.c|6 +- drivers/gpu/drm/drm_memory.c | 19 -- drivers/gpu/drm/drm_proc.c| 221 - drivers/gpu/drm/drm_sman.c| 350 - drivers/gpu/drm/drm_stub.c| 25 +-- drivers/gpu/drm/i810/i810_dma.c | 17 +- drivers/gpu/drm/i810/i810_drv.c |3 +- drivers/gpu/drm/i810/i810_drv.h |6 +- drivers/gpu/drm/i915/i915_drv.c |1 - drivers/gpu/drm/mga/mga_drv.c |1 - drivers/gpu/drm/nouveau/nouveau_drv.c |1 - drivers/gpu/drm/r128/r128_drv.c |1 - drivers/gpu/drm/radeon/radeon_drv.c |2 - drivers/gpu/drm/savage/savage_bci.c |7 +- drivers/gpu/drm/savage/savage_drv.c |2 +- drivers/gpu/drm/sis/sis_drv.c | 36 +++- drivers/gpu/drm/sis/sis_drv.h |7 +- drivers/gpu/drm/sis/sis_mm.c | 210 drivers/gpu/drm/tdfx/tdfx_drv.c |1 - drivers/gpu/drm/via/via_drv.c | 29 +++- drivers/gpu/drm/via/via_drv.h |7 +- drivers/gpu/drm/via/via_map.c | 10 +- drivers/gpu/drm/via/via_mm.c | 145 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 - drivers/staging/gma500/psb_drv.c |1 - include/drm/drmP.h| 28 +--- include/drm/drm_pciids.h | 42 include/drm/drm_sman.h| 176 - include/drm/sis_drm.h |4 + include/drm/via_drm.h |4 + 37 files changed, 337 insertions(+), 1170 deletions(-) delete mode 100644 drivers/gpu/drm/drm_proc.c delete mode 100644 drivers/gpu/drm/drm_sman.c delete mode 1006
