linux-stable.git/drivers/gpu/drm/via, branch linux-3.14.y

drivers: gpu: Mark function as static in via_drv.c

2014-01-14T03:05:00+00:00

Mark function as static because it is not used outside the file
drm/via/via_drv.c.

This eliminates the following warning in drm/via/via_drv.c:
drivers/gpu/drm/via/via_drv.c:49:6: warning: no previous prototype for ‘via_driver_postclose’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
Signed-off-by: Dave Airlie

drm: Kill DRM_SUSER

2013-12-18T01:35:45+00:00

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 
Signed-off-by: Dave Airlie

drm: Kill DRM_*MEMORYBARRIER

2013-12-18T01:35:21+00:00

The real linux interfaces are soooo much easier on the eyes ...

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: Kill DRM_COPY_(TO|FROM)_USER

2013-12-18T01:35:01+00:00

Less yelling ftw!

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: Kill DRM_WAKUP and DRM_INIT_WAITQUEUE

2013-12-18T01:34:13+00:00

Less yelling ftw!

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: Kill DRM_IRQ_ARGS

2013-12-18T01:33:46+00:00

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 
Signed-off-by: Dave Airlie

drm: Kill DRM_HZ

2013-12-18T01:33:24+00:00

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 
Signed-off-by: Dave Airlie

drm: Kill ctx_count from struct drm_device

2013-10-09T05:55:32+00:00

The only user of ctx_count is the via driver, and we can replace that
use with list_is_singular().

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie

drm: rip out drm_core_has_MTRR checks

2013-08-19T04:11:44+00:00

The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.

David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected drivers. David helped a lot in that. Quoting our mail
discussion:

On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann  wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter  wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann  wrote:
>>>> -#if __OS_HAS_MTRR
>>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>>> -{
>>>> -       return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>>> -}
>>>> -#else
>>>> -#define drm_core_has_MTRR(dev) (0)
>>>> -#endif
>>>> -
>>>
>>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting
>>> it in .driver_features). Any reason to keep it around?
>>
>> Yeah, I guess we could rip things out. Which will also force me to
>> properly audit drivers for the eventual behaviour change this could
>> entail (in case there's an x86 driver which did not ask for an mtrr,
>> but iirc there isn't).
>
> david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
> test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
> fi ; done
> drivers/gpu/drm/exynos
> drivers/gpu/drm/gma500
> drivers/gpu/drm/i2c
> drivers/gpu/drm/nouveau
> drivers/gpu/drm/omapdrm
> drivers/gpu/drm/qxl
> drivers/gpu/drm/rcar-du
> drivers/gpu/drm/shmobile
> drivers/gpu/drm/tilcdc
> drivers/gpu/drm/ttm
> drivers/gpu/drm/udl
> drivers/gpu/drm/vmwgfx
> david@david-mb ~/dev/kernel/linux $
>
> So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
> But I cannot tell whether they break if we call arch_phys_wc_add/del,
> anyway. At least nouveau seemed to work here, but it doesn't use AGP
> or drm_bufs, I guess.

Cool, thanks a lot for stitching together the list of drivers to look
at. So for real KMS drivers it's the drives responsibility to add an
mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
already. Somehow the savage driver also ends up doing that, I have no
idea why.

Note that gma500 as a pure KMS driver doesn't need MTRR setup since
the platforms that it supports all support PAT. So no MTRRs needed to
get wc iomappings.

The mtrr support in the drm core is all for legacy mappings of garts,
framebuffers and registers. All legacy drivers set the USE_MTRR flag,
so we're good there.

All in all I think we can really just ditch this

/endquote

v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann

v3: Rebase on top of David Herrmann's agp setup/cleanup changes.

Cc: David Herrmann 
Cc: Andy Lutomirski 
Signed-off-by: Daniel Vetter 
Acked-by: Andy Lutomirski 
Reviewed-by: David Herrmann 
Signed-off-by: Dave Airlie

drm: remove FASYNC support

2013-08-19T00:05:17+00:00

So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.

First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...

Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.

No merged drm driver has ever done that.

After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:

commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie 
Date:   Sun Aug 29 12:04:35 2004 +0000

    Drop GAMMA DRM from a great height ...

Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.

So stop this particular cargo-cult and rip it all out.

v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.

v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.

v4: Actually git add ... tsk.

Cc: Dave Airlie 
Cc: Laurent Pinchart 
Cc: Rob Clark 
Acked-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
Reviewed-by: David Herrmann 
Signed-off-by: Dave Airlie