lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YvzniYpjr+PBIa56@intel.com>
Date:   Wed, 17 Aug 2022 16:05:13 +0300
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     Karol Herbst <kherbst@...hat.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        David Airlie <airlied@...ux.ie>,
        intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, rodrigo.vivi@...el.com,
        Zenghui Yu <yuzenghui@...wei.com>,
        Imre Deak <imre.deak@...el.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when
 it's supported

On Wed, Aug 17, 2022 at 08:15:58PM +0800, Kai-Heng Feng wrote:
> On Wed, Aug 17, 2022 at 7:59 PM Ville Syrjälä
> <ville.syrjala@...ux.intel.com> wrote:
> 
> [snipped]
> 
> > I had a quick trawl through some Windows stuff for this and
> > it does seem to do a few extra checks:
> > - platform must be TGL-H (nothing else has the DPin stuff I guess)
> > - OpRegion header must indicate dGPU presence
> 
> Is the dGPU presence denoted by the return bitmask of
> INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED

No, there are apparently some extra bits in the OpRegion
header which we're not currently even decoding.

> 
> IIUC the mask 20 won't be set when dGPU is not present.

Not sure whether that bit would change depending on the dGPU
presence or not. Windows doesn't seem trust it alone, so either
it won't change or someone was just extra paranoid.

> 
> >
> > Otherwise it does call this DSM uncoditionally on boot/S4 resume
> > so seems like that is the only really validated configuration.
> > Although it does seem to explicitly turn off displays prior to
> > the DSM so that does perhaps indicate that those ports might have
> > also been enabled via the iGPU by the BIOS. Not sure if disabling
> > the ports would work correctly after the DSM or not. If not then
> > the DSM call would need to happen after state readout/sanitization
> > so that we can shut things down gracefully.
> >
> > Additionally after the DSM call it scans the FIA TC live state
> > bits to check for DPin usage. Looks like its trying to make sure
> > the driver stops poking at the relevant power wells once in DPin
> > mode. i915 doesn't check that stuff atm so we might end up
> > mangling something while the dGPU is driving the port.
> 
> Thanks for investigating this. I am not really familiar with other
> stuffs you mentioned, but I am happy to test any follow-up patch.
> 
> Kai-Heng
> 
> >
> > --
> > Ville Syrjälä
> > Intel

-- 
Ville Syrjälä
Intel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ