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

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

8 0x655c
0x655c
[3.268289] [drm]   Encoders:
[3.268291] [drm]   encoder: 8802a0a91a00, 0x0002
[3.268293] [drm]   encoder: 8802a0a90600, 0x0001
[3.268295] [drm]   encoder: 8802a0a90200, 0x0001
[3.268296] [drm]   encoder: 8802a0a90800, 0x0008
[3.268298] [drm] DFP1: INTERNAL_UNIPHY
[5.689859] [drm] radeon_dp_getdpcd 8802a1879c00
[5.689864] [drm] dig_connector 8802a335fd80
[5.689867] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[5.721938] [drm] fb mappable at 0xD047B000
[5.721944] [drm] vram apper at 0xD000
[5.721947] [drm] size 8294400
[5.721950] [drm] fb depth is 24
[5.721952] [drm]pitch is 7680
[5.722277] fbcon: radeondrmfb (fb0) is primary device
[5.722365] [drm:radeon_dp_set_link_config] *ERROR* corrupt dpcd, updating
[5.722952] [drm] radeon_dp_set_link_config, 8802a1878c00, 54, 1
[5.722953] [drm] dig_connector 8802a335fd60
[5.722954] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[6.865341] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
updating
[6.865932] [drm] radeon_dp_set_rx_power_state, 8802a1878c00, 0
[6.865933] [drm] dig_connector 8802a335fd60
[6.865934] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[8.001613] [drm:radeon_dp_link_train] *ERROR* corrupt dpcd, updating
[8.002284] [drm] radeon_dp_link_train, 8802a1878c00
[8.002285] [drm] dig_connector 8802a335fd60
[8.002287] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[8.002287] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[8.002289] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
updating
[8.002594] [drm] radeon_dp_getdpcd 8802a1878c00
[8.002595] [drm] dig_connector 8802a335fd60
[8.002595] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[8.002597] [drm] radeon_dp_set_rx_power_state, 8802a1878c00, 17
[8.002598] [drm] dig_connector 8802a335fd60
[8.002599] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[8.010706] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5
times
[8.010707] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[8.410554] Console: switching to colour frame buffer device 240x67
[8.419076] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[8.419080] radeon :00:01.0: registered panic notifier
[8.447905] [drm] Initialized radeon 2.40.0 20080528 for :00:01.0 on
minor 0
[   11.172631] [drm] radeon_dp_getdpcd 8802a1879c00
[   11.172638] [drm] dig_connector 8802a335fd80
[   11.172642] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.201610] [drm] radeon_dp_getdpcd 8802a1879c00
[   11.201617] [drm] dig_connector 8802a335fd80
[   11.201621] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.261417] [drm] radeon_dp_getdpcd 8802a1879c00
[   11.261423] [drm] dig_connector 8802a335fd80
[   11.261427] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.289599] [drm] radeon_dp_getdpcd 8802a1879c00
[   11.289611] [drm] dig_connector 8802a335fd80
[   11.289616] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

-- 
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/20150514/2e935ada/attachment-0001.html>

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

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #115780|0   |1
is obsolete||

--- Comment #97 from Alex Deucher  ---
Created attachment 115782
  --> https://bugs.freedesktop.org/attachment.cgi?id=115782=edit
more debugging

Can you attach your dmesg output with the attached patch?  Please include all
the radeon related output.

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

[PATCH 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()

[Inki Dae]

Hi,

On 2015년 05월 13일 22:08, Jan Kara wrote:
> Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
> This removes the knowledge about vmas and mmap_sem locking from exynos
> driver. Also it fixes a problem that the function has been mapping user
> provided address without holding mmap_sem.
> 
> Signed-off-by: Jan Kara 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 89 ++
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 97 
> -
>  2 files changed, 29 insertions(+), 157 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 81a250830808..265519c0fe2d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
>   dma_addr_t  dma_addr;
>   unsigned long   userptr;
>   unsigned long   size;
> - struct page **pages;
> - unsigned intnpages;
> + struct frame_vector *vec;
>   struct sg_table *sgt;
> - struct vm_area_struct   *vma;
>   atomic_trefcount;
>   boolin_pool;
>   boolout_of_list;
> @@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device 
> *drm_dev,
>  {
>   struct g2d_cmdlist_userptr *g2d_userptr =
>   (struct g2d_cmdlist_userptr *)obj;
> + struct page **pages;
>  
>   if (!obj)
>   return;
> @@ -382,19 +381,21 @@ out:
>   exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
>   DMA_BIDIRECTIONAL);
>  
> - exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
> - g2d_userptr->npages,
> - g2d_userptr->vma);
> + pages = frame_vector_pages(g2d_userptr->vec);
> + if (!IS_ERR(pages)) {
> + int i;
>  
> - exynos_gem_put_vma(g2d_userptr->vma);
> + for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
> + set_page_dirty_lock(pages[i]);
> + }
> + put_vaddr_frames(g2d_userptr->vec);
> + frame_vector_destroy(g2d_userptr->vec);
>  
>   if (!g2d_userptr->out_of_list)
>   list_del_init(_userptr->list);
>  
>   sg_free_table(g2d_userptr->sgt);
>   kfree(g2d_userptr->sgt);
> -
> - drm_free_large(g2d_userptr->pages);
>   kfree(g2d_userptr);
>  }
>  
> @@ -413,6 +414,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
> drm_device *drm_dev,
>   struct vm_area_struct *vma;
>   unsigned long start, end;
>   unsigned int npages, offset;
> + struct frame_vector *vec;
>   int ret;
>  
>   if (!size) {
> @@ -456,65 +458,37 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
> drm_device *drm_dev,
>   return ERR_PTR(-ENOMEM);
>  
>   atomic_set(_userptr->refcount, 1);
> + g2d_userptr->size = size;
>  
>   start = userptr & PAGE_MASK;
>   offset = userptr & ~PAGE_MASK;
>   end = PAGE_ALIGN(userptr + size);
>   npages = (end - start) >> PAGE_SHIFT;
> - g2d_userptr->npages = npages;
> -
> - pages = drm_calloc_large(npages, sizeof(struct page *));

The declaration to pages isn't needed anymore because you removed it.

> - if (!pages) {
> - DRM_ERROR("failed to allocate pages.\n");
> - ret = -ENOMEM;
> + vec = g2d_userptr->vec = frame_vector_create(npages);

I think you can use g2d_userptr->vec so it seems that vec isn't needed.

> + if (!vec)
>   goto err_free;
> - }
>  
> - down_read(>mm->mmap_sem);
> - vma = find_vma(current->mm, userptr);

For vma, ditto.

Thanks,
Inki Dae

[--SNIP--]

[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 #96 from Nicolas Werner  ---
(In reply to Alex Deucher from comment #95)
> Created attachment 115780 [details] [review]
> add some debugging output
> 
> Can you attach the dmesg output with the attached patch?

Seems like we're getting somewhere, looks like a bad pointer?

[5.645981] [drm] radeon_dp_getdpcd
[5.645988] [drm] dig_connector 8802a21c42c0
[5.645991] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[5.677325] [drm] fb mappable at 0xD047B000
[5.677330] [drm] vram apper at 0xD000
[5.677332] [drm] size 8294400
[5.677335] [drm] fb depth is 24
[5.677337] [drm]pitch is 7680
[5.677542] fbcon: radeondrmfb (fb0) is primary device
[5.677635] [drm:radeon_dp_set_link_config] *ERROR* corrupt dpcd, updating
[5.678223] [drm] radeon_dp_set_link_config, 54, 1
[5.678224] [drm] dig_connector 8802a21c42a0
[5.678225] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[6.818832] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
updating
[6.819418] [drm] radeon_dp_set_rx_power_state, 0
[6.819420] [drm] dig_connector 8802a21c42a0
[6.819421] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.953814] [drm:radeon_dp_link_train] *ERROR* corrupt dpcd, updating
[7.954642] [drm] radeon_dp_link_train
[7.954644] [drm] dig_connector 8802a21c42a0
[7.954645] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.954646] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.954647] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
updating
[7.954950] [drm] radeon_dp_getdpcd
[7.954951] [drm] dig_connector 8802a21c42a0
[7.954952] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[7.954954] [drm] radeon_dp_set_rx_power_state, 17
[7.954955] [drm] dig_connector 8802a21c42a0
[7.954956] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[7.962990] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5
times
[7.962991] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[8.361691] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[8.390386] [drm] Initialized radeon 2.40.0 20080528 for :00:01.0 on
minor 0
[   10.548765] [drm] radeon_dp_getdpcd
[   10.548773] [drm] dig_connector 8802a21c42c0
[   10.548777] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   10.579288] [drm] radeon_dp_getdpcd
[   10.579297] [drm] dig_connector 8802a21c42c0
[   10.579300] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   10.638418] [drm] radeon_dp_getdpcd
[   10.638425] [drm] dig_connector 8802a21c42c0
[   10.638428] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   10.667255] [drm] radeon_dp_getdpcd
[   10.667263] [drm] dig_connector 8802a21c42c0
[   10.667267] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

-- 
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/20150514/81d1660e/attachment.html>

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

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #115774|0   |1
is obsolete||

--- Comment #95 from Alex Deucher  ---
Created attachment 115780
  --> https://bugs.freedesktop.org/attachment.cgi?id=115780=edit
add some debugging output

Can you attach the dmesg output with the attached 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/20150514/af8b2cc5/attachment.html>

[PATCH] fix typo for drmOpenByName

[Daniel Kurtz]

NAK.  The original code is correct.

On Thu, May 14, 2015 at 2:17 PM, Guo Yejun  wrote:
> Signed-off-by: Guo Yejun 
> ---
>  xf86drm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index f7c45f8..5e7306e 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -635,9 +635,8 @@ static int drmOpenByName(const char *name, int type)
> drmFreeVersion(version);
> id = drmGetBusid(fd);
> drmMsg("drmGetBusid returned '%s'\n", id ? id : "NULL");
> -   if (!id || !*id) {
> -   if (id)
> -   drmFreeBusid(id);

This code basically says:
If no string was returned (id == NULL), or an empty string (*id ==
NULL), aka "", then return fd and free id if it was an empty string.

> +   if (id && *id) {
> +   drmFreeBusid(id);
> return fd;
> } else {
> drmFreeBusid(id);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 #94 from Nicolas Werner  ---
(In reply to Alex Deucher from comment #93)
> Created attachment 115778 [details] [review]
> debuging patch
> 
> Your dpcd is indeed getting corrupted somehow.  I can't see how though.  The
> attached patch (please drop your hardcode to 2 patch when you apply this
> one) should workaround the issue by re-fetching the dpcd when required, but
> doesn't fix the root cause.  Please attach the dmesg output with this patch
> applied as well.  I'd like to see how often it's getting corrupted.

Interestingly this doesn't work, I get the same blackscreen as usually:

[5.946595] [drm] radeon_dp_getdpcd
[5.946601] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[5.978557] [drm] fb mappable at 0xD047B000
[5.978563] [drm] vram apper at 0xD000
[5.978565] [drm] size 8294400
[5.978567] [drm] fb depth is 24
[5.978569] [drm]pitch is 7680
[5.978789] fbcon: radeondrmfb (fb0) is primary device
[5.978881] [drm:radeon_dp_set_link_config] *ERROR* corrupt dpcd, updating
[5.979556] [drm] radeon_dp_set_link_config, 54, 1
[5.979558] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.118887] [drm] radeon_dp_set_rx_power_state, 0
[7.118889] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.118891] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
updating
[8.254349] [drm:radeon_dp_link_train] *ERROR* corrupt dpcd, updating
[8.255018] [drm] radeon_dp_link_train
[8.255019] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[8.255020] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[8.255022] [drm] radeon_dp_set_rx_power_state, 0
[8.255023] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[8.255024] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
updating
[8.255326] [drm] radeon_dp_getdpcd
[8.255326] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[8.263438] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5
times
[8.263440] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[8.662772] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[8.691450] [drm] Initialized radeon 2.40.0 20080528 for :00:01.0 on
minor 0
[   11.436860] [drm] radeon_dp_getdpcd
[   11.436866] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.467143] [drm] radeon_dp_getdpcd
[   11.467151] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.530015] [drm] radeon_dp_getdpcd
[   11.530021] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.558174] [drm] radeon_dp_getdpcd
[   11.558182] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

-- 
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/20150514/8aa6855c/attachment.html>

[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 #93 from Alex Deucher  ---
Created attachment 115778
  --> https://bugs.freedesktop.org/attachment.cgi?id=115778=edit
debuging patch

Your dpcd is indeed getting corrupted somehow.  I can't see how though.  The
attached patch (please drop your hardcode to 2 patch when you apply this one)
should workaround the issue by re-fetching the dpcd when required, but doesn't
fix the root cause.  Please attach the dmesg output with this patch applied as
well.  I'd like to see how often it's getting corrupted.

-- 
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/20150514/8ec35659/attachment.html>

[PATCH] drm: remove unused function

[Sudip Mukherjee]

this function was not used anywhere and was giving a build warning.

Signed-off-by: Sudip Mukherjee 
---
 drivers/gpu/drm/drm_crtc.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4059f06..6e60f71 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4313,25 +4313,6 @@ void drm_property_unreference_blob(struct 
drm_property_blob *blob)
 EXPORT_SYMBOL(drm_property_unreference_blob);

 /**
- * drm_property_unreference_blob_locked - Unreference a blob property with 
blob_lock held
- *
- * Drop a reference on a blob property. May free the object. This must be
- * called with blob_lock held.
- *
- * @param dev  Device the blob was created on
- * @param blob Pointer to blob property
- */
-static void drm_property_unreference_blob_locked(struct drm_property_blob 
*blob)
-{
-   if (!blob)
-   return;
-
-   DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id, 
atomic_read(>refcount.refcount));
-
-   kref_put(>refcount, drm_property_free_blob);
-}
-
-/**
  * drm_property_reference_blob - Take a reference on an existing property
  *
  * Take a new reference on an existing blob property.
-- 
1.8.1.2

[PATCH 1/1] drm/bridge: ptn3460: Fix I2C ID table to match the reported modalias

[Javier Martinez Canillas]

I2C drivers that support OF, have both an I2C and OF device ID tables
that are used to fill the supported module aliases. But currently the
I2C core only uses the OF table to match a device with a driver and
the aliases information are always reported in the form i2c:.

The client->name is used as the name postfix and when booting with OF
this is obtained with of_modalias_node() which drops the compatible
string vendor prefix.

So for I2C drivers, the I2C and OF device ID tables should be keep in
sync in order to make module auto-loading to work but the I2C device
entries shouldn't have the vendor prefix since that is not reported.

Before this patch:

MODALIAS=i2c:ptn3460

$ modinfo | grep alias
alias:  i2c:nxp,ptn3460
alias:  of:N*T*Cnxp,ptn3460*

After this patch:

MODALIAS=i2c:ptn3460

$ modinfo | grep alias
alias:  i2c:ptn3460
alias:  of:N*T*Cnxp,ptn3460*

Signed-off-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/bridge/ptn3460.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9d2f053382e1..2cc15419088d 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -389,7 +389,7 @@ static int ptn3460_remove(struct i2c_client *client)
 }

 static const struct i2c_device_id ptn3460_i2c_table[] = {
-   {"nxp,ptn3460", 0},
+   {"ptn3460", 0},
{},
 };
 MODULE_DEVICE_TABLE(i2c, ptn3460_i2c_table);
-- 
2.1.4

[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 #92 from Nicolas Werner  ---
I accidently truncated the dmesg output, here's everything containing drm:
[2.430644] [drm] Initialized drm 1.1.0 20060810
[2.461050] [drm] radeon kernel modesetting enabled.
[2.467555] fb: switching to radeondrmfb from simple
[2.470628] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908
0x1043:0x1557).
[2.470651] [drm] register mmio base: 0xFEB0
[2.470695] [drm] register mmio size: 262144
[2.470704] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size
19968
[2.470848] [drm] Detected VRAM RAM=768M, BAR=256M
[2.470851] [drm] RAM width 64bits DDR
[2.486341] [drm] radeon: 768M of VRAM memory ready
[2.486345] [drm] radeon: 1024M of GTT memory ready.
[2.486411] [drm] Loading ARUBA Microcode
[2.492679] [drm] Internal thermal controller without fan control
[2.493274] [drm] radeon: dpm initialized
[2.494685] [drm] GART: num cpu pages 262144, num gpu pages 262144
[2.606096] [drm] PCIE GART of 1024M enabled (table at 0x00277000).
[2.619553] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.619555] [drm] Driver supports precise vblank timestamp query.
[2.619902] [drm] radeon: irq initialized.
[2.709613] [drm] ring test on 0 succeeded in 2 usecs
[2.709627] [drm] ring test on 3 succeeded in 3 usecs
[2.709636] [drm] ring test on 4 succeeded in 3 usecs
[2.978514] [drm] ring test on 5 succeeded in 1 usecs
[3.006343] [drm] UVD initialized successfully.
[3.016637] [drm] ib test on ring 0 succeeded in 0 usecs
[3.017179] [drm] ib test on ring 3 succeeded in 0 usecs
[3.017722] [drm] ib test on ring 4 succeeded in 0 usecs
[3.039679] [drm] ib test on ring 5 succeeded
[3.089055] [drm] radeon atom DIG backlight initialized
[3.089064] [drm] Radeon Display Connectors
[3.089066] [drm] Connector 0:
[3.089069] [drm]   eDP-1
[3.089071] [drm]   HPD1
[3.089075] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c
0x653c
[3.089076] [drm]   Encoders:
[3.089079] [drm] LCD1: INTERNAL_UNIPHY2
[3.089080] [drm] Connector 1:
[3.089082] [drm]   VGA-1
[3.089084] [drm]   HPD2
[3.089086] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c
0x654c
[3.089087] [drm]   Encoders:
[3.089089] [drm] CRT1: INTERNAL_UNIPHY2
[3.089091] [drm] CRT1: NUTMEG
[3.089092] [drm] Connector 2:
[3.089094] [drm]   HDMI-A-1
[3.089095] [drm]   HPD3
[3.089097] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c
0x655c
[3.089099] [drm]   Encoders:
[3.089100] [drm] DFP1: INTERNAL_UNIPHY
[5.243213] [drm] radeon_dp_getdpcd
[5.243219] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[5.274840] [drm] fb mappable at 0xD047B000
[5.274847] [drm] vram apper at 0xD000
[5.274855] [drm] size 8294400
[5.274859] [drm] fb depth is 24
[5.274861] [drm]pitch is 7680
[5.275084] fbcon: radeondrmfb (fb0) is primary device
[5.275155] [drm] radeon_dp_set_link_config, 27, 2
[5.275156] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[6.415109] [drm] radeon_dp_set_rx_power_state, 0
[6.415111] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.551762] [drm] radeon_dp_link_train
[7.551764] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.551765] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.551767] [drm] radeon_dp_set_rx_power_state, 0
[7.551768] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.962006] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[8.186573] [drm] Initialized radeon 2.40.0 20080528 for :00:01.0 on
minor 0
[   11.153606] [drm] radeon_dp_getdpcd
[   11.153612] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.183328] [drm] radeon_dp_getdpcd
[   11.183337] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.245364] [drm] radeon_dp_getdpcd
[   11.245371] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.277369] [drm] radeon_dp_getdpcd
[   11.277378] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   20.940212] [drm] radeon_dp_getdpcd
[   20.940218] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   20.968521] [drm] radeon_dp_getdpcd
[   20.968531] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   23.727223] [drm] radeon_dp_getdpcd
[   23.727231] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   23.754387] [drm] radeon_dp_getdpcd
[   23.754396] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

-- 
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/20150514/219c45da/attachment.html>

[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 #91 from Nicolas Werner  ---
(In reply to Alex Deucher from comment #90)
> (In reply to Nicolas Werner from comment #89)
> > (In reply to Alex Deucher from comment #88)
> > > Created attachment 115774 [details] [review] [review] [review]
> > > add some debugging output
> > > 
> > > Can you attach your dmesg output with this patch attached?  It should help
> > > narrow down where the dpcd info is getting corrupted.
> > 
> > Here it is (only the relevant section):
> > [5.534907] [drm] radeon_dp_getdpcd
> > [5.534913] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
> > [5.565816] [drm] fb mappable at 0xD047B000
> > [5.565823] [drm] vram apper at 0xD000
> > [5.565825] [drm] size 8294400
> > [5.565828] [drm] fb depth is 24
> > [5.565830] [drm]pitch is 7680
> > [5.566022] fbcon: radeondrmfb (fb0) is primary device
> > [5.566093] [drm] radeon_dp_set_link_config, 27, 2
> > [5.566095] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Are you still hardcoding the lanes here?
> 
> 
> > [6.706063] [drm] radeon_dp_set_rx_power_state, 0
> > [6.706065] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [7.843201] [drm] radeon_dp_link_train
> > [7.843203] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [7.843204] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00
> > [7.843206] [drm] radeon_dp_set_rx_power_state, 0
> > [7.843206] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Yes, I wouldn't get a working display otherwise, should I try without 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/20150514/2571/attachment-0001.html>

[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 #90 from Alex Deucher  ---
(In reply to Nicolas Werner from comment #89)
> (In reply to Alex Deucher from comment #88)
> > Created attachment 115774 [details] [review] [review]
> > add some debugging output
> > 
> > Can you attach your dmesg output with this patch attached?  It should help
> > narrow down where the dpcd info is getting corrupted.
> 
> Here it is (only the relevant section):
> [5.534907] [drm] radeon_dp_getdpcd
> [5.534913] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
> [5.565816] [drm] fb mappable at 0xD047B000
> [5.565823] [drm] vram apper at 0xD000
> [5.565825] [drm] size 8294400
> [5.565828] [drm] fb depth is 24
> [5.565830] [drm]pitch is 7680
> [5.566022] fbcon: radeondrmfb (fb0) is primary device
> [5.566093] [drm] radeon_dp_set_link_config, 27, 2
> [5.566095] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Are you still hardcoding the lanes here?


> [6.706063] [drm] radeon_dp_set_rx_power_state, 0
> [6.706065] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [7.843201] [drm] radeon_dp_link_train
> [7.843203] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [7.843204] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> [7.843206] [drm] radeon_dp_set_rx_power_state, 0
> [7.843206] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-- 
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/20150514/3a540c4f/attachment.html>

drm/exynos: Add atomic modesetting support

[Gustavo Padovan]

Hi Inki and Tobias,

2015-05-12 Gustavo Padovan :

> 2015-05-10 Inki Dae :
> 
> > 2015-05-09 21:13 GMT+09:00 Tobias Jakobi :
> > > Hello Inki,
> > >
> > >
> > > Inki Dae wrote:
> > >> Hi,
> > >>
> > >> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
> > >>> Hello,
> > >>>
> > >>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
> > >>> 1080p panel).
> > >>>
> > >>> Run the usual modetest tests (just primary plane, primary plane with
> > >>> vsync, primary plane with overlay, primary plane with overlay and video
> > >>> overlay, overlay partially outside of crtc area, etc.) and haven't
> > >>> noticed any issues so far.
> > >>
> > >> As I mentioned several times, it works well in case that only one crtc
> > >> driver is enabled. Could you check it again after you enable two or
> > >> more crtc drivers such as FIMD and HDMI or FIMD, HDMI and VIDI
> > >> together? For this, dts file for X2 should contain their device nodes
> > >> and also should be configurated though menuconfig.
> > > I've enabled VIDI and FIMD and confirmed that they should up properly in
> > > modetest before applying the series.
> > >
> > > Booting with the atomic series works fine, but I get a segfault when
> > > calling modetest. I've attached the kernel log below.
> > 
> > Below panic issue is same as one I faced with at previous patch seris,
> > v3, which was invalid memory access - state->crtc is NULL whille
> > modetest is being performed. It seems that the last patch of v4 didn't
> > resolve this issue yet.
> 
> The weird thing is that it works quite fine on my exynos 5 hardware.
> I'll take a look on what could be be happening to cause this kind of
> crash.

Can you please check if the following diff solves the issue?

iff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 8a1cd8b..3d64799 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -163,6 +163,9 @@ static void exynos_plane_atomic_update(struct drm_plane 
*plane,
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(state->crtc);
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);

+   if (!state->crtc)
+   return;
+
exynos_plane_mode_set(plane, state->crtc, state->fb,
  state->crtc_x, state->crtc_y,
  state->crtc_w, state->crtc_h,
@@ -179,6 +182,9 @@ static void exynos_plane_atomic_disable(struct drm_plane 
*plane,
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(old_state->crtc);

+   if (!old_state->crtc)
+   return;
+
if (exynos_crtc->ops->disable_plane)
exynos_crtc->ops->disable_plane(exynos_crtc,
exynos_plane->zpos);

[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 #89 from Nicolas Werner  ---
(In reply to Alex Deucher from comment #88)
> Created attachment 115774 [details] [review]
> add some debugging output
> 
> Can you attach your dmesg output with this patch attached?  It should help
> narrow down where the dpcd info is getting corrupted.

Here it is (only the relevant section):
[5.534907] [drm] radeon_dp_getdpcd
[5.534913] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[5.565816] [drm] fb mappable at 0xD047B000
[5.565823] [drm] vram apper at 0xD000
[5.565825] [drm] size 8294400
[5.565828] [drm] fb depth is 24
[5.565830] [drm]pitch is 7680
[5.566022] fbcon: radeondrmfb (fb0) is primary device
[5.566093] [drm] radeon_dp_set_link_config, 27, 2
[5.566095] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[6.706063] [drm] radeon_dp_set_rx_power_state, 0
[6.706065] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.843201] [drm] radeon_dp_link_train
[7.843203] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.843204] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[7.843206] [drm] radeon_dp_set_rx_power_state, 0
[7.843206] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-- 
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/20150514/6331a4b0/attachment.html>

[PATCH 2/2] drm: rcar-du: Disable all planes when stopping the CRTC

[Laurent Pinchart]

The DSnPR plane configuration registers are updated on vblank, and no
vblank will occur once the CRTC is stopped. We thus can't only disable
planes right before starting the CRTC as it would start scanning out
immediately from old frame buffers until the next vblank.

Fix the problem by disabling all planes when stopping the CRTC and wait
for the change to take effect. This increases the CRTC stop delay,
especially when multiple CRTCs are stopped in one operation as we now
wait for one vblank per CRTC. Whether this can be improved needs to be
researched.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index e6a32c4e4040..a40085806f5b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -398,6 +398,19 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (!rcrtc->started)
return;

+   /* Disable all planes and wait for the change to take effect. This is
+* required as the DSnPR registers are updated on vblank, and no vblank
+* will occur once the CRTC is stopped. Disabling planes when starting
+* the CRTC thus wouldn't be enough as it would start scanning out
+* immediately from old frame buffers until the next vblank.
+*
+* This increases the CRTC stop delay, especially when multiple CRTCs
+* are stopped in one operation as we now wait for one vblank per CRTC.
+* Whether this can be improved needs to be researched.
+*/
+   rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
+   drm_crtc_wait_one_vblank(crtc);
+
/* Disable vertical blanking interrupt reporting. We first need to wait
 * for page flip completion before stopping the CRTC as userspace
 * expects page flips to eventually complete.
-- 
Regards,

Laurent Pinchart

[PATCH 1/2] drm: rcar-du: Print the error value when DRM/KMS init fails

[Laurent Pinchart]

This helps debugging probe failures.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index da1216a73969..780ca11512ba 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -190,7 +190,7 @@ static int rcar_du_load(struct drm_device *dev, unsigned 
long flags)
/* DRM/KMS objects */
ret = rcar_du_modeset_init(rcdu);
if (ret < 0) {
-   dev_err(>dev, "failed to initialize DRM/KMS\n");
+   dev_err(>dev, "failed to initialize DRM/KMS (%d)\n", ret);
goto done;
}

-- 
Regards,

Laurent Pinchart

[PATCH] drm: adv7511: Fix crash in IRQ handler when no encoder is associated

[Laurent Pinchart]

The ADV7511 is probed before its slave encoder init function associates
it with an encoder. This creates a time window during which hot plug
detection interrupts can occur with an encoder, resulting in a crash in
the IRQ handler.

Fix this by ignoring hot plug detection IRQs when no encoder is
associated yet.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/i2c/adv7511.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index b728523e194f..2aaa3c88999e 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -438,7 +438,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511)
regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);

-   if (irq0 & ADV7511_INT0_HDP)
+   if (irq0 & ADV7511_INT0_HDP && adv7511->encoder)
drm_helper_hpd_irq_event(adv7511->encoder->dev);

if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
-- 
Regards,

Laurent Pinchart

[PATCH v2 1/4] break kconfig dependency loop

[Mauro Carvalho Chehab]

Em Wed,  1 Apr 2015 15:15:27 +0200
Gerd Hoffmann  escreveu:

> After adding virtio-gpu I get this funky kconfig dependency loop.
> 
> scripts/kconfig/conf --oldconfig Kconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by 
> DRM_VIRTIO_GPU
> drivers/gpu/drm/virtio/Kconfig:1:   symbol DRM_VIRTIO_GPU depends on 
> VIRTIO
> drivers/virtio/Kconfig:1:   symbol VIRTIO is selected by REMOTEPROC
> drivers/remoteproc/Kconfig:4:   symbol REMOTEPROC is selected by 
> OMAP_REMOTEPROC
> drivers/remoteproc/Kconfig:12:  symbol OMAP_REMOTEPROC depends on OMAP_IOMMU
> drivers/iommu/Kconfig:141:  symbol OMAP_IOMMU is selected by VIDEO_OMAP3
> drivers/media/platform/Kconfig:96:  symbol VIDEO_OMAP3 depends on 
> VIDEO_V4L2
> drivers/media/v4l2-core/Kconfig:6:  symbol VIDEO_V4L2 depends on I2C
> drivers/i2c/Kconfig:7:  symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
> drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on 
> FB_CYBER2000
> drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB
> 
> Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the
> loop, which looks like the best way to handle it to me.  I'm open to better
> suggestions though.

Gerd,

It seems that I never actually acked or nacked about this patch.

I'm ok with such change. So:

Acked-by: Mauro Carvalho Chehab 

Btw, it would make sense to add some help for config OMAP_IOMMU and
say that this is required in order to compile the OMAP3 media platform
drivers at drivers/iommu/Kconfig.

Regards,
Mauro

> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/media/platform/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index d9b872b..fc21734 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -87,8 +87,8 @@ config VIDEO_OMAP3
>   tristate "OMAP 3 Camera support"
>   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
>   depends on HAS_DMA
> + depends on OMAP_IOMMU
>   select ARM_DMA_USE_IOMMU
> - select OMAP_IOMMU
>   select VIDEOBUF2_DMA_CONTIG
>   ---help---
> Driver for an OMAP 3 camera controller.

[PATCH] drm: remove unused function

[Daniel Stone]

Hi Sudip,

On 14 May 2015 at 12:14, Sudip Mukherjee  wrote:
> this function was not used anywhere and was giving a build warning.

Thanks for the patch, but this function is used in following patches
that are in the process of being merged. This shouldn't have snuck in
in the earlier patch; apologies.

Cheers,
Daniel

[PATCH] drm: adv7511: Fix crash in IRQ handler when no encoder is associated

[Lars-Peter Clausen]

On 05/14/2015 02:29 PM, Laurent Pinchart wrote:
> The ADV7511 is probed before its slave encoder init function associates
> it with an encoder. This creates a time window during which hot plug
> detection interrupts can occur with an encoder, resulting in a crash in
> the IRQ handler.
>
> Fix this by ignoring hot plug detection IRQs when no encoder is
> associated yet.
>
> Signed-off-by: Laurent Pinchart 

Acked-by: Lars-Peter Clausen 

> ---
>   drivers/gpu/drm/i2c/adv7511.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> index b728523e194f..2aaa3c88999e 100644
> --- a/drivers/gpu/drm/i2c/adv7511.c
> +++ b/drivers/gpu/drm/i2c/adv7511.c
> @@ -438,7 +438,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511)
>   regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
>   regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
>
> - if (irq0 & ADV7511_INT0_HDP)
> + if (irq0 & ADV7511_INT0_HDP && adv7511->encoder)
>   drm_helper_hpd_irq_event(adv7511->encoder->dev);
>
>   if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
>

[PATCH] fix typo for drmOpenByName

[Guo Yejun]

Signed-off-by: Guo Yejun 
---
 xf86drm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index f7c45f8..5e7306e 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -635,9 +635,8 @@ static int drmOpenByName(const char *name, int type)
drmFreeVersion(version);
id = drmGetBusid(fd);
drmMsg("drmGetBusid returned '%s'\n", id ? id : "NULL");
-   if (!id || !*id) {
-   if (id)
-   drmFreeBusid(id);
+   if (id && *id) {
+   drmFreeBusid(id);
return fd;
} else {
drmFreeBusid(id);
-- 
1.9.1

[PATCH 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()

[Jan Kara]

On Thu 14-05-15 19:51:23, Inki Dae wrote:
> Hi,
> 
> On 2015년 05월 13일 22:08, Jan Kara wrote:
> > Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
> > This removes the knowledge about vmas and mmap_sem locking from exynos
> > driver. Also it fixes a problem that the function has been mapping user
> > provided address without holding mmap_sem.
> > 
> > Signed-off-by: Jan Kara 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 89 ++
> >  drivers/gpu/drm/exynos/exynos_drm_gem.c | 97 
> > -
> >  2 files changed, 29 insertions(+), 157 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > index 81a250830808..265519c0fe2d 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > @@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
> > dma_addr_t  dma_addr;
> > unsigned long   userptr;
> > unsigned long   size;
> > -   struct page **pages;
> > -   unsigned intnpages;
> > +   struct frame_vector *vec;
> > struct sg_table *sgt;
> > -   struct vm_area_struct   *vma;
> > atomic_trefcount;
> > boolin_pool;
> > boolout_of_list;
> > @@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device 
> > *drm_dev,
> >  {
> > struct g2d_cmdlist_userptr *g2d_userptr =
> > (struct g2d_cmdlist_userptr *)obj;
> > +   struct page **pages;
> >  
> > if (!obj)
> > return;
> > @@ -382,19 +381,21 @@ out:
> > exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
> > DMA_BIDIRECTIONAL);
> >  
> > -   exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
> > -   g2d_userptr->npages,
> > -   g2d_userptr->vma);
> > +   pages = frame_vector_pages(g2d_userptr->vec);
> > +   if (!IS_ERR(pages)) {
> > +   int i;
> >  
> > -   exynos_gem_put_vma(g2d_userptr->vma);
> > +   for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
> > +   set_page_dirty_lock(pages[i]);
> > +   }
> > +   put_vaddr_frames(g2d_userptr->vec);
> > +   frame_vector_destroy(g2d_userptr->vec);
> >  
> > if (!g2d_userptr->out_of_list)
> > list_del_init(_userptr->list);
> >  
> > sg_free_table(g2d_userptr->sgt);
> > kfree(g2d_userptr->sgt);
> > -
> > -   drm_free_large(g2d_userptr->pages);
> > kfree(g2d_userptr);
> >  }
> >  
> > @@ -413,6 +414,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
> > drm_device *drm_dev,
> > struct vm_area_struct *vma;
> > unsigned long start, end;
> > unsigned int npages, offset;
> > +   struct frame_vector *vec;
> > int ret;
> >  
> > if (!size) {
> > @@ -456,65 +458,37 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
> > drm_device *drm_dev,
> > return ERR_PTR(-ENOMEM);
> >  
> > atomic_set(_userptr->refcount, 1);
> > +   g2d_userptr->size = size;
> >  
> > start = userptr & PAGE_MASK;
> > offset = userptr & ~PAGE_MASK;
> > end = PAGE_ALIGN(userptr + size);
> > npages = (end - start) >> PAGE_SHIFT;
> > -   g2d_userptr->npages = npages;
> > -
> > -   pages = drm_calloc_large(npages, sizeof(struct page *));
> 
> The declaration to pages isn't needed anymore because you removed it.
> 
> > -   if (!pages) {
> > -   DRM_ERROR("failed to allocate pages.\n");
> > -   ret = -ENOMEM;
> > +   vec = g2d_userptr->vec = frame_vector_create(npages);
> 
> I think you can use g2d_userptr->vec so it seems that vec isn't needed.
> 
> > +   if (!vec)
> > goto err_free;
> > -   }
> >  
> > -   down_read(>mm->mmap_sem);
> > -   vma = find_vma(current->mm, userptr);
> 
> For vma, ditto.
  Thanks for review! Attached is a new version of the patch.

Honza

-- 
Jan Kara 
SUSE Labs, CR
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-exynos-Convert-g2d_userptr_get_dma_addr-to-use-g.patch
Type: text/x-patch
Size: 7676 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/cf217dc2/attachment.bin>

[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 #88 from Alex Deucher  ---
Created attachment 115774
  --> https://bugs.freedesktop.org/attachment.cgi?id=115774=edit
add some debugging output

Can you attach your dmesg output with this patch attached?  It should help
narrow down where the dpcd info is getting corrupted.

-- 
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/20150514/228ede95/attachment.html>

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

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

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

--- Comment #13 from Sylvain BERTRAND  ---
mini-hangs, choppy action: while playing, the game freezes briefly, and
this happens randomly all the time.
When there is a lot of things happening on the screen, for instance in
a team fight, it freezes longer and more often (very choppy).

-- 
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/20150514/146dee11/attachment.html>

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

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

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

--- Comment #12 from Sylvain BERTRAND  ---
Created attachment 115773
  --> https://bugs.freedesktop.org/attachment.cgi?id=115773=edit
dota2 glitch screenshot

-- 
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/20150514/f6f7ef5b/attachment.html>

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

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

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

--- Comment #11 from Sylvain BERTRAND  ---
Created attachment 115772
  --> https://bugs.freedesktop.org/attachment.cgi?id=115772=edit
dota2 glitch screenshot

-- 
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/20150514/16fe5d03/attachment.html>

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

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

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

--- Comment #10 from Sylvain BERTRAND  ---
Created attachment 115771
  --> https://bugs.freedesktop.org/attachment.cgi?id=115771=edit
dota2 glitch screenshot

-- 
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/20150514/ef36754e/attachment.html>

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

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

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

--- Comment #9 from Sylvain BERTRAND  ---
Created attachment 115770
  --> https://bugs.freedesktop.org/attachment.cgi?id=115770=edit
dota2 glitch screenshot

-- 
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/20150514/53280407/attachment.html>

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

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

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

--- Comment #8 from Sylvain BERTRAND  ---
Created attachment 115769
  --> https://bugs.freedesktop.org/attachment.cgi?id=115769=edit
dota2 glitch screenshot

-- 
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/20150514/15098226/attachment.html>

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

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

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

--- Comment #7 from Sylvain BERTRAND  ---
Created attachment 115768
  --> https://bugs.freedesktop.org/attachment.cgi?id=115768=edit
dota2 glitch screenshot

-- 
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/20150514/4d326926/attachment-0001.html>

[Bug 60553] [trine2] wrong colors when executed fullscreen

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

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

letharion at gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from letharion at gmail.com ---
I tested on the current git version today, and this is no longer an issue. :)

-- 
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/20150514/39c26d73/attachment.html>

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

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

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

--- Comment #6 from Sylvain BERTRAND  ---
Created attachment 115767
  --> https://bugs.freedesktop.org/attachment.cgi?id=115767=edit
dota2 glitch screenshot

-- 
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/20150514/b7115389/attachment.html>

[PATCH] fix typo for drmOpenByName

[Guo, Yejun]

Thanks  Daniel Kurtz  and Emil Velikov for the reply.

In general, drm APIs are invoked by user mode drivers, but, I want to mimic the 
behavior of driver in my unit test to create buffer objects. After do some 
searching, I wrote the following code in my unit test (user mode simple 
application based on libdrm). It does work in my old system (cannot go back to 
it and so do not know the exact version), but it failed when porting the unit 
test based on latest libdrm code. I stepped into function drmOpenByName and 
thought it is a typo.

int fd = drmOpen("i915", NULL);
drm_intel_bufmgr* bufmgr = drm_intel_bufmgr_gem_init(fd, 1024);
   drm_intel_bo * bo = drm_intel_bo_alloc(bufmgr,...);

After read the comment, looks like the above code is not used as expected. (I 
execute the utest together with X11 is running). 

Back to my original purpose, what's the correct way for me to create bo?   One 
possible way is to open("/dev/dri/renderDxxx"), but what should I do if the 
kernel version is too low to has this feature? 

Thanks.
Yejun

-Original Message-
From: djkurtz at google.com [mailto:djku...@google.com] On Behalf Of Daniel 
Kurtz
Sent: Thursday, May 14, 2015 6:53 PM
To: Guo, Yejun
Cc: dri-devel
Subject: Re: [PATCH] fix typo for drmOpenByName

NAK.  The original code is correct.

On Thu, May 14, 2015 at 2:17 PM, Guo Yejun  wrote:
> Signed-off-by: Guo Yejun 
> ---
>  xf86drm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index f7c45f8..5e7306e 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -635,9 +635,8 @@ static int drmOpenByName(const char *name, int type)
> drmFreeVersion(version);
> id = drmGetBusid(fd);
> drmMsg("drmGetBusid returned '%s'\n", id ? id : "NULL");
> -   if (!id || !*id) {
> -   if (id)
> -   drmFreeBusid(id);

This code basically says:
If no string was returned (id == NULL), or an empty string (*id == NULL), aka 
"", then return fd and free id if it was an empty string.

> +   if (id && *id) {
> +   drmFreeBusid(id);
> return fd;
> } else {
> drmFreeBusid(id);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Add DRM_CAS for mips32

[Matt Turner]

On Thu, May 14, 2015 at 5:12 AM, Aleksey Kuleshov  wrote:
> Signed-off-by: Aleksey Kuleshov 
> ---

At least a few years ago, DRM_CAS was only used by DRI1 which is
pretty dead at this point. Has something changed?

What problem are you trying to solve?

[radeon] drm-fixes-4.1

[Alex Deucher]

Hi Dave,

A just a few small fixes for radeon.

The following changes since commit 332545b3016cbff066c17037d32ec8aae8e4cfb5:

  Merge tag 'drm-intel-fixes-2015-05-08' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-05-11 06:06:22 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.1

for you to fetch changes up to bed447e7d1bd2d32d3fb09b4de0d0d5a23d3f82b:

  drm/radeon: don't do mst probing if MST isn't enabled. (2015-05-14 11:46:47 
-0400)


Alex Deucher (1):
  drm/radeon: add new bonaire pci id

Christian König (1):
  drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling

Dave Airlie (1):
  drm/radeon: don't do mst probing if MST isn't enabled.

 drivers/gpu/drm/radeon/cik.c   | 4 ++--
 drivers/gpu/drm/radeon/evergreen.c | 2 +-
 drivers/gpu/drm/radeon/ni.c| 5 +++--
 drivers/gpu/drm/radeon/r600.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 3 +++
 drivers/gpu/drm/radeon/rv770.c | 2 +-
 drivers/gpu/drm/radeon/si.c| 4 ++--
 include/drm/drm_pciids.h   | 1 +
 8 files changed, 14 insertions(+), 9 deletions(-)

[PATCH] fix typo for drmOpenByName

[Emil Velikov]

On 14 May 2015 at 07:17, Guo Yejun  wrote:
> Signed-off-by: Guo Yejun 
> ---
>  xf86drm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index f7c45f8..5e7306e 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -635,9 +635,8 @@ static int drmOpenByName(const char *name, int type)
> drmFreeVersion(version);
> id = drmGetBusid(fd);
> drmMsg("drmGetBusid returned '%s'\n", id ? id : "NULL");
> -   if (!id || !*id) {
> -   if (id)
> -   drmFreeBusid(id);
> +   if (id && *id) {
> +   drmFreeBusid(id);
I believe that it's correct as is, at least according to the comment
just before the loop. What makes you think that it's a typo ?
Admittedly this function is not too pretty, but most of that is due to
it originating from the UMS era.

-Emil

[RFC][PATCH 2/2] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Paul Bolle]

A naive question and a nit follow. That's probably not what you'd like
to see for an RFC, but the patch got tangled up in my mail filter
anyhow.

On Wed, 2015-05-13 at 23:23 +0800, CK Hu wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/Kconfig

> +config DRM_MEDIATEK_FBDEV
> + bool "Enable legacy fbdev support for Mediatek DRM"
> + depends on DRM_MEDIATEK
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select DRM_KMS_FB_HELPER
> + help
> +   Choose this option if you have a need for the legacy
> +   fbdev support.  Note that this support also provides
> +   the Linux console on top of the Mediatek DRM mode
> +   setting driver.

Naive question, as I know next to nothing about drivers/gpu/drm.
DRM_MEDIATEK_FBDEV isn't used anywhere, as far as I can see. So all that
setting this Kconfig symbol does is selecting four other Kconfig
symbols. Is selecting those four symbols enough to get fbdev support?
Taking the Cargo Cult approach of looking at similar symbols
(DRM_I915_FBDEV, DRM_MSM_FBDEV, DRM_STI_FBDEV, and DRM_TEGRA_FBDEV) I
noticed that they all do a bit more than just selecting other symbols.

> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mediatek_drm_drv.c

> + * 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 states the license of this driver is GPL v2. (Identical comments
seem to be part of all files added in this patch.)

> +MODULE_LICENSE("GPL");

And, according to include/linux/module.h, this states the license is GPL
v2 or later. So I think that either the comment at the top of these
files or the ident used in the MODULE_LICENSE() macro needs to be
changed.

Thanks,


Paul Bolle

Radeon Verde displayport failure.

[Dave Jones]

On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
 > On Tue, May 12, 2015 at 8:04 PM, Dave Jones  
 > wrote:
 > > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
 > >
 > >  > > I tried tweaking the delays in 
 > > drm_dp_link_train_clock_recovery_delay, without any noticable
 > >  > > difference.  Is there something else I can try to make it try harder 
 > > before giving up?
 > >  > >
 > >  >
 > >  > Can you attach your boot dmesg output with drm.debug=0xf set?
 > >  >
 > >  > You might also check the dpcd values in the driver during boot up and
 > >  > link training.  There appears to be an issue where that data gets
 > >  > corrupted in some cases:
 > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
 > >
 > > I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios 
 > > for eDP'
 > > patches from that bug. Again, no obvious difference.
 > >
 > > Log from kernel with both applied attached.
 > >
 > > Also a log file from after I woke up the LCD when it was in sleep mode.
 > >
 > > Something else curious is how it only discovers a maximum mode from the LCD
 > > of 1024x768.
 > 
 > I looks like the monitor is not responding.  I'm not entirely sure
 > what's going on.  I posted a new debugging patch on the bug report
 > that will dump the dpcd at various times to see if and when it's
 > getting corrupt.  Fixing that should at least get the monitor to come
 > up reliably (assuming you are experiencing the same issue).

attached.

Dave

-- next part --
[7.071367] [drm] Initialized drm 1.1.0 20060810
[7.096163] [drm] radeon kernel modesetting enabled.
[7.096206] [drm:drm_pci_init] 
[7.096301] [drm:drm_get_pci_dev] 
[7.096385] [drm:drm_minor_register] 
[7.098055] [drm:drm_minor_register] new minor registered 64
[7.098065] [drm:drm_minor_register] 
[7.098158] [drm:drm_minor_register] new minor registered 128
[7.098163] [drm:drm_minor_register] 
[7.098225] [drm:drm_minor_register] new minor registered 0
[7.098237] [drm] initializing kernel modesetting (VERDE 0x1002:0x682C 
0x1002:0x2B1E).
[7.098251] [drm] register mmio base: 0xFBE0
[7.098254] [drm] register mmio size: 262144
[7.098315] [drm:radeon_get_bios] ATOMBIOS detected
[7.098325] [drm:atom_allocate_fb_scratch] atom firmware requested 001fffe0 
32kb
[7.098470] [drm] Detected VRAM RAM=2048M, BAR=256M
[7.098473] [drm] RAM width 128bits DDR
[7.098602] [drm] radeon: 2048M of VRAM memory ready
[7.098607] [drm] radeon: 1024M of GTT memory ready.
[7.098621] [drm:si_init_microcode] 
[7.098625] [drm] Loading verde Microcode
[7.103464] [drm] Internal thermal controller with fan control
[7.103596] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.103631] [drm:radeon_ucode_print_mc_hdr] MC
[7.103635] [drm:radeon_ucode_print_common_hdr] size_bytes: 32044
[7.103638] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 40
[7.103641] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.103645] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.103648] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.103651] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.103655] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x00a37610
[7.103658] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 31500
[7.103661] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 544
[7.103665] [drm:radeon_ucode_print_common_hdr] crc32: 0x442d834d
[7.103678] [drm:radeon_ucode_print_mc_hdr] io_debug_size_bytes: 288
[7.103681] [drm:radeon_ucode_print_mc_hdr] io_debug_array_offset_bytes: 256
[7.104415] [drm:radeon_ucode_print_smc_hdr] SMC
[7.104419] [drm:radeon_ucode_print_common_hdr] size_bytes: 61800
[7.104422] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36
[7.104426] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.104429] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.104432] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.104435] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.104439] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x0133524b
[7.104442] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 61544
[7.104445] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 256
[7.104449] [drm:radeon_ucode_print_common_hdr] crc32: 0xfcbfb6b3
[7.104452] [drm:radeon_ucode_print_smc_hdr] ucode_start_addr: 65536
[7.111599] [drm] radeon: dpm initialized
[7.135847] [drm] GART: num cpu pages 262144, num gpu pages 262144
[7.136428] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.136435] [drm] PCIE gen 3 link speeds already enabled
[7.141626] [drm] PCIE GART of 1024M enabled (table at 0x00277000).
[7.142164] [drm] Supports vblank timestamp caching 

[Bug 90439] [LLVM] Xonotic render green (bisected)

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

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

smoki  changed:

   What|Removed |Added

   Severity|normal  |critical

-- 
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/20150514/c4a96672/attachment.html>

[Bug 90439] [LLVM] Xonotic render green (bisected)

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

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

--- Comment #6 from smoki  ---
 Uploaded piglit comparison within these llvm commits

https://dl.dropboxusercontent.com/u/74553632/bug90439.tar.bz2

 So basicaly the same ~130 piglits fail, just like in bug 89034 if i enable
sub-reg liveness.

-- 
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/20150514/e9ee9fe6/attachment.html>

[PATCH v9.5.1 09/20] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

[Liu Ying]

This patch adds a helper to get bits per pixel value of MIPI DSI pixel format.
The helper takes a parameter in the type 'enum mipi_dsi_pixel_format' and
returns it's bits per pixel value if the parameter is valid, otherwise, it
returns -EINVAL.  The helper makes users' life easier to do the conversion
from a specific MIPI DSI pixel format to it's bits per pixel value.

Signed-off-by: Liu Ying 
---
v9.5->v9.5.1:
 * To address Thierry Reding's comments, add a commit message to describe why
   the helper is useful and when to use it and fix typo in kernel-doc from
   'mipi dsi' to 'MIPI DSI'.

v9->v9.5:
 * Add kernel-doc for the new helper function to address Daniel Vetter's
   comment.

v8->v9:
 * Rebase onto the imx-drm/next branch of Philipp Zabel's open git repository.

v7->v8:
 * None.

v6->v7:
 * None.

v5->v6:
 * Address the over 80 characters in one line warning reported by the
   checkpatch.pl script.

v4->v5:
 * None.

v3->v4:
 * None.

v2->v3:
 * None.

v1->v2:
 * Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function
   could be placed at the common DRM MIPI DSI driver.
   This patch is newly added.

 include/drm/drm_mipi_dsi.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..186b15b 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -163,6 +163,28 @@ static inline struct mipi_dsi_device 
*to_mipi_dsi_device(struct device *dev)
return container_of(dev, struct mipi_dsi_device, dev);
 }

+/**
+ * mipi_dsi_pixel_format_to_bpp() - get bits per pixel for a MIPI DSI
+ *pixel format
+ * @fmt: MIPI DSI pixel format
+ *
+ * Return: The bits per pixel value for the MIPI DSI pixel format on success or
+ *a negative error code on failure.
+ */
+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt)
+{
+   switch (fmt) {
+   case MIPI_DSI_FMT_RGB888:
+   case MIPI_DSI_FMT_RGB666:
+   return 24;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   return 18;
+   case MIPI_DSI_FMT_RGB565:
+   return 16;
+   }
+   return -EINVAL;
+}
+
 struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node 
*np);
 int mipi_dsi_attach(struct mipi_dsi_device *dsi);
 int mipi_dsi_detach(struct mipi_dsi_device *dsi);
-- 
1.9.1

[PATCH RFC v9.5 09/20] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

[Liu Ying]

2015-05-12 21:36 GMT+08:00 Thierry Reding :
> On Fri, Feb 13, 2015 at 01:25:19PM +0800, Liu Ying wrote:
>> Signed-off-by: Liu Ying 
>
> This could use a commit message. Describe for example why this is useful
> or when to use it.

Ok, I'll add it in the next version.

>
>> ---
>> v9->v9.5:
>>  * Add kernel-doc for the new helper function to address Daniel Vetter's
>>comment.
>>
>> v8->v9:
>>  * Rebase onto the imx-drm/next branch of Philipp Zabel's open git 
>> repository.
>>
>> v7->v8:
>>  * None.
>>
>> v6->v7:
>>  * None.
>>
>> v5->v6:
>>  * Address the over 80 characters in one line warning reported by the
>>checkpatch.pl script.
>>
>> v4->v5:
>>  * None.
>>
>> v3->v4:
>>  * None.
>>
>> v2->v3:
>>  * None.
>>
>> v1->v2:
>>  * Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function
>>could be placed at the common DRM MIPI DSI driver.
>>This patch is newly added.
>>
>>  include/drm/drm_mipi_dsi.h | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>> index f1d8d0d..cabc910 100644
>> --- a/include/drm/drm_mipi_dsi.h
>> +++ b/include/drm/drm_mipi_dsi.h
>> @@ -163,6 +163,28 @@ static inline struct mipi_dsi_device 
>> *to_mipi_dsi_device(struct device *dev)
>>   return container_of(dev, struct mipi_dsi_device, dev);
>>  }
>>
>> +/**
>> + * mipi_dsi_pixel_format_to_bpp() - get bits per pixel for a mipi dsi
>> + *pixel format
>> + * @fmt: mipi dsi pixel format
>> + *
>> + * Return: The bits per pixel value for the mipi dsi pixel format on 
>> success or
>> + *a negative error code on failure.
>> + */
>
> s/mipi dsi/MIPI DSI/, please.

Ok.

Thanks,
Liu Ying

>
> Thierry
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Best Regards,
Liu Ying

Radeon Verde displayport failure.

[Alex Deucher]

On Tue, May 12, 2015 at 8:04 PM, Dave Jones  wrote:
> On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
>
>  > > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, 
> without any noticable
>  > > difference.  Is there something else I can try to make it try harder 
> before giving up?
>  > >
>  >
>  > Can you attach your boot dmesg output with drm.debug=0xf set?
>  >
>  > You might also check the dpcd values in the driver during boot up and
>  > link training.  There appears to be an issue where that data gets
>  > corrupted in some cases:
>  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
>
> I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios for 
> eDP'
> patches from that bug. Again, no obvious difference.
>
> Log from kernel with both applied attached.
>
> Also a log file from after I woke up the LCD when it was in sleep mode.
>
> Something else curious is how it only discovers a maximum mode from the LCD
> of 1024x768.

I looks like the monitor is not responding.  I'm not entirely sure
what's going on.  I posted a new debugging patch on the bug report
that will dump the dpcd at various times to see if and when it's
getting corrupt.  Fixing that should at least get the monitor to come
up reliably (assuming you are experiencing the same issue).

Alex

[Bug 90439] [LLVM] Xonotic render green (bisected)

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

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

--- Comment #5 from smoki  ---
Created attachment 115764
  --> https://bugs.freedesktop.org/attachment.cgi?id=115764=edit
piglit-bad

 and bad with r237140

-- 
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/20150514/55371973/attachment.html>

[Bug 90439] [LLVM] Xonotic render green (bisected)

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

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

--- Comment #4 from smoki  ---
Created attachment 115763
  --> https://bugs.freedesktop.org/attachment.cgi?id=115763=edit
piglit-good

 Yes, example output is from:

 R600_DEBUG=ps,vs,gs ./bin/copy-pixels -samples=8 -auto

 on r237139

-- 
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/20150514/686f61a6/attachment.html>

[PATCH v2] drm/i915: fix screen flickering

[Thomas Gummerer]

Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
always on for wm calculation (v4)") fixes a null pointer dereference.
Setting the primary and cursor panes to false in
ilk_compute_wm_parameters to false does however give the following
errors in the kernel log and causes the screen to flicker.

[  101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
*ERROR* uncleared fifo underrun on pipe A
[  101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun

Always setting the panes to enabled fixes this error.

Helped-by: Matt Roper 
Signed-off-by: Thomas Gummerer 
---

> Sorry, I missed your patch when you first sent it.  That type of fix
> looks like an okay workaround while we do a more in-depth rework of the
> watermark system.  However I think your patch could cause a crash if we
> disable the primary plane via the universal plane interface; if we do
> that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
> the primary plane is always enabled, ilk_wm_fbc() can eventually get
> called and use that 0 in the denominator of a division operation.
>
> If you just squash the following change into your patch, I think it should be
> safe:
> [...]

Thank you very much for the suggestion, here is an updated version of the 
patch.

 drivers/gpu/drm/i915/intel_pm.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fa4ccb3..555b896 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc 
*crtc,
p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);

-   if (crtc->primary->state->fb) {
-   p->pri.enabled = true;
+   if (crtc->primary->state->fb)
p->pri.bytes_per_pixel =
crtc->primary->state->fb->bits_per_pixel / 8;
-   } else {
-   p->pri.enabled = false;
-   p->pri.bytes_per_pixel = 0;
-   }
+   else
+   p->pri.bytes_per_pixel = 4;
+
+   p->cur.bytes_per_pixel = 4;
+   /*
+* TODO: for now, assume primary and cursor planes are always enabled.
+* Setting them to false makes the screen flicker.
+*/
+   p->pri.enabled = true;
+   p->cur.enabled = true;

-   if (crtc->cursor->state->fb) {
-   p->cur.enabled = true;
-   p->cur.bytes_per_pixel = 4;
-   } else {
-   p->cur.enabled = false;
-   p->cur.bytes_per_pixel = 0;
-   }
p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;

-- 
2.4.0.184.g8e1974e

[PATCH] drm/exynos: dp: Lower level of EDID read success message

[Krzysztof Kozlowski]

Don't pollute the dmesg with EDID read success message as an error.
Printing as debug should be fine.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 441ef06b8894..30feb7d06624 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -195,7 +195,7 @@ static int exynos_dp_read_edid(struct exynos_dp_device *dp)
}
}

-   dev_err(dp->dev, "EDID Read success!\n");
+   dev_dbg(dp->dev, "EDID Read success!\n");
return 0;
 }

-- 
1.9.1

[PATCH 1/1] drm/bridge: ptn3460: Fix I2C ID table to match the reported modalias

[Doug Anderson]

Javier,

On Thu, May 14, 2015 at 7:31 AM, Javier Martinez Canillas
 wrote:
> I2C drivers that support OF, have both an I2C and OF device ID tables
> that are used to fill the supported module aliases. But currently the
> I2C core only uses the OF table to match a device with a driver and
> the aliases information are always reported in the form i2c:.
>
> The client->name is used as the name postfix and when booting with OF
> this is obtained with of_modalias_node() which drops the compatible
> string vendor prefix.
>
> So for I2C drivers, the I2C and OF device ID tables should be keep in
> sync in order to make module auto-loading to work but the I2C device
> entries shouldn't have the vendor prefix since that is not reported.
>
> Before this patch:
>
> MODALIAS=i2c:ptn3460
>
> $ modinfo | grep alias
> alias:  i2c:nxp,ptn3460
> alias:  of:N*T*Cnxp,ptn3460*
>
> After this patch:
>
> MODALIAS=i2c:ptn3460
>
> $ modinfo | grep alias
> alias:  i2c:ptn3460
> alias:  of:N*T*Cnxp,ptn3460*
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/gpu/drm/bridge/ptn3460.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Doug Anderson 

[PATCH v2] drm/i915: fix screen flickering

[Matt Roper]

On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
> always on for wm calculation (v4)") fixes a null pointer dereference.
> Setting the primary and cursor panes to false in
> ilk_compute_wm_parameters to false does however give the following
> errors in the kernel log and causes the screen to flicker.
> 
> [  101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
> *ERROR* uncleared fifo underrun on pipe A
> [  101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
> 
> Always setting the panes to enabled fixes this error.
> 
> Helped-by: Matt Roper 
> Signed-off-by: Thomas Gummerer 

Seems like a reasonable short-term workaround and returns us to how the
code used to behaves.

Reviewed-by: Matt Roper 

> ---
> 
> > Sorry, I missed your patch when you first sent it.  That type of fix
> > looks like an okay workaround while we do a more in-depth rework of the
> > watermark system.  However I think your patch could cause a crash if we
> > disable the primary plane via the universal plane interface; if we do
> > that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
> > the primary plane is always enabled, ilk_wm_fbc() can eventually get
> > called and use that 0 in the denominator of a division operation.
> >
> > If you just squash the following change into your patch, I think it should 
> > be
> > safe:
> > [...]
> 
> Thank you very much for the suggestion, here is an updated version of the 
> patch.
> 
>  drivers/gpu/drm/i915/intel_pm.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fa4ccb3..555b896 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc 
> *crtc,
>   p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
>   p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
>  
> - if (crtc->primary->state->fb) {
> - p->pri.enabled = true;
> + if (crtc->primary->state->fb)
>   p->pri.bytes_per_pixel =
>   crtc->primary->state->fb->bits_per_pixel / 8;
> - } else {
> - p->pri.enabled = false;
> - p->pri.bytes_per_pixel = 0;
> - }
> + else
> + p->pri.bytes_per_pixel = 4;
> +
> + p->cur.bytes_per_pixel = 4;
> + /*
> +  * TODO: for now, assume primary and cursor planes are always enabled.
> +  * Setting them to false makes the screen flicker.
> +  */
> + p->pri.enabled = true;
> + p->cur.enabled = true;
>  
> - if (crtc->cursor->state->fb) {
> - p->cur.enabled = true;
> - p->cur.bytes_per_pixel = 4;
> - } else {
> - p->cur.enabled = false;
> - p->cur.bytes_per_pixel = 0;
> - }
>   p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
>   p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
>  
> -- 
> 2.4.0.184.g8e1974e
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[Bug 90439] [LLVM] Xonotic render green (bisected)

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

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

--- Comment #3 from Michel Dänzer  ---
You said on IRC that the same commit also broke some piglit tests. If so,
please attach the good and bad R600_DEBUG=ps,vs,gs output for one of those.

-- 
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/20150514/9b3e55e2/attachment.html>

[Bug 90439] [LLVM] Xonotic render green (bisected)

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

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

Michel Dänzer  changed:

   What|Removed |Added

Summary|Xonotic render green|[LLVM] Xonotic render green
   |(bisected)  |(bisected)

-- 
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/20150514/d276279c/attachment.html>

[RFC][PATCH 2/2] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[CK Hu]

This patch is a DRM Driver for Mediatek SoC MT8173.
Now support one crtc with MIPI DSI interface.
We used GEM framework for buffer management and use iommu for
physically non-continuous memory.

Signed-off-by: CK Hu 
---
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/mediatek/Kconfig  |   28 +
 drivers/gpu/drm/mediatek/Makefile |   13 +
 drivers/gpu/drm/mediatek/mediatek_drm_crtc.c  |  246 
 drivers/gpu/drm/mediatek/mediatek_drm_crtc.h  |   80 ++
 drivers/gpu/drm/mediatek/mediatek_drm_crtc_main.c |  420 +++
 drivers/gpu/drm/mediatek/mediatek_drm_ddp.c   |  202 
 drivers/gpu/drm/mediatek/mediatek_drm_ddp.h   |   23 +
 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.c  |  346 ++
 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.h  |   33 +
 drivers/gpu/drm/mediatek/mediatek_drm_drv.c   |  369 ++
 drivers/gpu/drm/mediatek/mediatek_drm_drv.h   |   37 +
 drivers/gpu/drm/mediatek/mediatek_drm_dsi.c   | 1333 +
 drivers/gpu/drm/mediatek/mediatek_drm_dsi.h   |   71 ++
 drivers/gpu/drm/mediatek/mediatek_drm_fb.c|  339 ++
 drivers/gpu/drm/mediatek/mediatek_drm_fb.h|   43 +
 drivers/gpu/drm/mediatek/mediatek_drm_gem.c   |  315 +
 drivers/gpu/drm/mediatek/mediatek_drm_gem.h   |   94 ++
 include/uapi/drm/mediatek_drm.h   |   59 +
 20 files changed, 4054 insertions(+)
 create mode 100644 drivers/gpu/drm/mediatek/Kconfig
 create mode 100644 drivers/gpu/drm/mediatek/Makefile
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_crtc.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_crtc.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_crtc_main.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_drv.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_drv.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_dsi.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_dsi.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_fb.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_fb.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_gem.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_gem.h
 create mode 100644 include/uapi/drm/mediatek_drm.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 47f2ce8..441be2d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -217,3 +217,5 @@ source "drivers/gpu/drm/sti/Kconfig"
 source "drivers/gpu/drm/amd/amdkfd/Kconfig"

 source "drivers/gpu/drm/imx/Kconfig"
+
+source "drivers/gpu/drm/mediatek/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7d4944e..55fe66c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_STI) += sti/
 obj-$(CONFIG_DRM_IMX) += imx/
+obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
 obj-y  += i2c/
 obj-y  += panel/
 obj-y  += bridge/
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
new file mode 100644
index 000..fa581fb
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -0,0 +1,28 @@
+config DRM_MEDIATEK
+   tristate "DRM Support for Mediatek SoCs"
+   depends on DRM
+   depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
+   select MTK_SMI
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   select DRM_PANEL_SIMPLE
+   select DRM_KMS_HELPER
+   select IOMMU_DMA
+   help
+ Choose this option if you have a Mediatek SoCs.
+ The module will be called mediatek-drm
+ This driver provides kernel mode setting and
+ buffer management to userspace.
+
+config DRM_MEDIATEK_FBDEV
+   bool "Enable legacy fbdev support for Mediatek DRM"
+   depends on DRM_MEDIATEK
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   select DRM_KMS_FB_HELPER
+   help
+ Choose this option if you have a need for the legacy
+ fbdev support.  Note that this support also provides
+ the Linux console on top of the Mediatek DRM mode
+ setting driver.
diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
new file mode 100644
index 000..a566a83
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -0,0 +1,13 @@
+mediatek-drm-objs := mediatek_drm_drv.o \
+  mediatek_drm_crtc.o \
+  mediatek_drm_fb.o \
+  mediatek_drm_gem.o \
+ 

[RFC][PATCH 1/2] dt-bindings: drm/mediatek: Add Mediatek DRM dts binding

[CK Hu]

This patch includes
1. Mediatek DRM Device binding
2. Mediatek DSI Device binding
3. Mediatek CRTC Main Device binding
4. Mediatek DDP Device binding

Signed-off-by: CK Hu 
---
 .../bindings/drm/mediatek/mediatek,crtc-main.txt   | 38 ++
 .../bindings/drm/mediatek/mediatek,ddp.txt | 22 +
 .../bindings/drm/mediatek/mediatek,drm.txt | 27 +++
 .../bindings/drm/mediatek/mediatek,dsi.txt | 20 
 4 files changed, 107 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,ddp.txt
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,drm.txt
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt

diff --git 
a/Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt 
b/Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt
new file mode 100644
index 000..5c6c420
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt
@@ -0,0 +1,38 @@
+Mediatek CRTC Main Device
+
+
+The Mediatek CRTC Main device is a crtc device of DRM system.
+
+Required properties:
+- compatible: "mediatek,-crtc-main"
+- interrupts: The interrupt signal from the CRTC Main block.
+- reg: Physical base address and length of the controller's registers
+- clocks: device clocks
+  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- ddp: phandle of ddp device which control display data path.
+
+Example:
+
+crtc_main: crtc at 1400c000 {
+   compatible = "mediatek,mt8173-crtc-main";
+   interrupts = ;
+   reg = <0 0x1400c000 0 0x1000>,  /* OVL0 */
+ <0 0x1400e000 0 0x1000>,  /* RDMA0 */
+ <0 0x14013000 0 0x1000>,  /* COLOR0 */
+ <0 0x14015000 0 0x1000>,  /* AAL */
+ <0 0x1401a000 0 0x1000>,  /* UFOE */
+ <0 0x14023000 0 0x1000>;  /* OD */
+   clocks = < MM_DISP_OVL0>,
+< MM_DISP_RDMA0>,
+< MM_DISP_COLOR0>,
+< MM_DISP_AAL>,
+< MM_DISP_UFOE>,
+< MM_DISP_OD>;
+   clock-names = "ovl0_disp",
+ "rdma0_disp",
+ "color0_disp",
+ "aal_disp",
+ "ufoe_disp",
+ "od_disp";
+   ddp = <>;
+};
\ No newline at end of file
diff --git a/Documentation/devicetree/bindings/drm/mediatek/mediatek,ddp.txt 
b/Documentation/devicetree/bindings/drm/mediatek/mediatek,ddp.txt
new file mode 100644
index 000..77cf630
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,ddp.txt
@@ -0,0 +1,22 @@
+Mediatek DDP Device
+
+
+The Mediatek DDP device control the display data path.
+
+Required properties:
+- compatible: "mediatek,-ddp"
+- reg: Physical base address and length of the controller's registers
+- power-domains: a phandle to DDP power domain node.
+- clocks: device clocks
+  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+
+Example:
+
+ddp: ddp at 1400 {
+   compatible = "mediatek,mt8173-ddp";
+   reg = <0 0x1400 0 0x100>,   /* CONFIG */
+ <0 0x1402 0 0x1000>;  /* MUTEX */
+   power-domains = < MT8173_POWER_DOMAIN_DIS>;
+   clocks = < MM_MUTEX_32K>;
+   clock-names = "mutex_disp";
+};
\ No newline at end of file
diff --git a/Documentation/devicetree/bindings/drm/mediatek/mediatek,drm.txt 
b/Documentation/devicetree/bindings/drm/mediatek/mediatek,drm.txt
new file mode 100644
index 000..c4a5702
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,drm.txt
@@ -0,0 +1,27 @@
+Mediatek DRM Device
+
+
+The Mediatek DRM device is a device needed to list all
+display component nodes that comprise the display subsystem.
+And it list the memory-related interface.
+
+Required properties:
+- compatible: "mediatek,-drm"
+- larb: Should contain a list of phandles pointing to larb device.
+  larb definitions as defined in
+  Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt
+- iommus: required a iommu node
+- connectors: Should contain a list of phandles pointing to connector device.
+  connector device should be one component of this master.
+- crtcs: Should contain a list of phandles pointing to crtc device.
+  crtc device should be one component of this master.
+
+Example:
+
+drm0: drm {
+   compatible = "mediatek,mt8173-drm";
+   larb = <>;
+   iommus = < M4U_PORT_DISP_OVL0>;
+   connectors = <>;
+   crtcs = <_main>;
+};
\ No newline at end of file
diff --git a/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt 
b/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
new file mode 100644
index 000..16e3eb3

[RFC][PATCH 0/2] MT8173 DRM support

[CK Hu]

MT8173 DRM include one master drm device and three sub device: dsi device,
crtc main device, and ddp device.

Master drm device control the drm sub device and memory management.
dsi device is a drm connector/encoder device which control MIPI/DSI hw block.
crtc main is a drm crtc device which control hw components in the display data
path.
ddp is a device which control display data path.

Display data path of crtc main is:
[OVL0] -> [COLOR0] -> [AAL] -> [OD] -> [UFOE] -> [RDMA0]

This patch depends on the other patches:
1. MT8173 IOMMU support

http://lists.infradead.org/pipermail/linux-mediatek/2015-March/58.html
2. add IOMMU dma_ops
cherry picked from git://linux-arm.org/linux-rm iommu/dma
commit d76a1911b02185bdc5f8b5525f9228cf266725c5

CK Hu (2):
  dt-bindings: drm/mediatek: Add Mediatek DRM dts binding
  drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

 .../bindings/drm/mediatek/mediatek,crtc-main.txt   |   38 +
 .../bindings/drm/mediatek/mediatek,ddp.txt |   22 +
 .../bindings/drm/mediatek/mediatek,drm.txt |   27 +
 .../bindings/drm/mediatek/mediatek,dsi.txt |   20 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/mediatek/Kconfig   |   28 +
 drivers/gpu/drm/mediatek/Makefile  |   13 +
 drivers/gpu/drm/mediatek/mediatek_drm_crtc.c   |  246 
 drivers/gpu/drm/mediatek/mediatek_drm_crtc.h   |   80 ++
 drivers/gpu/drm/mediatek/mediatek_drm_crtc_main.c  |  420 ++
 drivers/gpu/drm/mediatek/mediatek_drm_ddp.c|  202 +++
 drivers/gpu/drm/mediatek/mediatek_drm_ddp.h|   23 +
 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.c   |  346 +
 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.h   |   33 +
 drivers/gpu/drm/mediatek/mediatek_drm_drv.c|  369 ++
 drivers/gpu/drm/mediatek/mediatek_drm_drv.h|   37 +
 drivers/gpu/drm/mediatek/mediatek_drm_dsi.c| 1333 
 drivers/gpu/drm/mediatek/mediatek_drm_dsi.h|   71 ++
 drivers/gpu/drm/mediatek/mediatek_drm_fb.c |  339 +
 drivers/gpu/drm/mediatek/mediatek_drm_fb.h |   43 +
 drivers/gpu/drm/mediatek/mediatek_drm_gem.c|  315 +
 drivers/gpu/drm/mediatek/mediatek_drm_gem.h|   94 ++
 include/uapi/drm/mediatek_drm.h|   59 +
 24 files changed, 4161 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,ddp.txt
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,drm.txt
 create mode 100644 
Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
 create mode 100644 drivers/gpu/drm/mediatek/Kconfig
 create mode 100644 drivers/gpu/drm/mediatek/Makefile
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_crtc.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_crtc.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_crtc_main.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_ddp_comp.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_drv.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_drv.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_dsi.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_dsi.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_fb.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_fb.h
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_gem.c
 create mode 100644 drivers/gpu/drm/mediatek/mediatek_drm_gem.h
 create mode 100644 include/uapi/drm/mediatek_drm.h

-- 
1.8.1.1.dirty