- 10 Oct, 2013 12 commits
-
-
Ville Syrjälä authored
According to VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm p1 can be 2-3 always. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
For some reason there's a sort of off by one issue with the p1 divider. The actual p1 limits according to VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm is 2-3, so we should just say that instead of saying 1-3 and avoiding the 1 via the choice of comparison operator. I don't know why we're using different p1 limits for intel_limits_vlv_dac and intel_limits_vlv_hdmi, but let's preserve that for now. Signed-off-by:
-
Ville Syrjälä authored
We limit the maximum n divider value in order to make sure the PLL's reference inout is at least 19.2 MHz. I assume that is done to satisfy some hardware requirement. However we never check whether that calculated limit is below the maximum supoorted N divider value (7). In practice that is always true since we only support 100 MHz reference clock, but making the code safe against higher reference clocks seems like a reasoanble thing to do. Signed-off-by:
-
Ville Syrjälä authored
The p2 divider on VLV needs to be even when it's > 10. The current code to make that happen is rather weird. Just make the step size adjustement in the for loop decrement step. Signed-off-by:
-
Ville Syrjälä authored
Rewrite vlv_find_best_dpll() to use intel_clock_t rather than an army of local variables. Also extract the code to calculate the derived values into vlv_clock(). v2: Split up the earlier fixes, extract vlv_clock() v3: Initialize best_clock Signed-off-by:
-
Ville Syrjälä authored
We do 'bestppm - 10' in vlv_find_best_dpll() but never check whether that might underflow. Add such a check. Signed-off-by:
-
Ville Syrjälä authored
Use div_u64() to make the ppm calculation in vlv_find_best_dpll() safe against interger overflows. Signed-off-by:
-
Jani Nikula authored
Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Chris Wilson authored
The interface uses an unsigned long, and we can use the unsigned counter throughout our code, so do so. In the process, we notice one instance where the shrink count is based on a heuristic rather than the result, and another where we ask for too many pages to be purged. v2: nr_to_scan needs to be promoted to a long as well, so just use sc->nr_to_scan directly. Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
Since we are waiting upon IO completion, inform the kernel through use of the io_schedule() call rather than the regular schedule(). This should allow the kernel to make better decisions regarding scheduling and power management. Signed-off-by:
-
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:
-
- 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:
Dave Airlie <airlied@redhat.com>
-
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:
-
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:
-
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 2 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:
-
