[PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[Ben Widawsky]

/sys/kernel/debug has more or less been the standard location of debugfs
for several years now. Other parts of DRM already use this location, so
we should as well.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 943db10..1b8d3dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1305,7 +1305,7 @@ static void i915_capture_error_state(struct drm_device *dev)
 		return;
 	}
 
-	DRM_INFO("capturing error event; look for more information in /debug/dri/%d/i915_error_state\n",
+	DRM_INFO("capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n",
 		 dev->primary->index);
 
 	kref_init(&error->ref);
-- 
1.8.1.1

[PATCH 2/2] drm/i915: Adding a warning to FBC description

[Ben Widawsky]

It should only be used with caution...

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9cc8f87..912db3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -76,6 +76,7 @@ int i915_enable_fbc __read_mostly = -1;
 module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600);
 MODULE_PARM_DESC(i915_enable_fbc,
 		"Enable frame buffer compression for power savings "
+		"WARNING: FBC has been implicated in hangs over the years, and should likely be left to the default value. "
 		"(default: -1 (use per-chip default))");
 
 unsigned int i915_lvds_downclock __read_mostly = 0;
-- 
1.8.1.1

Re: [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[Carl Worth]

[-- Attachment #1.1: Type: text/plain, Size: 313 bytes --]

Ben Widawsky <ben@bwidawsk.net> writes:
> /sys/kernel/debug has more or less been the standard location of debugfs
> for several years now. Other parts of DRM already use this location, so
> we should as well.
>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

Reviewed-by: Carl Worth <cworth@cworth.org>

-Carl

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[Damien Lespiau]

On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote:
> /sys/kernel/debug has more or less been the standard location of debugfs
> for several years now. Other parts of DRM already use this location, so
> we should as well.
> 
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>

-- 
Damien

Re: [PATCH 2/2] drm/i915: Adding a warning to FBC description

[Daniel Vetter]

On Mon, Jan 28, 2013 at 03:32:16PM -0800, Ben Widawsky wrote:
> It should only be used with caution...
> 
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

Isn't that like the general assumption of these module parameters that
they can have pretty massive bad side-effects? Meaning I'm routinely
checking these already anyway in bug reports, same for non-standard rc6
settings.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9cc8f87..912db3a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -76,6 +76,7 @@ int i915_enable_fbc __read_mostly = -1;
>  module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600);
>  MODULE_PARM_DESC(i915_enable_fbc,
>  		"Enable frame buffer compression for power savings "
> +		"WARNING: FBC has been implicated in hangs over the years, and should likely be left to the default value. "
>  		"(default: -1 (use per-chip default))");
>  
>  unsigned int i915_lvds_downclock __read_mostly = 0;
> -- 
> 1.8.1.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[Daniel Vetter]

On Tue, Jan 29, 2013 at 08:41:12AM +0000, Damien Lespiau wrote:
> On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote:
> > /sys/kernel/debug has more or less been the standard location of debugfs
> > for several years now. Other parts of DRM already use this location, so
> > we should as well.
> > 
> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> 
> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>

Queued for -next, thanks for the patch. Oh and fixed up a bikeshed from
checkpatch.pl while applying:

Applying: drm/i915: Error state should print /sys/kernel/debug
WARNING: line over 80 characters
#22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308:
+       DRM_INFO("capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n",

total: 0 errors, 1 warnings, 8 lines checked

Yeah, I've added that OCD thing to my patch apply pipeline, let's see
how much fun it is ;-)
-Daniel
> 
> -- 
> Damien
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[Jani Nikula]

On Tue, 29 Jan 2013, Daniel Vetter <daniel@ffwll.ch> wrote:
> Queued for -next, thanks for the patch. Oh and fixed up a bikeshed from
> checkpatch.pl while applying:
>
> Applying: drm/i915: Error state should print /sys/kernel/debug
> WARNING: line over 80 characters
> #22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308:
> +       DRM_INFO("capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n",
>
> total: 0 errors, 1 warnings, 8 lines checked
>
> Yeah, I've added that OCD thing to my patch apply pipeline, let's see
> how much fun it is ;-)

You could go all the way: http://lwn.net/Articles/488992/ ;)

J.

Re: [PATCH 2/2] drm/i915: Adding a warning to FBC description

[Ben Widawsky]

On Tue, 29 Jan 2013 09:49:13 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Mon, Jan 28, 2013 at 03:32:16PM -0800, Ben Widawsky wrote:
> > It should only be used with caution...
> > 
> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> 
> Isn't that like the general assumption of these module parameters that
> they can have pretty massive bad side-effects? Meaning I'm routinely
> checking these already anyway in bug reports, same for non-standard
> rc6 settings.
> -Daniel
> 

I felt that way too, until we got a complain in #intel-gfx and it
changed my mind.

Whatevs, I ain't gonna fight for this one, I'll just punt the bug
reporter to you next time.

Re: [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[Ben Widawsky]

On Tue, 29 Jan 2013 09:54:18 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Jan 29, 2013 at 08:41:12AM +0000, Damien Lespiau wrote:
> > On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote:
> > > /sys/kernel/debug has more or less been the standard location of
> > > debugfs for several years now. Other parts of DRM already use
> > > this location, so we should as well.
> > > 
> > > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > 
> > Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
> 
> Queued for -next, thanks for the patch. Oh and fixed up a bikeshed
> from checkpatch.pl while applying:
> 
> Applying: drm/i915: Error state should print /sys/kernel/debug
> WARNING: line over 80 characters
> #22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308:
> +       DRM_INFO("capturing error event; look for more information
> in /sys/kernel/debug/dri/%d/i915_error_state\n",
> 
> total: 0 errors, 1 warnings, 8 lines checked
> 
> Yeah, I've added that OCD thing to my patch apply pipeline, let's see
> how much fun it is ;-)

I've not looked at the final patch yet, but I think breaking up
constant strings is considered bad form, and lines above 80 are
generally favored for grepability.

At least James Bottomley said that in his talk and LPC, and a bunch of
other maintainers seemed to agree. (and I agree)

> -Daniel
> > 
> > -- 
> > Damien

Re: [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug

[Ville Syrjälä]

On Tue, Jan 29, 2013 at 08:52:36AM -0800, Ben Widawsky wrote:
> On Tue, 29 Jan 2013 09:54:18 +0100
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Tue, Jan 29, 2013 at 08:41:12AM +0000, Damien Lespiau wrote:
> > > On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote:
> > > > /sys/kernel/debug has more or less been the standard location of
> > > > debugfs for several years now. Other parts of DRM already use
> > > > this location, so we should as well.
> > > > 
> > > > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > > 
> > > Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
> > 
> > Queued for -next, thanks for the patch. Oh and fixed up a bikeshed
> > from checkpatch.pl while applying:
> > 
> > Applying: drm/i915: Error state should print /sys/kernel/debug
> > WARNING: line over 80 characters
> > #22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308:
> > +       DRM_INFO("capturing error event; look for more information
> > in /sys/kernel/debug/dri/%d/i915_error_state\n",
> > 
> > total: 0 errors, 1 warnings, 8 lines checked
> > 
> > Yeah, I've added that OCD thing to my patch apply pipeline, let's see
> > how much fun it is ;-)
> 
> I've not looked at the final patch yet, but I think breaking up
> constant strings is considered bad form, and lines above 80 are
> generally favored for grepability.
> 
> At least James Bottomley said that in his talk and LPC, and a bunch of
> other maintainers seemed to agree. (and I agree)

I routinely ignore the 80 cols warnings. I'm sure a significant part
of my patches violate it, even the ones w/o long strings.

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH 2/2] drm/i915: Adding a warning to FBC description

[Jani Nikula]

On Tue, 29 Jan 2013, Ben Widawsky <ben@bwidawsk.net> wrote:
> On Tue, 29 Jan 2013 09:49:13 +0100
> Daniel Vetter <daniel@ffwll.ch> wrote:
>
>> On Mon, Jan 28, 2013 at 03:32:16PM -0800, Ben Widawsky wrote:
>> > It should only be used with caution...
>> > 
>> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>> 
>> Isn't that like the general assumption of these module parameters that
>> they can have pretty massive bad side-effects? Meaning I'm routinely
>> checking these already anyway in bug reports, same for non-standard
>> rc6 settings.
>> -Daniel
>> 
>
> I felt that way too, until we got a complain in #intel-gfx and it
> changed my mind.
>
> Whatevs, I ain't gonna fight for this one, I'll just punt the bug
> reporter to you next time.

Yeah, I agree it's *our* general assumption that these may have bad
side-effects. People just see the random forum posts recommending this
and that module param, and stick them in... Hmm, which means they won't
read that warning anyway. DRM_INFO("don't report a bug about this") when
enabling a feature that's disabled by default on a platform?

Jani.

Re: [PATCH 2/2] drm/i915: Adding a warning to FBC description

[Ben Widawsky]

On Wed, Jan 30, 2013 at 04:18:39PM +0200, Jani Nikula wrote:
> On Tue, 29 Jan 2013, Ben Widawsky <ben@bwidawsk.net> wrote:
> > On Tue, 29 Jan 2013 09:49:13 +0100
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> >> On Mon, Jan 28, 2013 at 03:32:16PM -0800, Ben Widawsky wrote:
> >> > It should only be used with caution...
> >> > 
> >> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> >> 
> >> Isn't that like the general assumption of these module parameters that
> >> they can have pretty massive bad side-effects? Meaning I'm routinely
> >> checking these already anyway in bug reports, same for non-standard
> >> rc6 settings.
> >> -Daniel
> >> 
> >
> > I felt that way too, until we got a complain in #intel-gfx and it
> > changed my mind.
> >
> > Whatevs, I ain't gonna fight for this one, I'll just punt the bug
> > reporter to you next time.
> 
> Yeah, I agree it's *our* general assumption that these may have bad
> side-effects. People just see the random forum posts recommending this
> and that module param, and stick them in... Hmm, which means they won't
> read that warning anyway. DRM_INFO("don't report a bug about this") when
> enabling a feature that's disabled by default on a platform?
> 
> Jani.

Now that's the kind of pessimism I like to hear! OTOH, the current
message: "Enable frame buffer compression for power savings" wouldn't
indicate any reason to not use it. And yes, I know, what git blame says.
I was on a personal crusade to fix FBC on ILK when I wrote that.

I like DRM_INFO as well, but I don't really see a reason not to change
the modinfo (DRM_INFO requires loading the wrong setting first).

-- 
Ben Widawsky, Intel Open Source Technology Center

Re: [PATCH 2/2] drm/i915: Adding a warning to FBC description

[Daniel Vetter]

On Thu, Jan 31, 2013 at 4:13 AM, Ben Widawsky <ben@bwidawsk.net> wrote:
>> Yeah, I agree it's *our* general assumption that these may have bad
>> side-effects. People just see the random forum posts recommending this
>> and that module param, and stick them in... Hmm, which means they won't
>> read that warning anyway. DRM_INFO("don't report a bug about this") when
>> enabling a feature that's disabled by default on a platform?
>>
>> Jani.
>
> Now that's the kind of pessimism I like to hear! OTOH, the current
> message: "Enable frame buffer compression for power savings" wouldn't
> indicate any reason to not use it. And yes, I know, what git blame says.
> I was on a personal crusade to fix FBC on ILK when I wrote that.
>
> I like DRM_INFO as well, but I don't really see a reason not to change
> the modinfo (DRM_INFO requires loading the wrong setting first).

Ok, count me convinced to merge such patches. Though I personally
don't care and don't mind checking bug reports for these, it looks
like I'm in the minority opinion.

I'd like though that such a solution not just takes care of fbc, but
also some of the other dangerous options (which are most): rc6 can
cause hangs, advanced power features can lead to flashing displays,
...

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch