summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* drm: rip out DRM_AGP_MEM and DRM_AGP_KERNDaniel Vetter2013-12-182-7/+7
| | | | | | | | 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>
* drm: remove global_mutex locking around agp_initDaniel Vetter2013-12-181-4/+0
| | | | | | | | | | | | | | | | | | | | 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>
* drm/agpsupport: use kzalloc instead of kmalloc/memsetDave Airlie2013-12-181-5/+2
| | | | Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: kill the ->agp_destroy callbackDaniel Vetter2013-12-182-4/+4
| | | | | | | | | | | | | | | 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>
* drm: inline drm_agp_destroyDaniel Vetter2013-12-182-16/+4
| | | | | | | | | | | | | | | 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>
* drm: remove agp_init() bus callbackDaniel Vetter2013-12-182-10/+10
| | | | | | | | | | | | | | | | | | | 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>
* drm: rip out drm_core_has_AGPDaniel Vetter2013-12-186-14/+11
| | | | | | | | | | 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>
* drm: ->agp_init can't failDaniel Vetter2013-12-182-7/+3
| | | | | | | | | 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>
* drm: kill DRIVER_REQUIRE_AGPDaniel Vetter2013-12-185-8/+11
| | | | | | | | | | | 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>
* drm/rcar-du: Fix return value check in rcar_du_lvdsenc_get_resources()Wei Yongjun2013-12-181-11/+2
| | | | | | | | | | | | 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>
* drm/dp: Use AUX constants from specificationThierry Reding2013-12-183-53/+57
| | | | | | | | | | | | | 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>
* drm/bufs: remove handling of _DRM_GEM mappingsDaniel Vetter2013-12-182-9/+0
| | | | | | | | | | | | | | 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>
* drm: restrict the device list for shadow attached driversDaniel Vetter2013-12-185-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm: rip out drm_platform_exitDaniel Vetter2013-12-181-11/+0
| | | | | | | | | 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>
* drm/msm: call drm_put_dev directly in ->removeDaniel Vetter2013-12-181-1/+1
| | | | | | | | | 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>
* drm/armada: directly call drm_put_dev in ->removeDaniel Vetter2013-12-181-1/+2
| | | | | | | | 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>
* drm/shmob: call drm_put_dev directly from ->remove hookDaniel Vetter2013-12-181-1/+3
| | | | | | | | | 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>
* drm/omap: call drm_put_dev directly in ->removeDaniel Vetter2013-12-181-2/+2
| | | | | | | | | | | 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>
* drm/tilcdc: call drm_put_dev directly from ->removeDaniel Vetter2013-12-181-1/+1
| | | | | | | | | | 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>
* drm/imx: directly call drm_put_dev in ->removeDaniel Vetter2013-12-181-1/+3
| | | | | | | | | | 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>
* drm/exynos: call drm_put_dev directly from ->removeDaniel Vetter2013-12-181-1/+3
| | | | | | | | | | 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>
* drm/rcar: call drm_put_dev directly in the ->remove hookDaniel Vetter2013-12-181-1/+3
| | | | | | | | | | | | 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>
* drm: shmob_drm: Check clk_prepare_enable() return valueLaurent Pinchart2013-12-181-4/+14
| | | | | | | | | | 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>
* video/fb: Propagate error code from failing to unregister conflicting fbChris Wilson2013-12-181-10/+21
| | | | | | | | | | | | | 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>
* drm: Push dirtyfb ioctl kms locking down to driversVille Syrjälä2013-12-185-8/+37
| | | | | | | | | | 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>
* drm: Don't reference objects in the flink name idrKristian Hogsberg2013-12-181-15/+0
| | | | | | | | | | | | | | | 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>
* drm: do not steal the display if we have a masterPaulo Zanoni2013-12-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm: Don't split up debug outputDaniel Vetter2013-12-181-3/+9
| | | | | | | | | | | | | 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>
* drm/edid: Make edid_load() return a void *Geert Uytterhoeven2013-12-181-2/+2
| | | | | | | | | 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>
* Merge tag 'drm-intel-next-2013-11-29' of ↵Dave Airlie2013-12-1839-1184/+2069
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next - 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
| * drm/i915: Fix port name in vlv_wait_port_ready() timeout warningVille Syrjälä2013-11-291-1/+1
| | | | | | | | | | | | | | | | We're currently misprinting the port name when vlv_wait_port_ready() times out. Fix it by using port_name(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Return a drm_mode_status enum in the mode_valid vfuncsDamien Lespiau2013-11-287-13/+19
| | | | | | | | | | | | | | | | We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add intel_display_power_enabled_sw() for use in atomic ctxImre Deak2013-11-284-13/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm we call intel_display_power_enabled() from i915_capture_error_state() in IRQ context and then take a mutex. To fix this add a new intel_display_power_enabled_sw() which returns the domain state based on software tracking as opposed to reading the actual HW state. Since we use domain_use_count for this without locking on the reader side make sure we increase the counter only after enabling all required power wells and decrease it before disabling any of these power wells. Regression introduced in commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c Author: Imre Deak <imre.deak@intel.com> Date:   Tue Sep 24 16:17:09 2013 +0300     drm/i915: support for multiple power wells Note that atm we depend on the value returned by intel_display_power_enabled_sw() in i915_capture_error_state() to avoid unclaimed register access reports. This was never guaranteed though, since another thread can disable the power concurrently. If this is a problem we need another explicit way to disable the reporting during error captures. v2: - remove barriers as the caller can't depend on the value returned from i915_capture_error_state_sw() anyway (Ville) - dump the state of pipe/transcoder power domain state (Daniel) Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: drop DRM_ERROR in intel_fbdev initJesse Barnes2013-11-281-1/+2
| | | | | | | | | | | | | | | | | | | | This should just be a debug. Add another debug msg to the inherit path while we're at it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72098 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: use parallel context restore when coming out of RC6Jesse Barnes2013-11-282-1/+2
| | | | | | | | | | | | | | | | | | | | Setting this bit restores all ring contexts in parallel rather than serially. Matches current BWG recommendations. Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Deepak S <deepak.s@inel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: use a lower RC6 timeout on VLVJesse Barnes2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We use timeout mode, and we need to lower the timeout to get good RC6 residency when loads are running. This gets me from 0% residency during glxgears to 77%, which is a pretty good improvement. This value also matches the current BWG recommentations. Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Deepak S <deepak.s@inel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/sdvo: Fix up debug output to not split linesDaniel Vetter2013-11-281-18/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | It leads to a big mess when stuff interleaves. Especially with the new patch I've submitted for the drm core to no longer artificially split up debug messages. v2: The size parameter to snprintf includes the terminating 0, but the return value does not. Adjust the logic accordingly. Spotted by Mika. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: make sparse happy for the new vlv mmio read functionDaniel Vetter2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | It doesn't like that we assign 0 to a pointer, it wants the real NULL. On closer look that initialization is actually bogus, and the compiler can easily see that we never use it unitialized. So let's just drop this. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: drop the right force-wake engine in the vlv mmio funcsDaniel Vetter2013-11-281-1/+1
| | | | | | | | | | | | | | | | This was fumbled in the conversion to per-engine forcewake. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix GT wake FIFO free entries for VLVVille Syrjälä2013-11-282-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | On VLV the GTFIFOCTL register has other bits besides the number of free entries in the GT wake FIFO. Apply a mask when we read th register to make sure we don't misinterpret the number of free FIFO entries. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: There's some unclarity about hsw, but brushed off as todays' Bspec just acting up a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Report all GTFIFODBG errorsVille Syrjälä2013-11-282-4/+6
| | | | | | | | | | | | | | | | On VLV GTFIFODBG has more bits. Just report them all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Enabling DebugFS for valleyview forcewake countsDeepak S2013-11-281-3/+11
| | | | | | | | | | | | | | | | | | Forcewake counts for valleyview are not exposed throgh DebugFS. Exposing with this change. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/vlv: Valleyview support for forcewake Individual power wells.Deepak S2013-11-283-31/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split vlv force wake routines to help individually control Media/Render well based on the register access. We've seen power savings in the lower sub-1W range on workloads that only need on of the power wells, e.g. glbenchmark, media playback Note: The same split isn't there for the forcewake queue, only the forcwake domains are split. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Rebase on top of the removed forcewake hack in the ring irq get/put code and add a note to add Deepak's answer to Chris question.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Add power well arguments to force wake routines.Deepak S2013-11-286-38/+56
| | | | | | | | | | | | | | | | | | | | | | | | Added power well arguments to all the force wake routines to help us individually control power well based on the scenario. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict with the removed forcewake hack and drop one spurious hunk Jesse noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Do not attempt to re-enable an unconnected primary planeChris Wilson2013-11-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to user fudging (for instance using video=VGA-1:e with FBDEV=n) we can attempt to reset an inconsistent CRTC that is marked as active but has no assigned fb. It would be wise to fix this earlier, but the long term plan is to have primary and secondary planes associated with a CRTC, in which crtc->fb being NULL will be expected. So for a quick short term fix with pretensions of grandeur, just check for a NULL fb during GPU reset and ignore the plane restoration. This fixes a potential hard hang (a panic in the panic handler) following a GPU hang. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Add a corresponding fixme comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add a debugfs entry for power domain infoImre Deak2013-11-263-0/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a debugfs entry showing the use-count for all power domains of each power well. v3: address comments from Paulo: - simplify power_domain_str() by using a switch table - move power_well::domain_count to power_domains - WARN_ON decrementing a 0 refcount Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add a default always-on power wellImre Deak2013-11-263-31/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we distinguished platforms without a dynamic power well with the HAS_POWER_WELL macro and for such platforms we didn't call any power domain functions. Instead of doing this check we can add an always-on power well for these platforms and call the power domain functions unconditionally. For always-on power wells we only increase/decrease their refcounts, otherwise they are nop. This makes high level driver code more readable and as a bonus provides some idea of the current power domains state for all platforms (once the relevant debugfs entry is added). v3: rename intel_power_wells to i9xx_always_on_power_well (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: don't do BDW/HSW specific powerdomains init on other platformsImre Deak2013-11-261-0/+3
| | | | | | | | | | | | Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: protect HSW power well check with IS_HASWELL in redisable_vgaJesse Barnes2013-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This may need work if other platforms do the same thing, but in the meantime we should avoid looking at HSW specific bits in this generic function. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [added IS_BROADWELL too as that needs the same handling (Imre)] Signed-off-by: Imre Deak <imre.deak@intel.com> [danvet: Add Imre's missing sob.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: use IS_HASWELL/BROADWELL instead of HAS_POWER_WELLImre Deak2013-11-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In intel_display_capture_error_state we use HAS_POWER_WELL to check if we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER which is specific to these platforms. Future platforms with power wells don't have this register, so HAS_POWER_WELL won't work there any more. Use IS_HASWELL/IS_BROADWELL instead. v3: fix using logical || instead of bitwise | (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-01 04:10:06 +0100