Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 17 Aug 2022 16:05:13 +0300
From:   Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
To:     Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc:     Karol Herbst <kherbst@redhat.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        David Airlie <airlied@linux.ie>,
        intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org, rodrigo.vivi@intel.com,
        Zenghui Yu <yuzenghui@huawei.com>,
        Imre Deak <imre.deak@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when
 it's supported
Message-ID: <YvzniYpjr+PBIa56@intel.com>
References: <20220816025217.618181-1-kai.heng.feng@canonical.com>
 <CACO55tt=Op=0E94kK+1M8cDXNCk5Tkc=FMR8=OQFc5ohehjwaw@mail.gmail.com>
 <CAAd53p49X95MKrTDUq92LuHw3y2i09fUA2HEPzM1EcO8xO97Eg@mail.gmail.com>
 <CACO55tvgmb4Vog701idDYGuh125S9mjWPXhftxDMZ7hg-nQXBw@mail.gmail.com>
 <CAAd53p4W9rjmVJcUasy9hb1Yam+846+Oomvc2r9RMNmWeh_=0w@mail.gmail.com>
 <YvzYGGXils/Gf44d@intel.com>
 <CAAd53p49zc2G1KutPMUcUBM3_rbCh9_40e0mdtcZKb+C69QL_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAd53p49zc2G1KutPMUcUBM3_rbCh9_40e0mdtcZKb+C69QL_Q@mail.gmail.com>
Precedence: bulk

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@linux.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