[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write (rev3)
== Series Details == Series: drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write (rev3) URL : https://patchwork.freedesktop.org/series/4446/ State : warning == Summary == Series 4446v3 drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write http://patchwork.freedesktop.org/api/1.0/series/4446/revisions/3/mbox/ Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (hsw-brixbox) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-c: fail -> PASS (hsw-brixbox) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-nuci5) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (snb-dellxps) Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (byt-nuc) UNSTABLE bdw-nuci7total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:194 pass:173 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:194 pass:155 dwarn:2 dfail:0 fail:0 skip:37 byt-nuc total:194 pass:154 dwarn:5 dfail:0 fail:0 skip:35 hsw-brixbox total:194 pass:172 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:194 pass:177 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:194 pass:183 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:194 pass:158 dwarn:2 dfail:0 fail:0 skip:34 Results at /archive/results/CI_IGT_test/Patchwork_1606/ fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 2016y-03m-15d-13h-10m-41s UTC integration manifest ace9fe27af8fed36ba4401dfee7eae1785e213ea drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V11] drm/i915/skl: SKL CDCLK change on modeset tracking VCO
On Tue, Mar 15, 2016 at 02:34:05PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
> to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
> is enabled when the cdclk is less then required. DP connected to DDI2
> and HPD on either port works correctly.
So this patch hard-hangs machines?
>
> Set cdclk based on the max required pixel clock based on VCO
> selected. Track boot vco instead of boot cdclk.
>
> The vco is now tracked at the atomic level and all CRTCs updated if
> the required vco is changed. Not tested with eDP v1.4 panels that
> require 8640 vco due to availability.
>
> V1: initial version
> V2: add vco tracking in intel_dp_compute_config(), rename
> skl_boot_cdclk.
> V3: rebase, V2 feedback not possible as encoders are not aware of
> atomic.
> V4: track target vco is atomic state. modeset all CRTCs if vco changes
> V5: rename atomic variable, cleaner if/else logic, use existing vco if
> encoder does not return a new vco value. check_patch.pl cleanup
> V6: simplify logic in intel_modeset_checks.
> V7: reorder an IF for readability and whitespace fix.
> V8: use dev_cdclk for tracking new cdclk during atomic
> V9: correctly handle vco 8640 when crtcs==0
> V10: Clean up if else in crtcs==0
> V11: Rebase for new intel_dpll_mgr.c
>
> Reviewed-by: Ville Syrjälä
Is the r-b from Ville really for v11?
-Daniel
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/i915_drv.h |2 +-
> drivers/gpu/drm/i915/intel_display.c | 111
> -
> drivers/gpu/drm/i915/intel_dpll_mgr.c |9 +--
> drivers/gpu/drm/i915/intel_drv.h |5 ++
> 4 files changed, 106 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 80b14f1..bf87e62 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1759,7 +1759,7 @@ struct drm_i915_private {
> int num_fence_regs; /* 8 on pre-965, 16 otherwise */
>
> unsigned int fsb_freq, mem_freq, is_ddr3;
> - unsigned int skl_boot_cdclk;
> + unsigned int skl_vco_freq;
> unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> unsigned int max_dotclk_freq;
> unsigned int rawclk_freq;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ce55f0b..fc5268c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5584,7 +5584,7 @@ static unsigned int skl_cdclk_decimal(unsigned int freq)
> return (freq - 1000) / 500;
> }
>
> -static unsigned int skl_cdclk_get_vco(unsigned int freq)
> +unsigned int skl_cdclk_get_vco(unsigned int freq)
> {
> unsigned int i;
>
> @@ -5742,17 +5742,21 @@ void skl_uninit_cdclk(struct drm_i915_private
> *dev_priv)
>
> void skl_init_cdclk(struct drm_i915_private *dev_priv)
> {
> - unsigned int required_vco;
> + unsigned int cdclk;
>
> /* DPLL0 not enabled (happens on early BIOS versions) */
> if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
> /* enable DPLL0 */
> - required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
> - skl_dpll0_enable(dev_priv, required_vco);
> + if (dev_priv->skl_vco_freq != 8640)
> + dev_priv->skl_vco_freq = 8100;
> + skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
> + cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 : 308570);
> + } else {
> + cdclk = dev_priv->cdclk_freq;
> }
>
> - /* set CDCLK to the frequency the BIOS chose */
> - skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);
> + /* set CDCLK to the lowest frequency, Modeset follows */
> + skl_set_cdclk(dev_priv, cdclk);
>
> /* enable DBUF power */
> I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
> @@ -5768,7 +5772,7 @@ int skl_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
> {
> uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
> uint32_t cdctl = I915_READ(CDCLK_CTL);
> - int freq = dev_priv->skl_boot_cdclk;
> + int freq = dev_priv->cdclk_freq;
>
> /*
>* check if the pre-os intialized the display
> @@ -5792,11 +5796,7 @@ int skl_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
> /* All well; nothing to sanitize */
> return false;
> sanitize:
> - /*
> - * As of now initialize with max cdclk till
> - * we get dynamic cdclk support
> - * */
> - dev_priv->skl_boot_cdclk = dev_priv->max_cdclk_freq;
> +
> skl_init_cdclk(dev_priv);
>
> /* we did have to sanitize */
> @@ -9753,6 +9753,73 @@ static void broadwell_modeset_commit_cdclk(struct
> drm_atomic_state *old_state)
> broadwell_set_cdclk(dev, req_cdclk);
> }
>
> +static int skl_modeset_calc_cdclk
Re: [Intel-gfx] [PATCH] drm/i915: Add delay on DPCD reads
On Tue, 2016-03-15 at 14:26 +0100, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 01:38:58PM +0200, Mika Kahola wrote:
> > Additional 50 ms delay is needed between DPCD reads on HP Bizlink 1326
> > DP to VGA adapter. Having said that, I haven't noticed a need for
> > additional delay between DPCD reads on other DP-VGA dongles.
> >
> > While at it, let's replace mdelay() with usleep_range() routine.
> >
> > Signed-off-by: Mika Kahola
>
> Please don't add more hacks to our own private copy of read_wake. This
> stuff needs to move into drm core, since really we can't be the only ones
> who try to plug in shit dongles ;-)
>
> Would be great to test this with an amd DP card and the exact same
> connector and see what happens. Then move these read_wake hacks into the
> drm_dp_dpcd_read function. Lyude is also working on something like this,
> but for DP MST hubs.
This particular DP-VGA dongle has been problematic. I have used Windows
to benchmark the performance. It takes eternity to light up the display
on Windows but the eventually the driver is able to do that.
You're right, perhaps the best place for this sort of hacks is the drm
core.
Cheers,
Mika
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 0e326e7..ff3883c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3125,9 +3125,11 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux,
> > unsigned int offset,
> >
> > for (i = 0; i < 3; i++) {
> > ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> > - if (ret == size)
> > + if (ret == size) {
> > + usleep_range(5, 50100);
> > return ret;
> > - msleep(1);
> > + }
> > + usleep_range(1000, 1100);
> > }
> >
> > return ret;
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
== Series Details == Series: drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3) URL : https://patchwork.freedesktop.org/series// State : failure == Summary == Series v3 drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs http://patchwork.freedesktop.org/api/1.0/series//revisions/3/mbox/ Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-s3: pass -> DMESG-WARN (skl-nuci5) Test gem_storedw_loop: Subgroup basic-bsd: pass -> DMESG-WARN (skl-nuci5) Subgroup basic-bsd1: pass -> DMESG-WARN (skl-nuci5) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (hsw-brixbox) pass -> DMESG-WARN (bdw-ultra) Subgroup basic-plain-flip: pass -> DMESG-WARN (hsw-gt2) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-c: fail -> PASS (hsw-brixbox) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-nuci5) Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (skl-nuci5) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (snb-dellxps) Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:194 pass:172 dwarn:1 dfail:0 fail:0 skip:21 bsw-nuc-2total:194 pass:156 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:194 pass:155 dwarn:4 dfail:0 fail:0 skip:35 hsw-brixbox total:194 pass:172 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:194 pass:176 dwarn:1 dfail:0 fail:0 skip:17 ivb-t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:152 pass:138 dwarn:3 dfail:0 fail:0 skip:10 snb-dellxps total:194 pass:158 dwarn:2 dfail:0 fail:0 skip:34 Results at /archive/results/CI_IGT_test/Patchwork_1607/ fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 2016y-03m-15d-13h-10m-41s UTC integration manifest 7cb417d02e1ff8af6261f9a159470dc61ae0faa7 drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: add dsi transcoders
== Series Details == Series: drm/i915/bxt: add dsi transcoders URL : https://patchwork.freedesktop.org/series/4483/ State : failure == Summary == Series 4483v1 drm/i915/bxt: add dsi transcoders http://patchwork.freedesktop.org/api/1.0/series/4483/revisions/1/mbox/ Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (skl-i5k-2) Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (hsw-brixbox) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-c: fail -> PASS (hsw-brixbox) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-nuci5) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (snb-dellxps) Subgroup basic-rte: dmesg-warn -> PASS (snb-dellxps) bdw-nuci7total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:194 pass:173 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:194 pass:156 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:194 pass:155 dwarn:4 dfail:0 fail:0 skip:35 hsw-brixbox total:194 pass:172 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:194 pass:177 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:194 pass:170 dwarn:1 dfail:0 fail:0 skip:23 skl-i7k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:194 pass:183 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:194 pass:159 dwarn:1 dfail:0 fail:0 skip:34 Results at /archive/results/CI_IGT_test/Patchwork_1608/ fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 2016y-03m-15d-13h-10m-41s UTC integration manifest f8674383de51fd39abf64633a2e37e278108f687 drm/i915/bxt: allow dsi on any pipe bd00d25cfe9977c2826db780539e7a01e680a252 drm/i915/dsi: use the BIT macro for clarity 45676697ab1cdb4c674ed5deb0202984ed8a6c86 drm/i915/bxt: add dsi transcoders bb910bf0aa8396510f7b47e178824161aa50f576 drm/i915: abstract get config for cpu transcoder 329cad09ea7efc6c284ce178ddca72c0c5133209 drm/i915: split set pipeconf to pipe and transcoder parts 88ba0136f2b4789e82fdb8efbf2c1d6d1c083cfb drm/i915: split get/set pipe timings to pipe and transcoder parts 16ca06fb41bfa6f7bb44f64ba133314fdf2e81bd drm/i915/bxt: fix dsi hw state pipe readout 5bebc9533048bbed094ff3861471447b1635896f drm/i915/dsi: refactor dsi get hw state readout 0d8cd289aa10e9b83200941306af5ab868ed4188 drm/i915: make transcoder_name return a string cebc90ba5af275ac8189b62919edbdc075b4dcb7 drm/i915: add for_each_port_masked macro ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix eDP low vswing for Broadwell
It was noticed on bug #94087 that module parameter
i915.edp_vswing=2 that should override the VBT setting
to use default voltage swing (400 mV) was not applied
for Broadwell.
This patch provides a fix for this by checking if default
i.e. higher voltage swing is requested to be used and
applies the DDI translations table for DP instead of eDP
(low vswing) table.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_ddi.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ab025a5..e30adcd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -443,9 +443,19 @@ void intel_prepare_ddi_buffer(struct intel_encoder
*encoder)
} else if (IS_BROADWELL(dev_priv)) {
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
- ddi_translations_edp = bdw_ddi_translations_edp;
+
+ if (dev_priv->edp_low_vswing)
+ ddi_translations_edp = bdw_ddi_translations_edp;
+ else
+ ddi_translations_edp = bdw_ddi_translations_dp;
+
ddi_translations_hdmi = bdw_ddi_translations_hdmi;
- n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
+
+ if (dev_priv->edp_low_vswing)
+ n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
+ else
+ n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
+
n_dp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
hdmi_default_entry = 7;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/16] drm/i915: Change lfsr_converts[] to u16
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> [ text/plain ]
> From: Ville Syrjälä
>
> All the values in the DSI PLL LFSR seed table fit into 9bits, so change
> the type to u16 from u32 to save a bit of space.
>
> drivers/gpu/drm/i915/i915.ko:
> -.rodata90824
> +.rodata90760
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index 2451c84949bd..916cc92c1400 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -56,7 +56,7 @@ struct dsi_mnp {
> u32 dsi_pll_div;
> };
>
> -static const u32 lfsr_converts[] = {
> +static const u16 lfsr_converts[] = {
> 426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
> 461, 486, 243, 377, 188, 350, 175, 343, 427, 213, /* 71 - 80 */
> 106, 53, 282, 397, 454, 227, 113, 56, 284, 142, /* 81 - 90 */
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/16] drm/i915: Power down the DSI PLL before reconfiguring it
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> [ text/plain ]
> From: Ville Syrjälä
>
> On VLV at least, the BIOS may leave the DSI PLL enabled in some wonky
> state where it just refuses to lock. Simply disabling the PLL before
> reconfiguring it is not enough to fix it, but power gating the PLL
> prior to reconfiguring does work.
>
> This happens on BYT FFRD8 when booting with HDMI connected so the DSI
> display will not be lit up by the BIOS.
>
> Also we can remove the code for BXT that disables the PLL before
> enabling it again.
>
> v2: s/vlv/intel/ since BXT made thing generic
> v3: Remove the BXT disable PLL before enable trick
>
> Signed-off-by: Ville Syrjälä
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 6 ++
> drivers/gpu/drm/i915/intel_dsi_pll.c | 8
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 4023b6bffa47..787411e1c36f 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -482,7 +482,13 @@ static void intel_dsi_pre_enable(struct intel_encoder
> *encoder)
>
> DRM_DEBUG_KMS("\n");
>
> + /*
> + * The BIOS may leave the PLL in a wonky state where it doesn't
> + * lock. It needs to be fully powered down to fix it.
> + */
> + intel_disable_dsi_pll(encoder);
> intel_enable_dsi_pll(encoder);
> +
> intel_dsi_prepare(encoder);
>
> /* Panel Enable over CRC PMIC */
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index 916cc92c1400..978cc2668a3d 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -474,14 +474,6 @@ static void bxt_enable_dsi_pll(struct intel_encoder
> *encoder)
>
> DRM_DEBUG_KMS("\n");
>
> - val = I915_READ(BXT_DSI_PLL_ENABLE);
> -
> - if (val & BXT_DSI_PLL_DO_ENABLE) {
> - WARN(1, "DSI PLL already enabled. Disabling it.\n");
> - val &= ~BXT_DSI_PLL_DO_ENABLE;
> - I915_WRITE(BXT_DSI_PLL_ENABLE, val);
> - }
> -
> /* Configure PLL vales */
> if (!bxt_configure_dsi_pll(encoder)) {
> DRM_ERROR("Configure DSI PLL failed, abort PLL enable\n");
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
Tomi, noticed two things that maybe infrastructure related, see below: On Wed, 2016-03-16 at 07:31 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3) > URL : https://patchwork.freedesktop.org/series// > State : failure > > == Summary == > > Series v3 drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs > http://patchwork.freedesktop.org/api/1.0/series//revisions/3/mbox > / > > Test drv_module_reload_basic: > skip -> PASS (bdw-nuci7) > Test gem_ringfill: > Subgroup basic-default-s3: > pass -> DMESG-WARN (skl-nuci5) > Test gem_storedw_loop: > Subgroup basic-bsd: > pass -> DMESG-WARN (skl-nuci5) > Subgroup basic-bsd1: > pass -> DMESG-WARN (skl-nuci5) Unrelated platform. All of the above are SND resume failures. Ville said he contacted Takashi about them. > Test kms_flip: > Subgroup basic-flip-vs-wf_vblank: > dmesg-warn -> PASS (hsw-brixbox) > pass -> DMESG-WARN (bdw-ultra) Unrelated platform. Tomi, there are ACPI erros in the log, maybe needs a BIOS upgrade? It's also affected by https://bugs.freedesktop.org/show_bug.cgi?id=94349 > Subgroup basic-plain-flip: > pass -> DMESG-WARN (hsw-gt2) Unrelated platform: https://patchwork.freedesktop.org/patch/75903/ > Test kms_pipe_crc_basic: > Subgroup read-crc-pipe-c: > fail -> PASS (hsw-brixbox) > Subgroup suspend-read-crc-pipe-b: > dmesg-warn -> PASS (skl-nuci5) > Subgroup suspend-read-crc-pipe-c: > pass -> INCOMPLETE (skl-nuci5) Unrelated platform, I opened a new bug: https://bugs.freedesktop.org/show_bug.cgi?id=94566 > Test pm_rpm: > Subgroup basic-pci-d3-state: > pass -> DMESG-WARN (snb-dellxps) Unrelated platform: https://patchwork.freedesktop.org/patch/75903/ > Subgroup basic-rte: > pass -> DMESG-WARN (bsw-nuc-2) Unrelated platform: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Tomi, basic-rte has also DMESG-WARN on snb-dellxps, yet not on this list. --Imre > > bdw- > nuci7total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:1 > 2 > bdw- > ultratotal:194 pass:172 dwarn:1 dfail:0 fail:0 skip:2 > 1 > bsw-nuc- > 2total:194 pass:156 dwarn:1 dfail:0 fail:0 skip:37 > byt- > nuc total:194 pass:155 dwarn:4 dfail:0 fail:0 skip:3 > 5 > hsw- > brixbox total:194 pass:172 dwarn:0 dfail:0 fail:0 skip:2 > 2 > hsw- > gt2 total:194 pass:176 dwarn:1 dfail:0 fail:0 skip:1 > 7 > ivb- > t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:2 > 5 > skl-i5k- > 2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 > skl-i7k- > 2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 > skl- > nuci5total:152 pass:138 dwarn:3 dfail:0 fail:0 skip:1 > 0 > snb- > dellxps total:194 pass:158 dwarn:2 dfail:0 fail:0 skip:3 > 4 > > Results at /archive/results/CI_IGT_test/Patchwork_1607/ > > fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 2016y- > 03m-15d-13h-10m-41s UTC integration manifest > 7cb417d02e1ff8af6261f9a159470dc61ae0faa7 drm/i915/bxt: Fix off-by-one > error in Broxton PLL IDs > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/16] drm/i915: Compute DSI PLL parameters during .compute_config()
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Compute the DSI PLL parameters during .compute_config() rather than
> .pre_pll_enable() so that we can fail gracefully if we can't find
> suitable parameters.
>
> In order to do that we need to store the DSI PLL parameters in
> pipe_config.
>
> v2: Handle BXT too
>
> Signed-off-by: Ville Syrjälä
[snip]
> @@ -317,15 +328,9 @@ static u32 bxt_dsi_get_pclk(struct intel_encoder
> *encoder, int pipe_bpp)
> return 0;
> }
>
> - dsi_ratio = I915_READ(BXT_DSI_PLL_CTL) &
> - BXT_DSI_PLL_RATIO_MASK;
> + config->dsi_pll.ctrl = I915_READ(BXT_DSI_PLL_CTL);
>
> - /* Invalid DSI ratio ? */
> - if (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
> - dsi_ratio > BXT_DSI_PLL_RATIO_MAX) {
> - DRM_ERROR("Invalid DSI pll ratio(%u) programmed\n", dsi_ratio);
> - return 0;
> - }
So you expect this to show up in the state checker instead now?
Reviewed-by: Jani Nikula
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/16] drm/i915: Fix CHV DSI PLL refclk during state readout
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use the proper refclock frequency (100MHz) when reading out the
> current DSI clock on CHV.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index d35c8dc28fb6..99236baa946b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -255,7 +255,7 @@ static u32 vlv_dsi_get_pclk(struct intel_encoder
> *encoder, int pipe_bpp,
> u32 dsi_clock, pclk;
> u32 pll_ctl, pll_div;
> u32 m = 0, p = 0, n;
> - int refclk = 25000;
> + int refclk = IS_CHERRYVIEW(dev_priv) ? 10 : 25000;
> int i;
>
> DRM_DEBUG_KMS("\n");
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/16] drm/i915: Dump pfit PGM_RATIOS as hex
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> pgm_ratios in stored as a register value in pipe config, so let's dump
> this one as hex as well.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d0b7fc85bc3a..ecda7e28ab9a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12722,7 +12722,7 @@ intel_pipe_config_compare(struct drm_device *dev,
> PIPE_CONF_CHECK_X(gmch_pfit.control);
> /* pfit ratios are autocomputed by the hw on gen4+ */
> if (INTEL_INFO(dev)->gen < 4)
> - PIPE_CONF_CHECK_I(gmch_pfit.pgm_ratios);
> + PIPE_CONF_CHECK_X(gmch_pfit.pgm_ratios);
> PIPE_CONF_CHECK_X(gmch_pfit.lvds_border_bits);
>
> if (!adjust) {
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/16] drm/i915: Eliminate {vlv, bxt}_configure_dsi_pll()
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> [ text/plain ]
> From: Ville Syrjälä
>
> Fold the DSI PLL configuration functions into the DSI PLL
> enable functions since they are small and not called from anywhere else.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c | 28 ++--
> 1 file changed, 6 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index 99236baa946b..3d3132c12edb 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -162,17 +162,6 @@ static int vlv_compute_dsi_pll(struct intel_encoder
> *encoder,
> return 0;
> }
>
> -static void vlv_configure_dsi_pll(struct intel_encoder *encoder,
> - const struct intel_crtc_state *config)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> -
> - vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, 0);
> - vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_DIVIDER, config->dsi_pll.div);
> - vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL,
> - config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
> -}
> -
> static void vlv_enable_dsi_pll(struct intel_encoder *encoder,
> const struct intel_crtc_state *config)
> {
> @@ -182,7 +171,10 @@ static void vlv_enable_dsi_pll(struct intel_encoder
> *encoder,
>
> mutex_lock(&dev_priv->sb_lock);
>
> - vlv_configure_dsi_pll(encoder, config);
> + vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, 0);
> + vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_DIVIDER, config->dsi_pll.div);
> + vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL,
> + config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
>
> /* wait at least 0.5 us after ungating before enabling VCO */
> usleep_range(1, 10);
> @@ -461,15 +453,6 @@ static int bxt_compute_dsi_pll(struct intel_encoder
> *encoder,
> return 0;
> }
>
> -static void bxt_configure_dsi_pll(struct intel_encoder *encoder,
> - const struct intel_crtc_state *config)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> -
> - I915_WRITE(BXT_DSI_PLL_CTL, config->dsi_pll.ctrl);
> - POSTING_READ(BXT_DSI_PLL_CTL);
> -}
> -
> static void bxt_enable_dsi_pll(struct intel_encoder *encoder,
> const struct intel_crtc_state *config)
> {
> @@ -481,7 +464,8 @@ static void bxt_enable_dsi_pll(struct intel_encoder
> *encoder,
> DRM_DEBUG_KMS("\n");
>
> /* Configure PLL vales */
> - bxt_configure_dsi_pll(encoder, config);
> + I915_WRITE(BXT_DSI_PLL_CTL, config->dsi_pll.ctrl);
> + POSTING_READ(BXT_DSI_PLL_CTL);
>
> /* Program TX, RX, Dphy clocks */
> for_each_dsi_port(port, intel_dsi->ports)
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
On Tue, 2016-03-15 at 16:37 -0700, Dongwon Kim wrote: > For BXT, Polarity of PORT_PLL_REF_SEL is reversed in > its description in Bspec. This bit should be set for > "Non-SSC". Thanks for the patch. In the future please also mention where the change originates from, in this case it is a recent update to the specification (which in turn is based on an internal report of an HDMI HW problem). Looking at that internal report (HSD) it says it only affects BXT-P but not BXT-T, so do we know that the meaning of the bit is inverted on both? Adding Art for more info. --Imre > Signed-off-by: Dongwon Kim > --- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/intel_dpll_mgr.c > index 4b636c4..d55b308 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c > @@ -1285,7 +1285,7 @@ static void bxt_ddi_pll_enable(struct > drm_i915_private *dev_priv, > enum port port = (enum port)pll->id;/* 1:1 port->PLL > mapping */ > > temp = I915_READ(BXT_PORT_PLL_ENABLE(port)); > - temp &= ~PORT_PLL_REF_SEL; > + temp |= PORT_PLL_REF_SEL; > /* Non-SSC reference */ > I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp); > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/16] drm/i915: Throw out BUGs from DPLL/PCH functions
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> These BUGs don't serve any purpose IMO. Throw them out.
>
> Signed-off-by: Ville Syrjälä
For some other things I might insist on replacing them with warns, but I
don't think these ones warrant that.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ce55f0b683c6..22930f05457c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1661,9 +1661,6 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
>
> assert_pipe_disabled(dev_priv, crtc->pipe);
>
> - /* No really, not for ILK+ */
> - BUG_ON(INTEL_INFO(dev)->gen >= 5);
> -
> /* PLL is protected by panel, make sure we can write it */
> if (IS_MOBILE(dev) && !IS_I830(dev))
> assert_panel_unlocked(dev_priv, crtc->pipe);
> @@ -1839,9 +1836,6 @@ static void ironlake_enable_pch_transcoder(struct
> drm_i915_private *dev_priv,
> i915_reg_t reg;
> uint32_t val, pipeconf_val;
>
> - /* PCH only available on ILK+ */
> - BUG_ON(!HAS_PCH_SPLIT(dev));
> -
> /* Make sure PCH DPLL is enabled */
> assert_shared_dpll_enabled(dev_priv, intel_crtc->config->shared_dpll);
>
> @@ -1895,9 +1889,6 @@ static void lpt_enable_pch_transcoder(struct
> drm_i915_private *dev_priv,
> {
> u32 val, pipeconf_val;
>
> - /* PCH only available on ILK+ */
> - BUG_ON(!HAS_PCH_SPLIT(dev_priv->dev));
> -
> /* FDI must be feeding us bits for PCH ports */
> assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
> assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/16] drm/i915: Add a local pipe variable to vlv_enable_pll()
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local
> pipe variable. Also makes it look more like the corresponding CHV code.
>
> While at is change the CHV code to enum pipe from int,
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 18158b0324ed..638ce9de 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1572,24 +1572,25 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - i915_reg_t reg = DPLL(crtc->pipe);
> + enum pipe pipe = crtc->pipe;
> + i915_reg_t reg = DPLL(pipe);
> u32 dpll = pipe_config->dpll_hw_state.dpll;
>
> - assert_pipe_disabled(dev_priv, crtc->pipe);
> + assert_pipe_disabled(dev_priv, pipe);
>
> /* PLL is protected by panel, make sure we can write it */
> if (IS_MOBILE(dev_priv->dev))
> - assert_panel_unlocked(dev_priv, crtc->pipe);
> + assert_panel_unlocked(dev_priv, pipe);
>
> I915_WRITE(reg, dpll);
> POSTING_READ(reg);
> udelay(150);
>
> if (wait_for(((I915_READ(reg) & DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
> - DRM_ERROR("DPLL %d failed to lock\n", crtc->pipe);
> + DRM_ERROR("DPLL %d failed to lock\n", pipe);
>
> - I915_WRITE(DPLL_MD(crtc->pipe), pipe_config->dpll_hw_state.dpll_md);
> - POSTING_READ(DPLL_MD(crtc->pipe));
> + I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
> + POSTING_READ(DPLL_MD(pipe));
>
> /* We do this three times for luck */
> I915_WRITE(reg, dpll);
> @@ -1608,11 +1609,11 @@ static void chv_enable_pll(struct intel_crtc *crtc,
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - int pipe = crtc->pipe;
> + enum pipe pipe = crtc->pipe;
> enum dpio_channel port = vlv_pipe_to_channel(pipe);
> u32 tmp;
>
> - assert_pipe_disabled(dev_priv, crtc->pipe);
> + assert_pipe_disabled(dev_priv, pipe);
>
> mutex_lock(&dev_priv->sb_lock);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/16] drm/i915: assert_panel_unlocked() in chv_enable_pll()
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Supposedly the power sequencer still locks out the DPLL registers on > CHV, so let's issue a warning if it's still locked when enabling the > DPLL. > > Also drop the redundant IS_MOBILE() check for VLV when we check the same > thing. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_display.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 638ce9de..d3332a33f8a7 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1579,8 +1579,7 @@ static void vlv_enable_pll(struct intel_crtc *crtc, > assert_pipe_disabled(dev_priv, pipe); > > /* PLL is protected by panel, make sure we can write it */ > - if (IS_MOBILE(dev_priv->dev)) > - assert_panel_unlocked(dev_priv, pipe); > + assert_panel_unlocked(dev_priv, pipe); > > I915_WRITE(reg, dpll); > POSTING_READ(reg); > @@ -1615,6 +1614,9 @@ static void chv_enable_pll(struct intel_crtc *crtc, > > assert_pipe_disabled(dev_priv, pipe); > > + /* PLL is protected by panel, make sure we can write it */ > + assert_panel_unlocked(dev_priv, pipe); > + > mutex_lock(&dev_priv->sb_lock); > > /* Enable back the 10bit clock to display controller */ -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/16] drm/i915: Remove the "three times for luck" trick from vlv_enable_pll()
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > VLV DPLL is somewhat sane and doesn't run on luck. > > Signed-off-by: Ville Syrjälä Acked-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_display.c | 11 --- > 1 file changed, 11 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index d3332a33f8a7..c85b77c1188d 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1590,17 +1590,6 @@ static void vlv_enable_pll(struct intel_crtc *crtc, > > I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md); > POSTING_READ(DPLL_MD(pipe)); > - > - /* We do this three times for luck */ > - I915_WRITE(reg, dpll); > - POSTING_READ(reg); > - udelay(150); /* wait for warmup */ > - I915_WRITE(reg, dpll); > - POSTING_READ(reg); > - udelay(150); /* wait for warmup */ > - I915_WRITE(reg, dpll); > - POSTING_READ(reg); > - udelay(150); /* wait for warmup */ > } > > static void chv_enable_pll(struct intel_crtc *crtc, -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/16] drm/i915: Don't read out port_clock on CHV when DPLL is disabled
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Check whether the DPLL is even enabled before readoing out the dividers > and trying to derive port_clock on CHV. We already did this on VLV. > > Also remove the comment "MIPI" comment from the VLV code since we call > this function whenever the pipe is enabled. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_display.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 98aae3914e9e..3e6b5fb140ad 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -7969,8 +7969,8 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc, > u32 mdiv; > int refclk = 10; > > - /* In case of MIPI DPLL will not even be used */ > - if (!(pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)) > + /* In case of DSI, DPLL will not be used */ > + if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0) > return; > > mutex_lock(&dev_priv->sb_lock); > @@ -8066,6 +8066,10 @@ static void chv_crtc_clock_get(struct intel_crtc *crtc, > u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3; > int refclk = 10; > > + /* In case of DSI, DPLL will not be used */ > + if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0) > + return; > + > mutex_lock(&dev_priv->sb_lock); > cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port)); > pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port)); -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support
On ti, 2016-03-15 at 14:14 +, Chris Wilson wrote: > On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote: > > > > I'm not sure if you want to check all failure paths, I think for that > > the existing failslab etc. mechanisms are better suited. This new > > option would be used at relatively few well defined places. The option > > is a mask since Chris wanted the possibility to mix failures (which > > makes sense when injecting a non-fatal failure somewhere). If he > > doesn't insist on that possibility I can convert the mask option to a > > counter based one identifying a single failure spot instead as you > > suggest. Chris? > We can extend the counter mechanism by having multiple counters behind > i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1) Now that there's a series to split down the init functions nicely, one could use the function names directly. By stripping parts of it if needed to shorten them. Regards, Joonas > so extensibility for more testing seems fine. > -Chris > -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support
On Wed, Mar 16, 2016 at 11:18:04AM +0200, Joonas Lahtinen wrote: > On ti, 2016-03-15 at 14:14 +, Chris Wilson wrote: > > On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote: > > > > > > I'm not sure if you want to check all failure paths, I think for that > > > the existing failslab etc. mechanisms are better suited. This new > > > option would be used at relatively few well defined places. The option > > > is a mask since Chris wanted the possibility to mix failures (which > > > makes sense when injecting a non-fatal failure somewhere). If he > > > doesn't insist on that possibility I can convert the mask option to a > > > counter based one identifying a single failure spot instead as you > > > suggest. Chris? > > We can extend the counter mechanism by having multiple counters behind > > i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1) > > Now that there's a series to split down the init functions nicely, one > could use the function names directly. By stripping parts of it if > needed to shorten them. That's nice. Advantage for using counters is that we can write a test to iterate over the first thousand and have it run against future faultpointers. Advantage for using names is that it is readable and easily extensible. What we could do for testing is record the available fault injection points for debugfs and so have the tests automatically adjust (given a working start point). Overkill? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/16] drm/i915: Implement WaPixelRepeatModeFixForC0:chv
On Tue, 15 Mar 2016, ville.syrj...@linux.intel.com wrote:
> [ text/plain ]
> From: Ville Syrjälä
>
> DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
> chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
> to either pipe B or C. So do that to make pixel repeat work on pipes
> B and C. Pipe A is fine without any tricks.
>
> Fortunately the pixel repeat propagation appears to be a oneshot
> operation, so once the value has been written we can clear the
> chicken bits. So it is still possible to drive pipe B and C with
> different pixel multipliers simultaneosly.
>
> Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B)
> for this to work. But since we keep that bit always set in all
> DPLLs there's no problem.
>
> This of course means we can't reliably read out the pixel multiplier
> for pipes B and C. That would make the state checker unhappy, so I
> added shadow copies of those registers in to dev_priv. The other
> option would have been to skip pixel multiplier, dpll_md an dotclock
> checks entirely on CHV, but that feels like a serious loss of cross
> checking, so just pretending that we have working DPLL MD registers
> seemed better. Obviously with the shadow copies we can't detect if
> the pixel multiplier was properly configured, nor can we take over
> its state from the BIOS, but hopefully people won't have displays
> that would be limitd to such crappy modes.
>
> There is one strange flicker still remaining. It's visible on
> pipe C/HDMID when HDMIB is enabled while driven by pipe B.
> It doesn't occur if pipe A drives HDMIB, nor is there any glitch
> on pipe B/HDMIB when port C/HDMID starts up. I don't have a board
> with HDMIC so not sure if it happens there too. So I'm not sure
> if it's somehow tied in with this strange linkage between pipe B
> and C. Sadly I was unable to find an enable sequence that would
> avoid the glitch, but at least it's not fatal ie. the output
> recovers afterwards.
>
> Signed-off-by: Ville Syrjälä
I didn't dig up the specs, but the code seems to do what the commit
message says.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 7 +++
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_display.c | 30 ++
> 3 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 80b14f1ba302..31689e1b19e6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1871,7 +1871,14 @@ struct drm_i915_private {
>
> u32 fdi_rx_config;
>
> + /* Shadow for DISPLAY_PHY_CONTROL which can't be safely read */
> u32 chv_phy_control;
> + /*
> + * Shadows for CHV DPLL_MD regs to keep the state
> + * checker somewhat working in the presence hardware
> + * crappiness (can't read out DPLL_MD for pipes B & C).
> + */
> + u32 chv_dpll_md[I915_MAX_PIPES];
>
> u32 suspend_count;
> bool suspended_to_idle;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7dfc4007f3fa..f138588a88cd 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4778,6 +4778,10 @@ enum skl_disp_power_wells {
> #define CBR_PND_DEADLINE_DISABLE(1<<31)
> #define CBR_PWM_CLOCK_MUX_SELECT(1<<30)
>
> +#define CBR4_VLV _MMIO(VLV_DISPLAY_BASE + 0x70450)
> +#define CBR_DPLLBMD_PIPE_C (1<<29)
> +#define CBR_DPLLBMD_PIPE_B (1<<18)
> +
> /* FIFO watermark sizes etc */
> #define G4X_FIFO_LINE_SIZE 64
> #define I915_FIFO_LINE_SIZE 64
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 414ed5007e60..18158b0324ed 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1635,9 +1635,27 @@ static void chv_enable_pll(struct intel_crtc *crtc,
> if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) ==
> DPLL_LOCK_VLV), 1))
> DRM_ERROR("PLL %d failed to lock\n", pipe);
>
> - /* not sure when this should be written */
> - I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
> - POSTING_READ(DPLL_MD(pipe));
> + if (pipe != PIPE_A) {
> + /*
> + * WaPixelRepeatModeFixForC0:chv
> + *
> + * DPLLCMD is AWOL. Use chicken bits to propagate
> + * the value from DPLLBMD to either pipe B or C.
> + */
> + I915_WRITE(CBR4_VLV, pipe == PIPE_B ? CBR_DPLLBMD_PIPE_B :
> CBR_DPLLBMD_PIPE_C);
> + I915_WRITE(DPLL_MD(PIPE_B), pipe_config->dpll_hw_state.dpll_md);
> + I915_WRITE(CBR4_VLV, 0);
> + dev_priv->chv_dpll_md[pipe] =
> pipe_config->dpll_hw_state.dpll_md;
> +
> + /*
> + * DPLLB VGA mode also seems to cause problems.
> + * We shou
Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support
On Wed, 2016-03-16 at 09:24 +, Chris Wilson wrote: > On Wed, Mar 16, 2016 at 11:18:04AM +0200, Joonas Lahtinen wrote: > > On ti, 2016-03-15 at 14:14 +, Chris Wilson wrote: > > > On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote: > > > > > > > > I'm not sure if you want to check all failure paths, I think > > > > for that > > > > the existing failslab etc. mechanisms are better suited. This > > > > new > > > > option would be used at relatively few well defined places. The > > > > option > > > > is a mask since Chris wanted the possibility to mix failures > > > > (which > > > > makes sense when injecting a non-fatal failure somewhere). If > > > > he > > > > doesn't insist on that possibility I can convert the mask > > > > option to a > > > > counter based one identifying a single failure spot instead as > > > > you > > > > suggest. Chris? > > > We can extend the counter mechanism by having multiple counters > > > behind > > > i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1) > > > > Now that there's a series to split down the init functions nicely, > > one > > could use the function names directly. By stripping parts of it if > > needed to shorten them. > > That's nice. Advantage for using counters is that we can write a test > to > iterate over the first thousand and have it run against future > faultpointers. Advantage for using names is that it is readable and > easily extensible. > > What we could do for testing is record the available fault injection > points for debugfs and so have the tests automatically adjust (given > a > working start point). Overkill? I'd prefer if we could fine grain things once we have more failure points. Atm the ones we defined cause driver init to fail, so separate counters wouldn't bring us much. I suggest that we keep the module option as a simple integer for now and extend it later to support the above tagged counter mechanism and debugfs interface. Here is what I planned to submit to the list: https://github.com/ideak/linux/commits/driver_init_refactor Comments? --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix eDP low vswing for Broadwell
On Wed, 16 Mar 2016, Mika Kahola wrote:
> [ text/plain ]
> It was noticed on bug #94087 that module parameter
> i915.edp_vswing=2 that should override the VBT setting
> to use default voltage swing (400 mV) was not applied
> for Broadwell.
>
> This patch provides a fix for this by checking if default
> i.e. higher voltage swing is requested to be used and
> applies the DDI translations table for DP instead of eDP
> (low vswing) table.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087
> Signed-off-by: Mika Kahola
cc: stable?
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ab025a5..e30adcd 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -443,9 +443,19 @@ void intel_prepare_ddi_buffer(struct intel_encoder
> *encoder)
> } else if (IS_BROADWELL(dev_priv)) {
> ddi_translations_fdi = bdw_ddi_translations_fdi;
> ddi_translations_dp = bdw_ddi_translations_dp;
> - ddi_translations_edp = bdw_ddi_translations_edp;
> +
> + if (dev_priv->edp_low_vswing)
> + ddi_translations_edp = bdw_ddi_translations_edp;
> + else
> + ddi_translations_edp = bdw_ddi_translations_dp;
> +
> ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> - n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> +
> + if (dev_priv->edp_low_vswing)
> + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> + else
> + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> +
Please just put these in one if statement above, instead of having two.
BR,
Jani.
> n_dp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
> hdmi_default_entry = 7;
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support
On Wed, Mar 16, 2016 at 11:43:14AM +0200, Imre Deak wrote: > On Wed, 2016-03-16 at 09:24 +, Chris Wilson wrote: > > On Wed, Mar 16, 2016 at 11:18:04AM +0200, Joonas Lahtinen wrote: > > > On ti, 2016-03-15 at 14:14 +, Chris Wilson wrote: > > > > On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote: > > > > > > > > > > I'm not sure if you want to check all failure paths, I think > > > > > for that > > > > > the existing failslab etc. mechanisms are better suited. This > > > > > new > > > > > option would be used at relatively few well defined places. The > > > > > option > > > > > is a mask since Chris wanted the possibility to mix failures > > > > > (which > > > > > makes sense when injecting a non-fatal failure somewhere). If > > > > > he > > > > > doesn't insist on that possibility I can convert the mask > > > > > option to a > > > > > counter based one identifying a single failure spot instead as > > > > > you > > > > > suggest. Chris? > > > > We can extend the counter mechanism by having multiple counters > > > > behind > > > > i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1) > > > > > > Now that there's a series to split down the init functions nicely, > > > one > > > could use the function names directly. By stripping parts of it if > > > needed to shorten them. > > > > That's nice. Advantage for using counters is that we can write a test > > to > > iterate over the first thousand and have it run against future > > faultpointers. Advantage for using names is that it is readable and > > easily extensible. > > > > What we could do for testing is record the available fault injection > > points for debugfs and so have the tests automatically adjust (given > > a > > working start point). Overkill? > > I'd prefer if we could fine grain things once we have more failure > points. Atm the ones we defined cause driver init to fail, so separate > counters wouldn't bring us much. I suggest that we keep the module > option as a simple integer for now and extend it later to support the > above tagged counter mechanism and debugfs interface. Here is what I > planned to submit to the list: > > https://github.com/ideak/linux/commits/driver_init_refactor Move the inline into __i915_inject_load_failure, and yes I am happy with the simple first step. Please use __func__ or __FUNCTION__ though as that is more descriptive than file, especially when they move. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Video freezes continue to plague me
On Tue, Mar 15, 2016 at 07:29:22PM -0500, Chris wrote: > On Tue, 2016-03-15 at 19:17 -0400, Felix Miata wrote: > > Chris composed on 2016-03-15 17:43 (UTC-0500): > > > > > On Tue, 2016-03-15 at 16:37 -0400, Felix Miata wrote: > > > > >> Chris composed on 2016-03-15 14:50 (UTC-0500): > > > > >> > My system is a Dell Optiplex 780. > > > > >> Which? Tower? Desktop? SFF? USFF? > > > > > Sorry, it's a desktop > > > > >> > I've filed several bug reports both > > >> > with the Intel Graphics Bugzilla and the Ubuntu Launchpad pages. > > >> > Initially back when this started in 2014 every 'freeze' would result in > > >> > an error of [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer > > >> > elapsed... render ring idle' in syslog. It would happen every few days > > >> > or so and nothing that was done would correct the problem > > > > >> Was ensuring heat is a non-issue also done? SFF & USFF models tend to run > > >> rather hot, so accumulated dust, and especially tobacco tar, within, > > >> especially within the power supply, can become an intermittent problem > > >> for > > >> software. > > > > > Currently it's 87F outside. I have a window open directly behind the > > > system and a fan blowing on the front of it. We're just not ready to > > > turn the AC on yet. CPU0 is running around 116F and CPU1 109F. This > > > whole issue of the video freezing whether it's with or without the > > > Hangcheck error has been ongoing here on my system since 13 Sept 2014. > > > The last time the video froze with the Hangcheck error was Jan 17 2016. > > > Since then the video has frozen without the error on 1/21/16; 1/27/16; > > > 2/25/16; 3/08/16; 3/11/16; and today 3/15/16 at 09:50am. I came back to > > > the desktop at around 11am to find it frozen at 9:50. I moved the mouse, > > > the video flickered and the clock caught up and came unfrozen. The only > > > thing in my syslog for that time is: > > > > > 09:50:07 localhost kernel: [347769.284331] [drm:drm_mode_addfb2] [FB:60] > > > 09:50:07 localhost kernel: [347769.303256] [drm:drm_mode_addfb2] [FB:62] > > > 09:50:07 localhost kernel: [347769.324369] [drm:drm_mode_addfb2] [FB:63] > > > > Ambient temps tolerated by humans really shouldn't matter. Excess heat > > inside > > the case is often a problem elsewhere than where temp probes lie when dust > > has materially accumulated. What I was really asking is, is its inside > > reasonably clean, including inside the PSU? In 2014 it would have been > > around > > 5 or 6 years old. Also, is the PSU fan always moving some air? > > > > Maybe it's time to give it an overnight memtest workout. Could be there's > > become an iffy bit in the video RAM area. > > > > I have a 780 too, and a 760, and a 745, and several 620s, but they are all > > SFF, and don't often get left on more than a couple of hours at a time. > > Video > > lockups I don't remember ever seeing on any of them. Gnome isn't installed > > on > > any. Kubuntu on one 620 might be 14.10, but only openSUSE 13.1, 13.2, 42.1 > > and Tumbleweed are on my 780. 13.2 uses kernel 3.16.7, 42.1 4.1.15, and TW > > (currently) 4.4.3. > > Thanks Felix, I'll see if giving it a good will make any difference. I finally tracked down a bug in the Xserver that would prevent Clients from being woken up if the DRI2 Drawable was destroyed by another Client. That is fixed in xorg-xserver-1.18.2. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support
On Wed, 2016-03-16 at 10:04 +, Chris Wilson wrote: > On Wed, Mar 16, 2016 at 11:43:14AM +0200, Imre Deak wrote: > > On Wed, 2016-03-16 at 09:24 +, Chris Wilson wrote: > > > On Wed, Mar 16, 2016 at 11:18:04AM +0200, Joonas Lahtinen wrote: > > > > On ti, 2016-03-15 at 14:14 +, Chris Wilson wrote: > > > > > On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote: > > > > > > > > > > > > I'm not sure if you want to check all failure paths, I > > > > > > think > > > > > > for that > > > > > > the existing failslab etc. mechanisms are better suited. > > > > > > This > > > > > > new > > > > > > option would be used at relatively few well defined places. > > > > > > The > > > > > > option > > > > > > is a mask since Chris wanted the possibility to mix > > > > > > failures > > > > > > (which > > > > > > makes sense when injecting a non-fatal failure somewhere). > > > > > > If > > > > > > he > > > > > > doesn't insist on that possibility I can convert the mask > > > > > > option to a > > > > > > counter based one identifying a single failure spot instead > > > > > > as > > > > > > you > > > > > > suggest. Chris? > > > > > We can extend the counter mechanism by having multiple > > > > > counters > > > > > behind > > > > > i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1) > > > > > > > > Now that there's a series to split down the init functions > > > > nicely, > > > > one > > > > could use the function names directly. By stripping parts of it > > > > if > > > > needed to shorten them. > > > > > > That's nice. Advantage for using counters is that we can write a > > > test > > > to > > > iterate over the first thousand and have it run against future > > > faultpointers. Advantage for using names is that it is readable > > > and > > > easily extensible. > > > > > > What we could do for testing is record the available fault > > > injection > > > points for debugfs and so have the tests automatically adjust > > > (given > > > a > > > working start point). Overkill? > > > > I'd prefer if we could fine grain things once we have more failure > > points. Atm the ones we defined cause driver init to fail, so > > separate > > counters wouldn't bring us much. I suggest that we keep the module > > option as a simple integer for now and extend it later to support > > the > > above tagged counter mechanism and debugfs interface. Here is what > > I > > planned to submit to the list: > > > > https://github.com/ideak/linux/commits/driver_init_refactor > > Move the inline into __i915_inject_load_failure hm, I have the macro in the header file to optimize for the failure_count=0 case. Or did you mean to bring __i915_inject_load_failure to the header file too/merge it into the macro? > , and yes I am happy with > the simple first step. Please use __func__ or __FUNCTION__ though as > that is more descriptive than file, especially when they move. Ok. --Imre > -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/dsi: start using enum mipi_dsi_pixel_format
A small step moving us closer to DRM MIPI DSI code. Use enum
mipi_dsi_pixel_format instead of our own. The first benefit is being
able to use common mipi_dsi_pixel_format_to_bpp().
There's a little back and forth conversion with the VBT -> enum ->
register, since we have just shoved the VBT value into the register
directly. Longer term, all the VBT parsing and deciphering should be
done in intel_bios.c, and abstracted there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 25 +-
drivers/gpu/drm/i915/intel_dsi.h | 10 +
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 33 ++
drivers/gpu/drm/i915/intel_dsi_pll.c | 30 +--
4 files changed, 56 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 01b8e9f4c272..ea78b0bf7e14 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -787,7 +787,7 @@ static void set_dsi_timings(struct drm_encoder *encoder,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
enum port port;
- unsigned int bpp = dsi_pixel_format_bpp(intel_dsi->pixel_format);
+ unsigned int bpp =
mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
unsigned int lane_count = intel_dsi->lane_count;
u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
@@ -849,6 +849,23 @@ static void set_dsi_timings(struct drm_encoder *encoder,
}
}
+static u32 pixel_format_to_reg(enum mipi_dsi_pixel_format fmt)
+{
+ switch (fmt) {
+ case MIPI_DSI_FMT_RGB888:
+ return VID_MODE_FORMAT_RGB888;
+ case MIPI_DSI_FMT_RGB666:
+ return VID_MODE_FORMAT_RGB666;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ return VID_MODE_FORMAT_RGB666_PACKED;
+ case MIPI_DSI_FMT_RGB565:
+ return VID_MODE_FORMAT_RGB565;
+ default:
+ MISSING_CASE(fmt);
+ return VID_MODE_FORMAT_RGB666;
+ }
+}
+
static void intel_dsi_prepare(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = &intel_encoder->base;
@@ -858,7 +875,7 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
const struct drm_display_mode *adjusted_mode =
&intel_crtc->config->base.adjusted_mode;
enum port port;
- unsigned int bpp = dsi_pixel_format_bpp(intel_dsi->pixel_format);
+ unsigned int bpp =
mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
u32 val, tmp;
u16 mode_hdisplay;
@@ -917,9 +934,7 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
val |= CMD_MODE_DATA_WIDTH_8_BIT; /* XXX */
} else {
val |= intel_dsi->channel << VID_MODE_CHANNEL_NUMBER_SHIFT;
-
- /* XXX: cross-check bpp vs. pixel format? */
- val |= intel_dsi->pixel_format;
+ val |= pixel_format_to_reg(intel_dsi->pixel_format);
}
tmp = 0;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 92f39227b361..54f072cd78f1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -34,8 +34,6 @@
#define DSI_DUAL_LINK_FRONT_BACK 1
#define DSI_DUAL_LINK_PIXEL_ALT2
-int dsi_pixel_format_bpp(int pixel_format);
-
struct intel_dsi_host;
struct intel_dsi {
@@ -64,8 +62,12 @@ struct intel_dsi {
/* number of DSI lanes */
unsigned int lane_count;
- /* video mode pixel format for MIPI_DSI_FUNC_PRG register */
- u32 pixel_format;
+ /*
+* video mode pixel format
+*
+* XXX: consolidate on .format in struct mipi_dsi_device.
+*/
+ enum mipi_dsi_pixel_format pixel_format;
/* video mode format for MIPI_VIDEO_MODE_FORMAT register */
u32 video_mode_format;
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 7f145b4fec6a..8302a972d2d4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -412,6 +412,25 @@ static const struct drm_panel_funcs vbt_panel_funcs = {
.get_modes = vbt_panel_get_modes,
};
+/* XXX: This should be done when parsing the VBT in intel_bios.c */
+static enum mipi_dsi_pixel_format pixel_format_from_vbt(u32 fmt)
+{
+ /* It just so happens the VBT matches register contents. */
+ switch (fmt) {
+ case VID_MODE_FORMAT_RGB888:
+ return MIPI_DSI_FMT_RGB888;
+ case VID_MODE_FORMAT_RGB666:
+ return MIPI_DSI_FMT_RGB666;
+ case VID_MODE_FORMAT_RGB666_PACKED:
+ return MIPI_DSI_FMT_RGB666_PACKED;
+ case VID_MODE_FORMAT_RGB565:
+ retu
[Intel-gfx] [PATCH 1/2] drm/i915/dsi: lose the loose 666 format name in favor of packed
The enum mipi_dsi_pixel_format defines MIPI_DSI_FMT_RGB666 for the
"loose" 24 bpp format and MIPI_DSI_FMT_RGB666_PACKED for the 18 bpp
format. We have this the other way round, defining a loose version for
24 bpp.
Follow suit with what's in enum mipi_dsi_pixel_format to avoid future
confusion. Rename
VID_MODE_FORMAT_RGB666 -> VID_MODE_FORMAT_RGB666_PACKED
VID_MODE_FORMAT_RGB666_LOOSE -> VID_MODE_FORMAT_RGB666
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
drivers/gpu/drm/i915/intel_dsi_pll.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc4007f3fa..85ceec611412 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7887,8 +7887,8 @@ enum skl_disp_power_wells {
#define VID_MODE_FORMAT_MASK (0xf << 7)
#define VID_MODE_NOT_SUPPORTED(0 << 7)
#define VID_MODE_FORMAT_RGB565(1 << 7)
-#define VID_MODE_FORMAT_RGB666(2 << 7)
-#define VID_MODE_FORMAT_RGB666_LOOSE (3 << 7)
+#define VID_MODE_FORMAT_RGB666_PACKED (2 << 7)
+#define VID_MODE_FORMAT_RGB666(3 << 7)
#define VID_MODE_FORMAT_RGB888(4 << 7)
#define CMD_MODE_CHANNEL_NUMBER_SHIFT 5
#define CMD_MODE_CHANNEL_NUMBER_MASK (3 << 5)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 2451c84949bd..9ef0f7806e4a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -37,10 +37,10 @@ int dsi_pixel_format_bpp(int pixel_format)
switch (pixel_format) {
default:
case VID_MODE_FORMAT_RGB888:
- case VID_MODE_FORMAT_RGB666_LOOSE:
+ case VID_MODE_FORMAT_RGB666:
bpp = 24;
break;
- case VID_MODE_FORMAT_RGB666:
+ case VID_MODE_FORMAT_RGB666_PACKED:
bpp = 18;
break;
case VID_MODE_FORMAT_RGB565:
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: SKL CDCLK change on modeset tracking VCO (rev10)
== Series Details == Series: drm/i915/skl: SKL CDCLK change on modeset tracking VCO (rev10) URL : https://patchwork.freedesktop.org/series/1609/ State : failure == Summary == Series 1609v10 drm/i915/skl: SKL CDCLK change on modeset tracking VCO http://patchwork.freedesktop.org/api/1.0/series/1609/revisions/10/mbox/ Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> DMESG-WARN (hsw-gt2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-nuci5) Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (snb-dellxps) Subgroup basic-rte: dmesg-warn -> PASS (snb-dellxps) bdw-nuci7total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:194 pass:173 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:194 pass:156 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:194 pass:155 dwarn:4 dfail:0 fail:0 skip:35 hsw-gt2 total:194 pass:176 dwarn:1 dfail:0 fail:0 skip:17 ivb-t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:194 pass:183 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:194 pass:159 dwarn:1 dfail:0 fail:0 skip:34 snb-x220ttotal:194 pass:159 dwarn:1 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1609/ fc881ebd9c3c26919c7d1113f8bf7014e1a05563 drm-intel-nightly: 2016y-03m-15d-13h-10m-41s UTC integration manifest 31aa1232a835a2b9d867f846acd8d73cc3340789 drm/i915/skl: SKL CDCLK change on modeset tracking VCO ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add fault injection support
On Wed, Mar 16, 2016 at 12:17:51PM +0200, Imre Deak wrote: > On Wed, 2016-03-16 at 10:04 +, Chris Wilson wrote: > > On Wed, Mar 16, 2016 at 11:43:14AM +0200, Imre Deak wrote: > > > On Wed, 2016-03-16 at 09:24 +, Chris Wilson wrote: > > > > On Wed, Mar 16, 2016 at 11:18:04AM +0200, Joonas Lahtinen wrote: > > > > > On ti, 2016-03-15 at 14:14 +, Chris Wilson wrote: > > > > > > On Tue, Mar 15, 2016 at 04:01:14PM +0200, Imre Deak wrote: > > > > > > > > > > > > > > I'm not sure if you want to check all failure paths, I > > > > > > > think > > > > > > > for that > > > > > > > the existing failslab etc. mechanisms are better suited. > > > > > > > This > > > > > > > new > > > > > > > option would be used at relatively few well defined places. > > > > > > > The > > > > > > > option > > > > > > > is a mask since Chris wanted the possibility to mix > > > > > > > failures > > > > > > > (which > > > > > > > makes sense when injecting a non-fatal failure somewhere). > > > > > > > If > > > > > > > he > > > > > > > doesn't insist on that possibility I can convert the mask > > > > > > > option to a > > > > > > > counter based one identifying a single failure spot instead > > > > > > > as > > > > > > > you > > > > > > > suggest. Chris? > > > > > > We can extend the counter mechanism by having multiple > > > > > > counters > > > > > > behind > > > > > > i915.inject_load_failure (i.e. =gem:4,driver:10,modeset:1) > > > > > > > > > > Now that there's a series to split down the init functions > > > > > nicely, > > > > > one > > > > > could use the function names directly. By stripping parts of it > > > > > if > > > > > needed to shorten them. > > > > > > > > That's nice. Advantage for using counters is that we can write a > > > > test > > > > to > > > > iterate over the first thousand and have it run against future > > > > faultpointers. Advantage for using names is that it is readable > > > > and > > > > easily extensible. > > > > > > > > What we could do for testing is record the available fault > > > > injection > > > > points for debugfs and so have the tests automatically adjust > > > > (given > > > > a > > > > working start point). Overkill? > > > > > > I'd prefer if we could fine grain things once we have more failure > > > points. Atm the ones we defined cause driver init to fail, so > > > separate > > > counters wouldn't bring us much. I suggest that we keep the module > > > option as a simple integer for now and extend it later to support > > > the > > > above tagged counter mechanism and debugfs interface. Here is what > > > I > > > planned to submit to the list: > > > > > > https://github.com/ideak/linux/commits/driver_init_refactor > > > > Move the inline into __i915_inject_load_failure > > hm, I have the macro in the header file to optimize for the > failure_count=0 case. Or did you mean to > bring __i915_inject_load_failure to the header file too/merge it into > the macro? Just the extra inlined conditional need not be in the header. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 1/7] drm/i915: move VBT based TV presence check to intel_bios.c
Hide knowledge about VBT child devices in intel_bios.c.
v2: also move int_tv_support check to intel_bios.c (Sivakumar)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 41 ++
drivers/gpu/drm/i915/intel_tv.c | 46 +--
3 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1ba302..f314d2737b4e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3334,6 +3334,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
/* intel_bios.c */
int intel_bios_init(struct drm_i915_private *dev_priv);
bool intel_bios_is_valid_vbt(const void *buf, size_t size);
+bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index bf62a19c8f69..d5e6da01adaa 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1431,3 +1431,44 @@ intel_bios_init(struct drm_i915_private *dev_priv)
return 0;
}
+
+/**
+ * intel_bios_is_tv_present - is integrated TV present in VBT
+ * @dev_priv: i915 device instance
+ *
+ * Return true if TV is present. If no child devices were parsed from VBT,
+ * assume TV is present.
+ */
+bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv)
+{
+ union child_device_config *p_child;
+ int i;
+
+ if (!dev_priv->vbt.int_tv_support)
+ return false;
+
+ if (!dev_priv->vbt.child_dev_num)
+ return true;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ p_child = dev_priv->vbt.child_dev + i;
+ /*
+* If the device type is not TV, continue.
+*/
+ switch (p_child->old.device_type) {
+ case DEVICE_TYPE_INT_TV:
+ case DEVICE_TYPE_TV:
+ case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
+ break;
+ default:
+ continue;
+ }
+ /* Only when the addin_offset is non-zero, it is regarded
+* as present.
+*/
+ if (p_child->old.addin_offset)
+ return true;
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index d5570c859009..223129d3c765 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1519,47 +1519,6 @@ static const struct drm_encoder_funcs intel_tv_enc_funcs
= {
.destroy = intel_encoder_destroy,
};
-/*
- * Enumerate the child dev array parsed from VBT to check whether
- * the integrated TV is present.
- * If it is present, return 1.
- * If it is not present, return false.
- * If no child dev is parsed from VBT, it assumes that the TV is present.
- */
-static int tv_is_present_in_vbt(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- union child_device_config *p_child;
- int i, ret;
-
- if (!dev_priv->vbt.child_dev_num)
- return 1;
-
- ret = 0;
- for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
- p_child = dev_priv->vbt.child_dev + i;
- /*
-* If the device type is not TV, continue.
-*/
- switch (p_child->old.device_type) {
- case DEVICE_TYPE_INT_TV:
- case DEVICE_TYPE_TV:
- case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
- break;
- default:
- continue;
- }
- /* Only when the addin_offset is non-zero, it is regarded
-* as present.
-*/
- if (p_child->old.addin_offset) {
- ret = 1;
- break;
- }
- }
- return ret;
-}
-
void
intel_tv_init(struct drm_device *dev)
{
@@ -1575,13 +1534,10 @@ intel_tv_init(struct drm_device *dev)
if ((I915_READ(TV_CTL) & TV_FUSE_STATE_MASK) == TV_FUSE_STATE_DISABLED)
return;
- if (!tv_is_present_in_vbt(dev)) {
+ if (!intel_bios_is_tv_present(dev_priv)) {
DRM_DEBUG_KMS("Integrated TV is not present.\n");
return;
}
- /* Even if we have an encoder we may not have a connector */
- if (!dev_priv->vbt.int_tv_support)
- return;
/*
* Sanity check the TV output by checking to see if the
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 6/7] drm/i915/bios: drop has_mipi in favor of intel_bios_is_dsi_present
Favor a single point of truth instead of duplicating the information.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_bios.c | 12 +++-
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c7402c062b9..cff4b6ec79d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1415,7 +1415,6 @@ struct intel_vbt_data {
unsigned int lvds_use_ssc:1;
unsigned int display_clock_mode:1;
unsigned int fdi_rx_polarity_inverted:1;
- unsigned int has_mipi:1;
int lvds_ssc_freq;
unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 4b6bd6f2e193..aa90dc662e7f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -706,7 +706,7 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
const struct mipi_pps_data *pps;
/* parse MIPI blocks only if LFP type is MIPI */
- if (!dev_priv->vbt.has_mipi)
+ if (!intel_bios_is_dsi_present(dev_priv, NULL))
return;
/* Initialize this to undefined indicating no generic MIPI support */
@@ -1232,13 +1232,6 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
continue;
}
- if (p_child->common.dvo_port >= DVO_PORT_MIPIA
- && p_child->common.dvo_port <= DVO_PORT_MIPID
- &&p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {
- DRM_DEBUG_KMS("Found MIPI as LFP\n");
- dev_priv->vbt.has_mipi = 1;
- }
-
child_dev_ptr = dev_priv->vbt.child_dev + count;
count++;
@@ -1580,7 +1573,8 @@ bool intel_bios_is_dsi_present(struct drm_i915_private
*dev_priv,
switch (dvo_port) {
case DVO_PORT_MIPIA:
case DVO_PORT_MIPIC:
- *port = dvo_port - DVO_PORT_MIPIA;
+ if (port)
+ *port = dvo_port - DVO_PORT_MIPIA;
return true;
case DVO_PORT_MIPIB:
case DVO_PORT_MIPID:
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 7/7] drm/i915: hide away VBT private data in a separate header
We've been accumulating code across the driver that depends on the VBT
specific structures and defines. The VBT is an uncontrollable
beast. Encourage encapsulation of the VBT data by hiding the structures
and defines in a private header only to be included from intel_bios.c.
Signed-off-by: Jani Nikula
---
Documentation/DocBook/gpu.tmpl| 2 +-
drivers/gpu/drm/i915/intel_bios.c | 4 +-
drivers/gpu/drm/i915/intel_bios.h | 861 ++
drivers/gpu/drm/i915/intel_vbt_defs.h | 826
4 files changed, 865 insertions(+), 828 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_vbt_defs.h
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1692c4dd5487..ab7ffebf4b95 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -3334,7 +3334,7 @@ int num_ioctls;
Video BIOS Table (VBT)
!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
!Idrivers/gpu/drm/i915/intel_bios.c
-!Idrivers/gpu/drm/i915/intel_bios.h
+!Idrivers/gpu/drm/i915/intel_vbt_defs.h
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index aa90dc662e7f..083003b015f5 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -29,7 +29,9 @@
#include
#include
#include "i915_drv.h"
-#include "intel_bios.h"
+
+#define _INTEL_BIOS_PRIVATE
+#include "intel_vbt_defs.h"
/**
* DOC: Video BIOS Table (VBT)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 350d4e0f75a4..ab0ea315eddb 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -1,5 +1,5 @@
/*
- * Copyright © 2006 Intel Corporation
+ * Copyright © 2016 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -19,543 +19,16 @@
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
* SOFTWARE.
- *
- * Authors:
- *Eric Anholt
- *
- */
-
-#ifndef _INTEL_BIOS_H_
-#define _INTEL_BIOS_H_
-
-/**
- * struct vbt_header - VBT Header structure
- * @signature: VBT signature, always starts with "$VBT"
- * @version: Version of this structure
- * @header_size: Size of this structure
- * @vbt_size: Size of VBT (VBT Header, BDB Header and data blocks)
- * @vbt_checksum: Checksum
- * @reserved0: Reserved
- * @bdb_offset:Offset of &struct bdb_header from beginning of
VBT
- * @aim_offset:Offsets of add-in data blocks from beginning of
VBT
- */
-struct vbt_header {
- u8 signature[20];
- u16 version;
- u16 header_size;
- u16 vbt_size;
- u8 vbt_checksum;
- u8 reserved0;
- u32 bdb_offset;
- u32 aim_offset[4];
-} __packed;
-
-/**
- * struct bdb_header - BDB Header structure
- * @signature: BDB signature "BIOS_DATA_BLOCK"
- * @version: Version of the data block definitions
- * @header_size: Size of this structure
- * @bdb_size: Size of BDB (BDB Header and data blocks)
- */
-struct bdb_header {
- u8 signature[16];
- u16 version;
- u16 header_size;
- u16 bdb_size;
-} __packed;
-
-/* strictly speaking, this is a "skip" block, but it has interesting info */
-struct vbios_data {
- u8 type; /* 0 == desktop, 1 == mobile */
- u8 relstage;
- u8 chipset;
- u8 lvds_present:1;
- u8 tv_present:1;
- u8 rsvd2:6; /* finish byte */
- u8 rsvd3[4];
- u8 signon[155];
- u8 copyright[61];
- u16 code_segment;
- u8 dos_boot_mode;
- u8 bandwidth_percent;
- u8 rsvd4; /* popup memory size */
- u8 resize_pci_bios;
- u8 rsvd5; /* is crt already on ddc2 */
-} __packed;
-
-/*
- * There are several types of BIOS data blocks (BDBs), each block has
- * an ID and size in the first 3 bytes (ID in first, size in next 2).
- * Known types are listed below.
*/
-#define BDB_GENERAL_FEATURES 1
-#define BDB_GENERAL_DEFINITIONS 2
-#define BDB_OLD_TOGGLE_LIST 3
-#define BDB_MODE_SUPPORT_LIST4
-#define BDB_GENERIC_MODE_TABLE 5
-#define BDB_EXT_MMIO_REGS6
-#define BDB_SWF_IO 7
-#define BDB_SWF_MMIO 8
-#define BDB_PSR 9
-#define BDB_MODE_REMOVAL_TABLE 10
-#define BDB_CHILD_DEVICE_TABLE 11
-#define BDB_DRIVER_FEATURES 12
-#define BDB_DRIVER_PERSISTENCE 13
-#define BDB_EXT_TABLE_PTRS 14
-#define BDB_DOT_CLOCK_OVERRIDE 15
-#define BDB_DISPLAY_SELECT 16
-/* 17 rsvd */
-#define BDB_DRIVER_ROTATION 18
-#define BDB_DISPLAY_REMOVE 19
-#define BDB_OEM_CUSTOM 20
-#define BDB_EFP_LIST21 /* workarounds for VGA hsync/vsync */
-#define BD
[Intel-gfx] [PATCH RESEND 3/7] drm/i915: move VBT based eDP port check to intel_bios.c
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 33 +
drivers/gpu/drm/i915/intel_dp.c | 21 +
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fb7a22e802b..c6ec7029f691 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3336,6 +3336,7 @@ int intel_bios_init(struct drm_i915_private *dev_priv);
bool intel_bios_is_valid_vbt(const void *buf, size_t size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
+bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 4f7eba36a849..7f61ca8165f0 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1522,3 +1522,36 @@ bool intel_bios_is_lvds_present(struct drm_i915_private
*dev_priv, u8 *i2c_pin)
return false;
}
+
+/**
+ * intel_bios_is_port_edp - is the device in given port eDP
+ * @dev_priv: i915 device instance
+ * @port: port to check
+ *
+ * Return true if the device in %port is eDP.
+ */
+bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port)
+{
+ union child_device_config *p_child;
+ static const short port_mapping[] = {
+ [PORT_B] = DVO_PORT_DPB,
+ [PORT_C] = DVO_PORT_DPC,
+ [PORT_D] = DVO_PORT_DPD,
+ [PORT_E] = DVO_PORT_DPE,
+ };
+ int i;
+
+ if (!dev_priv->vbt.child_dev_num)
+ return false;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ p_child = dev_priv->vbt.child_dev + i;
+
+ if (p_child->common.dvo_port == port_mapping[port] &&
+ (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
+ (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
+ return true;
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e326e776e8f..2f8ce53df9cb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4990,14 +4990,6 @@ put_power:
bool intel_dp_is_edp(struct drm_device *dev, enum port port)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- union child_device_config *p_child;
- int i;
- static const short port_mapping[] = {
- [PORT_B] = DVO_PORT_DPB,
- [PORT_C] = DVO_PORT_DPC,
- [PORT_D] = DVO_PORT_DPD,
- [PORT_E] = DVO_PORT_DPE,
- };
/*
* eDP not supported on g4x. so bail out early just
@@ -5009,18 +5001,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port
port)
if (port == PORT_A)
return true;
- if (!dev_priv->vbt.child_dev_num)
- return false;
-
- for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
- p_child = dev_priv->vbt.child_dev + i;
-
- if (p_child->common.dvo_port == port_mapping[port] &&
- (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
- (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
- return true;
- }
- return false;
+ return intel_bios_is_port_edp(dev_priv, port);
}
void
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 2/7] drm/i915: move VBT based LVDS presence check to intel_bios.c
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 50
drivers/gpu/drm/i915/intel_lvds.c | 53 +--
3 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f314d2737b4e..5fb7a22e802b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3335,6 +3335,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
int intel_bios_init(struct drm_i915_private *dev_priv);
bool intel_bios_is_valid_vbt(const void *buf, size_t size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
+bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index d5e6da01adaa..4f7eba36a849 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1472,3 +1472,53 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv)
return false;
}
+
+/**
+ * intel_bios_is_lvds_present - is LVDS present in VBT
+ * @dev_priv: i915 device instance
+ * @i2c_pin: i2c pin for LVDS if present
+ *
+ * Return true if LVDS is present. If no child devices were parsed from VBT,
+ * assume LVDS is present.
+ */
+bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 *i2c_pin)
+{
+ int i;
+
+ if (!dev_priv->vbt.child_dev_num)
+ return true;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ union child_device_config *uchild = dev_priv->vbt.child_dev + i;
+ struct old_child_dev_config *child = &uchild->old;
+
+ /* If the device type is not LFP, continue.
+* We have to check both the new identifiers as well as the
+* old for compatibility with some BIOSes.
+*/
+ if (child->device_type != DEVICE_TYPE_INT_LFP &&
+ child->device_type != DEVICE_TYPE_LFP)
+ continue;
+
+ if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
+ *i2c_pin = child->i2c_pin;
+
+ /* However, we cannot trust the BIOS writers to populate
+* the VBT correctly. Since LVDS requires additional
+* information from AIM blocks, a non-zero addin offset is
+* a good indicator that the LVDS is actually present.
+*/
+ if (child->addin_offset)
+ return true;
+
+ /* But even then some BIOS writers perform some black magic
+* and instantiate the device without reference to any
+* additional data. Trust that if the VBT was written into
+* the OpRegion then they have validated the LVDS's existence.
+*/
+ if (dev_priv->opregion.vbt)
+ return true;
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index cbd1b0d547ee..766ba566fef1 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -775,57 +775,6 @@ static const struct dmi_system_id intel_no_lvds[] = {
{ } /* terminating entry */
};
-/*
- * Enumerate the child dev array parsed from VBT to check whether
- * the LVDS is present.
- * If it is present, return 1.
- * If it is not present, return false.
- * If no child dev is parsed from VBT, it assumes that the LVDS is present.
- */
-static bool lvds_is_present_in_vbt(struct drm_device *dev,
- u8 *i2c_pin)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- int i;
-
- if (!dev_priv->vbt.child_dev_num)
- return true;
-
- for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
- union child_device_config *uchild = dev_priv->vbt.child_dev + i;
- struct old_child_dev_config *child = &uchild->old;
-
- /* If the device type is not LFP, continue.
-* We have to check both the new identifiers as well as the
-* old for compatibility with some BIOSes.
-*/
- if (child->device_type != DEVICE_TYPE_INT_LFP &&
- child->device_type != DEVICE_TYPE_LFP)
- continue;
-
- if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
- *i2c_pin = child->i2c_pin;
-
- /* However, we cannot trust the BIOS writers to populate
-* the VBT correctly. Since LVDS requires additional
-* information from AIM blocks, a non-zero addin offset is
-
[Intel-gfx] [PATCH RESEND 5/7] drm/i915/panel: setup pwm backlight based on connector type
Use the connector type instead of VBT directly to decide which backlight
mechanism to use on VLV/CHV. (Indirectly, this is the same thing, but
hides the VBT use.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 0fe059bc7d80..8c8996fcbaf5 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1743,7 +1743,7 @@ intel_panel_init_backlight_funcs(struct intel_panel
*panel)
panel->backlight.get = pch_get_backlight;
panel->backlight.hz_to_pwm = pch_hz_to_pwm;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- if (dev_priv->vbt.has_mipi) {
+ if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
panel->backlight.setup = pwm_setup_backlight;
panel->backlight.enable = pwm_enable_backlight;
panel->backlight.disable = pwm_disable_backlight;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 4/7] drm/i915: move VBT based DSI presence check to intel_bios.c
Hide knowledge about VBT child devices in intel_bios.c.
v2: Move port check to intel_bios.c (Sivakumar)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 39 ++-
drivers/gpu/drm/i915/intel_dsi.c | 17 -
3 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c6ec7029f691..9c7402c062b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1449,7 +1449,6 @@ struct intel_vbt_data {
/* MIPI DSI */
struct {
- u16 port;
u16 panel_id;
struct mipi_config *config;
struct mipi_pps_data *pps;
@@ -3337,6 +3336,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
+bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 7f61ca8165f0..4b6bd6f2e193 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1237,7 +1237,6 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
&&p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {
DRM_DEBUG_KMS("Found MIPI as LFP\n");
dev_priv->vbt.has_mipi = 1;
- dev_priv->vbt.dsi.port = p_child->common.dvo_port;
}
child_dev_ptr = dev_priv->vbt.child_dev + count;
@@ -1555,3 +1554,41 @@ bool intel_bios_is_port_edp(struct drm_i915_private
*dev_priv, enum port port)
return false;
}
+
+/**
+ * intel_bios_is_dsi_present - is DSI present in VBT
+ * @dev_priv: i915 device instance
+ * @port: port for DSI if present
+ *
+ * Return true if DSI is present, and return the port in %port.
+ */
+bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv,
+ enum port *port)
+{
+ union child_device_config *p_child;
+ u8 dvo_port;
+ int i;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ p_child = dev_priv->vbt.child_dev + i;
+
+ if (!(p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT))
+ continue;
+
+ dvo_port = p_child->common.dvo_port;
+
+ switch (dvo_port) {
+ case DVO_PORT_MIPIA:
+ case DVO_PORT_MIPIC:
+ *port = dvo_port - DVO_PORT_MIPIA;
+ return true;
+ case DVO_PORT_MIPIB:
+ case DVO_PORT_MIPID:
+ DRM_DEBUG_KMS("VBT has unsupported DSI port %c\n",
+ port_name(dvo_port - DVO_PORT_MIPIA));
+ break;
+ }
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 01b8e9f4c272..1df70ab9edf9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1121,7 +1121,7 @@ void intel_dsi_init(struct drm_device *dev)
DRM_DEBUG_KMS("\n");
/* There is no detection method for MIPI so rely on VBT */
- if (!dev_priv->vbt.has_mipi)
+ if (!intel_bios_is_dsi_present(dev_priv, &port))
return;
if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
@@ -1162,16 +1162,15 @@ void intel_dsi_init(struct drm_device *dev)
intel_connector->unregister = intel_connector_unregister;
/* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
- if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIA) {
- intel_encoder->crtc_mask = (1 << PIPE_A);
- intel_dsi->ports = (1 << PORT_A);
- } else if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIC) {
- intel_encoder->crtc_mask = (1 << PIPE_B);
- intel_dsi->ports = (1 << PORT_C);
- }
+ if (port == PORT_A)
+ intel_encoder->crtc_mask = 1 << PIPE_A;
+ else
+ intel_encoder->crtc_mask = 1 << PIPE_B;
if (dev_priv->vbt.dsi.config->dual_link)
- intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
+ intel_dsi->ports = (1 << PORT_A) | (1 << PORT_C);
+ else
+ intel_dsi->ports = 1 << port;
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi->ports) {
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/int
Re: [Intel-gfx] [PATCH] drm/i915: Fix eDP low vswing for Broadwell
On Wed, 2016-03-16 at 11:49 +0200, Jani Nikula wrote:
> On Wed, 16 Mar 2016, Mika Kahola wrote:
> > [ text/plain ]
> > It was noticed on bug #94087 that module parameter
> > i915.edp_vswing=2 that should override the VBT setting
> > to use default voltage swing (400 mV) was not applied
> > for Broadwell.
> >
> > This patch provides a fix for this by checking if default
> > i.e. higher voltage swing is requested to be used and
> > applies the DDI translations table for DP instead of eDP
> > (low vswing) table.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087
> > Signed-off-by: Mika Kahola
>
> cc: stable?
>
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index ab025a5..e30adcd 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -443,9 +443,19 @@ void intel_prepare_ddi_buffer(struct intel_encoder
> > *encoder)
> > } else if (IS_BROADWELL(dev_priv)) {
> > ddi_translations_fdi = bdw_ddi_translations_fdi;
> > ddi_translations_dp = bdw_ddi_translations_dp;
> > - ddi_translations_edp = bdw_ddi_translations_edp;
> > +
> > + if (dev_priv->edp_low_vswing)
> > + ddi_translations_edp = bdw_ddi_translations_edp;
> > + else
> > + ddi_translations_edp = bdw_ddi_translations_dp;
> > +
> > ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> > - n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> > +
> > + if (dev_priv->edp_low_vswing)
> > + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> > + else
> > + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> > +
>
> Please just put these in one if statement above, instead of having two.
>
Ok, I'll fix those if statements. I'll throw a second version for a
review.
Cheers,
Mika
> BR,
> Jani.
>
> > n_dp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> > n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
> > hdmi_default_entry = 7;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Extract out gamma table and CSC to their own file
The moves a couple of functions programming the gamma LUT and CSC
units into their own file.
On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or
12bits).
The CSC unit is only available from Haswell on.
We also need to make a special case for CherryView which is recognized
as a gen 8 but doesn't have the same enhanced color correction unit
from Haswell on.
v2: Fix access to GAMMA_MODE register on older generations than
Haswell (from Matt Roper's comments)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_color.c | 191 +++
drivers/gpu/drm/i915/intel_display.c | 163 +++---
drivers/gpu/drm/i915/intel_drv.h | 10 ++
5 files changed, 216 insertions(+), 151 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_color.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5558a03..7ffb51b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += intel_audio.o \
intel_atomic.o \
intel_atomic_plane.o \
intel_bios.o \
+ intel_color.o \
intel_display.o \
intel_dpll_mgr.o \
intel_fbc.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1..cd0c041 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -593,6 +593,8 @@ struct drm_i915_display_funcs {
/* render clock increase/decrease */
/* display clock increase/decrease */
/* pll clock increase/decrease */
+
+ void (*load_luts)(struct drm_crtc *crtc);
};
enum forcewake_domain_id {
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
new file mode 100644
index 000..35b7f62
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_drv.h"
+
+/*
+ * Set up the pipe CSC unit.
+ *
+ * Currently only full range RGB to limited range RGB conversion
+ * is supported, but eventually this should handle various
+ * RGB<->YCbCr scenarios as well.
+ */
+static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc->pipe;
+ uint16_t coeff = 0x7800; /* 1.0 */
+
+ /*
+* TODO: Check what kind of values actually come out of the pipe
+* with these coeff/postoff values and adjust to get the best
+* accuracy. Perhaps we even need to take the bpc value into
+* consideration.
+*/
+
+ if (intel_crtc->config->limited_color_range)
+ coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
+
+ I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), coeff << 16);
+ I915_WRITE(PIPE_CSC_COEFF_BY(pipe), 0);
+
+ I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), coeff);
+ I915_WRITE(PIPE_CSC_COEFF_BU(pipe), 0);
+
+ I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), 0);
+ I915_WRITE(PIPE_CSC_COEFF_BV(pipe), coeff << 16);
+
+ I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+ if (INTEL_INFO(dev)->gen > 6) {
+ uint16_t postoff = 0;
+
+ if (intel_crtc->config->limited_color_range)
+ postoff = (16 * (1
[Intel-gfx] [PATCH 3/4] drm/i915: Implement color management on bdw/skl/bxt/kbl
Patch based on a previous series by Shashank Sharma.
v2: Do not read GAMMA_MODE register to figure what mode we're in
v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0
Add documentation on how the Broadcast RGB property is affected by CTM
v4: Update contributors
v5: Refactor degamma/gamma LUTs load into a single function
v6: Fix missing intel_crtc variable (bisect issue)
v7: Fix & simplify limited range matrix multiplication (Matt Roper's
comment)
Signed-off-by: Shashank Sharma
Signed-off-by: Kumar, Kiran S
Signed-off-by: Kausal Malladi
Signed-off-by: Lionel Landwerlin
Acknowledged-by: Matt Roper
---
Documentation/DocBook/gpu.tmpl | 6 +-
drivers/gpu/drm/i915/i915_drv.c | 24 ++-
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/i915_reg.h | 22 +++
drivers/gpu/drm/i915/intel_color.c | 345 +--
drivers/gpu/drm/i915/intel_display.c | 22 ++-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_fbdev.c | 8 +
8 files changed, 371 insertions(+), 65 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1692c4d..430e99b 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2153,7 +2153,11 @@ void intel_crt_init(struct drm_device *dev)
ENUM
{ "Automatic", "Full", "Limited 16:235" }
Connector
- TBD
+ When this property is set to Limited 16:235
+ and CTM is set, the hardware will be programmed with the
+ result of the multiplication of CTM by the limited range
+ matrix to ensure the pixels normaly in the range 0..1.0 are
+ remapped to the range 16/255..235/255.
“audio”
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e8200..3807b73 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -66,6 +66,9 @@ static struct drm_driver driver;
#define IVB_CURSOR_OFFSETS \
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
IVB_CURSOR_C_OFFSET }
+#define BDW_COLORS \
+ .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+
static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
.has_overlay = 1, .overlay_needs_physical = 1,
@@ -288,24 +291,28 @@ static const struct intel_device_info
intel_haswell_m_info = {
.is_mobile = 1,
};
+#define BDW_FEATURES \
+ HSW_FEATURES, \
+ BDW_COLORS
+
static const struct intel_device_info intel_broadwell_d_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.gen = 8,
};
static const struct intel_device_info intel_broadwell_m_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.gen = 8, .is_mobile = 1,
};
static const struct intel_device_info intel_broadwell_gt3d_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.gen = 8,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
};
static const struct intel_device_info intel_broadwell_gt3m_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.gen = 8, .is_mobile = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
};
@@ -321,13 +328,13 @@ static const struct intel_device_info
intel_cherryview_info = {
};
static const struct intel_device_info intel_skylake_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
};
static const struct intel_device_info intel_skylake_gt3_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
@@ -345,17 +352,18 @@ static const struct intel_device_info intel_broxton_info
= {
.has_fbc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
+ BDW_COLORS,
};
static const struct intel_device_info intel_kabylake_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
};
static const struct intel_device_info intel_kabylake_gt3_info = {
- HSW_FEATURES,
+ BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd0c041..e4f7059 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -594,6 +594,7 @@ struct drm_i915_display_funcs {
/* display clock increase/decrease */
/* pll clock increase/decrease */
+ void (*load_csc_matrix)(struct drm_crtc *crtc);
void (*load_luts)(struct drm_crtc *crtc);
};
@@ -745,6 +746,11 @@ struct intel_device_info {
u8 has_slice_pg:1;
u8 has_subslice_pg:1;
u8 has_eu_pg:1;
+
+ struct color_
[Intel-gfx] [PATCH 4/4] drm/i915: Implement color management on chv
Patch based on a previous series by Shashank Sharma.
v2: Update contributors
v3: Refactor degamma/gamma LUTs load into a single function
v4: Remove unused variable
Signed-off-by: Shashank Sharma
Signed-off-by: Kumar, Kiran S
Signed-off-by: Kausal Malladi
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.c| 3 +
drivers/gpu/drm/i915/i915_reg.h| 31 +
drivers/gpu/drm/i915/intel_color.c | 133 +++--
3 files changed, 161 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3807b73..8a2aaa7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -68,6 +68,8 @@ static struct drm_driver driver;
#define BDW_COLORS \
.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+#define CHV_COLORS \
+ .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
@@ -325,6 +327,7 @@ static const struct intel_device_info intel_cherryview_info
= {
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
+ CHV_COLORS,
};
static const struct intel_device_info intel_skylake_info = {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d9defd3..95f56a0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7678,6 +7678,37 @@ enum skl_disp_power_wells {
#define PREC_PAL_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A,
_PAL_PREC_GC_MAX_B) + (i) * 4)
#define PREC_PAL_EXT_GC_MAX(pipe, i) _MMIO(_PIPE(pipe,
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
+/* pipe CSC & degamma/gamma LUTs on CHV */
+#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
+#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
+#define _CGM_PIPE_A_CSC_COEFF45(VLV_DISPLAY_BASE + 0x67908)
+#define _CGM_PIPE_A_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6790C)
+#define _CGM_PIPE_A_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x67910)
+#define _CGM_PIPE_A_DEGAMMA(VLV_DISPLAY_BASE + 0x66000)
+#define _CGM_PIPE_A_GAMMA (VLV_DISPLAY_BASE + 0x67000)
+#define _CGM_PIPE_A_MODE (VLV_DISPLAY_BASE + 0x67A00)
+#define CGM_PIPE_MODE_GAMMA (1 << 2)
+#define CGM_PIPE_MODE_CSC(1 << 1)
+#define CGM_PIPE_MODE_DEGAMMA(1 << 0)
+
+#define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900)
+#define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904)
+#define _CGM_PIPE_B_CSC_COEFF45(VLV_DISPLAY_BASE + 0x69908)
+#define _CGM_PIPE_B_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6990C)
+#define _CGM_PIPE_B_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x69910)
+#define _CGM_PIPE_B_DEGAMMA(VLV_DISPLAY_BASE + 0x68000)
+#define _CGM_PIPE_B_GAMMA (VLV_DISPLAY_BASE + 0x69000)
+#define _CGM_PIPE_B_MODE (VLV_DISPLAY_BASE + 0x69A00)
+
+#define CGM_PIPE_CSC_COEFF01(pipe) _MMIO_PIPE(pipe,
_CGM_PIPE_A_CSC_COEFF01, _CGM_PIPE_B_CSC_COEFF01)
+#define CGM_PIPE_CSC_COEFF23(pipe) _MMIO_PIPE(pipe,
_CGM_PIPE_A_CSC_COEFF23, _CGM_PIPE_B_CSC_COEFF23)
+#define CGM_PIPE_CSC_COEFF45(pipe) _MMIO_PIPE(pipe,
_CGM_PIPE_A_CSC_COEFF45, _CGM_PIPE_B_CSC_COEFF45)
+#define CGM_PIPE_CSC_COEFF67(pipe) _MMIO_PIPE(pipe,
_CGM_PIPE_A_CSC_COEFF67, _CGM_PIPE_B_CSC_COEFF67)
+#define CGM_PIPE_CSC_COEFF8(pipe) _MMIO_PIPE(pipe,
_CGM_PIPE_A_CSC_COEFF8, _CGM_PIPE_B_CSC_COEFF8)
+#define CGM_PIPE_DEGAMMA(pipe, i, w) _MMIO(_PIPE(pipe, _CGM_PIPE_A_DEGAMMA,
_CGM_PIPE_B_DEGAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_GAMMA(pipe, i, w) _MMIO(_PIPE(pipe, _CGM_PIPE_A_GAMMA,
_CGM_PIPE_B_GAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_MODE(pipe)_MMIO_PIPE(pipe, _CGM_PIPE_A_MODE,
_CGM_PIPE_B_MODE)
+
/* MIPI DSI registers */
#define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and C only */
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index c6340d8..aa0b20d 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -29,6 +29,7 @@
#define CTM_COEFF_1_0 (1ULL << 32)
#define CTM_COEFF_2_0 (CTM_COEFF_1_0 << 1)
#define CTM_COEFF_4_0 (CTM_COEFF_2_0 << 1)
+#define CTM_COEFF_8_0 (CTM_COEFF_4_0 << 1)
#define CTM_COEFF_0_5 (CTM_COEFF_1_0 >> 1)
#define CTM_COEFF_0_25 (CTM_COEFF_0_5 >> 1)
#define CTM_COEFF_0_125(CTM_COEFF_0_25 >> 1)
@@ -199,6 +200,58 @@ static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
}
}
+/*
+ * Set up the pipe CSC unit on CherryView.
+ */
+static void cherryview_load_csc_matrix(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_crtc_state *state = crtc->state;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ int pipe = to_intel_crtc(crtc)->pipe;
[Intel-gfx] [PATCH 0/4] Pipe level color management
This series introduces pipe level color management for Intel platforms on CherryView and Broadwell on. This series is based of a previous set of patches by Shashank Sharma. Cheers, Lionel v9: Rebase on nightly v10: Mask GAMMA_MODE register value (Matt Roper) Cleanup legacy LUT helper (Emil Velikov) v11: Rebase on drm-nightly Lionel Landwerlin (4): drm/i915: Extract out gamma table and CSC to their own file drm/i915: Do not read GAMMA_MODE register drm/i915: Implement color management on bdw/skl/bxt/kbl drm/i915: Implement color management on chv Documentation/DocBook/gpu.tmpl | 6 +- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/i915_drv.c | 27 +- drivers/gpu/drm/i915/i915_drv.h | 8 + drivers/gpu/drm/i915/i915_reg.h | 53 drivers/gpu/drm/i915/intel_color.c | 556 +++ drivers/gpu/drm/i915/intel_display.c | 184 +++- drivers/gpu/drm/i915/intel_drv.h | 12 + drivers/gpu/drm/i915/intel_fbdev.c | 8 + 9 files changed, 695 insertions(+), 160 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_color.c -- 2.7.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Do not read GAMMA_MODE register
Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.
v2: Read GAMMA_MODE register value at init (Matt Roper's comment)
v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
with other registers (Matt Roper's comment).
v4: Mask GAMMA_MODE register with interesting bits when reading
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_color.c | 7 +--
drivers/gpu/drm/i915/intel_display.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 35b7f62..16657eb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -121,6 +121,8 @@ static void haswell_load_luts(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *intel_crtc_state =
+ to_intel_crtc_state(crtc->state);
bool reenable_ips = false;
/*
@@ -128,11 +130,12 @@ static void haswell_load_luts(struct drm_crtc *crtc)
* GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
*/
if (IS_HASWELL(dev) && intel_crtc->config->ips_enabled &&
- ((I915_READ(GAMMA_MODE(intel_crtc->pipe)) & GAMMA_MODE_MODE_MASK) ==
-GAMMA_MODE_MODE_SPLIT)) {
+ (intel_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
hsw_disable_ips(intel_crtc);
reenable_ips = true;
}
+
+ intel_crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);
i9xx_load_luts(crtc);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 45c1ae6..fcfc71e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9843,6 +9843,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
intel_get_pipe_timings(crtc, pipe_config);
+ pipe_config->gamma_mode =
+ I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
+
if (INTEL_INFO(dev)->gen >= 9) {
skl_init_scalers(dev, crtc, pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ec4677a..5b97d4a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -576,6 +576,9 @@ struct intel_crtc_state {
*/
bool need_postvbl_update;
} wm;
+
+ /* Gamma mode programmed on the pipe */
+ uint32_t gamma_mode;
};
struct vlv_wm_state {
--
2.7.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: More intel_engine_cs renaming
From: Tvrtko Ursulin
Some trivial ones, first pass done with Coccinelle:
@@
@@
(
- I915_NUM_RINGS
+ I915_NUM_ENGINES
|
- intel_ring_flag
+ intel_engine_flag
|
- for_each_ring
+ for_each_engine
|
- i915_gem_request_get_ring
+ i915_gem_request_get_engine
|
- intel_ring_idle
+ intel_engine_idle
|
- i915_gem_reset_ring_status
+ i915_gem_reset_engine_status
|
- i915_gem_reset_ring_cleanup
+ i915_gem_reset_engine_cleanup
|
- init_ring_lists
+ init_engine_lists
)
But that didn't fully work so I cleaned it up with:
for f in *.[hc]; do sed -i -e s/I915_NUM_RINGS/I915_NUM_ENGINES/ $f; done
for f in *.[hc]; do sed -i -e
s/i915_gem_request_get_ring/i915_gem_request_get_engine/ $f; done
for f in *.[hc]; do sed -i -e s/intel_ring_flag/intel_engine_flag/ $f; done
for f in *.[hc]; do sed -i -e s/intel_ring_idle/intel_engine_idle/ $f; done
for f in *.[hc]; do sed -i -e s/init_ring_lists/init_engine_lists/ $f; done
for f in *.[hc]; do sed -i -e
s/i915_gem_reset_ring_cleanup/i915_gem_reset_engine_cleanup/ $f; done
for f in *.[hc]; do sed -i -e
s/i915_gem_reset_ring_status/i915_gem_reset_engine_status/ $f; done
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 52 ++---
drivers/gpu/drm/i915/i915_drv.h| 26 +--
drivers/gpu/drm/i915/i915_gem.c| 74 +++---
drivers/gpu/drm/i915/i915_gem_context.c| 16 +++
drivers/gpu/drm/i915/i915_gem_debug.c | 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++---
drivers/gpu/drm/i915/i915_guc_submission.c | 6 +--
drivers/gpu/drm/i915/i915_irq.c| 20
drivers/gpu/drm/i915/i915_trace.h | 6 +--
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 4 +-
drivers/gpu/drm/i915/intel_lrc.c | 12 ++---
drivers/gpu/drm/i915/intel_mocs.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c| 12 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c| 12 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h| 20
drivers/gpu/drm/i915/intel_uncore.c| 4 +-
19 files changed, 147 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a71ffaaf380d..dabce8403d56 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -143,7 +143,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
obj->base.size / 1024,
obj->base.read_domains,
obj->base.write_domain);
- for_each_ring(engine, dev_priv, i)
+ for_each_engine(engine, dev_priv, i)
seq_printf(m, "%x ",
i915_gem_request_get_seqno(obj->last_read_req[i]));
seq_printf(m, "] %x %x%s%s%s",
@@ -184,7 +184,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
}
if (obj->last_write_req != NULL)
seq_printf(m, " (%s)",
-
i915_gem_request_get_ring(obj->last_write_req)->name);
+
i915_gem_request_get_engine(obj->last_write_req)->name);
if (obj->frontbuffer_bits)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
}
@@ -402,7 +402,7 @@ static void print_batch_pool_stats(struct seq_file *m,
memset(&stats, 0, sizeof(stats));
- for_each_ring(engine, dev_priv, i) {
+ for_each_engine(engine, dev_priv, i) {
for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++)
{
list_for_each_entry(obj,
&engine->batch_pool.cache_list[j],
@@ -591,7 +591,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void
*data)
pipe, plane);
}
if (work->flip_queued_req) {
- struct intel_engine_cs *engine =
i915_gem_request_get_ring(work->flip_queued_req);
+ struct intel_engine_cs *engine =
i915_gem_request_get_engine(work->flip_queued_req);
seq_printf(m, "Flip queued on %s at seqno %x,
next seqno %x [current breadcrumb %x], completed? %d\n",
engine->name,
@@ -644,7 +644,7 @@ static int i915_gem_batch_pool_info(struct seq_file *m,
void *data)
if (ret)
return ret;
- for_each_ring(engine, dev_priv, i) {
+ for_each_engine(engine, dev_priv, i) {
for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++)
{
int count;
@@ -689,7 +689,7 @@ static int i915_gem_request_info(struct seq_file *m, void
*data)
return ret;
any = 0;
-
[Intel-gfx] [PATCH 5/5] drm/i915: More renaming of rings to engines
From: Tvrtko Ursulin
This time using only sed and a few by hand.
v2: Rename also intel_ring_id and intel_ring_initialized.
v3: Fixed typo in intel_ring_initialized.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_dma.c| 12 +++
drivers/gpu/drm/i915/i915_drv.h| 14 -
drivers/gpu/drm/i915/i915_gem.c| 50 +++---
drivers/gpu/drm/i915/i915_gem_debug.c | 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +--
drivers/gpu/drm/i915/i915_irq.c| 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 8 ++---
drivers/gpu/drm/i915/intel_mocs.c | 6 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c| 16 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 10 +++---
11 files changed, 63 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index dabce8403d56..1d8c3ef29318 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2483,7 +2483,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct intel_guc guc;
struct i915_guc_client client = {};
struct intel_engine_cs *engine;
- enum intel_ring_id i;
+ enum intel_engine_id i;
u64 total = 0;
if (!HAS_GUC_SCHED(dev_priv->dev))
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 19f605b0cd6d..85b31300103d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -87,16 +87,16 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = 1;
break;
case I915_PARAM_HAS_BSD:
- value = intel_ring_initialized(&dev_priv->engine[VCS]);
+ value = intel_engine_initialized(&dev_priv->engine[VCS]);
break;
case I915_PARAM_HAS_BLT:
- value = intel_ring_initialized(&dev_priv->engine[BCS]);
+ value = intel_engine_initialized(&dev_priv->engine[BCS]);
break;
case I915_PARAM_HAS_VEBOX:
- value = intel_ring_initialized(&dev_priv->engine[VECS]);
+ value = intel_engine_initialized(&dev_priv->engine[VECS]);
break;
case I915_PARAM_HAS_BSD2:
- value = intel_ring_initialized(&dev_priv->engine[VCS2]);
+ value = intel_engine_initialized(&dev_priv->engine[VCS2]);
break;
case I915_PARAM_HAS_RELAXED_FENCING:
value = 1;
@@ -444,7 +444,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
cleanup_gem:
mutex_lock(&dev->struct_mutex);
- i915_gem_cleanup_ringbuffer(dev);
+ i915_gem_cleanup_engines(dev);
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
cleanup_irq:
@@ -1261,7 +1261,7 @@ int i915_driver_unload(struct drm_device *dev)
intel_guc_ucode_fini(dev);
mutex_lock(&dev->struct_mutex);
- i915_gem_cleanup_ringbuffer(dev);
+ i915_gem_cleanup_engines(dev);
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db999c24c192..fd1ed66dd298 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1931,9 +1931,9 @@ struct drm_i915_private {
int (*execbuf_submit)(struct i915_execbuffer_params *params,
struct drm_i915_gem_execbuffer2 *args,
struct list_head *vmas);
- int (*init_rings)(struct drm_device *dev);
- void (*cleanup_ring)(struct intel_engine_cs *ring);
- void (*stop_ring)(struct intel_engine_cs *ring);
+ int (*init_engines)(struct drm_device *dev);
+ void (*cleanup_engine)(struct intel_engine_cs *engine);
+ void (*stop_engine)(struct intel_engine_cs *engine);
} gt;
struct intel_context *kernel_context;
@@ -1969,7 +1969,7 @@ static inline struct drm_i915_private *guc_to_i915(struct
intel_guc *guc)
/* Iterate over initialised rings */
#define for_each_engine(ring__, dev_priv__, i__) \
for ((i__) = 0; (i__) < I915_NUM_ENGINES; (i__)++) \
- for_each_if ring__) = &(dev_priv__)->engine[(i__)]),
intel_ring_initialized((ring__
+ for_each_if ring__) = &(dev_priv__)->engine[(i__)]),
intel_engine_initialized((ring__
enum hdmi_force_audio {
HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
@@ -2039,7 +2039,7 @@ struct drm_i915_gem_object {
struct drm_mm_node *stolen;
struct list_head global_list;
- struct list_head ring_list[I915_NUM_ENGINES];
+ struct list_head engine_list[
[Intel-gfx] [PATCH 3/5] drm/i915: Rename intel_engine_cs struct members
From: Tvrtko Ursulin
From ring to engine, by the virtue of Coccinelle patch
below and a couple manual fixups.
@@
identifier I, J;
@@
struct I {
...
- struct intel_engine_cs *J;
+ struct intel_engine_cs *engine;
...
}
@@
identifier I, J;
@@
struct I {
...
- struct intel_engine_cs J;
+ struct intel_engine_cs engine;
...
}
@@
struct drm_i915_private *d;
@@
(
- d->ring
+ d->engine
)
@@
struct i915_execbuffer_params *p;
@@
(
- p->ring
+ p->engine
)
@@
struct intel_ringbuffer *r;
@@
(
- r->ring
+ r->engine
)
@@
struct drm_i915_gem_request *req;
@@
(
- req->ring
+ req->engine
)
v2: Script missed the tracepoint code - fixed up by hand.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 8 +--
drivers/gpu/drm/i915/i915_drv.h | 18 +++
drivers/gpu/drm/i915/i915_gem.c | 38 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 24 -
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 24 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++---
drivers/gpu/drm/i915/i915_gem_render_state.c | 6 +--
drivers/gpu/drm/i915/i915_gpu_error.c| 18 +++
drivers/gpu/drm/i915/i915_guc_submission.c | 9 ++--
drivers/gpu/drm/i915/i915_irq.c | 40 +++
drivers/gpu/drm/i915/i915_trace.h| 46 -
drivers/gpu/drm/i915/intel_display.c | 18 +++
drivers/gpu/drm/i915/intel_lrc.c | 76 ++--
drivers/gpu/drm/i915/intel_mocs.c| 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 8 +--
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 74 +--
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
19 files changed, 215 insertions(+), 214 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 164e1432d41f..a71ffaaf380d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -984,7 +984,7 @@ static int i915_hws_info(struct seq_file *m, void *data)
const u32 *hws;
int i;
- engine = &dev_priv->ring[(uintptr_t)node->info_ent->data];
+ engine = &dev_priv->engine[(uintptr_t)node->info_ent->data];
hws = engine->status_page.page_addr;
if (hws == NULL)
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4aa3db61a535..19f605b0cd6d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -87,16 +87,16 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = 1;
break;
case I915_PARAM_HAS_BSD:
- value = intel_ring_initialized(&dev_priv->ring[VCS]);
+ value = intel_ring_initialized(&dev_priv->engine[VCS]);
break;
case I915_PARAM_HAS_BLT:
- value = intel_ring_initialized(&dev_priv->ring[BCS]);
+ value = intel_ring_initialized(&dev_priv->engine[BCS]);
break;
case I915_PARAM_HAS_VEBOX:
- value = intel_ring_initialized(&dev_priv->ring[VECS]);
+ value = intel_ring_initialized(&dev_priv->engine[VECS]);
break;
case I915_PARAM_HAS_BSD2:
- value = intel_ring_initialized(&dev_priv->ring[VCS2]);
+ value = intel_ring_initialized(&dev_priv->engine[VCS2]);
break;
case I915_PARAM_HAS_RELAXED_FENCING:
value = 1;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8d87242ce601..0187a560aa51 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1652,7 +1652,7 @@ struct i915_execbuffer_params {
uint32_tdispatch_flags;
uint32_targs_batch_start_offset;
uint64_tbatch_obj_vm_offset;
- struct intel_engine_cs *ring;
+ struct intel_engine_cs *engine;
struct drm_i915_gem_object *batch_obj;
struct intel_context*ctx;
struct drm_i915_gem_request *request;
@@ -1704,7 +1704,7 @@ struct drm_i915_private {
wait_queue_head_t gmbus_wait_queue;
struct pci_dev *bridge_dev;
- struct intel_engine_cs ring[I915_NUM_RINGS];
+ struct intel_engine_cs engine[I915_NUM_RINGS];
struct drm_i915_gem_object *semaphore_obj;
uint32_t last_seqno, next_seqno;
@@ -1969,7 +1969,7 @@ static inline struct drm_i915_private *guc_to_i915(struct
intel_guc *guc)
/* Iterate over initialised rings */
#define for_each_ring(ring__, dev_priv__, i__) \
for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
- for_each_if ring__) = &(dev_priv__)->ring[(i__)]),
intel_ring_initialized((ring__
+
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave, I'll just flush this one out of the way. BR, Jani. The following changes since commit f2c488212b511f7eadef78c564f1bff8f64db231: Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-next (2016-03-14 10:49:40 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2016-03-16 for you to fetch changes up to 94669e6ba1ada133394ec8295d773df8b9238d08: drm/i915: Handle -EDEADLK in drm_atomic_commit from load-detect. (2016-03-14 10:50:58 +0200) Maarten Lankhorst (1): drm/i915: Handle -EDEADLK in drm_atomic_commit from load-detect. drivers/gpu/drm/i915/intel_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: More renaming of rings to engines
On Wed, Mar 16, 2016 at 11:00:40AM +, Tvrtko Ursulin wrote:
> if (!i915.enable_execlists) {
> dev_priv->gt.execbuf_submit = i915_gem_ringbuffer_submission;
> - dev_priv->gt.init_rings = i915_gem_init_rings;
> - dev_priv->gt.cleanup_ring = intel_cleanup_ring_buffer;
> - dev_priv->gt.stop_ring = intel_stop_ring_buffer;
> + dev_priv->gt.init_engines = i915_gem_init_engines;
> + dev_priv->gt.cleanup_engine = intel_cleanup_engine;
> + dev_priv->gt.stop_engine = intel_stop_engine;
> } else {
> dev_priv->gt.execbuf_submit = intel_execlists_submission;
> - dev_priv->gt.init_rings = intel_logical_rings_init;
> - dev_priv->gt.cleanup_ring = intel_logical_ring_cleanup;
> - dev_priv->gt.stop_ring = intel_logical_ring_stop;
> + dev_priv->gt.init_engines = intel_logical_rings_init;
> + dev_priv->gt.cleanup_engine = intel_logical_ring_cleanup;
> + dev_priv->gt.stop_engine = intel_logical_ring_stop;
Missing the lrc engines
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1369,7 +1369,7 @@ eb_get_batch(struct eb_vmas *eb)
>
> #define I915_USER_RINGS (4)
>
> -static const enum intel_ring_id user_ring_map[I915_USER_RINGS + 1] = {
> +static const enum intel_engine_id user_ring_map[I915_USER_RINGS + 1] = {
> [I915_EXEC_DEFAULT] = RCS,
> [I915_EXEC_RENDER] = RCS,
> [I915_EXEC_BLT] = BCS,
Now user engines;
> @@ -1417,7 +1417,7 @@ eb_select_ring(struct drm_i915_private *dev_priv,
select_engine
Haven't looked outside of the patches for missing changes, but they will
stand out as we update the code nevertheless.
Do it, do it now.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
