* [BUG - BISECTED] display not detected anymore
@ 2021-08-14 12:46 ` Heiko Carstens
0 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-14 12:46 UTC (permalink / raw)
To: Dave Airlie, Rodrigo Vivi
Cc: Jani Nikula, Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
Hello,
I have Fedora 33 running, and with the Fedore kernel update from 5.11
series to 5.12 my external monitor was not detected anymore. Same is
true with the Fedora supplied 5.13 kernel version.
So I tried with vanilla kernel 5.11 and latest git head from Linus'
tree. 5.11 works while latest git head does not. Bisecting the problem
points to commit 32c3d9b0f51e ("Merge tag 'drm-intel-next-2021-01-27'
of git://anongit.freedesktop.org/drm/drm-intel into drm-next").
Unfortunately it is a merge commit, so it looks like conflicting
changes have been made in the parent branches.
Hardware in use:
- ThinkPad X1 Yoga 4th / Carbon 7th
- Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
Thunderbolt cable and a monitor (Eizo EV3285) is connected via
Displayport to the docking station.
The monitor is detected and works without any problems (4k@60HZ)
before the above mentioned merge commit. With the commit and
afterwards it is not detected anymore and only the Thinkpad builtin
display can be used.
Any idea what went wrong? I can provide more information, or test
debug patches if wanted. Just let me know.
Thanks,
Heiko
^ permalink raw reply [flat|nested] 12+ messages in thread* [Intel-gfx] [BUG - BISECTED] display not detected anymore
@ 2021-08-14 12:46 ` Heiko Carstens
0 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-14 12:46 UTC (permalink / raw)
To: Dave Airlie, Rodrigo Vivi
Cc: Jani Nikula, Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
Hello,
I have Fedora 33 running, and with the Fedore kernel update from 5.11
series to 5.12 my external monitor was not detected anymore. Same is
true with the Fedora supplied 5.13 kernel version.
So I tried with vanilla kernel 5.11 and latest git head from Linus'
tree. 5.11 works while latest git head does not. Bisecting the problem
points to commit 32c3d9b0f51e ("Merge tag 'drm-intel-next-2021-01-27'
of git://anongit.freedesktop.org/drm/drm-intel into drm-next").
Unfortunately it is a merge commit, so it looks like conflicting
changes have been made in the parent branches.
Hardware in use:
- ThinkPad X1 Yoga 4th / Carbon 7th
- Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
Thunderbolt cable and a monitor (Eizo EV3285) is connected via
Displayport to the docking station.
The monitor is detected and works without any problems (4k@60HZ)
before the above mentioned merge commit. With the commit and
afterwards it is not detected anymore and only the Thinkpad builtin
display can be used.
Any idea what went wrong? I can provide more information, or test
debug patches if wanted. Just let me know.
Thanks,
Heiko
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [BUG - BISECTED] display not detected anymore
2021-08-14 12:46 ` [Intel-gfx] " Heiko Carstens
@ 2021-08-18 11:20 ` Heiko Carstens
-1 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-18 11:20 UTC (permalink / raw)
To: Ville Syrjälä, Stanislav Lisovskiy
Cc: Dave Airlie, Rodrigo Vivi, Jani Nikula, Joonas Lahtinen,
Daniel Vetter, intel-gfx, dri-devel
On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> Hello,
>
> I have Fedora 33 running, and with the Fedore kernel update from 5.11
> series to 5.12 my external monitor was not detected anymore. Same is
> true with the Fedora supplied 5.13 kernel version.
>
> So I tried with vanilla kernel 5.11 and latest git head from Linus'
> tree. 5.11 works while latest git head does not. Bisecting the problem
> points to commit 32c3d9b0f51e ("Merge tag 'drm-intel-next-2021-01-27'
> of git://anongit.freedesktop.org/drm/drm-intel into drm-next").
>
> Unfortunately it is a merge commit, so it looks like conflicting
> changes have been made in the parent branches.
>
> Hardware in use:
>
> - ThinkPad X1 Yoga 4th / Carbon 7th
> - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
>
> The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
> Thunderbolt cable and a monitor (Eizo EV3285) is connected via
> Displayport to the docking station.
>
> The monitor is detected and works without any problems (4k@60HZ)
> before the above mentioned merge commit. With the commit and
> afterwards it is not detected anymore and only the Thinkpad builtin
> display can be used.
>
> Any idea what went wrong? I can provide more information, or test
> debug patches if wanted. Just let me know.
So looks like I made a mistake when bisecting (it literally took me
two days due to the low power machine, even with a minimized kernel
config). Anyway, looking into it again the first bad commit is
ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
With that commit the display is not detected anymore, one commit
before that it still works. So this one seems to be broken.
Ville, Stanislav, any idea how to fix this?
commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jan 22 22:56:32 2021 +0200
drm/i915: Encapsulate dbuf state handling harder
In order to make the dbuf state computation less fragile
let's make it stand on its own feet by not requiring someone
to peek into a crystall ball ahead of time to figure out
which pipes need to be added to the state under which potential
future conditions. Instead we compute each piece of the state
as we go along, and if any fallout occurs that affects more than
the current set of pipes we add the affected pipes to the state
naturally.
That requires that we track a few extra thigns in the global
dbuf state: dbuf slices for each pipe, and the weight each
pipe has when distributing the same set of slice(s) between
multiple pipes. Easy enough.
We do need to follow a somewhat careful sequence of computations
though as there are several steps involved in cooking up the dbuf
state. Thoguh we could avoid some of that by computing more things
on demand instead of relying on earlier step of the algorithm to
have filled it out. I think the end result is still reasonable
as the entire sequence is pretty much consolidated into a single
function instead of being spread around all over.
The rough sequence is this:
1. calculate active_pipes
2. calculate dbuf slices for every pipe
3. calculate total enabled slices
4. calculate new dbuf weights for any crtc in the state
5. calculate new ddb entry for every pipe based on the sets of
slices and weights, and add any affected crtc to the state
6. calculate new plane ddb entries for all crtcs in the state,
and add any affected plane to the state so that we'll perform
the requisite hw reprogramming
And as a nice bonus we get to throw dev_priv->wm.distrust_bios_wm
out the window.
v2: Keep crtc_state->wm.skl.ddb
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122205633.18492-8-ville.syrjala@linux.intel.com
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore
@ 2021-08-18 11:20 ` Heiko Carstens
0 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-18 11:20 UTC (permalink / raw)
To: Ville Syrjälä, Stanislav Lisovskiy
Cc: Dave Airlie, Rodrigo Vivi, Jani Nikula, Joonas Lahtinen,
Daniel Vetter, intel-gfx, dri-devel
On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> Hello,
>
> I have Fedora 33 running, and with the Fedore kernel update from 5.11
> series to 5.12 my external monitor was not detected anymore. Same is
> true with the Fedora supplied 5.13 kernel version.
>
> So I tried with vanilla kernel 5.11 and latest git head from Linus'
> tree. 5.11 works while latest git head does not. Bisecting the problem
> points to commit 32c3d9b0f51e ("Merge tag 'drm-intel-next-2021-01-27'
> of git://anongit.freedesktop.org/drm/drm-intel into drm-next").
>
> Unfortunately it is a merge commit, so it looks like conflicting
> changes have been made in the parent branches.
>
> Hardware in use:
>
> - ThinkPad X1 Yoga 4th / Carbon 7th
> - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
>
> The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
> Thunderbolt cable and a monitor (Eizo EV3285) is connected via
> Displayport to the docking station.
>
> The monitor is detected and works without any problems (4k@60HZ)
> before the above mentioned merge commit. With the commit and
> afterwards it is not detected anymore and only the Thinkpad builtin
> display can be used.
>
> Any idea what went wrong? I can provide more information, or test
> debug patches if wanted. Just let me know.
So looks like I made a mistake when bisecting (it literally took me
two days due to the low power machine, even with a minimized kernel
config). Anyway, looking into it again the first bad commit is
ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
With that commit the display is not detected anymore, one commit
before that it still works. So this one seems to be broken.
Ville, Stanislav, any idea how to fix this?
commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jan 22 22:56:32 2021 +0200
drm/i915: Encapsulate dbuf state handling harder
In order to make the dbuf state computation less fragile
let's make it stand on its own feet by not requiring someone
to peek into a crystall ball ahead of time to figure out
which pipes need to be added to the state under which potential
future conditions. Instead we compute each piece of the state
as we go along, and if any fallout occurs that affects more than
the current set of pipes we add the affected pipes to the state
naturally.
That requires that we track a few extra thigns in the global
dbuf state: dbuf slices for each pipe, and the weight each
pipe has when distributing the same set of slice(s) between
multiple pipes. Easy enough.
We do need to follow a somewhat careful sequence of computations
though as there are several steps involved in cooking up the dbuf
state. Thoguh we could avoid some of that by computing more things
on demand instead of relying on earlier step of the algorithm to
have filled it out. I think the end result is still reasonable
as the entire sequence is pretty much consolidated into a single
function instead of being spread around all over.
The rough sequence is this:
1. calculate active_pipes
2. calculate dbuf slices for every pipe
3. calculate total enabled slices
4. calculate new dbuf weights for any crtc in the state
5. calculate new ddb entry for every pipe based on the sets of
slices and weights, and add any affected crtc to the state
6. calculate new plane ddb entries for all crtcs in the state,
and add any affected plane to the state so that we'll perform
the requisite hw reprogramming
And as a nice bonus we get to throw dev_priv->wm.distrust_bios_wm
out the window.
v2: Keep crtc_state->wm.skl.ddb
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122205633.18492-8-ville.syrjala@linux.intel.com
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [BUG - BISECTED] display not detected anymore
2021-08-18 11:20 ` [Intel-gfx] " Heiko Carstens
@ 2021-08-19 18:07 ` Ville Syrjälä
-1 siblings, 0 replies; 12+ messages in thread
From: Ville Syrjälä @ 2021-08-19 18:07 UTC (permalink / raw)
To: Heiko Carstens
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
On Wed, Aug 18, 2021 at 01:20:54PM +0200, Heiko Carstens wrote:
> On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> > Hello,
> >
> > I have Fedora 33 running, and with the Fedore kernel update from 5.11
> > series to 5.12 my external monitor was not detected anymore. Same is
> > true with the Fedora supplied 5.13 kernel version.
> >
> > So I tried with vanilla kernel 5.11 and latest git head from Linus'
> > tree. 5.11 works while latest git head does not. Bisecting the problem
> > points to commit 32c3d9b0f51e ("Merge tag 'drm-intel-next-2021-01-27'
> > of git://anongit.freedesktop.org/drm/drm-intel into drm-next").
> >
> > Unfortunately it is a merge commit, so it looks like conflicting
> > changes have been made in the parent branches.
> >
> > Hardware in use:
> >
> > - ThinkPad X1 Yoga 4th / Carbon 7th
> > - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
> >
> > The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
> > Thunderbolt cable and a monitor (Eizo EV3285) is connected via
> > Displayport to the docking station.
> >
> > The monitor is detected and works without any problems (4k@60HZ)
> > before the above mentioned merge commit. With the commit and
> > afterwards it is not detected anymore and only the Thinkpad builtin
> > display can be used.
> >
> > Any idea what went wrong? I can provide more information, or test
> > debug patches if wanted. Just let me know.
>
> So looks like I made a mistake when bisecting (it literally took me
> two days due to the low power machine, even with a minimized kernel
> config). Anyway, looking into it again the first bad commit is
>
> ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
>
> With that commit the display is not detected anymore, one commit
> before that it still works. So this one seems to be broken.
>
> Ville, Stanislav, any idea how to fix this?
>
> commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date: Fri Jan 22 22:56:32 2021 +0200
>
> drm/i915: Encapsulate dbuf state handling harder
That has nothing to do with display detection, so very mysterious.
Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
boot with drm.debug=0xe with both good and bad kernels and attach the
dmesg from both to the bug.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore
@ 2021-08-19 18:07 ` Ville Syrjälä
0 siblings, 0 replies; 12+ messages in thread
From: Ville Syrjälä @ 2021-08-19 18:07 UTC (permalink / raw)
To: Heiko Carstens
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
On Wed, Aug 18, 2021 at 01:20:54PM +0200, Heiko Carstens wrote:
> On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> > Hello,
> >
> > I have Fedora 33 running, and with the Fedore kernel update from 5.11
> > series to 5.12 my external monitor was not detected anymore. Same is
> > true with the Fedora supplied 5.13 kernel version.
> >
> > So I tried with vanilla kernel 5.11 and latest git head from Linus'
> > tree. 5.11 works while latest git head does not. Bisecting the problem
> > points to commit 32c3d9b0f51e ("Merge tag 'drm-intel-next-2021-01-27'
> > of git://anongit.freedesktop.org/drm/drm-intel into drm-next").
> >
> > Unfortunately it is a merge commit, so it looks like conflicting
> > changes have been made in the parent branches.
> >
> > Hardware in use:
> >
> > - ThinkPad X1 Yoga 4th / Carbon 7th
> > - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
> >
> > The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
> > Thunderbolt cable and a monitor (Eizo EV3285) is connected via
> > Displayport to the docking station.
> >
> > The monitor is detected and works without any problems (4k@60HZ)
> > before the above mentioned merge commit. With the commit and
> > afterwards it is not detected anymore and only the Thinkpad builtin
> > display can be used.
> >
> > Any idea what went wrong? I can provide more information, or test
> > debug patches if wanted. Just let me know.
>
> So looks like I made a mistake when bisecting (it literally took me
> two days due to the low power machine, even with a minimized kernel
> config). Anyway, looking into it again the first bad commit is
>
> ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
>
> With that commit the display is not detected anymore, one commit
> before that it still works. So this one seems to be broken.
>
> Ville, Stanislav, any idea how to fix this?
>
> commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date: Fri Jan 22 22:56:32 2021 +0200
>
> drm/i915: Encapsulate dbuf state handling harder
That has nothing to do with display detection, so very mysterious.
Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
boot with drm.debug=0xe with both good and bad kernels and attach the
dmesg from both to the bug.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [BUG - BISECTED] display not detected anymore
2021-08-19 18:07 ` [Intel-gfx] " Ville Syrjälä
@ 2021-08-20 16:05 ` Heiko Carstens
-1 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-20 16:05 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
On Thu, Aug 19, 2021 at 09:07:26PM +0300, Ville Syrjälä wrote:
> > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> >
> > With that commit the display is not detected anymore, one commit
> > before that it still works. So this one seems to be broken.
> >
> > Ville, Stanislav, any idea how to fix this?
> >
> > commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Date: Fri Jan 22 22:56:32 2021 +0200
> >
> > drm/i915: Encapsulate dbuf state handling harder
>
> That has nothing to do with display detection, so very mysterious.
>
> Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
> boot with drm.debug=0xe with both good and bad kernels and attach the
> dmesg from both to the bug.
Everything (hopefully) provided here:
https://gitlab.freedesktop.org/drm/intel/-/issues/4013
Please let me know if you need more, or if I can help otherwise to
resolve this.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore
@ 2021-08-20 16:05 ` Heiko Carstens
0 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-20 16:05 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
On Thu, Aug 19, 2021 at 09:07:26PM +0300, Ville Syrjälä wrote:
> > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> >
> > With that commit the display is not detected anymore, one commit
> > before that it still works. So this one seems to be broken.
> >
> > Ville, Stanislav, any idea how to fix this?
> >
> > commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Date: Fri Jan 22 22:56:32 2021 +0200
> >
> > drm/i915: Encapsulate dbuf state handling harder
>
> That has nothing to do with display detection, so very mysterious.
>
> Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
> boot with drm.debug=0xe with both good and bad kernels and attach the
> dmesg from both to the bug.
Everything (hopefully) provided here:
https://gitlab.freedesktop.org/drm/intel/-/issues/4013
Please let me know if you need more, or if I can help otherwise to
resolve this.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [BUG - BISECTED] display not detected anymore
2021-08-20 16:05 ` [Intel-gfx] " Heiko Carstens
@ 2021-08-26 18:45 ` Heiko Carstens
-1 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-26 18:45 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
Hi Ville,
> > > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> > >
> > > With that commit the display is not detected anymore, one commit
> > > before that it still works. So this one seems to be broken.
> > >
> > > Ville, Stanislav, any idea how to fix this?
> > >
> > > commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Date: Fri Jan 22 22:56:32 2021 +0200
> > >
> > > drm/i915: Encapsulate dbuf state handling harder
> >
> > That has nothing to do with display detection, so very mysterious.
> >
> > Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
> > boot with drm.debug=0xe with both good and bad kernels and attach the
> > dmesg from both to the bug.
>
> Everything (hopefully) provided here:
> https://gitlab.freedesktop.org/drm/intel/-/issues/4013
>
> Please let me know if you need more, or if I can help otherwise to
> resolve this.
Did you have any time to look into this already?
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore
@ 2021-08-26 18:45 ` Heiko Carstens
0 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-08-26 18:45 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
Hi Ville,
> > > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> > >
> > > With that commit the display is not detected anymore, one commit
> > > before that it still works. So this one seems to be broken.
> > >
> > > Ville, Stanislav, any idea how to fix this?
> > >
> > > commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Date: Fri Jan 22 22:56:32 2021 +0200
> > >
> > > drm/i915: Encapsulate dbuf state handling harder
> >
> > That has nothing to do with display detection, so very mysterious.
> >
> > Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
> > boot with drm.debug=0xe with both good and bad kernels and attach the
> > dmesg from both to the bug.
>
> Everything (hopefully) provided here:
> https://gitlab.freedesktop.org/drm/intel/-/issues/4013
>
> Please let me know if you need more, or if I can help otherwise to
> resolve this.
Did you have any time to look into this already?
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [BUG - BISECTED] display not detected anymore
2021-08-26 18:45 ` [Intel-gfx] " Heiko Carstens
@ 2021-09-09 8:12 ` Heiko Carstens
-1 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-09-09 8:12 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
Hi Ville,
> > > > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> > > >
> > > > With that commit the display is not detected anymore, one commit
> > > > before that it still works. So this one seems to be broken.
> > > >
> > > > Ville, Stanislav, any idea how to fix this?
> > > >
> > > > commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> > > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Date: Fri Jan 22 22:56:32 2021 +0200
> > > >
> > > > drm/i915: Encapsulate dbuf state handling harder
> > >
> > > That has nothing to do with display detection, so very mysterious.
> > >
> > > Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
> > > boot with drm.debug=0xe with both good and bad kernels and attach the
> > > dmesg from both to the bug.
> >
> > Everything (hopefully) provided here:
> > https://gitlab.freedesktop.org/drm/intel/-/issues/4013
> >
> > Please let me know if you need more, or if I can help otherwise to
> > resolve this.
>
> Did you have any time to look into this already?
How do we proceed with this? Saying that this is either "very
mysterious" or "very strange" won't fix the regression. :)
Thanks,
Heiko
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore
@ 2021-09-09 8:12 ` Heiko Carstens
0 siblings, 0 replies; 12+ messages in thread
From: Heiko Carstens @ 2021-09-09 8:12 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Stanislav Lisovskiy, Dave Airlie, Rodrigo Vivi, Jani Nikula,
Joonas Lahtinen, Daniel Vetter, intel-gfx, dri-devel
Hi Ville,
> > > > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> > > >
> > > > With that commit the display is not detected anymore, one commit
> > > > before that it still works. So this one seems to be broken.
> > > >
> > > > Ville, Stanislav, any idea how to fix this?
> > > >
> > > > commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> > > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Date: Fri Jan 22 22:56:32 2021 +0200
> > > >
> > > > drm/i915: Encapsulate dbuf state handling harder
> > >
> > > That has nothing to do with display detection, so very mysterious.
> > >
> > > Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
> > > boot with drm.debug=0xe with both good and bad kernels and attach the
> > > dmesg from both to the bug.
> >
> > Everything (hopefully) provided here:
> > https://gitlab.freedesktop.org/drm/intel/-/issues/4013
> >
> > Please let me know if you need more, or if I can help otherwise to
> > resolve this.
>
> Did you have any time to look into this already?
How do we proceed with this? Saying that this is either "very
mysterious" or "very strange" won't fix the regression. :)
Thanks,
Heiko
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-09-09 12:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-14 12:46 [BUG - BISECTED] display not detected anymore Heiko Carstens
2021-08-14 12:46 ` [Intel-gfx] " Heiko Carstens
2021-08-18 11:20 ` Heiko Carstens
2021-08-18 11:20 ` [Intel-gfx] " Heiko Carstens
2021-08-19 18:07 ` Ville Syrjälä
2021-08-19 18:07 ` [Intel-gfx] " Ville Syrjälä
2021-08-20 16:05 ` Heiko Carstens
2021-08-20 16:05 ` [Intel-gfx] " Heiko Carstens
2021-08-26 18:45 ` Heiko Carstens
2021-08-26 18:45 ` [Intel-gfx] " Heiko Carstens
2021-09-09 8:12 ` Heiko Carstens
2021-09-09 8:12 ` [Intel-gfx] " Heiko Carstens
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.