aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2013-12-17drm/i915: Try to fix the messy IVB sprite scaling workaroundVille Syrjälä
We now have a very clear method of disabling LP1+ wartermarks, and we can actually detect if we actually did disable them, or if they were already disabled. Use that to clean up the WaCxSRDisabledForSpriteScaling:ivb handling. I was hoping to apply the workaround in a way that wouldn't require a blocking wait, but sadly IVB really does appear to require LP1+ watermarks to be off for an entire frame before enabling sprite scaling. Simply disabling LP1+ watermarks during the previous frame is not enough, no matter how early in the frame we do it :( Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Move ILK/SNB/IVB over to the HSW WM codeVille Syrjälä
The new HSW watermark code can now handle ILK/SNB/IVB as well, so switch them over. Kill the old code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Disable LP1+ watermarks safely in initVille Syrjälä
ILK doesn't like if we just write the LP1+ watermarks registers with 0. We need to just disable the watermarks by clearing the enable bit. Use that method also when disabling LP1+ watermarks in init_clock_gating. It looks like disabling the sprite LP1 watermarks can cause underruns even if we just toggle the WM1S_LP_EN bit. So treat that bit like the actual watermark numbers and avoid setting it to 0 immediately. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Linetime watermarks are a HSW featureVille Syrjälä
Linetime watermarks don't exist on ILK/SNB/IVB, so don't compute them except on HSW. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Disable FBC WM on ILK, and disable LP2+ when FBC is enabledVille Syrjälä
ILK has a bunch of issues with FBC. First of all, BSpec tells us that FBC WM should never be enabled. Secondly when FBC is enabled with FBC WM disabled, LP2+ watermarks must be disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Don't merge LP1+ watermarks on ILK/SNB/IVB when multiple pipes are ↵Ville Syrjälä
enabled Multi-pipe LP1+ watermarks are a HSW+ feature, so let's not do it on earlier generations. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Fix LP1+ watermark disabling ILKVille Syrjälä
On ILK disabling LP1+ watermarks must be done carefully to avoid underruns. If we just write 0 to the register in the middle of the scan cycle we often get an underrun. So instead we have to leave the actual watermark levels in the register intact, and just toggle the enable bit. Presumably the hardware takes a while to get out of low power mode, and so the watermark level need to stay valid until that time. We also have to be careful with the WM1S_LP_EN bit. It seems the hardware more or less treats it like the actual watermarks numbers, and so we must not toggle it too soon. Just leave it alone when disabling the LP1+ watermarks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Fix LP1 sprite watermarks for ILK/SNBVille Syrjälä
ILK/SNB don't have LP2+ watermarks for sprites. Also the LP1 sprite watermark register has its own enable bit. Take these differences into account when programming the LP1+ registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Avoid computing invalid WM levels when sprites/scaling is enabledVille Syrjälä
On ILK/SNB only LP0/1 watermarks can be enabled when sprites are enabled, and on ILK/SNB/IVB sprite scaling is limited to LP0 only. So we can avoid computing the extra levels we're never going to use. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Add ILK/SNB/IVB WM latency field supportVille Syrjälä
Add a new function ilk_wm_lp_latency() which will tell us what to write into the WM_LPx register latency field. HSW is different from erlier gens in this regard. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Add IVB DDB partitioning controlVille Syrjälä
On IVB the display data buffer partitioning control lives in the DISP_ARB_CTL2 register. Add the relevant defines/code for it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: kick firmware fbs even when i915 fbdev is disabledDaniel Vetter
Otherwise we don't kick out firmware framebuffers like vesafb and efifb when CONFIG_DRM_I915_FBDEV=n but CONFIG_FB=y. There's still the pesky issue with vgacon which we should somehow replace with the dummy console at least. We have a similar issue at module un/reload, since vgacon state is terminally botched after i915.ko has loaded in modeset mode. But this gets us a step further at least. v2: Use IS_ENABLED - I always get this wrong for tristates. Spotted by Jani. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Use IS_VALLEYVIEW() to test the is_valleyview flagDamien Lespiau
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Use symbolic names for booleans in i915_semaphore_is_enabledDaniel Vetter
Noticed while reviewing a patch and couldn't resist the OCD. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Don't emit mbox updates without semaphoresBen Widawsky
Aside from the fact that it leaves confusing dumps on error capture, it is entirely unnecessary, and potentially harmful in cases like BDW, where the instruction has changed. In reality (seemingly), this will have no behavioral impact. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915: Reorder/respace MI instruction definitionBen Widawsky
A few command were out of numerical order and had different spacing. Put them back in numerical order, with proper spacing. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915/vlv: split DPIO init and resetJesse Barnes
We only need to init the reg offset for DPIO once, but we need to reset DPIO at resume time and at init time. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/i915/vlv: add early DPIO init v3Jesse Barnes
Just add an early init since we may need to access DPIO regs early on. The init call in modeset_init_hw is also needed for the resume case, when we need to reset DPIO to keep things happy. v2: split reset and reg init v3: split patches (Daniel) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebookRafał Miłecki
This bug in EDID was exposed by: commit eccea7920cfb009c2fa40e9ecdce8c36f61cab66 Author: Alex Deucher <alexander.deucher@amd.com> Date: Mon Mar 26 15:12:54 2012 -0400 drm/radeon/kms: improve bpc handling (v2) Which resulted in kind of regression in 3.5. This fixes https://bugs.freedesktop.org/show_bug.cgi?id=70934 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-17Merge branch 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie
into drm-next A single ttm vm fix. * 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/ttm: Fix accesses through vmas with only partial coverage
2013-12-16drm/ttm: Fix accesses through vmas with only partial coverageThomas Hellstrom
VMAs covering a bo but that didn't start at the same address space offset as the bo they were mapping were incorrectly generating SEGFAULT errors in the fault handler. Reported-by: Joseph Dolinak <kanilo2@yahoo.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Cc: stable@vger.kernel.org
2013-12-16drm/i915: only build i915_debugfs.c when CONFIG_DEBUG_FS is enabledJani Nikula
The whole file is wrapped around in #if defined(CONFIG_DEBUG_FS) anyway, so skip the file at the build level already. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-16drm/i915: fix return value check of debugfs_create_file()Wei Yongjun
In case of error, the function debugfs_create_file() returns NULL pointer not ERR_PTR() if debugfs is enabled. The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-16drm/i915: parse backlight modulation frequency from the BIOS VBTJani Nikula
We don't actually do anything with the information yet, but parse and log what's in the VBT. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-16drm/nouveau: only runtime suspend by default in optimus configurationIlia Mirkin
The intent was to only enable it by default for optimus, e.g. see the runtime_idle callback. The suspend callback may be called directly, e.g. as a result of nouveau_crtc_set_config. Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-15radeon_pm: fix oops in hwmon_attributes_visible() and ↵Sergey Senozhatsky
radeon_hwmon_show_temp_thresh() Since commit ec39f64bba34 ("drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups") radeon_hwmon_init() is using hwmon_device_register_with_groups(), which sets `rdev' as a device private driver_data, while hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'. Fix them by using dev_get_drvdata(), in order to avoid this oops: BUG: unable to handle kernel paging request at 0000000000001e28 IP: [<ffffffffa02ae8b4>] hwmon_attributes_visible+0x18/0x3d [radeon] PGD 15057e067 PUD 151a8e067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Call Trace: internal_create_group+0x114/0x1d9 sysfs_create_group+0xe/0x10 sysfs_create_groups+0x22/0x5f device_add+0x34f/0x501 device_register+0x15/0x18 hwmon_device_register_with_groups+0xb5/0xed radeon_hwmon_init+0x56/0x7c [radeon] radeon_pm_init+0x134/0x7e5 [radeon] radeon_modeset_init+0x75f/0x8ed [radeon] radeon_driver_load_kms+0xc6/0x187 [radeon] drm_dev_register+0xf9/0x1b4 [drm] drm_get_pci_dev+0x98/0x129 [drm] radeon_pci_probe+0xa3/0xac [radeon] pci_device_probe+0x6e/0xcf driver_probe_device+0x98/0x1c4 __driver_attach+0x5c/0x7e bus_for_each_dev+0x7b/0x85 driver_attach+0x19/0x1b bus_add_driver+0x104/0x1ce driver_register+0x89/0xc5 __pci_register_driver+0x58/0x5b drm_pci_init+0x86/0xea [drm] radeon_init+0x97/0x1000 [radeon] do_one_initcall+0x7f/0x117 load_module+0x1583/0x1bb4 SyS_init_module+0xa0/0xaf Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-14drm/i915: add runtime PM support on HaswellPaulo Zanoni
Now that all the infrastructure is in place and all the tests from pm_pc8 pass, we can finally enable the feature. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-14drm/i915: release the GTT mmaps when going into D3Paulo Zanoni
So we'll get a fault when someone tries to access the mmap, then we'll wake up from D3. v2: - Rebase v3: - Use gtt active/inactive Testcase: igt/pm_pc8/gem-mmap-gtt Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add comment + WARN as discussed with Paulo on irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-14drm/i915: cancel the hangcheck before runtime suspendPaulo Zanoni
The hangcheck function requires the hardware to be working, and if we're suspending we're going to put the HW in D3 state. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm/i915: get a PC8 reference when enabling the power wellPaulo Zanoni
In the current code, at haswell_modeset_global_resources, first we decide if we want to enable/disable the power well, then we decide if we want to enable/disable PC8. On the case where we're enabling PC8 this works fine, but on the case where we disable PC8 due to a non-eDP monitor being enabled, we first enable the power well and then disable PC8. Although wrong, this doesn't seem to be causing any problems now, and we don't even see anything in dmesg. But the patches for runtime D3 turn this problem into a real bug, so we need to fix it. This fixes the "modeset-non-lpsp" subtest from the "pm_pc8" test from intel-gpu-tools. v2: - Rebase (i915_disable_power_well). v3: - More reabase. v4: - Rebase on top of -fixes instead of -nightly. This is commit d62292c8f778772d1b6ec125d461c8c16fdc0417 in -next, but we need it in -fixes to address Dave's report. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reported-by: Dave Jones <davej@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm/i915: change CRTC assertion on LCPLL disablePaulo Zanoni
Currently, PC8 is enabled at modeset_global_resources, which is called after intel_modeset_update_state. Due to this, there's a small race condition on the case where we start enabling PC8, then do a modeset while PC8 is still being enabled. The racing condition triggers a WARN because intel_modeset_update_state will mark the CRTC as enabled, then the thread that's still enabling PC8 might look at the data structure and think that PC8 is being enabled while a pipe is enabled. Despite the WARN, this is not really a bug since we'll wait for the PC8-enabling thread to finish when we call modeset_global_resources. The spec says the CRTC cannot be enabled when we disable LCPLL, so we had a check for crtc->base.enabled. If we change to crtc->active we will still prevent disabling LCPLL while the CRTC is enabled, and we will also prevent the WARN above. This is a replacement for the previous patch named "drm/i915: get/put PC8 when we get/put a CRTC" Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (cherry picked from commit 798183c54799fbe1e5a5bfabb3a8c0505ffd2149 from -next due to Dave's report.) Reported-by: Dave Jones <davej@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm/i915/bdw: Implement ff workaroundsBen Widawsky
WaVSRefCountFullforceMissDisable and WaDSRefCountFullforceMissDisable VS is a carry-over from HSW, and DS is likely not used by anyone yet. Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Line of 106 chars is too long. Really.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm/i915/bdw: Force all Data Cache Data Port access to be Non-CoherentBen Widawsky
I stumbled on to some unimplemented errata. To be honest, I am not really sure of the impact, just that the docs say to do. No w/a name for this one. v2: v1 was a stale thing which should have never seen the light of day. (Haihao) Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm/i915/bdw: Don't use forcewake needlesslyVille Syrjälä
Not all registers need forcewake even if they're not shadowed. Add the missing check to gen8_writeX() to avoid needless forcewake usage when writing eg. display registers. v2: Use straight up <0x40000 check instead of NEEDS_FORCE_WAKE() Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm/i915: Clear out old GT FIFO errors in intel_uncore_early_sanitize()Ville Syrjälä
The BIOS or someone else might have done something bad and there might be old GT FIFO erros reported in GTFIFODBG. Clear those out in intel_uncore_early_sanitize() to make sure we don't mistake them for our problems. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13drm: don't double-free on driver load errorIlia Mirkin
All instances of drm_dev_register are followed by drm_dev_free on failure. Don't free dev->control/render/primary on failure, as they will be freed by drm_dev_free since commit 8f6599da8e (drm: delay minor destruction to drm_dev_free()). Instead unplug them. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reported-and-tested-by: Bruno Prémont <bonbons@linux-vserver.org> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-13Merge branch 'vmwgfx-fixes-3.13' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-fixes Part of a driver stack fix that fixes surface overcommiting on single execbuf calls. * 'vmwgfx-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Add max surface memory param
2013-12-12drm/i915: dont call irq_put when irq test is onMika Kuoppala
If test is running, irq_get was not called so we should gain balance by not doing irq_put "So the rule is: if you access unlocked values, you use ACCESS_ONCE(). You don't say "but it can't matter". Because you simply don't know." -- Linus v2: use local variable so it can't change during test (Chris) v3: update commit msg and use ACCESS_ONCE (Ville) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12drm/i915: Rework the FBC interval/stall stuff a bitVille Syrjälä
Don't touch DPFC_RECOMP_CTL on FBC2, use RMW to update the FBC_CONTROL on FBC1 to make it easier for people to experiment with different numbers. Also fix the interval mask for FBC1. v2: Rebased Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12Revert "drm/radeon: Implement radeon_pci_shutdown"Alex Deucher
This causes a race condition between drm_dev_unregister() and pci_driver.shutdown at shutdown or driver unload time. We need to revisit how to properly support kexec within the drm. This reverts commit 846ae41ae99d314bf2a02784152208a6ddf7eddc.
2013-12-12drm/radeon: add missing display tiling setup for olandAlex Deucher
Fixes improperly set up display params for 2D tiling on oland. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-12-12drm/radeon: fix typo in cik_copy_dmaChristian König
Otherwise we end up with a rather strange looking result. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Tom Stellard <thomas.stellard@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-12-12drm/radeon/cik: plug in missing blit callbackAlex Deucher
I implemented support for this, but forget to hook up the callback so the driver can actually use it. On asics with a dedicated DMA engine, we use the DMA engine for buffer migration so this is just for testing purposes. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-12-12drm/radeon/dpm: Fix hwmon crashMartin Andersson
Commit ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d (drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups) converted one usage of dev_get_drvdata, but there were two more. bug: https://bugs.freedesktop.org/show_bug.cgi?id=72457 Signed-off-by: Martin Andersson <g02maran@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-12-12drm/i915: Enable FBC for all mobile gen2 and gen3 platformsVille Syrjälä
All mobile gen2 and gen3 chipsets should have FBC1, and the code should now handle them all. So just set has_fbc=true for all such chipsets. Note that fbc is still disabled by default for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12drm/i915: FBC_CONTROL2 is gen4 onlyVille Syrjälä
Gen2 and gen3 don't have the FBC_CONTROL2 register, so don't touch it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12drm/i915: Gen2 FBC1 CFB pitch wants 32B unitsVille Syrjälä
On gen2 the compressed frame buffer pitch is specified in 32B units rather than the 64B units used on gen3+. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12drm/i915: split intel_ddi_pll_mode_set in 2 piecesPaulo Zanoni
The first piece, intel_ddi_pll_select, finds a PLL and assigns it to the CRTC, but doesn't write any register. It can also fail in case it doesn't find a PLL. The second piece, intel_ddi_pll_enable, uses the information stored by intel_ddi_pll_select to actually enable the PLL by writing to its register. This function can't fail. We also have some refcount sanity checks here. The idea is that one day we'll remove all the functions that touch registers from haswell_crtc_mode_set to haswell_crtc_enable, so we'll call intel_ddi_pll_select at haswell_crtc_mode_set and then call intel_ddi_pll_enable at haswell_crtc_enable. Since I'm already touching this code, let's take care of this particular split today. v2: - Clock on the debug message is in KHz - Add missing POSTING_READ Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Bikeshed comments.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12drm/i915: Fix timeout with missed interrupts in __wait_seqnoMika Kuoppala
Commit 094f9a54e355 ("drm/i915: Fix __wait_seqno to use true infinite timeouts") added support for __wait_seqno to detect missing interrupts and go around them by polling. As there is also timeout detection in __wait_seqno, the polling and timeout detection were done with the same timer. When there has been missed interrupts and polling is needed, the timer is set to trigger in (now + 1) jiffies in future, instead of the caller specified timeout. Now when io_schedule() returns, we calculate the jiffies left to timeout using the timer expiration value. As the current jiffies is now bound to be always equal or greater than the expiration value, the timeout_jiffies will become zero or negative and we return -ETIME to caller even tho the timeout was never reached. Fix this by decoupling timeout calculation from timer expiration. v2: Commit message with some sense in it (Chris Wilson) v3: add parenthesis on timeout_expire calculation v4: don't read jiffies without timeout (Chris Wilson) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12drm/radeon: Fix sideport problems on certain RS690 boardsAlex Deucher
Some RS690 boards with 64MB of sideport memory show up as having 128MB sideport + 256MB of UMA. In this case, just skip the sideport memory and use UMA. This fixes rendering corruption and should improve performance. bug: https://bugs.freedesktop.org/show_bug.cgi?id=35457 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-04-04 12:54:05 +0000