From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
"Runyan, Arthur J" <arthur.j.runyan@intel.com>
Subject: Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW
Date: Mon, 24 Aug 2020 21:04:38 +0300 [thread overview]
Message-ID: <20200824180438.GI6112@intel.com> (raw)
In-Reply-To: <30685BA7-1D02-48A0-9B7A-4933ED2B8F0D@canonical.com>
On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
>
>
> > On Aug 17, 2020, at 00:22, Runyan, Arthur J <arthur.j.runyan@intel.com> wrote:
> >
> > You'll need to read out the DDI_BUF_TRANS_* and DISPIO_CR_TX_BMU_CR0 registers at boot before i915 programs them and compare with what driver programs.
> > Rodrigo can probably show you how.
>
> Right, I'll wait for a patch then :)
To grab the BIOS reg values we just have to make sure the driver
doesn't load. Eg. pass something like
"modprobe.blacklist=i915,snd_hda_intel 3" to the kernel cmdline
(+ whatever other magic ubuntu might require). Confirm with
something like "lsmod | grep i915" to make sure the driver didn't
sneak in despite our best efforts.
Then we can dump the registers with intel_reg from igt-gpu-tools:
intel_reg read --count 20 0x64E00 0x64E60 0x64EC0 0x64F20 0x64F80
intel_reg read 0x64000 0x64100 0x64200 0x64300 0x64400 0x6C00C
The only somewhat suspicious thing I noticed is that we treat
DISPIO_CR_TX_BMU_CR0:tx_blnclegdisbl as a bitmask (bit 23 -> DDI A,
bit 24 -> DDI B, etc.) whereas the spec seems to be saying that we
should just zero out all the bits of tx_blnclegdisbl when any DDI
needs iboost. Art, is our interpretation of the bits correct or just
a fairy tale?
>
> Kai-Heng
>
> >
> > -----Original Message-----
> > From: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > Sent: Thursday, August 13, 2020 10:14 PM
> > To: Runyan, Arthur J <arthur.j.runyan@intel.com>
> > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Ville Syrjälä <ville.syrjala@linux.intel.com>; intel-gfx <intel-gfx@lists.freedesktop.org>
> > Subject: Re: [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW
> >
> > Hi,
> >
> >> On Aug 14, 2020, at 01:56, Runyan, Arthur J <arthur.j.runyan@intel.com> wrote:
> >>
> >> The workaround is freeing up stuck vswing values to let new vswing programming kick in. Maybe the new vswing values are wrong.
> >> Try checking the vswing that driver programs against what BIOS/GOP programs.
> >
> > Do you mean to print out value of I915_READ()?
> > val = I915_READ(CHICKEN_TRANS(transcoder));
> >
> > Kai-Heng
> >
> >>
> >> -----Original Message-----
> >> From: Vivi, Rodrigo <rodrigo.vivi@intel.com>
> >> Sent: Thursday, August 13, 2020 9:50 AM
> >> To: Kai-Heng Feng <kai.heng.feng@canonical.com>; Runyan, Arthur J
> >> <arthur.j.runyan@intel.com>
> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; intel-gfx
> >> <intel-gfx@lists.freedesktop.org>
> >> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143"
> >> breaks HDMI on ASUS GL552VW
> >>
> >> Art, any comment here?
> >>
> >> I just checked and the W/a 1143 is implemented as described, but it is failing HDMI on this hybrid system.
> >>
> >>> On Aug 12, 2020, at 9:07 PM, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> There's a regression reported that HDMI output stops working after os upgrade:
> >>> https://bugs.launchpad.net/bugs/1871721
> >>>
> >>> Here's the bisect result:
> >>> 0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit
> >>> commit 0519c102f5285476d7868a387bdb6c58385e4074
> >>> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> Date: Mon Jan 22 19:41:31 2018 +0200
> >>>
> >>> drm/i915: Implement display w/a #1143
> >>>
> >>> Apparently SKL/KBL/CFL need some manual help to get the
> >>> programmed HDMI vswing to stick. Implement the relevant
> >>> workaround (display w/a #1143).
> >>>
> >>> Note that the relevant chicken bits live in a transcoder register
> >>> even though the bits affect a specific DDI port rather than a
> >>> specific transcoder. Hence we must pick the correct transcoder
> >>> register instance based on the port rather than based on the
> >>> cpu_transcoder.
> >>>
> >>> Also note that for completeness I included support for DDI A/E
> >>> in the code even though we never have HDMI on those ports.
> >>>
> >>> v2: CFL needs the w/a as well (Rodrigo and Art)
> >>>
> >>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>> Cc: Art Runyan <arthur.j.runyan@intel.com>
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> Link: https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrjala@linux.intel.com
> >>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>>
> >>>
> >>> dmesg from drm-tip with drm.debug=0xe can be found here:
> >>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments
> >>> /
> >>> 64
> >>>
> >>> Kai-Heng
> >>
> >>
> >
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-08-24 18:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 4:07 [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW Kai-Heng Feng
2020-08-13 16:50 ` Vivi, Rodrigo
2020-08-13 17:56 ` Runyan, Arthur J
2020-08-14 5:13 ` Kai-Heng Feng
2020-08-16 16:22 ` Runyan, Arthur J
2020-08-17 6:17 ` Kai-Heng Feng
2020-08-24 18:04 ` Ville Syrjälä [this message]
2020-08-24 18:46 ` Runyan, Arthur J
2020-08-26 4:40 ` Kai-Heng Feng
2020-08-26 13:05 ` Ville Syrjälä
2020-09-03 6:26 ` Kai-Heng Feng
2020-10-13 5:20 ` Kai-Heng Feng
2020-10-13 11:15 ` Ville Syrjälä
2020-10-13 11:50 ` Saarinen, Jani
2020-10-13 12:18 ` Kai-Heng Feng
2020-10-13 12:25 ` Saarinen, Jani
2021-04-07 14:34 ` Rodrigo Vivi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200824180438.GI6112@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=arthur.j.runyan@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kai.heng.feng@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.