Hi,
I noticed that on my machine the screen starts to flicker after I
suspend and resume my machine, on the main laptop display if an external
display is attached with kernel v4.1-rc1. I tracked the regression down
to commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
always on for wm calculation (v4)"), and sent a patch that fixes that
behavior at [1] about two weeks ago, although I'm not sure it's the
right thing to do, as I'm not very familiar with the code. The same bug
still exists in vv4.1-rc3.
Jan Niehusmann confirmed the behavior, but there has been no further
discussion on the topic. I also forgot to cc the people that were
involved in the patch that caused the regression (sorry about that).
Is there anything else that I can do to help fixing this issue?
Thanks,
Thomas
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/065494.html
On Tue, 12 May 2015, Thomas Gummerer <[email protected]> wrote:
> Hi,
>
> I noticed that on my machine the screen starts to flicker after I
> suspend and resume my machine, on the main laptop display if an external
> display is attached with kernel v4.1-rc1. I tracked the regression down
> to commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
> always on for wm calculation (v4)"), and sent a patch that fixes that
> behavior at [1] about two weeks ago, although I'm not sure it's the
> right thing to do, as I'm not very familiar with the code. The same bug
> still exists in vv4.1-rc3.
>
> Jan Niehusmann confirmed the behavior, but there has been no further
> discussion on the topic. I also forgot to cc the people that were
> involved in the patch that caused the regression (sorry about that).
>
> Is there anything else that I can do to help fixing this issue?
Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
BR,
Jani.
>
> Thanks,
> Thomas
>
> [1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/065494.html
--
Jani Nikula, Intel Open Source Technology Center
Hi,
On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
> Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
The visible effect in the video is similar to what I see on the LVDS
display. I also see some influence of the mouse pointer position on the
blanked areas.
The effect on the external screen is more like single scan
lines jumping to the right and back, at a high (but still visible)
frequency.
What I'm missing in the report, are some log entries I'm seeing on my
notebook:
Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
Jan
On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
> Hi,
>
> On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
> > Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
>
> The visible effect in the video is similar to what I see on the LVDS
> display. I also see some influence of the mouse pointer position on the
> blanked areas.
>
> The effect on the external screen is more like single scan
> lines jumping to the right and back, at a high (but still visible)
> frequency.
>
> What I'm missing in the report, are some log entries I'm seeing on my
> notebook:
>
> Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
> Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
hi,
I also have the similar entries in my dmesg, though my problem is a
little different from yours and my bisect lead to another commit.
And that also is still not fixed (last tested with 4.0).
http://patchwork.freedesktop.org/patch/46071/
regards
sudip
>
> Jan
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote:
> > What I'm missing in the report, are some log entries I'm seeing on my
> > notebook:
> >
> > Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> > Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
> > Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> > Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
> hi,
> I also have the similar entries in my dmesg, though my problem is a
> little different from yours and my bisect lead to another commit.
> And that also is still not fixed (last tested with 4.0).
(Please note that I didn't do a bisect - that was Thomas. I only noted
that I can confirm his observations and that his patch helps to prevent
or hide the issue.)
Perhaps these are two completely unrelated issues?
Jan
Jan Niehusmann <[email protected]> writes:
> Hi,
>
> On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
>> Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
>
> The visible effect in the video is similar to what I see on the LVDS
> display. I also see some influence of the mouse pointer position on the
> blanked areas.
I can see the same thing, though it looks slightly different to me, but
the slight difference might be unrelated.
> The effect on the external screen is more like single scan
> lines jumping to the right and back, at a high (but still visible)
> frequency.
I don't see the behavior on my external screen. Maybe some more
information that might help:
The laptop is a dell XPS 15 9530, screen resolution 3200x1800. The
external display is connected via DisplayPort, resulution 1920x1080.
Output from lspci:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:04.0 Signal processing controller: Intel Corporation Device 0c03 (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset Family Thermal Management Controller (rev 05)
02:00.0 3D controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev a1)
06:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b)
07:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5249 PCI Express Card Reader (rev 01)
> What I'm missing in the report, are some log entries I'm seeing on my
> notebook:
>
> Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
> Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
I see the last two messages in my dmesg output, but not the first two.
>
> Jan
Sudip Mukherjee <[email protected]> writes:
> On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
>> Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
>> Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
>> Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
>> Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
> hi,
> I also have the similar entries in my dmesg, though my problem is a
> little different from yours and my bisect lead to another commit.
> And that also is still not fixed (last tested with 4.0).
>
> http://patchwork.freedesktop.org/patch/46071/
Thank you for the pointer, but this seems to be an unrelated issue. I
tried applying the patch, but it doesn't fix the issues that I'm
experiencing.
> regards
> sudip
On Wed, May 13, 2015 at 01:10:11PM +0200, Jan Niehusmann wrote:
> On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote:
> > > What I'm missing in the report, are some log entries I'm seeing on my
> > > notebook:
> > >
> > > Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> > > Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
> > > Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> > > Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
> > hi,
> > I also have the similar entries in my dmesg, though my problem is a
> > little different from yours and my bisect lead to another commit.
> > And that also is still not fixed (last tested with 4.0).
>
> (Please note that I didn't do a bisect - that was Thomas. I only noted
> that I can confirm his observations and that his patch helps to prevent
> or hide the issue.)
>
> Perhaps these are two completely unrelated issues?
yes, maybe unrelated issue. since I am also having similar errors in
dmesg and also having a similar type of problem so replied here.
regards
sudip
>
> Jan
>
On Wed, May 13, 2015 at 01:27:06PM +0200, Thomas Gummerer wrote:
> Sudip Mukherjee <[email protected]> writes:
>
> > On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
> > http://patchwork.freedesktop.org/patch/46071/
>
> Thank you for the pointer, but this seems to be an unrelated issue. I
> tried applying the patch, but it doesn't fix the issues that I'm
> experiencing.
thanks for confirming. I am out of this thread now :)
regards
sudip
>
> > regards
> > sudip
On Tue, May 12, 2015 at 09:54:07PM +0200, Thomas Gummerer wrote:
>
> Hi,
>
> I noticed that on my machine the screen starts to flicker after I
> suspend and resume my machine, on the main laptop display if an external
> display is attached with kernel v4.1-rc1. I tracked the regression down
> to commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
> always on for wm calculation (v4)"), and sent a patch that fixes that
> behavior at [1] about two weeks ago, although I'm not sure it's the
> right thing to do, as I'm not very familiar with the code. The same bug
> still exists in vv4.1-rc3.
>
> Jan Niehusmann confirmed the behavior, but there has been no further
> discussion on the topic. I also forgot to cc the people that were
> involved in the patch that caused the regression (sorry about that).
>
> Is there anything else that I can do to help fixing this issue?
>
> Thanks,
> Thomas
>
> [1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/065494.html
Sorry, I missed your patch when you first sent it. That type of fix
looks like an okay workaround while we do a more in-depth rework of the
watermark system. However I think your patch could cause a crash if we
disable the primary plane via the universal plane interface; if we do
that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
the primary plane is always enabled, ilk_wm_fbc() can eventually get
called and use that 0 in the denominator of a division operation.
If you just squash the following change into your patch, I think it should be
safe:
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eb97cbe..99fa8ee 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2076,7 +2076,7 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc,
p->pri.bytes_per_pixel =
crtc->primary->state->fb->bits_per_pixel / 8;
else
- p->pri.bytes_per_pixel = 0;
+ p->pri.bytes_per_pixel = 4;
p->cur.bytes_per_pixel = 4;
/*
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
always on for wm calculation (v4)") fixes a null pointer dereference.
Setting the primary and cursor panes to false in
ilk_compute_wm_parameters to false does however give the following
errors in the kernel log and causes the screen to flicker.
[ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
*ERROR* uncleared fifo underrun on pipe A
[ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun
Always setting the panes to enabled fixes this error.
Helped-by: Matt Roper <[email protected]>
Signed-off-by: Thomas Gummerer <[email protected]>
---
> Sorry, I missed your patch when you first sent it. That type of fix
> looks like an okay workaround while we do a more in-depth rework of the
> watermark system. However I think your patch could cause a crash if we
> disable the primary plane via the universal plane interface; if we do
> that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
> the primary plane is always enabled, ilk_wm_fbc() can eventually get
> called and use that 0 in the denominator of a division operation.
>
> If you just squash the following change into your patch, I think it should be
> safe:
> [...]
Thank you very much for the suggestion, here is an updated version of the
patch.
drivers/gpu/drm/i915/intel_pm.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fa4ccb3..555b896 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc,
p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
- if (crtc->primary->state->fb) {
- p->pri.enabled = true;
+ if (crtc->primary->state->fb)
p->pri.bytes_per_pixel =
crtc->primary->state->fb->bits_per_pixel / 8;
- } else {
- p->pri.enabled = false;
- p->pri.bytes_per_pixel = 0;
- }
+ else
+ p->pri.bytes_per_pixel = 4;
+
+ p->cur.bytes_per_pixel = 4;
+ /*
+ * TODO: for now, assume primary and cursor planes are always enabled.
+ * Setting them to false makes the screen flicker.
+ */
+ p->pri.enabled = true;
+ p->cur.enabled = true;
- if (crtc->cursor->state->fb) {
- p->cur.enabled = true;
- p->cur.bytes_per_pixel = 4;
- } else {
- p->cur.enabled = false;
- p->cur.bytes_per_pixel = 0;
- }
p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
--
2.4.0.184.g8e1974e
On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
> always on for wm calculation (v4)") fixes a null pointer dereference.
> Setting the primary and cursor panes to false in
> ilk_compute_wm_parameters to false does however give the following
> errors in the kernel log and causes the screen to flicker.
>
> [ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
> *ERROR* uncleared fifo underrun on pipe A
> [ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
>
> Always setting the panes to enabled fixes this error.
>
> Helped-by: Matt Roper <[email protected]>
> Signed-off-by: Thomas Gummerer <[email protected]>
Seems like a reasonable short-term workaround and returns us to how the
code used to behaves.
Reviewed-by: Matt Roper <[email protected]>
> ---
>
> > Sorry, I missed your patch when you first sent it. That type of fix
> > looks like an okay workaround while we do a more in-depth rework of the
> > watermark system. However I think your patch could cause a crash if we
> > disable the primary plane via the universal plane interface; if we do
> > that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
> > the primary plane is always enabled, ilk_wm_fbc() can eventually get
> > called and use that 0 in the denominator of a division operation.
> >
> > If you just squash the following change into your patch, I think it should be
> > safe:
> > [...]
>
> Thank you very much for the suggestion, here is an updated version of the
> patch.
>
> drivers/gpu/drm/i915/intel_pm.c | 24 +++++++++++-------------
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fa4ccb3..555b896 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc,
> p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
> p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
>
> - if (crtc->primary->state->fb) {
> - p->pri.enabled = true;
> + if (crtc->primary->state->fb)
> p->pri.bytes_per_pixel =
> crtc->primary->state->fb->bits_per_pixel / 8;
> - } else {
> - p->pri.enabled = false;
> - p->pri.bytes_per_pixel = 0;
> - }
> + else
> + p->pri.bytes_per_pixel = 4;
> +
> + p->cur.bytes_per_pixel = 4;
> + /*
> + * TODO: for now, assume primary and cursor planes are always enabled.
> + * Setting them to false makes the screen flicker.
> + */
> + p->pri.enabled = true;
> + p->cur.enabled = true;
>
> - if (crtc->cursor->state->fb) {
> - p->cur.enabled = true;
> - p->cur.bytes_per_pixel = 4;
> - } else {
> - p->cur.enabled = false;
> - p->cur.bytes_per_pixel = 0;
> - }
> p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
> p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
>
> --
> 2.4.0.184.g8e1974e
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
On Thu, 14 May 2015, Matt Roper <[email protected]> wrote:
> On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
>> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
>> always on for wm calculation (v4)") fixes a null pointer dereference.
>> Setting the primary and cursor panes to false in
>> ilk_compute_wm_parameters to false does however give the following
>> errors in the kernel log and causes the screen to flicker.
>>
>> [ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
>> *ERROR* uncleared fifo underrun on pipe A
>> [ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CPU pipe A FIFO underrun
>>
>> Always setting the panes to enabled fixes this error.
>>
>> Helped-by: Matt Roper <[email protected]>
>> Signed-off-by: Thomas Gummerer <[email protected]>
>
> Seems like a reasonable short-term workaround and returns us to how the
> code used to behaves.
>
> Reviewed-by: Matt Roper <[email protected]>
Pushed to drm-intel-fixes, thanks for the patch and review.
BR,
Jani.
>
>> ---
>>
>> > Sorry, I missed your patch when you first sent it. That type of fix
>> > looks like an okay workaround while we do a more in-depth rework of the
>> > watermark system. However I think your patch could cause a crash if we
>> > disable the primary plane via the universal plane interface; if we do
>> > that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
>> > the primary plane is always enabled, ilk_wm_fbc() can eventually get
>> > called and use that 0 in the denominator of a division operation.
>> >
>> > If you just squash the following change into your patch, I think it should be
>> > safe:
>> > [...]
>>
>> Thank you very much for the suggestion, here is an updated version of the
>> patch.
>>
>> drivers/gpu/drm/i915/intel_pm.c | 24 +++++++++++-------------
>> 1 file changed, 11 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>> index fa4ccb3..555b896 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc *crtc,
>> p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
>> p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
>>
>> - if (crtc->primary->state->fb) {
>> - p->pri.enabled = true;
>> + if (crtc->primary->state->fb)
>> p->pri.bytes_per_pixel =
>> crtc->primary->state->fb->bits_per_pixel / 8;
>> - } else {
>> - p->pri.enabled = false;
>> - p->pri.bytes_per_pixel = 0;
>> - }
>> + else
>> + p->pri.bytes_per_pixel = 4;
>> +
>> + p->cur.bytes_per_pixel = 4;
>> + /*
>> + * TODO: for now, assume primary and cursor planes are always enabled.
>> + * Setting them to false makes the screen flicker.
>> + */
>> + p->pri.enabled = true;
>> + p->cur.enabled = true;
>>
>> - if (crtc->cursor->state->fb) {
>> - p->cur.enabled = true;
>> - p->cur.bytes_per_pixel = 4;
>> - } else {
>> - p->cur.enabled = false;
>> - p->cur.bytes_per_pixel = 0;
>> - }
>> p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
>> p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
>>
>> --
>> 2.4.0.184.g8e1974e
>>
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
--
Jani Nikula, Intel Open Source Technology Center