- 31 Oct, 2013 8 commits
-
-
Thierry Reding authored
This structure extends drm_file with Tegra DRM specific fields and has nothing to do with host1x. Rename the structure to more clearly mark the boundaries between host1x and Tegra DRM. While at it, move the structure definition out of the header. It's never used outside of the drm.c source file, so it can be defined within that. Signed-off-by:Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The host1x and Tegra DRM drivers are currently tightly coupled. Renaming the structure marks the boundary more clearly. Signed-off-by: -
Thierry Reding authored
Remove the unused host1x field from the structure and group the fields more logically. Signed-off-by: -
Thierry Reding authored
Some of the fields in struct host1x_drm haven't been used for a while, so remove them. Signed-off-by: -
Thierry Reding authored
Signed-off-by: -
Erik Faye-Lund authored
The num_relocs count are passed to the kernel per job, not per gather. For multi-gather jobs, we would previously fail if there were relocs in other gathers aside from the first one. Fix this by simply moving the check until all gathers have been consumed. Signed-off-by:
Erik Faye-Lund <kusmabite@gmail.com> Reviewed-by:
Arto Merilainen <amerilainen@nvidia.com> Acked-By:
Terje Bergstrom <tbergstrom@nvidia.com> Signed-off-by:
-
Thierry Reding authored
Fix a typo (iotcl -> ioctl) in the debug message when an unknown IOCTL is encountered. Acked-by:
David Airlie <airlied@linux.ie> Signed-off-by:
-
Thierry Reding authored
When userspace removes the active framebuffer using DRM_IOCTL_MODE_RMFB, or explicitly disables the CRTC (by calling drmModeSetCrtc(..., NULL) for example), a NULL framebuffer will be passed to the .set_config() implementation of a CRTC. The drm_crtc_helper_set_config() helper will decide to disable a CRTC when that happens. To do so, it calls drm_crtc_helper_disable(), which in turn will iterate over all encoders and decouple them from their connectors and finally call drm_helper_disable_unused_functions() to clean up and call the .disable() or .dpms() implementation for each encoder. However, at no point during this sequence does it track the DPMS mode of a connector, so it will usually remain on after this. When a connector is enabled again, drm_helper_connector_dpms() will not notice that the DPMS mode actually changed and won't do anything, which causes the connector to stay disabled indefinitely. To prevent this from happening, explicitly set the connector's DPMS mode to off when the CRTC is disabled. That way it reflects the correct state and can be enabled again. This solves an issue observed when terminating an X server running on the xf86-video-modesetting driver. Without this patch, the connector would not be enabled properly and the screen would stay dark. Acked-by:
-
- 15 Oct, 2013 2 commits
-
-
Dave Airlie authored
This will make the next patch to change how this works a lot cleaner. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
git://people.freedesktop.org/~danvet/drm-intelDave Airlie authored
New feature pile for 3.12! Highlights: - Stereo/3d support for hdmi from Damien, both the drm core bits and the i915 integration. - Manual boost/deboost logic for gpu turbo (Chris) - Fixed up clock readout support for vlv (Chris). - Tons of little fixes and improvements for vlv in general (Chon Minng Lee and Jesse Barnes). - Power well support for the legacy vga plane (Ville). - DP impromevents from Jani. - Improvements to the Haswell modeset sequence (Ville+Paulo). - Haswell DDI improvements, using the VBT for some tuning values and to check the configuration (Paulo). - Tons of other small improvements and fixups. * 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel: (92 commits) drm/i915: Use adjusted_mode in the fastboot hack to disable pfit drm/i915: Add a more detailed comment about the set_base() fastboot hack drm/i915/vlv: Turn off power gate for BIOS-less system. drm/i915/vlv: reset DPIO on load and resume v2 drm/i915: Simplify PSR debugfs drm/i915: Tweak RPS thresholds to more aggressively downclock drm/i915: Boost RPS frequency for CPU stalls drm/i915: Fix __wait_seqno to use true infinite timeouts drm/i915: Add some missing steps to i915_driver_load error path drm/i915: Clean up the ring scaling calculations drm/i915: Don't populate pipe_src_{w,h} multiple times drm/i915: implement the Haswell mode set sequence workaround drm/i915: Disable/enable planes as the first/last thing during modeset on HSW i915/vlv: untangle integrated clock source handling v4 drm/i915: fix typo s/PatherPoint/PantherPoint/ drm/i915: Make intel_resume_power_well() static drm/i915: destroy connector sysfs files earlier drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time drm/i915/dp: retry i2c-over-aux seven times on AUX DEFER drm/i915/vlv: reduce GT FIFO error info to a debug message ...
-
- 10 Oct, 2013 1 commit
-
-
Daniel Vetter authored
The conflict in intel_drv.h tripped me up a bit since a patch in dinq moves all the functions around, but another one in drm-next removes a single function. So I'ev figured backing this into a backmerge would be good. i915_dma.c is just adjacent lines changed, nothing nefarious there. Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 Oct, 2013 22 commits
-
-
Jani Nikula authored
It's not really needed, rather just adds another place to hold intermediate values that could go wrong, and it's not clear that the training pattern set or training lane set should be written at this point at all. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Jani Nikula authored
Signed-off-by:
-
Ville Syrjälä authored
The user of these counters was killed in commit d79cdc83 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:32 2013 +0200 drm: no-op out GET_STATS ioctl so clean up the leftovers as well. Signed-off-by:
-
Ville Syrjälä authored
We can get the PCI vendor and device IDs via dev->pdev. So we can drop the duplicated information. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
'map_count' and 'work' are never used. Kill them both. Signed-off-by:
-
Ville Syrjälä authored
irq_enabled is only ever 0 or 1, so make it a bool. Signed-off-by:
-
Ville Syrjälä authored
drm_vblank_init() is too ugly. Make it a bit easier on the eye by collecting all the per-crtc vblank counters, timestamps etc. to a structure and just allocate an array of those. Signed-off-by:
-
Ville Syrjälä authored
vblank_enabled is only ever 0 or 1, so make it a bool. Signed-off-by:
-
Ville Syrjälä authored
vblank_inmodeset is a bitmask, with only two bits mind you, but better make it unsigned anyway. Signed-off-by:
-
Ville Syrjälä authored
vblank_disable_allowed is only ever 0 or 1, so make it a bool. Signed-off-by:
-
Jani Nikula authored
v2: duplicate intel_connector->edid, not uninitialized edid (Dave Airlie). Signed-off-by:
-
Lespiau, Damien authored
drm_helper_probe_single_connector_modes() can be used to implement ->fill_modes(), not ->probe(). Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Chris Wilson authored
If the firmware is not builtin and userspace is not yet running, we can stall the boot process for a minute whilst the firmware loader times out. This is contrary to expectations of providing a builtin EDID! In the process, we can rearrange the code to make the error handling more resilient and prevent gcc warning about unitialised variables along the error paths. v2: Load builtins first, fix gcc second (Jani) and cosmetics (Ville). v3: Verify that we do not read beyond the end of the fwdata (Ville) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
David Herrmann authored
Analog to drm_dev_register(), we now provide drm_dev_unregister() which does the reverse. drm_dev_put() is still in place and combines the calls to drm_dev_unregister() and drm_dev_free() so buses don't have to change. *_get() and *_put() are used for reference-counting in the kernel. However, drm_dev_put() definitely does not do any kind of ref-counting. Hence, use the more appropriate *_register(), *_unregister(), *_alloc() and *_free() names. Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
-
David Herrmann authored
The error paths in DRM bus drivers currently leak memory as they don't correctly revert drm_dev_alloc(). Introduce drm_dev_free() to free DRM devices which haven't been registered, yet. We must be careful not to introduce any side-effects with cleanups done in drm_dev_free(). drm_ht_remove(), drm_ctxbitmap_cleanup() and drm_gem_destroy() are all fine in that regard. Signed-off-by:
-
David Herrmann authored
Try to keep all functions that handle DRM file_operations in drm_fops.c so internal helpers can be marked static later. This makes the split between the 3 core files more obvious: - drm_stub.c: DRM device allocation/destruction and management - drm_fops.c: DRM file_operations (except for ioctl) - drm_drv.c: Global DRM init + ioctl handling Well, ioctl handling is still spread throughout hundreds of source files, but at least the others are clearly defined this way. Signed-off-by:
-
David Herrmann authored
All bus drivers do device setup themselves. This requires us to adjust all of them if we introduce new core features. Thus, merge all these into a uniform drm_dev_register() helper. Note that this removes the drm_lastclose() error path for AGP as it is horribly broken. Moreover, no bus driver called this in any other error path either. Instead, we use the recently introduced AGP cleanup helpers. We also keep a DRIVER_MODESET condition around pci_set_drvdata() to keep semantics. [airlied: keep passing flags through so drivers don't oops on load] Signed-off-by:
-
David Herrmann authored
Instead of managing device allocation+initialization in each bus-driver, we should do that in a central place. drm_fill_in_dev() already does most of it, but also requires the global drm lock for partial AGP device registration. Split both apart so we have a clean device initialization/allocation phase, and a registration phase. Signed-off-by:
-
David Herrmann authored
All drivers embed gem-objects into their own buffer objects. There is no reason to keep drm_gem_object_alloc(), gem->driver_private and ->gem_init_object() anymore. New drivers are highly encouraged to do the same. There is no benefit in allocating gem-objects separately. Cc: Dave Airlie <airlied@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Ben Skeggs <skeggsb@gmail.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
-
David Herrmann authored
There is no reason to keep the gem object separately allocated. nouveau is the last user of gem_obj->driver_private, so if we embed it, we can get rid of 8bytes per gem-object. The implementation follows the radeon driver. bo->gem is only valid, iff the bo was created via the gem helpers _and_ iff the user holds a valid gem reference. That is, as the gem object holds a reference to the nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not guaranteed to also hold a gem reference. The gem object might get destroyed after the last user drops the gem-ref via drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a gem-reference. For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is valid. However, this shouldn't be used for real functionality to avoid gem-internal dependencies. Note that the implementation follows the previous style. However, we no longer can check for bo->gem != NULL to test for a valid gem object. This wasn't done before, so we should be safe now. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
- 04 Oct, 2013 4 commits
-
-
Damien Lespiau authored
When booting with i915.fastboot=1, we always take tha code path and end up undoing what we're trying to do with adjusted_mode. Hopefully, as the fastboot hardware readout code is using adjusted_mode as well, it should be equivalent. Signed-off-by:
-
Damien Lespiau authored
Instead of it just being on the mailing list, let's put Jesse's explanation next to the code in question. Signed-off-by:
-
Chon Ming Lee authored
During system boot up, by default, the power gate for render, media and display well still power gated. Normally, BIOS will turn off the power gate. In the BIOS-less system, the driver need to turn off the power gate very early during driver load. v2: Move this to intel_uncore_sanitize to allow it to get call during resume path. (Daniel) v3: Remove redundant write 0 to DPIO_CTL, and use DPIO_RESET instead of just 0x1 (Ville) Add turn of power gate for display 2d/render well/media well. v4: Remove toggle cmnreset in intel_uncore_sanitize. Cmnreset should toggle after CRI clock source has been selected. Jesse DPIO reset patch which toggle the cmnreset in intel_modeset_init_hw() should handle it. (Ville) Signed-off-by:Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by:
-
Jesse Barnes authored
DPIO needs to have common reset de-asserted on soft resets like boot and S3. In some cases, the BIOS will have done this for us, but it should be safe to do at runtime as well, as long as we do it when the pipes are otherwise off. v2: update bit name to match docs better (Ville) reset after CRI clock select (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=69166Signed-off-by:Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
- 03 Oct, 2013 3 commits
-
-
Rodrigo Vivi authored
for igt test case. v2: remove trailing spaces and fix conflicts Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: - make it comipile - s/IS_HASWELL/HAS_PSR/] Signed-off-by:
-
Chris Wilson authored
After applying wait-boost we often find ourselves stuck at higher clocks than required. The current threshold value requires the GPU to be continuously and completely idle for 313ms before it is dropped by one bin. Conversely, we require the GPU to be busy for an average of 90% over a 84ms period before we upclock. So the current thresholds almost never downclock the GPU, and respond very slowly to sudden demands for more power. It is easy to observe that we currently lock into the wrong bin and both underperform in benchmarks and consume more power than optimal (just by repeating the task and measuring the different results). An alternative approach, as discussed in the bspec, is to use a continuous threshold for upclocking, and an average value for downclocking. This is good for quickly detecting and reacting to state changes within a frame, however it fails with the common throttling method of waiting upon the outstanding frame - at least it is difficult to choose a threshold that works well at 15,000fps and at 60fps. So continue to use average busy/idle loads to determine frequency change. v2: Use 3 power zones to keep frequencies low in steady-state mostly idle (e.g. scrolling, interactive 2D drawing), and frequencies high for demanding games. In between those end-states, we use a fast-reclocking algorithm to converge more quickly on the desired bin. v3: Bug fixes - make sure we reset adj after switching power zones. v4: Tune - drop the continuous busy thresholds as it prevents us from choosing the right frequency for glxgears style swap benchmarks. Instead the goal is to be able to find the right clocks irrespective of the wait-boost. Signed-off-by:
-
Chris Wilson authored
If we encounter a situation where the CPU blocks waiting for results from the GPU, give the GPU a kick to boost its the frequency. This should work to reduce user interface stalls and to quickly promote mesa to high frequencies - but the cost is that our requested frequency stalls high (as we do not idle for long enough before rc6 to start reducing frequencies, nor are we aggressive at down clocking an underused GPU). However, this should be mitigated by rc6 itself powering off the GPU when idle, and that energy use is dependent upon the workload of the GPU in addition to its frequency (e.g. the math or sampler functions only consume power when used). Still, this is likely to adversely affect light workloads. In particular, this nearly eliminates the highly noticeable wake-up lag in animations from idle. For example, expose or workspace transitions. (However, given the situation where we fail to downclock, our requested frequency is almost always the maximum, except for Baytrail where we manually downclock upon idling. This often masks the latency of upclocking after being idle, so animations are typically smooth - at the cost of increased power consumption.) Stéphane raised the concern that this will punish good applications and reward bad applications - but due to the nature of how mesa performs its client throttling, I believe all mesa applications will be roughly equally affected. To address this concern, and to prevent applications like compositors from permanently boosting the RPS state, we ratelimit the frequency of the wait-boosts each client recieves. Unfortunately, this techinique is ineffective with Ironlake - which also has dynamic render power states and suffers just as dramatically. For Ironlake, the thermal/power headroom is shared with the CPU through Intelligent Power Sharing and the intel-ips module. This leaves us with no GPU boost frequencies available when coming out of idle, and due to hardware limitations we cannot change the arbitration between the CPU and GPU quickly enough to be effective. v2: Limit each client to receiving a single boost for each active period. Tested by QA to only marginally increase power, and to demonstrably increase throughput in games. No latency measurements yet. v3: Cater for front-buffer rendering with manual throttling. v4: Tidy up. v5: Sadly the compositor needs frequent boosts as it may never idle, but due to its picking mechanism (using ReadPixels) may require frequent waits. Those waits, along with the waits for the vrefresh swap, conspire to keep the GPU at low frequencies despite the interactive latency. To overcome this we ditch the one-boost-per-active-period and just ratelimit the number of wait-boosts each client can receive. Reported-and-tested-by:Paul Neumann <paul104x@yahoo.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716Signed-off-by:
-
