Hello,
I tested 3.0.0-rc1 on my notebook which has never been the best friend
of the i915 driver. With linux-2.6.38-gentoo-r4 it has the problem
that the screen remains blank after the lid is closed and reopened, but
that problem I can live with. With 3.0.0-r1 I am back to a former
problem that the screen goes (and remains) blank while booting.
The next step I will do is to test linux-2.6.39-gentoo, probably I
did not notice information that I have to adjust boot parameters or the
kernel config?
Best regards,
Dirk
On Tue, 31 May 2011, Dirk Gouders wrote:
> Hello,
>
> I tested 3.0.0-rc1 on my notebook which has never been the best friend
> of the i915 driver. With linux-2.6.38-gentoo-r4 it has the problem
> that the screen remains blank after the lid is closed and reopened, but
> that problem I can live with. With 3.0.0-r1 I am back to a former
> problem that the screen goes (and remains) blank while booting.
>
> The next step I will do is to test linux-2.6.39-gentoo, probably I
> did not notice information that I have to adjust boot parameters or the
> kernel config?
based on my having lived through the i915 "black screen of death",
pulling out my handy "git bisect" and with advice from chris wilson,
these days, i simply apply this patch to the source:
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index d2c7104..a1a5d03 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
struct opregion_asle *asle = dev_priv->opregion.asle;
u32 max;
+return ASLE_BACKLIGHT_FAILED; // rday
+
if (!(bclp & ASLE_BCLP_VALID))
return ASLE_BACKLIGHT_FAILED;
i tried taking it out a couple of times and immediately got the same
i915-related problem so until i hear differently, the patch stays in.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
"Robert P. J. Day" <[email protected]> writes:
> On Tue, 31 May 2011, Dirk Gouders wrote:
>
>> Hello,
>>
>> I tested 3.0.0-rc1 on my notebook which has never been the best friend
>> of the i915 driver. With linux-2.6.38-gentoo-r4 it has the problem
>> that the screen remains blank after the lid is closed and reopened, but
>> that problem I can live with. With 3.0.0-r1 I am back to a former
>> problem that the screen goes (and remains) blank while booting.
>>
>> The next step I will do is to test linux-2.6.39-gentoo, probably I
>> did not notice information that I have to adjust boot parameters or the
>> kernel config?
>
> based on my having lived through the i915 "black screen of death",
> pulling out my handy "git bisect" and with advice from chris wilson,
> these days, i simply apply this patch to the source:
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
> index d2c7104..a1a5d03 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
> struct opregion_asle *asle = dev_priv->opregion.asle;
> u32 max;
>
> +return ASLE_BACKLIGHT_FAILED; // rday
> +
> if (!(bclp & ASLE_BCLP_VALID))
> return ASLE_BACKLIGHT_FAILED;
>
>
> i tried taking it out a couple of times and immediately got the same
> i915-related problem so until i hear differently, the patch stays in.
Thanks for the hint. I tested the patch with 3.0.0-rc1 and
unfortunately the symptoms remain the same.
Meanwhile, I tested 2.6.39-gentoo as well and it also causes that
problem. So, this is not really a (new) 3.0.0-rc1 issue.
Best regards,
Dirk
Dirk Gouders <[email protected]> writes:
> "Robert P. J. Day" <[email protected]> writes:
>
>> On Tue, 31 May 2011, Dirk Gouders wrote:
>>
>>> Hello,
>>>
>>> I tested 3.0.0-rc1 on my notebook which has never been the best friend
>>> of the i915 driver. With linux-2.6.38-gentoo-r4 it has the problem
>>> that the screen remains blank after the lid is closed and reopened, but
>>> that problem I can live with. With 3.0.0-r1 I am back to a former
>>> problem that the screen goes (and remains) blank while booting.
>>>
>>> The next step I will do is to test linux-2.6.39-gentoo, probably I
>>> did not notice information that I have to adjust boot parameters or the
>>> kernel config?
>>
>> based on my having lived through the i915 "black screen of death",
>> pulling out my handy "git bisect" and with advice from chris wilson,
>> these days, i simply apply this patch to the source:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
>> index d2c7104..a1a5d03 100644
>> --- a/drivers/gpu/drm/i915/intel_opregion.c
>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>> @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
>> struct opregion_asle *asle = dev_priv->opregion.asle;
>> u32 max;
>>
>> +return ASLE_BACKLIGHT_FAILED; // rday
>> +
>> if (!(bclp & ASLE_BCLP_VALID))
>> return ASLE_BACKLIGHT_FAILED;
>>
>>
>> i tried taking it out a couple of times and immediately got the same
>> i915-related problem so until i hear differently, the patch stays in.
>
> Thanks for the hint. I tested the patch with 3.0.0-rc1 and
> unfortunately the symptoms remain the same.
>
> Meanwhile, I tested 2.6.39-gentoo as well and it also causes that
> problem. So, this is not really a (new) 3.0.0-rc1 issue.
>
> Best regards,
>
> Dirk
Your patch reminded me of another patch of Chris that caused problems
for several other people, but manually applied to the changed context in
3.0.0-rc1 again works for me:
--- linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-30 02:43:36.000000000 +0200
+++ /usr/src/linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-31 20:53:35.000000000 +0200
@@ -267,7 +267,7 @@
case 4:
return alternate ? 100 : 96;
default:
- return alternate ? 100 : 120;
+ return alternate ? 120 : 100;
}
}
The strange thing is that I am pretty sure that I did not have to modify
2.6.28-gentoo{,-r4} what I at that time also reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=31596
Best regards,
Dirk
Dirk Gouders <[email protected]> writes:
> Dirk Gouders <[email protected]> writes:
>
>> "Robert P. J. Day" <[email protected]> writes:
>>
>>> On Tue, 31 May 2011, Dirk Gouders wrote:
>>>
>>>> Hello,
>>>>
>>>> I tested 3.0.0-rc1 on my notebook which has never been the best friend
>>>> of the i915 driver. With linux-2.6.38-gentoo-r4 it has the problem
>>>> that the screen remains blank after the lid is closed and reopened, but
>>>> that problem I can live with. With 3.0.0-r1 I am back to a former
>>>> problem that the screen goes (and remains) blank while booting.
>>>>
>>>> The next step I will do is to test linux-2.6.39-gentoo, probably I
>>>> did not notice information that I have to adjust boot parameters or the
>>>> kernel config?
>>>
>>> based on my having lived through the i915 "black screen of death",
>>> pulling out my handy "git bisect" and with advice from chris wilson,
>>> these days, i simply apply this patch to the source:
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
>>> index d2c7104..a1a5d03 100644
>>> --- a/drivers/gpu/drm/i915/intel_opregion.c
>>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>>> @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
>>> struct opregion_asle *asle = dev_priv->opregion.asle;
>>> u32 max;
>>>
>>> +return ASLE_BACKLIGHT_FAILED; // rday
>>> +
>>> if (!(bclp & ASLE_BCLP_VALID))
>>> return ASLE_BACKLIGHT_FAILED;
>>>
>>>
>>> i tried taking it out a couple of times and immediately got the same
>>> i915-related problem so until i hear differently, the patch stays in.
>>
>> Thanks for the hint. I tested the patch with 3.0.0-rc1 and
>> unfortunately the symptoms remain the same.
>>
>> Meanwhile, I tested 2.6.39-gentoo as well and it also causes that
>> problem. So, this is not really a (new) 3.0.0-rc1 issue.
>>
>> Best regards,
>>
>> Dirk
>
> Your patch reminded me of another patch of Chris that caused problems
> for several other people, but manually applied to the changed context in
> 3.0.0-rc1 again works for me:
>
> --- linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-30 02:43:36.000000000 +0200
> +++ /usr/src/linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-31 20:53:35.000000000 +0200
> @@ -267,7 +267,7 @@
> case 4:
> return alternate ? 100 : 96;
> default:
> - return alternate ? 100 : 120;
> + return alternate ? 120 : 100;
> }
> }
>
> The strange thing is that I am pretty sure that I did not have to modify
> 2.6.28-gentoo{,-r4} what I at that time also reported here:
> https://bugs.freedesktop.org/show_bug.cgi?id=31596
For completeness I want to report that I did a bisect and found out that
the following commit seems to be the one that reintroduced the problem
that I have to manually patch the kernel to avoid a blank screen
(with backlight turned on) during boot:
47a05eca72991039e788b25232061f9c9df9ec23 is the first bad commit
commit 47a05eca72991039e788b25232061f9c9df9ec23
Author: Jesse Barnes <[email protected]>
Date: Mon Feb 7 13:46:40 2011 -0800
drm/i915: disable PCH ports if needed when disabling a CRTC
Disable any PCH ports associated with a pipe when disabling it. This
should prevent transcoder disable failures due to ports still being on.
Signed-off-by: Jesse Barnes <[email protected]>
[ickle: introduce *_PIPE_ENABLED() macro]
Signed-off-by: Chris Wilson <[email protected]>
:040000 040000 2c7c54cceb89821941943614cede86c4a2c2a8bc 9382527ee169beb54a10eb0afe8a69d418025c2e M drivers
Dirk
On Mon, 13 Jun 2011 23:21:12 +0200
Dirk Gouders <[email protected]> wrote:
> Dirk Gouders <[email protected]> writes:
>
> > Dirk Gouders <[email protected]> writes:
> >
> >> "Robert P. J. Day" <[email protected]> writes:
> >>
> >>> On Tue, 31 May 2011, Dirk Gouders wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> I tested 3.0.0-rc1 on my notebook which has never been the best friend
> >>>> of the i915 driver. With linux-2.6.38-gentoo-r4 it has the problem
> >>>> that the screen remains blank after the lid is closed and reopened, but
> >>>> that problem I can live with. With 3.0.0-r1 I am back to a former
> >>>> problem that the screen goes (and remains) blank while booting.
> >>>>
> >>>> The next step I will do is to test linux-2.6.39-gentoo, probably I
> >>>> did not notice information that I have to adjust boot parameters or the
> >>>> kernel config?
> >>>
> >>> based on my having lived through the i915 "black screen of death",
> >>> pulling out my handy "git bisect" and with advice from chris wilson,
> >>> these days, i simply apply this patch to the source:
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
> >>> index d2c7104..a1a5d03 100644
> >>> --- a/drivers/gpu/drm/i915/intel_opregion.c
> >>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> >>> @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
> >>> struct opregion_asle *asle = dev_priv->opregion.asle;
> >>> u32 max;
> >>>
> >>> +return ASLE_BACKLIGHT_FAILED; // rday
> >>> +
> >>> if (!(bclp & ASLE_BCLP_VALID))
> >>> return ASLE_BACKLIGHT_FAILED;
> >>>
> >>>
> >>> i tried taking it out a couple of times and immediately got the same
> >>> i915-related problem so until i hear differently, the patch stays in.
> >>
> >> Thanks for the hint. I tested the patch with 3.0.0-rc1 and
> >> unfortunately the symptoms remain the same.
> >>
> >> Meanwhile, I tested 2.6.39-gentoo as well and it also causes that
> >> problem. So, this is not really a (new) 3.0.0-rc1 issue.
> >>
> >> Best regards,
> >>
> >> Dirk
> >
> > Your patch reminded me of another patch of Chris that caused problems
> > for several other people, but manually applied to the changed context in
> > 3.0.0-rc1 again works for me:
> >
> > --- linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-30 02:43:36.000000000 +0200
> > +++ /usr/src/linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-31 20:53:35.000000000 +0200
> > @@ -267,7 +267,7 @@
> > case 4:
> > return alternate ? 100 : 96;
> > default:
> > - return alternate ? 100 : 120;
> > + return alternate ? 120 : 100;
> > }
> > }
> >
> > The strange thing is that I am pretty sure that I did not have to modify
> > 2.6.28-gentoo{,-r4} what I at that time also reported here:
> > https://bugs.freedesktop.org/show_bug.cgi?id=31596
>
> For completeness I want to report that I did a bisect and found out that
> the following commit seems to be the one that reintroduced the problem
> that I have to manually patch the kernel to avoid a blank screen
> (with backlight turned on) during boot:
>
> 47a05eca72991039e788b25232061f9c9df9ec23 is the first bad commit
> commit 47a05eca72991039e788b25232061f9c9df9ec23
> Author: Jesse Barnes <[email protected]>
> Date: Mon Feb 7 13:46:40 2011 -0800
>
> drm/i915: disable PCH ports if needed when disabling a CRTC
>
> Disable any PCH ports associated with a pipe when disabling it. This
> should prevent transcoder disable failures due to ports still being on.
>
> Signed-off-by: Jesse Barnes <[email protected]>
> [ickle: introduce *_PIPE_ENABLED() macro]
> Signed-off-by: Chris Wilson <[email protected]>
>
> :040000 040000 2c7c54cceb89821941943614cede86c4a2c2a8bc 9382527ee169beb54a10eb0afe8a69d418025c2e M drivers
Just to confirm, does this patch also keep your screen enabled?
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 81a9059..ef41487 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1366,7 +1366,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
val = I915_READ(reg);
if (ADPA_PIPE_ENABLED(val, pipe))
I915_WRITE(reg, val & ~ADPA_DAC_ENABLE);
-
+#if 0
reg = PCH_LVDS;
val = I915_READ(reg);
if (LVDS_PIPE_ENABLED(val, pipe)) {
@@ -1374,7 +1374,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
POSTING_READ(reg);
udelay(100);
}
-
+#endif
disable_pch_hdmi(dev_priv, pipe, HDMIB);
disable_pch_hdmi(dev_priv, pipe, HDMIC);
disable_pch_hdmi(dev_priv, pipe, HDMID);
Jesse Barnes <[email protected]> writes:
> On Mon, 13 Jun 2011 23:21:12 +0200
> Dirk Gouders <[email protected]> wrote:
>
>> Dirk Gouders <[email protected]> writes:
>>
>> > Dirk Gouders <[email protected]> writes:
>> >
>> >> "Robert P. J. Day" <[email protected]> writes:
>> >>
>> >>> On Tue, 31 May 2011, Dirk Gouders wrote:
>> >>>
>> >>>> Hello,
>> >>>>
>> >>>> I tested 3.0.0-rc1 on my notebook which has never been the best friend
>> >>>> of the i915 driver. With linux-2.6.38-gentoo-r4 it has the problem
>> >>>> that the screen remains blank after the lid is closed and reopened, but
>> >>>> that problem I can live with. With 3.0.0-r1 I am back to a former
>> >>>> problem that the screen goes (and remains) blank while booting.
>> >>>>
>> >>>> The next step I will do is to test linux-2.6.39-gentoo, probably I
>> >>>> did not notice information that I have to adjust boot parameters or the
>> >>>> kernel config?
>> >>>
>> >>> based on my having lived through the i915 "black screen of death",
>> >>> pulling out my handy "git bisect" and with advice from chris wilson,
>> >>> these days, i simply apply this patch to the source:
>> >>>
>> >>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
>> >>> index d2c7104..a1a5d03 100644
>> >>> --- a/drivers/gpu/drm/i915/intel_opregion.c
>> >>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>> >>> @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
>> >>> struct opregion_asle *asle = dev_priv->opregion.asle;
>> >>> u32 max;
>> >>>
>> >>> +return ASLE_BACKLIGHT_FAILED; // rday
>> >>> +
>> >>> if (!(bclp & ASLE_BCLP_VALID))
>> >>> return ASLE_BACKLIGHT_FAILED;
>> >>>
>> >>>
>> >>> i tried taking it out a couple of times and immediately got the same
>> >>> i915-related problem so until i hear differently, the patch stays in.
>> >>
>> >> Thanks for the hint. I tested the patch with 3.0.0-rc1 and
>> >> unfortunately the symptoms remain the same.
>> >>
>> >> Meanwhile, I tested 2.6.39-gentoo as well and it also causes that
>> >> problem. So, this is not really a (new) 3.0.0-rc1 issue.
>> >>
>> >> Best regards,
>> >>
>> >> Dirk
>> >
>> > Your patch reminded me of another patch of Chris that caused problems
>> > for several other people, but manually applied to the changed context in
>> > 3.0.0-rc1 again works for me:
>> >
>> > --- linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-30 02:43:36.000000000 +0200
>> > +++ /usr/src/linux-3.0-rc1/drivers/gpu/drm/i915/intel_bios.c 2011-05-31 20:53:35.000000000 +0200
>> > @@ -267,7 +267,7 @@
>> > case 4:
>> > return alternate ? 100 : 96;
>> > default:
>> > - return alternate ? 100 : 120;
>> > + return alternate ? 120 : 100;
>> > }
>> > }
>> >
>> > The strange thing is that I am pretty sure that I did not have to modify
>> > 2.6.28-gentoo{,-r4} what I at that time also reported here:
>> > https://bugs.freedesktop.org/show_bug.cgi?id=31596
>>
>> For completeness I want to report that I did a bisect and found out that
>> the following commit seems to be the one that reintroduced the problem
>> that I have to manually patch the kernel to avoid a blank screen
>> (with backlight turned on) during boot:
>>
>> 47a05eca72991039e788b25232061f9c9df9ec23 is the first bad commit
>> commit 47a05eca72991039e788b25232061f9c9df9ec23
>> Author: Jesse Barnes <[email protected]>
>> Date: Mon Feb 7 13:46:40 2011 -0800
>>
>> drm/i915: disable PCH ports if needed when disabling a CRTC
>>
>> Disable any PCH ports associated with a pipe when disabling it. This
>> should prevent transcoder disable failures due to ports still being on.
>>
>> Signed-off-by: Jesse Barnes <[email protected]>
>> [ickle: introduce *_PIPE_ENABLED() macro]
>> Signed-off-by: Chris Wilson <[email protected]>
>>
>> :040000 040000 2c7c54cceb89821941943614cede86c4a2c2a8bc 9382527ee169beb54a10eb0afe8a69d418025c2e M drivers
>
> Just to confirm, does this patch also keep your screen enabled?
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
> index 81a9059..ef41487 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1366,7 +1366,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
> val = I915_READ(reg);
> if (ADPA_PIPE_ENABLED(val, pipe))
> I915_WRITE(reg, val & ~ADPA_DAC_ENABLE);
> -
> +#if 0
> reg = PCH_LVDS;
> val = I915_READ(reg);
> if (LVDS_PIPE_ENABLED(val, pipe)) {
> @@ -1374,7 +1374,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
> POSTING_READ(reg);
> udelay(100);
> }
> -
> +#endif
> disable_pch_hdmi(dev_priv, pipe, HDMIB);
> disable_pch_hdmi(dev_priv, pipe, HDMIC);
> disable_pch_hdmi(dev_priv, pipe, HDMID);
No, that patch does not help.
Yesterday, I reverted the following part of the above commit which
completely leaves out the call to intel_disable_pch_ports() and that
helped, but I'm afraid that is not very useful information:
@@ -2864,14 +2900,12 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
ironlake_fdi_disable(crtc);
- if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
- temp = I915_READ(PCH_LVDS);
- if (temp & LVDS_PORT_EN) {
- I915_WRITE(PCH_LVDS, temp & ~LVDS_PORT_EN);
- POSTING_READ(PCH_LVDS);
- udelay(100);
- }
- }
+ /* This is a horrible layering violation; we should be doing this in
+ * the connector/encoder ->prepare instead, but we don't always have
+ * enough information there about the config to know whether it will
+ * actually be necessary or just cause undesired flicker.
+ */
+ intel_disable_pch_ports(dev_priv, pipe);
intel_disable_transcoder(dev_priv, pipe);
On Wed, 15 Jun 2011 23:29:53 +0200
Dirk Gouders <[email protected]> wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
> > index 81a9059..ef41487 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1366,7 +1366,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
> > val = I915_READ(reg);
> > if (ADPA_PIPE_ENABLED(val, pipe))
> > I915_WRITE(reg, val & ~ADPA_DAC_ENABLE);
> > -
> > +#if 0
> > reg = PCH_LVDS;
> > val = I915_READ(reg);
> > if (LVDS_PIPE_ENABLED(val, pipe)) {
> > @@ -1374,7 +1374,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
> > POSTING_READ(reg);
> > udelay(100);
> > }
> > -
> > +#endif
> > disable_pch_hdmi(dev_priv, pipe, HDMIB);
> > disable_pch_hdmi(dev_priv, pipe, HDMIC);
> > disable_pch_hdmi(dev_priv, pipe, HDMID);
>
> No, that patch does not help.
Oh is this not an LVDS panel? I'm curious which of the port disables
is at fault in your config then. If you have an eDP panel, it would
likely be the PCH_DP_D write. It could be a side effect of the
PANEL_UNLOCK_REGS write as well though, can you try commenting each of
those out?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
Jesse Barnes <[email protected]> writes:
> Oh is this not an LVDS panel? I'm curious which of the port disables
> is at fault in your config then. If you have an eDP panel, it would
> likely be the PCH_DP_D write. It could be a side effect of the
> PANEL_UNLOCK_REGS write as well though, can you try commenting each of
> those out?
Yes, you are right. Commenting out a single line helps:
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 81a9059..ed95cbf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1356,7 +1356,7 @@ static void intel_disable_pch_ports(struct drm_i915_private *dev_priv,
u32 reg, val;
val = I915_READ(PCH_PP_CONTROL);
- I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
+ //I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
disable_pch_dp(dev_priv, pipe, PCH_DP_B);
disable_pch_dp(dev_priv, pipe, PCH_DP_C);
Dirk
On Thu, 16 Jun 2011 00:03:38 +0200
Dirk Gouders <[email protected]> wrote:
> Jesse Barnes <[email protected]> writes:
>
> > Oh is this not an LVDS panel? I'm curious which of the port disables
> > is at fault in your config then. If you have an eDP panel, it would
> > likely be the PCH_DP_D write. It could be a side effect of the
> > PANEL_UNLOCK_REGS write as well though, can you try commenting each of
> > those out?
>
> Yes, you are right. Commenting out a single line helps:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 81a9059..ed95cbf 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1356,7 +1356,7 @@ static void intel_disable_pch_ports(struct drm_i915_private *dev_priv,
> u32 reg, val;
>
> val = I915_READ(PCH_PP_CONTROL);
> - I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
> + //I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
>
> disable_pch_dp(dev_priv, pipe, PCH_DP_B);
> disable_pch_dp(dev_priv, pipe, PCH_DP_C);
Ok interesting, that means one of the locked regs we're trying to write
later is the real culprit for this issue... those include the LVDS reg
and the panel timing regs. I'll see if I can figure out which one
might be the problem.
--
Jesse Barnes, Intel Open Source Technology Center
Jesse Barnes <[email protected]> writes:
> On Thu, 16 Jun 2011 00:03:38 +0200
> Dirk Gouders <[email protected]> wrote:
>
>> Jesse Barnes <[email protected]> writes:
>>
>> > Oh is this not an LVDS panel? I'm curious which of the port disables
>> > is at fault in your config then. If you have an eDP panel, it would
>> > likely be the PCH_DP_D write. It could be a side effect of the
>> > PANEL_UNLOCK_REGS write as well though, can you try commenting each of
>> > those out?
>>
>> Yes, you are right. Commenting out a single line helps:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 81a9059..ed95cbf 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -1356,7 +1356,7 @@ static void intel_disable_pch_ports(struct drm_i915_private *dev_priv,
>> u32 reg, val;
>>
>> val = I915_READ(PCH_PP_CONTROL);
>> - I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
>> + //I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
>>
>> disable_pch_dp(dev_priv, pipe, PCH_DP_B);
>> disable_pch_dp(dev_priv, pipe, PCH_DP_C);
>
> Ok interesting, that means one of the locked regs we're trying to write
> later is the real culprit for this issue... those include the LVDS reg
> and the panel timing regs. I'll see if I can figure out which one
> might be the problem.
Thanks a lot for your help.
Perhaps this information is helpful: with the above change, a trace is
generated during boot:
------------[ cut here ]------------
WARNING: at drivers/gpu/drm/i915/intel_display.c:1020 ironlake_crtc_disable+0x65
4/0x124c()
Hardware name: 08946MG
PCH LVDS enabled on transcoder A, should be disabled
Modules linked in:
Pid: 1, comm: swapper Not tainted 3.0.0-rc3-00055-gada9c93-dirty #6
Call Trace:
[<ffffffff8103e052>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff8103e107>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffff812d517a>] ? ironlake_crtc_disable+0x654/0x124c
[<ffffffff812ea90d>] ? intel_panel_set_backlight+0x3e/0x2b7
[<ffffffff812c55a7>] ? intel_crtc_dpms+0x38/0xfd
[<ffffffff812c2d49>] ? intel_crtc_disable+0x1a/0x4f
[<ffffffff8127c93b>] ? drm_helper_disable_unused_functions+0xd0/0xfb
[<ffffffff812dbab9>] ? intel_modeset_init+0x1500/0x15c0
[<ffffffff81297388>] ? i915_driver_load+0xc0d/0x13d9
[<ffffffff812865d8>] ? drm_get_minor+0x22b/0x288
[<ffffffff81288206>] ? drm_get_pci_dev+0x149/0x253
[<ffffffff814d4fc2>] ? _raw_spin_lock_irqsave+0x16/0x34
[<ffffffff812096c5>] ? local_pci_probe+0x49/0x95
[<ffffffff81209aa9>] ? pci_device_probe+0xc4/0xf3
[<ffffffff812fd902>] ? driver_sysfs_add+0x66/0x8d
[<ffffffff812fdb90>] ? driver_probe_device+0xa8/0x138
[<ffffffff812fdc6f>] ? __driver_attach+0x4f/0x6f
[<ffffffff812fdc20>] ? driver_probe_device+0x138/0x138
[<ffffffff812fce89>] ? bus_for_each_dev+0x47/0x72
[<ffffffff812fd515>] ? bus_add_driver+0xae/0x1fe
[<ffffffff817fe14d>] ? drm_core_init+0x121/0x121
[<ffffffff812fe0f4>] ? driver_register+0x8d/0xf5
[<ffffffff817fe14d>] ? drm_core_init+0x121/0x121
[<ffffffff81209cff>] ? __pci_register_driver+0x50/0xbb
[<ffffffff817fe14d>] ? drm_core_init+0x121/0x121
[<ffffffff810002e5>] ? do_one_initcall+0x78/0x12b
[<ffffffff817d9b3f>] ? kernel_init+0xa8/0x126
[<ffffffff814db414>] ? kernel_thread_helper+0x4/0x10
[<ffffffff817d9a97>] ? start_kernel+0x337/0x337
[<ffffffff814db410>] ? gs_change+0xb/0xb
---[ end trace bb2314f7f28ba213 ]---
Dirk
Dirk Gouders <[email protected]> writes:
> Jesse Barnes <[email protected]> writes:
>
>> On Thu, 16 Jun 2011 00:03:38 +0200
>> Dirk Gouders <[email protected]> wrote:
>>
>>> Jesse Barnes <[email protected]> writes:
>>>
>>> > Oh is this not an LVDS panel? I'm curious which of the port disables
>>> > is at fault in your config then. If you have an eDP panel, it would
>>> > likely be the PCH_DP_D write. It could be a side effect of the
>>> > PANEL_UNLOCK_REGS write as well though, can you try commenting each of
>>> > those out?
>>>
>>> Yes, you are right. Commenting out a single line helps:
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> index 81a9059..ed95cbf 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -1356,7 +1356,7 @@ static void intel_disable_pch_ports(struct drm_i915_private *dev_priv,
>>> u32 reg, val;
>>>
>>> val = I915_READ(PCH_PP_CONTROL);
>>> - I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
>>> + //I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
>>>
>>> disable_pch_dp(dev_priv, pipe, PCH_DP_B);
>>> disable_pch_dp(dev_priv, pipe, PCH_DP_C);
>>
>> Ok interesting, that means one of the locked regs we're trying to write
>> later is the real culprit for this issue... those include the LVDS reg
>> and the panel timing regs. I'll see if I can figure out which one
>> might be the problem.
>
> Thanks a lot for your help.
>
> Perhaps this information is helpful: with the above change, a trace is
> generated during boot:
>
> ------------[ cut here ]------------
> WARNING: at drivers/gpu/drm/i915/intel_display.c:1020 ironlake_crtc_disable+0x65
> 4/0x124c()
> Hardware name: 08946MG
> PCH LVDS enabled on transcoder A, should be disabled
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 3.0.0-rc3-00055-gada9c93-dirty #6
> Call Trace:
> [<ffffffff8103e052>] ? warn_slowpath_common+0x78/0x8c
> [<ffffffff8103e107>] ? warn_slowpath_fmt+0x45/0x4a
> [<ffffffff812d517a>] ? ironlake_crtc_disable+0x654/0x124c
> [<ffffffff812ea90d>] ? intel_panel_set_backlight+0x3e/0x2b7
> [<ffffffff812c55a7>] ? intel_crtc_dpms+0x38/0xfd
> [<ffffffff812c2d49>] ? intel_crtc_disable+0x1a/0x4f
> [<ffffffff8127c93b>] ? drm_helper_disable_unused_functions+0xd0/0xfb
> [<ffffffff812dbab9>] ? intel_modeset_init+0x1500/0x15c0
> [<ffffffff81297388>] ? i915_driver_load+0xc0d/0x13d9
> [<ffffffff812865d8>] ? drm_get_minor+0x22b/0x288
> [<ffffffff81288206>] ? drm_get_pci_dev+0x149/0x253
> [<ffffffff814d4fc2>] ? _raw_spin_lock_irqsave+0x16/0x34
> [<ffffffff812096c5>] ? local_pci_probe+0x49/0x95
> [<ffffffff81209aa9>] ? pci_device_probe+0xc4/0xf3
> [<ffffffff812fd902>] ? driver_sysfs_add+0x66/0x8d
> [<ffffffff812fdb90>] ? driver_probe_device+0xa8/0x138
> [<ffffffff812fdc6f>] ? __driver_attach+0x4f/0x6f
> [<ffffffff812fdc20>] ? driver_probe_device+0x138/0x138
> [<ffffffff812fce89>] ? bus_for_each_dev+0x47/0x72
> [<ffffffff812fd515>] ? bus_add_driver+0xae/0x1fe
> [<ffffffff817fe14d>] ? drm_core_init+0x121/0x121
> [<ffffffff812fe0f4>] ? driver_register+0x8d/0xf5
> [<ffffffff817fe14d>] ? drm_core_init+0x121/0x121
> [<ffffffff81209cff>] ? __pci_register_driver+0x50/0xbb
> [<ffffffff817fe14d>] ? drm_core_init+0x121/0x121
> [<ffffffff810002e5>] ? do_one_initcall+0x78/0x12b
> [<ffffffff817d9b3f>] ? kernel_init+0xa8/0x126
> [<ffffffff814db414>] ? kernel_thread_helper+0x4/0x10
> [<ffffffff817d9a97>] ? start_kernel+0x337/0x337
> [<ffffffff814db410>] ? gs_change+0xb/0xb
> ---[ end trace bb2314f7f28ba213 ]---
Some redundant information, but if I change one line at another place
in the i915 code (whithout the above modification) the result is more
satisfactory on my machine, because in that case the display even works
after I close and reopen the lid:
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
index 927442a..ebb67ae 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -267,7 +267,7 @@ static int intel_bios_ssc_frequency(struct drm_device *dev,
case 4:
return alternate ? 100 : 96;
default:
- return alternate ? 100 : 120;
+ return alternate ? 120 : 100;
}
}
Dirk
On Thu, 16 Jun 2011 13:49:11 +0200
Dirk Gouders <[email protected]> wrote:
> Some redundant information, but if I change one line at another place
> in the i915 code (whithout the above modification) the result is more
> satisfactory on my machine, because in that case the display even works
> after I close and reopen the lid:
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
> index 927442a..ebb67ae 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -267,7 +267,7 @@ static int intel_bios_ssc_frequency(struct drm_device *dev,
> case 4:
> return alternate ? 100 : 96;
> default:
> - return alternate ? 100 : 120;
> + return alternate ? 120 : 100;
> }
> }
Does your machine also work if you set the lvds_use_ssc param to 0?
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 16 Jun 2011 19:54:36 +0200
Dirk Gouders <[email protected]> wrote:
> Jesse Barnes <[email protected]> writes:
>
> > On Thu, 16 Jun 2011 13:49:11 +0200
> > Dirk Gouders <[email protected]> wrote:
> >
> >> Some redundant information, but if I change one line at another place
> >> in the i915 code (whithout the above modification) the result is more
> >> satisfactory on my machine, because in that case the display even works
> >> after I close and reopen the lid:
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
> >> index 927442a..ebb67ae 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/intel_bios.c
> >> @@ -267,7 +267,7 @@ static int intel_bios_ssc_frequency(struct drm_device *dev,
> >> case 4:
> >> return alternate ? 100 : 96;
> >> default:
> >> - return alternate ? 100 : 120;
> >> + return alternate ? 120 : 100;
> >> }
> >> }
> >
> > Does your machine also work if you set the lvds_use_ssc param to 0?
>
> Yes, that works!
> I undid all modifications, compiled the i915 driver as a module (I am
> not sure if that is necessary) und used i915.lvds_use_ssc=0 as a
> further bootparameter, I will attach the dmesg output.
>
> Would you say "This problem was just a case of wrong parameter usage",
> then?
No, we should be parsing the VBT differently in your case it appears.
But the simple change above will break other platforms, so it's
possible we're missing a VBT format change and need to parse it
differently depending on the version.
--
Jesse Barnes, Intel Open Source Technology Center
Jesse Barnes <[email protected]> writes:
>> > Does your machine also work if you set the lvds_use_ssc param to 0?
>>
>> Yes, that works!
>> I undid all modifications, compiled the i915 driver as a module (I am
>> not sure if that is necessary) und used i915.lvds_use_ssc=0 as a
>> further bootparameter, I will attach the dmesg output.
>>
>> Would you say "This problem was just a case of wrong parameter usage",
>> then?
>
> No, we should be parsing the VBT differently in your case it appears.
> But the simple change above will break other platforms, so it's
> possible we're missing a VBT format change and need to parse it
> differently depending on the version.
OK, thanks a lot for spending your time to help me to find this
comfortable workaround.
Please let me know if I can help with further testing.
Dirk