[i915]] *ERROR* mismatch in scaler_state.scaler_id

[Sergey Senozhatsky]

On (05/08/15 01:27), Konduru, Chandra wrote:
> > there are no specific steps, happens during boot and every time the screen 
> > goes
> > unblank. attached dmesg, .config.
> > 
> OK, I am able reproduce the mismatch scaler id log on HSW system.
> Though, this log doesn't affect system functionality, but it is an unnecessary
> annoyance. This check is targeted for SKL and shouldn't happen for HSW.
> Submitted a patch to limit the check for skl+:
> http://patchwork.freedesktop.org/patch/48858/

jfi, the usual patch exchange happens in mailing lists.
`git am ' vs. `browsing some pages and downloading attached patches'.

back to the patch: no more mismatch warnings.

Reported-and-tested-by: Sergey Senozhatsky 

-ss

[RFC] How implement Secure Data Path ?

[One Thousand Gnomes]

> dma-buf user handles are fds, which means anything allocated can be passed
> around nicely already. The question really is whether we'll have one ioctl
> on top of a special dev node or a syscall. I thought that in these cases
> where the dev node is only ever used to allocate the real thing, a syscall
> is the preferred way to go.

So you'd go for

fd = dmabuf_alloc(blah..., O_whatever) ?

Whichever I guess.. really we want open("/dev/foo/parameters.") but
we missed that chance a long time ago.

The billion dollar question is how is the resource managed, who owns the
object, who is charged for it, how to does containerise. We really ought
to have a clear answer to that.

> > I guess the same kind of logic as with GEM (except preferably without
> > the DoS security holes) applies as to why its useful to have handles to
> > the DMA buffers.
> 
> We have handles (well file descriptors) to dma-bufs already, I'm a bit
> confused what you mean?

I was agreeing with your argument - with GEM as an example that it works
for the CPU accessing case.

Alan

[PATCH v3] dma-buf: add ref counting for module as exporter

[Sumit Semwal]

Add reference counting on a kernel module that exports dma-buf and
implements its operations. This prevents the module from being unloaded
while DMABUF file is in use.

The original patch [1] was submitted by Tomasz Stanislawski, but this
is a simpler way to do it.

v3: call module_put() as late as possible, per gregkh's comment.
v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO
macro to simplify the change.

Signed-off-by: Sumit Semwal 

[1]: https://lkml.org/lkml/2012/8/8/163
---
 drivers/dma-buf/dma-buf.c | 10 +-
 include/linux/dma-buf.h   | 10 --
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138a6a8d..63a9914e42b8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,6 +73,7 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
if (dmabuf->resv == (struct reservation_object *)[1])
reservation_object_fini(dmabuf->resv);

+   module_put(dmabuf->owner);
kfree(dmabuf);
return 0;
 }
@@ -302,14 +304,20 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}

+   if (!try_module_get(exp_info->owner))
+   return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
-   if (dmabuf == NULL)
+   if (!dmabuf) {
+   module_put(exp_info->owner);
return ERR_PTR(-ENOMEM);
+   }

dmabuf->priv = exp_info->priv;
dmabuf->ops = exp_info->ops;
dmabuf->size = exp_info->size;
dmabuf->exp_name = exp_info->exp_name;
+   dmabuf->owner = exp_info->owner;
init_waitqueue_head(>poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = >poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 2f0b431b73e0..f98bd7068d55 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -115,6 +115,8 @@ struct dma_buf_ops {
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
  * @exp_name: name of the exporter; useful for debugging.
+ * @owner: pointer to exporter module; used for refcounting when exporter is a
+ * kernel module.
  * @list_node: node for dma_buf accounting and debugging.
  * @priv: exporter specific private data for this buffer object.
  * @resv: reservation object linked to this dma-buf
@@ -129,6 +131,7 @@ struct dma_buf {
unsigned vmapping_counter;
void *vmap_ptr;
const char *exp_name;
+   struct module *owner;
struct list_head list_node;
void *priv;
struct reservation_object *resv;
@@ -164,7 +167,8 @@ struct dma_buf_attachment {

 /**
  * struct dma_buf_export_info - holds information needed to export a dma_buf
- * @exp_name:  name of the exporting module - useful for debugging.
+ * @exp_name:  name of the exporter - useful for debugging.
+ * @owner: pointer to exporter module - used for refcounting kernel module
  * @ops:   Attach allocator-defined dma buf ops to the new buffer
  * @size:  Size of the buffer
  * @flags: mode flags for the file
@@ -176,6 +180,7 @@ struct dma_buf_attachment {
  */
 struct dma_buf_export_info {
const char *exp_name;
+   struct module *owner;
const struct dma_buf_ops *ops;
size_t size;
int flags;
@@ -187,7 +192,8 @@ struct dma_buf_export_info {
  * helper macro for exporters; zeros and fills in most common values
  */
 #define DEFINE_DMA_BUF_EXPORT_INFO(a)  \
-   struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
+   struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \
+.owner = THIS_MODULE }

 /**
  * get_dma_buf - convenience wrapper for get_file.
-- 
1.9.1

drm/exynos: Add atomic modesetting support

[Gustavo Padovan]

Hi Inki,

2015-05-07 Inki Dae :

> Hi,
> 
> On 2015년 05월 07일 06:45, Gustavo Padovan wrote:
> > Hi Inki and Joonyoung.
> > 
> > Any thoughts on this?
> 
> You need to resolve one issue that booting is still halted when one more
> crtc drivers are enabled, which is a dead lock issue incurred by
> register_framebuffer call. For this, I pointed out already at v3.

Don't the last patch of series in v4 fixes this? I think it can fixes
those issues, but I can't test here as I don't have the hardware.

> 
> The last patch may resolve invalid memory access which state->crtc had
> NULL while modetest is being performed but it didn't resolve above
> booting halt issue.
> 
> So as of now, I have merged this patch series for more reviews to
> exynos-drm-next-todo yesterday. I will move them to exynos-drm-next if
> the issue is resolved.

Thanks for moving it to -next-todo

Gustavo

[Bug 90370] [radeonsi] dota2 suffers from many glitches

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

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

--- Comment #2 from Sylvain BERTRAND  ---
portal2 is mini-hanging a lot then hangs for good

-- 
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/20150508/5a8092ac/attachment.html>

[Bug 90370] [radeonsi] dota2 suffers from many glitches

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

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

--- Comment #1 from Sylvain BERTRAND  ---
Xorg.0.log http://filebin.ca/21306lWrU1vK/Xorg.0.log
(bugzilla attachment upload does not work with lynx)

-- 
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/20150508/58bf02c3/attachment.html>

[RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

[Peter Zijlstra]

On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote:

> I've changed the uapi for configuring the i915_oa specific attributes
> when calling perf_event_open(2) whereby instead of cramming lots of
> bitfields into the perf_event_attr config members, I'm now
> daisy-chaining a drm_i915_oa_event_attr_t structure off of a single
> config member that's extensible and validated in the same way as the
> perf_event_attr struct. I've found this much nicer to work with while
> being neatly extensible too.

This worries me a bit.. is there more background for this?

[RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

[Peter Zijlstra]

So I've not yet went through the entire series; but I'm wondering if its
at all possible to re-use some of this work:

lkml.kernel.org/r/1428453299-19121-1-git-send-email-sukadev at 
linux.vnet.ibm.com

That's for a Power8 HV call that can basically return an array of
values; which on a superficial level sounds a bit like what this GPU
hardware does.

Let me read more of this..

[PATCH] drm/rockchip: Add BGR formats to VOP

[Tomasz Figa]

Hi Mark,

Thanks for review.

On Fri, May 8, 2015 at 5:40 PM, Mark yao  wrote:
>> @@ -233,6 +243,7 @@ static const struct vop_win_phy win23_data = {
>> .nformats = ARRAY_SIZE(formats_234),
>> .enable = VOP_REG(WIN2_CTRL0, 0x1, 0),
>> .format = VOP_REG(WIN2_CTRL0, 0x7, 1),
>> +   .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
>
> Should be:
>
> .rb_swap = VOP_REG(VOP_WIN2_CTRL0, 0x1, 12),
>

Right, good catch.

>> .dsp_info = VOP_REG(WIN2_DSP_INFO0, 0x0fff0fff, 0),
>> .dsp_st = VOP_REG(WIN2_DSP_ST0, 0x1fff1fff, 0),
>> .yrgb_mst = VOP_REG(WIN2_MST0, 0x, 0),
>> @@ -246,6 +257,7 @@ static const struct vop_win_phy cursor_data = {
>> .nformats = ARRAY_SIZE(formats_234),
>> .enable = VOP_REG(HWC_CTRL0, 0x1, 0),
>> .format = VOP_REG(HWC_CTRL0, 0x7, 1),
>> +   .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
>
> cursor win not support rb_swap, remove it.
>

Hmm, according to the datasheet of RK3288 I have (0.7, October 2014),
there is a field called hwc_rb_swap at bit 12 of HWC_CTRL0 register.
Is it an error in the datasheet?

Best regards,
Tomasz

[PATCH] drm/edid: Add CEA modes before inferred modes

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

Currently we're adding CEA modes after the inferred modes, which means
we might get multiple modes that are very close to each other, but
slightly different, which seems a bit silly. That's because duplicate
mode check that occurs when adding inferred modes would not consider
CEA modes as potential duplicates. Reverse the order so that CEA
modes get added before inferred modes, and are thus considered potential
duplicates.

Or as ajax put it on irc:
"< ajax> the point of the "pick a timing formula" heuristic was to
generate something the sink could _likely_ sink.  if it tells us
timings it can sink explicitly then second-guessing seems dumb."

Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e7a1400..314a364 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3744,10 +3744,10 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
num_modes += add_cvt_modes(connector, edid);
num_modes += add_standard_modes(connector, edid);
num_modes += add_established_modes(connector, edid);
-   if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
-   num_modes += add_inferred_modes(connector, edid);
num_modes += add_cea_modes(connector, edid);
num_modes += add_alternate_cea_modes(connector, edid);
+   if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
+   num_modes += add_inferred_modes(connector, edid);

if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
edid_fixup_preferred(connector, quirks);
-- 
2.0.5

[PATCH] drm/rockchip: Add BGR formats to VOP

[Mark yao]

On 2015年05月08日 16:49, Tomasz Figa wrote:
> Hi Mark,
>
> Thanks for review.
>
> On Fri, May 8, 2015 at 5:40 PM, Mark yao  wrote:
>>> @@ -233,6 +243,7 @@ static const struct vop_win_phy win23_data = {
>>>  .nformats = ARRAY_SIZE(formats_234),
>>>  .enable = VOP_REG(WIN2_CTRL0, 0x1, 0),
>>>  .format = VOP_REG(WIN2_CTRL0, 0x7, 1),
>>> +   .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
>> Should be:
>>
>>  .rb_swap = VOP_REG(VOP_WIN2_CTRL0, 0x1, 12),
>>
> Right, good catch.
>
>>>  .dsp_info = VOP_REG(WIN2_DSP_INFO0, 0x0fff0fff, 0),
>>>  .dsp_st = VOP_REG(WIN2_DSP_ST0, 0x1fff1fff, 0),
>>>  .yrgb_mst = VOP_REG(WIN2_MST0, 0x, 0),
>>> @@ -246,6 +257,7 @@ static const struct vop_win_phy cursor_data = {
>>>  .nformats = ARRAY_SIZE(formats_234),
>>>  .enable = VOP_REG(HWC_CTRL0, 0x1, 0),
>>>  .format = VOP_REG(HWC_CTRL0, 0x7, 1),
>>> +   .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
>> cursor win not support rb_swap, remove it.
>>
> Hmm, according to the datasheet of RK3288 I have (0.7, October 2014),
> there is a field called hwc_rb_swap at bit 12 of HWC_CTRL0 register.
> Is it an error in the datasheet?
>
> Best regards,
> Tomasz
>
>
>
Oh, yes, I find it, rb_swap at HWC_CTRL0 bit 12. you are right.
Thanks :-)

-- 
ï¼­ark Yao

[Bug 67994] Lockup with UVD and DPM on RV730

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

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

--- Comment #18 from zimous  ---
Eh, now I realized that this bug is also about DPM.  In my case "radeon.dpm=0"
does not help.  Sorry for that, I should have filed a new bug.

Also, after more testing it seems that 4.1.0-rc-2 + drm-fixes behaves more like
4.0.2 + patch.  It depends, sometimes Ctrl+F1 / restart X / clean poweroff is
possible, sometimes not.

-- 
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/20150508/4a763ac4/attachment.html>

[PATCH] drm/rockchip: Add BGR formats to VOP

[Tomasz Figa]

VOP can support BGR formats in all windows thanks to red/blue swap option
provided in WINx_CTRL0 registers. This patch enables support for
ABGR, XBGR, BGR888 and BGR565 formats by using this feature.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 4557f33..45fa11c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -169,6 +169,7 @@ struct vop_win_phy {

struct vop_reg enable;
struct vop_reg format;
+   struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
struct vop_reg dsp_st;
@@ -198,8 +199,12 @@ struct vop_data {
 static const uint32_t formats_01[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ABGR,
DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888,
DRM_FORMAT_RGB565,
+   DRM_FORMAT_BGR565,
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_NV24,
@@ -208,8 +213,12 @@ static const uint32_t formats_01[] = {
 static const uint32_t formats_234[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ABGR,
DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888,
DRM_FORMAT_RGB565,
+   DRM_FORMAT_BGR565,
 };

 static const struct vop_win_phy win01_data = {
@@ -217,6 +226,7 @@ static const struct vop_win_phy win01_data = {
.nformats = ARRAY_SIZE(formats_01),
.enable = VOP_REG(WIN0_CTRL0, 0x1, 0),
.format = VOP_REG(WIN0_CTRL0, 0x7, 1),
+   .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
.act_info = VOP_REG(WIN0_ACT_INFO, 0x1fff1fff, 0),
.dsp_info = VOP_REG(WIN0_DSP_INFO, 0x0fff0fff, 0),
.dsp_st = VOP_REG(WIN0_DSP_ST, 0x1fff1fff, 0),
@@ -233,6 +243,7 @@ static const struct vop_win_phy win23_data = {
.nformats = ARRAY_SIZE(formats_234),
.enable = VOP_REG(WIN2_CTRL0, 0x1, 0),
.format = VOP_REG(WIN2_CTRL0, 0x7, 1),
+   .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
.dsp_info = VOP_REG(WIN2_DSP_INFO0, 0x0fff0fff, 0),
.dsp_st = VOP_REG(WIN2_DSP_ST0, 0x1fff1fff, 0),
.yrgb_mst = VOP_REG(WIN2_MST0, 0x, 0),
@@ -246,6 +257,7 @@ static const struct vop_win_phy cursor_data = {
.nformats = ARRAY_SIZE(formats_234),
.enable = VOP_REG(HWC_CTRL0, 0x1, 0),
.format = VOP_REG(HWC_CTRL0, 0x7, 1),
+   .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
.dsp_st = VOP_REG(HWC_DSP_ST, 0x1fff1fff, 0),
.yrgb_mst = VOP_REG(HWC_MST, 0x, 0),
 };
@@ -351,15 +363,32 @@ static inline void vop_mask_write_relaxed(struct vop 
*vop, uint32_t offset,
}
 }

+static bool has_rb_swapped(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_BGR888:
+   case DRM_FORMAT_BGR565:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static enum vop_data_format vop_convert_format(uint32_t format)
 {
switch (format) {
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
return VOP_FMT_ARGB;
case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_BGR888:
return VOP_FMT_RGB888;
case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
return VOP_FMT_YUV420SP;
@@ -377,6 +406,7 @@ static bool is_alpha_support(uint32_t format)
 {
switch (format) {
case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
return true;
default:
return false;
@@ -587,6 +617,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
enum vop_data_format format;
uint32_t val;
bool is_alpha;
+   bool rb_swap;
bool visible;
int ret;
struct drm_rect dest = {
@@ -620,6 +651,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
return 0;

is_alpha = is_alpha_support(fb->pixel_format);
+   rb_swap = has_rb_swapped(fb->pixel_format);
format = vop_convert_format(fb->pixel_format);
if (format < 0)
return format;
@@ -688,6 +720,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
val = (dsp_sty - 1) << 16;
val |= (dsp_stx - 1) & 0x;
VOP_WIN_SET(vop, win, dsp_st, val);
+   VOP_WIN_SET(vop, win, rb_swap, rb_swap);

if (is_alpha) {
VOP_WIN_SET(vop, win, dst_alpha_ctl,
-- 
2.2.0.rc0.207.ga3a616c

[PATCH] drm/prime: Allow internal imports without import_sg_table

[Tomasz Figa]

Currently drm_gem_prime_import() checks if gem_prime_import_sg_table()
is implemented in DRM driver ops. However it is not necessary for
internal imports (i.e. dma_buf->ops == _gem_prime_dmabuf_ops
and obj->dev == dev), which only increment reference count on respective
GEM objects.

This patch makes the helper check this condition only in case of
external imports fo rwhich importing sg table is indeed needed.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/drm_prime.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7fec191..162dd29 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -502,9 +502,6 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
struct drm_gem_object *obj;
int ret;

-   if (!dev->driver->gem_prime_import_sg_table)
-   return ERR_PTR(-EINVAL);
-
if (dma_buf->ops == _gem_prime_dmabuf_ops) {
obj = dma_buf->priv;
if (obj->dev == dev) {
@@ -517,6 +514,9 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
}
}

+   if (!dev->driver->gem_prime_import_sg_table)
+   return ERR_PTR(-EINVAL);
+
attach = dma_buf_attach(dma_buf, dev->dev);
if (IS_ERR(attach))
return ERR_CAST(attach);
-- 
2.2.0.rc0.207.ga3a616c

[Bug 67713] Freezes on Trinity 7500G

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

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

--- Comment #9 from Erik  ---
I had the same issue while connecting a second monitor, with the following
card:

VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity
[Radeon HD 7660G] (prog-if 00 [VGA controller])

The problem arised when I updated to kernel 4.0.1-1-ARCH #1 SMP PREEMPT
(updated some other packets also, like mesa 10.5.4-1).

It worked after the RADEON_VA=0 fix described at the beggining, but in dmesg
still appears attachment 115642:

[   57.343370] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for
more than 5secs aborting
[   57.343388] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing 3336 (len 2642, WS 0, PS 8) @ 0x393E
[   62.462796] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for
more than 5secs aborting
[   62.462815] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing 3336 (len 2642, WS 0, PS 8) @ 0x393E
[   62.547688] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery
reached max voltage
[   62.547715] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery
failed

-- 
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/20150508/80d015bd/attachment-0001.html>

[Bug 67713] Freezes on Trinity 7500G

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

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

--- Comment #8 from Erik  ---
Created attachment 115642
  --> https://bugs.freedesktop.org/attachment.cgi?id=115642=edit
dmesg still with errors

Dmesg Erik

-- 
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/20150508/c5bab81e/attachment.html>

[PATCH] drm/rockchip: Add BGR formats to VOP

[Mark yao]

Hi Tomasz
 Thanks for the fix, but some register is wrong.

On 2015年05月08日 16:16, Tomasz Figa wrote:
> VOP can support BGR formats in all windows thanks to red/blue swap option
> provided in WINx_CTRL0 registers. This patch enables support for
> ABGR, XBGR, BGR888 and BGR565 formats by using this feature.
>
> Signed-off-by: Tomasz Figa 
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 
> +
>   1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 4557f33..45fa11c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -169,6 +169,7 @@ struct vop_win_phy {
>   
>   struct vop_reg enable;
>   struct vop_reg format;
> + struct vop_reg rb_swap;
>   struct vop_reg act_info;
>   struct vop_reg dsp_info;
>   struct vop_reg dsp_st;
> @@ -198,8 +199,12 @@ struct vop_data {
>   static const uint32_t formats_01[] = {
>   DRM_FORMAT_XRGB,
>   DRM_FORMAT_ARGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ABGR,
>   DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
>   DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
>   DRM_FORMAT_NV12,
>   DRM_FORMAT_NV16,
>   DRM_FORMAT_NV24,
> @@ -208,8 +213,12 @@ static const uint32_t formats_01[] = {
>   static const uint32_t formats_234[] = {
>   DRM_FORMAT_XRGB,
>   DRM_FORMAT_ARGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ABGR,
>   DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
>   DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
>   };
>   
>   static const struct vop_win_phy win01_data = {
> @@ -217,6 +226,7 @@ static const struct vop_win_phy win01_data = {
>   .nformats = ARRAY_SIZE(formats_01),
>   .enable = VOP_REG(WIN0_CTRL0, 0x1, 0),
>   .format = VOP_REG(WIN0_CTRL0, 0x7, 1),
> + .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
>   .act_info = VOP_REG(WIN0_ACT_INFO, 0x1fff1fff, 0),
>   .dsp_info = VOP_REG(WIN0_DSP_INFO, 0x0fff0fff, 0),
>   .dsp_st = VOP_REG(WIN0_DSP_ST, 0x1fff1fff, 0),
> @@ -233,6 +243,7 @@ static const struct vop_win_phy win23_data = {
>   .nformats = ARRAY_SIZE(formats_234),
>   .enable = VOP_REG(WIN2_CTRL0, 0x1, 0),
>   .format = VOP_REG(WIN2_CTRL0, 0x7, 1),
> + .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
Should be:

.rb_swap = VOP_REG(VOP_WIN2_CTRL0, 0x1, 12),

>   .dsp_info = VOP_REG(WIN2_DSP_INFO0, 0x0fff0fff, 0),
>   .dsp_st = VOP_REG(WIN2_DSP_ST0, 0x1fff1fff, 0),
>   .yrgb_mst = VOP_REG(WIN2_MST0, 0x, 0),
> @@ -246,6 +257,7 @@ static const struct vop_win_phy cursor_data = {
>   .nformats = ARRAY_SIZE(formats_234),
>   .enable = VOP_REG(HWC_CTRL0, 0x1, 0),
>   .format = VOP_REG(HWC_CTRL0, 0x7, 1),
> + .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
cursor win not support rb_swap, remove it.
>   .dsp_st = VOP_REG(HWC_DSP_ST, 0x1fff1fff, 0),
>   .yrgb_mst = VOP_REG(HWC_MST, 0x, 0),
>   };
> @@ -351,15 +363,32 @@ static inline void vop_mask_write_relaxed(struct vop 
> *vop, uint32_t offset,
>   }
>   }
>   
> +static bool has_rb_swapped(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_BGR888:
> + case DRM_FORMAT_BGR565:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
>   static enum vop_data_format vop_convert_format(uint32_t format)
>   {
>   switch (format) {
>   case DRM_FORMAT_XRGB:
>   case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
>   return VOP_FMT_ARGB;
>   case DRM_FORMAT_RGB888:
> + case DRM_FORMAT_BGR888:
>   return VOP_FMT_RGB888;
>   case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
>   return VOP_FMT_RGB565;
>   case DRM_FORMAT_NV12:
>   return VOP_FMT_YUV420SP;
> @@ -377,6 +406,7 @@ static bool is_alpha_support(uint32_t format)
>   {
>   switch (format) {
>   case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
>   return true;
>   default:
>   return false;
> @@ -587,6 +617,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
>   enum vop_data_format format;
>   uint32_t val;
>   bool is_alpha;
> + bool rb_swap;
>   bool visible;
>   int ret;
>   struct drm_rect dest = {
> @@ -620,6 +651,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
>   return 0;
>   
>   is_alpha = is_alpha_support(fb->pixel_format);
> + rb_swap = has_rb_swapped(fb->pixel_format);
>   format = vop_convert_format(fb->pixel_format);
>   if (format < 0)
>   return format;
> @@ -688,6 +720,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
>   val = 

[Bug 67994] Lockup with UVD and DPM on RV730

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

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

--- Comment #17 from zimous  ---
Created attachment 115641
  --> https://bugs.freedesktop.org/attachment.cgi?id=115641=edit
dmesg Linux 4.0.2 + patch "Disable semapthores..." #2

Another try with the patched kernel.  This time I quit mplayer while stil
playing ok a run again.  Maybe contains useful info.

-- 
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/20150508/a2e8f69c/attachment.html>

[alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Jyri Sarha]

On 05/08/15 16:27, Russell King - ARM Linux wrote:
> On Fri, May 08, 2015 at 04:16:08PM +0300, Jyri Sarha wrote:
>> On 2015-04-02 12:22, Russell King wrote:
...
>> For what I can see, you are setting the cross dependency between
>> the sample rate and channels incorrectly.
>
> There is a dependency between sample rate and channels.
>
>> You should look for the
>> currently tested channel count directly from hw params.
>
> I'm not so sure that's right after looking at 
> snd_ac97_pcm_double_rate_rules().
> That's pretty much the same problem - AC'97 codecs can operate at a
> sample rate of either the bus frame frequency or twice the bus frame
> frequency.
>

Maybe digging the channels from intervals works too, I have just never
used that myself. The param_channels() works too and it is slightly simpler.

[Bug 67994] Lockup with UVD and DPM on RV730

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

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

--- Comment #16 from zimous  ---
Created attachment 115640
  --> https://bugs.freedesktop.org/attachment.cgi?id=115640=edit
dmesg Linux 4.0.2 + "Disable semaphores ..." patch

-- 
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/20150508/e70ab64c/attachment.html>

[Bug 67994] Lockup with UVD and DPM on RV730

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

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

--- Comment #15 from zimous  ---
Created attachment 115638
  --> https://bugs.freedesktop.org/attachment.cgi?id=115638=edit
dmesg Linux 4.0.2 (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/20150508/d5d694b8/attachment.html>

[Bug 67994] Lockup with UVD and DPM on RV730

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

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

--- Comment #14 from zimous  ---
Same problem here, resurrecting the bug.  The situation is better with the
"Disable semaphores for UVDv1" patch from bug #85320, but still not completely
working.  Tested with:

mplayer -vo vdpau -vc ffh264vdpau movie.mkv

It is an older machine (but still serving well):

CPU: 32bit Intel P4
MB: MS-6728, Intel 865PE; Notably no MSIs!
GPU: RV730 [Radeon HD 4600 AGP Series]; The "abomination" on AGP!
distro: gentoo
gcc: 4.9.2
xorg: 1.17.1
mesa: 10.5.2 (r600, llvm enabled)
xf886-video-ati: 7.5.0
mplayer: 1.2_pre20150214
ffmpeg: 2.6.2

1) Stable kernel 4.0.2
- Movie plays for a few seconds, then the whole desktop freezes.
- Keyboard dead, display dead. Ctrl+F1 to switch to console not possible.
- Immediate poweroff (ACPI button) makes a clean shutdown.  After few seconds
not possible, only hard reboot.
- Relevant line of dmesg: radeon :01:00.0: failed to get a new IB (-35)

2) Stable kernel 4.0.2 + patch "Disable semaphores ..."
- Movie plays for a longer time (10's of second) well.
- Then the video stucks in a short loop (~second), while audio, subtitles and
rest of the destop still ok.
- After longer time (~minutes) audio and the whole desktop freezes.
- But I can do Ctrl+F1 to switch to console and even restart X, but the image
is corrupted.
- Relevant line of dmesg: radeon :01:00.0: failed to sync rings (-35)

3) Kernel 4.1.0-rc2 + ~airlied/drm-fixes (commit 3790e39)
- At first, almost the same as in 2), maybe the times are even longer.
- But in the end, the whole system freezes, no Ctrl+F1, no clean poweroff.
- I have no dmesg saved (at the moment) due to the fatal crash.

-- 
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/20150508/8d24511c/attachment.html>

[PATCH] drm/edid: Kerneldoc for newly added edid_corrupt

[Daniel Vetter]

Also treat it as a proper boolean.

Cc: Todd Previte 
Cc: Paulo Zanoni 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_edid.c  | 8 
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 include/drm/drm_crtc.h  | 1 +
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index be6713c2fc9d..e426223482fb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1064,7 +1064,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid,
int score = drm_edid_header_is_valid(raw_edid);
if (score == 8) {
if (edid_corrupt)
-   *edid_corrupt = 0;
+   *edid_corrupt = false;
} else if (score >= edid_fixup) {
/* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
 * The corrupt flag needs to be set here otherwise, the
@@ -1072,12 +1072,12 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid,
 * checksum is correct and the test fails
 */
if (edid_corrupt)
-   *edid_corrupt = 1;
+   *edid_corrupt = true;
DRM_DEBUG("Fixing EDID header, your hardware may be 
failing\n");
memcpy(raw_edid, edid_header, sizeof(edid_header));
} else {
if (edid_corrupt)
-   *edid_corrupt = 1;
+   *edid_corrupt = true;
goto bad;
}
}
@@ -1089,7 +1089,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid,
}

if (edid_corrupt)
-   *edid_corrupt = 1;
+   *edid_corrupt = true;

/* allow CEA to slide through, switches mangle this */
if (raw_edid[0] != 0x02)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2b1ed66c748f..9cf9208aeaff 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4120,7 +4120,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
struct drm_connector *connector = _connector->base;

if (intel_connector->detect_edid == NULL ||
-   connector->edid_corrupt == 1 ||
+   connector->edid_corrupt ||
intel_dp->aux.i2c_defer_count > 6) {
/* Check EDID read for NACKs, DEFERs and corruption
 * (DP CTS 1.2 Core r1.1)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b9fcdc824997..0a4a040d6bb7 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -647,6 +647,7 @@ struct drm_encoder {
  * @audio_latency: audio latency info from ELD, if found
  * @null_edid_counter: track sinks that give us all zeros for the EDID
  * @bad_edid_counter: track sinks that give us an EDID with invalid checksum
+ * @edid_corrupt: indicates whether the last read EDID was corrupt
  * @debugfs_entry: debugfs directory for this connector
  * @state: current atomic state for this connector
  * @has_tile: is this connector connected to a tiled monitor
-- 
2.1.4

[alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Jyri Sarha]

On 2015-04-02 12:22, Russell King wrote:
> Add a helper for the EDID like data structure, which is typically 
> passed
> from a HDMI adapter to its associated audio driver.  This informs the
> audio driver of the capabilities of the attached HDMI sink.
> 
> Signed-off-by: Russell King 
> ---
>  include/sound/pcm_drm_eld.h |  6 +++
>  sound/core/Kconfig  |  3 ++
>  sound/core/Makefile |  1 +
>  sound/core/pcm_drm_eld.c| 92 
> +
>  4 files changed, 102 insertions(+)
>  create mode 100644 include/sound/pcm_drm_eld.h
>  create mode 100644 sound/core/pcm_drm_eld.c
> 
> diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h
> new file mode 100644
> index ..93357b25d2e2
> --- /dev/null
> +++ b/include/sound/pcm_drm_eld.h
> @@ -0,0 +1,6 @@
> +#ifndef __SOUND_PCM_DRM_ELD_H
> +#define __SOUND_PCM_DRM_ELD_H
> +
> +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void 
> *eld);
> +
> +#endif
> diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> index 313f22e9d929..b534c8a6046b 100644
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -6,6 +6,9 @@ config SND_PCM
>   tristate
>   select SND_TIMER
> 
> +config SND_PCM_ELD
> + bool
> +
>  config SND_DMAENGINE_PCM
>   tristate
> 
> diff --git a/sound/core/Makefile b/sound/core/Makefile
> index 4daf2f58261c..591b49157b4d 100644
> --- a/sound/core/Makefile
> +++ b/sound/core/Makefile
> @@ -13,6 +13,7 @@ snd-$(CONFIG_SND_JACK)+= jack.o
>  snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o \
>   pcm_memory.o memalloc.o
>  snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
> +snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
> 
>  # for trace-points
>  CFLAGS_pcm_lib.o := -I$(src)
> diff --git a/sound/core/pcm_drm_eld.c b/sound/core/pcm_drm_eld.c
> new file mode 100644
> index ..47d9b60435fe
> --- /dev/null
> +++ b/sound/core/pcm_drm_eld.c
> @@ -0,0 +1,92 @@
> +/*
> + *  PCM DRM helpers
> + *
> + *   This program is free software; you can redistribute it and/or 
> modify
> + *   it under the terms of the GNU General Public License version 2 as
> + *   published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const unsigned int eld_rates[] = {
> + 32000,
> + 44100,
> + 48000,
> + 88200,
> + 96000,
> + 176400,
> + 192000,
> +};
> +

For what I can see, you are setting the cross dependency between
the sample rate and channels incorrectly. You should look for the
currently tested channel count directly from hw params.

> +static int eld_limit_rates(struct snd_pcm_hw_params *params,
> +struct snd_pcm_hw_rule *rule)
> +{
> + struct snd_interval *r = hw_param_interval(params, rule->var);
> + struct snd_interval *c;
> + unsigned int rate_mask = 7, i;
> + const u8 *sad, *eld = rule->private;
> +
> + sad = drm_eld_sad(eld);
> + if (sad) {
> + c = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS);
-   c = hw_param_interval(params, 
SNDRV_PCM_HW_PARAM_CHANNELS);
+   uint pchannels = params_channels(params);
> +
> + for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) {
> + unsigned channels = 1 + (sad[0] & 7);
> +
> + /*
> +  * Exclude SADs which do not include the
> +  * requested number of channels.
> +  */
> + if (pchannels <= channels)
> + rate_mask |= sad[1];
> + }
> +printk("%s: r %d-%d c %d-%d m %x\n", __func__, r->min, r->max,
> c->min, c->max, rate_mask);
> + }
> +
> + return snd_interval_list(r, ARRAY_SIZE(eld_rates), eld_rates,
> +  rate_mask);
> +}
> +

 From this side the dependency is missing all together.

> +static int eld_limit_channels(struct snd_pcm_hw_params *params,
> +   struct snd_pcm_hw_rule *rule)
> +{
> + struct snd_interval *var = hw_param_interval(params, rule->var);
> + struct snd_interval t = { .min = 1, .max = 2, .integer = 1, };
> + unsigned int i;

+   unsigned int j;

> + const u8 *sad, *eld = rule->private;

+   int rate = params_rate(params);

> +
> + sad = drm_eld_sad(eld);
> + if (sad) {
> + for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) {

+for (j = 0; j < ARRAY_SIZE(eld_rates); j++)
+if ((sad[1] & (1< +  switch (sad[0] & 0x78) {
> +  case 0x08:
> + t.max = max(t.max, (sad[0] & 7) + 1u);
> + break;
> + }

+   }

> + }
> + }
> +
> + return snd_interval_refine(var, );
> +}
> +

The 

[Bug 97931] GPU lockup with Radeon HD 4670

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

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

--- Comment #3 from joe.r.floss.user at gmail.com ---
dmesg output is now attached. As for the Xorg log, I don't have one
corresponding to the lockup, unfortunately. I can attach a current one, or wait
for the next lockup and make sure I keep the log this time. Sorry, and thanks
for your help!

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

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

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

zimous  changed:

   What|Removed |Added

 CC||zimous at matfyz.cz

--- Comment #49 from zimous  ---
Hello, I have the same problem with RV730.  The "disable semaphores ..." patch
makes it better, but not completely, UVD is still not usable.  Please follow me
to bug #67994 which seems more approprite for RV730.

-- 
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/20150508/4c221621/attachment.html>

[Bug 97931] GPU lockup with Radeon HD 4670

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

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

--- Comment #2 from joe.r.floss.user at gmail.com ---
Created attachment 176211
  --> https://bugzilla.kernel.org/attachment.cgi?id=176211=edit
Kernel log for GPU lockup

Kernel log obtained with [AMD/ATI] RV730 XT [Radeon HD 4670] (driver: radeon)

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

[Bug 97931] GPU lockup with Radeon HD 4670

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.

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

[Bug 97931] New: GPU lockup with Radeon HD 4670

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

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

Bug ID: 97931
   Summary: GPU lockup with Radeon HD 4670
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3
(2015-04-23) x86_64 GNU/Linux
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: joe.r.floss.user at gmail.com
Regression: No

Created attachment 176201
  --> https://bugzilla.kernel.org/attachment.cgi?id=176201=edit
xserver-xorg package info

Hello,

I have a bug that regularly happens when running FlightGear (which uses OpenGL
a lot). The kernel messages are very similar to those from bug 68571 ("GPU
lockup on AMD Radeon HD6850 with DPM=1"). The symptoms are: screen goes blank
for a few seconds, reappears, goes blank again, reappears garbled, alternates
between blank and garbled a few times, and if I don't reboot quickly enough, I
seem to recall (not sure about this one) that the whole system may crash in a
way that requires a hard reset. My kernel command line is:

BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=... ro init=/bin/systemd
ipv6.disable=1

This bug is present on Debian unstable, I had it yesterday; it is also present
in the just-released jessie. I am attaching the kernel log from yesterday's
occurrence of the bug. My graphics adapter is:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730
XT [Radeon HD 4670] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology Device e100
Flags: bus master, fast devsel, latency 0, IRQ 50
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at fb9e (64-bit, non-prefetchable) [size=64K]
I/O ports at be00 [size=256]
[virtual] Expansion ROM at fb90 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Kernel driver in use: radeon

If there is something I can test to help solve this bug, please say so. I
wonder if there are graphics adapters with decent OpenGL support using free
drivers that don't suffer from this kind of bug...

Thanks

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

[PATCH v2] drm: bridge: Allow daisy chaining of bridges

[Daniel Vetter]

On Fri, May 08, 2015 at 09:03:19AM -0400, Rob Clark wrote:
> On Fri, May 8, 2015 at 6:11 AM, Archit Taneja  
> wrote:
> > Allow drm_bridge objects to link to each other in order to form an encoder
> > chain. The requirement for creating a chain of bridges comes because the
> > MSM drm driver uses up its encoder and bridge objects for blocks within
> > the SoC itself. There isn't anything left to use if the SoC display output
> > is connected to an external encoder IC. Having an additional bridge
> > connected to the existing bridge helps here. In general, it is possible for
> > platforms to have  multiple devices between the encoder and the
> > connector/panel that require some sort of configuration.
> >
> > We create drm bridge helper functions corresponding to each op in
> > 'drm_bridge_funcs'. These helpers call the corresponding
> > 'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
> > used internally by drm_atomic_helper.c and drm_crtc_helper.c.
> >
> > The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
> > the bridge closet to the encoder, and proceed until the last bridge in the
> > chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
> > helpers. The drm_bridge_disable/post_disable helpers disable the last
> > bridge in the chain first, and proceed until the first bridge in the chain
> > is disabled.
> >
> > drm_bridge_attach() remains the same. As before, the driver calling this
> > function should make sure it has set the links correctly. The order in
> > which the bridges are connected to each other determines the order in which
> > the calls are made. One requirement is that every bridge in the chain
> > should point the parent encoder object. This is required since bridge
> > drivers expect a valid encoder pointer in drm_bridge. For example, consider
> > a chain where an encoder's output is connected to bridge1, and bridge1's
> > output is connected to bridge2:
> >
> > /* Like before, attach bridge to an encoder */
> > bridge1->encoder = encoder;
> > ret = drm_bridge_attach(dev, bridge1);
> > ..
> >
> > /*
> >  * set the first bridge's 'next' bridge to bridge2, set its encoder
> >  * as bridge1's encoder
> >  */
> > bridge1->next = bridge2
> > bridge2->encoder = bridge1->encoder;
> > ret = drm_bridge_attach(dev, bridge2);
> >
> > ...
> > ...
> >
> > This method of bridge chaining isn't intrusive and existing drivers that
> > use drm_bridge will behave the same way as before. The bridge helpers also
> > cleans up the atomic and crtc helper files a bit.
> >
> > Signed-off-by: Archit Taneja 
> 
> Looks good. But I guess we probably should have some headerdoc for the
> new fxns, and somewhere a comment about not calling the bridge vfuncs
> directly but using the new helper funcs which handle the chaining.  I
> guess it isn't *as* critical as it would be if these were things
> intended to be called by drivers, rather than just from core, but all
> the same I think it would be a good idea.  With that,

Yeah, at least for patches that I'll take in through drm-misc I really
want kerneldoc. Also shouldnt' we do a cocci-run over all the drm drivers
to make sure they use the new helpers now?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/9] mm: Provide new get_vaddr_frames() helper

[Mel Gorman]

On Wed, May 06, 2015 at 09:28:09AM +0200, Jan Kara wrote:
> Provide new function get_vaddr_frames().  This function maps virtual
> addresses from given start and fills given array with page frame numbers of
> the corresponding pages. If given start belongs to a normal vma, the function
> grabs reference to each of the pages to pin them in memory. If start
> belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
> must make sure pfns aren't reused for anything else while he is using
> them.
> 
> This function is created for various drivers to simplify handling of
> their buffers.
> 
> Signed-off-by: Jan Kara 

Trivial comments only;

> ---
>  include/linux/mm.h |  44 +++
>  mm/gup.c   | 214 
> +
>  2 files changed, 258 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0755b9fd03a7..dcd1f02a78e9 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct mempolicy;
>  struct anon_vma;
> @@ -1197,6 +1198,49 @@ long get_user_pages_unlocked(struct task_struct *tsk, 
> struct mm_struct *mm,
>   int write, int force, struct page **pages);
>  int get_user_pages_fast(unsigned long start, int nr_pages, int write,
>   struct page **pages);
> +
> +/* Container for pinned pfns / pages */
> +struct frame_vector {
> + unsigned int nr_allocated;  /* Number of frames we have space for */
> + unsigned int nr_frames; /* Number of frames stored in ptrs array */
> + bool got_ref;   /* Did we pin pages by getting page ref? */
> + bool is_pfns;   /* Does array contain pages or pfns? */
> + void *ptrs[0];  /* Array of pinned pfns / pages. Use
> +  * pfns_vector_pages() or pfns_vector_pfns()
> +  * for access */
> +};
> +
> +struct frame_vector *frame_vector_create(unsigned int nr_frames);
> +void frame_vector_destroy(struct frame_vector *vec);
> +int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
> +  bool write, bool force, struct frame_vector *vec);
> +void put_vaddr_frames(struct frame_vector *vec);
> +int frame_vector_to_pages(struct frame_vector *vec);
> +void frame_vector_to_pfns(struct frame_vector *vec);
> +
> +static inline unsigned int frame_vector_count(struct frame_vector *vec)
> +{
> + return vec->nr_frames;
> +}
> +
> +static inline struct page **frame_vector_pages(struct frame_vector *vec)
> +{
> + if (vec->is_pfns) {
> + int err = frame_vector_to_pages(vec);
> +
> + if (err)
> + return ERR_PTR(err);
> + }
> + return (struct page **)(vec->ptrs);
> +}
> +
> +static inline unsigned long *frame_vector_pfns(struct frame_vector *vec)
> +{
> + if (!vec->is_pfns)
> + frame_vector_to_pfns(vec);
> + return (unsigned long *)(vec->ptrs);
> +}
> +
>  struct kvec;
>  int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
>   struct page **pages);
> diff --git a/mm/gup.c b/mm/gup.c
> index 6297f6bccfb1..8db5c40e65c4 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -936,6 +937,219 @@ int __mm_populate(unsigned long start, unsigned long 
> len, int ignore_errors)
>   return ret; /* 0 or negative error code */
>  }
>  
> +/*
> + * get_vaddr_frames() - map virtual addresses to pfns
> + * @start:   starting user address
> + * @nr_frames:   number of pages / pfns from start to map
> + * @write:   whether pages will be written to by the caller
> + * @force:   whether to force write access even if user mapping is
> + *   readonly. This will result in the page being COWed even
> + *   in MAP_SHARED mappings. You do not want this.

If they don't want it, why does it exist?

> + * @vec: structure which receives pages / pfns of the addresses mapped.
> + *   It should have space for at least nr_frames entries.
> + *
> + * This function maps virtual addresses from @start and fills @vec structure
> + * with page frame numbers or page pointers to corresponding pages (choice
> + * depends on the type of the vma underlying the virtual address). If @start
> + * belongs to a normal vma, the function grabs reference to each of the pages
> + * to pin them in memory. If @start belongs to VM_IO | VM_PFNMAP vma, we 
> don't
> + * touch page structures and the caller must make sure pfns aren't reused for
> + * anything else while he is using them.
> + *
> + * The function returns number of pages mapped which may be less than
> + * @nr_frames. In particular we stop mapping if there are more vmas of
> + * different type underlying the specified range of virtual addresses.
> + *
> + * This function takes care of grabbing mmap_sem as necessary.

drmModeSetCursor not working on Intel (Haswell) GPU

[Rian Quinn]

Running a bunch of tests for some mode setting code that I have, and the 
drmModeSetCursor function works great on VMWare and AMD GPUs, but I get nothing 
on the Intel GPU (3.19 kernel). It used to work fine (3.11 kernel). I don’t 
get any errors either. I simply don’t see anything. 

For my test cases, I have an HP EliteDesk 800, and I have two monitors hooked 
up to the DPs for the Intel GPU. When I run the code, I don’t see the cursor. 
I then added an AMD v3900, to the same box and moved the cables from the Intel 
GPU to the AMD GPU and ran the same code again, and the cursors show up fine. I 
then move one cable back to the Intel GPU (meaning each GPU has one of the 
monitors), and moved the cursor around, and it shows up fine on the AMD, and 
nothing on the Intel. I then ran the same software in VMWare and it runs fine 
there too. 

Did Intel drop support for hardware cursors? If they did, does anyone know what 
the right method is to detect this?

Thanks,
- Rian

P.S. I tried drmModeSetCursor2 also with no luck. 

[PATCH v2] drm: bridge: Allow daisy chaining of bridges

[Archit Taneja]

Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have  multiple devices between the encoder and the
connector/panel that require some sort of configuration.

We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.

The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.

drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:

/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..

/*
 * set the first bridge's 'next' bridge to bridge2, set its encoder
 * as bridge1's encoder
 */
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);

...
...

This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.

Signed-off-by: Archit Taneja 
---
v2:
- Add EXPORT_SYMBOL for the new functions
- Fix logic issue in mode_fixup()

 drivers/gpu/drm/drm_atomic_helper.c | 29 +-
 drivers/gpu/drm/drm_bridge.c| 76 +
 drivers/gpu/drm/drm_crtc_helper.c   | 54 ++
 include/drm/drm_crtc.h  | 14 +++
 4 files changed, 120 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 1d2ca52..d6c85c0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -281,14 +281,11 @@ mode_fixup(struct drm_atomic_state *state)
encoder = conn_state->best_encoder;
funcs = encoder->helper_private;

-   if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
-   ret = encoder->bridge->funcs->mode_fixup(
-   encoder->bridge, _state->mode,
-   _state->adjusted_mode);
-   if (!ret) {
-   DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
-   return -EINVAL;
-   }
+   ret = drm_bridge_mode_fixup(encoder->bridge, _state->mode,
+   _state->adjusted_mode);
+   if (!ret) {
+   DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
+   return -EINVAL;
}

if (funcs->atomic_check) {
@@ -578,8 +575,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
 * Each encoder has at most one connector (since we always steal
 * it away), so we won't call disable hooks twice.
 */
-   if (encoder->bridge)
-   encoder->bridge->funcs->disable(encoder->bridge);
+   drm_bridge_disable(encoder->bridge);

/* Right function depends upon target state. */
if (connector->state->crtc && funcs->prepare)
@@ -589,8 +585,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
else
funcs->dpms(encoder, DRM_MODE_DPMS_OFF);

-   if (encoder->bridge)
-   encoder->bridge->funcs->post_disable(encoder->bridge);
+   drm_bridge_post_disable(encoder->bridge);
}

for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
@@ -713,9 +708,7 @@ crtc_set_mode(struct drm_device 

[PATCH 4/7] vga_switcheroo: Cleanup header comment

[Lukas Wunner]

Hi Thierry,

On Fri, May 08, 2015 at 12:50:46PM +0200, Thierry Reding wrote:
> + *
> + * Switcher interface - methods require for ATPX and DCM
> + * - switchto - this throws the output MUX switch
> + * - discrete_set_power - sets the power state for the discrete card
> + *
> + * GPU driver interface
> + * - set_gpu_state - this should do the equiv of s/r for the card
> + * - this should *not* set the discrete power state
> + * - switch_check  - check if the device is in a position to switch now

That documentation is actually wrong, I fixed it in my MacBook Pro
gpu switching patchset but that is still under development and thus
not merged. Might as well fix it with this patch (if you want):

s/discrete_set_power - sets the power state for the discrete card/power_state - 
sets the power state for either GPU/
s/switch_check/can_switch/

Best regards,

Lukas

[PATCH v5 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Jyri Sarha]

Use new binding for the external tda19988 HDMI encoder.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..eadbba3 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -68,16 +68,26 @@

  {
status = "okay";
+   port {
+   lcdc_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
 };

-/ {
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <>;
+ {
+   tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
pinctrl-names = "default", "off";
pinctrl-0 = <_hdmi_bonelt_pins>;
pinctrl-1 = <_hdmi_bonelt_off_pins>;
-   status = "okay";
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
};
 };

-- 
1.9.1

[PATCH v5 5/6] drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT

[Jyri Sarha]

If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
patch should not be needed. However, without this patch the objects
needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is
built as module.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7d4944e..6081fa6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,7 +60,7 @@ obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/
 obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
-obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
+obj-y  += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
 obj-$(CONFIG_DRM_MSM) += msm/
-- 
1.9.1

[PATCH v5 4/6] drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti, tilcdc, slave binding support

[Jyri Sarha]

Adds a CONFIG_DRM_TILCDC_SLAVE_COMPAT module for "ti,tilcdc,slave"
node conversion. The implementation is in tilcdc_slave_compat.c and it
uses tilcdc_slave_compat.dts as a basis for creating a DTS
overlay. The DTS overlay adds an external tda998x encoder to tilcdc
that corresponds to the old tda998x based slave encoder.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/Kconfig |  12 ++
 drivers/gpu/drm/tilcdc/Makefile|   3 +
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 270 +
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 +++
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h   |  25 +++
 5 files changed, 382 insertions(+)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 8394a0b..bfbef69 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,3 +1,15 @@
+config DRM_TILCDC_SLAVE_COMPAT
+   bool "Support device tree blobs using TI LCDC Slave binding"
+   depends on DRM_TILCDC
+   default y
+   select OF_RESOLVE
+   select OF_OVERLAY
+   help
+ Choose this option if you need a kernel that is compatible
+ with device tree blobs using the obsolete "ti,tilcdc,slave"
+ binding. If you find "ti,tilcdc,slave"-string from your DTB,
+ you probably need this. Otherwise you do not.
+
 config DRM_TILCDC
tristate "DRM Support for TI LCDC Display Controller"
depends on DRM && OF && ARM && HAVE_DMA_ATTRS
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index e1f738b..deeca48 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,9 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
ccflags-y += -Werror
 endif

+obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc_slave_compat.o \
+tilcdc_slave_compat.dtb.o
+
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
new file mode 100644
index 000..106679b
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+/*
+ * To support the old "ti,tilcdc,slave" binding the binding has to be
+ * transformed to the new external encoder binding.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tilcdc_slave_compat.h"
+
+struct kfree_table {
+   int total;
+   int num;
+   void **table;
+};
+
+static int __init kfree_table_init(struct kfree_table *kft)
+{
+   kft->total = 32;
+   kft->num = 0;
+   kft->table = kmalloc(kft->total * sizeof(*kft->table),
+GFP_KERNEL);
+   if (!kft->table)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static int __init kfree_table_add(struct kfree_table *kft, void *p)
+{
+   if (kft->num == kft->total) {
+   void **old = kft->table;
+
+   kft->total *= 2;
+   kft->table = krealloc(old, kft->total * sizeof(*kft->table),
+ GFP_KERNEL);
+   if (!kft->table) {
+   kft->table = old;
+   kfree(p);
+   return -ENOMEM;
+   }
+   }
+   kft->table[kft->num++] = p;
+   return 0;
+}
+
+static void __init kfree_table_free(struct kfree_table *kft)
+{
+   int i;
+
+   for (i = 0; i < kft->num; i++)
+   kfree(kft->table[i]);
+
+   kfree(kft->table);
+}
+
+static
+struct property * __init tilcdc_prop_dup(const struct property *prop,
+struct kfree_table *kft)
+{
+   struct property *nprop;
+
+   nprop = kzalloc(sizeof(*nprop), GFP_KERNEL);
+   if (!nprop || kfree_table_add(kft, nprop))
+   return NULL;
+
+   nprop->name = kstrdup(prop->name, GFP_KERNEL);
+   if (!nprop->name || kfree_table_add(kft, nprop->name))
+   return NULL;
+
+   nprop->value = kmemdup(prop->value, prop->length, GFP_KERNEL);
+   if (!nprop->value || kfree_table_add(kft, nprop->value))
+   return NULL;
+
+   nprop->length = prop->length;
+
+   return nprop;
+}
+
+static void __init tilcdc_copy_props(struct device_node *from,
+struct device_node *to,
+const char * const props[],
+

[PATCH v5 3/6] drm/tilcdc: Add support for external tda998x encoder

[Jyri Sarha]

Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The current
implementation supports only tda998x encoder.

To be able to filter out the unsupported video modes the tilcdc driver
needs to hijack the external connectors helper functions. The tilcdc
installes new helper functions that are otherwise identical to
orignals, but the mode_valid() call-back check the mode first localy,
before calling the original call-back. The tilcdc dirver restores the
original helper functions before it is unbound from the external
device.

I got the idea and some lines of code from Jean-Francois Moine's
"drm/tilcdc: Change the interface with the tda998x driver"-patch.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 
 drivers/gpu/drm/tilcdc/Makefile|   1 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  33 
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  85 +--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   5 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 166 +
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  25 
 7 files changed, 329 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..2136ee8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
  - max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.

+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+   binding follows Documentation/devicetree/bindings/graph.txt and
+   suppors a single port with a single endpoint.
+
 Example:

fb: fb at 4830e000 {
@@ -26,4 +32,25 @@ Example:
interrupt-parent = <>;
interrupts = <36>;
ti,hwmods = "lcdc";
+
+   port {
+   lcdc_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+
+   tda19988: tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
+
+   pinctrl-names = "default", "off";
+   pinctrl-0 = <_hdmi_bonelt_pins>;
+   pinctrl-1 = <_hdmi_bonelt_off_pins>;
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
};
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 44485f9..e1f738b 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -7,6 +7,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_panel.o \
+   tilcdc_external.o \
tilcdc_drv.o

 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c2d5980..7d07733 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -37,6 +37,9 @@ struct tilcdc_crtc {

/* for deferred fb unref's: */
struct drm_flip_work unref_work;
+
+   /* Only set if an external encoder is connected */
+   bool simulate_vesa_sync;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   if (!tilcdc_crtc->simulate_vesa_sync)
+   return true;
+
+   /*
+* tilcdc does not generate VESA-compliant sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to fix the sync.
+*/
+   adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+   adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+   adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+   } else {
+   adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+   }
+
return true;
 }

@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
tilcdc_crtc->info = info;
 }

+void 

[PATCH v5 2/6] drm/tilcdc: Remove tilcdc slave support for tda998x driver

[Jyri Sarha]

Remove tilcdc slave support for tda998x driver. The tilcdc slave
support would conflicts with componentized use of tda998x.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 drivers/gpu/drm/tilcdc/Makefile|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  13 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 6 files changed, 470 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be "ti,tilcdc,slave".
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
-   muxing properly for pins that connect to TFP410 device
-
-Example:
-
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_hdmi_bonelt_pins>;
-   };
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
-   tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 095fca9..0f1e099 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,13 +20,11 @@
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
-#include "tilcdc_slave.h"
 #include "tilcdc_panel.h"

 #include "drm_fb_helper.h"

 static LIST_HEAD(module_list);
-static bool slave_probing;

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +40,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(>list);
 }

-void tilcdc_slave_probedefer(bool defered)
-{
-   slave_probing = defered;
-}
-
 static struct of_device_id tilcdc_of_match[];

 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -620,10 +613,6 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}

-   /* defer probing if slave is in deferred probing */
-   if (slave_probing == true)
-   return -EPROBE_DEFER;
-
return drm_platform_init(_driver, pdev);
 }

@@ -654,7 +643,6 @@ static int __init tilcdc_drm_init(void)
 {
DBG("init");
tilcdc_tfp410_init();
-   tilcdc_slave_init();
tilcdc_panel_init();
return platform_driver_register(_platform_driver);
 }
@@ -664,7 +652,6 @@ static void __exit tilcdc_drm_fini(void)
DBG("fini");
platform_driver_unregister(_platform_driver);
tilcdc_panel_fini();
-   tilcdc_slave_fini();
tilcdc_tfp410_fini();
 }

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 7596c14..6336512 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
 void tilcdc_module_cleanup(struct tilcdc_module *mod);
-void tilcdc_slave_probedefer(bool defered);

 /* Panel config that needs to be set in the crtc, but is not coming from
  * the mode timings.  The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
deleted file mode 100644
index 3775fd4..000
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ /dev/null
@@ -1,411 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General 

[PATCH v5 1/6] drm/tilcdc: Fix module unloading

[Jyri Sarha]

Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c735884..c2d5980 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
 }

+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);

-   WARN_ON(tilcdc_crtc->dpms == DRM_MODE_DPMS_ON);
+   tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);

drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(_crtc->unref_work);
-- 
1.9.1

[PATCH v5 0/6] Use DRM component API in tilcdc to connect to tda998x

[Jyri Sarha]

For all that I know this should be good for taking.

Changes since v4
* Rebased on top linux-4.1-rc2
* Drop "drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_..."
* Make connector_funcs const in struct tilcdc_drm_private because
  struct drm_connector's helper_private has been qualified as const in
  linux-4.1
* Check if a subcomponent has already triggered the unloading.
  - Fixes an oops if the external encoder is unloaded first and tilcdc after
* Add comment to explain hijacking of external drm connectors helper hijacking

Changes since v3 version of the patch-set:
* drm/tilcdc: Add support for external tda998x encoder
 - Hijack external connectors helper functions
 - Remove select of nonexistent DRM_TILCDC_INIT in tilcdc Kconfig
 - Correct author mail address to tilcdc_exteral.h
* drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding
 - Add a header file for tilcdc_slave_compat.dtb symbol declarations

Changes since v2 version of the patch-set:
- use obj-y in Makefle for tilcdc subdir in:
  "drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT"
- move to last:
  "drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint"

Changes since first version of the patch-set:
- Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible
- Add separate: 
  drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
- Reduce info-level spam
- Use component_master_add_with_match()
- Be more explicit about tda998x being the only supported external encoder

Remove tilcdc slave support and connect to tda998x trough its
component DRM API. For dtb backward compatibility the code creates at
boot time a DT overlay based on the earlier binding. The overlay
conforms to the new graph based binding.

The "drm/tilcdc: Decrement refcount of ep-node from
of_graph_get_next_endpoint" should probably not be merged. The "of:
Decrement refcount of previous endpoint in of_graph_get_next_endpoint"
is eventually going to be merged and before that leaking of two
of-node refcount increments each time the module is loaded is not that
serious. The of-nodes live forever anyway.

The merge of the dts patch can be delayed until the next merger
window, when the other patches are already in. The
DRM_TILCDC_SLAVE_COMPAT should keep the bbb HDMI operational until
then.

The first patch is just a bugfix and can be applied or dropped
independently.

Jyri Sarha (6):
  drm/tilcdc: Fix module unloading
  drm/tilcdc: Remove tilcdc slave support for tda998x driver
  drm/tilcdc: Add support for external tda998x encoder
  drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding
support
  drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
  ARM: dts: am335x-boneblack: Use new binding for HDMI

 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
 arch/arm/boot/dts/am335x-boneblack.dts |  20 +-
 drivers/gpu/drm/Makefile   |   2 +-
 drivers/gpu/drm/tilcdc/Kconfig |  12 +
 drivers/gpu/drm/tilcdc/Makefile|   5 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  36 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  98 +++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   6 +-
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 166 +
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  25 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 270 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h   |  25 ++
 16 files changed, 729 insertions(+), 490 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h

-- 
1.9.1

[alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Russell King - ARM Linux]

On Fri, May 08, 2015 at 04:16:08PM +0300, Jyri Sarha wrote:
> On 2015-04-02 12:22, Russell King wrote:
> >+static const unsigned int eld_rates[] = {
> >+32000,
> >+44100,
> >+48000,
> >+88200,
> >+96000,
> >+176400,
> >+192000,
> >+};
> >+
> 
> For what I can see, you are setting the cross dependency between
> the sample rate and channels incorrectly.

There is a dependency between sample rate and channels.

> You should look for the
> currently tested channel count directly from hw params.

I'm not so sure that's right after looking at snd_ac97_pcm_double_rate_rules().
That's pretty much the same problem - AC'97 codecs can operate at a
sample rate of either the bus frame frequency or twice the bus frame
frequency.

They achieve twice the bus frame frequency by reallocating a couple
of the PCM data slots which would otherwise be used for >2 channels
to the first two channels, thus allowing two front channel samples
per frame.

AC'97 limits the number of channels to two if:

if (rate->min > 48000) {

and limits the sample rate to 1-48kHz if:

if (channels->min > 2) {

> From this side the dependency is missing all together.

Yes, it I initially couldn't work out how to do that bit... but I have
a solution now which seems to sort-of work.

Testing with aplay, I find that it seems to mostly work, and I guess
that:

aplay -D hw:0,0 -v -f S24_LE -c 6 -r 192000 /dev/zero

resulting in:

Playing raw data '/dev/zero' : Signed 24 bit Little Endian, Rate 192000 Hz, 
Channels 6
Warning: rate is not accurate (requested = 192000Hz, got = 48000Hz)
 please, try the plug plugin
Hardware PCM card 0 'DW-HDMI' device 0 subdevice 0
Its setup is:
  stream   : PLAYBACK
  access   : RW_INTERLEAVED
  format   : S24_LE
  subformat: STD
  channels : 6
  rate : 48000
  exact rate   : 48000 (48000/1)

is acceptable.

Also looking at AC'97, I don't need to list the same parameter as a
dependent of the rule... something I'll try when I'm back from the
hospital later this afternoon...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v4 0/7] Use DRM component API in tilcdc to connect to tda998x

[Jyri Sarha]

On 05/07/15 12:44, Tomi Valkeinen wrote:
>
> On 01/04/15 11:49, Jyri Sarha wrote:
>> Ok, let's do one more full review round. The mode filtering issue was
>> the main reason for this new patch series version. However, I found
>> couple other things to fix too after scrutinizing the patches once
>> more.
>>
>> Changes since v3 version of the patch-set:
>> * drm/tilcdc: Add support for external tda998x encoder
>>   - Hijack external connectors helper functions
>>   - Remove select of nonexistent DRM_TILCDC_INIT in tilcdc Kconfig
>>   - Correct author mail address to tilcdc_exteral.h
>> * drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding
>>   - Add a header file for tilcdc_slave_compat.dtb symbol declarations
>>
>> Changes since v2 version of the patch-set:
>> - use obj-y in Makefle for tilcdc subdir in:
>>"drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT"
>> - move to last:
>>"drm/tilcdc: Decrement refcount of ep-node from 
>> of_graph_get_next_endpoint"
>>
>> Changes since first version of the patch-set:
>> - Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible
>> - Add separate:
>>drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
>> - Reduce info-level spam
>> - Use component_master_add_with_match()
>> - Be more explicit about tda998x being the only supported external encoder
>>
>> Remove tilcdc slave support and connect to tda998x trough its
>> component DRM API. For dtb backward compatibility the code creates at
>> boot time a DT overlay based on the earlier binding. The overlay
>> conforms to the new graph based binding.
>>
>> The "drm/tilcdc: Decrement refcount of ep-node from
>> of_graph_get_next_endpoint" should probably not be merged. The "of:
>> Decrement refcount of previous endpoint in of_graph_get_next_endpoint"
>> is eventually going to be merged and before that leaking of two
>> of-node refcount increments each time the module is loaded is not that
>> serious. The of-nodes live forever anyway.
>>
>> The merge of the dts patch can be delayed until the next merger
>> window, when the other patches are already in. The
>> DRM_TILCDC_SLAVE_COMPAT should keep the bbb HDMI operational until
>> then.
>
> I made a quick test on v4.1-rc2, and:
>

According to my tests the dump comes from having "drm/tilcdc: Decrement 
refcount of ep-node from of_graph_get_next_endpoint" still in the patch set.

That should not be there anymore. I'll mail a new patch set shortly with 
some additional fixes and comments.

Best regards,
Jyri

> [   15.199584] [drm] Initialized drm 1.1.0 20060810
> [   15.319496] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:616
> [   15.328339] in_atomic(): 1, irqs_disabled(): 128, pid: 130, name: insmod
> [   15.335336] 3 locks held by insmod/130:
> [   15.339339]  #0:  (>mutex){..}, at: []
> __driver_attach+0x50/0xa0
> [   15.347389]  #1:  (>mutex){..}, at: []
> __driver_attach+0x60/0xa0
> [   15.355420]  #2:  (devtree_lock){..}, at: []
> of_get_next_child+0x20/0x4c
> [   15.363731] irq event stamp: 5750
> [   15.367189] hardirqs last  enabled at (5749): []
> _raw_spin_unlock_irqrestore+0x38/0x64
> [   15.376377] hardirqs last disabled at (5750): []
> _raw_spin_lock_irqsave+0x24/0x6c
> [   15.385104] softirqs last  enabled at (5200): []
> __do_softirq+0x318/0x710
> [   15.393111] softirqs last disabled at (5147): []
> irq_exit+0xc4/0x138
> [   15.400668] CPU: 0 PID: 130 Comm: insmod Not tainted
> 4.1.0-rc2-7-g877542591d33-dirty #22
> [   15.409477] Hardware name: Generic AM33XX (Flattened Device Tree)
> [   15.415837] Backtrace:
> [   15.418403] [] (dump_backtrace) from []
> (show_stack+0x18/0x1c)
> [   15.426306]  r6:c08d04b0 r5:dd652000 r4: r3:
> [   15.432257] [] (show_stack) from []
> (dump_stack+0x94/0xc8)
> [   15.439810] [] (dump_stack) from []
> (___might_sleep+0x18c/0x294)
> [   15.447893]  r5:0268 r4:
> [   15.451643] [] (___might_sleep) from []
> (__might_sleep+0x64/0xa4)
> [   15.459816]  r7:dd119280 r6: r5:0268 r4:c08d04b0
> [   15.465759] [] (__might_sleep) from []
> (mutex_lock_nested+0x2c/0x430)
> [   15.474295]  r7:dd119280 r6:c0ae7c40 r5:c0203d0c r4:
> [   15.480239] [] (mutex_lock_nested) from []
> (kernfs_remove+0x20/0x38)
> [   15.488684]  r10:bf111da0 r9:bf111dd0 r8:dfa3a044 r7:dd119280
> r6:c0ae7c40 r5:dd11a510
> [   15.496897]  r4:c0a7a7e8
> [   15.499552] [] (kernfs_remove) from []
> (sysfs_remove_dir+0x4c/0x84)
> [   15.507907]  r5:dfa3a044 r4:dd11a510
> [   15.511658] [] (sysfs_remove_dir) from []
> (kobject_del+0x1c/0x4c)
> [   15.519831]  r5:dd11a510 r4:dfa3a044
> [   15.523580] [] (kobject_del) from []
> (kobject_release+0x70/0x1b8)
> [   15.531753]  r5:c0ac320c r4:dfa3a060
> [   15.535502] [] (kobject_release) from []
> (kobject_put+0x58/0x88)
> [   15.543585]  r8:dd653cac r7:dfa3a018 r6:a00c0013 r5:dfa3a018 r4:dfa3a044
> [   15.550627] [] (kobject_put) from []
> (of_node_put+0x1c/0x20)

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, sorry, I'm a bit late this week with the i915 fixes.

BR,
Jani.

The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22:

  Linux 4.1-rc2 (2015-05-03 19:22:23 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-05-08

for you to fetch changes up to 736a69ca8c99a595a523d2fece66491b89168da6:

  drm/i915: Drop PIPE-A quirk for 945GSE HP Mini (2015-05-07 15:28:34 +0300)


Chris Wilson (1):
  drm/i915: Drop PIPE-A quirk for 945GSE HP Mini

Jani Nikula (1):
  drm/i915/dp: there is no audio on port A

Lukas Wunner (2):
  drm/i915: Assume dual channel LVDS if pixel clock necessitates it
  drm/i915: Add missing MacBook Pro models with dual channel LVDS

Sonika Jindal (1):
  drm/i915: Sink rate read should be saved in deca-kHz

 drivers/gpu/drm/i915/intel_display.c |  3 ---
 drivers/gpu/drm/i915/intel_dp.c  |  9 +
 drivers/gpu/drm/i915/intel_lvds.c| 26 --
 3 files changed, 29 insertions(+), 9 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[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 #79 from N.Leiten  ---
(In reply to Alex Deucher from comment #78)
> Please note that DP is not direct clocked.  The link runs at either 1.62 or
> 2.7 Ghz depending on the bandwidth requirements.

Yes, thanks, I figured it out from driver. One more thing that I've not already
searched - the DP lanes init, actually we need 2 lanes for FHD 24-bit mode as
mentioned in DP brochures (they mention it in comparison table with LVDS
interface). I may be wrong at this point, just a suggestion. But flickering,
that I saw is about quarter of screen on left top corner.

-- 
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/20150508/11ec1edb/attachment.html>

[alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Jyri Sarha]

On 2015-04-05 20:26, Russell King - ARM Linux wrote:
> On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote:
>> At Sun, 5 Apr 2015 17:20:34 +0100,
>> Russell King - ARM Linux wrote:
>> > Since (afaik) ALSA has a lack of support for dynamic reconfiguration
>> > according to the attached device changing, the best we can do without
>> > a huge amount of re-work of HDMI support across all adapters is to
>> > process the capabilities of the attached device at prepare time
>> > according to the current capabilities.
>> 
>> Yeah, reconfiguration is tricky.  BTW, how is the HDMI unplug handled
>> during playback?
> 
> We don't handle it right now - and we don't have any notification to
> the audio drivers that that has happened.  Even if we did have such a
> notification, I'm not sure what the audio driver could do with it at
> the moment.
> 
>> > Implementing dynamic reconfiguration in ALSA is not something I want to
>> > get involved with, and as we /already/ have HDMI support merged in the
>> > kernel, this is not a blocker for at least trying to get some semblence
>> > of sanity, rather than having every driver re-implementing stuff like
>> > this.
>> 
>> Well, I didn't mean about the dynamic reconfiguration.  I thought of
>> rather min/max pairs, but it was just a wrong assumption.  Scratch
>> it.
>> 
>> One another question: don't we need to deal with the sample bits in
>> sad[2]?
> 
> It should, but I'm very wary about doing that without seeing more
> examples of real SADs.

If the same constraint setting helpers are to be used also with
external HDMI encoders with i2s interface, there should be an option
to leave out the constraints for the sample bits. There is no direct
connection between the number of bits on I2S and HDMI link. The CPU
DAI may apply its own constraints on the available sample formats and
too strict constraints at the encoder end may lead to zero available
formats.

Best regrads,
Jyri

> Right now, all my examples only support
> one SAD with either 2 channel or 6 channel audio at the standard
> (basic) 32, 44.1 and 48kHz rates.
> 
> The HDMI / CEA specs are very loose in their wording about the
> short audio descriptors.  I've no idea whether a sink can provide
> (for example) descriptors such as:
> 
>   LPCM, 6 channel 32, 44.1, 48kHz
>   LPCM, 2 channel, 32, 44.1, 48, 96, 192kHz
> 
> or whether have to describe that as a single descriptor.  I only
> have two TVs to test with here.
> 
> What I'm concerned about is that when the ALSA parameter refining
> starts, we start with (eg) 2-8 channels, 32-192kHz.  Given that,
> if we invoke the channel restriction before the rate restriction,
> we would end up limiting to 2 channel at 32-192kHz.  If we apply
> the restrictions in the opposite order, we'd restrict to 6
> channel, 32-48kHz.  Neither are obviously correct in this
> circumstance, and I don't really see a way to solve it given my
> understanding of the way ALSA's parameter refinement works.
> 
> I suspect this is why most HDMI drivers are implemented such that
> they take the maximum capabilities over all SADs, which would end
> up restricting audio in the above case to: up to 6 channels, at
> 32, 44.1, 48, 96 and 192kHz, even though 6 channel @ 192kHz isn't
> hasn't been indicated as supported.
> 
> Most of this is speculation though, based off what is in the
> documentation.  As I say, I don't have enough real-world examples
> to get a feel for what manufacturers _actually_ do to give a hint
> as to how the documentation should be interpreted.
> 
> So, maybe I should just copy what everyone else does and take the
> maximum of all descriptors...

[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 #78 from Alex Deucher  ---
Please note that DP is not direct clocked.  The link runs at either 1.62 or 2.7
Ghz depending on the bandwidth requirements.

-- 
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/20150508/17306617/attachment.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #76 from joe.r.floss.user at gmail.com ---
Ah, sorry, just realized it was a different series, will file a new bug.
Thanks.

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

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #75 from joe.r.floss.user at gmail.com ---
Created attachment 176191
  --> https://bugzilla.kernel.org/attachment.cgi?id=176191=edit
Kernel log for GPU lockup

Applies to a [AMD/ATI] RV730 XT [Radeon HD 4670] card

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

[PATCH v6 06/11] cec: add HDMI CEC framework

[Hans Verkuil]

Hi Kamil,

Just two tiny issues, and after that you can add my:

Reviewed-by: Hans Verkuil 

to this.

On 05/04/2015 07:32 PM, Kamil Debski wrote:
> diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
> new file mode 100644
> index 000..67b0049
> --- /dev/null
> +++ b/include/uapi/linux/cec.h
> @@ -0,0 +1,332 @@
> +#ifndef _CEC_H
> +#define _CEC_H
> +
> +#include 
> +
> +struct cec_msg {
> + __u64 ts;
> + __u32 len;
> + __u32 status;
> + __u32 timeout;
> + /* timeout (in ms) is used to timeout CEC_RECEIVE.
> +Set to 0 if you want to wait forever. */
> + __u8  msg[16];
> + __u8  reply;
> + /* If non-zero, then wait for a reply with this opcode.
> +If there was an error when sending the msg or FeatureAbort
> +was returned, then reply is set to 0.
> +If reply is non-zero upon return, then len/msg are set to
> +the received message.
> +If reply is zero upon return and status has the
> +CEC_TX_STATUS_FEATURE_ABORT bit set, then len/msg are set to the
> +received feature abort message.
> +If reply is zero upon return and status has the
> +CEC_TX_STATUS_REPLY_TIMEOUT
> +bit set, then no reply was seen at all.
> +This field is ignored with CEC_RECEIVE.
> +If reply is non-zero for CEC_TRANSMIT and the message is a broadcast,
> +then -EINVAL is returned.
> +if reply is non-zero, then timeout is set to 1000 (the required
> +maximum response time).
> +  */
> + __u32 sequence;
> + /* The framework assigns a sequence number to messages that are sent.
> +  * This can be used to track replies to previously sent messages.
> +  */
> + __u8 reserved[35];
> +};

It is confusing in struct cec_msg that the comments come *after* the field
they belong to instead of just before. Can you change this?

> +
> +#define CEC_G_EVENT  _IOWR('a', 9, struct cec_event)

This can be __IOR since we never write anything.

> +/*
> +   Read and set the vendor ID of the CEC adapter.
> + */
> +#define CEC_G_VENDOR_ID  _IOR('a', 10, __u32)
> +#define CEC_S_VENDOR_ID  _IOW('a', 11, __u32)
> +/*
> +   Enable/disable the passthrough mode
> + */
> +#define CEC_G_PASSTHROUGH_IOR('a', 12, __u32)
> +#define CEC_S_PASSTHROUGH_IOW('a', 13, __u32)
> +
> +#endif
> 

Regards,

Hans

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #74 from Alex Deucher  ---
(In reply to joe.r.floss.user from comment #73)
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> RV730 XT [Radeon HD 4670] (prog-if 00 [VGA controller])


Please file your own bug.  This bug is about different hardware.

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

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

joe.r.floss.user at gmail.com changed:

   What|Removed |Added

 CC||joe.r.floss.user at gmail.com

--- Comment #73 from joe.r.floss.user at gmail.com ---
Hello,

This bug is still present on Debian unstable, I had it again yesterday; it
regularly happens when running FlightGear. It is also present in the
just-released jessie. It makes it a bit hazardous to run OpenGL software...

I am attaching the kernel log from yesterday's occurrence of the bug. My
graphics adapter is:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730
XT [Radeon HD 4670] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology Device e100
Flags: bus master, fast devsel, latency 0, IRQ 50
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at fb9e (64-bit, non-prefetchable) [size=64K]
I/O ports at be00 [size=256]
[virtual] Expansion ROM at fb90 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Kernel driver in use: radeon

Symptoms are: screen goes blank for a few seconds, reappears, goes blank again,
reappears garbled, alternates between blank and garbled a few times, and if I
don't reboot quickly enough, I seem to recall (not sure about this one) that
the whole system may crash in a way that requires a hard reset.

If there is something I can test to help solve this bug, please say so. I
wonder if there are graphics adapters with decent OpenGL support using free
drivers that don't suffer from this kind of bug...

Thanks

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

Radeon Verde displayport failure.

[Deucher, Alexander]

> -Original Message-
> From: Dave Jones [mailto:davej at codemonkey.org.uk]
> Sent: Thursday, May 07, 2015 7:48 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; Koenig, Christian
> Subject: Radeon Verde displayport failure.
> 
> I just bought a new radeon (1002:682c), to pair with my shiny new displayport
> monitor.
> It shows a display during through the BIOS POST, and grub, but when the
> kernel
> starts up, it's a coin toss whether or not I get anything.
> Sometimes it just goes straight into power saving.
> 
> When I do get something on the console, it continues to boot and then X
> starts up and
> puts it into power saving too. Trying to flip back to tty1 doesn't light up 
> the
> display again.
> 
> I'm running On debian stable, with copied-by-hand verde_* firmware files
> from the linux-firmware git tree.
> Here's a log from the 4.0-rc2 kernel.
> 
> Any other info I can provide ?
> 

The link training with the monitor seems to fail periodically.  You may have to 
play with the timing in the link training sequence.  It looks like you also 
have some power management related issues.  Does booting with radeon.dpm=0 on 
the kernel command line in grub help?  Also does the monitor support audio?  
You might also try radeon.audio=0.

Alex

>   Dave
> 
> 
> 
> [drm] register mmio base: 0xFBE0
> [drm] register mmio size: 262144
> radeon :01:00.0: Invalid ROM contents
> ATOM BIOS: C755
> radeon :01:00.0: VRAM: 2048M 0x -
> 0x7FFF (2048M used)
> radeon :01:00.0: GTT: 1024M 0x8000 - 0xBFFF
> [drm] Detected VRAM RAM=2048M, BAR=256M
> [drm] RAM width 128bits DDR
> [TTM] Zone  kernel: Available graphics memory: 16400232 kiB
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [TTM] Initializing pool allocator
> [TTM] Initializing DMA pool allocator
> [drm] radeon: 2048M of VRAM memory ready
> [drm] radeon: 1024M of GTT memory ready.
> [drm] Loading verde Microcode
> [drm] Internal thermal controller with fan control
> [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
> input: HDA ATI HDMI HDMI as
> /devices/pci:00/:00:03.0/:01:00.1/sound/card0/input4
> input: HDA ATI HDMI HDMI as
> /devices/pci:00/:00:03.0/:01:00.1/sound/card0/input5
> [drm] radeon: dpm initialized
> [drm] GART: num cpu pages 262144, num gpu pages 262144
> [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
> [drm] PCIE gen 3 link speeds already enabled
> [drm] PCIE GART of 1024M enabled (table at 0x00277000).
> radeon :01:00.0: WB enabled
> radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00
> and cpu addr 0x880807d0ac00
> radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04
> and cpu addr 0x880807d0ac04
> radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08
> and cpu addr 0x880807d0ac08
> radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c
> and cpu addr 0x880807d0ac0c
> radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10
> and cpu addr 0x880807d0ac10
> radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18
> and cpu addr 0xc90001035a18
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> radeon :01:00.0: radeon: MSI limited to 32-bit
> radeon :01:00.0: radeon: using MSI.
> [drm] radeon: irq initialized.
> [drm] ring test on 0 succeeded in 1 usecs
> [drm] ring test on 1 succeeded in 1 usecs
> [drm] ring test on 2 succeeded in 1 usecs
> [drm] ring test on 3 succeeded in 9 usecs
> [drm] ring test on 4 succeeded in 3 usecs
> [drm] ring test on 5 succeeded in 2 usecs
> [drm] UVD initialized successfully.
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] ib test on ring 1 succeeded in 0 usecs
> [drm] ib test on ring 2 succeeded in 0 usecs
> [drm] ib test on ring 3 succeeded in 0 usecs
> [drm] ib test on ring 4 succeeded in 0 usecs
> [drm] ib test on ring 5 succeeded
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   DP-1
> [drm]   HPD4
> [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY2
> [drm] Connector 1:
> [drm]   DP-2
> [drm]   HPD5
> [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
> [drm]   Encoders:
> [drm] DFP2: INTERNAL_UNIPHY1
> [drm] Connector 2:
> [drm]   DP-3
> [drm]   HPD1
> [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
> [drm]   Encoders:
> [drm] DFP3: INTERNAL_UNIPHY1
> [drm] Connector 3:
> [drm]   DP-4
> [drm]   HPD2
> [drm]   DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 0x658c
> [drm]   Encoders:
> [drm] DFP4: INTERNAL_UNIPHY
> [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac
> failed
> [drm] fb mappable at 0xD047A000
> [drm] vram apper at 0xD000
> [drm] size 3145728

[PATCH v6 05/11] rc: Add HDMI CEC protoctol handling

[Hans Verkuil]

On 05/08/2015 01:02 PM, Hans Verkuil wrote:
> On 05/04/2015 07:32 PM, Kamil Debski wrote:
>> Add handling of remote control events coming from the HDMI CEC bus.
>> This patch includes a new keymap that maps values found in the CEC
>> messages to the keys pressed and released. Also, a new protocol has
>> been added to the core.
>>
>> Signed-off-by: Kamil Debski 
> 
> Acked-by: Hans Verkuil 

But if you could fix the typo in the subject: protoctol -> protocol, then
that would be appreciated...

Regards,

Hans

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver

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

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

--- Comment #6 from Samir Ibradžić  ---
Any news new, or at least some suggestion what code to look into?

-- 
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/20150508/43f6381a/attachment.html>

[PATCH v6 05/11] rc: Add HDMI CEC protoctol handling

[Hans Verkuil]

On 05/04/2015 07:32 PM, Kamil Debski wrote:
> Add handling of remote control events coming from the HDMI CEC bus.
> This patch includes a new keymap that maps values found in the CEC
> messages to the keys pressed and released. Also, a new protocol has
> been added to the core.
> 
> Signed-off-by: Kamil Debski 

Acked-by: Hans Verkuil 

[PATCH v6 04/11] HID: add HDMI CEC specific keycodes

[Hans Verkuil]

On 05/04/2015 07:32 PM, Kamil Debski wrote:
> Add HDMI CEC specific keycodes to the keycodes definition.
> 
> Signed-off-by: Kamil Debski 

Acked-by: Hans Verkuil 

> ---
>  include/uapi/linux/input.h |   12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index 731417c..7430a3f 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -752,6 +752,18 @@ struct input_keymap_entry {
>  #define KEY_KBDINPUTASSIST_ACCEPT0x264
>  #define KEY_KBDINPUTASSIST_CANCEL0x265
>  
> +#define KEY_RIGHT_UP 0x266
> +#define KEY_RIGHT_DOWN   0x267
> +#define KEY_LEFT_UP  0x268
> +#define KEY_LEFT_DOWN0x269
> +
> +#define KEY_NEXT_FAVORITE0x270
> +#define KEY_STOP_RECORD  0x271
> +#define KEY_PAUSE_RECORD 0x272
> +#define KEY_VOD  0x273
> +#define KEY_UNMUTE   0x274
> +#define KEY_DVB  0x275
> +
>  #define BTN_TRIGGER_HAPPY0x2c0
>  #define BTN_TRIGGER_HAPPY1   0x2c0
>  #define BTN_TRIGGER_HAPPY2   0x2c1
> 

[PATCH v2] libgencec: Add userspace library for the generic CEC kernel interface

[Hans Verkuil]

Hi Kamil,

On 05/04/2015 07:33 PM, Kamil Debski wrote:
> This is the first version of the libGenCEC library. It was designed to
> act as an interface between the generic CEC kernel API and userspace
> applications. It provides a simple interface for applications and an
> example application that can be used to test the CEC functionality.
> 
> signed-off-by: Kamil Debski 

I still strongly recommend that this library is added to the v4l-utils
repo. That already has support for v4l, dvb, media controller and IR
(i.e. everything under drivers/media), and the CEC library/utility should
be added there IMHO.

For example, I might want to use it in qv4l2, so being able to link it
knowing that I always get the latest version is very useful.

Also, v4l-utils is always updated to be in sync with the latest media_tree
kernel, and since CEC is part of that you really don't want to reinvent the
wheel in that respect.

There were objections in the past to renaming v4l-utils to media-utils, but
perhaps this should be revisited as it hasn't been v4l specific for a long 
time now.

Regards,

Hans

[Intel-gfx] [WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

[Steven Rostedt]

On Fri, 8 May 2015 12:18:10 -0400
Steven Rostedt  wrote:

> On Fri, 8 May 2015 12:08:31 -0400
> Steven Rostedt  wrote:
> 
> 
> > Maybe it's my bios still (it is an older box). I'll just block out
> > compiling in SND_HDA_INTEL, so that it doesn't break my tests (they
> > fail on a WARNING).
> 
> Hmm, right after I posted this I triggered the Call Trace again with 
> 
> # CONFIG_SND_HDA_INTEL is not set
> 
> :-/
> 
> Now to figure out how to keep this from triggering. I may just keep
> adding a patch to hide that warning.
> 

Oh, I forgot to mention, that before the Call Trace, I get theses:


[  673.093330] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register 
before interrupt
[  673.103206] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register 
before interrupt
[  673.139252] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register 
before interrupt
[  673.151323] [drm:ivybridge_set_fifo_underrun_reporting] *ERROR* uncleared 
fifo underrun on pipe A
[  673.160745] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A 
FIFO underrun

Mean anything?

-- Steve

[PATCH 7/7] vga_switcheroo: Remove unnecessary checks

[Thierry Reding]

From: Thierry Reding 

debugfs_remove() gracefully ignores NULL parameters, so the explicit
checks can be removed.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vga_switcheroo.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index c7771466595f..21060668fd25 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -525,14 +525,11 @@ static const struct file_operations 
vga_switcheroo_debugfs_fops = {

 static void vga_switcheroo_debugfs_fini(struct vgasr_priv *priv)
 {
-   if (priv->switch_file) {
-   debugfs_remove(priv->switch_file);
-   priv->switch_file = NULL;
-   }
-   if (priv->debugfs_root) {
-   debugfs_remove(priv->debugfs_root);
-   priv->debugfs_root = NULL;
-   }
+   debugfs_remove(priv->switch_file);
+   priv->switch_file = NULL;
+
+   debugfs_remove(priv->debugfs_root);
+   priv->debugfs_root = NULL;
 }

 static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv)
-- 
2.3.5

[PATCH 6/7] vga_switcheroo: Wrap overly long lines

[Thierry Reding]

From: Thierry Reding 

Wrap overly long lines to make checkpatch happy. While at it, also add
blank lines after declarations to eliminate additional problems flagged
by checkpatch.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vga_switcheroo.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index faa57e546138..c7771466595f 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -169,7 +169,8 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
   bool driver_power_control)
 {
return register_client(pdev, ops, -1,
-  pdev == vga_default_device(), 
driver_power_control);
+  pdev == vga_default_device(),
+  driver_power_control);
 }
 EXPORT_SYMBOL(vga_switcheroo_register_client);

@@ -185,6 +186,7 @@ static struct vga_switcheroo_client *
 find_client_from_pci(struct list_head *head, struct pci_dev *pdev)
 {
struct vga_switcheroo_client *client;
+
list_for_each_entry(client, head, list)
if (client->pdev == pdev)
return client;
@@ -195,6 +197,7 @@ static struct vga_switcheroo_client *
 find_client_from_id(struct list_head *head, int client_id)
 {
struct vga_switcheroo_client *client;
+
list_for_each_entry(client, head, list)
if (client->id == client_id)
return client;
@@ -205,6 +208,7 @@ static struct vga_switcheroo_client *
 find_active_client(struct list_head *head)
 {
struct vga_switcheroo_client *client;
+
list_for_each_entry(client, head, list)
if (client->active && client_is_vga(client))
return client;
@@ -262,10 +266,12 @@ static int vga_switcheroo_show(struct seq_file *m, void 
*v)
 {
struct vga_switcheroo_client *client;
int i = 0;
+
mutex_lock(_mutex);
list_for_each_entry(client, _priv.clients, list) {
seq_printf(m, "%d:%s%s:%c:%s%s:%s\n", i,
-  client_id(client) == VGA_SWITCHEROO_DIS ? "DIS" : 
"IGD",
+  client_id(client) == VGA_SWITCHEROO_DIS ? "DIS" :
+"IGD",
   client_is_vga(client) ? "" : "-Audio",
   client->active ? '+' : ' ',
   client->driver_power_control ? "Dyn" : "",
@@ -349,6 +355,7 @@ static int vga_switchto_stage2(struct vga_switcheroo_client 
*new_client)

if (new_client->fb_info) {
struct fb_event event;
+
console_lock();
event.info = new_client->fb_info;
fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, );
@@ -543,7 +550,8 @@ static int vga_switcheroo_debugfs_init(struct vgasr_priv 
*priv)
}

priv->switch_file = debugfs_create_file("switch", 0644,
-   priv->debugfs_root, NULL, 
_switcheroo_debugfs_fops);
+   priv->debugfs_root, NULL,
+   _switcheroo_debugfs_fops);
if (!priv->switch_file) {
pr_err("cannot create %s/vgaswitcheroo/switch\n", mp);
goto fail;
@@ -584,7 +592,8 @@ err:
 }
 EXPORT_SYMBOL(vga_switcheroo_process_delayed_switch);

-static void vga_switcheroo_power_switch(struct pci_dev *pdev, enum 
vga_switcheroo_state state)
+static void vga_switcheroo_power_switch(struct pci_dev *pdev,
+   enum vga_switcheroo_state state)
 {
struct vga_switcheroo_client *client;

@@ -603,7 +612,8 @@ static void vga_switcheroo_power_switch(struct pci_dev 
*pdev, enum vga_switchero

 /* force a PCI device to a certain state - mainly to turn off audio clients */

-void vga_switcheroo_set_dynamic_switch(struct pci_dev *pdev, enum 
vga_switcheroo_state dynamic)
+void vga_switcheroo_set_dynamic_switch(struct pci_dev *pdev,
+  enum vga_switcheroo_state dynamic)
 {
struct vga_switcheroo_client *client;

@@ -649,7 +659,8 @@ static int vga_switcheroo_runtime_resume(struct device *dev)

 /* this version is for the case where the power switch is separate
to the device being powered down. */
-int vga_switcheroo_init_domain_pm_ops(struct device *dev, struct dev_pm_domain 
*domain)
+int vga_switcheroo_init_domain_pm_ops(struct device *dev,
+ struct dev_pm_domain *domain)
 {
/* copy over all the bus versions */
if (dev->bus && dev->bus->pm) {
@@ -680,7 +691,8 @@ static int vga_switcheroo_runtime_resume_hdmi_audio(struct 
device *dev)
/* we need to check if we have to switch back on the video

[PATCH 5/7] vga_switcheroo: Use pr_fmt()

[Thierry Reding]

From: Thierry Reding 

Use pr_fmt() to define the "vga_switcheroo: " prefix that is prepended
to all output messages emitted by pr_*() functions. This allows making
existing strings much shorter and eliminates a bunch of warnings from
checkpatch about lines being overly long.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vga_switcheroo.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 610e2cd72563..faa57e546138 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -17,6 +17,8 @@
  * - switch_check  - check if the device is in a position to switch now
  */

+#define pr_fmt(fmt) "vga_switcheroo: " fmt
+
 #include 
 #include 
 #include 
@@ -111,7 +113,7 @@ int vga_switcheroo_register_handler(struct 
vga_switcheroo_handler *handler)

vgasr_priv.handler = handler;
if (vga_switcheroo_ready()) {
-   pr_info("vga_switcheroo: enabled\n");
+   pr_info("enabled\n");
vga_switcheroo_enable();
}
mutex_unlock(_mutex);
@@ -124,7 +126,7 @@ void vga_switcheroo_unregister_handler(void)
mutex_lock(_mutex);
vgasr_priv.handler = NULL;
if (vgasr_priv.active) {
-   pr_info("vga_switcheroo: disabled\n");
+   pr_info("disabled\n");
vga_switcheroo_debugfs_fini(_priv);
vgasr_priv.active = false;
}
@@ -155,7 +157,7 @@ static int register_client(struct pci_dev *pdev,
vgasr_priv.registered_clients++;

if (vga_switcheroo_ready()) {
-   pr_info("vga_switcheroo: enabled\n");
+   pr_info("enabled\n");
vga_switcheroo_enable();
}
mutex_unlock(_mutex);
@@ -235,7 +237,7 @@ void vga_switcheroo_unregister_client(struct pci_dev *pdev)
kfree(client);
}
if (vgasr_priv.active && vgasr_priv.registered_clients < 2) {
-   pr_info("vga_switcheroo: disabled\n");
+   pr_info("disabled\n");
vga_switcheroo_debugfs_fini(_priv);
vgasr_priv.active = false;
}
@@ -375,7 +377,7 @@ static bool check_can_switch(void)

list_for_each_entry(client, _priv.clients, list) {
if (!client->ops->can_switch(client->pdev)) {
-   pr_err("vga_switcheroo: client %x refused switch\n", 
client->id);
+   pr_err("client %x refused switch\n", client->id);
return false;
}
}
@@ -484,20 +486,20 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
char __user *ubuf,
if (can_switch) {
ret = vga_switchto_stage1(client);
if (ret)
-   pr_err("vga_switcheroo: switching failed stage 1 %d\n", 
ret);
+   pr_err("switching failed stage 1 %d\n", ret);

ret = vga_switchto_stage2(client);
if (ret)
-   pr_err("vga_switcheroo: switching failed stage 2 %d\n", 
ret);
+   pr_err("switching failed stage 2 %d\n", ret);

} else {
-   pr_info("vga_switcheroo: setting delayed switch to client 
%d\n", client->id);
+   pr_info("setting delayed switch to client %d\n", client->id);
vgasr_priv.delayed_switch_active = true;
vgasr_priv.delayed_client_id = client_id;

ret = vga_switchto_stage1(client);
if (ret)
-   pr_err("vga_switcheroo: delayed switching stage 1 
failed %d\n", ret);
+   pr_err("delayed switching stage 1 failed %d\n", ret);
}

 out:
@@ -528,20 +530,22 @@ static void vga_switcheroo_debugfs_fini(struct vgasr_priv 
*priv)

 static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv)
 {
+   static const char mp[] = "/sys/kernel/debug";
+
/* already initialised */
if (priv->debugfs_root)
return 0;
priv->debugfs_root = debugfs_create_dir("vgaswitcheroo", NULL);

if (!priv->debugfs_root) {
-   pr_err("vga_switcheroo: Cannot create 
/sys/kernel/debug/vgaswitcheroo\n");
+   pr_err("Cannot create %s/vgaswitcheroo\n", mp);
goto fail;
}

priv->switch_file = debugfs_create_file("switch", 0644,
priv->debugfs_root, NULL, 
_switcheroo_debugfs_fops);
if (!priv->switch_file) {
-   pr_err("vga_switcheroo: cannot create 
/sys/kernel/debug/vgaswitcheroo/switch\n");
+   pr_err("cannot create %s/vgaswitcheroo/switch\n", mp);
goto fail;
}
return 0;
@@ -560,7 +564,8 @@ int vga_switcheroo_process_delayed_switch(void)
if (!vgasr_priv.delayed_switch_active)
goto 

[PATCH 4/7] vga_switcheroo: Cleanup header comment

[Thierry Reding]

From: Thierry Reding 

The header comment uses a weird combination of formatting styles. Make
it consistent.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vga_switcheroo.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 0611ea8a5c49..610e2cd72563 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -6,15 +6,15 @@
  * Licensed under GPLv2
  *
  * vga_switcheroo.c - Support for laptop with dual GPU using one set of outputs
-
- Switcher interface - methods require for ATPX and DCM
- - switchto - this throws the output MUX switch
- - discrete_set_power - sets the power state for the discrete card
-
- GPU driver interface
- - set_gpu_state - this should do the equiv of s/r for the card
- - this should *not* set the discrete power state
- - switch_check  - check if the device is in a position to switch now
+ *
+ * Switcher interface - methods require for ATPX and DCM
+ * - switchto - this throws the output MUX switch
+ * - discrete_set_power - sets the power state for the discrete card
+ *
+ * GPU driver interface
+ * - set_gpu_state - this should do the equiv of s/r for the card
+ * - this should *not* set the discrete power state
+ * - switch_check  - check if the device is in a position to switch now
  */

 #include 
-- 
2.3.5

[PATCH 3/7] vga_switcheroo: Use pr_*() instead of printk()

[Thierry Reding]

From: Thierry Reding 

This silences a bunch of checkpatch warnings and makes the code shorter.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vga_switcheroo.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 37ac7b5dbd06..0611ea8a5c49 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -111,7 +111,7 @@ int vga_switcheroo_register_handler(struct 
vga_switcheroo_handler *handler)

vgasr_priv.handler = handler;
if (vga_switcheroo_ready()) {
-   printk(KERN_INFO "vga_switcheroo: enabled\n");
+   pr_info("vga_switcheroo: enabled\n");
vga_switcheroo_enable();
}
mutex_unlock(_mutex);
@@ -155,7 +155,7 @@ static int register_client(struct pci_dev *pdev,
vgasr_priv.registered_clients++;

if (vga_switcheroo_ready()) {
-   printk(KERN_INFO "vga_switcheroo: enabled\n");
+   pr_info("vga_switcheroo: enabled\n");
vga_switcheroo_enable();
}
mutex_unlock(_mutex);
@@ -235,7 +235,7 @@ void vga_switcheroo_unregister_client(struct pci_dev *pdev)
kfree(client);
}
if (vgasr_priv.active && vgasr_priv.registered_clients < 2) {
-   printk(KERN_INFO "vga_switcheroo: disabled\n");
+   pr_info("vga_switcheroo: disabled\n");
vga_switcheroo_debugfs_fini(_priv);
vgasr_priv.active = false;
}
@@ -375,7 +375,7 @@ static bool check_can_switch(void)

list_for_each_entry(client, _priv.clients, list) {
if (!client->ops->can_switch(client->pdev)) {
-   printk(KERN_ERR "vga_switcheroo: client %x refused 
switch\n", client->id);
+   pr_err("vga_switcheroo: client %x refused switch\n", 
client->id);
return false;
}
}
@@ -484,20 +484,20 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
char __user *ubuf,
if (can_switch) {
ret = vga_switchto_stage1(client);
if (ret)
-   printk(KERN_ERR "vga_switcheroo: switching failed stage 
1 %d\n", ret);
+   pr_err("vga_switcheroo: switching failed stage 1 %d\n", 
ret);

ret = vga_switchto_stage2(client);
if (ret)
-   printk(KERN_ERR "vga_switcheroo: switching failed stage 
2 %d\n", ret);
+   pr_err("vga_switcheroo: switching failed stage 2 %d\n", 
ret);

} else {
-   printk(KERN_INFO "vga_switcheroo: setting delayed switch to 
client %d\n", client->id);
+   pr_info("vga_switcheroo: setting delayed switch to client 
%d\n", client->id);
vgasr_priv.delayed_switch_active = true;
vgasr_priv.delayed_client_id = client_id;

ret = vga_switchto_stage1(client);
if (ret)
-   printk(KERN_ERR "vga_switcheroo: delayed switching 
stage 1 failed %d\n", ret);
+   pr_err("vga_switcheroo: delayed switching stage 1 
failed %d\n", ret);
}

 out:
@@ -534,14 +534,14 @@ static int vga_switcheroo_debugfs_init(struct vgasr_priv 
*priv)
priv->debugfs_root = debugfs_create_dir("vgaswitcheroo", NULL);

if (!priv->debugfs_root) {
-   printk(KERN_ERR "vga_switcheroo: Cannot create 
/sys/kernel/debug/vgaswitcheroo\n");
+   pr_err("vga_switcheroo: Cannot create 
/sys/kernel/debug/vgaswitcheroo\n");
goto fail;
}

priv->switch_file = debugfs_create_file("switch", 0644,
priv->debugfs_root, NULL, 
_switcheroo_debugfs_fops);
if (!priv->switch_file) {
-   printk(KERN_ERR "vga_switcheroo: cannot create 
/sys/kernel/debug/vgaswitcheroo/switch\n");
+   pr_err("vga_switcheroo: cannot create 
/sys/kernel/debug/vgaswitcheroo/switch\n");
goto fail;
}
return 0;
@@ -560,7 +560,7 @@ int vga_switcheroo_process_delayed_switch(void)
if (!vgasr_priv.delayed_switch_active)
goto err;

-   printk(KERN_INFO "vga_switcheroo: processing delayed switch to %d\n", 
vgasr_priv.delayed_client_id);
+   pr_info("vga_switcheroo: processing delayed switch to %d\n", 
vgasr_priv.delayed_client_id);

client = find_client_from_id(_priv.clients,
 vgasr_priv.delayed_client_id);
@@ -569,7 +569,7 @@ int vga_switcheroo_process_delayed_switch(void)

ret = vga_switchto_stage2(client);
if (ret)
-   printk(KERN_ERR "vga_switcheroo: delayed switching failed stage 
2 %d\n", ret);
+   pr_err("vga_switcheroo: delayed switching failed stage 2 %d\n", 
ret);

[PATCH 2/7] vgaarb: Fix a few checkpatch errors and warnings

[Thierry Reding]

From: Thierry Reding 

Wrap overly long lines (offending lines were mostly comments, so trivial
to fix up) and a number of other coding style issues pointed out by the
checkpatch tool.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vgaarb.c | 102 ---
 1 file changed, 60 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 5f1bde5efc7f..a0b433456107 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -136,7 +136,6 @@ struct pci_dev *vga_default_device(void)
 {
return vga_default;
 }
-
 EXPORT_SYMBOL_GPL(vga_default_device);

 void vga_set_default_device(struct pci_dev *pdev)
@@ -300,9 +299,9 @@ enable_them:

pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);

-   if (!vgadev->bridge_has_one_vga) {
+   if (!vgadev->bridge_has_one_vga)
vga_irq_set_state(vgadev, true);
-   }
+
vgadev->owns |= wants;
 lock_them:
vgadev->locks |= (rsrc & VGA_RSRC_LEGACY_MASK);
@@ -454,15 +453,15 @@ bail:
 }
 EXPORT_SYMBOL(vga_put);

-/* Rules for using a bridge to control a VGA descendant decoding:
-   if a bridge has only one VGA descendant then it can be used
-   to control the VGA routing for that device.
-   It should always use the bridge closest to the device to control it.
-   If a bridge has a direct VGA descendant, but also have a sub-bridge
-   VGA descendant then we cannot use that bridge to control the direct VGA 
descendant.
-   So for every device we register, we need to iterate all its parent bridges
-   so we can invalidate any devices using them properly.
-*/
+/*
+ * Rules for using a bridge to control a VGA descendant decoding: if a bridge
+ * has only one VGA descendant then it can be used to control the VGA routing
+ * for that device. It should always use the bridge closest to the device to
+ * control it. If a bridge has a direct VGA descendant, but also have a sub-
+ * bridge VGA descendant then we cannot use that bridge to control the direct
+ * VGA descendant. So for every device we register, we need to iterate all
+ * its parent bridges so we can invalidate any devices using them properly.
+ */
 static void vga_arbiter_check_bridge_sharing(struct vga_device *vgadev)
 {
struct vga_device *same_bridge_vgadev;
@@ -486,21 +485,26 @@ static void vga_arbiter_check_bridge_sharing(struct 
vga_device *vgadev)

/* see if the share a bridge with this device */
if (new_bridge == bridge) {
-   /* if their direct parent bridge is the same
-  as any bridge of this device then it can't 
be used
-  for that device */
+   /*
+* If their direct parent bridge is the same
+* as any bridge of this device then it can't
+* be used for that device.
+*/
same_bridge_vgadev->bridge_has_one_vga = false;
}

-   /* now iterate the previous devices bridge hierarchy */
-   /* if the new devices parent bridge is in the other 
devices
-  hierarchy then we can't use it to control this 
device */
+   /*
+* Now iterate the previous devices bridge hierarchy.
+* If the new devices parent bridge is in the other
+* devices hierarchy then we can't use it to control
+* this device
+*/
while (bus) {
bridge = bus->self;
-   if (bridge) {
-   if (bridge == vgadev->pdev->bus->self)
-   vgadev->bridge_has_one_vga = 
false;
-   }
+
+   if (bridge && bridge == vgadev->pdev->bus->self)
+   vgadev->bridge_has_one_vga = false;
+
bus = bus->parent;
}
}
@@ -530,9 +534,9 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
vgadev = kmalloc(sizeof(struct vga_device), GFP_KERNEL);
if (vgadev == NULL) {
pr_err("failed to allocate pci device\n");
-   /* What to do on allocation failure ? For now, let's
-* just do nothing, I'm not sure there is anything saner
-* to be done
+   /*
+* What to do on allocation failure ? For now, let's just do
+* nothing, I'm not sure there is anything saner to be done.
 */
return false;
}

[PATCH 1/7] vgaarb: Use vgaarb: prefix consistently in messages

[Thierry Reding]

From: Thierry Reding 

Define the pr_fmt() macro to causes all messages emitted by pr_*()
functions to be prefixed with "vgaarb: ".

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vgaarb.c | 39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 3b1e65b3d454..5f1bde5efc7f 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -29,6 +29,8 @@
  *
  */

+#define pr_fmt(fmt) "vgaarb: " fmt
+
 #include 
 #include 
 #include 
@@ -527,7 +529,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
/* Allocate structure */
vgadev = kmalloc(sizeof(struct vga_device), GFP_KERNEL);
if (vgadev == NULL) {
-   pr_err("vgaarb: failed to allocate pci device\n");
+   pr_err("failed to allocate pci device\n");
/* What to do on allocation failure ? For now, let's
 * just do nothing, I'm not sure there is anything saner
 * to be done
@@ -581,8 +583,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
 */
if (vga_default == NULL &&
((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
-   pr_info("vgaarb: setting as boot device: PCI:%s\n",
-   pci_name(pdev));
+   pr_info("setting as boot device: PCI:%s\n", pci_name(pdev));
vga_set_default_device(pdev);
}

@@ -591,7 +592,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
/* Add to the list */
list_add(>list, _list);
vga_count++;
-   pr_info("vgaarb: device added: PCI:%s,decodes=%s,owns=%s,locks=%s\n",
+   pr_info("device added: PCI:%s,decodes=%s,owns=%s,locks=%s\n",
pci_name(pdev),
vga_iostate_to_str(vgadev->decodes),
vga_iostate_to_str(vgadev->owns),
@@ -651,7 +652,7 @@ static inline void vga_update_device_decodes(struct 
vga_device *vgadev,
decodes_unlocked = vgadev->locks & decodes_removed;
vgadev->decodes = new_decodes;

-   pr_info("vgaarb: device changed decodes: 
PCI:%s,olddecodes=%s,decodes=%s:owns=%s\n",
+   pr_info("device changed decodes: 
PCI:%s,olddecodes=%s,decodes=%s:owns=%s\n",
pci_name(vgadev->pdev),
vga_iostate_to_str(old_decodes),
vga_iostate_to_str(vgadev->decodes),
@@ -673,7 +674,7 @@ static inline void vga_update_device_decodes(struct 
vga_device *vgadev,
if (!(old_decodes & VGA_RSRC_LEGACY_MASK) &&
new_decodes & VGA_RSRC_LEGACY_MASK)
vga_decode_count++;
-   pr_debug("vgaarb: decoding count now is: %d\n", vga_decode_count);
+   pr_debug("decoding count now is: %d\n", vga_decode_count);
 }

 static void __vga_set_legacy_decoding(struct pci_dev *pdev, unsigned int 
decodes, bool userspace)
@@ -1075,13 +1076,13 @@ static ssize_t vga_arb_write(struct file *file, const 
char __user * buf,
ret_val = -EPROTO;
goto done;
}
-   pr_debug("vgaarb: %s ==> %x:%x:%x.%x\n", curr_pos,
+   pr_debug("%s ==> %x:%x:%x.%x\n", curr_pos,
domain, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));

pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
-   pr_debug("vgaarb: pdev %p\n", pdev);
+   pr_debug("pdev %p\n", pdev);
if (!pdev) {
-   pr_err("vgaarb: invalid PCI address %x:%x:%x\n",
+   pr_err("invalid PCI address %x:%x:%x\n",
domain, bus, devfn);
ret_val = -ENODEV;
goto done;
@@ -1089,10 +1090,10 @@ static ssize_t vga_arb_write(struct file *file, const 
char __user * buf,
}

vgadev = vgadev_find(pdev);
-   pr_debug("vgaarb: vgadev %p\n", vgadev);
+   pr_debug("vgadev %p\n", vgadev);
if (vgadev == NULL) {
if (pdev) {
-   pr_err("vgaarb: this pci device is not a vga 
device\n");
+   pr_err("this pci device is not a vga device\n");
pci_dev_put(pdev);
}

@@ -1112,7 +1113,7 @@ static ssize_t vga_arb_write(struct file *file, const 
char __user * buf,
}
}
if (i == MAX_USER_CARDS) {
-   pr_err("vgaarb: maximum user cards (%d) number 
reached!\n",
+   pr_err("maximum user cards (%d) number reached!\n",
MAX_USER_CARDS);
pci_dev_put(pdev);

[PATCH 0/7] vga: Miscellaneous cleanups

[Thierry Reding]

From: Thierry Reding 

This is a set of cosmetic cleanups that I couldn't resist after fixing
the annoying and misleading "PCI device is not a VGA device" warning.

Thierry

Thierry Reding (7):
  vgaarb: Use vgaarb: prefix consistently in messages
  vgaarb: Fix a few checkpatch errors and warnings
  vga_switcheroo: Use pr_*() instead of printk()
  vga_switcheroo: Cleanup header comment
  vga_switcheroo: Use pr_fmt()
  vga_switcheroo: Wrap overly long lines
  vga_switcheroo: Remove unnecessary checks

 drivers/gpu/vga/vga_switcheroo.c |  95 ---
 drivers/gpu/vga/vgaarb.c | 137 ++-
 2 files changed, 134 insertions(+), 98 deletions(-)

-- 
2.3.5

[PATCH] vgaarb: Stop complaining about absent devices

[Thierry Reding]

From: Thierry Reding 

Some setups do not register a default VGA device, in which case the VGA
arbiter will still complain about the (non-existent) PCI device being a
non-VGA device.

Fix this by making the error message conditional on a default VGA device
having been set up. Note that the easy route of erroring out early isn't
going to work because otherwise priv->target won't be properly updated.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/vga/vgaarb.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 7bcbf863656e..3b1e65b3d454 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -1091,8 +1091,11 @@ static ssize_t vga_arb_write(struct file *file, const 
char __user * buf,
vgadev = vgadev_find(pdev);
pr_debug("vgaarb: vgadev %p\n", vgadev);
if (vgadev == NULL) {
-   pr_err("vgaarb: this pci device is not a vga device\n");
-   pci_dev_put(pdev);
+   if (pdev) {
+   pr_err("vgaarb: this pci device is not a vga 
device\n");
+   pci_dev_put(pdev);
+   }
+
ret_val = -ENODEV;
goto done;
}
-- 
2.3.5

[PATCH v6 07/11] DocBook/media: add CEC documentation

[Hans Verkuil]

Hi Kamil,

A few more comments about the documentation:

First of all you should add some documentation about what the passthrough mode
actually is. Right now all this says is that you can enable or disable it, but
not what it actually does.

And next I have a few small comments about the timestamp documentation:

> diff --git a/Documentation/DocBook/media/v4l/cec-ioc-g-event.xml 
> b/Documentation/DocBook/media/v4l/cec-ioc-g-event.xml
> new file mode 100644
> index 000..cbde320
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/cec-ioc-g-event.xml
> @@ -0,0 +1,125 @@

...

> +  
> +Description
> +
> +CEC devices can send asynchronous events. These can be retrieved 
> by calling
> +the CEC_G_EVENT ioctl. If the file descriptor is in 
> non-blocking
> +mode and no event is pending, then it will return -1 and set errno to 
> the .
> +
> +There can be up to 40 events queued up. If more events are added, 
> then the oldest event will be discarded.
> +
> +
> +  struct cec_event
> +  
> + 
> + 
> +   
> + __u64
> + ts
> + Timestamp of the event in ns.

"Timestamp of the event in ns. This is based on the monotonic clock. 
Applications
can access this clock using clock_gettime(2) with clock ID
CLOCK_MONOTONIC. To turn this into a struct 
timespec
use:


struct timespec tmspec;

tmspec.tv_sec = ts / 10;
tmspec.tv_nsec = ts % 10;
"

(I hope the docbook syntax for programlisting is correct)



> diff --git a/Documentation/DocBook/media/v4l/cec-ioc-receive.xml 
> b/Documentation/DocBook/media/v4l/cec-ioc-receive.xml
> new file mode 100644
> index 000..dbec20a
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/cec-ioc-receive.xml
> @@ -0,0 +1,185 @@

...

> +
> +  struct cec_msg
> +  
> + 
> + 
> +   
> + __u64
> + ts
> + Timestamp of when the message was transmitted in ns in the 
> case
> + of CEC_TRANSMIT with 
> reply
> + set to 0, or the timestamp of the received message in all other 
> cases.

The same timestamp explanation should be given here.

Regards,

Hans

[alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Russell King - ARM Linux]

On Fri, May 08, 2015 at 01:56:02PM +0300, Jyri Sarha wrote:
> On 2015-04-05 20:26, Russell King - ARM Linux wrote:
> >On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote:
> >>At Sun, 5 Apr 2015 17:20:34 +0100,
> >>Russell King - ARM Linux wrote:
> >>> Since (afaik) ALSA has a lack of support for dynamic reconfiguration
> >>> according to the attached device changing, the best we can do without
> >>> a huge amount of re-work of HDMI support across all adapters is to
> >>> process the capabilities of the attached device at prepare time
> >>> according to the current capabilities.
> >>
> >>Yeah, reconfiguration is tricky.  BTW, how is the HDMI unplug handled
> >>during playback?
> >
> >We don't handle it right now - and we don't have any notification to
> >the audio drivers that that has happened.  Even if we did have such a
> >notification, I'm not sure what the audio driver could do with it at
> >the moment.
> >
> >>> Implementing dynamic reconfiguration in ALSA is not something I want to
> >>> get involved with, and as we /already/ have HDMI support merged in the
> >>> kernel, this is not a blocker for at least trying to get some semblence
> >>> of sanity, rather than having every driver re-implementing stuff like
> >>> this.
> >>
> >>Well, I didn't mean about the dynamic reconfiguration.  I thought of
> >>rather min/max pairs, but it was just a wrong assumption.  Scratch
> >>it.
> >>
> >>One another question: don't we need to deal with the sample bits in
> >>sad[2]?
> >
> >It should, but I'm very wary about doing that without seeing more
> >examples of real SADs.
> 
> If the same constraint setting helpers are to be used also with
> external HDMI encoders with i2s interface, there should be an option
> to leave out the constraints for the sample bits. There is no direct
> connection between the number of bits on I2S and HDMI link. The CPU
> DAI may apply its own constraints on the available sample formats and
> too strict constraints at the encoder end may lead to zero available
> formats.

Possibly, but then how do we know which SAD to apply to limit the number
of channels?

I suspect for the use case you're suggesting above, it's better left to
the user rather than generic code to work it out otherwise things get
far too complex.  We'd need to have some way for the driver to report
back to this generic code the actual number of bits on the HDMI link.

However, as we currently know, ALSA appears to have a problem here which
pretty much makes properly restricting the channels and sample rates
impossible to do.  That issue is the one I'm much more keen to solve
right now, because without that being solved, this set of patches is
pretty much dead in the water.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[Intel-gfx] [WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

[Steven Rostedt]

On Fri, 8 May 2015 12:08:31 -0400
Steven Rostedt  wrote:


> Maybe it's my bios still (it is an older box). I'll just block out
> compiling in SND_HDA_INTEL, so that it doesn't break my tests (they
> fail on a WARNING).

Hmm, right after I posted this I triggered the Call Trace again with 

# CONFIG_SND_HDA_INTEL is not set

:-/

Now to figure out how to keep this from triggering. I may just keep
adding a patch to hide that warning.

-- Steve

[Intel-gfx] [WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

[Steven Rostedt]

On Fri, 8 May 2015 08:55:46 +0200
Daniel Vetter  wrote:

> On Thu, May 7, 2015 at 9:40 PM, Steven Rostedt  wrote:

> Please retry with snd-hda-intel blacklisted. At least last time I
> checked that was the only culprit left, i915 is just the messenger
> here. The other one was stupid things done by the bios, but we should
> correctly clear that up since a long time.

Maybe it's my bios still (it is an older box). I'll just block out
compiling in SND_HDA_INTEL, so that it doesn't break my tests (they
fail on a WARNING).

-- Steve

Radeon Verde displayport failure.

[Dave Jones]

On Fri, May 08, 2015 at 01:23:59PM +, Deucher, Alexander wrote:
 > > -Original Message-
 > > From: Dave Jones [mailto:davej at codemonkey.org.uk]
 > > Sent: Thursday, May 07, 2015 7:48 PM
 > > To: dri-devel at lists.freedesktop.org
 > > Cc: Deucher, Alexander; Koenig, Christian
 > > Subject: Radeon Verde displayport failure.
 > > 
 > > I just bought a new radeon (1002:682c), to pair with my shiny new 
 > > displayport
 > > monitor.
 > > It shows a display during through the BIOS POST, and grub, but when the
 > > kernel
 > > starts up, it's a coin toss whether or not I get anything.
 > > Sometimes it just goes straight into power saving.
 > > 
 > > When I do get something on the console, it continues to boot and then X
 > > starts up and
 > > puts it into power saving too. Trying to flip back to tty1 doesn't light 
 > > up the
 > > display again.
 > > 
 > > I'm running On debian stable, with copied-by-hand verde_* firmware files
 > > from the linux-firmware git tree.
 > > Here's a log from the 4.0-rc2 kernel.
 > > 
 > > Any other info I can provide ?
 > > 
 > 
 > The link training with the monitor seems to fail periodically.  You may have 
 > to play with the timing in the link training sequence.  It looks like you 
 > also have some power management related issues.  Does booting with 
 > radeon.dpm=0 on the kernel command line in grub help?  Also does the monitor 
 > support audio?  You might also try radeon.audio=0.

Pretty much the same story with those options..

[8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac 
failed
[8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link 
status failed
[8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

I did manage to get it to display something for a while. By disabling DP1.2 
with the
LCDs OSD, but then it would only do a maximum of 1024x768. And after a reboot,
I saw the same messages above, and straight to power saving.

Dave

[Bug 90266] Unigine Heaven 4.0 logging vm faults since radeon/llvm: Run LLVM's instruction combining pass

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

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

--- Comment #7 from Andy Furniss  ---
(In reply to Tom Stellard from comment #6)
> Created attachment 115625 [details] [review]
> Possible Fix
> 
> This patch should fix the issue, can you test?

Yes, this fixes 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/20150508/c4d74363/attachment.html>

[RFC] How implement Secure Data Path ?

[Enrico Weigelt, metux IT consult]

Am 08.05.2015 um 10:37 schrieb Daniel Vetter:

> dma-buf user handles are fds, which means anything allocated can be passed
> around nicely already. The question really is whether we'll have one ioctl
> on top of a special dev node or a syscall. I thought that in these cases
> where the dev node is only ever used to allocate the real thing, a syscall
> is the preferred way to go.

I'd generally prefer a /dev node instead of syscall, as they can be
dynamically allocated (loaded as module, etc), which in turn offers more
finer control (eg. for containers, etc). One could easily replace the
it with its own implementation (w/o patching the kernel directly and
reboot it).

Actually, I'm a bit unhappy with the syscall inflation, in fact I'm
not even a big friend of ioctl's - I'd really prefer the Plan9 way :p

>> I guess the same kind of logic as with GEM (except preferably without
>> the DoS security holes) applies as to why its useful to have handles to
>> the DMA buffers.
>
> We have handles (well file descriptors) to dma-bufs already, I'm a bit
> confused what you mean?

Just curious (as I'm pretty new to this area): how to GEM objects and
dma-bufs relate to each other ? Is it possible to directly exchange
buffers between GPUs, VPUs, IPUs, FBs, etc ?


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 
21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen 
begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist 
ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn 
Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, 
weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise 
nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen 
Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen 
Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu 
behalten.
Important Notice: This message may contain confidential or privileged 
information. It is intended only for the person it was addressed to. If you are 
not the intended recipient of this email you may not copy, forward, disclose or 
otherwise use it or any part of it in any form whatsoever. If you received this 
email in error please notify the sender by replying and delete this message and 
any attachments without retaining a copy.

[PATCH] drm/prime: Allow internal imports without import_sg_table

[Daniel Vetter]

On Fri, May 08, 2015 at 05:13:45PM +0900, Tomasz Figa wrote:
> Currently drm_gem_prime_import() checks if gem_prime_import_sg_table()
> is implemented in DRM driver ops. However it is not necessary for
> internal imports (i.e. dma_buf->ops == _gem_prime_dmabuf_ops
> and obj->dev == dev), which only increment reference count on respective
> GEM objects.
> 
> This patch makes the helper check this condition only in case of
> external imports fo rwhich importing sg table is indeed needed.
> 
> Signed-off-by: Tomasz Figa 

Makes sense, applied to drm-misc.

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_prime.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7fec191..162dd29 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -502,9 +502,6 @@ struct drm_gem_object *drm_gem_prime_import(struct 
> drm_device *dev,
>   struct drm_gem_object *obj;
>   int ret;
>  
> - if (!dev->driver->gem_prime_import_sg_table)
> - return ERR_PTR(-EINVAL);
> -
>   if (dma_buf->ops == _gem_prime_dmabuf_ops) {
>   obj = dma_buf->priv;
>   if (obj->dev == dev) {
> @@ -517,6 +514,9 @@ struct drm_gem_object *drm_gem_prime_import(struct 
> drm_device *dev,
>   }
>   }
>  
> + if (!dev->driver->gem_prime_import_sg_table)
> + return ERR_PTR(-EINVAL);
> +
>   attach = dma_buf_attach(dma_buf, dev->dev);
>   if (IS_ERR(attach))
>   return ERR_CAST(attach);
> -- 
> 2.2.0.rc0.207.ga3a616c
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC] How implement Secure Data Path ?

[Daniel Vetter]

On Thu, May 07, 2015 at 05:40:03PM +0100, One Thousand Gnomes wrote:
> On Thu, 7 May 2015 15:52:12 +0200
> Daniel Vetter  wrote:
> 
> > On Thu, May 07, 2015 at 03:22:20PM +0200, Thierry Reding wrote:
> > > On Wed, May 06, 2015 at 03:15:32PM +0200, Daniel Vetter wrote:
> > > > Yes the idea would be a special-purpose allocater thing like ion. Might
> > > > even want that to be a syscall to do it properly.
> > > 
> > > Would you care to elaborate why a syscall would be more proper? Not that
> > > I'm objecting to it, just for my education.
> > 
> > It seems to be the theme with someone proposing a global /dev node for a
> > few system wide ioctls, then reviewers ask to make a proper ioctl out of
> > it. E.g. kdbus, but I have vague memory of this happening a lot.
> 
> kdbus is not necessarily an advert for how to do anything 8)
> 
> If it can be user allocated then it really ought to be one or more device
> nodes IMHO, because you want the resource to be passable between users,
> you need a handle to it and you want it to go away nicely on last close.
> In the cases where the CPU is allowed to or expected to have write only
> access you also might want an mmap of it.

dma-buf user handles are fds, which means anything allocated can be passed
around nicely already. The question really is whether we'll have one ioctl
on top of a special dev node or a syscall. I thought that in these cases
where the dev node is only ever used to allocate the real thing, a syscall
is the preferred way to go.

> I guess the same kind of logic as with GEM (except preferably without
> the DoS security holes) applies as to why its useful to have handles to
> the DMA buffers.

We have handles (well file descriptors) to dma-bufs already, I'm a bit
confused what you mean?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] drm: bridge: Allow daisy chaining of bridges

[Rob Clark]

On Fri, May 8, 2015 at 9:54 AM, Daniel Vetter  wrote:
> On Fri, May 08, 2015 at 09:03:19AM -0400, Rob Clark wrote:
>> On Fri, May 8, 2015 at 6:11 AM, Archit Taneja  
>> wrote:
>> > Allow drm_bridge objects to link to each other in order to form an encoder
>> > chain. The requirement for creating a chain of bridges comes because the
>> > MSM drm driver uses up its encoder and bridge objects for blocks within
>> > the SoC itself. There isn't anything left to use if the SoC display output
>> > is connected to an external encoder IC. Having an additional bridge
>> > connected to the existing bridge helps here. In general, it is possible for
>> > platforms to have  multiple devices between the encoder and the
>> > connector/panel that require some sort of configuration.
>> >
>> > We create drm bridge helper functions corresponding to each op in
>> > 'drm_bridge_funcs'. These helpers call the corresponding
>> > 'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
>> > used internally by drm_atomic_helper.c and drm_crtc_helper.c.
>> >
>> > The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
>> > the bridge closet to the encoder, and proceed until the last bridge in the
>> > chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
>> > helpers. The drm_bridge_disable/post_disable helpers disable the last
>> > bridge in the chain first, and proceed until the first bridge in the chain
>> > is disabled.
>> >
>> > drm_bridge_attach() remains the same. As before, the driver calling this
>> > function should make sure it has set the links correctly. The order in
>> > which the bridges are connected to each other determines the order in which
>> > the calls are made. One requirement is that every bridge in the chain
>> > should point the parent encoder object. This is required since bridge
>> > drivers expect a valid encoder pointer in drm_bridge. For example, consider
>> > a chain where an encoder's output is connected to bridge1, and bridge1's
>> > output is connected to bridge2:
>> >
>> > /* Like before, attach bridge to an encoder */
>> > bridge1->encoder = encoder;
>> > ret = drm_bridge_attach(dev, bridge1);
>> > ..
>> >
>> > /*
>> >  * set the first bridge's 'next' bridge to bridge2, set its encoder
>> >  * as bridge1's encoder
>> >  */
>> > bridge1->next = bridge2
>> > bridge2->encoder = bridge1->encoder;
>> > ret = drm_bridge_attach(dev, bridge2);
>> >
>> > ...
>> > ...
>> >
>> > This method of bridge chaining isn't intrusive and existing drivers that
>> > use drm_bridge will behave the same way as before. The bridge helpers also
>> > cleans up the atomic and crtc helper files a bit.
>> >
>> > Signed-off-by: Archit Taneja 
>>
>> Looks good. But I guess we probably should have some headerdoc for the
>> new fxns, and somewhere a comment about not calling the bridge vfuncs
>> directly but using the new helper funcs which handle the chaining.  I
>> guess it isn't *as* critical as it would be if these were things
>> intended to be called by drivers, rather than just from core, but all
>> the same I think it would be a good idea.  With that,
>
> Yeah, at least for patches that I'll take in through drm-misc I really
> want kerneldoc. Also shouldnt' we do a cocci-run over all the drm drivers
> to make sure they use the new helpers now?

cocci might have been the more clever way to do it, but I did have a
quick check on the call-sites for bridge vfunc's with this patch
applied and didn't see any calls from drivers or unconverted call
sites in core..

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[Bug 90284] GPU lockup with DOTA2

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

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

Tom Stellard  changed:

   What|Removed |Added

 Attachment #115595|text/plain  |application/gzip
  mime type||

-- 
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/20150508/90e758f7/attachment.html>

[Bug 90284] GPU lockup with DOTA2

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

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

Tom Stellard  changed:

   What|Removed |Added

 Attachment #115515|text/plain  |application/gzip
  mime type||

-- 
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/20150508/63197ece/attachment.html>

[Bug 90370] [radeonsi] dota2 suffers from many glitches

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

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

Bug ID: 90370
   Summary: [radeonsi] dota2 suffers from many glitches
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: sylvain.bertrand at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

While playing dota2, I can see a lot of artifacts, and I get a lot of
mini hangs on tahiti xt gpu (radeonsi).
llvm f194367792d7c43f0476e11e7c0d171b8bfbc601 15/04/2015
linux 4.0.0
mesa a7d018accfd0161510a75ba685e056256de494c2 08/04/2015 (no glx-tls/dri3 is
on)
libdrm 0d78b37b1cac304ce5e84d1207f0a43abd29c000 15/04-22015

-- 
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/20150508/9d9ecd8c/attachment-0001.html>

[PATCH v2] drm: bridge: Allow daisy chaining of bridges

[Rob Clark]

On Fri, May 8, 2015 at 6:11 AM, Archit Taneja  wrote:
> Allow drm_bridge objects to link to each other in order to form an encoder
> chain. The requirement for creating a chain of bridges comes because the
> MSM drm driver uses up its encoder and bridge objects for blocks within
> the SoC itself. There isn't anything left to use if the SoC display output
> is connected to an external encoder IC. Having an additional bridge
> connected to the existing bridge helps here. In general, it is possible for
> platforms to have  multiple devices between the encoder and the
> connector/panel that require some sort of configuration.
>
> We create drm bridge helper functions corresponding to each op in
> 'drm_bridge_funcs'. These helpers call the corresponding
> 'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
> used internally by drm_atomic_helper.c and drm_crtc_helper.c.
>
> The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
> the bridge closet to the encoder, and proceed until the last bridge in the
> chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
> helpers. The drm_bridge_disable/post_disable helpers disable the last
> bridge in the chain first, and proceed until the first bridge in the chain
> is disabled.
>
> drm_bridge_attach() remains the same. As before, the driver calling this
> function should make sure it has set the links correctly. The order in
> which the bridges are connected to each other determines the order in which
> the calls are made. One requirement is that every bridge in the chain
> should point the parent encoder object. This is required since bridge
> drivers expect a valid encoder pointer in drm_bridge. For example, consider
> a chain where an encoder's output is connected to bridge1, and bridge1's
> output is connected to bridge2:
>
> /* Like before, attach bridge to an encoder */
> bridge1->encoder = encoder;
> ret = drm_bridge_attach(dev, bridge1);
> ..
>
> /*
>  * set the first bridge's 'next' bridge to bridge2, set its encoder
>  * as bridge1's encoder
>  */
> bridge1->next = bridge2
> bridge2->encoder = bridge1->encoder;
> ret = drm_bridge_attach(dev, bridge2);
>
> ...
> ...
>
> This method of bridge chaining isn't intrusive and existing drivers that
> use drm_bridge will behave the same way as before. The bridge helpers also
> cleans up the atomic and crtc helper files a bit.
>
> Signed-off-by: Archit Taneja 

Looks good. But I guess we probably should have some headerdoc for the
new fxns, and somewhere a comment about not calling the bridge vfuncs
directly but using the new helper funcs which handle the chaining.  I
guess it isn't *as* critical as it would be if these were things
intended to be called by drivers, rather than just from core, but all
the same I think it would be a good idea.  With that,

Reviewed-by: Rob Clark 


> ---
> v2:
> - Add EXPORT_SYMBOL for the new functions
> - Fix logic issue in mode_fixup()
>
>  drivers/gpu/drm/drm_atomic_helper.c | 29 +-
>  drivers/gpu/drm/drm_bridge.c| 76 
> +
>  drivers/gpu/drm/drm_crtc_helper.c   | 54 ++
>  include/drm/drm_crtc.h  | 14 +++
>  4 files changed, 120 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 1d2ca52..d6c85c0 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -281,14 +281,11 @@ mode_fixup(struct drm_atomic_state *state)
> encoder = conn_state->best_encoder;
> funcs = encoder->helper_private;
>
> -   if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
> -   ret = encoder->bridge->funcs->mode_fixup(
> -   encoder->bridge, _state->mode,
> -   _state->adjusted_mode);
> -   if (!ret) {
> -   DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
> -   return -EINVAL;
> -   }
> +   ret = drm_bridge_mode_fixup(encoder->bridge, 
> _state->mode,
> +   _state->adjusted_mode);
> +   if (!ret) {
> +   DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
> +   return -EINVAL;
> }
>
> if (funcs->atomic_check) {
> @@ -578,8 +575,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>  * Each encoder has at most one connector (since we always 
> steal
>  * it away), so we won't call disable hooks twice.
>  */
> -   if (encoder->bridge)
> -   encoder->bridge->funcs->disable(encoder->bridge);
> 

[Intel-gfx] [WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

[Daniel Vetter]

On Thu, May 7, 2015 at 9:40 PM, Steven Rostedt  wrote:
>  [ cut here ]
>  WARNING: CPU: 2 PID: 0 at 
> /work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_uncore.c:566
>  hsw_unclaimed_reg_debug.isra.10+0x6c/0x84()
>  Unclaimed register detected before writing to register 0xc4040
>  Modules linked in: microcode r8169
>  CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.1.0-rc2-test+ #4
>  Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
>   0236 880215203c68 81ba8161 
>   880215203cb8 880215203ca8 81080dbb 
>   81626bc6 88020de60068 000c4040 0001
>  Call Trace:
> [] dump_stack+0x4c/0x65
>   [] warn_slowpath_common+0xa1/0xbb
>   [] ? hsw_unclaimed_reg_debug.isra.10+0x6c/0x84
>   [] warn_slowpath_fmt+0x46/0x48
>   [] hsw_unclaimed_reg_debug.isra.10+0x6c/0x84
>   [] hsw_write32+0x86/0xcf
>   [] cpt_irq_handler+0x1e8/0x1f5
>   [] ivb_display_irq_handler+0xf4/0x11b
>   [] ironlake_irq_handler+0x187/0x24d
>   [] handle_irq_event_percpu+0xf7/0x2a3
>   [] handle_irq_event+0x41/0x64
>   [] handle_edge_irq+0xa0/0xb9
>   [] handle_irq+0x11d/0x128
>   [] ? atomic_notifier_call_chain+0x14/0x16
>   [] do_IRQ+0x4e/0xc4
>   [] common_interrupt+0x70/0x70
> [] ? cpuidle_enter_state+0xd8/0x135
>   [] ? cpuidle_enter_state+0xd4/0x135
>   [] cpuidle_enter+0x17/0x19
>   [] cpuidle_idle_call+0xf2/0x180
>   [] cpu_idle_loop+0x12b/0x164
>   [] cpu_startup_entry+0x13/0x14
>   [] start_secondary+0x102/0x106
>   [] ? set_cpu_sibling_map+0x35e/0x35e
>  ---[ end trace 77c6a96cf41e96d1 ]---
>
> I'm still triggering warnings in the i915 code. :-(

Please retry with snd-hda-intel blacklisted. At least last time I
checked that was the only culprit left, i915 is just the messenger
here. The other one was stupid things done by the bios, but we should
correctly clear that up since a long time.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 90340] RADEON "PITCAIRN" displayport output breaks when monitor turned off and on

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

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

--- Comment #6 from Christian König  ---
(In reply to Niels Ole Salscheider from comment #4)
> - the monitor never comes back on again under memtest86+ or in the BIOS

That sounds a bit like a problem with the hardware. Can everybody else test
this in the BIOS as well?

-- 
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/20150508/5c0a27e8/attachment.html>

[PATCH] drm/nouveau/core: deinline nv_mask()

[Peter Hurley]

On 05/07/2015 04:49 AM, Denys Vlasenko wrote:
> Function compiles to 89 bytes of machine code.
> 466 callsites with this .config:
> http://busybox.net/~vda/kernel_config
> Size reduction:

Much of the cruft is related to calling iowriteX.

Ben,

Isn't subdev io always mmio? (iow, never to the 64k i/o space)


>text  data  bss   dec hex filename
> 82432426 22255384 20627456 125315266 77828c2 vmlinux.before
> 82426986 22255416 20627456 125309858 77813a2 vmlinux
> 
> Signed-off-by: Denys Vlasenko 
> CC: Stefan Huehner 
> CC: Ben Skeggs 
> CC: David Airlie 
> CC: dri-devel at lists.freedesktop.org
> CC: linux-kernel at vger.kernel.org
> ---
>  drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h | 9 ++---
>  drivers/gpu/drm/nouveau/nvkm/core/subdev.c | 8 
>  2 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h 
> b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> index 6fdc391..261b7ff 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> @@ -109,11 +109,6 @@ nv_wr32(void *obj, u32 addr, u32 data)
>   iowrite32_native(data, subdev->mmio + addr);
>  }
>  
> -static inline u32
> -nv_mask(void *obj, u32 addr, u32 mask, u32 data)
> -{
> - u32 temp = nv_rd32(obj, addr);
> - nv_wr32(obj, addr, (temp & ~mask) | data);
> - return temp;
> -}
> +u32
> +nv_mask(void *obj, u32 addr, u32 mask, u32 data);
>  #endif
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/subdev.c 
> b/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
> index c5fb3a79..88331ea 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
> @@ -25,6 +25,14 @@
>  #include 
>  #include 
>  
> +u32
> +nv_mask(void *obj, u32 addr, u32 mask, u32 data)
> +{
> + u32 temp = nv_rd32(obj, addr);
> + nv_wr32(obj, addr, (temp & ~mask) | data);
> + return temp;
> +}
> +
>  struct nvkm_subdev *
>  nvkm_subdev(void *obj, int idx)
>  {
> 

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

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

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

N.Leiten  changed:

   What|Removed |Added

 CC||nickleiten at gmail.com

--- Comment #77 from N.Leiten  ---
Created attachment 115629
  --> https://bugs.freedesktop.org/attachment.cgi?id=115629=edit
Panel datasheet

At this time I managed to get working video-stream to panel, but the timings is
obviously wrong. The main problem is Spread Spectrum somehow get disabled in
reinit cycle, and not enabled, so I just removed SS management and got blinking
noise on the screen.
Also I added some delays that necessary for this panel (maybe all another needs
it too). Due to attached datasheet on page 15 we got sequence of power-on and
power-off for this panel. Interesting this is Reset interval of 500ms which is
mandatory between power-off panel and powering it back on.

Now I'm trying to figure initial PLL setings that BIOS set before OS starts,
after that I'll try to fix this behaviour. I don't fully know vesa framebuffer
initialization, but as I understand, it get values from VBIOS/default BIOS
address space for VGA and trying to apply them. Moreover, when radeon KMS is
off I got fully different values of Modeline comparing to EDID.

-- 
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/20150508/356e57c9/attachment-0001.html>

[Bug 90340] RADEON "PITCAIRN" displayport output breaks when monitor turned off and on

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

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

--- Comment #5 from Niels Ole Salscheider  
---
BTW: Make sure that you use the original cable, otherwise you might have
problems with standby anyway:
http://www.necdisplay.com/documents/Miscellaneous/DisplayPort_Notice.pdf

-- 
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/20150508/21819bad/attachment.html>

[Bug 90340] RADEON "PITCAIRN" displayport output breaks when monitor turned off and on

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

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

--- Comment #4 from Niels Ole Salscheider  
---
I observed the following behaviour with my setup:
- the monitor never comes back on again under memtest86+ or in the BIOS
- it always comes back on again when on the console (with the raden driver
loaded at least)
- it sometimes (?) comes back on under X
- if it does not come back on, something like switching to the console, power
cycle, switching to X, switching to the console brings it back on the console,
but it will turn off as soon as you switch to X. Switching to the console again
turns it on, etc.

-- 
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/20150508/90e55011/attachment.html>

[i915]] *ERROR* mismatch in scaler_state.scaler_id

[Konduru, Chandra]

> -Original Message-
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky at gmail.com]
> Sent: Thursday, May 07, 2015 4:24 AM
> To: Konduru, Chandra
> Cc: Daniel Vetter; Sergey Senozhatsky; David Airlie; Vetter, Daniel; intel-
> gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [i915]] *ERROR* mismatch in scaler_state.scaler_id
> 
> On (05/07/15 00:40), Konduru, Chandra wrote:
> >
> > Hi,
> > This error happens when crtc_state in driver not matching with hardware
> registers.
> > On skylake board that I have, I am not able to reproduce the issue.
> > Can you send the system configuration and steps to reproduce the issue?
> > Also can you send the full dmesg.log file?
> >
> 
> Hi,
> there are no specific steps, happens during boot and every time the screen 
> goes
> unblank. attached dmesg, .config.
> 
OK, I am able reproduce the mismatch scaler id log on HSW system.
Though, this log doesn't affect system functionality, but it is an unnecessary
annoyance. This check is targeted for SKL and shouldn't happen for HSW.
Submitted a patch to limit the check for skl+:
http://patchwork.freedesktop.org/patch/48858/

[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 #76 from Nicolas Werner  ---
Created attachment 115626
  --> https://bugs.freedesktop.org/attachment.cgi?id=115626=edit
dmesg drm debug kernel 3.18

I am also interested in providing help to fix this bug.

I even tried to bisect it, but I somehow didn't quite unterstand, how to
reproduce the working case, so it didn't give me any interesting results.

I'm attaching a log of my new setup using gentoo, before I switched to fglrx.
It's from kernel 3.18 (current stable in gentoo) and was produced after booting
with nomodeset and unloading radeon, drm etc
then doing
modprobe -v drm debug=1
modprobe -v radeon modesetting=1

then printing dmesg to a file.

Greetings,
Nicolas

-- 
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/20150508/5265bd2c/attachment.html>