drm-intel-next-2016-05-22:
- cmd-parser support for direct reg->reg loads (Ken Graunke)
- better handle DP++ smart dongles (Ville)
- bxt guc fw loading support (Nick Hoathe)
- remove a bunch of struct typedefs from dpll code (Ander)
- tons of small work all over to avoid casting between drm_device and the i915
dev struct (Tvrtko&Chris)
- untangle request retiring from other operations, also fixes reset stat corner
cases (Chris)
- skl atomic watermark support from Matt Roper, yay!
- various wm handling bugfixes from Ville
- big pile of cdclck rework for bxt/skl (Ville)
- CABC (Content Adaptive Brigthness Control) for dsi panels (Jani&Deepak M)
- nonblocking atomic commits for plane-only updates (Maarten Lankhorst)
- bunch of PSR fixes&improvements
- untangle our map/pin/sg_iter code a bit (Dave Gordon)
drm-intel-next-2016-05-08:
- refactor stolen quirks to share code between early quirks and i915 (Joonas)
- refactor gem BO/vma funcstion (Tvrtko&Dave)
- backlight over DPCD support (Yetunde Abedisi)
- more dsi panel sequence support (Jani)
- lots of refactoring around handling iomaps, vma, ring access and related
topics culmulating in removing the duplicated request tracking in the execlist
code (Chris & Tvrtko) includes a small patch for core iomapping code
- hw state readout for bxt dsi (Ramalingam C)
- cdclk cleanups (Ville)
- dedupe chv pll code a bit (Ander)
- enable semaphores on gen8+ for legacy submission, to be able to have a direct
comparison against execlist on the same platform (Chris) Not meant to be used
for anything else but performance tuning
- lvds border bit hw state checker fix (Jani)
- rpm vs. shrinker/oom-notifier fixes (Praveen Paneri)
- l3 tuning (Imre)
- revert mst dp audio, it's totally non-functional and crash-y (Lyude)
- first official dmc for kbl (Rodrigo)
- and tons of small things all over as usual
* 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel: (194 commits)
drm/i915: Revert async unpin and nonblocking atomic commit
drm/i915: Update DRIVER_DATE to 20160522
drm/i915: Inline sg_next() for the optimised SGL iterator
drm/i915: Introduce & use new lightweight SGL iterators
drm/i915: optimise i915_gem_object_map() for small objects
drm/i915: refactor i915_gem_object_pin_map()
drm/i915/psr: Implement PSR2 w/a for gen9
drm/i915/psr: Use ->get_aux_send_ctl functions
drm/i915/psr: Order DP aux transactions correctly
drm/i915/psr: Make idle_frames sensible again
drm/i915/psr: Try to program link training times correctly
drm/i915/userptr: Convert to drm_i915_private
drm/i915: Allow nonblocking update of pageflips.
drm/i915: Check for unpin correctness.
Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"
drm/i915: Make unpin async.
drm/i915: Prepare connectors for nonblocking checks.
drm/i915: Pass atomic states to fbc update functions.
drm/i915: Remove reset_counter from intel_crtc.
drm/i915: Remove queue_flip pointer.
...
This set of changes introduces an atomic API to the PWM subsystem. This
is influenced by the DRM atomic API that was introduced a while back,
though it is obviously a lot simpler. The fundamental idea remains the
same, though: drivers provide a single callback to implement the atomic
configuration of a PWM channel.
As a side-effect the PWM subsystem gains the ability for initial state
retrieval, so that the logical state mirrors that of the hardware. Many
use-cases don't care about this, but for others it is essential.
These new features require changes in all users, which these patches
take care of. The core is transitioned to use the atomic callback if
available and provides a fallback mechanism for other drivers.
Changes to transition users and drivers to the atomic API are postponed
to v4.8.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXRcVWAAoJEN0jrNd/PrOhO3EP/RDuuco1fROml1ElCjcnWWfv
3dPyKEJhZktMmRNd/V0zMUJiOwr77wlbX4oQ5HajMHNYFQ65jfihbbylhSDepnxg
mjKV/yo18rzYZt9fv8huwvlwMOlLrJ9wQn4Gkbr5tzke6nITp52DTNH5y/anPQIk
B7neA1TerodAbE9FWjYuBZIltkmYZDqdm//RCHXVyYym8VuotE+jf+nrMXI78FoL
lgG64z/2OaGI+NZJQcpWftuz9nnenpa3sSLrvpitWEb/dAsXroMW/f08uVuOW87v
0xk7N7zmEkef7izVOWiPOK/MxIdc8hI4A5JftzMJ7nbgJvwG78dJiOxgFhrJYx0z
7zrYfjvvzjW0dpjZUvO37T/V5Rfxrk9sM7qUHJmN0+1oEkkCo1/c75JWTU2AmT4l
qkJdOGhgv7LumIiwbEyxc/5Jyh1akKOUX2svO0+0dptLRX2UpN3yeKIYinG1dAuT
86+/uuM6CL5gc+jVZ3GLNWfzHUu2RFVX0r0pzywq53pK5gMEs5WyxoIb5mHb8liA
sHsrZ3wbGGn95yZo8CwkzXIUsUH7qKYK+UVWA6OVBoTq4AOBZtII1AqvUttl25qL
xuKpj70xaBhK7VGqzDYQ68lqBaRySh+yzL/QsmnPEyx59mW81ytMrsn1Kmnuae2l
bzUsnWrpHc6530fRggTD
=sxT9
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This set of changes introduces an atomic API to the PWM subsystem.
This is influenced by the DRM atomic API that was introduced a while
back, though it is obviously a lot simpler. The fundamental idea
remains the same, though: drivers provide a single callback to
implement the atomic configuration of a PWM channel.
As a side-effect the PWM subsystem gains the ability for initial state
retrieval, so that the logical state mirrors that of the hardware.
Many use-cases don't care about this, but for others it is essential.
These new features require changes in all users, which these patches
take care of. The core is transitioned to use the atomic callback if
available and provides a fallback mechanism for other drivers.
Changes to transition users and drivers to the atomic API are
postponed to v4.8"
* tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (30 commits)
pwm: Add information about polarity, duty cycle and period to debugfs
pwm: Switch to the atomic API
pwm: Update documentation
pwm: Add core infrastructure to allow atomic updates
pwm: Add hardware readout infrastructure
pwm: Move the enabled/disabled info into pwm_state
pwm: Introduce the pwm_state concept
pwm: Keep PWM state in sync with hardware state
ARM: Explicitly apply PWM config extracted from pwm_args
drm: i915: Explicitly apply PWM config extracted from pwm_args
input: misc: pwm-beeper: Explicitly apply PWM config extracted from pwm_args
input: misc: max8997: Explicitly apply PWM config extracted from pwm_args
backlight: lm3630a: explicitly apply PWM config extracted from pwm_args
backlight: lp855x: Explicitly apply PWM config extracted from pwm_args
backlight: lp8788: Explicitly apply PWM config extracted from pwm_args
backlight: pwm_bl: Use pwm_get_args() where appropriate
fbdev: ssd1307fb: Use pwm_get_args() where appropriate
regulator: pwm: Use pwm_get_args() where appropriate
leds: pwm: Use pwm_get_args() where appropriate
input: misc: max77693: Use pwm_get_args() where appropriate
...
If the source of the backlight PWM is from the
panel then the PWM can be controlled by DCS
command, this patch adds the support to
enable/disbale panel PWM, control backlight level
etc...
v2: Moving the CABC bkl functions to new file.(Jani)
v3: Rebase
v4: Rebase
v5: Use mipi_dsi_dcs_write() instead of mipi_dsi_dcs_write_buffer() (Jani)
Move DCS macro`s to include/video/mipi_display.h (Jani)
v6: Rename the file to intel_dsi_panel_pwm.c
Removing the CABC operations
v7 by Jani: renames, rebases, etc.
v8 by Jani: s/INTEL_BACKLIGHT_CABC/INTEL_BACKLIGHT_DSI_DCS/
v9 by Jani: rename init function to intel_dsi_dcs_init_backlight_funcs
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
Reviewed-by: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/71238a4b14b8c3a6c04070c789f09f1b4bc00a15.1461676337.git.jani.nikula@intel.com
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information
provided in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd
v3: Correct some formatting mistakes
v4: Updated to use AUX backlight control if PWM control is not possible
(Jani)
v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
v7: Add enable_dpcd_backlight module parameter.
v8: Rebase onto latest drm-intel-nightly branch
v9: Remove changes to intel_dp_dpcd_read_wake
Split addition edp_dpcd variable into a separate patch
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Yetunde Adebisi <yetundex.adebisi@intel.com>
[Jani: whitepace changes to appease checkpatch]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459865452-9138-4-git-send-email-yetundex.adebisi@intel.com
Do not use magic numbers, do not prefix stuff with "PCI_", do not
declare registers in implementation files. Also move the PCI
registers under correct comment in i915_reg.h.
v2:
- Consistently use BSM (not BDSM or other variants from PRM) (Chris)
- Also include register address to help identify the register (Chris)
v3:
- Refer to register value as *_val instead of *_reg (Chris)
v4:
- Make style checker happy
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Supposedly we would want to get the PWM output as close as possible to
the target, so let's round to closest.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-7-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Generalize rawclk handling by storing it in dev_priv.
Presumably our hrawclk readout works at least for CTG and ELK
since we've been using it for DP AUX on those platforms. There
are no real docs anymore after configdb vanished, so the only
reference is the public CTG GMCH spec. What bits are listed in
that doc match our code. The ELK GMCH spec have no relevant
details unfortunately.
The PNV situation is less clear. Starting from
commit aa17cdb4f8 ("drm/i915: initialize backlight max from VBT")
we assume that the CTG/ELK hrawclk readout works for PNV as well.
At least the results *seem* reasonable for one PNV machine (Lenovo
Ideapad S10-3t). Sadly the PNV GMCH spec doesn't have the goods on
the relevant register either.
So let's keep assuming it works for PNV,ELK,CTG and read it out on
those platforms. G33 also has hrawclk according to some notes
in BSpec, but we don't actually need it for anything, so let's not
even try to read it out there.
v2: Rebase due to IS_VALLYVIEW vs. IS_CHERRYVIEW split
Use KHz() all over, and kill off a few useless temp variables
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The cherryview device shares many characteristics with the valleyview
device. When support was added to the driver for cherryview, the
corresponding device info structure included .is_valleyview = 1.
This is not correct and leads to some confusion.
This patch changes .is_valleyview to .is_cherryview in the cherryview
device info structure and simplifies the IS_CHERRYVIEW macro.
Then where appropriate, instances of IS_VALLEYVIEW are replaced with
IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent.
v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro.
Also add followup patches to fix issues discovered during the first
review. (Ville)
v3: Fix some style issues and one gen check. Remove CRT related changes
as CRT is not supported on CHV. (Imre, Ville)
v4: Make a few more optimizations. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
If the backlight modulation frequency can't be extracted from the
registers or from VBT, use 200 Hz as the default. This may enable
backlight on some machines that previously failed.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448958232-26520-2-git-send-email-jani.nikula@intel.com
The only missing piece is the function to convert frequency to PWM
register value. The PWM is based on 19.2 MHz clock, except for BXT A
step, which is based on CDCLK, and which we ignore.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448958232-26520-1-git-send-email-jani.nikula@intel.com
Although we don't support or enable CPU PWM with LPT/SPT based systems,
it may have been enabled prior to loading the driver. Disable the CPU
PWM on LPT/SPT backlight disable to avoid warnings on LCPLL disable.
The issue has been present on BDW since BDW enabling, but was recently
introduced on HSW with
commit 437b15b801
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Sep 4 16:55:13 2015 +0300
drm/i915: use pch backlight override on hsw too
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reference: http://mid.gmane.org/87y4frhwsn.fsf@yhuang-dev.intel.com
Reported-by: kernel test robot <ying.huang@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446033429-8006-1-git-send-email-jani.nikula@intel.com
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Latest VBT mentions which set of registers will be used for BLC,
as controller number field. Making use of this field in BXT
BLC implementation. Also, the registers are used in case control
pin indicates display DDI. Adding a check for this.
According to Bspec, BLC_PWM_*_2 uses the display utility pin for output.
To use backlight 2, enable the utility pin with mode = PWM
v2: Jani's review comments
addressed
- Add a prefix _ to BXT BLC registers definitions.
- Add "bxt only" comment for u8 controller
- Remove control_pin check for DDI controller
- Check for valid controller values
- Set pipe bits in UTIL_PIN_CTL
- Enable/Disable UTIL_PIN_CTL in enable/disable_backlight()
- If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity
Satheesh's review comment addressed
- If UTIL PIN is already enabled, BIOS would have programmed it. No
need to disable and enable again.
v3: Jani's review comments
- add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK
- Disable UTIL_PIN if controller 1 is used
- Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before enabling
UTIL_PIN
- check valid controller value in intel_bios.c
- add backlight.util_pin_active_low
- disable util pin before enabling
v4: Change for BXT-PO branch:
Stubbed unwanted definition which was existing before
because of DC6 patch.
UTIL_PIN_MODE_PWM (0x1b << 24)
v2: Fixed Jani's review comment.
v3: Split the backight PWM frequency programming into separate patch,
in cases BIOS doesn't initializes it.
v4: Starting afresh and not modifying existing state for backlight, as
per Jani's recommendation.
v5: Fixed Jani's review comment wrt util pin enable
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously we've relied on having basically one backlight and one
backlight type per platform. This is already a bit quirky with PMIC PWM
support on VLV/CHV platforms with MIPI DSI. In the foreseeable future
we'll have at least DPCD based backlight control on eDP and DCS command
based backlight control on MIPI DSI. Backlight is becoming more and more
connector specific, so reflect this fact by making the backlight control
hooks connector specific.
This enables further work to reuse generic backlight code in
intel_panel.c while adding more specific backlight code accessed via the
hooks.
Cc: Deepak M <m.deepak@intel.com>
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Deepak M <m.deepak@intel.com>
Reviewed-by: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make adjusted_mode const whereever we don't have to modify it. This only
covers cases when we have a local adjusted_mode variable, and doesn't
make any difference for cases where we just dereference
pipe_config->adjusted_mode.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The adjustead_mode crtc_ timings are what we will program into the hardware,
so it's those timings we should be looking practically everywhere.
The normal and crtc_ timings should differ only when stere doubling is
used. In that case the normal timings are the orignal non-doubled
timigns, and crtc_ timings are the doubled timings used by the hardware.
The only case where we continue to look at the normal timings is when we
pass the adjusted_mode to drm_match_{cea,hdmi}_mode() to find the VIC.
drm_edid keeps the modes aronund in the non-double form only, so it
needs the non-double timings to match against.
Done with sed
's/adjusted_mode->\([vhVH]\)/adjusted_mode->crtc_\1/g'
's/adjusted_mode->clock/adjusted_mode->crtc_clock/g'
with a manual s/VDisplay/vdisplay/ within the comment in intel_dvo.c
v2: Update due to intel_dsi.c changes
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename the function argument to 'adjusted_mode' whenever the function
only ever gets passed the adjusted_mode.
v2: Update due to intel_dsi.c changes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.
vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fall back to VBT based backlight modulation frequency if it's not
set. Do not hard code.
This could be a problem if there is no VBT.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Normally we determine the backlight PWM modulation frequency (which we
also use as backlight max value) from the backlight registers at module
load time, expecting the registers have been initialized by the BIOS. If
this is not the case, we fail.
The VBT contains the backlight modulation frequency in Hz. Add platform
specific functions to convert the frequency in Hz to backlight PWM
modulation frequency, and use them to initialize the backlight when the
registers are not initialized by the BIOS.
v2: Fix SPT and VLV. Thanks to Clint for the VLV code.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently the difference between backlight control on HSW vs. BDW/SKL is
that on HSW we modify the duty cycle on the CPU register, and have the
hardware pass the changes on to the PCH registers. We still drive the
PCH PWM on both. While HSW and BDW use the same LPT PCH, BDW does not
pass these messages on to the PCH. Therefore on BDW we need to enable
the PCH override bit, and program the PCH directly. (On SPT PCH, this
mode is the default.) We could as well do this on HSW too, and in fact
I've been told this is what a certain other operating system does. So
use PCH backlight override on HSW too.
This simplifies some follow-up code, but it does have the danger of
breaking backlight on HSW machines. It should work, but mysterious are
the ways of backlight.
While at it, name the related backlight hooks according to the PCH
rather than the CPU for clarity.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
- Renamed all function as pwm_* instead of vlv_*
- Call intel_panel_actually_set_backlight in enable function
- Return -ENODEV in case pwm_get fails
- in case pwm_config error return error cdoe from pwm_config
- Cleanup pwm in intel_panel_destroy_backlight
v4: Removed unused #defines and initialized backlight with INVALID_PIPE (Ville)
CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some 855gm models (at least ThinkPad X40) regressed because of
commit b0cd324fae
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Nov 12 16:25:43 2014 +0200
drm/i915: don't save/restore backlight hist ctl registers
which tried to make our driver more robust by not blindly saving and
restoring registers, but it failed to take into account
commit 0eb96d6ed3
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Oct 14 12:33:41 2009 -0700
drm/i915: save/restore BLC histogram control reg across suspend/resume
Fix the regression by enabling hist ctl on gen2.
v2: Improved the comment.
v3: Improved the comment, again.
Reported-and-tested-by: Philipp Gesang <phg@phi-gamma.net>
References: http://mid.gmane.org/20150623222648.GD12335@acheron
Fixes: b0cd324fae ("drm/i915: don't save/restore backlight hist ctl registers")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Enabling BLC on BXT.
Includes register definition, and new functions for BXT.
In BXT, there are 2 sets of registers for BLC. Until there is clarity
about which set would be effective, set 1 is being used.
This would have to be re-visited if there is any change or when 2 LFPs are
enabled on BXT.
This patch enables brightness change which would be effected by use of
hot-keys or sysfs entry.
TODO:- BLC implementation will have to re-visited when
1. there is clarity about which set of registers has to be used and when.
2. CDCLK frequency is changed
v2: Jani's review comments
- Modified comment in i915_reg.h
- Renamed register defintions
- Removed definition of duty cycle max. Not required now and its not 64-bit.
v3:
- Rebase on top of VLV/CHV backlight changes, in particuliar
bxt_set_backlight() now has a different prototype (Damien)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Shankar, Uma <uma.shankar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have grown a number of different implementations of
DIV_ROUND_CLOSEST_ULL throughout the kernel. Move the i915 one to
kernel.h so that it can be reused.
Signed-off-by: Javi Merino <javi.merino@arm.com>
Reviewed-by: Jeff Epler <jepler@unpythonic.net>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Guenter Roeck <linux@roeck-us.net>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Alex Elder <elder@linaro.org>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull drm updates from Dave Airlie:
"This is the main drm pull, it has a shared branch with some alsa
crossover but everything should be acked by relevant people.
New drivers:
- ATMEL HLCDC driver
- designware HDMI core support (used in multiple SoCs).
core:
- lots more atomic modesetting work, properties and atomic ioctl
(hidden under option)
- bridge rework allows support for Samsung exynos chromebooks to
work finally.
- some more panels supported
i915:
- atomic plane update support
- DSI uses shared DSI infrastructure
- Skylake basic support is all merged now
- component framework used for i915/snd-hda interactions
- write-combine cpu memory mappings
- engine init code refactored
- full ppgtt enabled where execlists are enabled.
- cherryview rps/gpu turbo and pipe CRC support.
radeon:
- indirect draw support for evergreen/cayman
- SMC and manual fan control for SI/CI
- Displayport audio support
amdkfd:
- SDMA usermode queue support
- replace suballocator usage with more suitable one
- rework for allowing interfacing to more than radeon
nouveau:
- major renaming in prep for later splitting work
- merge arm platform driver into nouveau
- GK20A reclocking support
msm:
- conversion to atomic modesetting
- YUV support for mdp4/5
- eDP support
- hw cursor for mdp5
tegra:
- conversion to atomic modesetting
- better suspend/resume support for child devices
rcar-du:
- interlaced support
imx:
- move to using dw_hdmi shared support
- mode_fixup support
sti:
- DVO support
- HDMI infoframe support
exynos:
- refactoring and cleanup, removed lots of internal unnecessary
abstraction
- exynos7 DECON display controller support
Along with the usual bunch of fixes, cleanups etc"
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (724 commits)
drm/radeon: fix voltage setup on hawaii
drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary
drm/radeon: only enable kv/kb dpm interrupts once v3
drm/radeon: workaround for CP HW bug on CIK
drm/radeon: Don't try to enable write-combining without PAT
drm/radeon: use 0-255 rather than 0-100 for pwm fan range
drm/i915: Clamp efficient frequency to valid range
drm/i915: Really ignore long HPD pulses on eDP
drm/exynos: Add DECON driver
drm/i915: Correct the base value while updating LP_OUTPUT_HOLD in MIPI_PORT_CTRL
drm/i915: Insert a command barrier on BLT/BSD cache flushes
drm/i915: Drop vblank wait from intel_dp_link_down
drm/exynos: fix NULL pointer reference
drm/exynos: remove exynos_plane_dpms
drm/exynos: remove mode property of exynos crtc
drm/exynos: Remove exynos_plane_dpms() call with no effect
drm/i915: Squelch overzealous uncore reset WARN_ON
drm/i915: Take runtime pm reference on hangcheck_info
drm/i915: Correct the IOSF Dev_FN field for IOSF transfers
drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage
...
The objective is to make this structure usable with the atomic helpers,
so let's start with the rename. Patch generated with coccinelle:
@@ @@
-struct intel_crtc_config {
+struct intel_crtc_state {
...
}
@@ @@
-struct intel_crtc_config
+struct intel_crtc_state
v2: Completely generate the patch with cocci. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 6dda730e55
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Jun 24 18:27:40 2014 +0300
drm/i915: respect the VBT minimum backlight brightness
introduced a bug which resulted in inconsistent brightness levels on
different machines. If a suspended was entered with the screen off some
machines would resume with the screen at minimum brightness and others
at maximum brightness.
The following commands can be used to produce this behavior.
xset dpms force off
sleep 1
sudo systemctl suspend
(resume ...)
The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled. If it is zero,
it is set to the maximum level. Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.
Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero. Also, expand the comparison for
the possible case when the level is less than the minimum.
Fixes: 6dda730e55 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
So with all the code movement and extraction in intel_pm.c in -next
git is hopelessly confused with
commit 2208d655a9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Nov 14 09:25:29 2014 +0100
drm/i915: drop WaSetupGtModeTdRowDispatch:snb
from -fixes. Worse even small changes in -next move around the
conflict context so rerere is equally useless. Let's just backmerge
and be done with it.
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_pm.c
Except for git getting lost no tricky conflicts really.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Now that the backlight device no longer gets registered too early we
should be able to drop most of the INVALID_PIPE checks from the backlight
code.
The only exceptio is the opregion stuff where we may (in theory at
least) get a request from the BIOS already during driver init as soon as
the backlight setup has been done. In which case we can still get the
INVALID_PIPE from intel_get_pipe_from_connector(). So leave that check
in place, and add a comment explaining why.
For the rest, if we still manage to get here with INVALID_PIPE on
VLV/CHV we will now get a WARN from the lower level functions and
can then actually investigate further.
v2: Leave the check in the BIOS related code (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
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>
Currently we register the backlight device as soon as we register the
connector. That means we can get backlight requests from userspace
already before reading out the current modeset hardware state.
That means we don't yet know the current crtc->encoder->connector mapping,
which causes problems for VLV/CHV which need to know the current pipe in
order to figure out which BLC registers to poke. Currently we just
ignore such requests fairly deep in the backlight code which means the
backlight device brightness property will get out of sync with our
backlight.level and the actual hardware state.
Fix the problem by delaying the backlight device registration until the
entire modeset init has been performed. And we also move the
backlight unregisteration to happen as the first thing during the
modeset cleanup so that we also won't be bothered with userspace
backlight requested during teardown.
This is a real world problem on machines using systemd, because systemd,
for some reason, wants to restore the backlight to the level it used last
time. And that happens as soon as it sees the backlight device appearing
in the system. Sometimes the userspace access makes it through before
the modeset init, sometimes not.
v2: Do not lie to the user in the debug prints (Jani)
Include connector name in the prints (Jani)
Fix a typo in the commit message (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/CHV both pipes A and B have their own backlight control
registers. In order to correctly read out the current hardware state at
init we need to know which pipe is driving the eDP port. Pass that
information down from the eDP init code into the backlight code.
To determine the correct pipe we first look at which pipe is currently
configured in the port control register, if that look invalid we look
at which pipe's PPS is currently controlling the port, and if that
too looks invalid we just assume pipe A.
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>
On VLV/CHV when the display is off, we can't read out the current
backlight level from the hardware since we have no pipe to do so.
Currently we end up reading a bigus register due to passing
INVALID_PIPE to VLV_BLC_PWM_CTL().
Skip the entire .get_backlight() call if the backlight isn't enabled
according to backlight.enabled.
This problem can be reproduced simply by reading the backlight device
actual_brightness file while the display is off.
Cc: Jani Nikula <jani.nikula@intel.com>
Suggested-by: Jani Nikula <jani.nikula@intel.com>
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>
VLV/CHV have backlight controls only on pipes A and B. Bail out
without touching registers that don't exist, and print a warning.
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>
Never trust (your interpretation of) the VBT. Regression from
commit 6dda730e55
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Jun 24 18:27:40 2014 +0300
drm/i915: respect the VBT minimum backlight brightness
causing div by zero if VBT minimum brightness equals maximum brightness.
Despite my attempts I've failed in my detective work to figure out what
the root cause is. This is not the real fix, but we have to do
something.
Reported-by: Mike Auty <mike.auty@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86551
Cc: stable@vger.kernel.org (v3.17+)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
SPT is always in the PCH override mode, and the bit MBZ. Only set
override on LPT.
v2: check for PCH version (Ville)
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>
So I've sent the first pull request to Dave and I expect his request
for a merge tree any second now ;-)
More seriously I have some pending patches for 3.19 that depend upon
both trees, hence backmerge. Conflicts are all trivial.
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/intel_display.c
v2: Of course I've forgotten the fixup script for the silent conflict.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Move the duplicated DIV_ROUND_CLOSEST_ULL macro into the intel_drv.h
header file so that it can be shared between intel_display.c
and intel_panel.c.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-By: Joe Konno <joe.konno@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Improper truncated integer division in the scale() function causes
actual_brightness != brightness. This (partial) work-around should be
sufficient for a majority of use-cases, but it is by no means a complete
solution.
TODO: Determine how best to scale "user" values to "hw" values, and
vice-versa, when the ranges are of different sizes. That would be a
buggy scenario even with this work-around.
The issue was introduced in the following (v3.17-rc1) commit:
6dda730 drm/i915: respect the VBT minimum backlight brightness
Note that for easier backporting this commit adds a duplicated macro.
A follow-up cleanup patch rectifies this for 3.18+
v2: (thanks to Chris Wilson) clarify commit message, use rounded division
macro
v3: -DIV_ROUND_CLOSEST() fails to build with CONFIG_X86_32=y. (Jani)
-Use DIV_ROUND_CLOSEST_ULL() instead. (Damien)
-v1 and v2 originally authored by Joe Konno.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Cc: stable@vger.kernel.org
Reviewed-By: Joe Konno <joe.konno@intel.com>
[danvet: Add backporting note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SKL stage 1 patches still need polish so will likely miss the 3.18
merge window. We've decided to postpone to 3.19 so let's pull this in
to make patch merging and conflict handling easier.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Dave Airlie