Commit Graph

413898 Commits

Author SHA1 Message Date
Dave Airlie d5e41ad3b9 drm/agpsupport: use kzalloc instead of kmalloc/memset
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:27:06 +10:00
Daniel Vetter 4efafebe70 drm: kill the ->agp_destroy callback
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.

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:24:39 +10:00
Daniel Vetter d6e4b28b60 drm: inline drm_agp_destroy
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 they all
seem to do properly.

Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:23:46 +10:00
Daniel Vetter 2c695fa044 drm: remove agp_init() bus callback
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.

v2: Rebase on top of the agp_init interface change.

v3: Remove the rebase-fail where I've accidentally killed the ->irq_by_busid
callback a bit too early.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:22:30 +10:00
Daniel Vetter d9906753bb drm: rip out drm_core_has_AGP
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:20:04 +10:00
Daniel Vetter 8da79ccd1a drm: ->agp_init can't fail
Thanks to the removal of REQUIRE_AGP we can use a void return value
and shed a bit of complexity.

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:18:12 +10:00
Daniel Vetter 24986ee069 drm: kill DRIVER_REQUIRE_AGP
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:17:53 +10:00
Wei Yongjun 5ec467a803 drm/rcar-du: Fix return value check in rcar_du_lvdsenc_get_resources()
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
[Remove the unneeded mem == NULL check]
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:10:48 +10:00
Thierry Reding 6b27f7f0e9 drm/dp: Use AUX constants from specification
The current values seem to be defined in a format that's specific to the
i915, gma500 and radeon drivers. To make this more generally useful, use
the values as defined in the specification.

While at it, prefix the constants with DP_ for improved namespacing.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:08:51 +10:00
Daniel Vetter 05f51722a1 drm/bufs: remove handling of _DRM_GEM mappings
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 Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:08:42 +10:00
Daniel Vetter b3f2333de8 drm: restrict the device list for shadow attached drivers
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
else.

v2: Rebase on top of David Herrmann's drm device register changes.
Also drop the bogus dev_set_drvdata for platform drivers that somehow
crept into the original version - drivers really should be in full
control of that field.

v3: Initialize driver->legacy_dev_list outside of the loop, spotted by
David Herrmann.

v4: Rebase on top of the newly created host1x drm_bus for tegra.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:08:36 +10:00
Daniel Vetter e2577d455a drm: rip out drm_platform_exit
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:06:22 +10:00
Daniel Vetter 0ff420f7f5 drm/msm: call drm_put_dev directly in ->remove
The drvdata pointer is already assigned to something useful.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:49 +10:00
Daniel Vetter 50fb3c3b2e drm/armada: directly call drm_put_dev in ->remove
Again no apparent user of the driver data field.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:48 +10:00
Daniel Vetter 405bea7a9e drm/shmob: call drm_put_dev directly from ->remove hook
We need to chase one pointer here.

Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:46 +10:00
Daniel Vetter fd3c025314 drm/omap: call drm_put_dev directly in ->remove
Again omap already sets the driver data pointer to the drm_device.

Also drop the driver unregister call, that should be (and already is)
done in the module unload hook.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:44 +10:00
Daniel Vetter c84b435657 drm/tilcdc: call drm_put_dev directly from ->remove
tilcdc already stores the drm_device in the driver data pointer. So
use that.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:43 +10:00
Daniel Vetter 9076dccfc5 drm/imx: directly call drm_put_dev in ->remove
Again no apparent user of the driver data field.

Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:41 +10:00
Daniel Vetter a9a346d6a8 drm/exynos: call drm_put_dev directly from ->remove
I didn't find any user of the driver data yet, so store the
drm_device pointer in there.

Cc: Inki Dae <inki.dae@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:40 +10:00
Daniel Vetter 57a24cf897 drm/rcar: call drm_put_dev directly in the ->remove hook
The magic dance drm_platform_exit does is actually a remnant of the
old legacy shadow attach support for platform devices. Modern modesetting
drm drivers shouldn't do this any more (and usb/pci devices actually don't
do this).

Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:05:39 +10:00
Laurent Pinchart c0c72a85c6 drm: shmob_drm: Check clk_prepare_enable() return value
The clk_prepare_enable() call can fail. Check it's return value. We
can't propagate it all the way to the user as the KMS operations in
which the clock is enabled return a void.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 11:04:40 +10:00
Thierry Reding 66ee52e284 drm: Implement dummies for debugfs helpers
In case where debugfs support is disabled, define dummy functions to
avoid the need for #ifdefery in drivers.

Based on an earlier patch by Arnd Bergmann.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 10:58:11 +10:00
Chris Wilson 46eeb2c144 video/fb: Propagate error code from failing to unregister conflicting fb
If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 10:56:13 +10:00
Ville Syrjälä 73e9efd4bd drm: Push dirtyfb ioctl kms locking down to drivers
Not all drivers will need take all the modeset locks for dirtyfb, so
push the locking down to the drivers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 10:49:08 +10:00
Kristian Hogsberg ee61c7303f drm: Don't reference objects in the flink name idr
There's no reason to keep a reference to objects in the name idr.  Each
handle to an object has a reference to the object and just before we
destroy the last handle we take the object out of the name idr.  Thus,
if an object is in the name idr, there's at least one reference to the
object.

Or to put it another way, the name idr reference will never keep the
object alive.  It just looks like it, which is confusing.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18 10:48:17 +10:00