Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-09 Thread Ville Syrjälä
On Wed, Sep 09, 2015 at 02:51:58AM +0300, Konduru, Chandra wrote: > > > > > +static void skl_wa_clkgate(struct drm_i915_private *dev_priv, > > > > > + int pipe, int enable) > > > > > +{ > > > > > + if (pipe == PIPE_A || pipe == PIPE_B) { > > > > > + if (enable) > > > > > +

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-09 Thread Konduru, Chandra
> > > > > > + > > > > > > + /* workaround for NV12 */ > > > > > > + skl_wa_clkgate(dev_priv, pipe, 1); > > > > > > > > > > I wonder what's the cost of having this > > > > > a) always enabled > > > > > b) enabled when the pipe is enabled > > > > > c) enabled only when NV12 is used > > > > > ? >

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-08 Thread Konduru, Chandra
> > > > +static void skl_wa_clkgate(struct drm_i915_private *dev_priv, > > > > + int pipe, int enable) > > > > +{ > > > > + if (pipe == PIPE_A || pipe == PIPE_B) { > > > > + if (enable) > > > > + I915_WRITE(CLKGATE_DIS_PSL(pipe), > > > > +

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-05 Thread Ville Syrjälä
On Sat, Sep 05, 2015 at 01:28:56AM +, Konduru, Chandra wrote: > > > + > > > + if (((IS_SKYLAKE(dev) && intel_get_stepping(dev) == 'C') || > > > + (IS_BROXTON(dev) && intel_get_stepping(dev) == 'A')) && > > > + fb->pixel_format == DRM_FORMAT_NV12) { > > > +

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-04 Thread Ville Syrjälä
On Wed, Aug 19, 2015 at 06:02:35PM -0700, Chandra Konduru wrote: > Adding driver workarounds for nv12. > > Signed-off-by: Chandra Konduru > --- > drivers/gpu/drm/i915/i915_reg.h | 20 > drivers/gpu/drm/i915/intel_csr.c |2 +- >

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-04 Thread Konduru, Chandra
> > + > > + if (((IS_SKYLAKE(dev) && intel_get_stepping(dev) == 'C') || > > + (IS_BROXTON(dev) && intel_get_stepping(dev) == 'A')) && > > + fb->pixel_format == DRM_FORMAT_NV12) { > > + I915_WRITE(CHICKEN_PIPESL(pipe), > > +

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-04 Thread Konduru, Chandra
> > > On Thu, Aug 27, 2015 at 01:44:06AM +, Konduru, Chandra wrote: > > > > > > -static char intel_get_stepping(struct drm_device *dev) > > > > > > +char intel_get_stepping(struct drm_device *dev) > > > > > > > > > > I guess we should have a new home for this now that it's used outside > > >

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-04 Thread Daniel Vetter
> > Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Vetter, Daniel; > > Syrjala, Ville > > Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds > > > > On Thu, Aug 27, 2015 at 01:44:06AM +, Konduru, Chandra wrote: > > > >

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-03 Thread Konduru, Chandra
bject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds > > On Thu, Aug 27, 2015 at 01:44:06AM +, Konduru, Chandra wrote: > > > > -static char intel_get_stepping(struct drm_device *dev) > > > > +char intel_get_stepping(struct drm_device *dev) > &g

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-09-02 Thread Daniel Vetter
On Thu, Aug 27, 2015 at 01:44:06AM +, Konduru, Chandra wrote: > > > -static char intel_get_stepping(struct drm_device *dev) > > > +char intel_get_stepping(struct drm_device *dev) > > > > I guess we should have a new home for this now that it's used outside of > > intel_csr.c Plus kerneldoc,

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-08-26 Thread Daniel Vetter
On Wed, Aug 19, 2015 at 06:02:35PM -0700, Chandra Konduru wrote: Adding driver workarounds for nv12. Signed-off-by: Chandra Konduru chandra.kond...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 20 drivers/gpu/drm/i915/intel_csr.c |2 +-

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

2015-08-26 Thread Konduru, Chandra
-static char intel_get_stepping(struct drm_device *dev) +char intel_get_stepping(struct drm_device *dev) I guess we should have a new home for this now that it's used outside of intel_csr.c Plus kerneldoc, as usual. Will add kerneldoc header and respun, but where do you want to move to?