aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_dsi.c
AgeCommit message (Collapse)AuthorFilesLines
2019-06-17drm/i915: move modesetting output/encoder code under display/Jani Nikula1-128/+0
Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Acked-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-13drm/i915: Determine DSI panel orientation from VBTVille Syrjälä1-0/+17
VBT appears to have two (or possibly three) ways to indicate the panel rotation. The first is in the MIPI config block, but that apparenly usually (maybe always?) indicates 0 degrees despite the actual panel orientation. The second way to indicate this is in the general features block, which can just indicate whether 180 degress rotation is used. The third might be a separate rotation data block, but that is not at all documented so who knows what it may contain. Let's try the first two. We first try the DSI specicic VBT information, and it it doesn't look trustworthy (ie. indicates 0 degrees) we fall back to the 180 degree thing. Just to avoid too many changes in one go we shall also keep the hardware readout path for now. If this works for more than just my VLV FFRD the question becomes how many of the panel orientation quirks are now redundant? v2: Move the code into intel_dsi.c (Jani) Cc: Hans de Goede <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Hans de Goede <[email protected]>
2018-10-31drm/i915/dsi: move connector mode functions to common fileMadhav Chauhan1-0/+47
Move DSI connector functions to intel_dsi.c and make them available to both legacy and ICL DSI. v2 by Jani: - Move the functions to intel_dsi.c - Don't reuse intel_dsi_connector_destroy() Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/99244c6edf4a26ef2e279c7160d22dbbb5cd95f2.1540900289.git.jani.nikula@intel.com
2018-10-31drm/i915/icl: Move dsi host init code to common fileMadhav Chauhan1-0/+34
This patch moves intl_dsi_host_init() code to intel_dsi.c so that legacy and gen11 DSI code can share this code. v2 by Jani: - Move the shared stuff to intel_dsi.c Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1ee42b2d3c639e3f3c14a2c1595b8778901574d4.1540900289.git.jani.nikula@intel.com
2018-10-22drm/i915/dsi: abstract intel_dsi_tlpx_ns()Jani Nikula1-0/+13
Will be needed in the future. No functional changes. Cc: Madhav Chauhan <[email protected]> Cc: Ville Syrjala <[email protected]> Reviewed-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/2cb427e5bc2ea88e4226bfcf162b3a6f307e32e1.1539613303.git.jani.nikula@intel.com
2018-10-18drm/i915/dsi: refactor bitrate calculations in intel_dsi_vbt_init()Jani Nikula1-0/+17
Abstract bitrate calculation to a newly resurrected intel_dsi.c file that will contain common code for VLV and ICL DSI. No functional changes. Cc: Madhav Chauhan <[email protected]> Cc: Ville Syrjala <[email protected]> Reviewed-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/100e9721dfdec4f3987549ef24291bafc9cb0517.1539613303.git.jani.nikula@intel.com
2018-07-06drm/i915/dsi: rename the current DSI files based on first platformJani Nikula1-1866/+0
Starting from ICL or gen 11 we have a new DSI block which requires completely different programming from the current implementation. Having them in the same file would be confusing. Rename the current DSI and DSI PLL implementation files as vlv_dsi.c and vlv_dsi_pll.c. No functional changes. v2: use "gen7" prefix. v3: use "vlv" prefix. References: https://patchwork.freedesktop.org/series/44823/ Cc: Madhav Chauhan <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-06-13drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSIVille Syrjälä1-0/+6
When encountering a connector with the scaling mode property both intel and modesetting ddxs sometimes add tons of DBLSCAN modes to the output's mode list. The idea presumably being that since the output will be going through the panel fitter anyway we can pretend to use any kind of mode. Sadly that means we can't reject user modes with the DBLSCAN flag until we know whether we're going to be using the panel's native mode or the user mode directly. Doing otherwise means X clients using xf86vidmode/xrandr will get a protocol error (and often self terminate as a result) when the kernel refuses to use the requested mode with the DBLSCAN flag. To undo the regression we'll move the DBLSCAN checks into the connector->mode_valid() and encoder->compute_config() hooks. Cc: [email protected] Cc: Vito Caputo <[email protected]> Reported-by: Vito Caputo <[email protected]> Fixes: e995ca0b8139 ("drm/i915: Provide a device level .mode_valid() hook") References: https://lkml.org/lkml/2018/5/21/715 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106804 Tested-by: Arkadiusz Miskiewicz <[email protected]>
2018-06-01drm/i915: s/plane/i9xx_plane/Ville Syrjälä1-4/+4
Call the enum i9xx_plane_id variable i9xx_plane like we do elsewhere. Cc: Hans de Goede <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]>
2018-05-22Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."Jani Nikula1-1/+1
This reverts commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e. Per the report, no matter what display mode you select with xrandr, the i915 driver will always select the alternate fixed mode. For the reporter this means that the display will always run at 40Hz which is quite annoying. This may be due to the mode comparison. But there are some other potential issues. The choice of alt_fixed_mode seems dubious. It's the first non-preferred mode, but there are no guarantees that the only difference would be refresh rate. Similarly, there may be more than one preferred mode in the probed modes list, and the commit changes the preferred mode selection to choose the last one on the list instead of the first. (Note that the probed modes list is the raw, unfiltered, unsorted list of modes from drm_add_edid_modes(), not the pretty result after a drm_helper_probe_single_connector_modes() call.) Finally, we already have eerily similar code in place to find the downclock mode for DRRS that seems like could be reused here. Back to the drawing board. Note: This is a hand-crafted revert due to conflicts. If it fails to backport, please just try reverting the original commit directly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105469 Reported-by: Rune Petersen <[email protected]> Reported-by: Mark Spencer <[email protected]> Fixes: dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP if available.") Cc: Clint Taylor <[email protected]> Cc: David Weinehall <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Jim Bride <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.14+ Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Dhinakaran Pandiyan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-29drm/i915: Provide a device level .mode_valid() hookVille Syrjälä1-5/+0
We never support certain mode flags etc. Reject those early on in the mode_config.mode_valid() hook. That allows us to remove some duplicated checks from the connector .mode_valid() hooks, and it guarantees that we never see those flags even from user mode as the mode_config.mode_valid() hooks gets executed for those as well. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
2017-12-08Merge tag 'drm-intel-next-2017-12-01' of ↵Dave Airlie1-1/+1
git://anongit.freedesktop.org/drm/drm-intel into drm-next [airlied: fix conflict in intel_dsi.c] drm-intel-next-2017-12-01: - Init clock gate fix (Ville) - Execlists event handling corrections (Chris, Michel) - Improvements on GPU Cache invalidation and context switch (Chris) - More perf OA changes (Lionel) - More selftests improvements and fixes (Chris, Matthew) - Clean-up on modules parameters (Chris) - Clean-up around old ringbuffer submission and hw semaphore on old platforms (Chris) - More Cannonlake stabilization effort (David, James) - Display planes clean-up and improvements (Ville) - New PMU interface for perf queries... (Tvrtko) - ... and other subsequent PMU changes and fixes (Tvrtko, Chris) - Remove success dmesg noise from rotation (Chris) - New DMC for Kabylake (Anusha) - Fixes around atomic commits (Daniel) - GuC updates and fixes (Sagar, Michal, Chris) - Couple gmbus/i2c fixes (Ville) - Use exponential backoff for all our wait_for() (Chris) - Fixes for i915/fbdev (Chris) - Backlight fixes (Arnd) - Updates on shrinker (Chris) - Make Hotplug enable more robuts (Chris) - Disable huge pages (TPH) on lack of a needed workaround (Joonas) - New GuC images for SKL, KBL, BXT (Sagar) - Add HW Workaround for Geminilake performance (Valtteri) - Fixes for PPS timings (Imre) - More IPS fixes (Maarten) - Many fixes for Display Port on gen2-gen4 (Ville) - Retry GPU reset making the recover from hang more robust (Chris) * tag 'drm-intel-next-2017-12-01' of git://anongit.freedesktop.org/drm/drm-intel: (101 commits) drm/i915: Update DRIVER_DATE to 20171201 drm/i915/cnl: Mask previous DDI - PLL mapping drm/i915: Remove unsafe i915.enable_rc6 drm/i915: Sleep and retry a GPU reset if at first we don't succeed drm/i915: Interlaced DP output doesn't work on VLV/CHV drm/i915: Pass crtc state to intel_pipe_{enable,disable}() drm/i915: Wait for pipe to start on i830 as well drm/i915: Fix vblank timestamp/frame counter jumps on gen2 drm/i915: Fix deadlock in i830_disable_pipe() drm/i915: Fix has_audio readout for DDI A drm/i915: Don't add the "force audio" property to DP connectors that don't support audio drm/i915: Disable DP audio for g4x drm/i915/selftests: Wake the device before executing requests on the GPU drm/i915: Set fake_vma.size as well as fake_vma.node.size for capture drm/i915: Tidy up signed/unsigned comparison drm/i915: Enable IPS with only sprite plane visible too, v4. drm/i915: Make ips_enabled a property depending on whether IPS is enabled, v3. drm/i915: Avoid PPS HW/SW state mismatch due to rounding drm/i915: Skip switch-to-kernel-context on suspend when wedged drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too ...
2017-12-04drm/i915: Add "panel orientation" property to the panel connector, v6.Hans de Goede1-0/+28
Ideally we could use the VBT for this, that would be simple, in intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set connector->display_info.panel_orientation accordingly and call drm_connector_init_panel_orientation_property(), done. Unfortunately vbt.dsi.config->rotation is always 0 even on tablets with an upside down LCD and where the GOP is properly rotating the EFI fb in hardware. So instead we end up reading the rotation from the primary plane. This commit only implements the panel orientation property for DSI panels on BYT / CHT hardware, as all known non normal oriented panels sofar are only found on this hardware. Changes in v2: -Read back the rotation applied by the GOP from the primary plane instead of relying on dev_priv->vbt.dsi.config->rotation, because it seems that the VBT rotation filed is always 0 even on devices where the GOP does apply a rotation Changes in v3: -Rewrite the code to read back the orientation from the primary plane to contain all of this in intel_dsi.c instead of poking a bunch of holes between all the different layers Changes in v6: -Move hardware readout to intel_dsi_init() Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-11-09drm/i915: Eliminate some encoder->crtc usage from DSI codeVille Syrjälä1-9/+8
Extract the current crtc from the crtc state rather than via the legacy encoder->crtc pointer whenever possible. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> Reviewed-by: Dhinakaran Pandiyan <[email protected]>
2017-10-30drm/i915: Populate output_types from .get_config()Ville Syrjälä1-0/+2
Rather than having the caller of .get_config() set output_types based on encoder->type, let's just have .get_config() itself populate output_types. This way we are isolated from encoder->type, which won't be useable for this purpose anyway soon (at least for DDI encoders). Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2017-10-20drm/i915: Use existing DSI backlight ports infoMadhav Chauhan1-33/+4
This patch re-use already parsed DSI backlight/cabc ports info for saving it inside struct intel_dsi rather than parsing it at the time of DSI initialization. V2: Remove backlight and cabc variable initialization (Jani N). Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-10-06drm/i915: push DDI and DSI underrun reporting on enable to encoderJani Nikula1-1/+6
Simplify CRTC enable. v2: Don't forget DSI (Daniel) Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1ad8f3ccaed99a5f03e3d53345221a25ad0be50f.1507200657.git.jani.nikula@intel.com
2017-09-26drm/i915: Enable scanline read based on frame timestampsUma Shankar1-0/+8
For certain platforms on certain encoders, timings are driven from port instead of pipe. Thus, we can't rely on pipe scanline registers to get the timing information. Some cases scanline register read will not be functional. This is causing vblank evasion logic to fail since it relies on scanline, causing atomic update failure warnings. This patch uses pipe framestamp and current timestamp registers to calculate scanline. This is an indirect way to get the scanline. It helps resolve atomic update failure for gen9 dsi platforms. v2: Addressed Ville and Daniel's review comments. Updated the register MACROs, handled race condition for register reads, extracted timings from the hwmode. Removed the dependency on crtc->config to get the encoder type. v3: Made get scanline function generic v4: Addressed Ville's review comments. Added a flag to decide timestamp based scanline reporting. Changed 64bit variables to u32 v5: Adressed Ville's review comments. Put the scanline compute function at the place of caller. Removed hwmode flags from uapi and used a local i915 data structure instead. v6: Used vblank hwmode to get the timings. v7: Fixed sparse warnings, indentation and minor review comments. v8: Limited this only for Gen9 DSI. Credits-to: Ville Syrjälä <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Signed-off-by: Chandra Konduru <[email protected]> Signed-off-by: Vidya Srinivas <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-09-13drm/i915/dsi: Replace MIPI command error message with debug messageMika Kahola1-1/+1
Error message indicating that the same MIPI command is sent consecutively is perhaps too strongly said. Let's replace that as a debug message instead. Signed-off-by: Mika Kahola <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-09-13Revert "drm/i915/bxt: Disable device ready before shutdown command"Uma Shankar1-11/+0
This reverts commit bbdf0b2ff32a ("drm/i915/bxt: Disable device ready before shutdown command"). Disable device ready before shutdown command was added previously to avoid a split screen issue seen on dual link DSI panels. As of now, dual link is not supported and will need some rework in the upstream code. For single link DSI panels, the change is not required. This will cause failure in sending SHUTDOWN packet during disable. Hence reverting the change. Will handle the change as part of dual link enabling in upstream. Fixes: bbdf0b2ff32a ("drm/i915/bxt: Disable device ready before shutdown command") Cc: <[email protected]> # v4.12+ Signed-off-by: Uma Shankar <[email protected]> Signed-off-by: Vidya Srinivas <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-08-22drm/i915: Constify states passed to enable/disable/etc. encoder hooksVille Syrjälä1-11/+11
The enable/disable/etc. encoder hooks aren't supposed to alter the state(s), so pass them as const. Unfortunately C lacks any kind of deep const thingy, so this can't catch all abuses. But at least it acts as a hint to the reader telling them not to mess about with the state(s). v2: Update intel_tv_mode_find() and ironlake_edp_pll_on() as well v3: Deal with intel_sdvo_connector_state Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-08-15drm/i915/edp: Allow alternate fixed mode for eDP if available.Jim Bride1-1/+1
Some fixed resolution panels actually support more than one mode, with the only thing different being the refresh rate. Having this alternate mode available to us is desirable, because it allows us to test PSR on panels whose setup time at the preferred mode is too long. With this patch we allow the use of the alternate mode if it's available and it was specifically requested. v2 and v3: Rebase v4: * Fix up some leaky mode stuff (Chris) * Rebase v5: * Fix a NULL pointer derefrence (David Weinehall) v6: * Whitespace / spelling / checkpatch clean-up; no functional change. (David) * Rebase Cc: David Weinehall <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: David Weinehall <[email protected]> Signed-off-by: Jim Bride <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-08-08drm: Nuke drm_atomic_helper_connector_dpmsDaniel Vetter1-1/+0
It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: Daniel Vetter <[email protected]> Cc: Archit Taneja <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Peter Senna Tschudin <[email protected]> Cc: Martin Donnelly <[email protected]> Cc: Martyn Welch <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Inki Dae <[email protected]> Cc: Joonyoung Shim <[email protected]> Cc: Seung-Woo Kim <[email protected]> Cc: Kyungmin Park <[email protected]> Cc: Kukjin Kim <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Cc: Stefan Agner <[email protected]> Cc: Alison Wang <[email protected]> Cc: Russell King <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: CK Hu <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Carlo Caione <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Marek Vasut <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Tomi Valkeinen <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Mark Yao <[email protected]> Cc: Heiko Stuebner <[email protected]> Cc: Benjamin Gaignard <[email protected]> Cc: Vincent Abriou <[email protected]> Cc: Yannick Fertre <[email protected]> Cc: Philippe Cornu <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Jonathan Hunter <[email protected]> Cc: Jyri Sarha <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Shawn Guo <[email protected]> Cc: John Stultz <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Cc: Sergei Shtylyov <[email protected]> Cc: Jeffy Chen <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Yakir Yang <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Romain Perier <[email protected]> Cc: Kieran Bingham <[email protected]> Cc: Xinliang Liu <[email protected]> Cc: Alexey Brodkin <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Rongrong Zou <[email protected]> Cc: Rob Clark <[email protected]> Cc: Hai Li <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: zain wang <[email protected]> Cc: Baoyou Xie <[email protected]> Cc: Boris Brezillon <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Neil Armstrong <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Philipp Zabel <[email protected]> Acked-by: Archit Taneja <[email protected]> Tested-by: Philippe Cornu <[email protected]> (on stm) Reviewed-by: Laurent Pinchart <[email protected]> Acked-by: Shawn Guo <[email protected]> Acked-by: Shawn Guo <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Acked-by: Vincent Abriou <[email protected]>
2017-08-08drm: Nuke drm_atomic_helper_connector_set_propertyDaniel Vetter1-1/+0
It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly the same. What is rather strange here is how few drivers set this up, I suspect the earlier patch to handle properties in the core did end up fixing a pile of possible issues. Signed-off-by: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Benjamin Gaignard <[email protected]> Cc: Vincent Abriou <[email protected]> Cc: Eric Anholt <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Vincent Abriou <[email protected]>
2017-06-15drm/i915/glk: Add cold boot sequence for GLK DSIMadhav Chauhan1-28/+51
As per BSEPC, if device ready bit is '0' in enable IO sequence then its a cold boot/reset scenario eg: S3/S4 resume. If cold boot scenario detected in enable IO, then prepare port immediately. In normal boot scenario, prepare port after glk_dsi_device_ready(). Without cold boot sequence enabled, features like S3/S4 doesn't work. Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-06-15drm/i915/glk: Split GLK DSI device ready functionalityMadhav Chauhan1-7/+18
This patch divides glk_dsi_device_ready() function into two part. First part will program LP wake and MIPI DSI mode to MIPI_CTRL reg using newly defined function glk_dsi_enable_io(). glk_dsi_enable_io() will be called from intel_dsi_pre_enable. Second part will do remaining device ready activities using the existing function glk_dsi_device_ready(). Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-06-12drm/i915: Pass crtc_state and connector state to backlight enable/disable ↵Maarten Lankhorst1-2/+2
functions The backlight functions need to determine the pipe and the transcoder the backlight will be enabled on, so pass crtc_state instead of trying to dereference the state without holding locks. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100022 Signed-off-by: Maarten Lankhorst <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]>
2017-05-30drm/i915: Convert DSI connector properties to atomic.Maarten Lankhorst1-33/+5
Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-30drm/i915: Use per-connector scaling mode propertyMaarten Lankhorst1-17/+11
None of the intel connectors can use all types of scaling modes, so only try the ones that are possible. This is another preparation for connectors towards conversion to atomic. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [mlankhorst: Use renamed drm_connector_attach_scaling_mode_property function]
2017-05-30drm/i915: Use atomic scaling_mode instead of panel.fitting_modeMaarten Lankhorst1-6/+5
The first step in converting connector properties to atomic is wiring up the atomic state. We're still not completely supoprting the scaling mode in the atomic case, but this is the first step towards it. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-04-28drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messagesAnder Conselvan de Oliveira1-4/+3
The sequence in glk_dsi_device_ready() enters ULPS then waits until it is *not* active to then disable it. The correct sequence according to the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., ULPS is active, and then disable ULPS. Fixing the condition gets rid of the following spurious error messages: [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence") Cc: Deepak M <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Cc: <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Madhav Chauhan <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-07drm/i915/dsi: rename intel_dsi_pre_disable to intel_dsi_disableJani Nikula1-9/+12
The hook names reflect more the phase in the mode set sequence the hooks are called in than what they actually do in terms of the specific encoder. Stick to that scheme, and rename intel_dsi_pre_disable to intel_dsi_disable. Unify the comments around this while at it. No functional changes. v2: Add more sense in the enable/disable hook comments (Ville) Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Bob Paauwe <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-07drm/i915/dsi: rename intel_dsi_exec_vbt_sequence to intel_dsi_vbt_exec_sequenceJani Nikula1-12/+12
Use the prefix intel_dsi_vbt for all the DSI VBT functions. No functional changes. Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/0a05abca364f3bc7f9caf90c9bd3a68eef5f222f.1488810382.git.jani.nikula@intel.com
2017-03-07drm/i915/dsi: stop using the drm_panel framework completelyJani Nikula1-12/+2
Now that we've stopped using the drm_panel hooks, there aren't any benefits left with using the drm_panel framework. Remove the rest of the drm_panel use. No functional changes. Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/6602e36641451952065092401bd6e6cfbe93e208.1488810382.git.jani.nikula@intel.com
2017-03-07drm/i915/dsi: call vbt_panel_get_modes directly instead of via drm_panelJani Nikula1-1/+1
Commit 18a00095a5f3 ("drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences") started calling the VBT sequence functions directly instead of using the drm_panel hooks. Remove the last drm_panel hook by calling vbt_panel_get_modes() directly. No functional changes. Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/63d0d41f29583507f5968b42b5f52e6574a1f245.1488810382.git.jani.nikula@intel.com
2017-03-07drm/i915/dsi: remove support for more than one panel driverJani Nikula1-18/+1
Fact is, there are no other panel drivers except the VBT based one. Simplify the code and maintenance. No functional changes. Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/7dfd041dd25e8e930150ede09589bb232f6248d5.1488810382.git.jani.nikula@intel.com
2017-03-02drm/i915/glk: Fix DSI enable I/O sequenceMadhav Chauhan1-0/+1
One of the if statement covers the next line in enable I/O sequence. This patch correct the same by adding error message. Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence") Reported-by: Chris Wilson <[email protected]> Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Skip delays for v3 VBTs in vid-modeHans de Goede1-4/+15
For v3 VBTs in vid-mode the delays are part of the VBT sequences, so we should not also delay ourselves otherwise we get double delays. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)Hans de Goede1-0/+2
According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON on enable for cmd-mode, just like we already call their counterparts on disable. Note: untested, my panel is a vid-mode panel. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disableHans de Goede1-0/+2
For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF, v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF orderHans de Goede1-0/+5
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN first. Since the v2 order has known issues, we use the v3 order everywhere, add a comment documenting this. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlightHans de Goede1-2/+2
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as we call intel_panel_enable_backlight() / intel_panel_disable_backlight(). Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()Hans de Goede1-2/+7
Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready state (LP-11), this is the sequence in which things should be done according to the spec. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Group DPOunit clock gate workaround with PLL enableHans de Goede1-8/+8
Move the DPOunit clock gate workaround to directly after the PLL enable. The exact location of the workaround does not matter and there are 2 reasons to group it with the PLL enable: 1) This moves it out of the middle of the init sequence from the spec, making it easier to follow the init sequence / compare it to the spec 2) It is grouped with the pll disable call in intel_dsi_post_disable, so for consistency it should be grouped with the pll enable in intel_dsi_pre_enable Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio callsHans de Goede1-6/+4
Now that we are no longer bound to the drm_panel_ callbacks, call MIPI_SEQ_POWER_ON/OFF at the proper place. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ONHans de Goede1-1/+0
intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET, will always be called at some point before intel_dsi_pre_enable() making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant. In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes against the VBT spec. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/dsi: Document the panel enable / disable sequences from the specHans de Goede1-0/+37
Document the DSI panel enable / disable sequences from the spec, for easy comparison between the code and the spec. Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-01drm/i915/glk: Add MIPIIO Enable/disable sequenceDeepak M1-11/+195
v2: Addressed Jani's Review comments(renamed bit field macros) v3: Jani's Review comment for aligning code to platforms and added wrapper functions. v4: Corrected enable/disable seuqence as per BSPEC v5: Corrected waiting twice for same bit (Review comments: Jani) v6: Rebased to Han's patches(dsi restructuring code) Signed-off-by: Deepak M <[email protected]> Signed-off-by: Madhav Chauhan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-02-28drm/i915/dsi: VLV/CHT Only wait for LP00 on MIPI PORT AHans de Goede1-3/+5
On some devices only MIPI PORT C is used, in this case checking the MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C on VLV/CHT) will result in false positive "DSI LP not going Low" errors as this checks the PORT A clk status. In case both ports are used we have already checked the AFE_LATCHOUT bit when going through the for_each_dsi_port() loop for PORT A and checking the same bit again for PORT C is a no-op. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97061 Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/242e4438bf29ebffc66eaa182f22b9d60d304bc2.1488273823.git.jani.nikula@intel.com
2017-02-28drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequencesHans de Goede1-4/+10
The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are not fine grained enough to abstract all the different steps we need to take (and VBT sequences we need to exec) properly. So simply remove the panel _enable/disable and prepare/unprepare callbacks and instead export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c and call that from intel_dsi_enable/disable(). No functional changes. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bob Paauwe <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/b4ca5185d4788d92df2ed60837a24b8962a8e8ba.1488273823.git.jani.nikula@intel.com
Powered by cgit, Gruvboxed by Blaster4385.