== Series Details ==
Series: drm/i915: Failsafe migration blits (rev3)
URL : https://patchwork.freedesktop.org/series/95617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10826 -> Patchwork_21501
Summary
---
**SUCCES
> -Original Message-
> From: Nikula, Jani
> Sent: Monday, November 1, 2021 5:37 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> ; ville.syrj...@linux.intel.com
> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy
== Series Details ==
Series: drm/i915: Failsafe migration blits (rev3)
URL : https://patchwork.freedesktop.org/series/95617/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5fe248ea3330 drm/i915/ttm: Reorganize the ttm move code
-:510: WARNING:FILE_PATH_CHANGES: added, moved or d
On Mon, 2021-10-25 at 12:04 +0300, Jani Nikula wrote:
> On Fri, 22 Oct 2021, Lucas De Marchi wrote:
> > On Thu, Oct 21, 2021 at 04:11:26PM +0300, Jani Nikula wrote:
> > > On Wed, 20 Oct 2021, "Souza, Jose" wrote:
> > > > On Wed, 2021-10-20 at 12:47 +0300, Jani Nikula wrote:
> > > > > On Tue, 19 O
== Series Details ==
Series: drm/i915/display: Exit PSR when doing async flips (rev3)
URL : https://patchwork.freedesktop.org/series/96440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10825_full -> Patchwork_21500_full
Su
> -Original Message-
> From: Navare, Manasi D
> Sent: Tuesday, November 2, 2021 10:11 AM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
>
> On Mon, Nov 01, 2021 at 09:45:23AM -0700, Kulka
On Mon, Nov 01, 2021 at 09:45:23AM -0700, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Navare, Manasi D
> > Sent: Saturday, October 30, 2021 4:43 AM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > Subject: Re: [PATCH] drm/i915/dsc: Fix the
== Series Details ==
Series: drm/i915/guc/slpc: Implement waitboost for SLPC (rev3)
URL : https://patchwork.freedesktop.org/series/96082/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10825_full -> Patchwork_21499_full
Summ
== Series Details ==
Series: drm/i915/display: Exit PSR when doing async flips (rev3)
URL : https://patchwork.freedesktop.org/series/96440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10825 -> Patchwork_21500
Summary
== Series Details ==
Series: drm/i915: Failsafe migration blits (rev2)
URL : https://patchwork.freedesktop.org/series/95617/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10825_full -> Patchwork_21498_full
Summary
---
Changing the buffer in the middle of the scanout then entering an
period of flip idleness will cause part of the previous buffer being
diplayed to user when PSR is enabled.
So here disabling and scheduling activation after a few milliseconds
when async flip is enabled in the state.
The async flip
== Series Details ==
Series: drm/i915/guc/slpc: Implement waitboost for SLPC (rev3)
URL : https://patchwork.freedesktop.org/series/96082/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10825 -> Patchwork_21499
Summary
--
On Mon, 01 Nov 2021 18:26:05 -0700, Vinay Belgaumkar wrote:
>
> Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
> patch set implements it for the SLPC path. A boost can happen when a request
> is waiting for an unmet dependency. GT frequency gets temporarily bumped to
>
== Series Details ==
Series: drm/i915/guc/slpc: Implement waitboost for SLPC (rev3)
URL : https://patchwork.freedesktop.org/series/96082/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3b5f16b5d3d0 drm/i915/guc/slpc: Define and initialize boost frequency
-:13: WARNING:TYPO_SPELL
Add a helper to sort through the SLPC/RPS paths of get/set methods.
Boost frequency will be modified as long as it is within the constraints
of RP0 and if it is different from the existing one. We will set min
freq to boost only if there is at least one active waiter.
v2: Add num_boosts to guc_slp
Add helper in RPS code for handling SLPC and non-SLPC paths.
When boost is requested in the SLPC path, we can ask GuC to ramp
up the frequency req by setting the minimum frequency to boost freq.
Reset freq back to the min softlimit when there are no more waiters.
v2: Schedule a worker thread which
Define helpers and struct members required to record boost info.
Boost frequency is initialized to RP0 at SLPC init. Also define num_waiters
which can track the pending boost requests.
Boost will be done by scheduling a worker thread. This will avoid
the need to make H2G calls inside an interrupt
Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
patch set implements it for the SLPC path. A boost can happen when a request
is waiting for an unmet dependency. GT frequency gets temporarily bumped to
boost freq to allow the previous request to finish quickly. We achieve
On 11/1/2021 1:26 PM, Dixit, Ashutosh wrote:
On Sun, 31 Oct 2021 21:39:35 -0700, Belgaumkar, Vinay wrote:
Define helpers and struct members required to record boost info.
Boost frequency is initialized to RP0 at SLPC init. Also define num_waiters
which can track the pending boost requests.
On 11/1/2021 1:28 PM, Dixit, Ashutosh wrote:
On Sun, 31 Oct 2021 21:39:36 -0700, Belgaumkar, Vinay wrote:
@@ -945,6 +960,17 @@ void intel_rps_boost(struct i915_request *rq)
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
struct intel_rps *rps = &READ
On 11/1/2021 1:24 PM, Dixit, Ashutosh wrote:
On Sun, 31 Oct 2021 21:39:34 -0700, Belgaumkar, Vinay wrote:
Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
patch set implements it for the SLPC path. A "boost" happens when user
calls gem_wait ioctl on a submission th
Hi Matt and Michal,
On Thu, Oct 28, 2021 at 08:28:16PM -0700, Matt Roper wrote:
> From: Michal Wajdeczko
>
> Update CT debug macros by including tile ID in all messages.
>
> Cc: Michał Winiarski
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
Andi
Hi Matt and Paulo,
> @@ -2771,40 +2771,45 @@ static inline void dg1_master_intr_enable(void
> __iomem * const regs)
> static irqreturn_t dg1_irq_handler(int irq, void *arg)
> {
> struct drm_i915_private * const i915 = arg;
> + void __iomem * const t0_regs = i915->gt.uncore->regs;
>
== Series Details ==
Series: series starting with [1/2] drm/i915: Factor out
i915_ggtt_suspend_vm/i915_ggtt_resume_vm()
URL : https://patchwork.freedesktop.org/series/96467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10824_full -> Patchwork_21497_full
=
Hi Matt,
> +static int
> +intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
> phys_addr)
I have already r-b this, but, as I commented in patch 5, 'id' is
redundant. Can we remove it?
Andi
> +{
> + int ret;
> +
> + intel_uncore_init_early(gt->uncore, gt->i915);
> +
>
Hi Matt and Tvrtko,
[...]
> static int
> intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
> phys_addr)
we don't actually need 'id', it's gt->info.id. It's introduced in
patch 3 with the value '0' but it's not needed.
> {
> + struct drm_i915_private *i915 = gt->i915;
== Series Details ==
Series: drm/i915: Failsafe migration blits (rev2)
URL : https://patchwork.freedesktop.org/series/95617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10825 -> Patchwork_21498
Summary
---
**SUCCES
Hi Matt,
On Thu, Oct 28, 2021 at 08:28:10PM -0700, Matt Roper wrote:
> On a multi-tile platform, each tile has its own registers + GGTT space,
> and BAR 0 is extended to cover all of them. Upcoming patches will start
> exposing the tiles as multiple GTs within a single PCI device. In
> preparati
== Series Details ==
Series: drm/i915/display: Exit PSR when doing async flips (rev2)
URL : https://patchwork.freedesktop.org/series/96440/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10824_full -> Patchwork_21496_full
Su
== Series Details ==
Series: drm/i915: Failsafe migration blits (rev2)
URL : https://patchwork.freedesktop.org/series/95617/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b8b912b983e0 drm/i915/ttm: Reorganize the ttm move code
-:510: WARNING:FILE_PATH_CHANGES: added, moved or d
Hi Ville,
>
> On Fri, Oct 29, 2021 at 12:43:03AM -0700, Vivek Kasireddy wrote:
> > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> > more framebuffers/scanout buffers results in only one that is mappable/
> > fenceable. Therefore, pageflipping between these 2 FBs where onl
Hi Tvrtko,
> On 29/10/2021 08:43, Vivek Kasireddy wrote:
> > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> > more framebuffers/scanout buffers results in only one that is mappable/
> > fenceable. Therefore, pageflipping between these 2 FBs where only one
> > is mappable/f
On Sun, 31 Oct 2021 21:39:37 -0700, Belgaumkar, Vinay wrote:
>
> +static int set_boost_freq(struct intel_rps *rps, u32 val)
Since this is legacy rps code path maybe change function name to
rps_set_boost_freq?
On Fri, Oct 29, 2021 at 05:18:01PM -0700, José Roberto de Souza wrote:
> Changing the buffer in the middle of the scanout then entering an
> period of flip idleness will cause part of the previous buffer being
> diplayed to user when PSR is enabled.
>
> So here disabling and scheduling activation
On Mon, 2021-11-01 at 16:36 -0400, Rodrigo Vivi wrote:
> On Fri, Oct 29, 2021 at 05:18:01PM -0700, José Roberto de Souza wrote:
> > Changing the buffer in the middle of the scanout then entering an
> > period of flip idleness will cause part of the previous buffer being
> > diplayed to user when PS
== Series Details ==
Series: series starting with [1/2] drm/i915: Factor out
i915_ggtt_suspend_vm/i915_ggtt_resume_vm()
URL : https://patchwork.freedesktop.org/series/96467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10824 -> Patchwork_21497
===
On Sun, 31 Oct 2021 21:39:36 -0700, Belgaumkar, Vinay wrote:
>
> @@ -945,6 +960,17 @@ void intel_rps_boost(struct i915_request *rq)
> if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
> struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
>
> + if
On Sun, 31 Oct 2021 21:39:35 -0700, Belgaumkar, Vinay wrote:
>
> Define helpers and struct members required to record boost info.
> Boost frequency is initialized to RP0 at SLPC init. Also define num_waiters
> which can track the pending boost requests.
>
> Boost will be done by scheduling a worker
On Sun, 31 Oct 2021 21:39:34 -0700, Belgaumkar, Vinay wrote:
>
> Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
> patch set implements it for the SLPC path. A "boost" happens when user
> calls gem_wait ioctl on a submission that has not landed on HW yet.
Afaiu user doe
== Series Details ==
Series: series starting with [1/2] drm/i915: Factor out
i915_ggtt_suspend_vm/i915_ggtt_resume_vm()
URL : https://patchwork.freedesktop.org/series/96467/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won
== Series Details ==
Series: drm/i915/display: Exit PSR when doing async flips (rev2)
URL : https://patchwork.freedesktop.org/series/96440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10824 -> Patchwork_21496
Summary
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason[1], and we then set up
either GPU- or CPU ptes to the allocated LMEM, we can expose old
contents from other clients.
So aft
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async callback that checks the
blit fence for errors and if there are errors perform
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move code out and since we will have to change the
Factor out functions that are needed by the next patch to suspend/resume
the memory mappings for DPT FBs.
No functional change, except reordering during suspend the
ggtt->invalidate(ggtt) call wrt. atomic_set(&ggtt->vm.open, open) and
mutex_unlock(&ggtt->vm.mutex). This shouldn't matter due to the
At least during hibernation the DPT mappings are lost with all stolen
memory content, so suspend/resume these mappings similarly to GGTT
mappings.
This fixes a problem where the restoring modeset during system resume fails
with pipe faults if a tiled framebuffer was active before suspend.
Cc: Chr
On Mon, 2021-11-01 at 12:11 +0200, Ville Syrjälä wrote:
> On Fri, Oct 29, 2021 at 09:57:02PM +, Souza, Jose wrote:
> > On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Prepare for per-lane drive settings by querying the desired vswing
> > > level p
On Sat, 2021-10-30 at 07:44 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/display: Check async flip state of every crtc and
> plane once (rev2)
> URL: https://patchwork.freedesktop.org/series/96402/
> State:success
> Details:
> https://intel-gfx-ci.01.org/tree/dr
> -Original Message-
> From: Navare, Manasi D
> Sent: Saturday, October 30, 2021 4:43 AM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
>
> On Wed, Oct 27, 2021 at 09:37:10PM -0700, Kulka
== Series Details ==
Series: drm/i915: Introduce refcounted sg-tables
URL : https://patchwork.freedesktop.org/series/96459/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10822_full -> Patchwork_21495_full
Summary
---
I didn't notice anything nag worthy, entire set look ok to me.
Reviewed-by: Juha-Pekka Heikkila
On 27.10.2021 1.50, Imre Deak wrote:
This patchset removes the CCS FB stride restrictions on ADLP. This makes
the uAPI for these FBs (via CCS modifiers) match the TGL one.
It also fixes a few issue
Hi,
On 11/1/21 15:50, Tvrtko Ursulin wrote:
On 01/11/2021 13:51, Thomas Hellström wrote:
Hi, Tvrtko
On Mon, 2021-11-01 at 13:14 +, Tvrtko Ursulin wrote:
On 01/11/2021 12:24, Thomas Hellström wrote:
As we start to introduce asynchronous failsafe object migration,
where we update the obj
writes:
> From: Rodrigo Vivi
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to consolidate
> the data into GuC i
On 01/11/2021 13:51, Thomas Hellström wrote:
Hi, Tvrtko
On Mon, 2021-11-01 at 13:14 +, Tvrtko Ursulin wrote:
On 01/11/2021 12:24, Thomas Hellström wrote:
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
comman
Reviewed-by: Caz Yokoyama
-caz
On Thu, 2021-10-28 at 21:08 +, Souza, Jose wrote:
> Reviewed-by: Caz Yokoyama
== Series Details ==
Series: drm/i915: Introduce refcounted sg-tables
URL : https://patchwork.freedesktop.org/series/96459/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10822 -> Patchwork_21495
Summary
---
**SUCCESS
Hi, Tvrtko
On Mon, 2021-11-01 at 13:14 +, Tvrtko Ursulin wrote:
>
> On 01/11/2021 12:24, Thomas Hellström wrote:
> > As we start to introduce asynchronous failsafe object migration,
> > where we update the object state and then submit asynchronous
> > commands we need to record what memory re
On 01/11/2021 12:24, Thomas Hellström wrote:
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for thr
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for three purposes:
1) Error capture.
2) Asynchronous m
Hi,
On Wed, Oct 27, 2021 at 06:06:28PM +0300, Jani Nikula wrote:
> On Sat, 23 Oct 2021, Len Baker wrote:
> > Sorry, but I'm missing something here. In linux-next this is the commit
> > history of include/linux/stddef.h file:
> >
> > 3080ea5553cc stddef: Introduce DECLARE_FLEX_ARRAY() helper
> > 5
On Thu, Oct 28, 2021 at 10:32:25PM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915/display/dmc: Add Support for PipeC and PipeD DMC (rev2)
> URL : https://patchwork.freedesktop.org/series/95532/
> State : success
Thanks for the patch, pushed to drm-intel-next.
>
> == Summary =
On Thu, 28 Oct 2021, "Kulkarni, Vandita" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Thursday, October 28, 2021 8:06 PM
>> To: Kulkarni, Vandita ; intel-
>> g...@lists.freedesktop.org
>> Cc: Deak, Imre ; Roper, Matthew D
>> ; ville.syrj...@linux.intel.com
>> Subject: RE: [
On Fri, 29 Oct 2021 at 09:22, Thomas Hellström
wrote:
>
> As we start to introduce asynchronous failsafe object migration,
> where we update the object state and then submit asynchronous
> commands we need to record what memory resources are actually used
> by various part of the command stream. I
On Fri, Oct 29, 2021 at 01:24:32PM -0700, José Roberto de Souza wrote:
> For every crtc in state, intel_atomic_check_async() was checking all
> the crtc and plane states again.
>
> v2: comparing pipe ids instead of crtc pointers when iterating over
> planes
>
> Cc: Karthik B S
> Cc: Vandita Kulk
On 01/11/2021 10:40, Joonas Lahtinen wrote:
Quoting Tvrtko Ursulin (2021-11-01 12:15:19)
On 25/10/2021 05:26, Cooper Chiou wrote:
This implements WaProgramMgsrForCorrectSliceSpecificMmioReads which
was omitted by mistake from Gen9 documentation, while it is actually
applicable to fused off p
Quoting Tvrtko Ursulin (2021-11-01 12:15:19)
>
> On 25/10/2021 05:26, Cooper Chiou wrote:
> > This implements WaProgramMgsrForCorrectSliceSpecificMmioReads which
> > was omitted by mistake from Gen9 documentation, while it is actually
> > applicable to fused off parts.
> >
> > Workaround consists
On Fri, Oct 29, 2021 at 12:43:03AM -0700, Vivek Kasireddy wrote:
> On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> more framebuffers/scanout buffers results in only one that is mappable/
> fenceable. Therefore, pageflipping between these 2 FBs where only one
> is mappable/fe
On 27/10/2021 21:10, Matthew Brost wrote:
On Wed, Oct 27, 2021 at 01:04:49PM -0700, John Harrison wrote:
On 10/27/2021 12:17, Matthew Brost wrote:
On Tue, Oct 26, 2021 at 02:58:00PM -0700, John Harrison wrote:
On 10/20/2021 14:47, Matthew Brost wrote:
A weak implementation of parallel submi
On Mon, 28 Jun 2021, Madhumitha Tolakanahalli Pradeep
wrote:
> PCH display HPD IRQ is not detected with default filter value.
> So, PP_CONTROL is manually reprogrammed.
Returning to this workaround.
You're not supposed to enable the workaround when there's eDP
connected. This is also crucial in
On 25/10/2021 05:26, Cooper Chiou wrote:
This implements WaProgramMgsrForCorrectSliceSpecificMmioReads which
was omitted by mistake from Gen9 documentation, while it is actually
applicable to fused off parts.
Workaround consists of making sure MCR packet control register is
programmed to point
On 29/10/2021 08:43, Vivek Kasireddy wrote:
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies
On Fri, Oct 29, 2021 at 09:57:02PM +, Souza, Jose wrote:
> On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Prepare for per-lane drive settings by querying the desired vswing
> > level per-lane.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers
On Fri, Oct 29, 2021 at 09:59:11PM +, Souza, Jose wrote:
> On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Prepare for per-lane drive settings by querying the desired vswing
> > level per-lane.
> >
> > Note that the code only does two loops, with each
On 28/10/2021 16:30, Daniel Vetter wrote:
On Thu, Oct 28, 2021 at 10:41:38AM +0200, Christian König wrote:
Am 21.10.21 um 13:13 schrieb Tvrtko Ursulin:
On 21/10/2021 12:06, Maarten Lankhorst wrote:
Op 21-10-2021 om 12:38 schreef Christian König:
Am 21.10.21 um 12:35 schrieb Maarten Lankhor
Hi Stephen,
On Tue, 5 Oct 2021 18:59:40 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/linux/dma-buf.h:456: warning: Function parameter or member 'cb_in'
> not described in 'dma_buf'
> inc
On Fri, Oct 29, 2021 at 10:18:01PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We will need to do some i2c poking from the encoder->shutdown() hook.
> Currently that gets called after irqs have been turned off. We still
> poll the gmbus status bits even if the interrupt never arrives so
Hi all,
On Fri, 15 Oct 2021 20:26:48 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/drm_modeset_lock.c:111:29: error: conflicting types for
> '__stack_depot_save'
> 111 | static depo
On Fri, Oct 29, 2021 at 10:18:02PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Looks like our VBIOS/GOP generally fail to turn the DP dual mode adater
> TMDS output buffers back on after a reboot. This leads to a black screen
> after reboot if we turned the TMDS output buffers off prior
78 matches
Mail list logo
