summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_panel.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'v3.16' into drm-nextDave Airlie2014-08-051-6/+10
|\ | | | | | | | | | | | | | | | | | | Linux 3.16 backmerge requested by i915, nouveau and radeon authors Conflicts: drivers/gpu/drm/i915/i915_gem_render_state.c drivers/gpu/drm/i915/intel_drv.h
| * Revert "drm/i915: Don't set the 8to6 dither flag when not scaling"Daniel Vetter2014-07-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 773875bfb6737982903c42d1ee88cf60af80089c. It is very much needed and the lack of dithering has been reported by a large list of people with various gen2/3 hardware. Also, the original patch was complete non-sense since the WARNING backtraces in the references bugzilla are about gmch_pfit.lvds_border_bits mismatch, not at all about the dither bit. That one seems to work. Cc: Jiri Kosina <jkosina@suse.cz> Cc: Pavel Machek <pavel@ucw.cz> Cc: Hans de Bruin <jmdebruin@xmsnet.nl> Cc: stable@vger.kernel.org Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: quirk asserts controllable backlight presence, overriding VBTScot Doyle2014-07-091-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT caused a regression on machines with a misconfigured VBT. Add a quirk to assert the presence of a controllable backlight. Use it to ignore the VBT backlight presence check during backlight setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Tested-by: James Duley <jagduley@gmail.com> Tested-by: Michael Mullin <masmullin@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Scot Doyle <lkml14@scotdoyle.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org # 3.15 only [danvet: Add cc: stable because the regressing commit is in 3.15.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: respect the VBT minimum backlight brightnessJani Nikula2014-07-231-17/+143
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically we've exposed the full backlight PWM duty cycle range to the userspace, in the name of "mechanism, not policy". However, it turns out there are both panels and board designs where there is a minimum duty cycle that is required for proper operation. The minimum duty cycle is available in the VBT. The backlight class sysfs interface does not make any promises to the userspace about the physical meaning of the range 0..max_brightness. Specifically there is no guarantee that 0 means off; indeed for acpi_backlight 0 usually is not off, but the minimum acceptable value. Respect the minimum backlight, and expose the range acceptable to the hardware as 0..max_brightness to the userspace via the backlight class device; 0 means the minimum acceptable enabled value. To switch off the backlight, the user must disable the encoder. As a side effect, make the backlight class device max brightness and physical PWM modulation frequency (i.e. max duty cycle) independent. This allows a follow-up patch to virtualize the max value exposed to the userspace. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: s/BUG_ON/WARN_ON/] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: set backlight duty cycle after backlight enable for gen4Jani Nikula2014-06-111-3/+2
| | | | | | | | | | | | | | | | | | | | | | For reasons I can't claim to fully understand gen4 seems to require backlight duty cycle setting after the backlight has been enabled, or else black screen follows. I don't have documentation for the correct sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1. This fixes a regression introduced by commit b35684b8fa94e04f55fd38bf672b737741d2f9e2 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:13:41 2013 +0200 drm/i915: do full backlight setup at enable time Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791 Reported-and-tested-by: mcy@lm7.fr Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423 Reported-and-tested-by: Marc Milgram <mmilgram@redhat.com> Cc: Stable <stable@vger.kernel.org> # 3.14+ Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* Merge commit '9e9a928eed8796a0a1aaed7e0b676db86ba84594' into drm-nextDave Airlie2014-06-051-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | Merge drm-fixes into drm-next. Both i915 and radeon need this done for later patches. Conflicts: drivers/gpu/drm/drm_crtc_helper.c drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem_execbuffer.c drivers/gpu/drm/i915/i915_gem_gtt.c
| * drm/i915: restore backlight precision when converting from ACPIAaron Lu2014-05-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm: convert crtc and connection_mutex to ww_mutex (v5)Rob Clark2014-06-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm: Split connection_mutex out of mode_config.mutex (v3)Daniel Vetter2014-06-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from connector->encoder and encoder->crtc and other modeset-relevant connector state (e.g. properties which control the panel fitter). The later is used by modeset operations. But they don't really care about the former since it's allowed to e.g. enable a disconnected VGA output or with a mode not in the probed list. Thus far this hasn't been a problem, but for the atomic modeset conversion Rob Clark needs to convert all modeset relevant locks into w/w locks. This is required because the order of acquisition is determined by how userspace supplies the atomic modeset data. This has run into troubles in the detect path since the i915 load detect code needs _both_ protections offered by the mode_config.mutex: It updates probe state and it needs to change the modeset configuration to enable the temporary load detect pipe. The big deal here is that for the probe/detect users of this lock a plain mutex fits best, but for atomic modesets we really want a w/w mutex. To fix this lets split out a new connection_mutex lock for the modeset relevant parts. For simplicity I've decided to only add one additional lock for all connector/encoder links and modeset configuration states. We have piles of different modeset objects in addition to those (like bridges or panels), so adding per-object locks would be much more effort. Also, we're guaranteed (at least for now) to do a full modeset if we need to acquire this lock. Which means that fine-grained locking is fairly irrelevant compared to the amount of time the full modeset will take. I've done a full audit, and there's just a few things that justify special focus: - Locking in drm_sysfs.c is almost completely absent. We should sprinkle mode_config.connection_mutex over this file a bit, but since it already lacks mode_config.mutex this patch wont make the situation any worse. This is material for a follow-up patch. - omap has a omap_framebuffer_flush function which walks the connector->encoder->crtc links and is called from many contexts. Some look like they don't acquire mode_config.mutex, so this is already racy. Again fixing this is material for a separate patch. - The radeon hot_plug function to retrain DP links looks at connector->dpms. Currently this happens without any locking, so is already racy. I think radeon_hotplug_work_func should gain mutex_lock/unlock calls for the mode_config.connection_mutex. - Same applies to i915's intel_dp_hot_plug. But again, this is already racy. - i915 load_detect code needs to acquire this lock. Which means the w/w dance due to Rob's work will be nicely contained to _just_ this function. I've added fixme comments everywhere where it looks suspicious but in the sysfs code. After a quick irc discussion with Dave Airlie it sounds like the lack of locking in there is due to sysfs cleanup fun at module unload. v1: original (only compile tested) v2: missing mutex_init(), etc (from Rob Clark) v3: i915 needs more care in the conversion: - Protect the edp pp logic with the connection_mutex. - Use connection_mutex in the backlight code due to get_pipe_from_connector. - Use drm_modeset_lock_all in suspend/resume paths. - Update lock checks in the overlay code. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com>
* | drm/i915: replace drm_get_connector_name() with direct name field useJani Nikula2014-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generated using semantic patches: @@ expression E; @@ - drm_get_connector_name(&E) + E.name @@ expression E; @@ - drm_get_connector_name(E) + E->name v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/i915: shuffle panel codeJani Nikula2014-05-201-75/+75
| | | | | | | | | | | | | | | | | | Somehow a few functions have been dropped in the middle of backlight code. Move them around. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge tag 'drm-intel-next-2014-04-16' of ↵Dave Airlie2014-05-011-4/+4
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2014-04-16: - vlv infoframe fixes from Jesse - dsi/mipi fixes from Shobhit - gen8 pageflip fixes for LRI/SRM from Damien - cmd parser fixes from Brad Volkin - some prep patches for CHV, DRRS, ... - and tons of little things all over drm-intel-next-2014-04-04: - cmd parser for gen7 but only in enforcing and not yet granting mode - the batch copying stuff is still missing. Also performance is a bit ... rough (Brad Volkin + OACONTROL fix from Ken). - deprecate UMS harder (i.e. CONFIG_BROKEN) - interrupt rework from Paulo Zanoni - runtime PM support for bdw and snb, again from Paulo - a pile of refactorings from various people all over the place to prep for new stuff (irq reworks, power domain polish, ...) drm-intel-next-2014-04-04: - cmd parser for gen7 but only in enforcing and not yet granting mode - the batch copying stuff is still missing. Also performance is a bit ... rough (Brad Volkin + OACONTROL fix from Ken). - deprecate UMS harder (i.e. CONFIG_BROKEN) - interrupt rework from Paulo Zanoni - runtime PM support for bdw and snb, again from Paulo - a pile of refactorings from various people all over the place to prep for new stuff (irq reworks, power domain polish, ...) Conflicts: drivers/gpu/drm/i915/i915_gem_context.c
| * drm/i915: Don't set the 8to6 dither flag when not scalingDaniel Vetter2014-04-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently we really only need this when the pfit is enabled, at least I couldn't dicern any difference here. Furthermore the hacks we have to reconstruct this bit is a bit glaring, and probably only works because we can't move the lvds port to any other pipe than pipe B on gen2/3. So let's just rip this out. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77137 (the LVDS WARNING log, not the main "VGA can't be turned on" issue). Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'v3.14-rc6' into drm-intel-next-queuedDaniel Vetter2014-03-101-2/+2
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.14-rc6 I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts when merging Ville's new hdmi cloning support into my -next tree Conflicts: drivers/gpu/drm/i915/Makefile drivers/gpu/drm/i915/intel_dp.c Makefile cleanup conflicts with an acpi build fix, intel_dp.c is trivial. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: do not setup backlight if not available according to VBTJani Nikula2014-04-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some machines use an external EC for controlling the backlight. Info about this is present in the VBT. Do not setup native backlight control if no PWM backlight is available or supported according to VBT. The acpi_backlight interface appears to work for the EC control. In most cases there has been no harm done, but it looks like there are machines out there that have both an EC and our PWM line connected to the same wire. This, obviously, does not end well. This should fix the regression caused by commit bc0bb9fd1c7810407ab810d204bbaecb255fddde Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:14:29 2013 +0200 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE AFAICT the quirk removed by the above commit effectively resulted in i915 not driving the backlight PWM output, thus not messing things up. Additionally this should fix the regression caused by commit fbc9fe1b4f222a7c575e3bd8e9defe59c6190a04 Author: Aaron Lu <aaron.lu@intel.com> Date: Fri Oct 11 21:27:45 2013 +0800 ACPI / video: Do not register backlight if win8 and native interface exists which left some machines without a functioning backlight interface. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76276 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=62281 CC: Aaron Lu <aaron.lu@intel.com> CC: Eric Griffith <EGriffith92@gmail.com> CC: Kent Baxley <kent.baxley@canonical.com> Tested-by: Kamal Mostafa <kamal@canonical.com> Tested-by: Martin <bugs@mrvanes.com> Tested-by: jrg.otte@gmail.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | Merge tag 'v3.14-rc7' into drm-nextDave Airlie2014-03-181-2/+2
|\ \ \ | |/ / |/| / | |/ | | | | Linux 3.14-rc7 Backmerge to help out Intel guys.
| * drm/i915: use backlight legacy combination mode also for i915gm/i945gmJani Nikula2014-03-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | i915gm and i945gm also seem to use and need the legacy combination mode bit in BLC_PWM_CTL. v2: Also do this for i915gm (Ville). Reported-and-tested-by: Luis Ortega <luiorpe1@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75001 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Initialize downclock mode in panel initVandana Kannan2014-02-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of modifying intel_panel in lvds_init_connector/dsi_init/ edp_init_connector, making changes to move intel_panel->downclock_mode initialization to intel_panel_init() v2: Jani's review comments incorporated Removed downclock_mode local variable in dsi_init and edp_init_connector Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move module parameters into a struct, in a new fileJani Nikula2014-01-271-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With 20+ module parameters, I think referring to them via a struct improves clarity over just having a bunch of globals. While at it, move the parameter initialization and definitions into a new file i915_params.c to reduce clutter in i915_drv.c. Apart from the ill-named i915_enable_rc6, i915_enable_fbc and i915_enable_ppgtt parameters, for which we lose the "i915_" prefix internally, the module parameters now look the same both on the kernel command line and in code. For example, "i915.modeset". The downsides of the change are losing static on a couple of variables and not having the initialization and module_param_named() right next to each other. On the other hand, all module parameters are now defined in one place at i915_params.c. Plus you can do this to find all module parameter references: $ git grep "i915\." -- drivers/gpu/drm/i915 v2: - move the definitions into a new file - s/i915_params/i915/ - make i915_try_reset i915.reset, for consistency Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Only restore backlight combination mode reg for umsDaniel Vetter2014-01-241-2/+0
|/ | | | | | | | | | | | | | | | | This was forgotten in commit 565ee3897f0cb1e9b09905747b3784e6605767e8 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 13 12:56:29 2013 +0200 drm/i915: do not save/restore backlight registers in KMS Since the confusion was likely due to the duplicated definition for this pci config register, let's unify that, too. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Eliminate lots of WARNs when there's no backlight presentVille Syrjälä2014-01-221-3/+3
| | | | | | | | | | | | | | | | My 855gm doesn't register the intel backlight but it still ends up calling the backlight code to enable/disable the backlight via the LVDS code. This leads to some WARNs due to backlight.max being 0. Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight() check whether there's a backlight present or not. Also move the backlight.present check from asle_set_backlight() into intel_panel_set_backlight() for some extra symmetry. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add some runtime PM get/put callsPaulo Zanoni2013-12-101-0/+3
| | | | | | | | | | | | These are needed when we cat the debugfs and sysfs files. V2: - Rebase V3: - Rebase V4: - Rebase 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>
* drm/i915: Make downclock deduction common for all panelsVandana Kannan2013-12-101-0/+57
| | | | | | | | | | | | If one mode of a internal panel has more than one refresh rate, then a reduced clock is found for the LFP (LVDS/eDP). This enables switching between low and high frequency dynamically. Moving downclock calculation to intel_panel so that it is common for LVDS and eDP. Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'bdw-fixes' into backlight-reworkDaniel Vetter2013-11-151-1/+80
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: GEN8 backlight supportBen Widawsky2013-11-141-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: nuke get max backlight functionsJani Nikula2013-11-141-133/+0
| | | | | | | | | | | | | | | | 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-141-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-141-56/+93
| | | | | | | | | | | | | | | | | | | | | | 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-141-12/+56
| | | | | | | | | | | | | | | | 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-131-0/+6
| | | | | | | | | | | | 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-131-21/+24
| | | | | | | | | | | | | | | | 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-131-12/+36
| | | | | | | | | | | | | | | | | | | | | | | | 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-131-2/+0
| | | | | | | | | | | | | | | | 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-131-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-131-208/+434
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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-131-38/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-131-28/+37
|/ | | | | | | | | | | | | 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>
* Merge tag 'drm-intel-fixes-2013-11-07' of ↵Dave Airlie2013-11-081-38/+115
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Bit a bit -fixes pull request in the merge window than usual dua to two feauture-y things: - Display CRCs are now enabled on all platforms, including the odd DP case on gm45/vlv. Since this is a testing-only feature it should ever hurt, but I figured it'll help with regression-testing -fixes. So I left it in and didn't postpone it to 3.14. - Display power well refactoring from Imre. Would have caused major pain conflict with the bdw stage 1 patches if I'd postpone this to -next. It's only an relatively small interface rework, so shouldn't cause pain. It's also been in my tree since almost 3 weeks already. That accounts for about two thirds of the pull, otherwise just bugfixes: - vlv backlight fix from Jesse/Jani - vlv vblank timestamp fix from Jesse - improved edp detection through vbt from Ville (fixes a vlv issue) - eDP vdd fix from Paulo - fixes for dvo lvds on i830M - a few smaller things all over Note: This contains a backmerge of v3.12. Since the -internal branch always applied on top of -nightly I need that unified base to merge bdw patches. So you'll get a conflict with radeon connector props when pulling this (and nouveau/master will also conflict a bit when Ben doesn't rebase). The backmerge itself only had conflicts in drm/i915. There's also a tiny conflict between Jani's backlight fix and your sysfs lifetime fix in drm-next. * tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel: (940 commits) drm/i915/vlv: use per-pipe backlight controls v2 drm/i915: make backlight functions take a connector drm/i915: move opregion asle request handling to a work queue drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV drm/i915: Make intel_dp_is_edp() less specific drm/i915: Give names to the VBT child device type bits drm/i915/vlv: enable HDA display audio for Valleyview2 drm/i915/dvo: call ->mode_set callback only when the port is running drm/i915: avoid unclaimed registers when capturing the error state drm/i915: Enable DP port CRC for the "auto" source on g4x/vlv drm/i915: scramble reset support for DP port CRC on vlv drm/i915: scramble reset support for DP port CRC on g4x drm/i916: add "auto" pipe CRC source ... Conflicts: MAINTAINERS drivers/gpu/drm/i915/intel_panel.c drivers/gpu/drm/nouveau/core/subdev/mc/base.c drivers/gpu/drm/radeon/atombios_encoders.c drivers/gpu/drm/radeon/radeon_connectors.c
| * drm/i915/vlv: use per-pipe backlight controls v2Jesse Barnes2013-11-061-12/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the connector and pipe passed around, we can now set the backlight on the right pipe on VLV/BYT. v2: drop combination mode check for VLV (Jani) add save/restore code for VLV backlight regs (Jani) check for existing modulation freq when initializing backlight regs (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67245 Tested-by: Joe Konno <joe.konno@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: make backlight functions take a connectorJesse Barnes2013-11-061-26/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV/BYT, backlight controls a per-pipe, so when adjusting the backlight we need to pass the correct info. So make the externally visible backlight functions take a connector argument, which can be used internally to figure out the pipe backlight to adjust. v2: make connector pipe lookup check for NULL crtc (Jani) fixup connector check in ASLE code (Jani) v3: make sure we take the mode config lock around lookups (Daniel) v4: fix double unlock in panel_get_brightness (Daniel) v5: push ASLE work into a work queue (Daniel) v6: separate ASLE work to a prep patch, rebase (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge tag 'drm-intel-next-2013-10-18' of ↵Dave Airlie2013-10-251-0/+4
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next - CRC support from Damien and He Shuang. Long term this should allow us to test an awful lot modesetting corner cases automatically. So for me as the maintainer this is really big. - HDMI audio fix from Jani. - VLV dpll computation code refactoring from Ville. - Fixups for the gpu booster from last time around (Chris). - Some cleanups in the context code from Ben. - More watermark work from Ville (we'll be getting there ...). - vblank timestamp improvements from Ville. - CONFIG_FB=n support, including drm core changes to make the fbdev helpers optional. - DP link training improvements (Jani). - mmio vtable from Ben, prep work for future hw. * tag 'drm-intel-next-2013-10-18' of git://people.freedesktop.org/~danvet/drm-intel: (132 commits) drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp drm/i915: remove dead code in ironlake_crtc_mode_set drm/i915: crc support for hsw drm/i915: fix CRC debugfs setup drm/i915: wait one vblank when disabling CRCs drm/i915: use ->get_vblank_counter for the crc frame counter drm/i915: wire up CRC interrupt for ilk/snb drm/i915: add CRC #defines for ilk/snb drm/i915: extract display_pipe_crc_update drm/i915: don't Oops in debugfs for I915_FBDEV=n drm/i915: set HDMI pixel clock in audio configuration drm/i915: pass mode to ELD write vfuncs cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n drm/i915: check gem bo size when creating framebuffers drm/i915: Use unsigned long for obj->user_pin_count drm/i915: prevent tiling changes on framebuffer backing storage drm/i915: grab dev->struct_mutex around framebuffer_init drm/i915: vlv: fix VGA hotplug after modeset drm: add support for additional stereo 3D modes drm/i915: preserve dispaly init order on ByT ...
| * drm/i915: Use pipe_name() instead of the pipe numberDamien Lespiau2013-10-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | Yet other direct usages of the pipe number instead of pipe_name(). We've been tracking them lately but managed to miss these last ones. v2: Catch them all! (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Add breadcrumbs for why the backlight is being setChris Wilson2013-10-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | At the moment we have 3 paths that lead to actually_set_backlight(), from modesetting, ACPI/OpRegion requests and our very own intel_backlight interface, and we have no way of distinguishing them in the debug log. So add a debug breadcrumb to explain the source of the backlight changes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/sysfs: sort out minor and connector device object lifetimes.Dave Airlie2013-10-221-1/+1
|/ | | | | | | | | | | | | | | | | So drm was abusing device lifetimes, by having embedded device structures in the minor and connector it meant that the lifetime of the internal drm objects (drm_minor and drm_connector) were tied to the lifetime of the device files in sysfs, so if something kept those files opened the current code would kfree the objects and things would go downhill from there. Now in reality there is no need for these lifetimes to be so intertwined, especailly with hotplugging of devices where we wish to remove the sysfs and userspace facing pieces before we can unwind the internal objects due to open userspace files or mmaps, so split the objects out so the struct device is no longer embedded and do what fbdev does and just allocate and remove the sysfs inodes separately. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915/vlv: hack to init backlight regs if BIOS fails to do so v2Jesse Barnes2013-10-011-0/+17
| | | | | | | | | | | | | | | | | | Still digging up the actual VBT info for this, but wanted to get this out there for testing, or in case others are also bugged by this. This can happen if you boot with an external display connected. In that case, the attached eDP backlight modulation frequency may not be programmed, so we need to use something (in this case the value my BIOS normally programs with just the internal display enabled). v2: fix masking and magic value in read_blc_pwm_ctl (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67732 Tested-by: shui yangwei <yangweix.shui@intel.com> (v1) Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: backlight combination mode bit is gen4 onlyJani Nikula2013-10-011-1/+1
| | | | | | | | Not valid for later non-PCH split platforms such as VLV. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter2013-09-241-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches: - Header cleanup in intel_drv.h, both changed in -fixes and my current -next pile. - Cursor handling cleanup for -next which depends upon the cursor handling fix merged into -rc2. All just trivial conflicts of the "changed adjacent lines" type: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Track pfit enable state separately from sizeChris Wilson2013-09-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Detangle the additional state of whether or not the hw has the pfit enabled from whether it has zero size. This allows us to cleanly distinguish in the code when we expect the pfit to be enabled (for Haswell pc8), and when the BIOS is confused and needs sanitizing. Reported-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68251 Tested-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: register backlight device also when backlight class is a moduleJani Nikula2013-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Ville and I were wondering why his laptop was missing the intel_backlight sysfs interface. Turns out we never register it when CONFIG_BACKLIGHT_CLASS_DEVICE=m. This has been broken ever since the i915 native backlight interface was added. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud