> -Original Message-
> From: Peter Chubb [mailto:peter.chubb at nicta.com.au]
> Sent: Wednesday, December 11, 2013 5:11 PM
> To: Markus Trippelsdorf
> Cc: Peter Chubb; Deucher, Alexander; airlied at linux.ie; dri-
> devel at lists.freedesktop.org
> Subject: Re: Can no longer shutdown after
On Dec 11, 2013, at 7:56 PM, Sougata Santra wrote:
[snip]
> In OSX, we can open "file/rsrc" to get the resource fork of "file".
> This behavior is emulated inside hfsplus on Linux, which means that
> to some degree every file acts like a directory. That is the reason
> lookup() inode operations i
;http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/1c00a250/attachment.pgp>
the bug.
------ next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/c401cffc/attachment.html>
The intent was to only enable it by default for optimus, e.g. see the
runtime_idle callback. The suspend callback may be called directly, e.g.
as a result of nouveau_crtc_set_config.
Reported-by: Stefan Lippers-Hollmann
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org
---
See http://lis
eport.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/87a62e00/attachment.html>
Hi Dave,
Just noticed that this one here hasn't landed in drm-fixes yet.
Somehow I've thought it has and I've sent you the latest bdw fix in
the normal pull request. I guess I need to get my topic branch model
sorted out a bit better first.
Can you please pull this one in before pulling the norma
Hi,
On 11 Dec 2013, at 19:11, Al Viro wrote:
> On Wed, Dec 11, 2013 at 10:49:29PM +0300, Vyacheslav Dubeyko wrote:
>> This feature worked earlier under Linux. So, I suppose that some changes in
>> HFS+ driver
>> or in VFS broke it. And it needs to investigate and fix the reported issue.
>> Than
On 12/11/13 01:17 PM, Keith Packard wrote:
> I stole the conditional for _X_ATTRIBUTE_PRINTF from xproto and
> changed the name to _DRM_ATTRIBUTE_PRINTF to avoid future conflicts.
>
> Signed-off-by: Keith Packard
> ---
> xf86drm.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
g this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/c060fa97/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/34621a80/attachment.html>
On Wed, Dec 11, 2013 at 10:49:29PM +0300, Vyacheslav Dubeyko wrote:
> This feature worked earlier under Linux. So, I suppose that some changes in
> HFS+ driver
> or in VFS broke it. And it needs to investigate and fix the reported issue.
> Thank you for the
> report.
This "feature" is severely
From: Sougata Santra
HFS+ resource fork lookup breaks opendir() library function. Since
opendir first calls open() with O_DIRECTORY flag set. O_DIRECTORY
means "refuse to open if not a directory". The open system call
in the kernel does a check for inode->i_op->lookup and returns
-ENOTDIR. So if
On Wed, Dec 11, 2013 at 4:48 PM, Matt Roper
wrote:
> On Mon, Nov 25, 2013 at 09:47:34AM -0500, Rob Clark wrote:
> ...
>> +static struct drm_crtc_state *
>> +drm_atomic_helper_get_crtc_state(struct drm_crtc *crtc, void *state)
>> +{
>> + struct drm_atomic_helper_state *a = state;
>> + stru
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/f0b7b8f1/attachment.html>
If you feed the tool a suitable bogus register map you can break it
in arbitary (code executing) ways. While this isn't a particularly
exciting or probable attack vector we still ought to fix it.
One of a set of sscanf issues reported by Jackie Chang
Signed-off-by: Alan Cox
---
drivers/gpu/drm/
On Wed, 11 Dec 2013 15:46:53 +0100
Thomas Hellstrom wrote:
> > I think the kernel just has to trust userspace on this. I can't think
> > of any way of not involving userspace, so if somebody really wants to
> > hack mesa to gain some fps advantage on a multiseat system, let them ;)
> >
> > Basica
https://bugzilla.kernel.org/show_bug.cgi?id=66871
--- Comment #6 from Erik Edwards ---
Created attachment 118081
--> https://bugzilla.kernel.org/attachment.cgi?id=118081&action=edit
System messages
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=66871
--- Comment #5 from Erik Edwards ---
Created attachment 118071
--> https://bugzilla.kernel.org/attachment.cgi?id=118071&action=edit
Xorg.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=66871
--- Comment #4 from Erik Edwards ---
Created attachment 118061
--> https://bugzilla.kernel.org/attachment.cgi?id=118061&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=66871
--- Comment #3 from Erik Edwards ---
I'm not sure what you mean.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Dave,
Just a bunch of regression fixes plus a few patches for long-standing
issues in gem corner-cases that we've hunted down in the past weeks. Since
apparently people hit those in the wild (and we also have nice igts for
them) I've opted for -fixes and cc: stable.
There's 1-2 things oustandi
On 11/15/2013 01:53 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This series implements a common reset framework driver for Tegra, and
> updates all relevant Tegra drivers to use it. It also removes the custom
> DMA bindings and replaced them with the standard DMA DT bindings.
>
> Histor
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/61489062/attachment.html>
On Wed, Dec 11, 2013 at 2:24 PM, Daniel Vetter
wrote:
> Cc: Patrik Jakobsson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/gma500/psb_intel_drv.h | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
> b/drivers/gpu/drm/gma500/psb_intel_d
.org/archives/dri-devel/attachments/20131211/19466503/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/3b7d4d24/attachment-0001.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/90b2544e/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/f3a14d1e/attachment.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/6bb2ad8b/attachment.html>
ll need to update all
drivers as well to make sure the signed variables don't overflow.
Perhaps unsigned long long would be a better choice for future
compatibility?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/5717e8c8/attachment.pgp>
pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131211/9ce0e72b/attachment.pgp>
https://bugzilla.kernel.org/show_bug.cgi?id=22312
--- Comment #6 from Alex Deucher ---
(In reply to Dnitry from comment #5)
> Created attachment 118051 [details]
> uname -a, lspci -v -s 01:00.0, dmesg
>
> Yes, I still have this issue. It doesn't manifest itself. Everything works
> fine except gl
https://bugzilla.kernel.org/show_bug.cgi?id=22312
Dnitry changed:
What|Removed |Added
Attachment #118051|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=22312
--- Comment #5 from Dnitry ---
Created attachment 118051
--> https://bugzilla.kernel.org/attachment.cgi?id=118051&action=edit
uname -a, lspci -v -s 01:00.0, dmesg
Yes, I still have this issue. It doesn't manifest itself. Everything works fine
e
On 12/11/2013 12:35 PM, Lauri Kasanen wrote:
> On Wed, 11 Dec 2013 12:04:05 +0900
> Michel D?nzer wrote:
>
>>> Of all the worries that exist, this is a non-issue. Userspace can
>>> simply queue a lot of draw calls that take 1 second each through the
>>> normal command submission methods, why would
On Wed, Dec 11, 2013 at 5:34 AM, Daniel Vetter
wrote:
> tilcdc already stores the drm_device in the driver data pointer. So
> use that.
>
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
> 1 file changed, 1 insertion(+
On Wed, Dec 11, 2013 at 5:34 AM, Daniel Vetter
wrote:
> The drvdata pointer is already assigned to something useful.
>
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Wed, Dec 11, 2013 at 8:20 AM, Daniel Vetter
wrote:
> Again omap already sets the driver data pointer to the drm_device.
>
> v2: Don't rip out the platform_driver_unregister call for omap_dmm_driver.
> Pesky difference between drm and dmm ...
>
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
Cc: Patrik Jakobsson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_intel_drv.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
b/drivers/gpu/drm/gma500/psb_intel_drv.h
index bde27fdb41bf..dc2c8eb030fa 100644
--- a/drivers/gpu/drm/gma5
This was hidden in a generic void * dev->mm_private. But only ever
used for gem. But thanks to this fake generic pretension no one
noticed that Rob's drm drivers are now all broken.
So just give the offset manager a type pointer and fix up msm, omapdrm
and tilcdc.
v2: Fixup compile fail.
v3: Fix
Again omap already sets the driver data pointer to the drm_device.
v2: Don't rip out the platform_driver_unregister call for omap_dmm_driver.
Pesky difference between drm and dmm ...
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
1 file changed, 1 ins
On Mon, Nov 25, 2013 at 09:47:34AM -0500, Rob Clark wrote:
...
> +static struct drm_crtc_state *
> +drm_atomic_helper_get_crtc_state(struct drm_crtc *crtc, void *state)
> +{
> + struct drm_atomic_helper_state *a = state;
> + struct drm_crtc_state *cstate;
> + int ret;
> +
> + ret =
On Wed, 11 Dec 2013 12:04:05 +0900
Michel D?nzer wrote:
> > Of all the worries that exist, this is a non-issue. Userspace can
> > simply queue a lot of draw calls that take 1 second each through the
> > normal command submission methods, why would it need to tweak some
> > obscure number to cause
https://bugzilla.kernel.org/show_bug.cgi?id=66871
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
Hi Daniel,
Thank you for the patch.
On Wednesday 11 December 2013 11:34:27 Daniel Vetter wrote:
> We need to chase one pointer here.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +++-
> 1 file change
On Fri, Nov 29, 2013 at 4:01 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote:
>
>> > Additionally the current code is broken in that the upper layer in
>> > vm/base.c doesn't increment "pte" by the right amount.
>> >
>> > Now, if those two assertions can be
I stole the conditional for _X_ATTRIBUTE_PRINTF from xproto and
changed the name to _DRM_ATTRIBUTE_PRINTF to avoid future conflicts.
Signed-off-by: Keith Packard
---
xf86drm.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/xf86drm.h b/xf86drm.h
index 1e763a3..0bf205f
Hello Dave Airlie,
The patch 925142431bd6: "drm: update VIA driver to 2.7.2" from Nov
12, 2005, leads to the following static checker warning:
drivers/gpu/drm/via/via_irq.c:242 via_driver_irq_wait()
error: buffer overflow 'masks' 4 <= 5
drivers/gpu/drm/via/via_irq.c
225
https://bugzilla.kernel.org/show_bug.cgi?id=29512
Alan changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=28902
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Die, 2013-12-10 at 12:03 +0100, Maarten Lankhorst wrote:
> op 10-12-13 01:49, Michel D?nzer schreef:
> > On Mon, 2013-12-09 at 23:45 +0100, Marek Ol??k wrote:
> >> On Mon, Dec 9, 2013 at 9:30 PM, Lauri Kasanen wrote:
> >>> Note that the hotness calculation will be in userspace, as only there
>
https://bugzilla.kernel.org/show_bug.cgi?id=27192
Alan changed:
What|Removed |Added
Component|Video(Other)|Video(DRI - non Intel)
Assignee|drivers_
https://bugzilla.kernel.org/show_bug.cgi?id=26442
Alan changed:
What|Removed |Added
Resolution|--- |OBSOLETE
Status|NEW
Hi Daniel
On Wed, Dec 11, 2013 at 11:35 AM, Daniel Vetter
wrote:
> This was hidden in a generic void * dev->mm_private. But only ever
> used for gem. But thanks to this fake generic pretension no one
> noticed that Rob's drm drivers are now all broken.
>
> So just give the offset manager a type
Fixes improperly set up display params for 2D tiling on
oland.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/rad
On Wed, Dec 11, 2013 at 11:34 AM, Daniel Vetter
wrote:
> This has the nice advantage that we'll get rid of a DRM_WAIT_ON user
> for free.
>
> Cc: Patrik Jakobsson
> Cc: Alan Cox
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/gma500/psb_irq.c | 15 ---
> 1 file changed, 15
On my HP Elitebook 8740w qith a Mobility Radeon HD 5870
commit 846ae41ae99d314bf2a02784152208a6ddf7eddc
breaks shutdown. The machine hangs when trying to shutdown, kexec or
hibernate, before seeing the usual `machine halted' (or whatever) message.
If I comment out thus:
index 9f5ff28..40bff3c 1
From: Dan Carpenter
drivers/gpu/drm/r128/r128_state.c:1014:10-17: WARNING opportunity for
memdup_user
/c/kernel-tests/src/cocci/drivers/gpu/drm/r128/r128_state.c:1029:9-16: WARNING
opportunity for memdup_user
/c/kernel-tests/src/cocci/drivers/gpu/drm/r128/r128_state.c:904:10-17: WARNING
opport
This is just used for a debugfs file, and we can easily reconstruct
this number by just walking the list twice. Which isn't really bad for
a debugfs file anyway.
So let's rip this out.
There's the other issue that the dev->vmalist itself is a bit useless,
since that can be reconstructed with all
It's racy, and it's only used in debugfs. There are simpler ways to
know whether something is going on (like looking at dmesg with full
debugging enabled). And they're all much more useful.
So let's just rip this out.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 2 --
drivers/g
Now dev->ioctl_count tries to prevent the device from disappearing if
it's still in use. And if we'd actually need this code it would be
hopelessly racy and broken.
But luckily the vfs already takes care of this. So we can just rip it
out.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dr
This was hidden in a generic void * dev->mm_private. But only ever
used for gem. But thanks to this fake generic pretension no one
noticed that Rob's drm drivers are now all broken.
So just give the offset manager a type pointer and fix up msm, omapdrm
and tilcdc.
v2: Fixup compile fail.
Cc: Dav
Especially not on modesetting drivers - this is used to size
the driver private structure for legacy drm buffers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/qxl/qxl_drv.c | 1 -
drivers/gpu/drm/radeon/radeon_drv.c | 1 -
3 files changed, 3 d
With the last patch to ditch the ->get_name callbacks the last
user is now gone.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 1 -
drivers/gpu/drm/drm_platform.c | 1 -
drivers/gpu/drm/drm_usb.c | 1 -
include/drm/drmP.h | 5 -
4 files changed, 8 deletio
The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.
The exception is usb, which used a ge
This was only ever used to pretty-print the irq driver name. And on
kms systems due to set_version bonghits we never set up the prettier
name, ever. Which make this a bit pointless.
Also, we can always dig out the driver-instance/irq relationship
through other means, so this isn't that useful. So
This is only used for drm versions 1.0, and kms drivers have never
been there. So we can appropriately restrict this to legacy and hence
pci devices and inline everything.
v2: Make the dummy function actually return something, caught by Wu
Fengguang's 0-day tester.
Signed-off-by: Daniel Vetter
-
Now that they're all unused we can get rid of them, including the
dummy version in drm_usb.c.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 6 --
drivers/gpu/drm/drm_platform.c | 6 --
drivers/gpu/drm/drm_usb.c | 6 --
include/drm/drmP.h | 1 -
4
Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.
With that we can now also remove drm_dev_to_irq from drm_irq.c.
Signed-off-by:
It's only ever called for legacy drivers, which are all pci.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 1348e041c2af..24c6590bb33e 100644
--- a/dr
To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/d
Since really that's all it protects - legacy horror stories in
drm_bufs.c. Since I don't want to waste any more time on this I didn't
bother to actually look at what it protects in there, but it's at
least contained now.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 32 ++
So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.
Unfortunately the vga switcheroo callbacks took this commen
Completely unused. Hooray, midlayer mistakes that didn't cause work to
undo!
v2: Rebase on top of the recent tegra changes which added a host1x drm
bus.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 1 -
drivers/gpu/drm/drm_platform.c | 1 -
drivers/gpu/drm/drm_usb.c |
Only used in some legacy pci drivers, and dereferncing the pci irq is
actually shorter ...
Since this removes all users for drm_dev_to_irq from the tree except
in drm_irq.c, move the inline helper in there. It'll disappear soon,
too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c
The dev->struct_mutex locking in drm_irq.c only protects
dev->irq_enabled. Which isn't really much at all and only prevents
especially nasty ums userspace from concurrently installing the
interrupt handling a few times. Or at least trying.
There are tons of unlocked readers of dev->irqs_enabled in
This just adds a correspdonding check, follow-up patches will exploit
this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f70d3b9b7b22..3f
This is a ums-only ioctl, and we've only ever supported ums (at least
in upstream) on pci devices. So no point in keeping that piece of
legacy logic abstracted within the drm bus driver.
To keep things work without CONFIG_PCI also add a dummy ioctl.
v2: Block the irq_by_busid ioctl for modeset dr
Checking for both an irq number _and_ whether it's enabled is
redundant. Also this will breakd drivers which do their own irq
management and just set dev->irq_enabled once the irq stuff is all set
up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 insertion(
Since this is all old ums stuff (including the one in the radeon
driver) I've just tried to perfectly replicate the existing semantics.
Reinventing wait queue code with semantics that differ from all the
standard linux wait functions is just hairy, so now we can get rid of
this and so make sure it
Note that I've dropped the timeout - we don't expect the display
hardware to ever hang, and the current code isn't really up to handle
this correctly anyway.
The only risk I see is that old user modesetting drivers wreak havoc
with themselves by disabling the interrupt support at the wrong time.
B
This has the nice advantage that we'll get rid of a DRM_WAIT_ON user
for free.
Cc: Patrik Jakobsson
Cc: Alan Cox
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_irq.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/
Checking directly for the right capability is simpler. Also this rids
us of a few places that use DRM_CURRENTPID.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
drivers/gpu/drm/via/via_dma.c | 4 ++--
include/drm/drm_os_linux.h| 1 -
3 files changed, 3 ins
The real linux interfaces are s much easier on the eyes ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_irq.c | 2 +-
drivers/gpu/drm/mga/mga_drv.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_dma.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dma.h | 2 +-
drivers/gpu/drm
Less yelling ftw!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_buffer.c | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
drivers/gpu/drm/mga/mga_dma.c | 4 ++--
drivers/gpu/drm/mga/mga_state.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 ++--
dr
Less yelling ftw!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c| 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c| 4 ++--
drivers/gpu/drm/mga/mga_irq.c| 4 ++--
drivers/gpu/drm/omapdrm/omap_irq.c
I've killed them a long time ago in drm/i915, let's get rid of this
remnant of shared drm core days for good.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 2 +-
drivers/gpu/drm/gma500/psb_drv.h| 2 +-
drivers/gpu/drm/gma500/psb_irq.c| 2 +-
drivers/g
We don't have any userspace interfaces that use HZ as a time unit, so
having our own DRM define is useless.
Remove this remnant from the shared drm core days.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
drive
The header provides dummy functions and
fallbacks, so no need for screaming macros.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_agpsupport.c | 8
drivers/gpu/drm/drm_memory.c | 6 +++---
include/drm/drmP.h | 5 +++--
include/drm/drm_agpsupport.h | 16 +
David Herrmann dutifully moved this locking along when moving the
agp_init call out of the generic drm_dev_register into the pci
specific load helpers.
But afaict there's no need and the reason for that locking has been
purely a historical accident - we need the lock around the driver dev
node reg
Call drm_pci_agp_destroy directly, there's no point in the
indirection. Long term we want to shuffle this into each driver's
unload logic, but that needs cleared-up drm lifetime rules first.
v2: Add a dummy function for !CONFIG_PCI, spotted my David Herrmann.
v3: Fixup for the coding style police
Wrapping a kfree is pointless.
v2: Add a comment to the kerneldoc for drm_agp_init to explain where
the kfree happens as requested by David. Note that for modeset drivers
agp cleanup is fairly complicated anyway: The drm_agp_clear is a noop
and drivers must call drm_agp_release on their own. Which
The PCI bus helper is the only user of it. Call it directly before
device-registration to get rid of the callback.
Note that all drm_agp_*() calls are locked with the drm-global-mutex so we
need to explicitly lock it during initialization. It's not really clear
why it's needed, but lets be safe.
Most place actually want to just check for dev->agp (most do, but a
few don't so this fixes a few potential NULL derefs). The only
exception is the agp init code which should check for the AGP driver
feature flag.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_agpsupport.c| 2 +-
driv
Thanks to the removal of REQUIRE_AGP we can use a void return value
and shed a bit of complexity.
Reviewed-by: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 3 +--
drivers/gpu/drm/drm_stub.c | 7 ++-
include/drm/drmP.h | 2 +-
3 files changed, 4 insert
Only the two intel drivers need this and they can easily check for
working agp support in their driver ->load callbacks.
This is the only reason why agp initialization could fail, so allows
us to rip out a bit of error handling code in the next patch.
Signed-off-by: Daniel Vetter
---
drivers/gp
Gone with the new gem vma offset manager from David.
We can also ditch the uapi header definition from the enum since
userspace never used this. It ended up in there purely for historical
reasons (for reusing the old drm mmap code essentially), not because
userspace ever needed it.
Cc: David Herr
There's really no need for the drm core to keep a list of all
devices of a given driver - the linux device model keeps perfect
track of this already for us.
The exception is old legacy ums drivers using pci shadow attaching.
So rename the lists to make the use case clearer and rip out everything
e
This very much looks like a remnant of the old legady ums shadow
attach days. Now with the last users gone we can rip it out since
we won't ever support an ums drm driver again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_platform.c | 11 ---
include/drm/drmP.h | 1
1 - 100 of 128 matches
Mail list logo