summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/i915_dma.c
AgeCommit message (Collapse)Author
2013-08-05drm/i915: Create an init vmBen Widawsky
Move all the similar address space (VM) initialization code to one function. Until we have multiple VMs, there should only ever be 1 VM. The aliasing ppgtt is a special case without it's own VM (since it doesn't need it's own address space management). Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-26Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm fixes from Dave Airlie: "This is just a regular fixes pull apart from the qxl one, it has radeon and intel bits in it, The intel fixes are for a regression with the RC6 fix and a 3.10 hdmi regression, whereas radeon is more DPM fixes, a few lockup fixes and some rn50/r100 DAC fixes" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon/dpm: fix r600_enable_sclk_control() drm/radeon/dpm: implement force performance levels for rv6xx drm/radeon/dpm: fix displaygap programming on rv6xx drm/radeon/dpm: fix a typo in the rv6xx mclk setup drm/i915: initialize gt_lock early with other spin locks drm/i915: fix hdmi portclock limits drm/radeon: fix combios tables on older cards drm/radeon: improve dac adjust heuristics for legacy pdac drm/radeon: Another card with wrong primary dac adj drm/radeon: fix endian issues with DP handling (v3) drm/radeon/vm: only align the pt base to 32k drm/radeon: wait for 3D idle before using CP DMA
2013-07-26Merge tag 'pm+acpi-3.11-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management fixes from Rafael Wysocki: "These are just two fixes, a revert of the would-be backlight fix that didn't work and an intel_pstate fix for two problems related to maximum P-state selection. Specifics: - Revert of the ACPI video commit that I hoped would help fix backlight problems related to Windows 8 compatibility on some systems. Unfortunately, it turned out to cause problems to happen too. - Fix for two problems in intel_pstate, a possible failure to respond to a load change on a quiet system and a possible failure to select the highest available P-state on some systems. From Dirk Brandewie" * tag 'pm+acpi-3.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8" cpufreq / intel_pstate: Change to scale off of max P-state
2013-07-26Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"Rafael J. Wysocki
We attempted to address a regression introduced by commit a57f7f9 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which ACPI video backlight support doesn't work on a number of systems, because the relevant AML methods in the ACPI tables in their BIOSes become useless after the BIOS has been told that the OS is compatible with Windows 8. That problem is tracked by the bug entry at: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware expects Windows 8) introduced for this purpose essentially prevented the ACPI backlight support from being used if the BIOS had been told that the OS was compatible with Windows 8 and the i915 driver was loaded, in which case the backlight would always be handled by i915. Unfortunately, however, that turned out to cause problems with backlight to appear on multiple systems with symptoms indicating that i915 was unable to control the backlight on those systems as expected. For this reason, revert commit 8c5bd7a, but leave the function acpi_video_backlight_quirks() introduced by it, because another commit on top of it uses that function. References: https://lkml.org/lkml/2013/7/21/119 References: https://lkml.org/lkml/2013/7/22/261 References: https://lkml.org/lkml/2013/7/23/429 References: https://lkml.org/lkml/2013/7/23/459 References: https://lkml.org/lkml/2013/7/23/81 References: https://lkml.org/lkml/2013/7/24/27 Reported-and-tested-by: James Hogan <james@albanarts.com> Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com> Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com> Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk> Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Reported-by: Kalle Valo <kvalo@adurom.com> Tested-by: Joerg Platte <jplatte@naasa.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-25drm/i915: initialize gt_lock early with other spin locksJani Nikula
commit 181d1b9e31c668259d3798c521672afb8edd355c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 21 13:16:24 2013 +0200 drm/i915: fix up gt init sequence fallout moved dev_priv->gt_lock initialization after use. Do the initialization much earlier with other spin lock initializations. Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Cc: stable@vger.kernel.org (since the regressing patch is also cc: stable) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-25drm/i915: fix the racy object accountingDaniel Vetter
Just use a spinlock to protect them. v2: Rebase onto the new object create refcount fix patch. v3: Don't kill dev_priv->mm.object_memory as requested by Chris and hence just use a spinlock instead of atomic_t. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67287 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-25drm/i915: Colocate all GT access routines in the same fileChris Wilson
Currently, the register access code is split between i915_drv.c and intel_pm.c. It only bares a superficial resemblance to the reset of the powermanagement code, so move it all into its own file. This is to ease further patches to enforce serialised register access. v2: Scan for random abuse of I915_WRITE_NOTRACE v3: Take the opportunity to rename the GT functions as uncore. Uncore is the term used by the hardware design (and bspec) for all functions outside of the GPU (and CPU) cores in what is also known as the System Agent. v4: Rebase onto SNB rc6 fixes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Wrestle patch into applying and inline intel_uncore_early_sanitize (plus move the old comment to the new function). Also keep the _santize postfix for intel_uncore_sanitize.] [danvet: Squash in fixup spotted by Chris on irc: We need to call intel_pm_init before intel_uncore_sanitize since the later will call cancel_work on the delayed rps setup work the former initializes.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-25Merge commit 'Merge branch 'drm-fixes' of ↵Daniel Vetter
git://people.freedesktop.org/~airlied/linux' This backmerges Linus' merge commit of the latest drm-fixes pull: commit 549f3a1218ba18fcde11ef0e22b07e6365645788 Merge: 42577ca 058ca4a Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Jul 23 15:47:08 2013 -0700 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux We've accrued a few too many conflicts, but the real reason is that I want to merge the 100% solution for Haswell concurrent registers writes into drm-intel-next. But that depends upon the 90% bandaid merged into -fixes: commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access Also, we can roll up on accrued conflicts. Usually I'd backmerge a tagged -rc, but I want to get this done before heading off to vacations next week ;-) Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_gem.c v2: For added hilarity we have a init sequence conflict around the gt_lock, so need to move that one, too. Spotted by Jani Nikula. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-22Merge tag 'drm-intel-fixes-2013-07-22' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes - fixup panel fitter readout for gen2/3 (just quitens dmesg noise) - fix pft computations for non-autoscaled resolutions (i.e. letter/pillar boxing on gen2/3) - preserve the DDI A/E lane sharing bit (Stéphane Marchesin) - fix the "rc6 fails to work after resume" regression, big thanks to Konstantin Khlebnikov for the patch and debug insight about what actually might be going on here - fix Oops in is_crtc_connector_off (Chris) - sanitize shared dpll state - our new paranoid state checker tripped up over dirt left behind by the BIOS - correctly restore fences, fixes the "my screen is all messed up after resume" regression introduced in the final 3.10 pull request - quirk backlights harder, this time for Dell XPS13 machines to fix a regression (patch from Kamal Mostafa) - 90% fix for some haswell hangs when accessing registers concurrently, the 100% solution is simply too invasive for -fixes and what we have here seems to be good enough (Chris) * tag 'drm-intel-fixes-2013-07-22' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: fix up gt init sequence fallout drm/i915: Serialize almost all register access drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight drm/i915: correctly restore fences with objects attached drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() drm/i915: Sanitize shared dpll state drm/i915: fix long-standing SNB regression in power consumption after resume v2 drm/i915: Preserve the DDI_A_4_LANES bit from the bios drm/i915: fix pfit regression for non-autoscaled resolutions drm/i915: fix up readout of the lvds dither bit on gen2/3
2013-07-21drm/i915: fix up gt init sequence falloutDaniel Vetter
The regression fix for gen6+ rps fallout commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 Author: Konstantin Khlebnikov <khlebnikov@openvz.org> Date: Wed Jul 17 10:22:58 2013 +0400 drm/i915: fix long-standing SNB regression in power consumption after resume unintentionally also changed the init sequence ordering between gt_init and gt_reset - we need to reset BIOS damage like leftover forcewake references before we run our own code. Otherwise we can get nasty dmesg noise like [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. again. Since _reset suggests that we first need to have stuff initialized (which isn't the case here) call it sanitze instead. While at it also block out the rps disable introduced by the above commit on ilk: We don't have any knowledge of ilk rps being broken in similar ways. And the disable functions uses the default hw state which is only read out when we're enabling rps. So essentially we've been writing random grabage into that register. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-18ACPI / video / i915: No ACPI backlight if firmware expects Windows 8Rafael J. Wysocki
According to Matthew Garrett, "Windows 8 leaves backlight control up to individual graphics drivers rather than making ACPI calls itself. There's plenty of evidence to suggest that the Intel driver for Windows [8] doesn't use the ACPI interface, including the fact that it's broken on a bunch of machines when the OS claims to support Windows 8. The simplest thing to do appears to be to disable the ACPI backlight interface on these systems". There's a problem with that approach, however, because simply avoiding to register the ACPI backlight interface if the firmware calls _OSI for Windows 8 may not work in the following situations: (1) The ACPI backlight interface actually works on the given system and the i915 driver is not loaded (e.g. another graphics driver is used). (2) The ACPI backlight interface doesn't work on the given system, but there is a vendor platform driver that will register its own, equally broken, backlight interface if not prevented from doing so by the ACPI subsystem. Therefore we need to allow the ACPI backlight interface to be registered until the i915 driver is loaded which then will unregister it if the firmware has called _OSI for Windows 8 (or will register the ACPI video driver without backlight support if not already present). For this reason, introduce an alternative function for registering ACPI video, acpi_video_register_with_quirks(), that will check whether or not the ACPI video driver has already been registered and whether or not the backlight Windows 8 quirk has to be applied. If the quirk has to be applied, it will block the ACPI backlight support and either unregister the backlight interface if the ACPI video driver has already been registered, or register the ACPI video driver without the backlight interface otherwise. Make the i915 driver use acpi_video_register_with_quirks() instead of acpi_video_register() in i915_driver_load(). This change is based on earlier patches from Matthew Garrett, Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's. References: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Tested-by: Aaron Lu <aaron.lu@intel.com> Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Tested-by: Yves-Alexis Perez <corsac@debian.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
2013-07-17drm/i915: Create a global list of vmsBen Widawsky
After we plumb our code to support multiple address spaces (VMs), there are a few situations where we want to be able to traverse the list of all address spaces in the system. Cases like eviction, or error state collection are obvious example. v2: Delete the global link instead of the list head. While this in and of itself shouldn't be really be a problem, doing this allows us to WARN on an non-empty list, which is a problem. (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-17drm/i915: Put the mm in the parent address spaceBen Widawsky
Every address space should support object allocation. It therefore makes sense to have the allocator be part of the "superclass" which GGTT and PPGTT will derive. Since our maximum address space size is only 2GB we're not yet able to avoid doing allocation/eviction; but we'd hope one day this becomes almost irrelvant. v2: Rebased Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-17drm/i915: Move gtt and ppgtt under address space umbrellaBen Widawsky
The GTT and PPGTT can be thought of more generally as GPU address spaces. Many of their actions (insert entries), state (LRU lists), and many of their characteristics (size) can be shared. Do that. The change itself doesn't actually impact most of the VMA/VM rework coming up, it just fits in with the grand scheme of abstracting the GPU VM operations. GGTT will usually be a special case where we either know an object must be in the GGTT (dislay engine, workarounds, etc.). The scratch page is left as part of the VM (even though it's currently shared with the ppgtt code) because in the future when we have Full PPGTT, I intend to create a separate scratch page for each. v2: Drop usage of i915_gtt_vm (Daniel) Make cleanup also part of the parent class (Ben) Modified commit msg Rebased v3: Properly share scratch page (Imre) Finish commit message (Daniel, Imre) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-17drm/i915: fix long-standing SNB regression in power consumption after resume v2Konstantin Khlebnikov
This patch fixes regression in power consumtion of sandy bridge gpu, which exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that it's extremely busy. After that it never reaches rc6 state. Bug exists since kernel v3.6: commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 14 11:04:48 2012 -0700 drm/i915: load boot context at driver init time For some reason RC6 is already enabled at the beginning of resuming process. Following initliaztion breaks some internal state and confuses RPS engine. This patch disables RC6 at the beginnig of resume and initialization. I've rearranged initialization sequence, because intel_disable_gt_powersave() needs initialized force_wake_get/put and some locks from the dev_priv. Note: The culprit in the initialization sequence seems to be the write to MBCTL added in the above mentioned commit. The first version of this patch just held a forcewake reference across the clock gating init functions, which seems to have been enought to gather quite a few positive test reports. But since that smelled a bit like ad-hoc duct-tape v2 now just disables rps/rc6 across the entire hw setup. References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 References: https://bugzilla.kernel.org/show_bug.cgi?id=58971 References: https://patchwork.kernel.org/patch/2827634/ (patch v1) Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Add note about v1 vs. v2 of this patch and use standard layout for the commit citation. Also add the tested-bys from v1 and a cc: stable.] Cc: stable@vger.kernel.org (Note: tiny conflict due to the addition of the backlight lock in 3.11) Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1) Tested-by: rocko <rockorequin@hotmail.com> (v1) Tested-by: JohnMB <johnmbryant@sky.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-16drm/i915: store eLLC sizeBen Widawsky
The eLLC cannot be determined by PCIID because as far as we know, even machines supporting eLLC may not have it enabled, or fused off or whatever. It's possible this isn't actually true, and at that point we can switch to a DEV_INFO flag instead. I've defined everything where the docs are clear, and left the rest as magic. But we need it before we set the pte_encode function pointers, which happens really early, in gtt_init. The problem with just doing the normal sequence earlier is we don't have the ability to use forcewake until after the pte functions have been set up. Since all solutions are somewhat ugly (barring rewriting all the init ordering), I've opted to do the detection really early, and the enabling later - since the register to detect doesn't require forcewake. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Move dev_priv->ellc_size away from the dri1 dungeon to a nice place right next to the l3 parity stuff. Also squash in the follow-up commit to read out the eLLC size a bit earlier.] Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-11drm/i915: kill dev_priv->rps.lockDaniel Vetter
Now that the rps interrupt locking isn't clearly separated (at elast conceptually) from all the other interrupt locking having a different lock stopped making sense: It protects much more than just the rps workqueue it started out with. But with the addition of VECS the separation started to blurr and resulted in some more complex locking for the ring interrupt refcount. With this we can (again) unifiy the ringbuffer irq refcounts without causing a massive confusion, but that's for the next patch. v2: Explain better why the rps.lock once made sense and why no longer, requested by Ben. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-10drm/i915: don't frob mm.suspended when not using umsDaniel Vetter
In kernel modeset driver mode we're in full control of the chip, always. So there's no need at all to set mm.suspended in i915_gem_idle. Hence move that out into the leavevt ioctl. Since i915_gem_idle doesn't suspend gem any more we can also drop the re-enabling for KMS in the thaw function. Also clean up the handling of mm.suspend at driver load by coalescing all the assignments. Stumbled over while reading through our resume code for unrelated reasons. v2: Shovel mm.suspended into the (newly created) ums dungeon as suggested by Chris Wilson. The plan is that once we've completely stopped relying on the register save/restore code we could shovel even that in there. v3: Improve the locking for the entervt/leavevt ioctls a bit by moving the dev->struct_mutex locking outside of i915_gem_idle. Also don't clear dev_priv->ums.mm_suspended for the kms case, we allocate it with kzalloc. Both suggested by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-01drm/i915: Move gtt_mtrr to i915_gttBen Widawsky
for file in `ls drivers/gpu/drm/i915/*.c` ; do sed -i "s/mm.gtt_mtrr/gtt.mtrr/" $file; done Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-28Merge tag 'drm-intel-next-2013-06-18' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-next Last 3.11 feature pull. I have a few odds bits and pieces and fixes in my queue, I'll sort them out later on to see what's for 3.11-fixes and what's for 3.12. But nothing to hold this here up imo. Highlights: - more hangcheck work from Mika and Chris to prepare for arb robustness - trickle feed fixes from Ville - first parts of the shared pch pll rework, with some basic hw state readout and cross-checking (this shuts up the confused pch pll refcount WARN that Linus just recently forwarded) - Haswell audio power well support from Wang Xingchao (alsa bits acked by Takashi) - some cleanups and asserts sprinkling around the plane/gamma enabling sequence from Ville - more gtt refactoring from Ben - clear up the adjusted->mode vs. pixel clock vs. port clock confusion - 30bpp support, this time for real hopefully * tag 'drm-intel-next-2013-06-18' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits) drm/i915: remove a superflous semi-colon drm/i915: Kill useless "Enable panel fitter" comments drm/i915: Remove extra "ring" from error message drm/i915: simplify the reduced clock handling for pch plls drm/i915: stop killing pfit on i9xx drm/i915: explicitly set up PIPECONF (and gamma table) on haswell drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms drm/i915: set up PIPECONF explicitly on ilk-ivb drm/i915: find guilty batch buffer on ring resets drm/i915: store ring hangcheck action drm/i915: add batch bo to i915_add_request() drm/i915: change i915_add_request to macro drm/i915: add i915_gem_context_get_hang_stats() drm/i915: add struct i915_ctx_hang_stats drm/i915: Try harder to disable trickle feed on VLV drm/i915: fix up pch pll enabling for pixel multipliers drm/i915: hw state readout and cross-checking for shared dplls drm/i915: WARN on lack of shared dpll drm/i915: split up intel_modeset_check_state drm/i915: extract readout_hw_state from setup_hw_state ... Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_fb.c drivers/gpu/drm/i915/intel_sdvo.c
2013-06-13drm/i915: add struct i915_ctx_hang_statsMika Kuoppala
To count context losses, add struct i915_ctx_hang_stats for both i915_hw_context and drm_i915_file_private. drm_i915_file_private is used when there is no context. v2: renamed and cleaned up the struct (Chris Wilson, Ian Romanick) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-11Merge tag 'drm-intel-next-2013-06-01' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: Another round of drm-intel-next for 3.11. Highlights: - Haswell IPS support (Paulo Zanoni) - VECS support on Haswell (Ben Widawsky, Xiang Haihao, ...) - Haswell watermark fixes (Paulo Zanoni) - "Make the gun bigger again" multithread fence fix from Chris. - i915_error_state finnally no longer fails with -ENOMEM! Big thanks to Mika for tackling this. - vlv sideband locking fixes from Jani - Hangcheck prep work for arb_robustness support (Mika&Chris) - edp vs cpu port confusion clean-up from Imre - pile of smaller fixes and cleanups all over. * tag 'drm-intel-next-2013-06-01' of git://people.freedesktop.org/~danvet/drm-intel: (70 commits) drm/i915: add i915_ips_status debugfs entry drm/i915: add enable_ips module option drm/i915: implement IPS feature drm/i915: fix up the edp power well check drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparam drm/i915: add I915_EXEC_VEBOX to i915_gem_do_execbuffer() drm/i915: add VEBOX into debugfs drm/i915: Enable vebox interrupts drm/i915: vebox interrupt get/put drm/i915: consolidate interrupt naming scheme drm/i915: Convert irq_refounct to struct drm/i915: make PM interrupt writes non-destructive drm/i915: Add PM regs to pre/post install drm/i915: Create an ivybridge_irq_preinstall drm/i915: Create a more generic pm handler for hsw+ drm/i915: add support for 5/6 data buffer partitioning on Haswell drm/i915: properly set HSW WM_LP watermarks drm/i915: properly set HSW WM_PIPE registers drm/i915: fix pch_nop support drm/i915: Vebox ringbuffer init ...
2013-06-06i915/drm: Add private api for power well usageWang Xingchao
Haswell Display audio depends on power well in graphic side, it should request power well before use it and release power well after use. I915 will not shutdown power well if it detects audio is using. This patch protects display audio crash for Intel Haswell C3 stepping board. Signed-off-by: Wang Xingchao <xingchao.wang@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-03drm/i915: Demote unknown param to DRM_DEBUGBen Widawsky
It's not terribly interesting to know that a parameter doesn't exist, and it can get in the way of interesting messages, especially with the staggered VECS merging as we've done. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-31drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparamXiang, Haihao
This will let userland only try to use the new ring when the appropriate kernel is present Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-31drm/i915: release scratch page at module unloadImre Deak
Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-31drm/i915: Call context fini at cleanupBen Widawsky
If contexts were actually initialized, and we fail somewhere later during init this would possibly leak memory, and lead to some error messages about unclean takedown. As the odds of this occurring, and someone actually caring/noticing are pretty slim, the patch isn't terribly important. Found by code inspection while working on something else. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-31drm/i915: use drm_mm_takedownBen Widawsky
I noticed this while doing the VMA abstraction. AFAICT, it won't actually fix anything, but it is the correct thing to do. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-31drm/i915: use mappable size for fb kickoutBen Widawsky
The GTT start is either 0 in the KMS case, or some value which is set only after the init IOCTL in the UMS case. In both cases, we don't have this information until after we've tried to kick out the firmware fb. This patch should have no functional change since we kzalloc the GTT struct anyway. It only clarifies the situation for people who end up having to look at that code. This weirdness was introduced in: commit 93d187993b783c68383a884091a600d9ad499ea6 Author: Ben Widawsky <ben@bwidawsk.net> Date: Thu Jan 17 12:45:17 2013 -0800 drm/i915: Remove use of gtt_mappable_entries Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-31i915: Use arch_phys_wc_{add,del}Andy Lutomirski
i915 open-coded logic that was essentially equivalent to the new API. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-05-10drm/i915: Organize VBT stuff inside drm_i915_privateRodrigo Vivi
drm_i915_private is getting bigger and bigger when adding new vbt stuff. So, the better way of getting drm_i915_private organized is to create a special structure for vbt stuff. v2: Basically conflicts fixes Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-25drm/i915: protect backlight registers and data with a spinlockJani Nikula
Backlight data and registers are fiddled through LVDS/eDP modeset enable/disable hooks, backlight sysfs files, asle interrupts, and register save/restore. Protect the backlight related registers and driver private fields using a spinlock. The locking in register save/restore covers a little more than is strictly necessary, including non-modeset case, for simplicity. v2: Cover register access, save/restore, i915_read_blc_pwm_ctl() and code paths leading there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-23drm/i915: Introduce HAS_FPGA_DBG_UNCLAIMED()Damien Lespiau
Let's introduce one more of those orthogonal feature macros. This should hopefully make the code more readable and make things easier for new platform enabling. This time, HAS_FPGA_DBG_UNCLAIMED() is true for platforms that have bit 31 of FPGA_DBG able to signal unclaimed writes. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-23drm/i915: Replace the line of %s by a DEV_INFO_FOR_EACH_FLAG() invocationDamien Lespiau
This way, when adding a device flag we don't have to manually maintain that list. v2: undefine the helper macros (Jani Nikula, Daniel Vetter) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-23drm/i915: Turn DEV_INFO_FLAGS into a foreach style macroDamien Lespiau
DEV_INFO_FOR_FLAG() now takes 2 parameters: • A function to apply to the flag • A separator This will allow us to use the macro twice in the DRM_DEBUG_DRIVER() call of i915_dump_device_info(). v2: Fix a typo in the subject (Jani Nikula) v3: Undef the helper macros (Jani Nikula, Daniel vetter) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Map registers before GTT initBen Widawsky
This will allow us to read/write registers in GTT init. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fix up error handling. We really should look into devres for this stuff ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-06drm/i915: Support PCH no displayBen Widawsky
GEN supports a fusing option which subtracts the PCH display (making the CPU display also useless). In this configuration MMIO which gets decoded to a certain range will hang the CPU. For us, this is sort of the equivalent of having no pipes, and we can easily modify some code to not do certain things with no pipes. v2: Moved the num pipes check up in the call chain, and removed extra checks noted by Daniel. For more details, see: http://lists.freedesktop.org/archives/intel-gfx/2013-March/025746.html v3: Drop the intel_setup_overlay check (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-02drm/i915: sprite support for ValleyView v4Jesse Barnes
No constant alpha yet though, that needs a new ioctl and/or property to get/set. v2: use drm_plane_format_cpp (Ville) fix up vlv_disable_plane, remove IVB bits (Ville) remove error path rework (Ville) fix component order confusion (Ville) clean up platform init (Ville) use compute_offset_xtiled (Ville) v3: fix up more format confusion (Ville) update to new page offset function (Ville) v4: remove incorrect formats from framebuffer_init (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-23drm/i915: Move num_pipes to intel infoBen Widawsky
Requested by Daniel. v2: Fix incorrect num_pipe settings. (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20drm/i915: clear the FPGA_DBG_RM_NOCLAIM bit at driver initPaulo Zanoni
Otherwise, if the BIOS did anything wrong, our first I915_{WRITE,READ} will give us "unclaimed register" messages. V2: Even earlier. V3: Move it to intel_early_sanitize_regs. Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58897 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-14i915: ignore lid open event when resumingZhang Rui
i915 driver needs to do modeset when 1. system resumes from sleep 2. lid is opened In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes, thus it is the i915_resume code does the modeset rather than intel_lid_notify(). But in PM_SUSPEND_FREEZE state, this will be broken because system is still responsive to the lid events. 1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid. 2. When we reopen the lid, intel_lid_notify() will do a modeset, before the system is resumed. here is the error log, [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]() [92146.548076] Hardware name: VGN-Z540N [92146.548078] pipe_off wait timed out [92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G W 3.8.0-rc3-s0i3-v3-test+ #9 [92146.548175] Call Trace: [92146.548189] [<c10378e2>] warn_slowpath_common+0x72/0xa0 [92146.548227] [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915] [92146.548263] [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915] [92146.548270] [<c10379b3>] warn_slowpath_fmt+0x33/0x40 [92146.548307] [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915] [92146.548344] [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915] [92146.548380] [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915] [92146.548417] [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915] [92146.548456] [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915] [92146.548493] [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915] [92146.548535] [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915] [92146.548543] [<c15610d3>] notifier_call_chain+0x43/0x60 [92146.548550] [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80 [92146.548556] [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30 [92146.548563] [<c131a684>] acpi_lid_send_state+0x78/0xa4 [92146.548569] [<c131aa9e>] acpi_button_notify+0x3b/0xf1 [92146.548577] [<c12df56a>] ? acpi_os_execute+0x17/0x19 [92146.548582] [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc [92146.548589] [<c12e2b82>] acpi_device_notify+0x16/0x18 [92146.548595] [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f [92146.548600] [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b [92146.548607] [<c1051208>] process_one_work+0x128/0x3f0 [92146.548613] [<c1564f73>] ? common_interrupt+0x33/0x38 [92146.548618] [<c104f8c0>] ? wake_up_worker+0x30/0x30 [92146.548624] [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e [92146.548629] [<c10524f9>] worker_thread+0x119/0x3b0 [92146.548634] [<c10523e0>] ? manage_workers+0x240/0x240 [92146.548640] [<c1056e84>] kthread+0x94/0xa0 [92146.548647] [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0 [92146.548652] [<c15649b7>] ret_from_kernel_thread+0x1b/0x28 [92146.548658] [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0 three different modeset flags are introduced in this patch MODESET_ON_LID_OPEN: do modeset on next lid open event MODESET_DONE: modeset already done MODESET_SUSPENDED: suspended, only do modeset when system is resumed In this way, 1. when lid is closed, MODESET_ON_LID_OPEN is set so that we'll do modeset on next lid open event. 2. when lid is opened, MODESET_DONE is set so that duplicate lid open events will be ignored. 3. when system suspends, MODESET_SUSPENDED is set. In this case, we will not do modeset on any lid events. Plus, locking mechanism is also introduced to avoid racing. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-31drm/i915: Add probe and remove to the gtt opsBen Widawsky
The idea, and much of the code came originally from: commit 0712f0249c3148d8cf42a3703403c278590d4de5 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Jan 18 17:23:16 2013 -0800 drm/i915: Create a vtable for i915 gtt Daniel didn't like the color of that patch series, and so I asked him to start something which appealed to his sense of color. The preceding patches are those, and now this is going on top of that. [extracted from the original commit message] One immediately obvious thing to implement is our gmch probing. The init function was getting massively bloated. Fundamentally, all that's needed from GMCH probing is the GTT size, and the stolen size. It makes design sense to put the mappable calculation in there as well, but the code turns out a bit nicer without it (IMO) The intel_gtt bridge thing is still here, but the subsequent patches will finish ripping that out. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Bikeshedded one comment (GMADR is just the PCI aperture, we use it for other things than just accessing tiled surfaces through a linear view) and cut the newly added long lines a bit. Also one checkpatch error.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-20drm/i915: extract hangcheck/reset/error_state state into substructDaniel Vetter
This has been sprinkled all over the place in dev_priv. I think it'd be good to also move all the code into a separate file like i915_gem_error.c, but that's for another patch. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-20drm/i915: Remove use of gtt_mappable_entriesBen Widawsky
Mappable_end, ie. size is almost always what you want as opposed to the number of entries. Since we already have that information, we can scrap the number of entries and only calculate it when needed. If gtt_start is !0, this will have slightly different behavior. This difference can only occur in DRI1, and exists when we try to kick out the firmware fb. The new code seems like a bugfix to me. The other case where we've changed the behavior is during init we check the mappable region against our current known upper and lower limits (64MB, and 512MB). This now matches the comment, and makes things more convenient after removing gtt_mappable_entries. Also worth noting is the setting of mappable_end is taken out of setup because we do it earlier now in the DRI2 case and therefore need to add that tiny hunk to support the DRI1 IOCTL. v2: Move up mappable end to before legacy AGP init v3: Add the dev_priv inclusion here from previous rebase error in patch 5 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: squash in fix for a printk format flag mismatch warning.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-17drm/i915: Remove use on gma_bus_addr on gen6+Ben Widawsky
We have enough info to not use the intel_gtt bridge stuff. v2: Move setup of mappable_base above the legacy init stuff because we still need that on older platforms. (Daniel) v3: Remove the dev_priv hunk which was rebased in by accident Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-17drm/i915: Create a gtt structureBen Widawsky
The purpose of the gtt structure is to help isolate our gtt specific properties from the rest of the code (in doing so it help us finish the isolation from the AGP connection). The following members are pulled out (and renamed): gtt_start gtt_total gtt_mappable_end gtt_mappable gtt_base_addr gsm The gtt structure will serve as a nice place to put gen specific gtt routines in upcoming patches. As far as what else I feel belongs in this structure: it is meant to encapsulate the GTT's physical properties. This is why I've not added fields which track various drm_mm properties, or things like gtt_mtrr (which is itself a pretty transient field). Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [Ben modified commit messages] Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-17drm/i915: Use the reloc.handle as an index into the execbuffer arrayChris Wilson
Using copywinwin10 as an example that is dependent upon emitting a lot of relocations (2 per operation), we see improvements of: c2d/gm45: 618000.0/sec to 623000.0/sec. i3-330m: 748000.0/sec to 789000.0/sec. (measured relative to a baseline with neither optimisations applied). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-17drm/i915: Allow userspace to hint that the relocations were knownDaniel Vetter
Userspace is able to hint to the kernel that its command stream and auxiliary state buffers already hold the correct presumed addresses and so the relocation process may be skipped if the kernel does not need to move any buffers in preparation for the execbuffer. Thus for the common case where the allotment of buffers is static between batches, we can avoid the overhead of individually checking the relocation entries. Note that this requires userspace to supply the domain tracking and requests for workarounds itself that would otherwise be computed based upon the relocation entries. Using copywinwin10 as an example that is dependent upon emitting a lot of relocations (2 per operation), we see improvements of: c2d/gm45: 618000.0/sec to 632000.0/sec. i3-330m: 748000.0/sec to 830000.0/sec. (measured relative to a baseline with neither optimisations applied). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Fixup merge conflict in userspace header due to different baseline trees.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-17Merge tag 'drm-intel-next-2012-12-21' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: - seqno wrap fixes and debug infrastructure from Mika Kuoppala and Chris Wilson - some leftover kill-agp on gen6+ patches from Ben - hotplug improvements from Damien - clear fb when allocated from stolen, avoids dirt on the fbcon (Chris) - Stolen mem support from Chris Wilson, one of the many steps to get to real fastboot support. - Some DDI code cleanups from Paulo. - Some refactorings around lvds and dp code. - some random little bits&pieces * tag 'drm-intel-next-2012-12-21' of git://people.freedesktop.org/~danvet/drm-intel: (93 commits) drm/i915: Return the real error code from intel_set_mode() drm/i915: Make GSM void drm/i915: Move GSM mapping into dev_priv drm/i915: Move even more gtt code to i915_gem_gtt drm/i915: Make next_seqno debugs entry to use i915_gem_set_seqno drm/i915: Introduce i915_gem_set_seqno() drm/i915: Always clear semaphore mboxes on seqno wrap drm/i915: Initialize hardware semaphore state on ring init drm/i915: Introduce ring set_seqno drm/i915: Missed conversion to gtt_pte_t drm/i915: Bug on unsupported swizzled platforms drm/i915: BUG() if fences are used on unsupported platform drm/i915: fixup overlay stolen memory leak drm/i915: clean up PIPECONF bpc #defines drm/i915: add intel_dp_set_signal_levels drm/i915: remove leftover display.update_wm assignment drm/i915: check for the PCH when setting pch_transcoder drm/i915: Clear the stolen fb before enabling drm/i915: Access to snooped system memory through the GTT is incoherent drm/i915: Remove stale comment about intel_dp_detect() ... Conflicts: drivers/gpu/drm/i915/intel_display.c
2012-12-18drm/i915: fixup overlay stolen memory leakDaniel Vetter
We need to clean up the overlay first, before taking down the stolen memory allocator. This regression has been introducec in commit 8040513870399f1cb032cb8bc805df5042fedcdf Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 15 11:32:29 2012 +0000 drm/i915: Allocate overlay registers from stolen memory v2: Rework the patch a bit as suggested by Chris Wilson: - move the overlay teardown up, into the modeset cleanup - move the stolen mm takedown into i915_gem_cleanup_stolen Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 13:43:36 +0000