aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
...
| * drm/i915: Drop forcewake w/a for missed interrupts/seqno on SandybridgeChris Wilson2013-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I believe, and an evening of i-g-t, that our original workaround for the missed interrupts on Sandybridge, that of holding forcewake whilst we wait for an interrupts, is no longer required. This leaves us dependent on the second workaround of forcing an UC read of the ACTHD before reading back the seqno from the snooped HWS. Dropping the forcewake should allow us to conserve a little power, not much as the GPU is meant to be busy whilst we wait for it! Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Move the gtt mm takedown to cleanupBen Widawsky2013-11-26
| | | | | | | | | | | | | | | | | | Our VM code already has a cleanup function, and this is a nice place to put the drm_mm_takedown. This should have no functional impact, it just leaves the unload function a bit cleaer, and is more logical IMO Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Missed dropped VMA conversionBen Widawsky2013-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This belonged in commit 07fe0b12800d4752d729d4122c01f41f80a5ba5a Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:10 2013 -0700 drm/i915: plumb VM into bind/unbind code But it was somehow missed along the way. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Remove defunct ctx switch commentsBen Widawsky2013-11-26
| | | | | | | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Removed unused vm argsBen Widawsky2013-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915_gem_execbuffer_relocate became defunct in: commit 27173f1f95db5e74ceb35fe9a2f2f348ea11bac9 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Aug 14 11:38:36 2013 +0200 drm/i915: Convert execbuf code to use vmas eb_create: never used? Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: The lingering vm parameter to eb_create might have been back from the days where we didn't yet keep both vmas and obj lists in the eb struct. But I didn't check really.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Demote drop_caches_set printBen Widawsky2013-11-26
| | | | | | | | | | | | | | | | | | | | | | Many tests call this ad naseum now (in an infinite loop, very often). It clutters the logs. Actually, I'd rather drop it completely... Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Disallow dynamic ppgtt param modificationBen Widawsky2013-11-26
| | | | | | | | | | | | | | | | This would have never worked. 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>
| * drm/i915: Add a few missed bits to the mmBen Widawsky2013-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should really have been added in BDW integration, as well as: commit 93bd8649dba3155d1a0ba2a902d9c49f1c75a1da Author: Ben Widawsky <ben@bwidawsk.net> Date: Tue Jul 16 16:50:06 2013 -0700 drm/i915: Put the mm in the parent address space It didn't really matter before, but it will in the future. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix BDW PPGTT error pathBen Widawsky2013-11-26
| | | | | | | | | | | | | | | | | | | | When we fail for some reason on loading the PDPs, it would be wise to disable the PPGTT in the ring registers. If we do not do this, we have undefined results. 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>
| * drm/i915: Don't set the fence number in DPFC_CTL on SNBVille Syrjälä2013-11-25
| | | | | | | | | | | | | | | | | | | | | | SNB has another register where the actual FBC CPU fence number is stored. The documenation explicitly states that the fence number in DPFC_CTL must be 0 on SNB. And in fact when it's not zero, the GTT tracking simply doesn't work. 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>
| * drm/i915: Fix module unloading with DRM_I915_UMS=nDaniel Vetter2013-11-25
| | | | | | | | | | | | | | | | | | | | | | | | Oops, makes testing early boot failures in i915.ko a bit more pain, so let's fix it. v2: We already have a bit of static storage to track this (Chris). Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * i915, fbdev: Fix Kconfig typoBorislav Petkov2013-11-21
| | | | | | | | | | | | | | | | | | | | Too many t's. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * i915, debugfs: Fix uninitialized warningBorislav Petkov2013-11-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc complains that: drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’: drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used uninitialized in this function [-Wuninitialized] drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ‘val’ was declared here but it can't see that we're going to use val only in the success case. So shut it up. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Hold pc8 lock around toggling pc8.gpu_idleChris Wilson2013-11-21
| | | | | | | | | | | | | | | | | | | | We need to hold the pc8 lock around toggling the value of gpu_idle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Enable pipe gamma for spritesVille Syrjälä2013-11-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We send the primary and cursor plane data through the gamma unit. In order to get matching output from sprites, also send the sprite data through the gamma unit. In the future we should add some properties to control this explicitly, and also add properties for the per-sprite gamma ramps what have you, but for now this seems like a reasonable thing to do. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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>
| * drm/i915: Use plane_name() in gen7_enable_fbc()Ville Syrjälä2013-11-21
| | | | | | | | | | | | | | | | | | All the other .enable_fbc() funcs use plane_name(). Make gen7_enable_fbc() do the same. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Set has_fbc=true for all SNB+, except VLVVille Syrjälä2013-11-21
| | | | | | | | | | | | | | | | | | At least since SNB (perhaps even earlier) even the desktop parts should have FBC. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Emit SRM after the MSG_FBC_REND_STATE LRIVille Syrjälä2013-11-21
| | | | | | | | | | | | | | | | | | The spec tells us that we need to emit an SRM after the LRI to MSG_FBC_REND_STATE. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Limit FBC flush to post batch flushVille Syrjälä2013-11-21
| | | | | | | | | | | | | | | | | | | | Don't issue the FBC nuke/cache clean command when invalidate_domains!=0. That would indicate that we're not being called for the post-batch flush. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: remove intel_uncore_clear_errorsDaniel Vetter2013-11-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This was forgotten in commit 9d1cb9147dbe45f6e94dc796518ecf67cb64b359 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Nov 1 13:32:08 2013 -0200 drm/i915: avoid unclaimed registers when capturing the error state Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: reuse WRPLL when possiblePaulo Zanoni2013-11-18
| | | | | | | | | | | | | | | | | | | | It seems we do have machines with 3 HDMI/DVI outputs, so sharing WRPLLs is the only way to get 3 pipes working. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68485 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: dp aux irq support for g4x/vlvDaniel Vetter2013-11-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now we have this everywhere. Next up would be to wire up the DP hotplug pin to speed up panel power sequencing for eDP panels ... I've decided to leave the has_aux_irq logic in the code, it should come handy for hw bringup. For testing/fail-safety the dp aux code already has a timeout when waiting for interrupts to signal completion and screams rather loud if they don't arrive in time. Given that we need a real piece of hw to talk to anyway this is probably as good as it gets. v2: Don't check the dp aux channel bits on i965 machines, they have a different meaning there. Yay for reusing bits at will! Spotted by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge branch 'backlight-rework' into drm-intel-next-queuedDaniel Vetter2013-11-15
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in Jani's backlight rework branch. This was merged through a separate branch to be able to sort out the Broadwell conflicts properly before pulling it into the main development branch. Conflicts: drivers/gpu/drm/i915/intel_display.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * Merge branch 'bdw-fixes' into backlight-reworkDaniel Vetter2013-11-15
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge the bdw changes into the backlight rework branch so that we can adapt the new code for bdw, too. This is a bit a mess, but doing this another way would have delayed the merging of the backlight refactoring. Mea culpa. As discussed with Jani on irc only do bdw-specific callbacks for the set/get methods and bake in the only other special-case into the pch enable function. Conflicts: drivers/gpu/drm/i915/intel_panel.c v2: Don't enable the PWM too early for bdw (Jani). v3: Create new bdw_ functions for setup and enable - the rules change sufficiently imo with the switch from controlling the pwm from the cpu to controlling it completel from the pch to warrant this. v4: Rip out unused pipe variable in bdw_enable_backlight (0-day builder). Tested-by: Ben Widawsky <ben@bwidawsk.net> (on bdw) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | | * drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwellBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pipe B and pipe C interrupt mask and enable registers are now part of the pipe, so disabling the pipe power wells will lost the contests of the registers. Art totally debugged this one! v2: Use the irq_lock to clarify code, and prevent future bugs (Daniel) Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Make sparse happy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | | * drm/i915/bdw: Limit GTT to 2GBBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because of the way in which we're allocating the pages for the Aliasing PPGTT, we cannot actually successfully alloc enough space for anything greater than 2GB. Instead of a quick hack to fix this, we should defer until we have the real solution in place (allocating much less contiguous space). This wasn't found sooner because we didn't not have any systems supporting more than a 2GB GTT. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | | * drm/i915/bdw: Add comment about gen8 HWS PGABen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This confused me some many times that I think it is appropriate to add a small comment to instruct the reader of the code that it is indeed doing what it is supposed to do. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | | * drm/i915/bdw: Free correct number of ppgtt pagesBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am unclear how this got messed up in the shuffle, but it did. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | | * drm/i915/bdw: Do gen6 style reset for gen8Ben Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch existed before, but was lost over time. Note that reset is still somewhat problematic in my limited testing (ie. module_reload will not pass) but it can be disabled with a module parameter, and support should be considered preliminary anyway. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | | * drm/i915/bdw: GEN8 backlight supportBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to Haswell the CPU control register for backlight (BLC_PWM_CPU_CTL) toggled the PCH baclight pin for us. This made some sense as there was no pin on the CPU. With Haswell came the introduction of a CPU backlight pin, but the interface was still controlled by software with the same mechnism. Behind the scenes, hardware did all the dirty work for us. Broadwell no longer provides this for free. If we want to use the PCH backlight pin [1] then we have to set the override bit BLC_PWM_PCH_CTL1 and program BLC_PWM_PCH_CTL2 for the PWM values. This patch implements that. This patch is compile tested only, and given that I rarely if ever touch this code, careful review is welcome. [1] According to Art, we know of no devices that exist which use the CPU pin (and remember it has existed already on HSW). If such a device does exist, we'll have to handle it properly - this is left as TODO until then. v2: Drop the abstraction prep patch, as a bigger backlight overhaul is in the works, and do just the mimimal bdw enabling now. (by Jani) CC: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | | * drm/i915/bdw: Add BDW to ULT macroBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For what we care about ULT and ULX are interchangeable. We know of 3 types of pciids for these cases. I am not sure if at some point we will need to distinguish ULT and ULX. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: do not save/restore backlight registers in KMSJani Nikula2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The backlight enable code now has the smarts to do the right thing. Only do backlight register save/restore in UMS. Some VLV specific code gets dropped as UMS is not supported on VLV. v2: Move save/restore to UMS instead of removing completely (Daniel). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: nuke get max backlight functionsJani Nikula2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No longer needed. We now have fully cached max backlight values. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: remove QUIRK_NO_PCH_PWM_ENABLEJani Nikula2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The quirk was added as what I'd say was a stopgap measure in commit e85843bec6c2ea7c10ec61238396891cc2b753a9 Author: Kamal Mostafa <kamal@canonical.com> Date: Fri Jul 19 15:02:01 2013 -0700 drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight without really digging into what was going on. Also, as mentioned in the related bug [1], having the quirk regressed some of the machines it was supposed to fix to begin with, and there were patches posted to disable the quirk on such machines [2]! The fact is, we do need the BLM_PCH_PWM_ENABLE bit set to have backlight. With the quirk, we've relied on BIOS to have set it, and our save/restore code to retain it. With the full backlight setup at enable, we have no place for things that rely on previous state. With the per platform hooks, we've also made a change in the PCH platform enable order: setting the backlight duty cycle between CPU and PCH PWM enable. Some experimenting and commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid indicate that we can't set the backlight before enabling CPU PWM; the value just won't stick. But AFAICT we should do it before enabling the PCH PWM. Finally, any fallout we should fix properly, preferrably without quirks, and absolutely without quirks that rely on existing state. With the per platform hooks have much more flexibility to adjust the sequence as required by platforms. [1] https://bugzilla.kernel.org/show_bug.cgi?id=47941 [2] http://lkml.kernel.org/r/1378229848-29113-1-git-send-email-kamal@canonical.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: do full backlight setup at enable timeJani Nikula2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should now have all the information we need to do a full initialization of the backlight registers. v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: gather backlight information at setupJani Nikula2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prepare for being able to use the information at enable. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: debug print on backlight registerJani Nikula2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: use the initialized backlight max value instead of reading itJani Nikula2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now have the max backlight value cached. Use it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: move backlight level setting in enable/disable to hooksJani Nikula2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows more flexibility in the ordering of the register writes, and lets us drop level setting altogether as necessary on a per platform basis. For gen2-gen3, this is the only thing that happens in enable/disable. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: vlv does not have pipe field in backlight registersJani Nikula2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It has per pipe registers. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: fix gen2-gen3 backlight setJani Nikula2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Citing Jani's response to Imre's question in the review discussion: > According to the gen2/3 bspec I have, the correct mask is > BACKLIGHT_DUTY_CYCLE_MASK_PNV only in case of IS_PINEVIEW(dev), for > everything else it's BACKLIGHT_DUTY_CYCLE_MASK. What you say is correct, but we've treated all gen2/3 similar to PNV since commit ca88479c1c3b7b1a9f94320745f5331e1de77f80 Author: Keith Packard <keithp@keithp.com> Date: Fri Nov 18 11:09:24 2011 -0800 drm/i915: Treat pre-gen4 backlight duty cycle value consistently i.e. we only use the high 15 bits for all gen2/3. For non-PNV this just means the lowest bit is always zero. For PNV the lowest bit has a different meaning in both the PWM freq and duty cycle fields. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Make the commit message less empty.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: handle backlight through chip specific functionsJani Nikula2013-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The backlight code has grown rather hairy, not least because the hardware registers and bits have repeatedly been shuffled around. And this isn't expected to get any easier with new hardware. Make things easier for our (read: my) poor brains, and split the code up into chip specific functions. There should be no functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: make asle notifications update backlight on all connectorsJani Nikula2013-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ALthough usually there's only one connector that supports backlight, this also finds the correct connector. Before, we only updated the connector on pipe A, which might not be the one with backlight. (This only made a difference on BYT.) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: make backlight info per-connectorJani Nikula2013-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move from dev_priv to connector->panel. We still don't allow multiple sysfs interfaces, though. There should be no functional changes, except for a slight reordering of connector backlight and sysfs destroy calls. (This change happens now that the backlight device is actually per-connector, even though the destroy calls became per-connector earlier.) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: clean up backlight conditional buildJani Nikula2013-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've always felt the backlight device conditional build has been all backwards. Make it feel right. Gently move things towards connector based stuff while at it. There should be no functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Reject opening of pipe crc files for invalid pipesDaniel Vetter2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't init the lock nor set up all the other state. And it doesn't make sense anyway. This appeases lockdep when running the igt/drv_debugfs_reader test. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Use for_each_pipe in intel_display_crc_initDaniel Vetter2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a nice macro, so use it. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Deprecated UMS supportDaniel Vetter2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's been 5 years since kms support was merged and roughly 4 years since UMS support was ripped out from userspace drivers. Thus far it's not been a big burden to keep the ums paths alive, and we've made some good progress in better separating it from the kms code by sprinkling DRIVER_MODESET checks all over the place. But now that the drm demidlayering is within reach this changes. I want to make the driver loading code more robust using devres.c and other cool tricks. But that doesn't work with ums due to the shadow-attach trick. Which means we either a) need to split out a complete ums codebase like radeon has b) kill it for good. The 2nd option is obviously much less work than the first, so I think it's time to test the waters and see how many people out there still use ums. I've decided that silently failing to initialize the driver (and not e.g. failing to load the module) is the right thing. That way we should only get reports from users that actually care about some ums features (like accelerated gl or support for secondary outputs). Everyone else will just fall back to the vesa X driver. For developers there's a small info level dmesg output. The plan is to drop this Kconfig option after 3.16 (so gives us 2 full releases) and then start killing code for real 2-3 releases afterwards. That should be more than enough time for users to pipe up. Of course if anyone does we need to revisit this plan and maybe go with option a) above. Also enable the KMS support by default in Kconfig and polish the help texts a bit. v2: Add the missing hunk of actual code changes. Oops. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Kill legeacy AGP for gen3 kmsDaniel Vetter2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thus far we've tried to carefully work around the fact that old userspace relied on the AGP-backed legacy buffer mapping ioctls for a bit too long. But it's really horribly, and now some new users for it started to show up again: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45547.html This uses drmAgpSize to figure out the GTT size, which is both the wrong thing to inquire and also might force us to keep this crap around for another few years. So I want to stop this particular zombie from raising ever again. Now it's only been 4 years since XvMC was fixed for gen3, so a bit early by the usual rules. But since Linus explicitly said that an ABI breakage only counts if someone actually observes it I want to tempt fate an accelarate the demise of AGP. We probably need to wait 2-3 kernel releases with this shipping until we go on a killing spree code-wise. v2: Remove intel_agp_enabled since it's unused (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Make AGP=n work even on gen3Daniel Vetter2013-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most platforms din't hit this condition, but if we want to allow building without agp we should also make this allowed on gen3. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-05 15:47:31 -0400