[Intel-gfx] [PATCH 1/2] drm/i915: Do a dummy DPCD read before the actual read

[Daniel Vetter]

On Thu, Oct 16, 2014 at 12:39:29PM -0700, Todd Previte wrote:
> 
> On 10/16/2014 10:46 AM, ville.syrjala at linux.intel.com wrote:
> >From: Ville Syrj?l? 
> >
> >Sometimes we seem to get utter garbage from DPCD reads. The resulting
> >buffer is filled with the same byte, and the operation completed without
> >errors. My HP ZR24w monitor seems particularly susceptible to this
> >problem once it's gone into a sleep mode.
> >
> >The issue seems to happen only for the first AUX message that wakes the
> >sink up. But as the first AUX read we often do is the DPCD receiver
> >cap it does wreak a bit of havoc with subsequent link training etc. when
> >the receiver cap bw/lane/etc. information is garbage.
> >
> >A sufficient workaround seems to be to perform a single byte dummy read
> >before reading the actual data. I suppose that just wakes up the sink
> >sufficiently and we can just throw away the returned data in case it's
> >crap. DP_DPCD_REV seems like a sufficiently safe location to read here.
> >
> >Signed-off-by: Ville Syrj?l? 
> >---
> >  drivers/gpu/drm/i915/intel_dp.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >b/drivers/gpu/drm/i915/intel_dp.c
> >index 64c8e04..f07f02c 100644
> >--- a/drivers/gpu/drm/i915/intel_dp.c
> >+++ b/drivers/gpu/drm/i915/intel_dp.c
> >@@ -2870,6 +2870,13 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, 
> >unsigned int offset,
> > ssize_t ret;
> > int i;
> >+/*
> >+ * Sometime we just get the same incorrect byte repeated
> >+ * over the entire buffer. Doing just one throw away read
> >+ * initially seems to "solve" it.
> >+ */
> >+drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
> >+
> > for (i = 0; i < 3; i++) {
> > ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> > if (ret == size)
> Seems like a reasonable workaround for this problem, though investigating
> the actual root cause might be worthwhile.
> 
> Reviewed-by: Todd Previte 

Cc: stable at vger.kernel.org

... one for Jani I guess. But I'm suspicious here too, so maybe we should
extract this read_wake function to the core dp helpers and convince that
some other driver should use it? Adding more people and lists.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 85267] vlc crashes with vdpau (Radeon 3850HD) [r600]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85267

--- Comment #3 from Dieter N?tzel  ---
Fixed bug 84140, too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/89df4fa3/attachment.html>

[Bug 84140] mplayer crashes playing some files using vdpau output

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84140

--- Comment #27 from Dieter N?tzel  ---
Fixed by this patch:

https://bugs.freedesktop.org/attachment.cgi?id=108144
[Mesa-dev] [PATCH] r600g: Drop references to destroyed blend state

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/06f6ec20/attachment.html>

[PATCH v2] drm/crtc: Remove duplicated ioctl code

[Ville Syrjälä]

On Wed, Oct 08, 2014 at 11:40:34AM -0500, Chuck Ebbert wrote:
> Make drm_mode_add_fb() call drm_mode_add_fb2() after converting its
> args to the new internal format, instead of duplicating code.
> 
> Also picks up a lot more error checking, which the legacy modes
> should pass after being converted to the new format.
> 
> Signed-off-by: Chuck Ebbert 

Looks good to me.

Reviewed-by: Ville Syrj?l? 

> ---
>  drm_crtc.c |   31 +++
>  1 file changed, 7 insertions(+), 24 deletions(-)
> 
> Against 3.17.0, compile tested only.
> This time with the correct signed-off-by.
> 
> diff a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2925,11 +2925,9 @@ int drm_mode_addfb(struct drm_device *dev,
>  {
>   struct drm_mode_fb_cmd *or = data;
>   struct drm_mode_fb_cmd2 r = {};
> - struct drm_mode_config *config = >mode_config;
> - struct drm_framebuffer *fb;
> - int ret = 0;
> + int ret;
>  
> - /* Use new struct with format internally */
> + /* convert to new format and call new ioctl */
>   r.fb_id = or->fb_id;
>   r.width = or->width;
>   r.height = or->height;
> @@ -2937,27 +2934,12 @@ int drm_mode_addfb(struct drm_device *dev,
>   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
>   r.handles[0] = or->handle;
>  
> - if (!drm_core_check_feature(dev, DRIVER_MODESET))
> - return -EINVAL;
> -
> - if ((config->min_width > r.width) || (r.width > config->max_width))
> - return -EINVAL;
> -
> - if ((config->min_height > r.height) || (r.height > config->max_height))
> - return -EINVAL;
> -
> - fb = dev->mode_config.funcs->fb_create(dev, file_priv, );
> - if (IS_ERR(fb)) {
> - DRM_DEBUG_KMS("could not create framebuffer\n");
> - return PTR_ERR(fb);
> - }
> + ret = drm_mode_addfb2(dev, , file_priv);
> + if (ret)
> + return ret;
> +
> + or->fb_id = r.fb_id;
>  
> - mutex_lock(_priv->fbs_lock);
> - or->fb_id = fb->base.id;
> - list_add(>filp_head, _priv->fbs);
> - DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
> - mutex_unlock(_priv->fbs_lock);
> -
>   return ret;
>  }
>  
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 79980] Random radeonsi crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #173 from Jacob  ---
(In reply to darkbasic from comment #171)
> On my system with 3.17+ sometimes it takes days to crash while sometimes it
> crashes after a few minutes. Only 3.15 did *always* crash in a couple of
> minutes. I remember 3.15-rc1-pre didn't crash, so the bad commit should be
> somewhere around 3.15-rc0 and 3.15-rc2.

Takes about a couple hours for me to crash 3.15-rc3, "sadly" not minutes.
3.15-rc2 didn't crash on me,  so I'm currently doing a bisection

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/06c37649/attachment.html>

[PATCH] drm/crtc: Fix two typos

[Ville Syrjälä]

On Wed, Oct 08, 2014 at 11:37:20AM -0500, Chuck Ebbert wrote:
> Fix:
> 
>   ioclt -> ioctl in comment
>   wrong variable name in debug message
> 
> Signed-off-by: Chuck Ebbert 

Reviewed-by: Ville Syrj?l? 

> ---
> 
> --- drivers/gpu/drm/drm_crtc.c.orig   2014-10-08 11:29:50.948406186 -0500
> +++ drivers/gpu/drm/drm_crtc.c2014-10-08 11:30:55.781479300 -0500
> @@ -2913,7 +2913,7 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format)
>   * @file_priv: drm file for the ioctl call
>   *
>   * Add a new FB to the specified CRTC, given a user request. This is the
> - * original addfb ioclt which only supported RGB formats.
> + * original addfb ioctl which only supported RGB formats.
>   *
>   * Called by the user via ioctl.
>   *
> @@ -3033,7 +3033,7 @@ static int framebuffer_check(const struc
>   num_planes = drm_format_num_planes(r->pixel_format);
>  
>   if (r->width == 0 || r->width % hsub) {
> - DRM_DEBUG_KMS("bad framebuffer width %u\n", r->height);
> + DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
>   return -EINVAL;
>   }
>  
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 85180] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85180

--- Comment #3 from Bernhardt Mark  ---
(In reply to Michel D?nzer from comment #2)
> Is this a regression? If yes, what was the last kernel version where it
> worked for you? Can you bisect?

I don't know. I have no access to this computer at this moment, but on weekend
I can try Debian Wheezy with 3.2 kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/a9bd85dd/attachment.html>

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2014-10-03:
- first batch of skl stage 1 enabling
- fixes from Rodrigo to the PSR, fbc and sink crc code
- kerneldoc for the frontbuffer tracking code, runtime pm code and the basic
  interrupt enable/disable functions
- smaller stuff all over
drm-intel-next-2014-09-19:
- bunch more i830M fixes from Ville
- full ppgtt now again enabled by default
- more ppgtt fixes from Michel Thierry and Chris Wilson
- plane config work from Gustavo Padovan
- spinlock clarifications
- piles of smaller improvements all over, as usual

As promised the updated pull with the backmerge to take care of the silent
conflict I've missed first time around.

Cheers, Daniel


The following changes since commit ebb69c95175609990af708ec90c46530f5a2c819:

  drm/i915: Enable pixel replicated modes on BDW and HSW. (2014-10-01 10:01:41 
+0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-10-03-merge

for you to fetch changes up to a8cbd4597799ade2b8a656dac7768c352b58e43a:

  Merge branch 'drm-intel-next-fixes' into drm-intel-next (2014-10-21 14:42:30 
+0200)


Brad Volkin (2):
  drm/i915: Re-enable the command parser when using PPGTT
  drm/i915: Log a message when rejecting LRM to OACONTROL

Chris Wilson (3):
  drm/i915: Remove dead code, i915_gem_verify_gtt
  drm/i915: Inline feature detection into sanitize_enable_ppgtt
  drm/i915: Remove the duplicated logic between the two shrink phases

Daisy Sun (1):
  drm/i915/skl: SKL FBC enablement

Damien Lespiau (31):
  drm/i915/skl: Add the Skylake PCI ids
  drm/i915/skl: Add an IS_GEN9() define
  drm/i915/skl: Fence registers on SKL are the same as SNB
  drm/i915/skl: Provide a placeholder for init_clock_gating()
  drm/i915/skl: Skylake shares the interrupt logic with Broadwell
  drm/i915/skl: Framebuffers need to be aligned to 256KB on Skylake
  drm/i915/skl: Implement the new update_plane() for primary planes
  drm/i915/skl: Don't create a VGA connector on Skylake
  drm/i915/skl: Don't try to read out the PCH transcoder state if not 
present
  drm/i915/skl: Program the DDI buffer translation tables
  drm/i915/skl: Add support for DP voltage swings and pre-emphasis
  drm/i915/skl: Skylake moves AUX_CTL from PCH to CPU
  drm/i915/skl: Add the additional graphics stolen sizes
  drm/i915/skl: gen9 uses the same bind_vma() vfuncs as gen6+
  drm/i915/skl: Implement the get_aux_clock_divider() DP vfunc
  drm/i915/skl: Provide a get_aux_send_ctl() vfunc for skylake
  drm/i915/skl: Initialize PPGTT like gen8
  drm/i915/skl: Allow the reg_read ioctl to return RCS_TIMESTAMP
  drm/i915/skl: report the same INSTDONE registers as gen8
  drm/i915/skl: Report the PDP regs as in gen8
  drm/i915/skl: SKL shares the same underrun interrupt as BDW
  drm/i915/skl: Adjust the display engine interrupts
  drm/i915/skl: Implement WaDisableSDEUnitClockGating:skl
  drm/i915/skl: Implement Wa4x4STCOptimizationDisable:skl
  drm/i915/skl: Implement WaDisableDgMirrorFixInHalfSliceChicken5:skl
  drm/i915/skl: Skylake has 2 "sprite" planes per pipe
  drm/i915/skl: Implement drm_plane vfuncs
  drm/i915/skl: Adjust assert_sprites_disabled()
  drm/i915/skl: Introduce a I915_MAX_PLANES macro
  drm/i915/skl: Introduce intel_num_planes()
  drm/i915/skl: Move gen9 pm initialization into its own branch

Daniel Vetter (36):
  drm/i915: WARN if interrupts aren't on in en/disable_pipestat
  drm/i915: Restore resume irq ordering comment
  drm/i915: Drop get/put_pages for scratch page
  agp/intel-gtt: Remove get/put_pages
  drm/i915: Fix irq checks in ring->irq_get/put functions
  drm/i915: Convert backlight_lock to a mutex
  drm/i915: Use generic vblank wait
  drm/i915: static inline for intel_wait_for_vblank
  drm/i915: Clarify event_lock locking, process context
  drm/i915: Clarify event_lock locking, irq context
  drm/i915: Clarify gpu_error.lock locking
  drm/i915: Clarify irq_lock locking, intel_tv_detect
  drm/i915: Clarify irq_lock locking, work functions
  drm/i915: Clarify irq_lock locking, interrupt install/uninstall
  drm/i915: Clarify irq_lock locking, irq handlers
  drm/i915: Clarify irq_lock locking, special cases
  drm/i915: Clarify uncore.lock locking
  drm/i915: Clarify mmio_flip_lock locking
  drm/i915: Update DRIVER_DATE to 20140919
  drm/i915: DocBook integration for frontbuffer tracking
  Merge branch 'topic/skl-stage1' into drm-intel-next-queued
  drm/i915: Tighting frontbuffer tracking around flips
  drm/i915: spelling fixes for frontbuffer tracking kerneldoc
  drm/i915: Remove intel_modeset_suspend_hw
  drm/i915: Extract intel_runtime_pm.c
  drm/i915: Bikeshed rpm functions name a bit.
  drm/i915: Move 

[Intel-gfx] [PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

[Paulo Zanoni]

2014-10-09 12:38 GMT-03:00 Todd Previte :
> These counters are used for Displayort complinace testing to detect error 
> conditions
> when executing certain compliance tests. Currently these are used in the EDID 
> tests
> to determine if the video mode needs to be set to the preferred mode or the 
> failsafe
> mode.
>
> Cc: dri-devel at lists.freedesktop.org

I see that this patch and a few others in your series still have
unaddressed/unanswered review comments, given on the first time you
sent the patches. Please take a look at them.

> Signed-off-by: Todd Previte 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 2 ++
>  include/drm/drm_dp_helper.h | 1 +
>  2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 08e33b8..8353051 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -654,10 +654,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>
> case DP_AUX_I2C_REPLY_NACK:
> DRM_DEBUG_KMS("I2C nack\n");
> +   aux->i2c_nack_count++;
> return -EREMOTEIO;
>
> case DP_AUX_I2C_REPLY_DEFER:
> DRM_DEBUG_KMS("I2C defer\n");
> +   aux->i2c_defer_count++;
> usleep_range(400, 500);
> continue;
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8edeed0..45f3ee8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -551,6 +551,7 @@ struct drm_dp_aux {
> struct mutex hw_mutex;
> ssize_t (*transfer)(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg);
> +   uint8_t i2c_nack_count, i2c_defer_count;
>  };
>
>  ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73530

--- Comment #63 from Christian A?falg  ---
I think / guess that I am having the same issues. I've got the same laptop,
running Arch Linux. Mostly, I've been using the proprietary catalyst driver,
since I never got the free driver working. The proprietary is working fine.

What is the issue here? You've been playing with timings for the physical link
to the internal panel? Is it so frickly? What would you need to fix the issue?
How can I help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/a260723b/attachment.html>

[PULL] drm-intel-next

[Daniel Vetter]

On Tue, Oct 21, 2014 at 2:27 PM, Daniel Vetter  
wrote:
> There's some simple merge conflicts with current upstream but nothing
> serious really, I can push out a merge point if you want to. As usual
> -nightly has the solution for you to peek at.

Sorrry I've lied, there's an annoying conflict that git somehow
doesn't spot which results in a function declaration that's no longer
used being left behind. I'll prep a new pull with the merge on top.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC PATCH v2 4/4] i-g-t: tests/drv_module_reload: add ipvr support

[Yao Cheng]

on vlv, if ipvr is installed, it need be manually unloaded before
i915, otherwise user might run into use-after-free issue.

Signed-off-by: Yao Cheng 
---
 tests/drv_module_reload | 16 
 1 file changed, 16 insertions(+)

diff --git a/tests/drv_module_reload b/tests/drv_module_reload
index 5cbff89..82c67bd 100755
--- a/tests/drv_module_reload
+++ b/tests/drv_module_reload
@@ -24,6 +24,14 @@ rmmod snd_hda_intel &> /dev/null

 #ignore errors in ips - gen5 only
 rmmod intel_ips &> /dev/null
+
+# vlv only for now:
+# due to platform device model limitation, need unload ipvr manually
+if lsmod | grep ipvr &> /dev/null ; then
+   echo Need manually unload ipvr.ko.
+   rmmod ipvr
+fi
+
 rmmod i915
 #ignore errors in intel-gtt, often built-in
 rmmod intel-gtt &> /dev/null
@@ -31,6 +39,11 @@ rmmod intel-gtt &> /dev/null
 rmmod drm_kms_helper &> /dev/null
 rmmod drm &> /dev/null

+if lsmod | grep ipvr &> /dev/null ; then
+   echo WARNING: ipvr.ko still loaded!
+   exit 1
+fi
+
 if lsmod | grep i915 &> /dev/null ; then
echo WARNING: i915.ko still loaded!
exit 1
@@ -41,6 +54,9 @@ fi
 modprobe i915
 echo 1 > /sys/class/vtconsole/vtcon1/bind

+# for vlv, load VED driver
+modprobe ipvr
+
 modprobe snd_hda_intel

 # try to run something
-- 
1.9.1

[RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED

[Yao Cheng]

Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver (a standalone drm driver) probes the VED device and
creates a new dri card on install.

Currently only supports VED on valleyview.
Kerneldoc is updated for i915_ved.c.

Signed-off-by: Yao Cheng 
---
 Documentation/DocBook/drm.tmpl  |   5 +
 drivers/gpu/drm/i915/Makefile   |   3 +
 drivers/gpu/drm/i915/i915_dma.c |  11 ++
 drivers/gpu/drm/i915/i915_drv.h |   9 ++
 drivers/gpu/drm/i915/i915_irq.c |   2 +
 drivers/gpu/drm/i915/i915_reg.h |   5 +
 drivers/gpu/drm/i915/i915_ved.c | 264 
 7 files changed, 299 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_ved.c

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index d7cfc98..f1787b4 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3806,6 +3806,11 @@ int num_ioctls;
 !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
 !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
   
+  
+VED video core integration
+!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
+!Idrivers/gpu/drm/i915/i915_ved.c
+  
 
 
   Display Hardware Handling
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3a6bce0..a4b9252 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -80,6 +80,9 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_dma.o \
  i915_ums.o

+# VED for VLV
+i915-y += i915_ved.o
+
 obj-$(CONFIG_DRM_I915)  += i915.o

 CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 85d14e1..47714e1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1791,6 +1791,13 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (IS_GEN5(dev))
intel_gpu_ips_init(dev_priv);

+   if (IS_VALLEYVIEW(dev)) {
+   ret = vlv_setup_ved(dev);
+   if (ret < 0) {
+   DRM_ERROR("failed to setup VED bridge: %d\n", ret);
+   }
+   }
+
intel_runtime_pm_enable(dev_priv);

return 0;
@@ -1833,6 +1840,10 @@ int i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;

+   if (IS_VALLEYVIEW(dev)) {
+   vlv_teardown_ved(dev);
+   }
+
ret = i915_gem_suspend(dev);
if (ret) {
DRM_ERROR("failed to idle hardware: %d\n", ret);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 821ba26..952df34 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1709,6 +1709,10 @@ struct drm_i915_private {

uint32_t bios_vgacntr;

+   /* used for setup VED bridge */
+   struct platform_device *ved_platdev;
+   int ved_irq;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
 * here! */
struct i915_dri1_state dri1;
@@ -2785,6 +2789,11 @@ void i915_restore_display_reg(struct drm_device *dev);
 void i915_setup_sysfs(struct drm_device *dev_priv);
 void i915_teardown_sysfs(struct drm_device *dev_priv);

+/* i915_ved.c */
+int vlv_setup_ved(struct drm_device *dev);
+void vlv_teardown_ved(struct drm_device *dev);
+void vlv_ved_irq_handler(struct drm_device *dev);
+
 /* intel_i2c.c */
 extern int intel_setup_gmbus(struct drm_device *dev);
 extern void intel_teardown_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 737b239..68c2977 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2177,6 +2177,8 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
snb_gt_irq_handler(dev, dev_priv, gt_iir);
if (pm_iir)
gen6_rps_irq_handler(dev_priv, pm_iir);
+   if (IS_VALLEYVIEW(dev) && (iir & VLV_VED_BLOCK_INTERRUPT))
+   vlv_ved_irq_handler(dev);
/* Call regardless, as some status bits might not be
 * signalled in iir */
valleyview_pipestat_irq_handler(dev, iir);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2ed02c3..95421ef 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1284,6 +1284,11 @@ enum punit_power_well {
 #define VLV_DISPLAY_BASE 0x18
 #define VLV_MIPI_BASE VLV_DISPLAY_BASE

+/* forwarding VED irq and sharing MMIO to the VED driver */
+#define VLV_VED_BLOCK_INTERRUPT(1 << 23)
+#define VLV_VED_BASE 0x17
+#define VLV_VED_SIZE 0x01
+
 

[RFC PATCH v2 0/4] drm driver for VED in Intel GPU

[Yao Cheng]

drm/ipvr is a new GEM driver for VED (PowerVR's VPU integrated in Intel GPU), 
which
extends video decoding capability.
Two new Kconfig added for building ipvr driver:
  CONFIG_DRM_IPVR: Build option for ipvr module
  CONFIG_DRM_IPVR_EC: Experimental feature of error concealment

The driver name "ipvr" means the PowerVR's core wrapped by Intel. The PowerVR 
VPUs
are also integrated by non-i915 platforms such as GMA500, so we keep ipvr driver
and i915 driver separated and independent to each other. To achieve this we do
the minimum change in i915: i915_ved.c added for setting up the bridge between 
VED
and i915, kerneldoc also updated.

User mode drm helper "libdrm_ipvr.so" and simple ioctl/decode test are included.

one test script "drv_module_reload" in i-g-t also updated to support ipvr 
loading
and unloading. Due to restriction in Linux platform device model, we have to
manually unload ipvr before unloading i915.

Yao Cheng (4):
  [1/4] drm/i915: add i915_ved.c to setup bridge for VED
  [2/4] drm/ipvr: drm driver for VED
  [3/4] libdrm/ipvr: user mode helper for ipvr drm driver
  [4/4] i-g-t: tests/drv_module_reload: add ipvr support

-- 
1.9.1

[Bug 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=62721

--- Comment #16 from S?bastien Bianti  ---
Created attachment 154411
  --> https://bugzilla.kernel.org/attachment.cgi?id=154411=edit
Full dmesg log fedora-20 3.16.4-200.fc20.x86_64

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=62721

S?bastien Bianti  changed:

   What|Removed |Added

 CC||sebastienbianti at free.fr

--- Comment #15 from S?bastien Bianti  ---
Same thing on fedora 20 with some differences in the logs:
?
[21407.558836] radeon :01:00.0: ring 0 stalled for more than 10449msec
[21407.558840] radeon :01:00.0: GPU lockup (waiting for 0x00181ecf
last fence id 0x0
0181ece on ring 0)
[21407.559903] BUG: unable to handle kernel paging request at c90404e80ffc
[21407.559975] IP: [] radeon_ring_backup+0xc8/0x160 [radeon]
[21407.560069] PGD 11b01c067 PUD 0 
[21407.560104] Oops:  [#1] SMP 
?

Hardware:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620
LE [Radeon HD 3450] (rev ff)

See attached full dmesg.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

So -rc1 is out the door and the first i915 pull request for 3.19 in your
inbox ;-)

Due to the early drm-next merge window we've already accumulated two
testing cycles instead of the usual one, but somehow there wasn't too much
going on really.

drm-intel-next-2014-10-03:
- first batch of skl stage 1 enabling
- fixes from Rodrigo to the PSR, fbc and sink crc code
- kerneldoc for the frontbuffer tracking code, runtime pm code and the basic
  interrupt enable/disable functions
- smaller stuff all over
drm-intel-next-2014-09-19:
- bunch more i830M fixes from Ville
- full ppgtt now again enabled by default
- more ppgtt fixes from Michel Thierry and Chris Wilson
- plane config work from Gustavo Padovan
- spinlock clarifications
- piles of smaller improvements all over, as usual

There's some simple merge conflicts with current upstream but nothing
serious really, I can push out a merge point if you want to. As usual
-nightly has the solution for you to peek at.

Cheers, Daniel


The following changes since commit d743ecf360637d489a3ba81a268f574359149601:

  drm/doc: Fixup drm_irq kerneldoc includes. (2014-09-24 11:43:47 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-10-03

for you to fetch changes up to b727735732d5b2fde0a88911210215e03e190d11:

  drm/i915: Update DRIVER_DATE to 20141003 (2014-10-03 17:38:34 +0200)


- first batch of skl stage 1 enabling
- fixes from Rodrigo to the PSR, fbc and sink crc code
- kerneldoc for the frontbuffer tracking code, runtime pm code and the basic
  interrupt enable/disable functions
- smaller stuff all over


Brad Volkin (2):
  drm/i915: Re-enable the command parser when using PPGTT
  drm/i915: Log a message when rejecting LRM to OACONTROL

Chris Wilson (3):
  drm/i915: Remove dead code, i915_gem_verify_gtt
  drm/i915: Inline feature detection into sanitize_enable_ppgtt
  drm/i915: Remove the duplicated logic between the two shrink phases

Daisy Sun (1):
  drm/i915/skl: SKL FBC enablement

Damien Lespiau (31):
  drm/i915/skl: Add the Skylake PCI ids
  drm/i915/skl: Add an IS_GEN9() define
  drm/i915/skl: Fence registers on SKL are the same as SNB
  drm/i915/skl: Provide a placeholder for init_clock_gating()
  drm/i915/skl: Skylake shares the interrupt logic with Broadwell
  drm/i915/skl: Framebuffers need to be aligned to 256KB on Skylake
  drm/i915/skl: Implement the new update_plane() for primary planes
  drm/i915/skl: Don't create a VGA connector on Skylake
  drm/i915/skl: Don't try to read out the PCH transcoder state if not 
present
  drm/i915/skl: Program the DDI buffer translation tables
  drm/i915/skl: Add support for DP voltage swings and pre-emphasis
  drm/i915/skl: Skylake moves AUX_CTL from PCH to CPU
  drm/i915/skl: Add the additional graphics stolen sizes
  drm/i915/skl: gen9 uses the same bind_vma() vfuncs as gen6+
  drm/i915/skl: Implement the get_aux_clock_divider() DP vfunc
  drm/i915/skl: Provide a get_aux_send_ctl() vfunc for skylake
  drm/i915/skl: Initialize PPGTT like gen8
  drm/i915/skl: Allow the reg_read ioctl to return RCS_TIMESTAMP
  drm/i915/skl: report the same INSTDONE registers as gen8
  drm/i915/skl: Report the PDP regs as in gen8
  drm/i915/skl: SKL shares the same underrun interrupt as BDW
  drm/i915/skl: Adjust the display engine interrupts
  drm/i915/skl: Implement WaDisableSDEUnitClockGating:skl
  drm/i915/skl: Implement Wa4x4STCOptimizationDisable:skl
  drm/i915/skl: Implement WaDisableDgMirrorFixInHalfSliceChicken5:skl
  drm/i915/skl: Skylake has 2 "sprite" planes per pipe
  drm/i915/skl: Implement drm_plane vfuncs
  drm/i915/skl: Adjust assert_sprites_disabled()
  drm/i915/skl: Introduce a I915_MAX_PLANES macro
  drm/i915/skl: Introduce intel_num_planes()
  drm/i915/skl: Move gen9 pm initialization into its own branch

Daniel Vetter (35):
  drm/i915: WARN if interrupts aren't on in en/disable_pipestat
  drm/i915: Restore resume irq ordering comment
  drm/i915: Drop get/put_pages for scratch page
  agp/intel-gtt: Remove get/put_pages
  drm/i915: Fix irq checks in ring->irq_get/put functions
  drm/i915: Convert backlight_lock to a mutex
  drm/i915: Use generic vblank wait
  drm/i915: static inline for intel_wait_for_vblank
  drm/i915: Clarify event_lock locking, process context
  drm/i915: Clarify event_lock locking, irq context
  drm/i915: Clarify gpu_error.lock locking
  drm/i915: Clarify irq_lock locking, intel_tv_detect
  drm/i915: Clarify irq_lock locking, work functions
  drm/i915: Clarify irq_lock locking, interrupt install/uninstall
  drm/i915: Clarify irq_lock locking, irq handlers
  drm/i915: Clarify irq_lock 

[Intel-gfx] [RFC PATCH v2 3/4] libdrm/ipvr: user mode helper for ipvr drm driver

[Daniel Vetter]

On Tue, Oct 21, 2014 at 02:37:47PM +0800, Yao Cheng wrote:
> add usermode helper for the ipvr kernel driver.
> test tools:
> 1. test_ioctl: test kernel driver by directly ioctl
> 2. test_decode: test decode functionality by calling libdrm_ipvr
> 
> Signed-off-by: Yao Cheng 

The testcase seems fairly limited, so I think we need the full libva
implementation to be able to review the kernel/userspace ioctl interface.
-Daniel

> ---
>  Makefile.am|6 +-
>  Makefile.sources   |1 +
>  configure.ac   |   26 +-
>  include/drm/ipvr_drm.h |  267 ++
>  ipvr/Makefile.am   |   58 +
>  ipvr/Makefile.sources  |5 +
>  ipvr/ipvr_bufmgr.h |  156 ++
>  ipvr/ipvr_bufmgr_gem.c | 1867 +
>  ipvr/libdrm_ipvr.pc.in |   11 +
>  ipvr/test_decode.c | 6773 
> 
>  ipvr/test_ioctl.c  |  332 +++
>  11 files changed, 9500 insertions(+), 2 deletions(-)
>  create mode 100644 include/drm/ipvr_drm.h
>  create mode 100644 ipvr/Makefile.am
>  create mode 100644 ipvr/Makefile.sources
>  create mode 100644 ipvr/ipvr_bufmgr.h
>  create mode 100644 ipvr/ipvr_bufmgr_gem.c
>  create mode 100644 ipvr/libdrm_ipvr.pc.in
>  create mode 100644 ipvr/test_decode.c
>  create mode 100644 ipvr/test_ioctl.c
> 
> diff --git a/Makefile.am b/Makefile.am
> index 3952a88..2227add 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -33,6 +33,10 @@ if HAVE_INTEL
>  INTEL_SUBDIR = intel
>  endif
>  
> +if HAVE_IPVR
> +IPVR_SUBDIR = ipvr
> +endif
> +
>  if HAVE_NOUVEAU
>  NOUVEAU_SUBDIR = nouveau
>  endif
> @@ -53,7 +57,7 @@ if HAVE_FREEDRENO
>  FREEDRENO_SUBDIR = freedreno
>  endif
>  
> -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
> $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests man
> +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(IPVR_SUBDIR) 
> $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) 
> $(FREEDRENO_SUBDIR) tests man
>  
>  libdrm_la_LTLIBRARIES = libdrm.la
>  libdrm_ladir = $(libdir)
> diff --git a/Makefile.sources b/Makefile.sources
> index d86fb2a..96f8c60 100644
> --- a/Makefile.sources
> +++ b/Makefile.sources
> @@ -18,6 +18,7 @@ LIBDRM_INCLUDE_H_FILES := \
>   include/drm/drm_mode.h \
>   include/drm/drm_sarea.h \
>   include/drm/i915_drm.h \
> + include/drm/ipvr_drm.h \
>   include/drm/mach64_drm.h \
>   include/drm/mga_drm.h \
>   include/drm/nouveau_drm.h \
> diff --git a/configure.ac b/configure.ac
> index ee59b03..6dcf1b2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -68,6 +68,11 @@ AC_ARG_ENABLE(intel,
> [Enable support for intel's KMS API (default: auto)]),
> [INTEL=$enableval], [INTEL=auto])
>  
> +AC_ARG_ENABLE(ipvr,
> +   AS_HELP_STRING([--disable-ipvr],
> +   [Enable support for baytrail's hardware VP8 decode (default: 
> auto)]),
> +   [IPVR=$enableval], [IPVR=auto])
> +
>  AC_ARG_ENABLE(radeon,
> AS_HELP_STRING([--disable-radeon],
> [Enable support for radeon's KMS API (default: auto)]),
> @@ -204,7 +209,7 @@ if test "x$drm_cv_atomic_primitives" = "xlibatomic-ops"; 
> then
>   AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have libatomic-ops-dev 
> installed])
>  fi
>  
> -if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno"; 
> then
> +if test "x$INTEL" != "xno" -o "x$IPVR" != "xno" -o "x$RADEON" != "xno" -o 
> "x$NOUVEAU" != "xno"; then
>   if test "x$drm_cv_atomic_primitives" = "xnone"; then
>   if test "x$INTEL" != "xauto"; then
>   if test "x$INTEL" != "xno"; then
> @@ -214,6 +219,14 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o 
> "x$NOUVEAU" != "xno"; then
>   AC_MSG_WARN([Disabling libdrm_intel. It depends on 
> atomic operations, which were not found for your compiler/cpu. Try compiling 
> with -march=native, or install the libatomics-op-dev package.])
>   INTEL=no
>   fi
> + if test "x$IPVR" != "xauto"; then
> + if test "x$IPVR" != "xno"; then
> + AC_MSG_ERROR([libdrm_ipvr depends upon atomic 
> operations, which were not found for your compiler/cpu. Try compiling with 
> -march=native, or install the libatomics-op-dev package, or, failing both of 
> those, disable support for Baytrail VP8 by passing --disable-ipvr to 
> ./configure])
> + fi
> + else
> + AC_MSG_WARN([Disabling libdrm_ipvr. It depends on 
> atomic operations, which were not found for your compiler/cpu. Try compiling 
> with -march=native, or install the libatomics-op-dev package.])
> + INTEL=no
> + fi
>   if test "x$RADEON" != "xauto"; then
>   if test "x$RADEON" != "xno"; then
>   AC_MSG_ERROR([libdrm_radeon depends upon atomic 
> operations, which were not 

[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED

[Daniel Vetter]

On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> Setup minimum required resources during i915_driver_load:
> 1. Create a platform device to share MMIO/IRQ resources
> 2. Make the platform device child of i915 device for runtime PM.
> 3. Create IRQ chip to forward the VED irqs.
> VED driver (a standalone drm driver) probes the VED device and
> creates a new dri card on install.
> 
> Currently only supports VED on valleyview.
> Kerneldoc is updated for i915_ved.c.
> 
> Signed-off-by: Yao Cheng 

Please resend with a patch changelog to account for my review comments.
And Ville's. Plus cc us both. And if there's anything you didn't address,
you must reply to the review and we need to further discuss this.

Thanks, Daniel
> ---
>  Documentation/DocBook/drm.tmpl  |   5 +
>  drivers/gpu/drm/i915/Makefile   |   3 +
>  drivers/gpu/drm/i915/i915_dma.c |  11 ++
>  drivers/gpu/drm/i915/i915_drv.h |   9 ++
>  drivers/gpu/drm/i915/i915_irq.c |   2 +
>  drivers/gpu/drm/i915/i915_reg.h |   5 +
>  drivers/gpu/drm/i915/i915_ved.c | 264 
> 
>  7 files changed, 299 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/i915_ved.c
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index d7cfc98..f1787b4 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3806,6 +3806,11 @@ int num_ioctls;
>  !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
>  !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
>
> +  
> +VED video core integration
> +!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
> +!Idrivers/gpu/drm/i915/i915_ved.c
> +  
>  
>  
>Display Hardware Handling
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 3a6bce0..a4b9252 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -80,6 +80,9 @@ i915-y += dvo_ch7017.o \
>  i915-y += i915_dma.o \
> i915_ums.o
>  
> +# VED for VLV
> +i915-y += i915_ved.o
> +
>  obj-$(CONFIG_DRM_I915)  += i915.o
>  
>  CFLAGS_i915_trace_points.o := -I$(src)
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 85d14e1..47714e1 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1791,6 +1791,13 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   if (IS_GEN5(dev))
>   intel_gpu_ips_init(dev_priv);
>  
> + if (IS_VALLEYVIEW(dev)) {
> + ret = vlv_setup_ved(dev);
> + if (ret < 0) {
> + DRM_ERROR("failed to setup VED bridge: %d\n", ret);
> + }
> + }
> +
>   intel_runtime_pm_enable(dev_priv);
>  
>   return 0;
> @@ -1833,6 +1840,10 @@ int i915_driver_unload(struct drm_device *dev)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> + if (IS_VALLEYVIEW(dev)) {
> + vlv_teardown_ved(dev);
> + }
> +
>   ret = i915_gem_suspend(dev);
>   if (ret) {
>   DRM_ERROR("failed to idle hardware: %d\n", ret);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 821ba26..952df34 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1709,6 +1709,10 @@ struct drm_i915_private {
>  
>   uint32_t bios_vgacntr;
>  
> + /* used for setup VED bridge */
> + struct platform_device *ved_platdev;
> + int ved_irq;
> +
>   /* Old dri1 support infrastructure, beware the dragons ya fools entering
>* here! */
>   struct i915_dri1_state dri1;
> @@ -2785,6 +2789,11 @@ void i915_restore_display_reg(struct drm_device *dev);
>  void i915_setup_sysfs(struct drm_device *dev_priv);
>  void i915_teardown_sysfs(struct drm_device *dev_priv);
>  
> +/* i915_ved.c */
> +int vlv_setup_ved(struct drm_device *dev);
> +void vlv_teardown_ved(struct drm_device *dev);
> +void vlv_ved_irq_handler(struct drm_device *dev);
> +
>  /* intel_i2c.c */
>  extern int intel_setup_gmbus(struct drm_device *dev);
>  extern void intel_teardown_gmbus(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 737b239..68c2977 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2177,6 +2177,8 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
> *arg)
>   snb_gt_irq_handler(dev, dev_priv, gt_iir);
>   if (pm_iir)
>   gen6_rps_irq_handler(dev_priv, pm_iir);
> + if (IS_VALLEYVIEW(dev) && (iir & VLV_VED_BLOCK_INTERRUPT))
> + vlv_ved_irq_handler(dev);
>   /* Call regardless, as some status bits might not be
>* signalled in iir */
>   valleyview_pipestat_irq_handler(dev, iir);
> diff --git 

[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO

[Darren Hart]

On Sat, Oct 18, 2014 at 12:13:23AM +0300, Jani Nikula wrote:
> Documentation/kbuild/kconfig-language.txt warns to use select with care,
> and in general use select only for non-visible symbols and for symbols
> with no dependencies, because select will force a symbol to a value
> without visiting the dependencies.
> 
> Select has become particularly problematic, interdependently, with the
> BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example:
> 
> scripts/kconfig/conf --randconfig Kconfig
> KCONFIG_SEED=0x48312B00
> warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 &&
> DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY
> && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI &&
> EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
> which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)
> warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 &&
> DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY
> && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI &&
> EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
> which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)
> 
> With tristates it's possible to end up selecting FOO=y depending on
> BAR=m in the config, which gets discovered at build time, not config
> time, like reported in the thread referenced below.
> 
> Do the following to fix the dependencies:
> 
> * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop
>   select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of
>   BACKLIGHT_CLASS_DEVICE.
> 
> * Remove config FB_BACKLIGHT altogether, and replace it with a
>   dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting
>   FB_BACKLIGHT select or depend on FB anyway, so we can simplify.
> 
> * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of
>   selecting ACPI_VIDEO and a number of its dependencies if ACPI is
>   enabled. This is tied to backlight, as ACPI_VIDEO depends on
>   BACKLIGHT_CLASS_DEVICE.
> 
> * Replace a couple of select INPUT/VT with depends as it seemed to be
>   necessary.
> 
> Reference: 
> http://lkml.kernel.org/r/CA+r1ZhhmT4DrWtf6MbRQo5EqXwx+LxCqh15Vsu_d9WpftLhnxw 
> at mail.gmail.com
> Reported-by: Jim Davis 
> Cc: Randy Dunlap 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Greg Kroah-Hartman 
> Cc: Darren Hart 
> Cc: Laurent Pinchart 
> Cc: Benjamin Herrenschmidt 
> Cc: Jens Frederich 
> Cc: Daniel Drake 
> Cc: Jon Nettleton 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Signed-off-by: Jani Nikula 

As for the drivers/platform/x86/Kconfig:

Acked-by: Darren Hart 

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED

[Ville Syrjälä]

On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> Setup minimum required resources during i915_driver_load:
> 1. Create a platform device to share MMIO/IRQ resources
> 2. Make the platform device child of i915 device for runtime PM.
> 3. Create IRQ chip to forward the VED irqs.
> VED driver (a standalone drm driver) probes the VED device and
> creates a new dri card on install.
> 
> Currently only supports VED on valleyview.
> Kerneldoc is updated for i915_ved.c.
> 
> Signed-off-by: Yao Cheng 
> ---
>  Documentation/DocBook/drm.tmpl  |   5 +
>  drivers/gpu/drm/i915/Makefile   |   3 +
>  drivers/gpu/drm/i915/i915_dma.c |  11 ++
>  drivers/gpu/drm/i915/i915_drv.h |   9 ++
>  drivers/gpu/drm/i915/i915_irq.c |   2 +
>  drivers/gpu/drm/i915/i915_reg.h |   5 +
>  drivers/gpu/drm/i915/i915_ved.c | 264 
> 
>  7 files changed, 299 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/i915_ved.c
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index d7cfc98..f1787b4 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3806,6 +3806,11 @@ int num_ioctls;
>  !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
>  !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
>
> +  
> +VED video core integration
> +!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
> +!Idrivers/gpu/drm/i915/i915_ved.c
> +  
>  
>  
>Display Hardware Handling
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 3a6bce0..a4b9252 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -80,6 +80,9 @@ i915-y += dvo_ch7017.o \
>  i915-y += i915_dma.o \
> i915_ums.o
>  
> +# VED for VLV
> +i915-y += i915_ved.o
> +
>  obj-$(CONFIG_DRM_I915)  += i915.o
>  
>  CFLAGS_i915_trace_points.o := -I$(src)
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 85d14e1..47714e1 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1791,6 +1791,13 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   if (IS_GEN5(dev))
>   intel_gpu_ips_init(dev_priv);
>  
> + if (IS_VALLEYVIEW(dev)) {

These must be (IS_VLV && !IS_CHV), or maybe define some HAS_VED() macro
to hide that.

> + ret = vlv_setup_ved(dev);
> + if (ret < 0) {
> + DRM_ERROR("failed to setup VED bridge: %d\n", ret);
> + }
> + }
> +
>   intel_runtime_pm_enable(dev_priv);
>  
>   return 0;
> @@ -1833,6 +1840,10 @@ int i915_driver_unload(struct drm_device *dev)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> + if (IS_VALLEYVIEW(dev)) {
> + vlv_teardown_ved(dev);
> + }
> +
>   ret = i915_gem_suspend(dev);
>   if (ret) {
>   DRM_ERROR("failed to idle hardware: %d\n", ret);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 821ba26..952df34 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1709,6 +1709,10 @@ struct drm_i915_private {
>  
>   uint32_t bios_vgacntr;
>  
> + /* used for setup VED bridge */
> + struct platform_device *ved_platdev;
> + int ved_irq;
> +

Could be neater to wrap this in a struct:

struct {
struct platform_device *platdev;
int irq;
} ved;


>   /* Old dri1 support infrastructure, beware the dragons ya fools entering
>* here! */
>   struct i915_dri1_state dri1;
> @@ -2785,6 +2789,11 @@ void i915_restore_display_reg(struct drm_device *dev);
>  void i915_setup_sysfs(struct drm_device *dev_priv);
>  void i915_teardown_sysfs(struct drm_device *dev_priv);
>  
> +/* i915_ved.c */
> +int vlv_setup_ved(struct drm_device *dev);
> +void vlv_teardown_ved(struct drm_device *dev);
> +void vlv_ved_irq_handler(struct drm_device *dev);
> +
>  /* intel_i2c.c */
>  extern int intel_setup_gmbus(struct drm_device *dev);
>  extern void intel_teardown_gmbus(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 737b239..68c2977 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2177,6 +2177,8 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
> *arg)
>   snb_gt_irq_handler(dev, dev_priv, gt_iir);
>   if (pm_iir)
>   gen6_rps_irq_handler(dev_priv, pm_iir);
> + if (IS_VALLEYVIEW(dev) && (iir & VLV_VED_BLOCK_INTERRUPT))
> + vlv_ved_irq_handler(dev);

This is the vlv irq handler so no need to check the platform type.

>   /* Call regardless, as some status bits might not be
>* signalled in iir */
>   

[PATCH v2 01/15] drm/dsi: Make mipi_dsi_dcs_{read,write}() symmetrical

[Andrzej Hajda]

On 10/21/2014 01:10 PM, Andrzej Hajda wrote:
> On 10/14/2014 11:00 AM, Thierry Reding wrote:
>> On Mon, Oct 13, 2014 at 02:29:15PM +0200, Andrzej Hajda wrote:
>>> Hi Thierry,
>>>
>>> On 10/13/2014 12:16 PM, Thierry Reding wrote:
 From: Thierry Reding 

 Currently the mipi_dsi_dcs_write() function requires the DCS command
 byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
 has a separate parameter. Make them more symmetrical by adding an extra
 command parameter to mipi_dsi_dcs_write().
>>> As we discussed before I do not see much symmetry here - dcs read is
>>> a kind of write command with non empty response.
>> The symmetry is in the API. DCS is a command specification, therefore
>> the command is the primary means of identification. Hiding the command
>> inside the payload buffer obfuscates in my opinion. Using an explicit
>> command parameter makes it immediately obvious from the function call
>> what command is being sent without having to look up the static buffer
>> where the command byte is embedded.
> 
> 1. According to specs command is an integral part of the payload,
> separating it from the payload is unnatural.
> 2. It is rather difficult to obfuscate command using static buffers, you can
>   use variadic macros as in panel_s6e8aa0.c, for example:
> mipi_dsi_dcs(dsi, MIPI_DCS_SET_PIXEL_FORMAT, 13);
>   it is the nicest way IMHO - you do not need to pass to the call extra
> arguments,
>   neither number of parameters, neither pointers, you just pass command
>   and its parameters.
> 
>   But if you do not like variadic macros you can still use static buffers:
> u8 dcs_set_pixel_format[] = {MIPI_DCS_SET_PIXEL_FORMAT, 13};
> ...
> mipi_dsi_dcs_write(dsi, dcs_set_pixel_format,
> ARRAY_SIZE(dcs_set_pixel_format));
> 
>   As you see you should pass buffer name, which should clearly indicate
>   what is its content, again no obfuscation.
> 
> Again, if it does not convince you I am fine with this patch. It leaves
> the possibility
> to use 'old' API, so it is OK to me.

To be more precise, I am fine with introduction of 'symmetrical' API,
there other issues regarding this patch which were discussed elsewhere.

Regards
Andrzej

[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85207

--- Comment #5 from Andy Furniss  ---
(In reply to Christian K?nig from comment #4)
> Created attachment 108165 [details] [review]
> Possible fix
> 
> Ups! Forgotten to take the VM lock in radeon_gem_va_update_vm. Fix is
> attached.
> 
> Thanks for testing,
> Christian.

I don't know about Elemental as it's far harder to trigger, but first try with
valley produced -

[  156.617954] radeon :01:00.0: GPU fault detected: 146 0x02e83504
[  156.617960] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00010F17
[  156.617961] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x08035004
[  156.617963] VM fault (0x04, vmid 4) at page 69399, read from VGT (53)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/684e319b/attachment-0001.html>

[PATCH v2 01/15] drm/dsi: Make mipi_dsi_dcs_{read,write}() symmetrical

[Andrzej Hajda]

On 10/14/2014 11:00 AM, Thierry Reding wrote:
> On Mon, Oct 13, 2014 at 02:29:15PM +0200, Andrzej Hajda wrote:
>> Hi Thierry,
>>
>> On 10/13/2014 12:16 PM, Thierry Reding wrote:
>>> From: Thierry Reding 
>>>
>>> Currently the mipi_dsi_dcs_write() function requires the DCS command
>>> byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
>>> has a separate parameter. Make them more symmetrical by adding an extra
>>> command parameter to mipi_dsi_dcs_write().
>> As we discussed before I do not see much symmetry here - dcs read is
>> a kind of write command with non empty response.
> The symmetry is in the API. DCS is a command specification, therefore
> the command is the primary means of identification. Hiding the command
> inside the payload buffer obfuscates in my opinion. Using an explicit
> command parameter makes it immediately obvious from the function call
> what command is being sent without having to look up the static buffer
> where the command byte is embedded.

1. According to specs command is an integral part of the payload,
separating it from the payload is unnatural.
2. It is rather difficult to obfuscate command using static buffers, you can
  use variadic macros as in panel_s6e8aa0.c, for example:
mipi_dsi_dcs(dsi, MIPI_DCS_SET_PIXEL_FORMAT, 13);
  it is the nicest way IMHO - you do not need to pass to the call extra
arguments,
  neither number of parameters, neither pointers, you just pass command
  and its parameters.

  But if you do not like variadic macros you can still use static buffers:
u8 dcs_set_pixel_format[] = {MIPI_DCS_SET_PIXEL_FORMAT, 13};
...
mipi_dsi_dcs_write(dsi, dcs_set_pixel_format,
ARRAY_SIZE(dcs_set_pixel_format));

  As you see you should pass buffer name, which should clearly indicate
  what is its content, again no obfuscation.

Again, if it does not convince you I am fine with this patch. It leaves
the possibility
to use 'old' API, so it is OK to me.

Regards
Andrzej

[Bug 79980] Random radeonsi crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #172 from darkbasic  ---
Sorry I meant 3.15-rc0 and 3.15-rc*3*.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/f3039402/attachment.html>

[Bug 79980] Random radeonsi crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #171 from darkbasic  ---
On my system with 3.17+ sometimes it takes days to crash while sometimes it
crashes after a few minutes. Only 3.15 did *always* crash in a couple of
minutes. I remember 3.15-rc1-pre didn't crash, so the bad commit should be
somewhere around 3.15-rc0 and 3.15-rc2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/45a1fcaa/attachment.html>

[PATCH 08/15] drm/dsi: Implement DCS nop command

[Andrzej Hajda]

On 10/13/2014 12:16 PM, Thierry Reding wrote:
> From: Thierry Reding 
>
> Provide a small convenience wrapper that transmits a DCS nop command.
>
> Signed-off-by: Thierry Reding 

For this and patches 09, 11, 12 the same comments apply as for 06/15.
Beside this they look OK to me.


Regards
Andrzej

> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 18 ++
>  include/drm/drm_mipi_dsi.h |  1 +
>  2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 6749b88a6c72..c88dcda2f4ac 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -517,6 +517,24 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, 
> u8 cmd, void *data,
>  EXPORT_SYMBOL(mipi_dsi_dcs_read);
>  
>  /**
> + * mipi_dsi_dcs_nop() - send DCS nop packet
> + * @dsi: DSI peripheral device
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi)
> +{
> + ssize_t err;
> +
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_NOP, NULL, 0);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_nop);
> +
> +/**
>   * mipi_dsi_dcs_enter_sleep_mode() - disable all unnecessary blocks inside 
> the
>   *display module except interface communication
>   * @dsi: DSI peripheral device
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 8693711eb623..be16c8e769bd 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -170,6 +170,7 @@ ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, 
> u8 cmd,
>  const void *data, size_t len);
>  ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data,
> size_t len);
> +int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_set_display_off(struct mipi_dsi_device *dsi);

[PATCH 10/15] drm/dsi: Implement DCS get_power_mode command

[Andrzej Hajda]

On 10/13/2014 12:16 PM, Thierry Reding wrote:
> From: Thierry Reding 
>
> Provide a small convenience wrapper that transmits a DCS get_power_mode
> command. A set of bitmasks for the mode bits is also provided.
>
> Signed-off-by: Thierry Reding 
Besides one nitpick below.

Acked-by: Andrzej Hajda 

---
 drivers/gpu/drm/drm_mipi_dsi.c | 21 +
 include/drm/drm_mipi_dsi.h |  7 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 60bd68b520ae..4e016a6a9fc3 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -553,6 +553,27 @@ int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi)
 EXPORT_SYMBOL(mipi_dsi_dcs_soft_reset);

 /**
+ * mipi_dsi_dcs_get_power_mode() - query the display module's current power
+ *mode
+ * @dsi: DSI peripheral device
+ * @mode: return location for the current power mode
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode)
+{
+   ssize_t err;
+
+   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_POWER_MODE, mode,
+   sizeof(*mode));
+   if (err < 0)
+   return err;
+
+   return 0;


Maybe better would be:
if (err == 1)
return 0;

return err < 0 ? err : -ENODATA;

Or sth similar.

I wonder also if it would not be better to make the function inline ?

> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_get_power_mode);
> +
> +/**
>   * mipi_dsi_dcs_enter_sleep_mode() - disable all unnecessary blocks inside 
> the
>   *display module except interface communication
>   * @dsi: DSI peripheral device
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 2afbd5853f78..b659b99ac890 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -164,6 +164,12 @@ enum mipi_dsi_dcs_tear_mode {
>   MIPI_DSI_DCS_TEAR_MODE_VHBLANK,
>  };
>  
> +#define MIPI_DSI_DCS_POWER_MODE_DISPLAY (1 << 2)
> +#define MIPI_DSI_DCS_POWER_MODE_NORMAL  (1 << 3)
> +#define MIPI_DSI_DCS_POWER_MODE_SLEEP   (1 << 4)
> +#define MIPI_DSI_DCS_POWER_MODE_PARTIAL (1 << 5)
> +#define MIPI_DSI_DCS_POWER_MODE_IDLE(1 << 6)
> +
>  ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi,
> const void *data, size_t len);
>  ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, u8 cmd,
> @@ -172,6 +178,7 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 
> cmd, void *data,
> size_t len);
>  int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
> +int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
>  int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
>  int mipi_dsi_dcs_set_display_off(struct mipi_dsi_device *dsi);

[PATCH 07/15] drm/dsi: Add to DocBook documentation

[Andrzej Hajda]

On 10/13/2014 12:16 PM, Thierry Reding wrote:
> From: Thierry Reding 
>
> Integrate the MIPI DSI helpers into DocBook and clean up various
> kerneldoc warnings. Also add a brief DOC section and clarify some
> aspects of the mipi_dsi_host struct's .transfer() operation.
>
> Signed-off-by: Thierry Reding 
Thanks

Acked-by: Andrzej Hajda 
--
Regards
Andrzej
> ---
>  Documentation/DocBook/drm.tmpl |  6 ++
>  drivers/gpu/drm/drm_mipi_dsi.c | 18 --
>  include/drm/drm_mipi_dsi.h | 16 ++--
>  3 files changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index be35bc328b77..da733c28c92f 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2343,6 +2343,12 @@ void intel_crt_init(struct drm_device *dev)
>  !Edrivers/gpu/drm/drm_dp_mst_topology.c
>  
>  
> +  MIPI DSI Helper Functions Reference
> +!Pdrivers/gpu/drm/drm_mipi_dsi.c dsi helpers
> +!Iinclude/drm/drm_mipi_dsi.h
> +!Edrivers/gpu/drm/drm_mipi_dsi.c
> +
> +
>EDID Helper Functions Reference
>  !Edrivers/gpu/drm/drm_edid.c
>  
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 8bb38db861ec..6749b88a6c72 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -35,6 +35,16 @@
>  
>  #include 
>  
> +/**
> + * DOC: dsi helpers
> + *
> + * These functions contain some common logic and helpers to deal with MIPI 
> DSI
> + * peripherals.
> + *
> + * Helpers are provided for a number of standard MIPI DSI command as well as 
> a
> + * subset of the MIPI DCS command set.
> + */
> +
>  static int mipi_dsi_device_match(struct device *dev, struct device_driver 
> *drv)
>  {
>   return of_driver_match_device(dev, drv);
> @@ -649,8 +659,10 @@ static void mipi_dsi_drv_shutdown(struct device *dev)
>  }
>  
>  /**
> - * mipi_dsi_driver_register - register a driver for DSI devices
> + * mipi_dsi_driver_register() - register a driver for DSI devices
>   * @drv: DSI driver structure
> + *
> + * Return: 0 on success or a negative error code on failure.
>   */
>  int mipi_dsi_driver_register(struct mipi_dsi_driver *drv)
>  {
> @@ -667,8 +679,10 @@ int mipi_dsi_driver_register(struct mipi_dsi_driver *drv)
>  EXPORT_SYMBOL(mipi_dsi_driver_register);
>  
>  /**
> - * mipi_dsi_driver_unregister - unregister a driver for DSI devices
> + * mipi_dsi_driver_unregister() - unregister a driver for DSI devices
>   * @drv: DSI driver structure
> + *
> + * Return: 0 on success or a negative error code on failure.
>   */
>  void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv)
>  {
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index bde663725a58..8693711eb623 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -26,6 +26,7 @@ struct mipi_dsi_device;
>   * struct mipi_dsi_msg - read/write DSI buffer
>   * @channel: virtual channel id
>   * @type: payload data type
> + * @flags: flags controlling this message transmission
>   * @tx_len: length of @tx_buf
>   * @tx_buf: data to be written
>   * @rx_len: length of @rx_buf
> @@ -47,8 +48,19 @@ struct mipi_dsi_msg {
>   * struct mipi_dsi_host_ops - DSI bus operations
>   * @attach: attach DSI device to DSI host
>   * @detach: detach DSI device from DSI host
> - * @transfer: send and/or receive DSI packet, return number of received 
> bytes,
> - * or error
> + * @transfer: transmit a DSI packet
> + *
> + * DSI packets transmitted by .transfer() are passed in as mipi_dsi_msg
> + * structures. This structure contains information about the type of packet
> + * being transmitted as well as the transmit and receive buffers. When an
> + * error is encountered during transmission, this function will return a
> + * negative error code. On success it shall return the number of bytes
> + * transmitted for write packets or the number of bytes received for read
> + * packets.
> + *
> + * Note that typically DSI packet transmission is atomic, so the .transfer()
> + * function will seldomly return anything other than the number of bytes
> + * contained in the transmit buffer on success.
>   */
>  struct mipi_dsi_host_ops {
>   int (*attach)(struct mipi_dsi_host *host,

[RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

ping!

On Fri, Oct 10, 2014 at 6:18 PM, Ajay Kumar  wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals using pixel data.
>
> DECON driver can be used to drive 2 different interfaces on Exynos7:
> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>
> The existing FIMD driver code was used as a template to create
> DECON driver. Only DECON-INT is supported as of now, and
> DECON-EXT support will be added later.
>
> Signed-off-by: Akshu Agrawal 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/exynos-decon.txt |   68 ++
>  drivers/gpu/drm/exynos/Kconfig |   11 +-
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos_drm_decon.c  | 1086 
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   17 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|   11 +
>  include/video/samsung_decon.h  |  346 +++
>  7 files changed, 1537 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
>  create mode 100644 include/video/samsung_decon.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt 
> b/Documentation/devicetree/bindings/video/exynos-decon.txt
> new file mode 100644
> index 000..e865650
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
> @@ -0,0 +1,68 @@
> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
> +
> +DECON (Display and Enhancement Controller) is the Display Controller for the
> +Exynos7 series of SoCs which transfers the image data from a video memory
> +buffer to an external LCD interface.
> +
> +Required properties:
> +- compatible: value should be "samsung,exynos7-decon";
> +
> +- reg: physical base address and length of the DECON registers set.
> +
> +- interrupt-parent: should be the phandle of the decon controller's
> +   parent interrupt controller.
> +
> +- interrupts: should contain a list of all DECON IP block interrupts in the
> +order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
> +format depends on the interrupt controller used.
> +
> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
> +   "lcd_sys", in the same order as they were listed in the interrupts
> +property.
> +
> +- pinctrl-0: pin control group to be used for this controller.
> +
> +- pinctrl-names: must contain a "default" entry.
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: list of clock names sorted in the same order as the clocks
> +   property. Must contain "pclk_decon0", "aclk_decon0",
> +  "decon0_eclk", "decon0_vclk", "sclk_dsd", aclk_lh_disp0",
> +  "aclk_disp", "aclk_lh_disp1".
> +
> +Optional Properties:
> +- samsung,power-domain: a phandle to DECON power domain node.
> +
> +Example:
> +
> +SoC specific DT entry:
> +
> +   decon at 1393 {
> +   compatible = "samsung,exynos7-decon";
> +   interrupt-parent = <>;
> +   reg = <0x1393 0x1000>;
> +   interrupt-names = "lcd_sys", "vsync", "fifo";
> +   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> +   clocks = <_disp PCLK_DECON_INT>,
> +<_disp ACLK_DECON_INT>,
> +<_disp SCLK_DECON_INT_ECLK>,
> +<_disp SCLK_DECON_INT_EXTCLKPLL>,
> +<_disp SCLK_DSD>,
> +<_bus0 ACLK_LH_DISP0>,
> +<_disp ACLK_CP_DISP>,
> +<_bus0 ACLK_LH_DISP1>;
> +   clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
> +   "decon0_vclk", "sclk_dsd", "aclk_lh_disp0",
> +   "aclk_disp", "aclk_lh_disp1";
> +   status = "disabled";
> +   };
> +
> +Board specific DT entry:
> +
> +   decon at 1393 {
> +   pinctrl-0 = <_clk _out>;
> +   pinctrl-names = "default";
> +   status = "okay";
> +   };
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index fd1c070..89275ea 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -31,6 +31,13 @@ config DRM_EXYNOS_FIMD
> help
>   Choose this option if you want to use Exynos FIMD for DRM.
>
> +config DRM_EXYNOS_DECON
> +   bool "Exynos DRM DECON"
> +   depends on DRM_EXYNOS
> +   select FB_MODE_HELPERS
> +   help
> + Choose this 

[Intel-gfx] [RFC PATCH v2 2/4] drm/ipvr: drm driver for VED

[Daniel Vetter]

On Tue, Oct 21, 2014 at 02:36:42PM +0800, Yao Cheng wrote:
> Probes VED and creates a new drm device for hardware accelerated
> video decoding.
> Currently support VP8 decoding on valleyview.
> 
> Signed-off-by: Yao Cheng 

The in-patch changelog here is missing, and there's also no indication in
the cover letter for what changes you've made. On a quick look you've
incorporated some of David's feedback, but not all of it. That's not good,
since if you only partially apply review feedback then you essentially
force reviewers to read the entire patch again, which is a good way to
driver them away. Also you should Cc: (in the sob section of the patch)
all the people who have commented on your patch already.

With that out of the way some high-level review:
- I think we need the full libva implementation to review the interfaces
  properly. At least the little libdrm test program doesn't seem to fully
  exercise it all.

- The ioctl structs need to be cleaned up. You can't use uint32_t and
  similar typedefs since they can clash with userspace. You must use __u32
  and friends. Also, some of the padding fields arent' really required -
  if you only have 4byte types then you don't need to align to 8 bytes.

- Input validation on ioctls looks spotty at best. E.g. if you have any
  padding fields you need to check that they are 0, otherwise we can't
  ever reuse them as flags fields. And on principle _all_ input fields
  must be validated first.

  For some good guidelines for ioctls see
  http://blog.ffwll.ch/2013/11/botching-up-ioctls.html

- Locking seems to be inexistent in places, at least some of the idr
  manipulation very much looks like it's done lock-free. That doesn't work
  well.

- You implement file-descriptor based fences, but then also have the more
  gem-traditional wait ioctl working on buffer objects. That's a bit a
  funky mix of implicit and explicit fencing. Furthermore adding new
  private fence objects isn't a good idea now that everyon is talking
  about de-staging android syncpts as the official userspace interface.

  Also, your userspace patches don't use this, so maybe we can just rip it
  all out?

- I'm a bit unclear on your usage of vxd_/pvr_ prefixes.

The driver is fairly big and I don't really have the time to do a full
blown review of even just the interfaces. I think we need to have some
internal discussions about how to do this, but meanwhile we can cover some
of the high-level bits.

Cheers, Daniel
> ---
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/ipvr/Kconfig   |   16 +
>  drivers/gpu/drm/ipvr/Makefile  |   21 +
>  drivers/gpu/drm/ipvr/ipvr_buffer.c | 1264 +++
>  drivers/gpu/drm/ipvr/ipvr_buffer.h |  188 ++
>  drivers/gpu/drm/ipvr/ipvr_debug.c  |  263 
>  drivers/gpu/drm/ipvr/ipvr_debug.h  |   50 ++
>  drivers/gpu/drm/ipvr/ipvr_drm.h|  267 
>  drivers/gpu/drm/ipvr/ipvr_drv.c|  759 +
>  drivers/gpu/drm/ipvr/ipvr_drv.h|  442 +
>  drivers/gpu/drm/ipvr/ipvr_exec.c   |  530 +++
>  drivers/gpu/drm/ipvr/ipvr_exec.h   |   68 ++
>  drivers/gpu/drm/ipvr/ipvr_fence.c  |  550 
>  drivers/gpu/drm/ipvr/ipvr_fence.h  |   68 ++
>  drivers/gpu/drm/ipvr/ipvr_gem.c|  191 ++
>  drivers/gpu/drm/ipvr/ipvr_gem.h|   46 ++
>  drivers/gpu/drm/ipvr/ipvr_mmu.c|  807 +++
>  drivers/gpu/drm/ipvr/ipvr_mmu.h|  135 
>  drivers/gpu/drm/ipvr/ipvr_trace.c  |   11 +
>  drivers/gpu/drm/ipvr/ipvr_trace.h  |  296 +
>  drivers/gpu/drm/ipvr/ved_cmd.c | 1269 
> 
>  drivers/gpu/drm/ipvr/ved_cmd.h |  104 +++
>  drivers/gpu/drm/ipvr/ved_ec.c  |  584 +
>  drivers/gpu/drm/ipvr/ved_ec.h  |  207 ++
>  drivers/gpu/drm/ipvr/ved_fw.c  |  660 +++
>  drivers/gpu/drm/ipvr/ved_fw.h  |   73 +++
>  drivers/gpu/drm/ipvr/ved_init.c|  829 +++
>  drivers/gpu/drm/ipvr/ved_init.h|   61 ++
>  drivers/gpu/drm/ipvr/ved_msg.h |  364 +++
>  drivers/gpu/drm/ipvr/ved_pm.c  |  392 +++
>  drivers/gpu/drm/ipvr/ved_pm.h  |   55 ++
>  drivers/gpu/drm/ipvr/ved_reg.h |  609 +
>  33 files changed, 11182 insertions(+)
>  create mode 100644 drivers/gpu/drm/ipvr/Kconfig
>  create mode 100644 drivers/gpu/drm/ipvr/Makefile
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_buffer.c
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_buffer.h
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_debug.c
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_debug.h
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_drm.h
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_drv.c
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_drv.h
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_exec.c
>  create mode 100644 drivers/gpu/drm/ipvr/ipvr_exec.h
>  create mode 100644 

[Bug 79980] Random radeonsi crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #170 from Jacob  ---
(In reply to DJ Dunn from comment #168)
> if this helps any, I've been seeing the same error on my gentoo box, its
> near constant on 3.16+ kernels within 2 or 3 min of loging in X but, ive
> been seeing it very rarely (once every few hours) on 3.14.22 but still
> seeing it, and I never seen it happen on 3.14.19
> 
> gentoo box with mesa-10.3.1 xorg-server-1.16.1

Could you test 3.14.20 and 3.14.21, to see if the issue also occur in any of
those, then do a bisection between the first version where the crashes started
to occur, and the version prior to it?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/6daa811b/attachment.html>

[PATCH] gpu:drm: Fix typo in Documentation/DocBook/drm.xml

[Daniel Vetter]

On Mon, Oct 20, 2014 at 10:00:20AM -0700, Randy Dunlap wrote:
> On 10/20/14 07:53, Masanari Iida wrote:
> > This patch fix spelling typos found in drm.xml.
> > It is because the file is generated from comments in
> > source codes, I have to fix the typos within source files.
> > 
> > Signed-off-by: Masanari Iida 
> 
> Acked-by: Randy Dunlap 

Applied to my drm trivial patch queue to make sure it won't get lost.
Should show up in linux-next soonish.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 06/15] drm/dsi: Implement some standard DCS commands

[Andrzej Hajda]

On 10/13/2014 12:16 PM, Thierry Reding wrote:
> From: YoungJun Cho 
>
> Add helpers for the {enter,exit}_sleep_mode, set_display_{on,off} and
> set_tear_{on,off} DCS commands.
>
> Signed-off-by: YoungJun Cho 
> [treding: kerneldoc and other minor cleanup]
> Signed-off-by: Thierry Reding 

The code below clearly shows that returning number of written bytes
by mipi_dsi_dcs_write is useless and causes only code bloat.
If mipi_dsi_dcs_write would return only error these function could be
written as static inlines in header file, for example:

static inline int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi)
{
return mipi_dsi_dcs_write(dsi, MIPI_DCS_ENTER_SLEEP_MODE, NULL, 0);
}

Regards
Andrzej

> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 118 
> +
>  include/drm/drm_mipi_dsi.h |  19 +++
>  2 files changed, 137 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 7cd69273dbad..8bb38db861ec 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -506,6 +506,124 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, 
> u8 cmd, void *data,
>  }
>  EXPORT_SYMBOL(mipi_dsi_dcs_read);
>  
> +/**
> + * mipi_dsi_dcs_enter_sleep_mode() - disable all unnecessary blocks inside 
> the
> + *display module except interface communication
> + * @dsi: DSI peripheral device
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi)
> +{
> + ssize_t err;
> +
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_ENTER_SLEEP_MODE, NULL, 0);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_enter_sleep_mode);
> +
> +/**
> + * mipi_dsi_dcs_exit_sleep_mode() - enable all blocks inside the display
> + *module
> + * @dsi: DSI peripheral device
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi)
> +{
> + ssize_t err;
> +
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_EXIT_SLEEP_MODE, NULL, 0);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_exit_sleep_mode);
> +
> +/**
> + * mipi_dsi_dcs_set_display_off() - stop displaying the image data on the
> + *display device
> + * @dsi: DSI peripheral device
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_set_display_off(struct mipi_dsi_device *dsi)
> +{
> + ssize_t err;
> +
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_DISPLAY_OFF, NULL, 0);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_set_display_off);
> +
> +/**
> + * mipi_dsi_dcs_set_display_on() - start displaying the image data on the
> + *display device
> + * @dsi: DSI peripheral device
> + *
> + * Return: 0 on success or a negative error code on failure
> + */
> +int mipi_dsi_dcs_set_display_on(struct mipi_dsi_device *dsi)
> +{
> + ssize_t err;
> +
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_DISPLAY_ON, NULL, 0);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_set_display_on);
> +
> +/**
> + * mipi_dsi_dcs_set_tear_off() - turn off the display module's Tearing Effect
> + *output signal on the TE signal line
> + * @dsi: DSI peripheral device
> + *
> + * Return: 0 on success or a negative error code on failure
> + */
> +int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi)
> +{
> + ssize_t err;
> +
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_TEAR_OFF, NULL, 0);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_off);
> +
> +/**
> + * mipi_dsi_dcs_set_tear_on() - turn on the display module's Tearing Effect
> + *output signal on the TE signal line.
> + * @dsi: DSI peripheral device
> + * @mode: the Tearing Effect Output Line mode
> + *
> + * Return: 0 on success or a negative error code on failure
> + */
> +int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
> +  enum mipi_dsi_dcs_tear_mode mode)
> +{
> + u8 value = mode;
> + ssize_t err;
> +
> + err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_TEAR_ON, ,
> +  sizeof(value));
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
> +
>  static int mipi_dsi_drv_probe(struct device *dev)
>  {
>   struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 92ca66306702..bde663725a58 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -140,12 +140,31 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device 
> *dsi, const void *payload,
>  

[Bug 84944] tearing on radeonsi vdpau deinterlacer

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84944

--- Comment #14 from warpme at o2.pl ---
(In reply to Christian K?nig from comment #13)

> 
> Page flipping operations are tear free, so what we see here is that without
> deinterlacing the graphics stack uses page flipping and with deinterlacing
> it uses glamor with of course results in badly tearing of the video.

Indeed - infrastructure for flipping seems to be ready:


[837858.379] (II) RADEON(0): KMS Pageflipping: enabled
[837858.379] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[837858.389] (II) RADEON(0): Output HDMI-0 using monitor section Monitor1

> 
> The question is why the heck do we fallback to a copy operation with glamor
> when deinterlacing is enabled? 

If You believe we should do some tests with added debug outputs - I'm more than
happy to do so :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/0b868c75/attachment.html>

[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85207

Christian K?nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #4 from Christian K?nig  ---
Created attachment 108165
  --> https://bugs.freedesktop.org/attachment.cgi?id=108165=edit
Possible fix

Ups! Forgotten to take the VM lock in radeon_gem_va_update_vm. Fix is attached.

Thanks for testing,
Christian.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/d546b8b9/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84944

--- Comment #13 from Christian K?nig  ---
(In reply to warpme from comment #11)
> Maybe Kabini's xserver log output about "EXA not supported" is clue here? Is
> EXA supported on Kabini at all?
> 
> heh - I spent great time to adding glamor to carefully minimized minimyth2
> image - just because on many places it is stated that mesa's radeonsi
> mandatory requires glamor 

Sorry you misunderstood me: Glamor is mandatory on SI, there is not support for
EXA. This is correct.

But glamor shouldn't be used in this situation because we have only one
fullscreen application on the screen. In this situation page flipping should be
used by the X server without any copy operation required by glamor.

Page flipping operations are tear free, so what we see here is that without
deinterlacing the graphics stack uses page flipping and with deinterlacing it
uses glamor with of course results in badly tearing of the video.

The question is why the heck do we fallback to a copy operation with glamor
when deinterlacing is enabled? Deinterlacing is independent of displaying the
video so this makes no sense.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/48b8a68a/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84944

--- Comment #12 from warpme at o2.pl ---
(In reply to Michel D?nzer from comment #10)
> (In reply to Christian K?nig from comment #9)
> > Please try to investigate what MythTV is actually doing different here to
> > cause the page flipping to not work correctly.
> 
> It would be interesting to know why the function can_flip() in
> xf86-video-ati/src/radeon_dri2.c returns FALSE. warpme, if you're familiar
> with gdb, you can attach it (from ssh) to the Xorg process while MythTV is
> running, set a breakpoint at that function and trace its execution.
> Otherwise, we may have to modify the function to print some debugging output.

Oh - minimyth2 is really minimalistic http downloaded, RAM expanded OS image.
Image has only binaries which are a must to run only mythtv. debuging it via
gdb/breakpoints - compared to printing debug outputs - is at least one order of
magnitude bigger task to do :-(
So if it is possible - I really strongly prefer approach with modified
functions to print some debugging outputs.
br

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/a7511e2d/attachment.html>

[GIT PULL] core drm support for Rockchip SoCs

[Mark yao]

Hi, Dave

The following changes since commit bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9:

Linux 3.17 (2014-10-05 12:23:04 -0700)

are available in the git repository at:

https://github.com/markyzq/kernel-drm-rockchip.git  drmrockchip

for you to fetch changes up to 45bb5f4e7e82b30e9e7069c73441413680c9a59f:

dt-bindings: video: Add documentation for rockchip vop (2014-10-17
16:39:31 +0800)


Mark yao (3):
drm: rockchip: Add basic drm driver
dt-bindings: video: Add for rockchip display subsytem
dt-bindings: video: Add documentation for rockchip vop

   .../devicetree/bindings/video/rockchip-drm.txt |   19 +
   .../devicetree/bindings/video/rockchip-vop.txt |   58 +
   drivers/gpu/drm/Kconfig|2 +
   drivers/gpu/drm/Makefile   |1 +
   drivers/gpu/drm/rockchip/Kconfig   |   17 +
   drivers/gpu/drm/rockchip/Makefile  |8 +
   drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  449 ++
   drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   54 +
   drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
   drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
   drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
   drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
   drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  293 
   drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
   drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1427 

   drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
   16 files changed, 3036 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt
   create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt
   create mode 100644 drivers/gpu/drm/rockchip/Kconfig
   create mode 100644 drivers/gpu/drm/rockchip/Makefile
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h

[Bug 85267] vlc crashes with vdpau (Radeon 3850HD) [r600]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85267

--- Comment #2 from Arthur Marsh  ---
Created attachment 108163
  --> https://bugs.freedesktop.org/attachment.cgi?id=108163=edit
log file of running valgrind with default options run against mesa rebuilt with
patch

It appears from this log that the particular error reported in this bug no
longer occurs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/82270595/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84944

--- Comment #11 from warpme at o2.pl ---
(In reply to Christian K?nig from comment #9)
> (In reply to warpme from comment #7)
> > (In reply to Christian K?nig from comment #5)
> > > The deinterlacer is hardware independent and so it's rather unlikely that 
> > > it
> > > is the source of the problem.
> > > 
> > > Can you grab a trace of MythTV with VDPAU_TRACE=1 in the environment once
> > > with and once without deinterlacing enabled? This way we can see what 
> > > MythTV
> > > is actually doing.
> > 
> > Adding VDPAU_TRACE=1 causes stop working VDPAU (MythTV switches to ffmpeg).
> > I can try to investigate this - if You believe it is worth 
> 
> Yes, we should definitely investigate what MythTV is doing here.
> 
> > For me results from tests Michel suggested shows issue is within GLAMOR as
> > Brazos without GLAMOR works OK while Brazos with GLAMOR NOK. As Kabini by
> > default requires GLAMOR - by default I have issue on Kabini. 
> 
> EXA on Brazos is tear free most of the time because we sync operations to
> the vblank using a hack. That hack isn't supported on GLAMOR and so GLAMOR
> operations are not synced to vblank at all (Michel knows more about this).
> 
> But the root cause is something completely different, cause GLAMOR shouldn't
> be used in the first place in this situation.

Well - radeonsi can't work here without glamor. Forcing EXA gives following in
xorg log:

(WW) RADEON(0): EXA not supported, using glamor

> 
> GLAMOR is made to accelerate things like window movements and text drawing.
> For fullscreen video playback there should be a page flip operation used.
> 
> Please try to investigate what MythTV is actually doing different here to
> cause the page flipping to not work correctly.

mythtv does exactly the same on Kabini like on Brazos. I'm using exactly the
same PXE booted image. Also all configs are the same as I'm simply booting the
same OS image + configs just on 2 different HW platforms. I believe all HW
depended things are purely and only internal to xserver and mesa.

Maybe Kabini's xserver log output about "EXA not supported" is clue here? Is
EXA supported on Kabini at all?

heh - I spent great time to adding glamor to carefully minimized minimyth2
image - just because on many places it is stated that mesa's radeonsi mandatory
requires glamor 

br

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/2a58dc0d/attachment-0001.html>

[Bug 85204] [Radeon HD 5650] return from sleep state failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85204

--- Comment #4 from Rafael Pereira  ---
By sleep state I mean the S3 sleeping state (sleep, standby Suspend to RAM and
DPMS), according the ACPI standard. 

Yes, it is a regression. The last working version is 3.16.6 (3.15.x, 3.14.x and
so on, didn't have this problem). I noticed the bug was first introduced on
version 3.17.0. I am working on the bisect.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/36ec8df3/attachment.html>

[Bug 79980] Random radeonsi crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #169 from DJ Dunn  ---
my card is HD7870

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/233214b1/attachment.html>

[Bug 79980] Random radeonsi crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #168 from DJ Dunn  ---
if this helps any, I've been seeing the same error on my gentoo box, its near
constant on 3.16+ kernels within 2 or 3 min of loging in X but, ive been seeing
it very rarely (once every few hours) on 3.14.22 but still seeing it, and I
never seen it happen on 3.14.19

gentoo box with mesa-10.3.1 xorg-server-1.16.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/bdd65f43/attachment.html>

[Bug 85267] vlc crashes with vdpau (Radeon 3850HD) [r600]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85267

--- Comment #1 from Michel D?nzer  ---
Created attachment 108144
  --> https://bugs.freedesktop.org/attachment.cgi?id=108144=edit
r600g: Drop references to destroyed blend state

Does this patch fix this problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/40d5ac3f/attachment.html>

[Bug 85267] New: vlc crashes with vdpau (Radeon 3850HD) [r600]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85267

Bug ID: 85267
   Summary: vlc crashes with vdpau (Radeon 3850HD) [r600]
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arthur.marsh at internode.on.net

I'm using version 10.3.1-1 on Debian of most mesa-related packages and Linux
kernel 3.18.0-rc1 from Linus' git head.

replaying a particular dvd in VLC triggers some errors:

(see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766058 )

vdpau-related packages are also installed;

when I ran the dvd in VLC under valgrind I encountered:

(comments are from michel at daenzer.net )

> ==13424== Invalid read of size 1
> ==13424==at 0x1A8789C0: r600_bind_blend_state_internal (in 
> /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_r600.so.1.0.0)
> ==13424==by 0x1A6723C0: blitter_restore_fragment_states (in 
> /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_r600.so.1.0.0)
> ==13424==by 0x1A675C47: util_blitter_clear_render_target (in 
> /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_r600.so.1.0.0)
> ==13424==by 0x1A852985: r600_clear_render_target (in 
> /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_r600.so.1.0.0)
> ==13424==by 0x1A69D9A9: vl_compositor_render (in 
> /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_r600.so.1.0.0)
> ==13424==by 0x1A629E96: vlVdpPresentationQueueDisplay (in 
> /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_r600.so.1.0.0)
> ==13424==by 0x1F2F80A3: Queue (in 
> /usr/lib/vlc/plugins/vdpau/libvdpau_display_plugin.so)
> ==13424==by 0x30D0E6DB48: ThreadDisplayPicture (in 
> /usr/lib/libvlccore.so.8.0.0)
> ==13424==by 0x30D0E6DEB2: Thread (in /usr/lib/libvlccore.so.8.0.0)
> ==13424==by 0x30022080A3: start_thread (pthread_create.c:309)
> ==13424==  Address 0xedfe51d is 61 bytes inside a block of size 64 free'd
> ==13424==at 0x4A08E90: free (vg_replace_malloc.c:473)
> ==13424==by 0x1A62C7DD: vlVdpOutputSurfaceRenderBitmapSurface (in 
> /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_r600.so.1.0.0)
> ==13424==by 0x1F2F8200: Queue (in 
> /usr/lib/vlc/plugins/vdpau/libvdpau_display_plugin.so)
> ==13424==by 0x30D0E6DB48: ThreadDisplayPicture (in 
> /usr/lib/libvlccore.so.8.0.0)
> ==13424==by 0x30D0E6DEB2: Thread (in /usr/lib/libvlccore.so.8.0.0)
> ==13424==by 0x30022080A3: start_thread (pthread_create.c:309)

This looks like a use-after-free bug in the Mesa r600g driver. Can you report
this upstream at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa ,
component Drivers/Gallium/r600?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/89d4bd54/attachment-0001.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84944

--- Comment #10 from Michel D?nzer  ---
(In reply to Christian K?nig from comment #9)
> Please try to investigate what MythTV is actually doing different here to
> cause the page flipping to not work correctly.

It would be interesting to know why the function can_flip() in
xf86-video-ati/src/radeon_dri2.c returns FALSE. warpme, if you're familiar with
gdb, you can attach it (from ssh) to the Xorg process while MythTV is running,
set a breakpoint at that function and trace its execution. Otherwise, we may
have to modify the function to print some debugging output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141021/89c21d12/attachment.html>

[PATCH] gpu:drm: Fix typo in Documentation/DocBook/drm.xml

[Masanari Iida]

This patch fix spelling typos found in drm.xml.
It is because the file is generated from comments in
source codes, I have to fix the typos within source files.

Signed-off-by: Masanari Iida 
---
 drivers/gpu/drm/drm_crtc.c | 2 +-
 drivers/gpu/drm/drm_irq.c  | 4 ++--
 drivers/gpu/drm/drm_modes.c| 2 +-
 drivers/gpu/drm/drm_prime.c| 4 ++--
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 2 +-
 include/drm/drm_dp_mst_helper.h| 2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..7f94989 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3611,7 +3611,7 @@ static struct drm_property *property_create_range(struct 
drm_device *dev,
  * object with drm_object_attach_property. The returned property object must be
  * freed with drm_property_destroy.
  *
- * Userspace is allowed to set any interger value in the (min, max) range
+ * Userspace is allowed to set any integer value in the (min, max) range
  * inclusive.
  *
  * Returns:
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5ef03c2..3e6b582 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1190,7 +1190,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_off);
  *
  * This functions restores the vblank interrupt state captured with
  * drm_vblank_off() again. Note that calls to drm_vblank_on() and
- * drm_vblank_off() can be unbalanced and so can also be unconditionaly called
+ * drm_vblank_off() can be unbalanced and so can also be unconditionally called
  * in driver load code to reflect the current hardware state of the crtc.
  *
  * This is the legacy version of drm_crtc_vblank_on().
@@ -1237,7 +1237,7 @@ EXPORT_SYMBOL(drm_vblank_on);
  *
  * This functions restores the vblank interrupt state captured with
  * drm_vblank_off() again. Note that calls to drm_vblank_on() and
- * drm_vblank_off() can be unbalanced and so can also be unconditionaly called
+ * drm_vblank_off() can be unbalanced and so can also be unconditionally called
  * in driver load code to reflect the current hardware state of the crtc.
  *
  * This is the native kms version of drm_vblank_on().
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d1b7d20..6d8b941 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -914,7 +914,7 @@ EXPORT_SYMBOL(drm_mode_equal_no_clocks_no_stereo);
  *
  * This function is a helper which can be used to validate modes against size
  * limitations of the DRM device/connector. If a mode is too big its status
- * memeber is updated with the appropriate validation failure code. The list
+ * member is updated with the appropriate validation failure code. The list
  * itself is not changed.
  */
 void drm_mode_validate_size(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 78ca308..6872eca 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -328,7 +328,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  */

 /**
- * drm_gem_prime_export - helper library implemention of the export callback
+ * drm_gem_prime_export - helper library implementation of the export callback
  * @dev: drm_device to export from
  * @obj: GEM object to export
  * @flags: flags like DRM_CLOEXEC
@@ -483,7 +483,7 @@ out_unlock:
 EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);

 /**
- * drm_gem_prime_import - helper library implemention of the import callback
+ * drm_gem_prime_import - helper library implementation of the import callback
  * @dev: drm_device to import into
  * @dma_buf: dma-buf object to import
  *
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 593b657..ee60bd4 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -73,7 +73,7 @@
  * those commands required by the parser. This generally works because command
  * opcode ranges have standard command length encodings. So for commands that
  * the parser does not need to check, it can easily skip them. This is
- * implementated via a per-ring length decoding vfunc.
+ * implemented via a per-ring length decoding vfunc.
  *
  * Unfortunately, there are a number of commands that do not follow the 
standard
  * length encoding for their opcode range, primarily amongst the MI_* commands.
@@ -838,7 +838,7 @@ finish:
  * @ring: the ring in question
  *
  * Only certain platforms require software batch buffer command parsing, and
- * only when enabled via module paramter.
+ * only when enabled via module parameter.
  *
  * Return: true if the ring requires software command parsing
  */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c01e5f3..0404fe1 100644
--- 

[Bug 50135] Unigine Heaven black stripes and weird shaders

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50135

--- Comment #17 from Alicia  ---
Just searching around, and found this:
https://bugs.freedesktop.org/show_bug.cgi?id=37296
Seems like this bug is similar, and possibly the same problem.

Oh, and before I forget, if anyone needs more info, or wants me to test
something, I'm more than willing to help. However, in terms of applying/testing
patches, I'd need some guidance since I've never done that before, so probably
a how-to or whatever will be needed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: