kernel/drivers/gpu/drm/sis/sis_drv.c, branch linux-4.17.y

drm/pci: Deprecate drm_pci_init/exit completely

2017-06-20T08:41:03Z

The magic switching between proper pci driver and shadow-attach isn't useful anymore since there's no ums+kms drivers left. Let's split this up properly, calling pci_register_driver for kms drivers and renaming the shadow-attach init to drm_legacy_pci_init/exit. Acked-by: Thierry Reding Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-6-daniel.vetter@ffwll.ch

drm: Remove drm_driver->set_busid hook

2017-06-20T08:40:49Z

The only special-case is pci devices, and we can easily handle this in the core. Do so and drop a pile of boilerplate from drivers. Acked-by: Thierry Reding Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-5-daniel.vetter@ffwll.ch

drm: Change the return type of the unload hook to void

2017-01-09T10:25:22Z

The integer returned by the unload hook is ignored by the drm core, so let's make it void. This patch was created using the following Coccinelle semantic script (except for the declaration and comment in drm_drv.h): Compile-tested only. // @ get_name @ struct drm_driver drv; identifier fn; @@ drv.unload = fn; @ replace_type @ identifier get_name.fn; @@ - int + void fn (...) { ... } @ remove_return_param @ identifier get_name.fn; @@ void fn (...) { <... if (...) return - ... ; ...> } @ drop_final_return @ identifier get_name.fn; @@ void fn (...) { ... - return 0; } // Suggested-by: Daniel Vetter Signed-off-by: Gabriel Krisman Bertazi Acked-by: Christian König . Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170106175731.29196-1-krisman@collabora.co.uk

drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

2016-11-02T15:33:47Z

If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to check for the config everywhere. Reviewed-by: Patrik Jakobsson Signed-off-by: Jani Nikula Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/1478014844-27454-1-git-send-email-jani.nikula@intel.com

drm: Mark up legacy/dri1 drivers with DRM_LEGACY

2016-08-08T08:05:22Z

It's super confusing that new drivers need to be marked with DRIVER_MODESET when really it means DRIVER_MODERN. Much better to invert the meaning and rename it to something that's suitably off-putting. Since there's over 100 places using DRIVER_MODESET we need to roll out this change without a flag day. v2: Update docs. Reviewed-by: Frank Binns Reviewed-by: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-1-git-send-email-daniel.vetter@ffwll.ch

drm: move drm_mmap to

2014-09-24T01:43:07Z

Now that we've removed the copypasted users in gem/ttm we can relegate the legacy buffer mapping support to where it belongs. Also give it the proper drm_legacy_ prefix. While at it statify drm_mmap_locked, somehow I've missed that in my previous header rework. Signed-off-by: Daniel Vetter Reviewed-by: David Herrmann Acked-by: Alex Deucher Signed-off-by: Dave Airlie

drm: add driver->set_busid() callback

2014-09-10T07:43:04Z

One step closer to dropping all the drm_bus_* code: Add a driver->set_busid() callback and make all drivers use the generic helpers. Nouveau is the only driver that uses two different bus-types with the same drm_driver. This is totally broken if both buses are available on the same machine (unlikely, but lets be safe). Therefore, we create two different drivers for each platform during module_init() and set the set_busid() callback respectively. Signed-off-by: David Herrmann Reviewed-by: Thierry Reding Signed-off-by: Dave Airlie

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

2014-01-14T03:04:33Z

Mark function as static because it is not used outside the file drm/sis/sis_drv.c. This eliminates the following warning in drm/sis/sis_drv.c: drivers/gpu/drm/sis/sis_drv.c:97:6: warning: no previous prototype for ‘sis_driver_postclose’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria Reviewed-by: Josh Triplett Signed-off-by: Dave Airlie

drm: rip out drm_core_has_MTRR checks

2013-08-19T04:11:44Z

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:17Z

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