summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_hdmi.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'drm-intel-next-2013-08-23' of ↵Dave Airlie2013-08-301-2/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Need to get my stuff out the door ;-) Highlights: - pc8+ support from Paulo - more vma patches from Ben. - Kconfig option to enable preliminary support by default (Josh Triplett) - Optimized cpu cache flush handling and support for write-through caching of display planes on Iris (Chris) - rc6 tuning from Stéphane Marchesin for more stability - VECS seqno wrap/semaphores fix (Ben) - a pile of smaller cleanups and improvements all over Note that I've ditched Ben's execbuf vma conversion for 3.12 since not yet ready. But there's still other vma conversion stuff in here. * tag 'drm-intel-next-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel: (62 commits) drm/i915: Print seqnos as unsigned in debugfs drm/i915: Fix context size calculation on SNB/IVB/VLV drm/i915: Use POSTING_READ in lcpll code drm/i915: enable Package C8+ by default drm/i915: add i915.pc8_timeout function drm/i915: add i915_pc8_status debugfs file drm/i915: allow package C8+ states on Haswell (disabled) drm/i915: fix SDEIMR assertion when disabling LCPLL drm/i915: grab force_wake when restoring LCPLL drm/i915: drop WaMbcDriverBootEnable workaround drm/i915: Cleaning up the relocate entry function drm/i915: merge HSW and SNB PM irq handlers drm/i915: fix how we mask PMIMR when adding work to the queue drm/i915: don't queue PM events we won't process drm/i915: don't disable/reenable IVB error interrupts when not needed drm/i915: add dev_priv->pm_irq_mask drm/i915: don't update GEN6_PMIMR when it's not needed drm/i915: wrap GEN6_PMIMR changes drm/i915: wrap GTIMR changes drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq ...
| * drm/i915: remove set but unused variablesPaulo Zanoni2013-08-221-2/+0
| | | | | | | | | | | | | | Caught by "make W=1 drivers/gpu/drm/i915/". Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/hdmi: Write HDMI vendor specific infoframesLespiau, Damien2013-08-301-0/+28
| | | | | | | | | | | | | | | | | | | | With all the common infoframe bits now in place, we can finally write the vendor specific infoframes in our driver. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
* | Merge tag 'drm-intel-next-2013-08-09' of ↵Dave Airlie2013-08-211-115/+138
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: New pile of stuff for -next: - Cleanup of the old crtc helper callbacks, all encoders are now converted to the i915 modeset infrastructure. - Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is prep work to eventually get things going for nuclear pageflips where we need to adjust watermarks on the fly. - More vm/vma patches from Ben. This refactoring isn't yet fully rolled out, we miss the execbuf conversion and some of the low-level bind/unbind support code. - Convert our hdmi infoframe code to use the new common helper functions (Damien). This contains some bugfixes for the common infoframe helpers. - Some cruft removal from Damien. - Various smaller bits&pieces all over, as usual. * tag 'drm-intel-next-2013-08-09' of git://people.freedesktop.org/~danvet/drm-intel: (105 commits) drm/i915: Fix FB WM for HSW drm/i915: expose HDMI connectors on port C on BYT drm/i915: fix a limit check in hsw_compute_wm_results() drm/i915: unbreak i915_gem_object_ggtt_unbind() drm/i915: Make intel_set_mode() static drm/i915: Remove intel_modeset_disable() drm/i915: Make intel_encoder_dpms() static drm/i915: Make i915_hangcheck_elapsed() static drm/i915: Fix #endif comment drm/i915: Remove i915_gem_object_check_coherency() drm/i915: Remove stale prototypes drm/i915: List objects allocated from stolen memory in debugfs drm/i915: Always call intel_update_sprite_watermarks() when disabling a plane drm/i915: Pass plane and crtc to intel_update_sprite_watermarks drm/i915: Don't try to disable plane if it's already disabled drm/i915: Pass crtc to our update/disable_plane hooks drm/i915: Split plane watermark parameters into a separate struct drm/i915: Pull some watermarks state into a separate structure drm/i915: Calculate max watermark levels for ILK+ drm/i915: Rename hsw_lp_wm_result to intel_wm_level ...
| * drm/i915/hmdi: Rename set_infoframe() to write_infoframe()Damien Lespiau2013-08-081-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | set_frame() wraps the write_frame() vfunc. Be consistent and name the wrapping function like the vfunc being called. It's doubly confusing as we also have a set_infoframes() vfunc and set_infoframe() doesn't wrap it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: Handle the DBLCLK flag in the common infoframe helperDamien Lespiau2013-08-081-3/+0
| | | | | | | | | | | | | | | | Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Remove the now obsolete infoframe definitionsDamien Lespiau2013-08-081-15/+0
| | | | | | | | | | | | | | | | | | All the HDMI infoframe code has been ported to use video/hdmi.c, so it's time to say bye bye to this code. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/hdmi: Port the infoframe code to the common hdmi helpersDamien Lespiau2013-08-081-24/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's use the drivers/video/hmdi.c and drm infoframe helpers to build our infoframes. v2: Simplify the logic to compute the buffer size. We can just take the maximum infoframe size rounded to 32, which happens to be what the hardware let us write anyway. v3: Remove unnecessary memset() (Ville Syrjälä) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/hdmi: Change the write_infoframe vfunc to take a buffer and a typeDamien Lespiau2013-08-081-50/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First step in the move to the shared infoframe infrastructure, let's move the different infoframe helpers and the write_infoframe() vfunc to a type (enum hdmi_infoframe_type) and a buffer + len instead of using our struct dip_infoframe. v2: constify the infoframe pointer and don't mix signs (Ville Syrjälä) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: rearrange vlv hdmi enable and pre_enable callbacksJani Nikula2013-08-051-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VLV wants encoder enabling before the pipe is up. This is currently achieved through calling the ->enable callback early, right after the ->pre_enable callback, in valleyview_crtc_enable(). This loses both the distinction between ->pre_enable and ->enable on VLV and the possibility to use a hook at the end of the modeset sequence. Rearrange the HDMI callbacks to make it possible to move ->enable call later. Basically do everything in ->pre_enable on VLV, and make ->enable a NOP. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMIChris Wilson2013-08-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we get flooded by the kernel warning us that we are doing long sequences of IO without serialisation. For example, WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef() Modules linked in: CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G W 3.11.0-rc2+ #4 Call Trace: [<c2028564>] ? warn_slowpath_common+0x63/0x78 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c20285dd>] ? warn_slowpath_null+0xf/0x13 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c227b060>] ? vlv_dpio_write+0x1c/0x21 [<c2262b3b>] ? intel_dp_set_signal_levels+0x24a/0x385 [<c2264909>] ? intel_dp_complete_link_train+0x25/0x1d1 [<c2264c55>] ? intel_dp_check_link_status+0xf7/0x106 [<c2238ced>] ? i915_hotplug_work_func+0x17b/0x221 [<c203a204>] ? process_one_work+0x12e/0x210 [<c203a5e4>] ? worker_thread+0x116/0x1ad [<c203a4ce>] ? rescuer_thread+0x1cb/0x1cb [<c203d8f5>] ? kthread+0x67/0x6c [<c2457ebb>] ? ret_from_kernel_thread+0x1b/0x30 [<c203d88e>] ? init_completion+0x18/0x18 v2: Retire the locking in vlv_crtc_enable() and do it close to the meat. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Squash in a s/mutex_lock/mutex_unlock/ fixup spotted by the 0 day kernel build/coccinelle and reported by Dan Carpenter.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/hdmi: use native encoder mode_set callbackDaniel Vetter2013-08-041-17/+12
| | | | | | | | | | | | | | | | | | | | Again drop the intel_ prefix from the intel_crtc local variable to save a bit of space. But here I didn't switch the upcast macros to intel_encoder since all our infoframe interfaces still use drm_encoder. That needs to be changed first. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge remote-tracking branch 'pfdo/drm-rcar-for-v3.12' into drm-nextDave Airlie2013-08-191-3/+16
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge the rcar stable branch that is being shared with the arm-soc tree. Signed-off-by: Dave Airlie <airlied@redhat.com> * pfdo/drm-rcar-for-v3.12: (220 commits) drm/rcar-du: Add FBDEV emulation support drm/rcar-du: Add internal LVDS encoder support drm/rcar-du: Configure RGB output routing to DPAD0 drm/rcar-du: Rework output routing support drm/rcar-du: Add support for DEFR8 register drm/rcar-du: Add support for multiple groups drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU drm/rcar-du: Add support for the R8A7790 DU drm/rcar-du: Move output routing configuration to group drm/rcar-du: Remove register definitions for the second channel drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size drm/rcar-du: Introduce CRTCs groups drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_* drm/rcar-du: Create rcar_du_planes structure drm/rcar-du: Rename platform data fields to match what they describe drm/rcar-du: Merge LVDS and VGA encoder code drm/rcar-du: Split VGA encoder and connector drm/rcar-du: Split LVDS encoder and connector drm/rcar-du: Clarify comment regarding plane Y source coordinate drm/rcar-du: Support per-CRTC clock and IRQ ... Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/intel_pm.c drivers/gpu/drm/qxl/qxl_release.c
| * drm/i915: fix hdmi portclock limitsDaniel Vetter2013-07-231-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 325b9d048810f7689ec644595061c0b700e64bce Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 19 11:24:33 2013 +0200 drm/i915: fixup 12bpc hdmi dotclock handling I've errornously claimed that we don't yet support the hdmi 1.4 dotclocks > 225 MHz on Haswell. But a bug report and a closer look at the wrpll table showed that we've supported port clocks up to 300MHz. With the new code to dynamically compute wrpll limits we should have no issues going up to the full 340 MHz range of hdmi 1.4, so let's just use that to fix this regression. That'll allow 4k over hdmi for free! v2: Drop the random hunk that somehow slipped in. v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also patch up the mode filtering. To do so extract the dotclock limits into a little helper function. v4: Use 300MHz (from Bspec) instead of 340MHz (upper limit for hdmi 1.3), apparently hw is not required to be able to drive the highest dotclocks. Suggested by Damien. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030 Tested-by: Andreas Reis <andreas.reis@gmail.com> (v2) Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Add some debug breadcrumbs to connector detectionChris Wilson2013-07-241-0/+3
|/ | | | | | | | | | | Try to decypher detection failures is a little tricker at the moment as the only indicator of progress is when output_poll_execute() tells us the result after the connector->detect() has run. This patch adds a telltale to the start of each detect function so that we can track progress and associate activity more clearly with each connector. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915: Don't use the HDMI port color range bit on Valleyview"Ville Syrjälä2013-07-011-1/+1
| | | | | | | | | | | | | | The PIPECONF color range bit doesn't appear to be effective, on HDMI outputs at least. The color range bit in the port register works though, so let's use it. I have not yet verified whether the PIPECONF bit works on DP outputs. This reverts commit 83a2af88f80ebf8104c9e083b786668b00f5b9ce. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: store adjusted dotclock in adjusted_mode->clockDaniel Vetter2013-06-041-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... not the port clock. This allows us to kill the funny semantics around pixel_target_clock. Since the dpll code still needs the real port clock, add a new port_clock field to the pipe configuration. Handling the default case for that one is a bit tricky, since encoders might not consistently overwrite it when retrying the crtc/encoder bw arbitrage step in the compute config stage. Hence we need to always clear port_clock and update it again if the encoder hasn't put in something more specific. This can't be done in one step since the encoder might want to adjust the mode first. I was a bit on the fence whether I should subsume the pixel multiplier handling into the port_clock, too. But then I decided against this since it's on an abstract level still the dotclock of the adjusted mode, and only our hw makes it a bit special due to the separate pixel mulitplier setting (which requires that the dpll runs at the non-multiplied dotclock). So after this patch the adjusted_mode accurately describes the mode we feed into the port, after the panel fitter and pixel multiplier (or line doubling, if we ever bother with that) have done their job. Since the fdi link is between the pfit and the pixel multiplier steps we need to be careful with calculating the fdi link config. v2: Fix up ilk cpu pll handling. v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config to make it clearer that we transmit the adjusted_mode without the pixel multiplier taken into account. The old code multiplied the the available link bw with the pixel multiplier, which results in the same fdi configuration, but is much more confusing. v4: Rebase on top of Imre's is_cpu_edp removal. v5: Rebase on top of Paulo's haswell watermark fixes, which introduce a new place which looked at the pixel_clock and so needed conversion. v6: Split out prep patches as requested by Paulo Zanoni. Also rebase on top of the fdi dotclock handling fix in the fdi lanes/bw computation code. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rename VLV IOSF sideband functions logicallyJani Nikula2013-05-231-21/+21
| | | | | | | | | Rename all VLV IOSF sideband register accessor functions to vlv_<port>_{read,write}. 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>
* drm/i915: drop redundant warnings on not holding dpio_lockJani Nikula2013-05-231-4/+0
| | | | | | | | The lower level sideband read/write functions already do this. 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>
* drm/i915: add encoder get_config function v5Jesse Barnes2013-05-211-0/+23
| | | | | | | | | | | | | | | | | | | | | We can use this for fetching encoder specific pipe_config state, like mode flags, adjusted clock, etc. Just used for mode flags atm, so we can check the pipe config state at mode set time. v2: get_config when checking hw state too v3: fix DVO and LVDS mode flags (Ville) get SDVO DTD for flag fetch (Ville) v4: use input timings (Ville) correct command used (Ville) remove gen4 check (Ville) v5: get DDI flag config too Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4) Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.10-rc2' into drm-intel-next-queuedDaniel Vetter2013-05-211-0/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.10-rc2 since the various (rather trivial) conflicts grew a bit out of hand. intel_dp.c has the only real functional conflict since the logic changed while dev_priv->edp.bpp was moved around. Also squash in a whitespace fixup from Ben Widawsky for i915_gem_gtt.c, git seems to do something pretty strange in there (which I don't fully understand tbh). Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: avoid full modeset when changing the color range propertiesDaniel Vetter2013-04-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Automatic color range selection was added in commit 55bc60db5988c8366751d3d04dd690698a53412c Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Jan 17 16:31:29 2013 +0200 drm/i915: Add "Automatic" mode for the "Broadcast RGB" property but that removed the check to avoid a full modeset if the value is unchanged. Unfortunately X sets all properties with their current value at start-up, resulting in some ugly flickering which shouldn't be there. v2: Change old_range from bool to uint32_t, spotted by Ville. v3: Actually git add everything ;-) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: implement fdi auto-ditheringDaniel Vetter2013-04-291-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit into this, among them the default 1080p mode. The solution is to dither down the pipe a bit so that everything fits, which this patch implements. But ports compute their state under the assumption that the bpp they pick will be the one selected, e.g. the display port bw computations won't work otherwise. Now we could adjust our code to again up-dither to the computed DP link parameters, but that's pointless. So instead when the pipe needs to adjust parameters we need to retry the pipe_config computation at the encoder stage. Furthermore we need to inform encoders that they should not increase bandwidth requirements if possible. This is required for the hdmi code, which prefers the pipe to up-dither to either of the two possible hdmi bpc values. LVDS has a similar requirement, although that's probably only theoretical in nature: It's unlikely that we'll ever see an 8bpc high-res lvds panel (which is required to hit the 2 fdi lane limit). eDP is the only thing which could increase the pipe_bpp setting again, even when in the retry-loop. This could hit the WARN. Two reasons for not bothering: - On many eDP panels we'll get a black screen if the bpp settings don't match vbt. So failing the modeset is the right thing to do. But since that also means it's the only way to light up the panel, it should work. So we shouldn't be able to hit this WARN. - There are still opens around the eDP panel handling, and maybe we need additional tricks. Before that happens it's imo no use trying to be too clever. Worst case we just need to kill that WARN or maybe fail the compute config stage if the eDP connector can't get the bpp setting it wants. And since this can only happen with an fdi link in between and so for pch eDP panels it's rather unlikely to blow up, if ever. v2: Rebased on top of a bikeshed from Paulo. v3: Improve commit message around eDP handling with the stuff things with Imre. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: fixup 12bpc hdmi dotclock handlingDaniel Vetter2013-04-291-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to multiply the hdmi port dotclock by 1.5x since it's not really a dotclock, but the 10/8 encoding bitclock divided by 10. Also add correct limit checks for the dotclock and reject modes which don't fit. HDMI 1.4 would allow more, but our hw doesn't support that unfortunately :( Somehow I suspect 12bpc hdmi output never really worked - we really need an i-g-t testcase to check all the different pixel modes and outputs. v2: Fixup the adjusted port clock handling - we need to make sure that the fdi link code still gets the real pixelclock. v3: g4x/vlv don't support 12bpc hdmi output so drop the bogus comment. Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Switch dotclock limit check to <= as suggested by Ville.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: update VLV PLL and DPIO code v11Jesse Barnes2013-04-191-0/+108
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Valleyview voltage swing, pre-emphasis and lane control registers can be programmed only through the h/w side band fabric. Update vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the appropriate programming. We need to make sure that the tx lane reset occurs in both the full mode set and DPMS paths, so factor things out to allow that. v2: use different DPIO_DIVISOR values for VGA and DisplayPort v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values for all display interfaces v4: collapse with various updates v5: squash with crtc enable/pll enable bits v6: split out DP code (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) remove unneeded check in 9xx pll div update (Jani) wrap VLV pll update call in IS_VALLEYVIEW (Jani) move port enable back to end of crtc enable (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) v7: fix up conflicts against latest drm-intel-next-queued v8: use DPIO reg names, fix pipes (Jani) from mPhy_registers_VLV2_ww20p5 doc v9: update to latest info from driver enabling notes doc driver_vbios_notes_9 v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work simultaneously (Jesse) v11: use pll/port callbacks for DPIO port activity (Daniel) use separate VLV CRTC enable function (Daniel) move around port ready checks (Jesse) Signed-off-by: Pallavi G <pallavi.g@intel.com> Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Drop pfit changes and add a little comment explaining that vlv has a different enable sequence and so needs it's own crtc_enable callback. Also apply a fixup patch from Wu Fengguang to shut up some compiler warnings.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move cpu_transcoder to the pipe configurationDaniel Vetter2013-04-181-3/+3
| | | | | | | | | | | | | | | | | | | | For a bunch of reason we need to more accurately track this: - hw pipe state readout for Haswell needs the cpu transcoder. - We need to know the right cpu transcoder in a bunch of places in ->disable and other modeset callbacks. In the future we need to add hw state readout&check support, too. But to avoid ugly merge conflicts do the rote sed job now without any functional changes. v2: Preserve the cpu_transcoder value when overwriting crtc->config. Reported by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) [danvet: Removed rough whitespace that Chris spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: (re)init HPD interrupt storm statisticsEgbert Eich2013-04-181-1/+0
| | | | | | | | | | | | | | | | | | | | When an encoder is shared on several connectors there is only one hotplug line, thus this line needs to be shared among these connectors. If HPD detect only works reliably on a subset of those connectors, we want to poll the others. Thus we need to make sure that storm detection doesn't mess up the settings for those connectors. Therefore we store the settings in the intel_connector struct and restore them from there. If nothing is set but the encoder has a hpd_pin set we assume this connector is hotplug capable. On init/reset we make sure the polled state of the connectors is (re)set to the default value, the HPD interrupts are marked enabled. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't use the HDMI port color range bit on ValleyviewVille Syrjälä2013-04-051-1/+1
| | | | | | | | | | | | | VLV docs still list the the color range selection bit for the HDMI ports, but for DP ports it has been repurposed. I have no idea whether the HDMI color range selection bit still works on VLV, but since we now have to use the PIPECONF color range bit for DP, we might as well do the same for HDMI. 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: precompute pipe bpp before touching the hwDaniel Vetter2013-03-281-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The procedure has now 3 steps: 1. Compute the bpp that the plane will output, this is done in pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also, this function clamps the pipe_bpp to whatever limit the EDID of any connected output specifies. 2. Adjust the pipe_bpp in the encoder and crtc functions, according to whatever constraints there are. 3. Decide whether to use dither by comparing the stored plane bpp with computed pipe_bpp. There are a few slight functional changes in this patch: - LVDS connector are now also going through the EDID clamping. But in a 2nd change we now unconditionally force the lvds bpc value - this shouldn't matter in reality when the panel setup is consistent, but better safe than sorry. - HDMI now forces the pipe_bpp to the selected value - I think that's what we actually want, since otherwise at least the pixelclock computations are wrong (I'm not sure whether the port would accept e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick the next higher bpc value, since otherwise there's no way to make use of the 12 bpc mode (since the next patch will remove the 12bpc plane format, it doesn't exist). Both of these changes are due to the removal of the pipe_bpp = min(display_bpp, plane_bpp); statement. Another slight change is the reworking of the dp bpc code: - For the mode_valid callback it's sufficient to only check whether the mode would fit at the lowest bpc. - The bandwidth computation code is a bit restructured: It now walks all available bpp values in an outer loop and the codeblock that computes derived values (once a good configuration is found) has been moved out of the for loop maze. This is prep work to allow us to successively fall back on bpc values, and also correctly support bpc values != 8 or 6. v2: Rebased on top of Paulo Zanoni's little refactoring to use more drm dp helper functions. v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color range work. v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed. v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked in a later patch though again. v6: Fix spelling in a comment. v7: Debug output improvements for the bpp computation. v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different things! v9: Reinstate the fix to properly ignore the firmware edp bpp ... this was lost in a rebase. v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have that. Still unsure whether this is the way to go, but at least 6bpc for a 8bpc hdmi output seems to work. v11: And g4x/vlv also lack 12bpc hdmi support, so only support high depth on DP. Adjust the code. v12: Rebased. v13: Split out the introduction of pipe_config->dither|pipe_bpp, as requested from Jesse Barnes. v14: Split out the special 6BPC handling for DP, as requested by Jesse Barnes. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: introduce pipe_config->dither|pipe_bppDaniel Vetter2013-03-281-1/+1
| | | | | | | | | We want to compute this earlier. To avoid a big complicated patch, this patch here just does the big search&replace and still calls the old functions at the same places. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add pipe_config->limited_color_rangeDaniel Vetter2013-03-281-2/+3
| | | | | | | | | | Now that we have a useful struct for this, let's use it. Some neat pointer-chasing required, but it's all there already. v2: Rebased on top of the added Haswell limited color range support. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add pipe_config->has_pch_encoderDaniel Vetter2013-03-281-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used way too often in the enable/disable paths. And will be even more useful in the future. Note that correct semantics of this change highly depend upon correct updating of intel_crtc->config: Like with all other modeset state, we need to call ->disable with the old config, but ->mode_set and ->enable with the new config. v2: Do not yet use the flag in the ->disable callbacks - atm we don't yet have support for the information stored in the pipe_config in the hw state readout code, so this will be wrong at boot-up/resume. v3: Rebased on top of the hdmi/dp ddi encoder merging. v4: Fixup stupid rebase error which lead to a NULL vfunc deref. v5: On haswell the VGA port is on the PCH! v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing parameter name in a function declaration. v7: Don't forget to git add ... Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* DRM/i915: Get rid if the 'hotplug_supported_mask' in struct drm_i915_private.Egbert Eich2013-03-271-3/+0
| | | | | | | | | Now since we have replaced the bits to show interest in hotplug IRQs we can go and nuke the 'hotplug_supported_mask'. Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* DRM/I915: Add enum hpd_pin to intel_encoder.Egbert Eich2013-03-261-0/+4
| | | | | | | | | | | | | | To clean up hotplug support we add a new enum to intel_encoder: enum hpd_pin. It allows the encoder to request a hpd line but leave the details which IRQ is responsible on which chipset generation to i915_irq.c. This way requesting hotplug support will become really simple on the encoder/connector level. Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use VLV DIP routines on VLV v2Jesse Barnes2013-03-231-4/+4
| | | | | | | | | | | | | | | | | | This fixes up broken logic introduced in commit 90b107c8f7ea75ef55db4e0515dda86b245f8978 Author: Shobhit Kumar <shobhit.kumar@intel.com> Date: Wed Mar 28 13:39:32 2012 -0700 drm/i915: Enable HDMI on ValleyView That one was probably a rebase fail along the way. v2: clean up init ordering (Daniel) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Pimp commit message a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.9-rc3' into drm-intel-next-queuedDaniel Vetter2013-03-191-32/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge so that I can merge Imre Deak's coalesced sg entries fixes, which depend upon the new for_each_sg_page introduce in commit a321e91b6d73ed011ffceed384c40d2785cf723b Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 27 17:02:56 2013 -0800 lib/scatterlist: add simple page iterator The merge itself is just two trivial conflicts: Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge branch 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux ↵Dave Airlie2013-02-241-2/+2
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Thierry writes: "Remove a duplicate implementation of the CEA VIC lookup and move the CEA and other mode tables to drm_edid.c to make it more difficult to create duplicates of the tables. Add some helpers to pack CEA-861/HDMI AVI, audio and SPD infoframes into binary buffers that can easily be written into hardware registers. A new helper function makes it easy construct an AVI infoframe from a DRM display mode. Convert the Tegra and Radeon drivers to use the new HDMI helpers." * 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux: drm/radeon: Use generic HDMI infoframe helpers drm/tegra: Use generic HDMI infoframe helpers drm: Add EDID helper documentation drm: Add HDMI infoframe helpers video: Add generic HDMI infoframe helpers drm: Add some missing forward declarations drm: Move mode tables to drm_edid.c drm: Remove duplicate drm_mode_cea_vic()
| | * drm: Remove duplicate drm_mode_cea_vic()Thierry Reding2013-02-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The same function had already been merged with a different name. Remove the duplicate one but reuse some of its kerneldoc fragments for the existing implementation. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
| * | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-02-241-29/+0
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Two regressions fixes from snowboarding land * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Revert hdmi HDP pin checks drm/i915: Handle untiled planes when computing their offsets
| | * drm/i915: Revert hdmi HDP pin checksDaniel Vetter2013-02-221-29/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8ec22b214d76773c9d89f4040505ce10f677ed9a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 11 18:01:34 2012 +0100 drm/i915/hdmi: Query the live connector status bit for G4x and commit b0ea7d37a8f63eeec5ae80b4a6403cfba01da02f Author: Damien Lespiau <damien.lespiau@intel.com> Date: Thu Dec 13 16:09:00 2012 +0000 drm/i915/hdmi: Read the HPD status before trying to read the EDID They reliably cause HDMI to not be detected on some systems (like my ivb or the bug reporters gm45). To fix up the very slow unplug issues we might want to fire up a 2nd detect cycle a few hundred ms after each hotplug. But for now at least make displays work again. I somewhat suspect that this is confined to HDMI connectors, since all the machines I have with DP+ outputs work correctly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org.kernel.org # for 8ec22b21 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-02-201-5/+5
| |\ \ | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next So here's my promised pile of fixes for 3.9. I've dropped the core prep patches for vt-switchless suspend/resume as discussed on irc. Highlights: - Fix dmar on g4x. Not really gfx related, but I'm fed up with getting blamed for dmar crapouts. - Disable wc ptes updates on ilk when dmar is enabled (Chris). So again, dmar, but this time gfx related :( - Reduced range support for hsw, using the pipe CSC (Ville). - Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is already confirmed to fix 2 bug reports, so added cc: stable on that one. - Regression fix for 8bit fb console (Ville). - Preserve lane reversal bits on DDI/FDI ports (Damien). - Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of them, need to decide what to do with the currently still in-flight ones. - Panel fitter regression fix from Mika Kuoppala (was accidentally left on on some pipes with the new modset code since 3.7). This also improves the modeset sequence and might help a few other unrelated issues with lvds. - Write backlight regs even harder ... another installement in our eternal fight against the BIOS and backlights. - Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for new ACPI stuff, but closing the race itself seems worthwile on its own. - A few other small fixes and tiny cleanups all over. Lots of the patches are cc: stable since I've stalled on a few not-so-important fixes for 3.8 due to the grumpy noise Linus made. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits) intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK drm/i915: Implement pipe CSC based limited range RGB output drm/i915: inverted brightness quirk for Acer Aspire 4736Z drm/i915: Print the hw context status is debugfs drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+ drm/i915: Set i9xx sdvo clock limits according to specifications drm/i915: Set i9xx lvds clock limits according to specifications drm/i915: Preserve the DDI link reversal configuration drm/i915: Preserve the FDI line reversal override bit on CPT drm/i915: add missing \n to UTS_RELEASE in the error_state drm: Use C8 instead of RGB332 when determining the format from depth/bpp drm: Fill depth/bits_per_pixel for C8 format drm/i915: don't clflush gem objects in stolen memory drm/i915: Don't wait for page flips if there was GPU reset drm/i915: Kill obj->pending_flip drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment drm/i915: remove bogus mutex_unlock from error-path drm/i915: Print the pipe control page GTT address ...
| * | drm/i915: rip out helper->disable noop functionsDaniel Vetter2013-02-141-1/+0
| | | | | | | | | | | | | | | | | | | | | Now that the driver is in control of whether it needs to disable everything at take-over or not, we can rip this all out. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: rename some HDMI bit definitionsPaulo Zanoni2013-03-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bits used only on HDMI mode now have HDMI_ prefix instead of SDVO_. The COLOR_FORMAT bits now have prefixes (and the 12bpc bit is for HDMI only). Notice that this patch uncovers a bug on the SDVO code: the COLOR_RANGE_16_235 bit can only be used if the port is in TMDS mode, not SDVO mode. This will have to be fixed in a later patch. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: remove duplicated SDVO/HDMI bit definitionsPaulo Zanoni2013-03-041-14/+9
| | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipeRodrigo Vivi2013-03-031-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While old platforms had 3 transcoders and 3 pipes (1:1), HSW has 4 transcoders and 3 pipes. These regs were being used only by HDMI code where pipe is always the same thing as cpu_transcoder. This patch allow us to use them for DP, specially for TRANSCODER_EDP. v2: Adding HSW_TVIDEO_DIP_VSC_DATA to transmit vsc to eDP. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: rename sdvox_reg to hdmi_reg on HDMI contextPaulo Zanoni2013-02-201-36/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some (but not all) of the HDMI registers can be used to control sDVO, so those registers have two names. IMHO, when we're talking about HDMI, we really should call the HDMI control register "hdmi_reg" instead of "sdvox_reg", otherwise we'll just confuse people reading our code (we now have platforms with HDMI but without SDVO). So now "struct intel_hdmi" has a member called "hdmi_reg" instead of "sdvox_reg". Also, don't worry: "struct intel_sdvo" still has a member called "sdvo_reg". v2: Rebase (v1 was sent in May 2012). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: use HAS_DDI on intel_hdmi.c and intel_display.cPaulo Zanoni2013-02-201-1/+1
| |/ |/| | | | | | | | | | | | | Since basically every code called on these places comes from intel_ddi.c Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: unify HDMI/DP hpd definitionsDaniel Vetter2013-02-151-5/+5
|/ | | | | | | | | | They're physically the same pins and also the same bits, duplicating only confuses the reader. This also makes it a bit obvious that we have quite some code duplication going on here. Squashing that is for a larger rework in our hpd handling though. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Convert intel_hdmi to enum portVille Syrjälä2013-01-241-12/+15
| | | | | | | | Use intel_dig_port->port rather than intel_hdmi->sdvox_erg. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Provide the quantization range in the AVI infoframeVille Syrjälä2013-01-201-0/+11
| | | | | | | | | | | | | | | | | The AVI infoframe is able to inform the display whether the source is sending full or limited range RGB data. As per CEA-861 [1] we must first check whether the display reports the quantization range as selectable, and if so we can set the approriate bits in the AVI inforframe. [1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame v2: Give the Q bits better names, add spec chapter information Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud