Otherwise we not necessary export the right information.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
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 opportunity for memdup_user
/c/kernel-tests/src/cocci/drivers/gpu/drm/r128/r128_state.c:914:9-16: WARNING opportunity for memdup_user
Use memdup_user rather than duplicating its implementation
This is a little bit restricted to reduce false positives
Generated by: coccinelle/api/memdup_user.cocci
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 the memory mapping
information from proc. But remove that is a different topic entirely.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This has the nice advantage that we'll get rid of a DRM_WAIT_ON user
for free.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The real linux interfaces are soooo much easier on the eyes ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The <linux/agp_backend.h> header provides dummy functions and
fallbacks, so no need for screaming macros.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 registration to paper over the midlayer init races, and the agp
init simply ended up in there. The real fix for all this is of course
to delay the dev (and sysfs/debugfs) interface registration until
everything is fully set up.
Until then stop the cargo-cult locking from spreading and remove the
locking.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Sometimes we want to disable all the screens on a system, because that
will allow the graphics card to be put into low-power states. The
problem is that, for example, while all screens are disabled, if we
get a hotplug interrupt, fbcon will decide to set a mode instead of
keeping everything disabled, which will remove us from our low power
states.
Let's assume that if there's a DRM master, it will be able to do
whatever is appropriate when we get the hotplug.
This problem can be reproduced by the runtime PM test program from
intel-gpu-tools: we disable all the screens so the graphics device can
be put into D3, then something triggers a hotplug interrupt, fbcon
sets a mode and breaks our test suite. The problem can be reproduced
more easily by the "i2c" subtest.
Other approaches considered for the problem:
- Return "false" if "bound == 0" and the caller of
drm_fb_helper_is_bound is a hotplug handler. This would break
the case where the machine boots with no outputs connected, then
the user plugs a monitor.
- Add a new IOCTL to force fbcon to not set modes. This would keep
all the current applications behaving the same, but adding a new
IOCTL is not always the greatest idea.
- Return false only if "dev->primary->master && bound == 0". This
was my first implementation, but Chris suggested we should do
the check irrespective of the "bound" variable.
Thanks to Daniel Vetter for the investigation, ideas and the
implementation of the hotplug alternative.
v2: - Do the check first, irrespective of "bound".
- Cc dri-devel
Cc: dri-devel@lists.freedesktop.org
Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise we risk that the 2nd part of the line ends up on a line of
it's own, which means a kernel dmesg line without a log level. This
then upsets the dmesg checker in piglit.
Only really happens in some of the truly nasty igt testcases which
race cache dropping (through debugfs) with other gem operations.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Always use "void *" for arbitrary memory buffers, as this allows to drop
casts in assignments.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- some more ppgtt prep patches from Ben
- a few fbc fixes from Ville
- power well rework from Imre
- vlv forcewake improvements from Deepak S, Ville and Jesse
- a few smaller things all over
[airlied: fixup forwcewake conflict]
* tag 'drm-intel-next-2013-11-29' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits)
drm/i915: Fix port name in vlv_wait_port_ready() timeout warning
drm/i915: Return a drm_mode_status enum in the mode_valid vfuncs
drm/i915: add intel_display_power_enabled_sw() for use in atomic ctx
drm/i915: drop DRM_ERROR in intel_fbdev init
drm/i915/vlv: use parallel context restore when coming out of RC6
drm/i915/vlv: use a lower RC6 timeout on VLV
drm/i915/sdvo: Fix up debug output to not split lines
drm/i915: make sparse happy for the new vlv mmio read function
drm/i915: drop the right force-wake engine in the vlv mmio funcs
drm/i915: Fix GT wake FIFO free entries for VLV
drm/i915: Report all GTFIFODBG errors
drm/i915: Enabling DebugFS for valleyview forcewake counts
drm/i915/vlv: Valleyview support for forcewake Individual power wells.
drm/i915: Add power well arguments to force wake routines.
drm/i915: Do not attempt to re-enable an unconnected primary plane
drm/i915: add a debugfs entry for power domain info
drm/i915: add a default always-on power well
drm/i915: don't do BDW/HSW specific powerdomains init on other platforms
drm/i915: protect HSW power well check with IS_HASWELL in redisable_vga
drm/i915: use IS_HASWELL/BROADWELL instead of HAS_POWER_WELL
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Some additional fixes for 3.13. Regression fixes for audio and hw_i2c,
vram fix for some SI PX cards, race fix in the hwmon code, and a few other
odds and ends.
* 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/atom: fix bus probes when hw_i2c is set (v2)
drm/radeon: fix null pointer dereference in dce6+ audio code
drm/radeon: fixup bad vram size on SI
drm/radeon: fix VGT_GS_INSTANCE_CNT register
drm/radeon: Fix a typo in Cayman and Evergreen registers
drm/radeon/dpm: simplify state adjust logic for NI
drm/radeon: add radeon_vm_bo_update trace point
drm/radeon: add VMID allocation trace point
drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
drm/radeon: program DCE2 audio dto just like DCE3
drm/radeon: fix typo in fetching mpll params
Ensure the side-by-side (half) flag is added to any existing flags when
adding modes from 3D_Structure_ALL.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some boards seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
