[Bug 79081] New: radeon with dpm at low profile still more power consuming than catalyst

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

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

Bug ID: 79081
   Summary: radeon with dpm at low profile still more power
consuming than catalyst
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16-rc2
  Hardware: All
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: vova7890 at mail.ru
Regression: No

Created attachment 141181
  --> https://bugzilla.kernel.org/attachment.cgi?id=141181=edit
dmesg

I don't know why and where, but open source driver is consuming more power than
with catalyst for about 2-3 watts. For example, if switchoff display, and don't
touch notebook, wia ssh I see powertop says with catalyst use only 4.43 watts,
and with radeon it usualy closer to 7 watts. DPM is enabled, hdmi is disabled,
battery profile is activated... See dmesg output.

Notebook: HP Probook 4242s
GPU: Radeon HD 7420G
Mesa: 10.2.2
Kernel: 3.16-rc2

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

[Bug 79051] Panic with radeon hd 5750, bisected

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
See this patch set and discussion:
http://lists.freedesktop.org/archives/dri-devel/2014-June/062411.html

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

[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

Dieter N?tzel  changed:

   What|Removed |Added

 CC||Dieter at nuetzel-hh.de

--- Comment #8 from Dieter N?tzel  ---
(In reply to Alex Deucher from comment #7)
> patch and rebuild your kernel.  E.g.,
> 
> patch -p1 -i disable_lbpw.diff
> 
> in the root of your kernel tree.

If you use radeon.ko (modules) it is enough to make
'make modules' in your kernel tree (which rebuild radeon.ko only) and move
radeon.ko to the right place, then rebuild your initrd with 'mkinitrd' and
maybe it is a good idea to do 'grub2-install /dev/XXX' (or 2 times if you have
RAID1) after all.

Cheers,
  Dieter

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

[PATCH v2] drm/gk20a: add BAR instance

[Alexandre Courbot]

GK20A's BAR is functionally identical to NVC0's, but do not support
being ioremapped write-combined. Create a BAR instance for GK20A that
reflect that state.

Signed-off-by: Alexandre Courbot 
---
Changes since v1:
- Fix compilation warning due to missing cast

Patch 1 of the series was ok and thus has not been resent.

 drivers/gpu/drm/nouveau/Makefile  |  1 +
 drivers/gpu/drm/nouveau/core/engine/device/nve0.c |  2 +-
 drivers/gpu/drm/nouveau/core/include/subdev/bar.h |  1 +
 drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c   | 54 +++
 drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c|  6 +--
 drivers/gpu/drm/nouveau/core/subdev/bar/priv.h|  6 +++
 6 files changed, 66 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 8b307e143632..11d9561d67c1 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -26,6 +26,7 @@ nouveau-y += core/core/subdev.o
 nouveau-y += core/subdev/bar/base.o
 nouveau-y += core/subdev/bar/nv50.o
 nouveau-y += core/subdev/bar/nvc0.o
+nouveau-y += core/subdev/bar/gk20a.o
 nouveau-y += core/subdev/bios/base.o
 nouveau-y += core/subdev/bios/bit.o
 nouveau-y += core/subdev/bios/boost.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
index 2d1e97d4264f..a2b9ccc48f66 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
@@ -165,7 +165,7 @@ nve0_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_IBUS   ] = _ibus_oclass;
device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass;
device->oclass[NVDEV_SUBDEV_VM ] = _vmmgr_oclass;
-   device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
+   device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
device->oclass[NVDEV_ENGINE_DMAOBJ ] = _dmaeng_oclass;
device->oclass[NVDEV_ENGINE_FIFO   ] =  gk20a_fifo_oclass;
device->oclass[NVDEV_ENGINE_SW ] =  nvc0_software_oclass;
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
index 9002cbb6432b..be037fac534c 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
@@ -33,5 +33,6 @@ nouveau_bar(void *obj)

 extern struct nouveau_oclass nv50_bar_oclass;
 extern struct nouveau_oclass nvc0_bar_oclass;
+extern struct nouveau_oclass gk20a_bar_oclass;

 #endif
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c 
b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
new file mode 100644
index ..bf877af9d3bd
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+#include "priv.h"
+
+int
+gk20a_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+  struct nouveau_oclass *oclass, void *data, u32 size,
+  struct nouveau_object **pobject)
+{
+   struct nouveau_bar *bar;
+   int ret;
+
+   ret = nvc0_bar_ctor(parent, engine, oclass, data, size, pobject);
+   if (ret)
+   return ret;
+
+   bar = (struct nouveau_bar *)*pobject;
+   bar->iomap_uncached = true;
+
+   return 0;
+}
+
+struct nouveau_oclass
+gk20a_bar_oclass = {
+   .handle = NV_SUBDEV(BAR, 0xea),
+   .ofuncs = &(struct nouveau_ofuncs) {
+   .ctor = gk20a_bar_ctor,
+   .dtor = nvc0_bar_dtor,
+   .init = nvc0_bar_init,
+   .fini = _nouveau_bar_fini,
+   },
+};
diff --git 

[PATCH] drm/ttm: recognize ARM arch in ioprot handler

[Alexandre Courbot]

From: Lucas Stach 

Nouveau can now be used on ARM, so add an ioprot handler for this
architecture.

Signed-off-by: Lucas Stach 
Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1df856f78568..30e5d90cb7bc 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -500,7 +500,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
pgprot_val(tmp) |= _PAGE_GUARDED;
}
 #endif
-#if defined(__ia64__)
+#if defined(__ia64__) || defined(__arm__)
if (caching_flags & TTM_PL_FLAG_WC)
tmp = pgprot_writecombine(tmp);
else
-- 
2.0.0

[PATCH v3 2/2] drm/nouveau: use DMA TT population method on ARM

[Alexandre Courbot]

Cached memory accesses between the CPU and the GPU are not coherent on
ARM. Use the DMA TTM allocator on this architecture to obtain coherent
memory.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 70893416d4b6..d77fc8a5167d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -385,6 +385,8 @@ nouveau_ttm_init(struct nouveau_drm *drm)
if (swiotlb_nr_tbl())
drm->ttm.populate_method = DMA;
 #endif
+   if (IS_ENABLED(CONFIG_ARM))
+   drm->ttm.populate_method = DMA;
 #if defined(TTM_HAS_AGP)
if (drm->agp.stat == ENABLED)
drm->ttm.populate_method = AGP;
-- 
2.0.0

[PATCH v3 1/2] drm/nouveau: cleanup TTM population logic

[Alexandre Courbot]

TTM pages can currently be populated using 3 different methods, but the
code does not make it clear which one is used. The same complex
conditions are tested in various parts of the code, which makes it
difficult to follow and error prone.

This patch introduces an enum into the nouveau_drm struct that indicates
which population method will be used for TT-backed BOs. It is set once
and for all during TTM initialization so the same conditions need not be
tested again and again. This will also allow us to add new non-default
TTM population cases by changing a single piece of code in
nouveau_ttm_init() instead of all over nouveau_bo.c

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 63 ++-
 drivers/gpu/drm/nouveau/nouveau_drm.h | 11 ++
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 15 +
 3 files changed, 59 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4db886f9f793..82c6b479abcb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -28,7 +28,6 @@
  */

 #include 
-#include 

 #include 
 #include 
@@ -467,11 +466,11 @@ static struct ttm_tt *
 nouveau_ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size,
  uint32_t page_flags, struct page *dummy_read)
 {
-#if __OS_HAS_AGP
+#if defined(TTM_HAS_AGP)
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct drm_device *dev = drm->dev;

-   if (drm->agp.stat == ENABLED) {
+   if (drm->ttm.populate_method == AGP) {
return ttm_agp_tt_create(bdev, dev->agp->bridge, size,
 page_flags, dummy_read);
}
@@ -524,21 +523,23 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
if (nv_device(drm->device)->card_type >= NV_50)
man->func = _gart_manager;
else
-   if (drm->agp.stat != ENABLED)
+   if (drm->ttm.populate_method != AGP)
man->func = _gart_manager;
else
man->func = _bo_manager_func;

-   if (drm->agp.stat == ENABLED) {
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+
+   if (drm->ttm.populate_method != AGP)
+   man->flags |= TTM_MEMTYPE_FLAG_CMA;
+
+   if (drm->ttm.populate_method == POOL) {
+   man->available_caching = TTM_PL_MASK_CACHING;
+   man->default_caching = TTM_PL_FLAG_CACHED;
+   } else {
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
-   } else {
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE |
-TTM_MEMTYPE_FLAG_CMA;
-   man->available_caching = TTM_PL_MASK_CACHING;
-   man->default_caching = TTM_PL_FLAG_CACHED;
}

break;
@@ -1249,13 +1250,11 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *mem)
/* System memory */
return 0;
case TTM_PL_TT:
-#if __OS_HAS_AGP
-   if (drm->agp.stat == ENABLED) {
+   if (drm->ttm.populate_method == AGP) {
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = drm->agp.base;
mem->bus.is_iomem = !dev->agp->cant_use_aperture;
}
-#endif
if (nv_device(drm->device)->card_type < NV_50 || !node->memtype)
/* untiled */
break;
@@ -1359,17 +1358,20 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
device = nv_device(drm->device);
dev = drm->dev;

-#if __OS_HAS_AGP
-   if (drm->agp.stat == ENABLED) {
+   switch (drm->ttm.populate_method) {
+   case AGP:
+#if defined(TTM_HAS_AGP)
return ttm_agp_tt_populate(ttm);
-   }
+#else
+   return 0;
 #endif
+   case DMA:
+   return ttm_dma_populate(ttm_dma, dev->dev);

-#ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
-   return ttm_dma_populate((void *)ttm, dev->dev);
+   case POOL:
+   /* POOL case is handled below */
+   break;
}
-#endif

r = ttm_pool_populate(ttm);
if (r) {
@@ -1409,19 +1411,20 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
device = nv_device(drm->device);
dev = drm->dev;

-#if __OS_HAS_AGP
-   if (drm->agp.stat == ENABLED) {
+   switch (drm->ttm.populate_method) {
+   case AGP:
+#if defined(TTM_HAS_AGP)
ttm_agp_tt_unpopulate(ttm);
-  

[PATCH v3 0/2] drm: nouveau: memory coherency for ARM

[Alexandre Courbot]

v2 was doing some pretty nasty things with the DMA API, so I took a different
approach for this v3.

As suggested, this version uses ttm_dma_populate() to populate BOs. The reason
for doing this was that it would entitle us to using the DMA sync functions,
but since the memory returned is already coherent anyway, we do not even
need to call these functions anymore.

So this series has turned into 2 small patches:

- The first attempts to make it more obvious that Nouveau can use different
ways to populate TTs, and make it possible to choose which method to use from
a single place.
- The second leverages this work to select the DMA allocator to populate TTs
on ARM.

Doing this solves all our coherency problems with Nouveau on Tegra, and
hopefully makes the code easier to read in the process.

Alexandre Courbot (2):
  drm/nouveau: cleanup TTM population logic
  drm/nouveau: use DMA TT population method on ARM

 drivers/gpu/drm/nouveau/nouveau_bo.c  | 63 ++-
 drivers/gpu/drm/nouveau/nouveau_drm.h | 11 ++
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 17 ++
 3 files changed, 61 insertions(+), 30 deletions(-)

-- 
2.0.0

[PATCH 2/2] drm/gk20a: add BAR instance

[Alexandre Courbot]

GK20A's BAR is functionally identical to NVC0's, but do not support
being ioremapped write-combined. Create a BAR instance for GK20A that
reflect that state.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/Makefile  |  1 +
 drivers/gpu/drm/nouveau/core/engine/device/nve0.c |  2 +-
 drivers/gpu/drm/nouveau/core/include/subdev/bar.h |  1 +
 drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c   | 54 +++
 drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c|  6 +--
 drivers/gpu/drm/nouveau/core/subdev/bar/priv.h|  6 +++
 6 files changed, 66 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 8b307e143632..11d9561d67c1 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -26,6 +26,7 @@ nouveau-y += core/core/subdev.o
 nouveau-y += core/subdev/bar/base.o
 nouveau-y += core/subdev/bar/nv50.o
 nouveau-y += core/subdev/bar/nvc0.o
+nouveau-y += core/subdev/bar/gk20a.o
 nouveau-y += core/subdev/bios/base.o
 nouveau-y += core/subdev/bios/bit.o
 nouveau-y += core/subdev/bios/boost.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
index 2d1e97d4264f..a2b9ccc48f66 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
@@ -165,7 +165,7 @@ nve0_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_IBUS   ] = _ibus_oclass;
device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass;
device->oclass[NVDEV_SUBDEV_VM ] = _vmmgr_oclass;
-   device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
+   device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
device->oclass[NVDEV_ENGINE_DMAOBJ ] = _dmaeng_oclass;
device->oclass[NVDEV_ENGINE_FIFO   ] =  gk20a_fifo_oclass;
device->oclass[NVDEV_ENGINE_SW ] =  nvc0_software_oclass;
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
index 9002cbb6432b..be037fac534c 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
@@ -33,5 +33,6 @@ nouveau_bar(void *obj)

 extern struct nouveau_oclass nv50_bar_oclass;
 extern struct nouveau_oclass nvc0_bar_oclass;
+extern struct nouveau_oclass gk20a_bar_oclass;

 #endif
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c 
b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
new file mode 100644
index ..cc7c3db211d1
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+#include "priv.h"
+
+int
+gk20a_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+  struct nouveau_oclass *oclass, void *data, u32 size,
+  struct nouveau_object **pobject)
+{
+   struct nouveau_bar *bar;
+   int ret;
+
+   ret = nvc0_bar_ctor(parent, engine, oclass, data, size, pobject);
+   if (ret)
+   return ret;
+
+   bar = *pobject;
+   bar->iomap_uncached = true;
+
+   return 0;
+}
+
+struct nouveau_oclass
+gk20a_bar_oclass = {
+   .handle = NV_SUBDEV(BAR, 0xea),
+   .ofuncs = &(struct nouveau_ofuncs) {
+   .ctor = gk20a_bar_ctor,
+   .dtor = nvc0_bar_dtor,
+   .init = nvc0_bar_init,
+   .fini = _nouveau_bar_fini,
+   },
+};
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c 
b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
index ca8139b9ab27..0a44459844e3 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c

[PATCH 1/2] drm/nouveau/bar: add noncached ioremap property

[Alexandre Courbot]

Some BARs (like GK20A's) do not support being ioremapped write-combined.
Add a boolean property to the BAR structure and handle that case in the
Nouveau BO implementation.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/include/subdev/bar.h |  3 +++
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 17 -
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
index 9faa98e67ad8..9002cbb6432b 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
@@ -20,6 +20,9 @@ struct nouveau_bar {
u32 flags, struct nouveau_vma *);
void (*unmap)(struct nouveau_bar *, struct nouveau_vma *);
void (*flush)(struct nouveau_bar *);
+
+   /* whether the BAR supports to be ioremapped WC or should be uncached */
+   bool iomap_uncached;
 };

 static inline struct nouveau_bar *
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index b6dc85c614be..4db886f9f793 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -500,18 +500,25 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
+   man->flags = TTM_MEMTYPE_FLAG_FIXED |
+TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->available_caching = TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_WC;
+   man->default_caching = TTM_PL_FLAG_WC;
+
if (nv_device(drm->device)->card_type >= NV_50) {
+   /* Some BARs do not support being ioremapped WC */
+   if (nouveau_bar(drm->device)->iomap_uncached) {
+   man->available_caching = TTM_PL_FLAG_UNCACHED;
+   man->default_caching = TTM_PL_FLAG_UNCACHED;
+   }
+
man->func = _vram_manager;
man->io_reserve_fastpath = false;
man->use_io_reserve_lru = true;
} else {
man->func = _bo_manager_func;
}
-   man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
-   man->available_caching = TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_WC;
-   man->default_caching = TTM_PL_FLAG_WC;
break;
case TTM_PL_TT:
if (nv_device(drm->device)->card_type >= NV_50)
-- 
2.0.0

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Jingoo Han]

On Friday, June 27, 2014 7:12 PM, Ajay Kumar wrote:
> 
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be set if we are using DP.
> 
> Signed-off-by: Ajay Kumar 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  .../devicetree/bindings/video/samsung-fimd.txt |1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
> 
>  include/video/samsung_fimd.h   |4 
>  3 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> index 2dad41b..12f3d7a 100644
> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> @@ -41,6 +41,7 @@ Optional Properties:
>  - samsung,power-domain: a phandle to FIMD power domain node.
>  - samsung,invert-vden: video enable signal is inverted
>  - samsung,invert-vclk: video clock signal is inverted
> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
>  - display-timings: timing settings for FIMD, as described in document [1].
>   Can be used in case timings cannot be provided otherwise
>   or to override timings provided by the panel.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..aa74e90 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>   unsigned int has_shadowcon:1;
>   unsigned int has_clksel:1;
>   unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
>  };
> 
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .timing_base = 0x2,
>   .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
> +};
> +
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DSI,
> + EXYNOS_FIMD_OUTPUT_DP,
>  };
> 
>  struct fimd_win_data {
> @@ -125,6 +133,8 @@ struct fimd_context {
>   struct exynos_drm_panel_info panel;
>   struct fimd_driver_data *driver_data;
>   struct exynos_drm_display *display;
> +
> + enum exynos_fimd_output_type exynos_fimd_output_type;
>  };
> 
>  static const struct of_device_id fimd_driver_dt_match[] = {
> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
> 
> + if (ctx->driver_data->has_dp_clkcon &&
> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
>   writel(val, ctx->regs + VIDCON0);
>  }
> 
> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct fimd_context *ctx;
>   struct resource *res;
> + u32 fimd_output_type;
>   int ret = -EINVAL;
> 
>   ret = exynos_drm_component_add(>dev, EXYNOS_DEVICE_TYPE_CRTC,
> @@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
>   ctx->vidcon1 |= VIDCON1_INV_VDEN;
>   if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
>   ctx->vidcon1 |= VIDCON1_INV_VCLK;
> + if (!of_property_read_u32(dev->of_node, "samsung,output-type",
> + _output_type)) {
> + if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
> + (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
> + dev_err(dev, "invalid output type for FIMD\n");
> + else
> + ctx->exynos_fimd_output_type = fimd_output_type;
> + }
> 
>   ctx->bus_clk = devm_clk_get(dev, "fimd");
>   if (IS_ERR(ctx->bus_clk)) {
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
> 
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 4
> --
> 1.7.9.5

[PATCH V3 0/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Inki Dae]

+ DT mailing list


On 2014? 06? 27? 19:12, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> 
> Changes since V2:
>   Add DT property to know the type of FIMD output interface
>   as per Inki's suggestion.
>   Add samsung,output-type DT property in FIMD node for all boards
>   supporting DP interface.
> 
> Ajay Kumar (7):
>   [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
>   [PATCH V3 2/7] ARM: dts: Add FIMD output property for snow
>   [PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit
>   [PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi
>   [PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250
>   [PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420
>   [PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale
> 
>  .../devicetree/bindings/video/samsung-fimd.txt |1 +
>  arch/arm/boot/dts/exynos5250-arndale.dts   |1 +
>  arch/arm/boot/dts/exynos5250-smdk5250.dts  |1 +
>  arch/arm/boot/dts/exynos5250-snow.dts  |1 +
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |1 +
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |1 +
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
> 
>  include/video/samsung_fimd.h   |4 
>  9 files changed, 34 insertions(+)
> 

[PATCH v2 1/4] drm/tegra: Implement more tiling modes

[Alexandre Courbot]

On Fri, Jun 27, 2014 at 5:28 PM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Tegra124 supports a block-linear mode in addition to the regular pitch
> linear and tiled modes. Add support for these by moving the internal
> representation into a structure rather than a simple flag.

Tested-by: Alexandre Courbot 

For the 4 patches. The first one has a trivial conflict on drm.h when
applied on today's -next.

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Michel Dänzer]

On 27.06.2014 17:18, Christian K?nig wrote:
> Am 27.06.2014 04:58, schrieb Michel D?nzer:
>> On 26.06.2014 19:39, Christian K?nig wrote:
>>> Am 26.06.2014 11:29, schrieb Michel D?nzer:
 From: Michel D?nzer 
 
 Prevents radeon_crtc_handle_flip() from running before 
 radeon_flip_work_func(), resulting in a kernel panic due to
 the BUG_ON() in drm_vblank_put().
 
 Tested-by: Dieter N?tzel  Signed-off-by:
 Michel D?nzer 
>>> Does patch #2 alone fixes the problem as well?
>> It should avoid the panic as well.
>> 
>> 
>>> I would rather want to avoid turning the pflip interrupt on and
>>> off.
>> What's the problem with that? It's not like we're saving any
>> register writes by not doing it.
> 
> We don't? As far as I can see we reprogram all interrupt registers
> if any of the interrupts changed,

Maybe I'm missing something, but: radeon_irq_kms_pflip_irq_get/put()
call radeon_irq_set() every time, as there can only be one active page
flip per CRTC. And radeon_irq_set() always writes the same registers,
only the bits it writes to them change depending on which interrupts the
driver is currently interested in.

> this has already lead to quite some additional overhead in the fence
> waiting code.

radeon_irq_set() should probably be split up to reduce the overhead.


>> The diagnostic messages Dieter was getting with only patch #2 show
>> that the pflip interrupt often triggers unnecessarily, potentially
>> wasting power by waking up the CPU from a power saving state
>> pointlessly.
> That's a really good point, but my question would rather be why does
> the pflip interrupt fires if there isn't any pflip?

There is a page flip, but it already completes in the vertical blank
interrupt handler in a lot of (most?) cases.

Which brings me back to the question: Do we really need the pflip
interrupt yet? [0] Since flips are no longer programmed to the hardware
in the vertical blank handler but in a work queue, is there actually
still any problem with handling the flip completion in the vertical
blank interrupt handler?

FWIW, by disabling the radeon_crtc_handle_flip() call from the pflip
interrupt handler, I no longer seem to be able to reproduce the
'impossible msc' lines in the Xorg log file.

[0] Of course the pflip interrupt will be needed for asynchronous flips,
but that doesn't mean we have to use it for all flips?


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH v2] drm/gk20a: add BAR instance

[Ken Adams]

On 6/27/14 8:56 PM, "Ben Skeggs"  wrote:

>On Sat, Jun 28, 2014 at 4:51 AM, Ken Adams  wrote:
>> quick note re: tegra and gpu bars...
>>
>> to this point we've explicitly avoided providing user-mode mappings due
>>to
>> power management issues, etc.
>> looks to me like this would allow such mappings.  is that the case?  are
>> there any paths which would require such mappings to function properly?

>What power management issues are you worried about in particular?  We
>have these concerns on discrete cards too, when doing things like
>changing vram frequencies.  TTM is able to kick out all userspace
>mappings, and clients will then block in the fault handler until it's
>safe - if they touch the mappings.
>
>Ben.


hi ben,

primarily it's the access problem you mentioned.  managing those mappings,
and kicking them out at best adds to the latency to take down power/detach
busii and the like.

and, generally, there are very few (if any) cases where there isn't a
better way to manipulate the pixels than with the cpu :) i understand
there are plenty of paths i don't know about here? and so i asked.

it's a solvable problem, of course.  but especially in the mobile world it
can pop up unexpectedly.  typically on someone's perf/power/stress tests :)

---
ken





>
>>
>> thanks
>> ---
>> ken
>>
>> p.s.: hello :)
>>
>> On 6/27/14 7:36 AM, "Alex Courbot"  wrote:
>>
>>>GK20A's BAR is functionally identical to NVC0's, but do not support
>>>being ioremapped write-combined. Create a BAR instance for GK20A that
>>>reflect that state.
>>>
>>>Signed-off-by: Alexandre Courbot 
>>>---
>>>Changes since v1:
>>>- Fix compilation warning due to missing cast
>>>
>>>Patch 1 of the series was ok and thus has not been resent.
>>>
>>> drivers/gpu/drm/nouveau/Makefile  |  1 +
>>> drivers/gpu/drm/nouveau/core/engine/device/nve0.c |  2 +-
>>> drivers/gpu/drm/nouveau/core/include/subdev/bar.h |  1 +
>>> drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c   | 54
>>>+++
>>> drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c|  6 +--
>>> drivers/gpu/drm/nouveau/core/subdev/bar/priv.h|  6 +++
>>> 6 files changed, 66 insertions(+), 4 deletions(-)
>>> create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>>>
>>>diff --git a/drivers/gpu/drm/nouveau/Makefile
>>>b/drivers/gpu/drm/nouveau/Makefile
>>>index 8b307e143632..11d9561d67c1 100644
>>>--- a/drivers/gpu/drm/nouveau/Makefile
>>>+++ b/drivers/gpu/drm/nouveau/Makefile
>>>@@ -26,6 +26,7 @@ nouveau-y += core/core/subdev.o
>>> nouveau-y += core/subdev/bar/base.o
>>> nouveau-y += core/subdev/bar/nv50.o
>>> nouveau-y += core/subdev/bar/nvc0.o
>>>+nouveau-y += core/subdev/bar/gk20a.o
>>> nouveau-y += core/subdev/bios/base.o
>>> nouveau-y += core/subdev/bios/bit.o
>>> nouveau-y += core/subdev/bios/boost.o
>>>diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>>>b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>>>index 2d1e97d4264f..a2b9ccc48f66 100644
>>>--- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>>>+++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>>>@@ -165,7 +165,7 @@ nve0_identify(struct nouveau_device *device)
>>>   device->oclass[NVDEV_SUBDEV_IBUS   ] =
>>>_ibus_oclass;
>>>   device->oclass[NVDEV_SUBDEV_INSTMEM] =
>>>nv50_instmem_oclass;
>>>   device->oclass[NVDEV_SUBDEV_VM ] =
>>>_vmmgr_oclass;
>>>-  device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
>>>+  device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
>>>   device->oclass[NVDEV_ENGINE_DMAOBJ ] =
>>>_dmaeng_oclass;
>>>   device->oclass[NVDEV_ENGINE_FIFO   ] =
>>>gk20a_fifo_oclass;
>>>   device->oclass[NVDEV_ENGINE_SW ] =
>>>nvc0_software_oclass;
>>>diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>>>b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>>>index 9002cbb6432b..be037fac534c 100644
>>>--- a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>>>+++ b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>>>@@ -33,5 +33,6 @@ nouveau_bar(void *obj)
>>>
>>> extern struct nouveau_oclass nv50_bar_oclass;
>>> extern struct nouveau_oclass nvc0_bar_oclass;
>>>+extern struct nouveau_oclass gk20a_bar_oclass;
>>>
>>> #endif
>>>diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>>>b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>>>new file mode 100644
>>>index ..bf877af9d3bd
>>>--- /dev/null
>>>+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>>>@@ -0,0 +1,54 @@
>>>+/*
>>>+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
>>>+ *
>>>+ * Permission is hereby granted, free of charge, to any person
>>>obtaining
>>>a
>>>+ * copy of this software and associated documentation files (the
>>>"Software"),
>>>+ * to deal in the Software without restriction, including without
>>>limitation
>>>+ * the rights to use, copy, modify, merge, publish, distribute,
>>>sublicense,
>>>+ * and/or sell copies of the Software, 

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay kumar]

Hi Andrej,

On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda  wrote:
> On 06/27/2014 01:48 PM, Ajay kumar wrote:
>> Hi Andrej,
>>
>> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda  
>> wrote:
>>> Hi Ajay,
>>>
>>> +CC DT
>>>
>>> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
 Add the missing setting for DP CLKCON register.

 This register is present on Exynos5 based FIMD controllers,
 and needs to be set if we are using DP.

 Signed-off-by: Ajay Kumar 
 ---
  .../devicetree/bindings/video/samsung-fimd.txt |1 +
  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
 
  include/video/samsung_fimd.h   |4 
  3 files changed, 28 insertions(+)

 diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
 b/Documentation/devicetree/bindings/video/samsung-fimd.txt
 index 2dad41b..12f3d7a 100644
 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
 +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
 @@ -41,6 +41,7 @@ Optional Properties:
  - samsung,power-domain: a phandle to FIMD power domain node.
  - samsung,invert-vden: video enable signal is inverted
  - samsung,invert-vclk: video clock signal is inverted
 +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, 
 DP=2)
>>> There is no point in introducing this property. Exynos DRM have already
>>> logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
>>> reused to determine display type. It can be done even without any
>>> additional callbacks, just by checking if there is connector of
>>> DRM_MODE_CONNECTOR_eDP type connected to fimd.
>> The mapping between crtc(struct exynos_drm_manager) and encoder(struct
>> exynos_drm_display)
>> in exynos drm happens by matching the exynos_drm_output_type variable in each
>> structure.
>> exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
>> FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
>> and both DP and MIPI statically choose the same enum EXYNOS_DISPLAY_TYPE_LCD,
>> as output type.
>> So, we cannot use that logic to differentiate between DP/MIPI DSI.
>>
>> Also, checking based on connector type doesn't hold good.
>> The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
>> DP->LVDS or MIPI->LVDS panels!
>
> True, I forgot about bridges. So additional callback/field is necessary.
> See below.
>
>>
>> Thanks and regards,
>> Ajay Kumar
>>
>>> Regards
>>> Andrzej
>>>
  - display-timings: timing settings for FIMD, as described in document [1].
   Can be used in case timings cannot be provided otherwise
   or to override timings provided by the panel.
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 33161ad..aa74e90 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -72,6 +72,7 @@ struct fimd_driver_data {
   unsigned int has_shadowcon:1;
   unsigned int has_clksel:1;
   unsigned int has_limited_fmt:1;
 + unsigned int has_dp_clkcon:1;
  };

  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
 @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data 
 = {
  static struct fimd_driver_data exynos5_fimd_driver_data = {
   .timing_base = 0x2,
   .has_shadowcon = 1,
 + .has_dp_clkcon = 1,
 +};
 +
 +enum exynos_fimd_output_type {
 + EXYNOS_FIMD_OUTPUT_DPI,
 + EXYNOS_FIMD_OUTPUT_DSI,
 + EXYNOS_FIMD_OUTPUT_DP,
  };

  struct fimd_win_data {
 @@ -125,6 +133,8 @@ struct fimd_context {
   struct exynos_drm_panel_info panel;
   struct fimd_driver_data *driver_data;
   struct exynos_drm_display *display;
 +
 + enum exynos_fimd_output_type exynos_fimd_output_type;
  };

  static const struct of_device_id fimd_driver_dt_match[] = {
 @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager 
 *mgr)
   if (clkdiv > 1)
   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;

 + if (ctx->driver_data->has_dp_clkcon &&
 + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
 + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
 +
   writel(val, ctx->regs + VIDCON0);
>
> New code should not split VIDCON0 related code.It should be moved few
> lines above or few lines below.
Ok, for better readability.

> Anyway this code should be rather placed in power related functions of
> dp encoder, as it enables dp. The only question
> is if DP_CLKCON update can be performed after VIDCON0 update. If yes the
> solution of the whole problem
I will check this.

> seems to be simple:
> - fimd should provide function fimd_set_dp_clk_gate 

[Bug 79071] Hang with dpm radeon hd 5750, pcie 1.1 motherboard

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

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

--- Comment #2 from Jonathan Howard  ---
Both high and auto appear to be same.
Lack of other reports for the card, with me running on pcie v1 motherboard
(card supports v2) give a hint (but not certain) probable cause.

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

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #18 from Sylvain BERTRAND  ---
Ok... I did a bit of gdb.

It's a bloody mess, many things are optimized out and breakpoints are not
working consistently.

I got the DRI2CanFlip function to return FALSE for those lines:
dri2.c:934 and dri2.c:945

That said, I was unlucky about can_flip debugging, since I hit only the TRUE
returning code paths of DRI2CanFlip.

-- 
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/20140627/d6138cf2/attachment.html>

[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

--- Comment #7 from Alex Deucher  ---
patch and rebuild your kernel.  E.g.,

patch -p1 -i disable_lbpw.diff

in the root of your kernel tree.

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

[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

--- Comment #6 from Fabian Pas  ---
Do I simply add that to the file?

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

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Michel Dänzer]

On 27.06.2014 17:26, Christian K?nig wrote:
> Am 27.06.2014 04:31, schrieb Michel D?nzer:
>> On 25.06.2014 12:59, Michel D?nzer wrote:
>>> 
>>> With these patches, 3.15 just survived two piglit runs on my Bonaire,
>>> one with the GART poisoning fix and one without. It never survived a
>>> single run before.
>>>
>>> Acked-and-Tested-by: Michel D?nzer 
>> So, are these patches going to 3.16 and 3.15?
> 
> We could send them in for 3.15,

What's the alternative for 3.15?

Looks like e.g. https://bugs.freedesktop.org/show_bug.cgi?id=80141 is
confirmed to be this.


> but for 3.16 we have some new features that depend on the new code.
> 
> We could backport them to the old code, but I really want to work on
> figuring out what's wrong with the new approach instead.
> 
> Going to prepare a branch for you to test over the weekend, would be
> nice if you could give it a try on Monday and see if that fixes the
> issues as well.

Sure, will do.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #5 from Alex Deucher  ---
Created attachment 141171
  --> https://bugzilla.kernel.org/attachment.cgi?id=141171=edit
possible fix

Does this patch help?

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

[PATCH v3 4/4] drm/tegra: Implement race-free hotplug detection

[Thierry Reding]

From: Thierry Reding 

A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happens
because on some boards the HDMI driver can control the regulator that
supplies the +5V pin on the HDMI connector. Therefore depending on the
timing between the initialization of the HDMI driver and the rest of
DRM, it's possible that the monitor returns the hotplug signal right
within the window where we would miss it.

Unfortunately, drm_kms_helper_poll_init() will wreak havoc when called
before at least some parts of the FB helpers have been set up.

This commit fixes this by splitting out the minimum of initialization
required to make drm_kms_helper_poll_init() work into a separate
function that can be called early. It is then safe to move all of the
poll helper initialization to an earlier point in time (before the
HDMI output driver has a chance to enable the +5V supply). That way if
the hotplug signal is returned before the initial FB helper setup, the
monitor will be forcefully detected at that point, and if the hotplug
signal is returned after that it will be properly handled by the poll
helpers.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c |  8 ++--
 drivers/gpu/drm/tegra/drm.h |  1 +
 drivers/gpu/drm/tegra/fb.c  | 47 ++---
 3 files changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 3396f9f6a9f7..fd736efd14bd 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -40,6 +40,12 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)

drm_mode_config_init(drm);

+   err = tegra_drm_fb_prepare(drm);
+   if (err < 0)
+   return err;
+
+   drm_kms_helper_poll_init(drm);
+
err = host1x_device_init(device);
if (err < 0)
return err;
@@ -59,8 +65,6 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)
if (err < 0)
return err;

-   drm_kms_helper_poll_init(drm);
-
return 0;
 }

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6b8fe9d86ed4..0d30689dff01 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -280,6 +280,7 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer 
*framebuffer,
unsigned int index);
 bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer);
 bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer);
+int tegra_drm_fb_prepare(struct drm_device *drm);
 int tegra_drm_fb_init(struct drm_device *drm);
 void tegra_drm_fb_exit(struct drm_device *drm);
 #ifdef CONFIG_DRM_TEGRA_FBDEV
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index d5d53aa79ced..fc1528e0bda1 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -271,13 +271,9 @@ static const struct drm_fb_helper_funcs 
tegra_fb_helper_funcs = {
.fb_probe = tegra_fbdev_probe,
 };

-static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm,
- unsigned int preferred_bpp,
- unsigned int num_crtc,
- unsigned int max_connectors)
+static struct tegra_fbdev *tegra_fbdev_create(struct drm_device *drm)
 {
struct tegra_fbdev *fbdev;
-   int err;

fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev) {
@@ -287,10 +283,21 @@ static struct tegra_fbdev *tegra_fbdev_create(struct 
drm_device *drm,

drm_fb_helper_prepare(drm, >base, _fb_helper_funcs);

+   return fbdev;
+}
+
+static int tegra_fbdev_init(struct tegra_fbdev *fbdev,
+   unsigned int preferred_bpp,
+   unsigned int num_crtc,
+   unsigned int max_connectors)
+{
+   struct drm_device *drm = fbdev->base.dev;
+   int err;
+
err = drm_fb_helper_init(drm, >base, num_crtc, max_connectors);
if (err < 0) {
dev_err(drm->dev, "failed to initialize DRM FB helper\n");
-   goto free;
+   return err;
}

err = drm_fb_helper_single_add_all_connectors(>base);
@@ -299,21 +306,17 @@ static struct tegra_fbdev *tegra_fbdev_create(struct 
drm_device *drm,
goto fini;
}

-   drm_helper_disable_unused_functions(drm);
-
err = drm_fb_helper_initial_config(>base, preferred_bpp);
if (err < 0) {
dev_err(drm->dev, "failed to set initial configuration\n");
goto fini;
}

-   return fbdev;
+   return 0;

 fini:

[PATCH v3 3/4] drm: Introduce drm_fb_helper_prepare()

[Thierry Reding]

From: Thierry Reding 

To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.

At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.

Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
Changes in v3:
- fix inconsistency "second" -> "third" (Daniel Vetter)

Changes in v2:
- improve kernel-doc (Daniel Vetter)

 drivers/gpu/drm/armada/armada_fbdev.c |  2 +-
 drivers/gpu/drm/ast/ast_fb.c  |  4 ++-
 drivers/gpu/drm/bochs/bochs_fbdev.c   |  3 +-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c |  4 ++-
 drivers/gpu/drm/drm_fb_cma_helper.c   |  3 +-
 drivers/gpu/drm/drm_fb_helper.c   | 47 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 +-
 drivers/gpu/drm/gma500/framebuffer.c  |  3 +-
 drivers/gpu/drm/i915/intel_fbdev.c|  3 +-
 drivers/gpu/drm/mgag200/mgag200_fb.c  |  3 +-
 drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  3 +-
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  2 +-
 drivers/gpu/drm/qxl/qxl_fb.c  |  5 +++-
 drivers/gpu/drm/radeon/radeon_fb.c|  4 ++-
 drivers/gpu/drm/tegra/fb.c|  4 +--
 drivers/gpu/drm/udl/udl_fb.c  |  3 +-
 include/drm/drm_fb_helper.h   |  2 ++
 18 files changed, 72 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index a7c947cd9386..7838e731b0de 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -149,7 +149,7 @@ int armada_fbdev_init(struct drm_device *dev)

priv->fbdev = fbh;

-   fbh->funcs = _fb_helper_funcs;
+   drm_fb_helper_prepare(dev, fbh, _fb_helper_funcs);

ret = drm_fb_helper_init(dev, fbh, 1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 2113894e4ff8..cba45c774552 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -328,8 +328,10 @@ int ast_fbdev_init(struct drm_device *dev)
return -ENOMEM;

ast->fbdev = afbdev;
-   afbdev->helper.funcs = _fb_helper_funcs;
spin_lock_init(>dirty_lock);
+
+   drm_fb_helper_prepare(dev, >helper, _fb_helper_funcs);
+
ret = drm_fb_helper_init(dev, >helper,
 1, 1);
if (ret) {
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 17e5c17f2730..19cf3e9413b6 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -189,7 +189,8 @@ int bochs_fbdev_init(struct bochs_device *bochs)
 {
int ret;

-   bochs->fb.helper.funcs = _fb_helper_funcs;
+   drm_fb_helper_prepare(bochs->dev, >fb.helper,
+ _fb_helper_funcs);

ret = drm_fb_helper_init(bochs->dev, >fb.helper,
 1, 1);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 2bd0291168e4..2a135f253e29 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -306,9 +306,11 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
return -ENOMEM;

cdev->mode_info.gfbdev = gfbdev;
-   gfbdev->helper.funcs = _fb_helper_funcs;
spin_lock_init(>dirty_lock);

+   drm_fb_helper_prepare(cdev->dev, >helper,
+ _fb_helper_funcs);
+
ret = drm_fb_helper_init(cdev->dev, >helper,
 cdev->num_crtc, CIRRUSFB_CONN_LIMIT);
if (ret) {
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index cb01e1606384..cc0ae047ed3b 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -354,9 +354,10 @@ struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device 
*dev,
return ERR_PTR(-ENOMEM);
}

-   fbdev_cma->fb_helper.funcs = _fb_cma_helper_funcs;
helper = _cma->fb_helper;

+   drm_fb_helper_prepare(dev, helper, _fb_cma_helper_funcs);
+
ret = drm_fb_helper_init(dev, helper, num_crtc, max_conn_count);
if (ret < 0) {
dev_err(dev->dev, "Failed to initialize drm fb 

[PATCH v3 2/4] drm: Constify struct drm_fb_helper_funcs

[Thierry Reding]

From: Thierry Reding 

There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
 drivers/gpu/drm/ast/ast_fb.c  | 2 +-
 drivers/gpu/drm/bochs/bochs_fbdev.c   | 2 +-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
 drivers/gpu/drm/drm_fb_cma_helper.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
 drivers/gpu/drm/gma500/framebuffer.c  | 2 +-
 drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
 drivers/gpu/drm/mgag200/mgag200_fb.c  | 2 +-
 drivers/gpu/drm/msm/msm_fbdev.c   | 2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 2 +-
 drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 +-
 drivers/gpu/drm/qxl/qxl_fb.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
 drivers/gpu/drm/tegra/fb.c| 2 +-
 drivers/gpu/drm/udl/udl_fb.c  | 2 +-
 include/drm/drm_fb_helper.h   | 2 +-
 17 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index fd166f532ab9..a7c947cd9386 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -131,7 +131,7 @@ static int armada_fb_probe(struct drm_fb_helper *fbh,
return ret;
 }

-static struct drm_fb_helper_funcs armada_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs armada_fb_helper_funcs = {
.gamma_set  = armada_drm_crtc_gamma_set,
.gamma_get  = armada_drm_crtc_gamma_get,
.fb_probe   = armada_fb_probe,
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index a28640f47c27..2113894e4ff8 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -287,7 +287,7 @@ static void ast_fb_gamma_get(struct drm_crtc *crtc, u16 
*red, u16 *green,
*blue = ast_crtc->lut_b[regno] << 8;
 }

-static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs ast_fb_helper_funcs = {
.gamma_set = ast_fb_gamma_set,
.gamma_get = ast_fb_gamma_get,
.fb_probe = astfb_create,
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 561b84474122..17e5c17f2730 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -179,7 +179,7 @@ void bochs_fb_gamma_get(struct drm_crtc *crtc, u16 *red, 
u16 *green,
*blue  = regno;
 }

-static struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
.gamma_set = bochs_fb_gamma_set,
.gamma_get = bochs_fb_gamma_get,
.fb_probe = bochsfb_create,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 32bbba0a787b..2bd0291168e4 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -288,7 +288,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
return 0;
 }

-static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
.gamma_set = cirrus_crtc_fb_gamma_set,
.gamma_get = cirrus_crtc_fb_gamma_get,
.fb_probe = cirrusfb_create,
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index f27c883be391..cb01e1606384 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -327,7 +327,7 @@ err_drm_gem_cma_free_object:
return ret;
 }

-static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
+static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
 };

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index d771b467cf0c..fc25fe75aa77 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -225,7 +225,7 @@ out:
return ret;
 }

-static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
 };

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index e7fcc148f333..76e4d777d01d 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -561,7 +561,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
return psbfb_create(psb_fbdev, sizes);
 }

-static struct drm_fb_helper_funcs psb_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs psb_fb_helper_funcs = {
.gamma_set = psbfb_gamma_set,
.gamma_get = psbfb_gamma_get,
.fb_probe = psbfb_probe,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 

[PATCH v3 1/4] drm/fb-helper: Fix hpd vs. initial config races

[Thierry Reding]

From: Daniel Vetter 

Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.

This race is especially noticable on embedded platforms where the
driver itself enables the voltage for the hdmi output, since only then
will monitors (after a bit of delay, as usual) respond by asserting
the hpd pin.

Most of the infrastructure is already there with the split-out
drm_fb_helper_init. And drm_fb_helper_initial_config already has all
the required locking to handle concurrent hpd events since

commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
Author: Daniel Vetter 
Date:   Thu Mar 20 14:26:35 2014 +0100

drm/fb-helper: improve drm_fb_helper_initial_config locking

The only missing bit is making drm_fb_helper_hotplug_event save
against concurrent calls of drm_fb_helper_initial_config. The only
unprotected bit is the check for fb_helper->fb.

With that drivers can first initialize the fb helper, then enabel
hotplug processing and then set up the initial config all in a
completely race-free manner. Update kerneldoc and convert i915 as a
proof of concept.

Feature requested by Thierry since his tegra driver atm reliably boots
slowly enough to misses the hotplug event for an external hdmi screen,
but also reliably boots to quickly for the hpd pin to be asserted when
the fb helper calls into the hdmi ->detect function.

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
Changes in v3:
- remove an additional occurrence of i915's enable_hotplug_processing
  that was introduced after the original patch

 drivers/gpu/drm/drm_fb_helper.c | 11 +--
 drivers/gpu/drm/i915/i915_dma.c |  3 ---
 drivers/gpu/drm/i915/i915_drv.c |  2 --
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_irq.c |  4 
 5 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d5d8cea1a679..13a098c9af31 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1613,8 +1613,10 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
  * either the output polling work or a work item launched from the driver's
  * hotplug interrupt).
  *
- * Note that the driver must ensure that this is only called _after_ the fb has
- * been fully set up, i.e. after the call to drm_fb_helper_initial_config.
+ * Note that drivers may call this even before calling
+ * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This allows
+ * for a race-free fbcon setup and will make sure that the fbdev emulation will
+ * not miss any hotplug events.
  *
  * RETURNS:
  * 0 on success and a non-zero error code otherwise.
@@ -1624,11 +1626,8 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
struct drm_device *dev = fb_helper->dev;
u32 max_width, max_height;

-   if (!fb_helper->fb)
-   return 0;
-
mutex_lock(_helper->dev->mode_config.mutex);
-   if (!drm_fb_helper_is_bound(fb_helper)) {
+   if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
mutex_unlock(_helper->dev->mode_config.mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e583a1838f8..84b55665bd87 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1377,9 +1377,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
 */
intel_fbdev_initial_config(dev);

-   /* Only enable hotplug handling once the fbdev is fully set up. */
-   dev_priv->enable_hotplug_processing = true;
-
drm_kms_helper_poll_init(dev);

return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6eb45ac7a7d5..b0955fffca98 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,7 +521,6 @@ static int i915_drm_freeze(struct drm_device *dev)
}

intel_runtime_pm_disable_interrupts(dev);
-   dev_priv->enable_hotplug_processing = false;

intel_suspend_gt_powersave(dev);

@@ -659,7 +658,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)
 * notifications.
 * */
intel_hpd_init(dev);
-   dev_priv->enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cea59649ef2..df6a98cd702f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1404,7 +1404,6 @@ struct drm_i915_private {
u32 

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay kumar]

Hi Andrej,

On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda  wrote:
> Hi Ajay,
>
> +CC DT
>
> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
>> Add the missing setting for DP CLKCON register.
>>
>> This register is present on Exynos5 based FIMD controllers,
>> and needs to be set if we are using DP.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/video/samsung-fimd.txt |1 +
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
>> 
>>  include/video/samsung_fimd.h   |4 
>>  3 files changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
>> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>> index 2dad41b..12f3d7a 100644
>> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
>> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>> @@ -41,6 +41,7 @@ Optional Properties:
>>  - samsung,power-domain: a phandle to FIMD power domain node.
>>  - samsung,invert-vden: video enable signal is inverted
>>  - samsung,invert-vclk: video clock signal is inverted
>> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
>
> There is no point in introducing this property. Exynos DRM have already
> logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
> reused to determine display type. It can be done even without any
> additional callbacks, just by checking if there is connector of
> DRM_MODE_CONNECTOR_eDP type connected to fimd.
The mapping between crtc(struct exynos_drm_manager) and encoder(struct
exynos_drm_display)
in exynos drm happens by matching the exynos_drm_output_type variable in each
structure.
exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
and both DP and MIPI statically choose the same enum EXYNOS_DISPLAY_TYPE_LCD,
as output type.
So, we cannot use that logic to differentiate between DP/MIPI DSI.

Also, checking based on connector type doesn't hold good.
The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
DP->LVDS or MIPI->LVDS panels!

Thanks and regards,
Ajay Kumar

>
> Regards
> Andrzej
>
>>  - display-timings: timing settings for FIMD, as described in document [1].
>>   Can be used in case timings cannot be provided otherwise
>>   or to override timings provided by the panel.
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 33161ad..aa74e90 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>>   unsigned int has_shadowcon:1;
>>   unsigned int has_clksel:1;
>>   unsigned int has_limited_fmt:1;
>> + unsigned int has_dp_clkcon:1;
>>  };
>>
>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data = 
>> {
>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>>   .timing_base = 0x2,
>>   .has_shadowcon = 1,
>> + .has_dp_clkcon = 1,
>> +};
>> +
>> +enum exynos_fimd_output_type {
>> + EXYNOS_FIMD_OUTPUT_DPI,
>> + EXYNOS_FIMD_OUTPUT_DSI,
>> + EXYNOS_FIMD_OUTPUT_DP,
>>  };
>>
>>  struct fimd_win_data {
>> @@ -125,6 +133,8 @@ struct fimd_context {
>>   struct exynos_drm_panel_info panel;
>>   struct fimd_driver_data *driver_data;
>>   struct exynos_drm_display *display;
>> +
>> + enum exynos_fimd_output_type exynos_fimd_output_type;
>>  };
>>
>>  static const struct of_device_id fimd_driver_dt_match[] = {
>> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>   if (clkdiv > 1)
>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>
>> + if (ctx->driver_data->has_dp_clkcon &&
>> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>> +
>>   writel(val, ctx->regs + VIDCON0);
>>  }
>>
>> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
>>   struct device *dev = >dev;
>>   struct fimd_context *ctx;
>>   struct resource *res;
>> + u32 fimd_output_type;
>>   int ret = -EINVAL;
>>
>>   ret = exynos_drm_component_add(>dev, EXYNOS_DEVICE_TYPE_CRTC,
>> @@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
>>   ctx->vidcon1 |= VIDCON1_INV_VDEN;
>>   if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
>>   ctx->vidcon1 |= VIDCON1_INV_VCLK;
>> + if (!of_property_read_u32(dev->of_node, "samsung,output-type",
>> + _output_type)) {
>> + if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
>> + (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
>> + dev_err(dev, "invalid output type for FIMD\n");
>> +   

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

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

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

--- Comment #11 from fredrik at obra.se ---
(In reply to comment #10)
> I applied the latest patch on a vanilla source-tree and i still get no
> signal.

Correction - I get a "resolution out of range" with the latest 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/20140627/7e8a780b/attachment.html>

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

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

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

--- Comment #10 from fredrik at obra.se ---
I applied the latest patch on a vanilla source-tree and i still get no signal.

-- 
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/20140627/9044ac20/attachment-0001.html>

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

[Darren Etheridge]

Guido,

On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> The tilcdc driver could be compiled as a module, but was severely broken
> and could not be used as such. This patchset attempts to fix the issues
> preventing a proper load/unload of the module.
>
> Issues included dangling sysfs nodes, dangling devices, memory leaks and
> a double kfree.
>
> It now seems to be working ok. We have tested this by loading and
> unloading the driver repeteadly, with both panel and slave connectors
> and found no flaws.
>
> There is still one warning left on tilcdc_crtc_destroy, caused by
> destroying the connector while still in an ON status. We don't know why
> this happens or why it's an issue, so we did not fix it.
>

Yes I see what you mean, it triggers the WARN_ON in tilcdc_crtc_destroy 
because DRM_MODE_DPMS_ON is still set.  This WARN_ON does make some 
sense because DPMS_OFF would have the effect of turning off clocks and 
putting the monitor to sleep which seems logical considering we have 
torn down the display.  Adding a tilcdc_crtc_dpms(DPMS_OFF) right before 
the WARN_ON confirms this, but it seems strange that this hasn't 
happened automatically (+ Russell doesn't need to do it in his Armada 
driver) - so I suspect there is a better way.

Otherwise I think this is a good and useful patch series.

Darren

> The first 7 patches are bug fixes which and should probably be applied
> in the stable trees. The last two are clean-ups.
>
>
> Resending this since I got no replies.
>
>
> Guido Mart?nez (9):
>drm/i2c: tda998x: move drm_i2c_encoder_destroy call
>drm/tilcdc: panel: fix dangling sysfs connector node
>drm/tilcdc: slave: fix dangling sysfs connector node
>drm/tilcdc: tfp410: fix dangling sysfs connector node
>drm/tilcdc: panel: fix leak when unloading the module
>drm/tilcdc: fix release order on exit
>drm/tilcdc: fix double kfree
>drm/tilcdc: remove submodule destroy calls
>drm/tilcdc: replace late_initcall with module_init
>
>   drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
>   drivers/gpu/drm/tilcdc/Module.symvers  |  0
>   drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +
>   drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
>   drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 39 
> +-
>   drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 27 +--
>   drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++---
>   7 files changed, 59 insertions(+), 60 deletions(-)
>   create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers
>

[PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git

[Alex Deucher]

On Fri, Jun 27, 2014 at 11:32 AM, Ed Tomlinson  wrote:
> Hi
>
>
>
> It seems the follow on message with the panic's as an attachment did not
> make it.
>
> Here is a link with the jpg:
>

Preliminary fixes and discussion here:
http://lists.freedesktop.org/archives/dri-devel/2014-June/062411.html

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

Alex

>
>
> https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986=108244876431105742323
>
>
>
> Thanks
>
> Ed
>
>
>
> On Friday 27 June 2014 09:17:08 Ed Tomlinson wrote:
>
>> Hi
>
>>
>
>> Got the following panic runing 16-rc2 + git. The latest commit was:
>
>>
>
>> commit d91d66e88ea95b6dd21958834414009614385153
>
>> Merge: 07f4695 6663a4f
>
>> Author: Linus Torvalds 
>
>> Date: Wed Jun 25 05:44:17 2014 -0700
>
>>
>
>> I was not doing anything interesting (displaying a photo from facebook
>> with firefox)
>
>> when this happened. The distribution is arch at is up to date as of june
>> 26th.
>
>>
>
>> Thanks
>
>> Ed Tomlinson
>
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 79071] Hang with dpm radeon hd 5750, pcie 1.1 motherboard

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Does it only hang when forced to high or does that just make it happen sooner? 
Do you get hangs when it's set to auto?  What makes you think it's the
motherboard?

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

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

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

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

--- Comment #9 from fredrik at obra.se ---
Created attachment 101887
  --> https://bugs.freedesktop.org/attachment.cgi?id=101887=edit
vbios.rom

-- 
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/20140627/91ca570c/attachment.html>

[Bug 79071] New: Hang with dpm radeon hd 5750, pcie 1.1 motherboard

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

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

Bug ID: 79071
   Summary: Hang with dpm radeon hd 5750, pcie 1.1 motherboard
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16-rc2 (all dpm kernels)
  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: jonathan at unbiased.name
Regression: No

Created attachment 141161
  --> https://bugzilla.kernel.org/attachment.cgi?id=141161=edit
dmesg

New bug report but problem been around since start of dpm code. Only now tried
out few more tests. I think (without certainty) underlying cause is the old
motherboard. (Have no other system to swap to.)

System runs stable until running games. Found cogs a good test case as it
usually hangs quickly on the menu. 

/sys/class/drm/card0/device/power_dpm_force_performance_level
No problems when low.
Set to high (ie not dynamic) still hangs in games.

Tried (modified for cypress_dpm.c)
https://bugs.freedesktop.org/attachment.cgi?id=86424
no fix.

Setting
eg_pi->vddci_control = false;
Working so far.


Any refined patch to test much appreciated.

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

[PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale

[Ajay kumar]

+DT mailing list

On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar  wrote:
> Set FIMD output type for arndale as DP.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index d0de1f5..e803183 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -540,6 +540,7 @@
>
> fimd: fimd at 1440 {
> status = "okay";
> +   samsung,output-type = <2>;
> display-timings {
> native-mode = <>;
> timing0: timing at 0 {
> --
> 1.7.9.5
>

[PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250

[Ajay kumar]

+DT mailing list

On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar  wrote:
> Set FIMD output type for smdk5250 as DP.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/boot/dts/exynos5250-smdk5250.dts |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index a794a70..ed28efb 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -382,6 +382,7 @@
>
> fimd at 1440 {
> status = "okay";
> +   samsung,output-type = <2>;
> display-timings {
> native-mode = <>;
> timing0: timing at 0 {
> --
> 1.7.9.5
>

[PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420

[Ajay kumar]

+DT mailing list

On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar  wrote:
> Set FIMD output type for smdk5420 as DP.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/boot/dts/exynos5420-smdk5420.dts |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 6052aa9..5f05a19 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -120,6 +120,7 @@
>
> fimd at 1440 {
> status = "okay";
> +   samsung,output-type = <2>;
> display-timings {
> native-mode = <>;
> timing0: timing at 0 {
> --
> 1.7.9.5
>

[PATCH V3 2/7] ARM: dts: Add FIMD output property for snow

[Ajay kumar]

+DT mailing list

On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar  wrote:
> Set FIMD output type for snow as DP.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/boot/dts/exynos5250-snow.dts |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 079fdf9..dc3ae9c 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -400,6 +400,7 @@
> fimd at 1440 {
> status = "okay";
> samsung,invert-vclk;
> +   samsung,output-type = <2>;
> };
>
> dp-controller at 145B {
> --
> 1.7.9.5
>

[PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi

[Ajay kumar]

+DT mailing list

On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar  wrote:
> Set FIMD output type for peach_pi as DP.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index f3af207..21e2de2 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -205,6 +205,7 @@
>   {
> status = "okay";
> samsung,invert-vclk;
> +   samsung,output-type = <2>;
>  };
>
>  _9 {
> --
> 1.7.9.5
>

[PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit

[Ajay kumar]

+DT mailing list

On Fri, Jun 27, 2014 at 3:42 PM, Ajay Kumar  wrote:
> Set FIMD output type for peach_pit as DP.
>
> Signed-off-by: Ajay Kumar 
> ---
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 1c5b8f9..164f523 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -255,6 +255,7 @@
>   {
> status = "okay";
> samsung,invert-vclk;
> +   samsung,output-type = <2>;
>  };
>
>   {
> --
> 1.7.9.5
>

[PATCH 3/3] tests/exynos: fix typos and change wording

[Tobias Jakobi]

No functional changes.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_fimg2d.c| 8 
 tests/exynos/exynos_fimg2d_test.c | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 435a88d..61b4f94 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -144,13 +144,13 @@ static void g2d_reset(struct g2d_context *ctx)
 }

 /*
- * g2d_flush - summit all commands and values in user side command buffer
+ * g2d_flush - submit all commands and values in user side command buffer
  * to command queue aware of fimg2d dma.
  *
  * @ctx: a pointer to g2d_context structure.
  *
  * This function should be called after all commands and values to user
- * side command buffer is set to summit that buffer to kernel side driver.
+ * side command buffer are set. It submits that buffer to the kernel side 
driver.
  */
 static int g2d_flush(struct g2d_context *ctx)
 {
@@ -191,7 +191,7 @@ static int g2d_flush(struct g2d_context *ctx)
 /**
  * g2d_init - create a new g2d context and get hardware version.
  *
- * fd: a file descriptor to drm device driver opened.
+ * fd: a file descriptor to an opened drm device.
  */
 struct g2d_context *g2d_init(int fd)
 {
@@ -520,7 +520,7 @@ int g2d_copy_with_scale(struct g2d_context *ctx, struct 
g2d_image *src,
 }

 /**
- * g2d_blend - blend image data in source and destion buffers
+ * g2d_blend - blend image data in source and destination buffers.
  *
  * @ctx: a pointer to g2d_context structure.
  * @src: a pointer to g2d_image structure including image and buffer
diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index 41fb869..aa140e5 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -39,7 +39,7 @@ static unsigned int screen_width, screen_height;
 /*
  * A structure to test fimg2d hw.
  *
- * @solid_fild: fill given color data to source buffer.
+ * @solid_fill: fill given color data to source buffer.
  * @copy: copy source to destination buffer.
  * @copy_with_scale: copy source to destination buffer scaling up or
  * down properly.
@@ -256,7 +256,7 @@ static int g2d_solid_fill_test(struct exynos_device *dev, 
struct exynos_bo *dst)
memset(, 0, sizeof(struct g2d_image));
img.bo[0] = dst->handle;

-   printf("soild fill test.\n");
+   printf("solid fill test.\n");

srand(time(NULL));
img_w = screen_width;
-- 
1.8.5.5

[PATCH 2/3] exynos: replace G2D_DOUBLE_TO_FIXED macro with documented function

[Tobias Jakobi]

This also avoids the floating point conversion steps and just
uses pure integer arithmetic. Also the G2D hardware scaling
factor is a bit unintuitive, so explain it in the function.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_fimg2d.c | 19 ++-
 exynos/fimg2d.h|  2 --
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index fc281b6..435a88d 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -40,6 +40,15 @@

 #define MIN(a, b)  ((a) < (b) ? (a) : (b))

+static unsigned int g2d_get_scaling(unsigned int src, unsigned int dst)
+{
+   /* The G2D hw scaling factor is a normalized inverse of the scaling 
factor. *
+* For example: When source width is 100 and destination width is 200   
*
+* (scaling of 2x), then the hw factor is NORMALIZE_CONSTANT * 100 / 
200.   */
+
+   return ((src << 16) / dst);
+}
+
 static unsigned int g2d_get_blend_op(enum e_g2d_op op)
 {
union g2d_blend_func_val val;
@@ -424,7 +433,7 @@ int g2d_copy_with_scale(struct g2d_context *ctx, struct 
g2d_image *src,
union g2d_rop4_val rop4;
union g2d_point_val pt;
unsigned int scale;
-   double scale_x = 0.0f, scale_y = 0.0f;
+   unsigned int scale_x, scale_y;

g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
@@ -450,8 +459,8 @@ int g2d_copy_with_scale(struct g2d_context *ctx, struct 
g2d_image *src,
scale = 0;
else {
scale = 1;
-   scale_x = (double)src_w / (double)dst_w;
-   scale_y = (double)src_h / (double)dst_h;
+   scale_x = g2d_get_scaling(src_w, dst_w);
+   scale_y = g2d_get_scaling(src_h, dst_h);
}

if (src_x + src_w > src->width)
@@ -483,8 +492,8 @@ int g2d_copy_with_scale(struct g2d_context *ctx, struct 
g2d_image *src,

if (scale) {
g2d_add_cmd(ctx, SRC_SCALE_CTRL_REG, G2D_SCALE_MODE_BILINEAR);
-   g2d_add_cmd(ctx, SRC_XSCALE_REG, G2D_DOUBLE_TO_FIXED(scale_x));
-   g2d_add_cmd(ctx, SRC_YSCALE_REG, G2D_DOUBLE_TO_FIXED(scale_y));
+   g2d_add_cmd(ctx, SRC_XSCALE_REG, scale_x);
+   g2d_add_cmd(ctx, SRC_YSCALE_REG, scale_y);
}

pt.val = 0;
diff --git a/exynos/fimg2d.h b/exynos/fimg2d.h
index 4785e2f..8e0321c 100644
--- a/exynos/fimg2d.h
+++ b/exynos/fimg2d.h
@@ -25,8 +25,6 @@
 #define G2D_MAX_CMD_LIST_NR64
 #define G2D_PLANE_MAX_NR   2

-#define G2D_DOUBLE_TO_FIXED(d) ((unsigned int)((d) * 65536.0))
-
 enum e_g2d_color_mode {
/* COLOR FORMAT */
G2D_COLOR_FMT_XRGB,
-- 
1.8.5.5

[PATCH 1/3] tests/exynos: fimg2d: add a checkerboard test

[Tobias Jakobi]

This makes it easier to see corruption which e.g. occurs when using the userptr
functionality to copy buffers allocated via plain malloc.
One of the reasons why this is currently just used with GEM buffer mode.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/exynos_fimg2d_test.c | 117 ++
 1 file changed, 117 insertions(+)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index c6bd558..41fb869 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -55,6 +55,9 @@ struct fimg2d_test_case {
int (*blend)(struct exynos_device *dev,
struct exynos_bo *src, struct exynos_bo *dst,
enum e_g2d_buf_type);
+   int (*checkerboard)(struct exynos_device *dev,
+   struct exynos_bo *src, struct exynos_bo *dst,
+   enum e_g2d_buf_type);
 };

 struct connector {
@@ -207,6 +210,33 @@ static struct exynos_bo *exynos_create_buffer(struct 
exynos_device *dev,
return bo;
 }

+/* Allocate buffer and fill it with checkerboard pattern, where the tiles *
+ * have a random color. The caller has to free the buffer.*/
+void *create_checkerboard_pattern(unsigned int num_tiles_x,
+   unsigned int num_tiles_y, 
unsigned int tile_size)
+{
+   unsigned int *buf;
+   unsigned int x, y, i, j;
+   const unsigned int stride = num_tiles_x * tile_size;
+
+   if (posix_memalign((void*), 64, num_tiles_y * tile_size * stride * 
4) != 0)
+   return NULL;
+
+   for (x = 0; x < num_tiles_x; ++x) {
+   for (y = 0; y < num_tiles_y; ++y) {
+   const unsigned int color = 0xff00 + (random() & 
0xff);
+
+   for (i = 0; i < tile_size; ++i) {
+   for (j = 0; j < tile_size; ++j) {
+   buf[x * tile_size + y * stride * 
tile_size + i + j * stride] = color;
+   }
+   }
+   }
+   }
+
+   return buf;
+}
+
 static void exynos_destroy_buffer(struct exynos_bo *bo)
 {
exynos_bo_destroy(bo);
@@ -533,11 +563,90 @@ err_free_userptr:
return 0;
 }

+static int g2d_checkerboard_test(struct exynos_device *dev,
+   struct exynos_bo *src,
+   struct exynos_bo *dst,
+   enum e_g2d_buf_type type)
+{
+   struct g2d_context *ctx;
+   struct g2d_image src_img = {0}, dst_img = {0};
+   unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
+   void *checkerboard = NULL;
+   int ret;
+
+   ctx = g2d_init(dev->fd);
+   if (!ctx)
+   return -EFAULT;
+
+   dst_img.bo[0] = dst->handle;
+
+   src_x = 0;
+   src_y = 0;
+   dst_x = 0;
+   dst_y = 0;
+
+   checkerboard = create_checkerboard_pattern(screen_width / 32, 
screen_height / 32, 32);
+   if (checkerboard == NULL) {
+   ret = -1;
+   goto fail;
+   }
+
+   img_w = screen_width - (screen_width % 32);
+   img_h = screen_height - (screen_height % 32);
+
+   switch (type) {
+   case G2D_IMGBUF_GEM:
+   memcpy(src->vaddr, checkerboard, img_w * img_h * 4);
+   src_img.bo[0] = src->handle;
+   break;
+   case G2D_IMGBUF_USERPTR:
+   src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
+   src_img.user_ptr[0].size = img_w * img_h * 4;
+   break;
+   default:
+   ret = -EFAULT;
+   goto fail;
+   }
+
+   printf("checkerboard test with %s.\n",
+   type == G2D_IMGBUF_GEM ? "gem" : "userptr");
+
+   src_img.width = img_w;
+   src_img.height = img_h;
+   src_img.stride = src_img.width * 4;
+   src_img.buf_type = type;
+   src_img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+
+   dst_img.width = screen_width;
+   dst_img.height = screen_height;
+   dst_img.stride = dst_img.width * 4;
+   dst_img.buf_type = G2D_IMGBUF_GEM;
+   dst_img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+   src_img.color = 0xff00;
+   ret = g2d_solid_fill(ctx, _img, src_x, src_y, screen_width, 
screen_height);
+   if (ret < 0)
+   goto fail;
+
+   ret = g2d_copy(ctx, _img, _img, src_x, src_y, dst_x, dst_y,
+   img_w, img_h);
+   if (ret < 0)
+   goto fail;
+
+   g2d_exec(ctx);
+
+fail:
+   free(checkerboard);
+   g2d_fini(ctx);
+
+   return ret;
+}
+
 static struct fimg2d_test_case test_case = {
.solid_fill = _solid_fill_test,
.copy = _copy_test,
.copy_with_scale = _copy_with_scale_test,
.blend = _blend_test,
+ 

[PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver

[Inki Dae]

On 2014? 06? 26? 23:36, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
> 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>  - Remove usage of driver_data to configure DP CLKCON register
>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 2 ++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  | 8 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
>  include/video/samsung_fimd.h | 4 
>  4 files changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 2e77a15..d8868f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>  
>   platform_set_drvdata(pdev, _dp_display);
>  
> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
> +
>   return exynos_drm_create_enc_conn(drm_dev, _dp_display);
>  }
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 36535f3..1089744 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
>   EXYNOS_DISPLAY_TYPE_VIDI,
>  };
>  
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_MIPI,
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DP,
> +};
> +
>  /*
>   * Exynos drm common overlay structure.
>   *
> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
>  extern struct platform_driver rotator_driver;
>  extern struct platform_driver gsc_driver;
>  extern struct platform_driver ipp_driver;
> +
> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
>  #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bb45ab2..a46a9c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .has_shadowcon = 1,
>  };
>  
> +enum exynos_fimd_output_type exynos_fimd_output_type;
> +
>  struct fimd_win_data {
>   unsigned intoffset_x;
>   unsigned intoffset_y;
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>  
> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);


You are passing output type directly from dp driver to fimd driver using
extern variable. This is really not good. Is that really only way for it?

One is,
it's to add a dt property in fimd node and use it; ex.
samsung,output_type. Whether fimd output should be DPI, DSI, or eDP
would be dependent on Machine.

Other is,
crtc driver is to get output type though encoder callback. At this
moment, crtc driver already knows encoder/connector driver. So I think
you can use a callback of encoder to get output type like below,

exynos_display_ops {
...
...get_output(struct drm_crtc *crtc);
};

at exynos_drm_encoder.c,
... exynos_drm_get_output_type(struct drm_crtc *crtc)
{
...
return display_ops->get_output(...);
}

at fimd_commit function,
...
ctx->output_type = exynos_drm_get_output_type(mgr->crtc);


I think first way is more simple and reasonable.

One more thing, does FIMD ip of Exynos4 series have DP_CLKCON register?
No, they have no any DP_CLKCON register so you would need to consider
other SoC without DP_CLKCON. For this, a proper volunteer would be
fimd_driver_data.

Thanks,
Inki Dae


> +
>   writel(val, ctx->regs + VIDCON0);
>  }
>  
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>  
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 4
> 

[PATCH v3 2/4] drm: Constify struct drm_fb_helper_funcs

[Russell King - ARM Linux]

On Fri, Jun 27, 2014 at 05:19:23PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> There's no need for this to be modifiable. Make it const so that it can
> be put into the .rodata section.
> 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Thierry Reding 

Definitely a good thing.  For Armada:

Acked-by: Russell King 

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v14 updated] imx-drm: use defines for clock polarity settings

[Denis Carikli]

Signed-off-by: Denis Carikli 
---
 drivers/gpu/ipu-v3/ipu-di.c  |4 ++--
 drivers/staging/imx-drm/ipuv3-crtc.c |4 ++--
 include/video/imx-ipu-v3.h   |8 +++-
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index c490ba4..5f7f799 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -595,7 +595,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct 
ipu_di_signal_cfg *sig)
}
}

-   if (sig->clk_pol)
+   if (sig->clk_pol == IPU_CLK_POL_POSEDGE)
di_gen |= DI_GEN_POLARITY_DISP_CLK;

ipu_di_write(di, di_gen, DI_GENERAL);
@@ -606,7 +606,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct 
ipu_di_signal_cfg *sig)
reg = ipu_di_read(di, DI_POL);
reg &= ~(DI_POL_DRDY_DATA_POLARITY | DI_POL_DRDY_POLARITY_15);

-   if (sig->enable_pol)
+   if (sig->enable_pol == IPU_ENABLE_POL_HIGH)
reg |= DI_POL_DRDY_POLARITY_15;
if (sig->data_pol)
reg |= DI_POL_DRDY_DATA_POLARITY;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 720868b..4e54f7a 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -165,8 +165,8 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;

-   sig_cfg.enable_pol = 1;
-   sig_cfg.clk_pol = 0;
+   sig_cfg.enable_pol = IPU_ENABLE_POL_HIGH;
+   sig_cfg.clk_pol = IPU_CLK_POL_NEGEDGE;
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 3e43e22..d52edb4 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -27,6 +27,12 @@ enum ipuv3_type {

 #define IPU_PIX_FMT_GBR24  v4l2_fourcc('G', 'B', 'R', '3')

+#define IPU_CLK_POL_NEGEDGE0
+#define IPU_CLK_POL_POSEDGE1
+
+#define IPU_ENABLE_POL_LOW 0
+#define IPU_ENABLE_POL_HIGH1
+
 /*
  * Bitfield of Display Interface signal polarities.
  */
@@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
unsigned clksel_en:1;
unsigned clkidle_en:1;
unsigned data_pol:1;/* true = inverted */
-   unsigned clk_pol:1; /* true = rising edge */
+   unsigned clk_pol:1;
unsigned enable_pol:1;
unsigned Hsync_pol:1;   /* true = active high */
unsigned Vsync_pol:1;
-- 
1.7.9.5

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #18 from higuita at gmx.net ---
On steam, you can select the game, right click on it, select proprieties? ,
launch options and put

apitrace %command%

you can run the game with gdb, strace , etc  using this option. it will output
to the console, so start steam in a terminal if you need to see the 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/20140627/a270a4fa/attachment.html>

[PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale

[Ajay Kumar]

Set FIMD output type for arndale as DP.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5250-arndale.dts |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..e803183 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -540,6 +540,7 @@

fimd: fimd at 1440 {
status = "okay";
+   samsung,output-type = <2>;
display-timings {
native-mode = <>;
timing0: timing at 0 {
-- 
1.7.9.5

[PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420

[Ajay Kumar]

Set FIMD output type for smdk5420 as DP.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6052aa9..5f05a19 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -120,6 +120,7 @@

fimd at 1440 {
status = "okay";
+   samsung,output-type = <2>;
display-timings {
native-mode = <>;
timing0: timing at 0 {
-- 
1.7.9.5

[PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250

[Ajay Kumar]

Set FIMD output type for smdk5250 as DP.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a794a70..ed28efb 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -382,6 +382,7 @@

fimd at 1440 {
status = "okay";
+   samsung,output-type = <2>;
display-timings {
native-mode = <>;
timing0: timing at 0 {
-- 
1.7.9.5

[PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi

[Ajay Kumar]

Set FIMD output type for peach_pi as DP.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5800-peach-pi.dts |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3af207..21e2de2 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -205,6 +205,7 @@
  {
status = "okay";
samsung,invert-vclk;
+   samsung,output-type = <2>;
 };

 _9 {
-- 
1.7.9.5

[PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit

[Ajay Kumar]

Set FIMD output type for peach_pit as DP.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1c5b8f9..164f523 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -255,6 +255,7 @@
  {
status = "okay";
samsung,invert-vclk;
+   samsung,output-type = <2>;
 };

  {
-- 
1.7.9.5

[PATCH V3 2/7] ARM: dts: Add FIMD output property for snow

[Ajay Kumar]

Set FIMD output type for snow as DP.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5250-snow.dts |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 079fdf9..dc3ae9c 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -400,6 +400,7 @@
fimd at 1440 {
status = "okay";
samsung,invert-vclk;
+   samsung,output-type = <2>;
};

dp-controller at 145B {
-- 
1.7.9.5

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay Kumar]

Add the missing setting for DP CLKCON register.

This register is present on Exynos5 based FIMD controllers,
and needs to be set if we are using DP.

Signed-off-by: Ajay Kumar 
---
 .../devicetree/bindings/video/samsung-fimd.txt |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
 include/video/samsung_fimd.h   |4 
 3 files changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..12f3d7a 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -41,6 +41,7 @@ Optional Properties:
 - samsung,power-domain: a phandle to FIMD power domain node.
 - samsung,invert-vden: video enable signal is inverted
 - samsung,invert-vclk: video clock signal is inverted
+- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
 - display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..aa74e90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+   unsigned int has_dp_clkcon:1;
 };

 static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
 static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+   .has_dp_clkcon = 1,
+};
+
+enum exynos_fimd_output_type {
+   EXYNOS_FIMD_OUTPUT_DPI,
+   EXYNOS_FIMD_OUTPUT_DSI,
+   EXYNOS_FIMD_OUTPUT_DP,
 };

 struct fimd_win_data {
@@ -125,6 +133,8 @@ struct fimd_context {
struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
struct exynos_drm_display *display;
+
+   enum exynos_fimd_output_type exynos_fimd_output_type;
 };

 static const struct of_device_id fimd_driver_dt_match[] = {
@@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv > 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;

+   if (ctx->driver_data->has_dp_clkcon &&
+   ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
+   writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
+
writel(val, ctx->regs + VIDCON0);
 }

@@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct fimd_context *ctx;
struct resource *res;
+   u32 fimd_output_type;
int ret = -EINVAL;

ret = exynos_drm_component_add(>dev, EXYNOS_DEVICE_TYPE_CRTC,
@@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
ctx->vidcon1 |= VIDCON1_INV_VDEN;
if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
ctx->vidcon1 |= VIDCON1_INV_VCLK;
+   if (!of_property_read_u32(dev->of_node, "samsung,output-type",
+   _output_type)) {
+   if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
+   (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
+   dev_err(dev, "invalid output type for FIMD\n");
+   else
+   ctx->exynos_fimd_output_type = fimd_output_type;
+   }

ctx->bus_clk = devm_clk_get(dev, "fimd");
if (IS_ERR(ctx->bus_clk)) {
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
 #define BLENDCON_NEW_8BIT_ALPHA_VALUE  (1 << 0)
 #define BLENDCON_NEW_4BIT_ALPHA_VALUE  (0 << 0)

+/* Video clock enable for DP */
+#define DP_CLKCON  0x27C
+#define DP_CLK_ENABLE  0x2
+
 /* Notes on per-window bpp settings
  *
  * Value   Win0 Win1 Win2 Win3 Win 4
-- 
1.7.9.5

[PATCH V3 0/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay Kumar]

This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Changes since V2:
Add DT property to know the type of FIMD output interface
as per Inki's suggestion.
Add samsung,output-type DT property in FIMD node for all boards
supporting DP interface.

Ajay Kumar (7):
  [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
  [PATCH V3 2/7] ARM: dts: Add FIMD output property for snow
  [PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit
  [PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi
  [PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250
  [PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420
  [PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale

 .../devicetree/bindings/video/samsung-fimd.txt |1 +
 arch/arm/boot/dts/exynos5250-arndale.dts   |1 +
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |1 +
 arch/arm/boot/dts/exynos5250-snow.dts  |1 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts |1 +
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |1 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
 include/video/samsung_fimd.h   |4 
 9 files changed, 34 insertions(+)

-- 
1.7.9.5

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Tomasz Figa]

On 27.06.2014 15:02, Ajay kumar wrote:
> Hi Andrej,
> 
> On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda  wrote:
>> On 06/27/2014 01:48 PM, Ajay kumar wrote:
>>> Hi Andrej,
>>>
>>> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda  
>>> wrote:
 Hi Ajay,

 +CC DT

 On 06/27/2014 12:12 PM, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
>
> This register is present on Exynos5 based FIMD controllers,
> and needs to be set if we are using DP.
>
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/samsung-fimd.txt |1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
> 
>  include/video/samsung_fimd.h   |4 
>  3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> index 2dad41b..12f3d7a 100644
> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> @@ -41,6 +41,7 @@ Optional Properties:
>  - samsung,power-domain: a phandle to FIMD power domain node.
>  - samsung,invert-vden: video enable signal is inverted
>  - samsung,invert-vclk: video clock signal is inverted
> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, 
> DP=2)
 There is no point in introducing this property. Exynos DRM have already
 logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
 reused to determine display type. It can be done even without any
 additional callbacks, just by checking if there is connector of
 DRM_MODE_CONNECTOR_eDP type connected to fimd.
>>> The mapping between crtc(struct exynos_drm_manager) and encoder(struct
>>> exynos_drm_display)
>>> in exynos drm happens by matching the exynos_drm_output_type variable in 
>>> each
>>> structure.
>>> exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
>>> FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
>>> and both DP and MIPI statically choose the same enum 
>>> EXYNOS_DISPLAY_TYPE_LCD,
>>> as output type.
>>> So, we cannot use that logic to differentiate between DP/MIPI DSI.
>>>
>>> Also, checking based on connector type doesn't hold good.
>>> The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
>>> DP->LVDS or MIPI->LVDS panels!
>>
>> True, I forgot about bridges. So additional callback/field is necessary.
>> See below.
>>
>>>
>>> Thanks and regards,
>>> Ajay Kumar
>>>
 Regards
 Andrzej

>  - display-timings: timing settings for FIMD, as described in document 
> [1].
>   Can be used in case timings cannot be provided otherwise
>   or to override timings provided by the panel.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..aa74e90 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>   unsigned int has_shadowcon:1;
>   unsigned int has_clksel:1;
>   unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
>  };
>
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,13 @@ static struct fimd_driver_data 
> exynos4_fimd_driver_data = {
>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .timing_base = 0x2,
>   .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
> +};
> +
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DSI,
> + EXYNOS_FIMD_OUTPUT_DP,
>  };
>
>  struct fimd_win_data {
> @@ -125,6 +133,8 @@ struct fimd_context {
>   struct exynos_drm_panel_info panel;
>   struct fimd_driver_data *driver_data;
>   struct exynos_drm_display *display;
> +
> + enum exynos_fimd_output_type exynos_fimd_output_type;
>  };
>
>  static const struct of_device_id fimd_driver_dt_match[] = {
> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager 
> *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>
> + if (ctx->driver_data->has_dp_clkcon &&
> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
>   writel(val, ctx->regs + VIDCON0);
>>
>> New code should not split VIDCON0 related code.It should be moved few
>> lines above or few lines below.
> Ok, for better readability.
> 
>> Anyway this code should be rather placed in power related functions of
>> dp encoder, as it enables dp. The only question
>> is if DP_CLKCON 

[Bug 70207] rs690: kernel can't bring lvds in dpms on mode

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

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

--- Comment #7 from David Heidelberger (okias)  
---
well, as I noticed, there is very dark image on screen, so it's backlight.

-- 
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/20140627/59f48470/attachment.html>

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Andrzej Hajda]

On 06/27/2014 01:48 PM, Ajay kumar wrote:
> Hi Andrej,
>
> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda  wrote:
>> Hi Ajay,
>>
>> +CC DT
>>
>> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
>>> Add the missing setting for DP CLKCON register.
>>>
>>> This register is present on Exynos5 based FIMD controllers,
>>> and needs to be set if we are using DP.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  .../devicetree/bindings/video/samsung-fimd.txt |1 +
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
>>> 
>>>  include/video/samsung_fimd.h   |4 
>>>  3 files changed, 28 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
>>> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>>> index 2dad41b..12f3d7a 100644
>>> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
>>> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
>>> @@ -41,6 +41,7 @@ Optional Properties:
>>>  - samsung,power-domain: a phandle to FIMD power domain node.
>>>  - samsung,invert-vden: video enable signal is inverted
>>>  - samsung,invert-vclk: video clock signal is inverted
>>> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)
>> There is no point in introducing this property. Exynos DRM have already
>> logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
>> reused to determine display type. It can be done even without any
>> additional callbacks, just by checking if there is connector of
>> DRM_MODE_CONNECTOR_eDP type connected to fimd.
> The mapping between crtc(struct exynos_drm_manager) and encoder(struct
> exynos_drm_display)
> in exynos drm happens by matching the exynos_drm_output_type variable in each
> structure.
> exynos_drm_output_type supports 3 types: LCD, HDMI and VIDI.
> FIMD statically chooses EXYNOS_DISPLAY_TYPE_LCD as the output type,
> and both DP and MIPI statically choose the same enum EXYNOS_DISPLAY_TYPE_LCD,
> as output type.
> So, we cannot use that logic to differentiate between DP/MIPI DSI.
>
> Also, checking based on connector type doesn't hold good.
> The connector type will be DRM_MODE_CONNECTOR_LVDS in case of
> DP->LVDS or MIPI->LVDS panels!

True, I forgot about bridges. So additional callback/field is necessary.
See below.

>
> Thanks and regards,
> Ajay Kumar
>
>> Regards
>> Andrzej
>>
>>>  - display-timings: timing settings for FIMD, as described in document [1].
>>>   Can be used in case timings cannot be provided otherwise
>>>   or to override timings provided by the panel.
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 33161ad..aa74e90 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>>>   unsigned int has_shadowcon:1;
>>>   unsigned int has_clksel:1;
>>>   unsigned int has_limited_fmt:1;
>>> + unsigned int has_dp_clkcon:1;
>>>  };
>>>
>>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>>> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data 
>>> = {
>>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>>>   .timing_base = 0x2,
>>>   .has_shadowcon = 1,
>>> + .has_dp_clkcon = 1,
>>> +};
>>> +
>>> +enum exynos_fimd_output_type {
>>> + EXYNOS_FIMD_OUTPUT_DPI,
>>> + EXYNOS_FIMD_OUTPUT_DSI,
>>> + EXYNOS_FIMD_OUTPUT_DP,
>>>  };
>>>
>>>  struct fimd_win_data {
>>> @@ -125,6 +133,8 @@ struct fimd_context {
>>>   struct exynos_drm_panel_info panel;
>>>   struct fimd_driver_data *driver_data;
>>>   struct exynos_drm_display *display;
>>> +
>>> + enum exynos_fimd_output_type exynos_fimd_output_type;
>>>  };
>>>
>>>  static const struct of_device_id fimd_driver_dt_match[] = {
>>> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>>   if (clkdiv > 1)
>>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>>
>>> + if (ctx->driver_data->has_dp_clkcon &&
>>> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
>>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>>> +
>>>   writel(val, ctx->regs + VIDCON0);

New code should not split VIDCON0 related code. It should be moved few
lines above or few lines below.
Anyway this code should be rather placed in power related functions of
dp encoder, as it enables dp. The only question
is if DP_CLKCON update can be performed after VIDCON0 update. If yes the
solution of the whole problem
seems to be simple:
- fimd should provide function fimd_set_dp_clk_gate or sth similar,
- this function should be called in exynos_dp_poweron/exynos_dp_poweroff.
I hope I have not missed anything this time.

Regards
Andrzej


>>>  }
>>>
>>> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
>>>   struct 

[PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver

[Ajay kumar]

Hi Inki,

Thanks for the review.

On Fri, Jun 27, 2014 at 1:04 PM, Inki Dae  wrote:
> On 2014? 06? 26? 23:36, Ajay Kumar wrote:
>> Add the missing setting for DP CLKCON register.
>>
>> This register is present on Exynos5 based FIMD controllers,
>> and needs to be used if we are using DP.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>> Changes since V1:
>>  - Remove usage of driver_data to configure DP CLKCON register
>>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 2 ++
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  | 8 
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
>>  include/video/samsung_fimd.h | 4 
>>  4 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 2e77a15..d8868f3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct 
>> device *master, void *data)
>>
>>   platform_set_drvdata(pdev, _dp_display);
>>
>> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
>> +
>>   return exynos_drm_create_enc_conn(drm_dev, _dp_display);
>>  }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 36535f3..1089744 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
>>   EXYNOS_DISPLAY_TYPE_VIDI,
>>  };
>>
>> +enum exynos_fimd_output_type {
>> + EXYNOS_FIMD_OUTPUT_MIPI,
>> + EXYNOS_FIMD_OUTPUT_DPI,
>> + EXYNOS_FIMD_OUTPUT_DP,
>> +};
>> +
>>  /*
>>   * Exynos drm common overlay structure.
>>   *
>> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
>>  extern struct platform_driver rotator_driver;
>>  extern struct platform_driver gsc_driver;
>>  extern struct platform_driver ipp_driver;
>> +
>> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
>>  #endif
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index bb45ab2..a46a9c4 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
>>   .has_shadowcon = 1,
>>  };
>>
>> +enum exynos_fimd_output_type exynos_fimd_output_type;
>> +
>>  struct fimd_win_data {
>>   unsigned intoffset_x;
>>   unsigned intoffset_y;
>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>>   if (clkdiv > 1)
>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>
>> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>
>
> You are passing output type directly from dp driver to fimd driver using
> extern variable. This is really not good. Is that really only way for it?
>
> One is,
> it's to add a dt property in fimd node and use it; ex.
> samsung,output_type. Whether fimd output should be DPI, DSI, or eDP
> would be dependent on Machine.
>
> Other is,
> crtc driver is to get output type though encoder callback. At this
> moment, crtc driver already knows encoder/connector driver. So I think
> you can use a callback of encoder to get output type like below,
>
> exynos_display_ops {
> ...
> ...get_output(struct drm_crtc *crtc);
> };
>
> at exynos_drm_encoder.c,
> ... exynos_drm_get_output_type(struct drm_crtc *crtc)
> {
> ...
> return display_ops->get_output(...);
> }
>
> at fimd_commit function,
> ...
> ctx->output_type = exynos_drm_get_output_type(mgr->crtc);
>
>
> I think first way is more simple and reasonable.
>
> One more thing, does FIMD ip of Exynos4 series have DP_CLKCON register?
> No, they have no any DP_CLKCON register so you would need to consider
> other SoC without DP_CLKCON. For this, a proper volunteer would be
> fimd_driver_data.
Right, I should also consider putting DP CLKCON register inside driver_data.
And, I will use the DT property you mentioned.
Will send a patchset ASAP.

Regards,
Ajay Kumar

> Thanks,
> Inki Dae
>
>
>> +
>>   writel(val, ctx->regs + VIDCON0);
>>  }
>>
>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>> index b039320..d8f4b0b 100644
>> --- a/include/video/samsung_fimd.h
>> +++ b/include/video/samsung_fimd.h
>> @@ -435,6 +435,10 @@
>>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>>
>> +/* Video clock enable for DP */
>> +#define DP_CLKCON0x27C
>> +#define DP_CLK_ENABLE0x2
>> +
>>  /* Notes on per-window bpp settings
>>   *
>>   * Value Win0 Win1 Win2 Win3 Win 4
>>
>

[Bug 70207] rs690: kernel can't bring lvds in dpms on mode

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

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

--- Comment #6 from Alex Deucher  ---
It's the same code in the driver whether the console layer calls it or X calls
it.  Maybe the console also mucks with the backlight?  You can use radeonreg
(http://cgit.freedesktop.org/~airlied/radeontool/) to compare registers.

-- 
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/20140627/650f0f13/attachment.html>

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #101773|0   |1
is obsolete||

--- Comment #8 from Alex Deucher  ---
Created attachment 101866
  --> https://bugs.freedesktop.org/attachment.cgi?id=101866=edit
testing patch

Does this help?  Can you also attach a copy of your vbios?  To get a copy of
your vbios:

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

-- 
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/20140627/0ddf7b28/attachment.html>

[Bug 70207] rs690: kernel can't bring lvds in dpms on mode

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

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

--- Comment #5 from David Heidelberger (okias)  
---
so bringing screen back fails somewhere on HW level?

in console:
  * driver set output=on, hw=on
  * result: output=on and hw=off stay
in X.org:
  * driver set output=on, hw=on
  * result: output=on and hw=on thanks to ? (some delay needed to resurrect
lvds? or trigger additional register?)

-- 
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/20140627/1d3a4a0b/attachment.html>

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Andrzej Hajda]

Hi Ajay,

+CC DT

On 06/27/2014 12:12 PM, Ajay Kumar wrote:
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be set if we are using DP.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/samsung-fimd.txt |1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
> 
>  include/video/samsung_fimd.h   |4 
>  3 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
> b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> index 2dad41b..12f3d7a 100644
> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> @@ -41,6 +41,7 @@ Optional Properties:
>  - samsung,power-domain: a phandle to FIMD power domain node.
>  - samsung,invert-vden: video enable signal is inverted
>  - samsung,invert-vclk: video clock signal is inverted
> +- samsung,output-type: Type of display output interface(DPI=0, DSI=1, DP=2)

There is no point in introducing this property. Exynos DRM have already
logic which creates pipeline: fimd --> DPI|DSI|DP, this logic can be
reused to determine display type. It can be done even without any
additional callbacks, just by checking if there is connector of
DRM_MODE_CONNECTOR_eDP type connected to fimd.


Regards
Andrzej

>  - display-timings: timing settings for FIMD, as described in document [1].
>   Can be used in case timings cannot be provided otherwise
>   or to override timings provided by the panel.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 33161ad..aa74e90 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -72,6 +72,7 @@ struct fimd_driver_data {
>   unsigned int has_shadowcon:1;
>   unsigned int has_clksel:1;
>   unsigned int has_limited_fmt:1;
> + unsigned int has_dp_clkcon:1;
>  };
>  
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -88,6 +89,13 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .timing_base = 0x2,
>   .has_shadowcon = 1,
> + .has_dp_clkcon = 1,
> +};
> +
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DSI,
> + EXYNOS_FIMD_OUTPUT_DP,
>  };
>  
>  struct fimd_win_data {
> @@ -125,6 +133,8 @@ struct fimd_context {
>   struct exynos_drm_panel_info panel;
>   struct fimd_driver_data *driver_data;
>   struct exynos_drm_display *display;
> +
> + enum exynos_fimd_output_type exynos_fimd_output_type;
>  };
>  
>  static const struct of_device_id fimd_driver_dt_match[] = {
> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>  
> + if (ctx->driver_data->has_dp_clkcon &&
> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
>   writel(val, ctx->regs + VIDCON0);
>  }
>  
> @@ -924,6 +938,7 @@ static int fimd_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct fimd_context *ctx;
>   struct resource *res;
> + u32 fimd_output_type;
>   int ret = -EINVAL;
>  
>   ret = exynos_drm_component_add(>dev, EXYNOS_DEVICE_TYPE_CRTC,
> @@ -949,6 +964,14 @@ static int fimd_probe(struct platform_device *pdev)
>   ctx->vidcon1 |= VIDCON1_INV_VDEN;
>   if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
>   ctx->vidcon1 |= VIDCON1_INV_VCLK;
> + if (!of_property_read_u32(dev->of_node, "samsung,output-type",
> + _output_type)) {
> + if ((fimd_output_type < EXYNOS_FIMD_OUTPUT_DPI) ||
> + (fimd_output_type > EXYNOS_FIMD_OUTPUT_DP))
> + dev_err(dev, "invalid output type for FIMD\n");
> + else
> + ctx->exynos_fimd_output_type = fimd_output_type;
> + }
>  
>   ctx->bus_clk = devm_clk_get(dev, "fimd");
>   if (IS_ERR(ctx->bus_clk)) {
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>  
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 4
> 

[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

--- Comment #4 from Fabian Pas  ---
Created attachment 141121
  --> https://bugzilla.kernel.org/attachment.cgi?id=141121=edit
The xorg.0 log file after a crash

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

[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

--- Comment #3 from Fabian Pas  ---
Created attachment 14
  --> https://bugzilla.kernel.org/attachment.cgi?id=14=edit
The glxinfo after a crash

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

[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

--- Comment #2 from Fabian Pas  ---
Created attachment 141101
  --> https://bugzilla.kernel.org/attachment.cgi?id=141101=edit
The dmesg log after a crash

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

[Bug 79051] New: Panic with radeon hd 5750, bisected

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

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

Bug ID: 79051
   Summary: Panic with radeon hd 5750, bisected
   Product: Drivers
   Version: 2.5
Kernel Version: 3.14.6 - 3.16-rc2
  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: jonathan at unbiased.name
Regression: No

Happens usually within first minute of starting weston (drm on archlinux.) just
opening windows and moving mouse. (no panic within X.)

Bisected to
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.14.y=19aef29eea6e5b42e4097c2ccdd80e944e9f9f6f

Still same with 3.16-rc2.

Panic only dumped to screen so don't have exact copy.
RIP in drm_vblank_put
radeon_crt_handle_flip
evergreen_irq_process
notice_schd_clock
radeon_irq_handler_kms
handle_irq_events_percpu
...

Removing the one line stops the panic so does this;

diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergre
index 971d933..e31d936 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4967,7 +4967,8 @@ restart_ih:
case 16: /* D5 page flip */
case 18: /* D6 page flip */
DRM_DEBUG("IH: D%d flip\n", ((src_id - 8) >> 1) + 1);
-   radeon_crtc_handle_flip(rdev, (src_id - 8) >> 1);
+   if (atomic_read(>irq.pflip[(src_id - 8) >> 1]))
+   radeon_crtc_handle_flip(rdev, (src_id - 8) >>
1)
break;
case 42: /* HPD hotplug */
switch (src_data) {

Only guess work on my part. Needs someone with knowledge of code determine real
fix.

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

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Christian König]

Am 27.06.2014 11:44, schrieb Michel D?nzer:
> On 27.06.2014 17:18, Christian K?nig wrote:
>> Am 27.06.2014 04:58, schrieb Michel D?nzer:
>>> On 26.06.2014 19:39, Christian K?nig wrote:
 Am 26.06.2014 11:29, schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> Prevents radeon_crtc_handle_flip() from running before
> radeon_flip_work_func(), resulting in a kernel panic due to
> the BUG_ON() in drm_vblank_put().
>
> Tested-by: Dieter N?tzel  Signed-off-by:
> Michel D?nzer 
 Does patch #2 alone fixes the problem as well?
>>> It should avoid the panic as well.
>>>
>>>
 I would rather want to avoid turning the pflip interrupt on and
 off.
>>> What's the problem with that? It's not like we're saving any
>>> register writes by not doing it.
>> We don't? As far as I can see we reprogram all interrupt registers
>> if any of the interrupts changed,
> Maybe I'm missing something, but: radeon_irq_kms_pflip_irq_get/put()
> call radeon_irq_set() every time, as there can only be one active page
> flip per CRTC. And radeon_irq_set() always writes the same registers,
> only the bits it writes to them change depending on which interrupts the
> driver is currently interested in.

We first turn on the vblank interrupt which results in a 
radeon_irq_set() and then turn on the pflip, which results in another 
radeon_irq_set() .

>
>> this has already lead to quite some additional overhead in the fence
>> waiting code.
> radeon_irq_set() should probably be split up to reduce the overhead.

Yeah, agree totally but didn't had time for this yet (it has a rather 
low priority). Might be a good task for someone to get his hands dirty 
on the kernel code for the first time as well.

I think turning interrupts on and off at each fence wait is the reason 
why inlining r100_mm_rreg and r100_mm_wreg again turned out to improve 
performance for some people quite a bit.

>>> The diagnostic messages Dieter was getting with only patch #2 show
>>> that the pflip interrupt often triggers unnecessarily, potentially
>>> wasting power by waking up the CPU from a power saving state
>>> pointlessly.
>> That's a really good point, but my question would rather be why does
>> the pflip interrupt fires if there isn't any pflip?
> There is a page flip, but it already completes in the vertical blank
> interrupt handler in a lot of (most?) cases.

The issue is still that as far as I understand it when the vblank 
interrupt fires the flip is actually not completed yet.

So we only don't see the pending bit high any more because of the 
minimal time between vblank fires and we check the bit.

The delay between vblank start and the flip being executed seemed to be 
depending on the pixel clock (which makes sense because the CRTC is 
driven by it), so when it might work ok for a 50Hz mode we can still run 
into problems with 24Hz modes.

> Which brings me back to the question: Do we really need the pflip
> interrupt yet? [0] Since flips are no longer programmed to the hardware
> in the vertical blank handler but in a work queue, is there actually
> still any problem with handling the flip completion in the vertical
> blank interrupt handler?

Good question, essentially we need to test with a TV capable of the 24Hz 
modes. I don't have the necessary hardware here and last time was only 
able to test this by torturing my poor HP monitor with a 24Hz modeline 
it actually couldn't handle.

> FWIW, by disabling the radeon_crtc_handle_flip() call from the pflip
> interrupt handler, I no longer seem to be able to reproduce the
> 'impossible msc' lines in the Xorg log file.

Good to know, that narrows down the scenario how this problem is triggered.

> [0] Of course the pflip interrupt will be needed for asynchronous flips,
> but that doesn't mean we have to use it for all flips?
It seemed to be the right thing for the job, but at this time I planned 
to use it exclusively and stop bothering with the vblank interrupt at all.

But then Alex noted that the pflip interrupt might be unreliable on 
older system and so I wanted to use the exiting vblank handling as 
backup. Now I'm not sure any more what's the best approach here.

Regards,
Christian.

[PATCH v2 1/4] drm/tegra: Implement more tiling modes

[Thierry Reding]

On Fri, Jun 27, 2014 at 07:17:24PM +0900, Alexandre Courbot wrote:
> On Fri, Jun 27, 2014 at 5:28 PM, Thierry Reding
>  wrote:
> > From: Thierry Reding 
> >
> > Tegra124 supports a block-linear mode in addition to the regular pitch
> > linear and tiled modes. Add support for these by moving the internal
> > representation into a structure rather than a simple flag.
> 
> Tested-by: Alexandre Courbot 
> 
> For the 4 patches. The first one has a trivial conflict on drm.h when
> applied on today's -next.

That conflict is caused by another patch I have in my tree. I can easily
resolve that when pulling this patch to my drm/tegra/for-next branch.

Thanks for testing!
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140627/cdf6b980/attachment.sig>

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Michel Dänzer]

On 27.06.2014 12:03, Michel D?nzer wrote:
> On 27.06.2014 11:06, Dieter N?tzel wrote:
>> Am 27.06.2014 03:03, schrieb Michel D?nzer:
>>>
>>> The question is, can you reproduce the panic or the 'impossible msc'
>>> lines in the Xorg log with only patch #2?
>>
>> Here we go (the 'new' #2 alone):
>>
>> For the panic I need more time.
>> But the first 'impossible msc' line arise during X start:
>>
>> [80.271] (II) RADEON(0): Modeline "1680x1050"x0.0  119.00  1680 1728
>> 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
>> [80.271] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920
>> 2040 2248 2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
>> [   100.246] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
>> completion event has impossible msc 5302 < target_msc 5303
>>
>> Some arise with KWin cube effects.
> 
> Once you've confirmed patch #2 alone avoids the panic, can you try if
> adding patch #1 again avoids the 'impossible msc' lines as well?

Never mind, I was able to reproduce them with both patches.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Michel Dänzer]

On 27.06.2014 11:06, Dieter N?tzel wrote:
> Am 27.06.2014 03:03, schrieb Michel D?nzer:
>> 
>> The question is, can you reproduce the panic or the 'impossible msc'
>> lines in the Xorg log with only patch #2?
> 
> Here we go (the 'new' #2 alone):
> 
> For the panic I need more time.
> But the first 'impossible msc' line arise during X start:
> 
> [80.271] (II) RADEON(0): Modeline "1680x1050"x0.0  119.00  1680 1728
> 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
> [80.271] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920
> 2040 2248 2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
> [   100.246] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
> completion event has impossible msc 5302 < target_msc 5303
> 
> Some arise with KWin cube effects.

Once you've confirmed patch #2 alone avoids the panic, can you try if
adding patch #1 again avoids the 'impossible msc' lines as well?


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Michel Dänzer]

On 26.06.2014 19:39, Christian K?nig wrote:
> Am 26.06.2014 11:29, schrieb Michel D?nzer:
>> From: Michel D?nzer 
>>
>> Prevents radeon_crtc_handle_flip() from running before
>> radeon_flip_work_func(), resulting in a kernel panic due to the BUG_ON()
>> in drm_vblank_put().
>>
>> Tested-by: Dieter N?tzel 
>> Signed-off-by: Michel D?nzer 
> 
> Does patch #2 alone fixes the problem as well?

It should avoid the panic as well.


> I would rather want to avoid turning the pflip interrupt on and off.

What's the problem with that? It's not like we're saving any register
writes by not doing it.

The diagnostic messages Dieter was getting with only patch #2 show that
the pflip interrupt often triggers unnecessarily, potentially wasting
power by waking up the CPU from a power saving state pointlessly.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH v2] drm/gk20a: add BAR instance

[Ken Adams]

quick note re: tegra and gpu bars...

to this point we've explicitly avoided providing user-mode mappings due to
power management issues, etc.
looks to me like this would allow such mappings.  is that the case?  are
there any paths which would require such mappings to function properly?

thanks
---
ken

p.s.: hello :)

On 6/27/14 7:36 AM, "Alex Courbot"  wrote:

>GK20A's BAR is functionally identical to NVC0's, but do not support
>being ioremapped write-combined. Create a BAR instance for GK20A that
>reflect that state.
>
>Signed-off-by: Alexandre Courbot 
>---
>Changes since v1:
>- Fix compilation warning due to missing cast
>
>Patch 1 of the series was ok and thus has not been resent.
>
> drivers/gpu/drm/nouveau/Makefile  |  1 +
> drivers/gpu/drm/nouveau/core/engine/device/nve0.c |  2 +-
> drivers/gpu/drm/nouveau/core/include/subdev/bar.h |  1 +
> drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c   | 54
>+++
> drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c|  6 +--
> drivers/gpu/drm/nouveau/core/subdev/bar/priv.h|  6 +++
> 6 files changed, 66 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>
>diff --git a/drivers/gpu/drm/nouveau/Makefile
>b/drivers/gpu/drm/nouveau/Makefile
>index 8b307e143632..11d9561d67c1 100644
>--- a/drivers/gpu/drm/nouveau/Makefile
>+++ b/drivers/gpu/drm/nouveau/Makefile
>@@ -26,6 +26,7 @@ nouveau-y += core/core/subdev.o
> nouveau-y += core/subdev/bar/base.o
> nouveau-y += core/subdev/bar/nv50.o
> nouveau-y += core/subdev/bar/nvc0.o
>+nouveau-y += core/subdev/bar/gk20a.o
> nouveau-y += core/subdev/bios/base.o
> nouveau-y += core/subdev/bios/bit.o
> nouveau-y += core/subdev/bios/boost.o
>diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>index 2d1e97d4264f..a2b9ccc48f66 100644
>--- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>+++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
>@@ -165,7 +165,7 @@ nve0_identify(struct nouveau_device *device)
>   device->oclass[NVDEV_SUBDEV_IBUS   ] = _ibus_oclass;
>   device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass;
>   device->oclass[NVDEV_SUBDEV_VM ] = _vmmgr_oclass;
>-  device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
>+  device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
>   device->oclass[NVDEV_ENGINE_DMAOBJ ] = _dmaeng_oclass;
>   device->oclass[NVDEV_ENGINE_FIFO   ] =  gk20a_fifo_oclass;
>   device->oclass[NVDEV_ENGINE_SW ] =  nvc0_software_oclass;
>diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>index 9002cbb6432b..be037fac534c 100644
>--- a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>+++ b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
>@@ -33,5 +33,6 @@ nouveau_bar(void *obj)
> 
> extern struct nouveau_oclass nv50_bar_oclass;
> extern struct nouveau_oclass nvc0_bar_oclass;
>+extern struct nouveau_oclass gk20a_bar_oclass;
> 
> #endif
>diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>new file mode 100644
>index ..bf877af9d3bd
>--- /dev/null
>+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/gk20a.c
>@@ -0,0 +1,54 @@
>+/*
>+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
>+ *
>+ * Permission is hereby granted, free of charge, to any person obtaining
>a
>+ * copy of this software and associated documentation files (the
>"Software"),
>+ * to deal in the Software without restriction, including without
>limitation
>+ * the rights to use, copy, modify, merge, publish, distribute,
>sublicense,
>+ * and/or sell copies of the Software, and to permit persons to whom the
>+ * Software is furnished to do so, subject to the following conditions:
>+ *
>+ * The above copyright notice and this permission notice shall be
>included in
>+ * all copies or substantial portions of the Software.
>+ *
>+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>EXPRESS OR
>+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>MERCHANTABILITY,
>+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
>SHALL
>+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>OTHER
>+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>ARISING
>+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>+ * DEALINGS IN THE SOFTWARE.
>+ */
>+
>+#include 
>+
>+#include "priv.h"
>+
>+int
>+gk20a_bar_ctor(struct nouveau_object *parent, struct nouveau_object
>*engine,
>+ struct nouveau_oclass *oclass, void *data, u32 size,
>+ struct nouveau_object **pobject)
>+{
>+  struct nouveau_bar *bar;
>+  int ret;
>+
>+  ret = nvc0_bar_ctor(parent, engine, oclass, data, size, pobject);
>+  if (ret)
>+  return ret;
>+
>+

[PATCH V3 0/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Mark Rutland]

On Fri, Jun 27, 2014 at 11:24:58AM +0100, Inki Dae wrote:
> 
> + DT mailing list

Thanks for the Cc.

Can we get the rest of the series? Judging a series based on its
diffstat alone is a little hard...

Or is my mailbox filtering hiding the rest of these from me?

Any reason for not Ccing lakml?

Mark.

> On 2014? 06? 27? 19:12, Ajay Kumar wrote:
> > This series is based on exynos-drm-next branch of Inki Dae's tree at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> > 
> > Changes since V2:
> > Add DT property to know the type of FIMD output interface
> > as per Inki's suggestion.
> > Add samsung,output-type DT property in FIMD node for all boards
> > supporting DP interface.
> > 
> > Ajay Kumar (7):
> >   [PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver
> >   [PATCH V3 2/7] ARM: dts: Add FIMD output property for snow
> >   [PATCH V3 3/7] ARM: dts: Add FIMD output property for peach_pit
> >   [PATCH V3 4/7] ARM: dts: Add FIMD output property for peach_pi
> >   [PATCH V3 5/7] ARM: dts: Add FIMD output property for smdk5250
> >   [PATCH V3 6/7] ARM: dts: Add FIMD output property for smdk5420
> >   [PATCH V3 7/7] ARM: dts: Add FIMD output property for arndale
> > 
> >  .../devicetree/bindings/video/samsung-fimd.txt |1 +
> >  arch/arm/boot/dts/exynos5250-arndale.dts   |1 +
> >  arch/arm/boot/dts/exynos5250-smdk5250.dts  |1 +
> >  arch/arm/boot/dts/exynos5250-snow.dts  |1 +
> >  arch/arm/boot/dts/exynos5420-peach-pit.dts |1 +
> >  arch/arm/boot/dts/exynos5420-smdk5420.dts  |1 +
> >  arch/arm/boot/dts/exynos5800-peach-pi.dts  |1 +
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
> > 
> >  include/video/samsung_fimd.h   |4 
> >  9 files changed, 34 insertions(+)
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git

[Ed Tomlinson]

Hi

It seems the follow on message with the panic's as an attachment did not make 
it.  
Here is a link with the jpg:

https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986=108244876431105742323[1]
 

Thanks
Ed

On Friday 27 June 2014 09:17:08 Ed Tomlinson wrote:
> Hi
> 
> Got the following panic runing 16-rc2 + git.  The latest commit was:
> 
> commit d91d66e88ea95b6dd21958834414009614385153
> Merge: 07f4695 6663a4f
> Author: Linus Torvalds 
> Date:   Wed Jun 25 05:44:17 2014 -0700
> 
> I was not doing anything interesting (displaying a photo from facebook with 
> firefox) 
> when this happened.  The distribution is arch at is up to date as of june 
> 26th.
> 
> Thanks
> Ed Tomlinson




[1] 
https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986=108244876431105742323
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140627/911f527d/attachment.html>

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Michel Dänzer]

On 25.06.2014 12:59, Michel D?nzer wrote:
> On 24.06.2014 19:14, Christian K?nig wrote:
>> Am 24.06.2014 08:49, schrieb Michel D?nzer:
>>> On 23.06.2014 18:56, Christian K?nig wrote:
 Am 23.06.2014 10:15, schrieb Michel D?nzer:
> On 19.06.2014 18:45, Christian K?nig wrote:
>
>> I think even when we revert to the old code we have a couple of
>> unsolved
>> problems with the VM support or in the driver in general where we
>> should
>> try to understand the underlying reason for it instead of applying
>> more
>> workarounds.
> I'm not suggesting applying more workarounds but going back to a known
> more stable state. It seems like we've maneuvered ourselves to a rather
> uncomfortable position from there, with no clear way to a better place.
> But if we basically started from the 3.14 state again, we have a few
> known hurdles like mine and Marek's Bonaire etc. which we know any
> further improvements will have to pass before they can be considered
> for
> general consumption.
 Yeah agree, especially on the uncomfortable position.

 Please try with the two attached patches applied on top of 3.15 and
 retest. They should revert back to the old implementation.
>>> Unfortunately, X fails to start with these, see the attached excerpt
>>> from dmesg.
>>
>> My fault, incorrectly solved a merge conflict and then failed to test
>> the right kernel.
>>
>> [...]
>> 
>> Please try attached patches instead,
> 
> With these patches, 3.15 just survived two piglit runs on my Bonaire,
> one with the GART poisoning fix and one without. It never survived a
> single run before.
> 
> Acked-and-Tested-by: Michel D?nzer 

So, are these patches going to 3.16 and 3.15?


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH v2 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

[Stéphane Marchesin]

On Fri, Jun 27, 2014 at 1:28 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flags of a
> buffer object after it has been allocated or imported. Flags associated
> with a buffer object can be queried using the DRM_TEGRA_GEM_GET_FLAGS
> IOCTL.
>
> Signed-off-by: Thierry Reding 

Reviewed-by: St?phane Marchesin 

> ---
> Changes in v2:
> - use -ENOENT if no GEM object is found
>
>  drivers/gpu/drm/tegra/drm.c  | 49 
> 
>  include/uapi/drm/tegra_drm.h | 21 +++
>  2 files changed, 70 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index a029525b598f..6e2e714a0649 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -548,6 +548,53 @@ static int tegra_gem_get_tiling(struct drm_device *drm, 
> void *data,
>
> return err;
>  }
> +
> +static int tegra_gem_set_flags(struct drm_device *drm, void *data,
> +  struct drm_file *file)
> +{
> +   struct drm_tegra_gem_set_flags *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +
> +   if (args->flags & ~DRM_TEGRA_GEM_FLAGS)
> +   return -EINVAL;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +   bo->flags = 0;
> +
> +   if (args->flags & DRM_TEGRA_GEM_BOTTOM_UP)
> +   bo->flags |= TEGRA_BO_BOTTOM_UP;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
> +
> +static int tegra_gem_get_flags(struct drm_device *drm, void *data,
> +  struct drm_file *file)
> +{
> +   struct drm_tegra_gem_get_flags *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +   args->flags = 0;
> +
> +   if (bo->flags & TEGRA_BO_BOTTOM_UP)
> +   args->flags |= DRM_TEGRA_GEM_BOTTOM_UP;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
>  #endif
>
>  static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> @@ -564,6 +611,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
> DRM_UNLOCKED),
>  #endif
>  };
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index 0829f75eb986..c15d781ecc0f 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -150,6 +150,23 @@ struct drm_tegra_gem_get_tiling {
> __u32 pad;
>  };
>
> +#define DRM_TEGRA_GEM_BOTTOM_UP(1 << 0)
> +#define DRM_TEGRA_GEM_FLAGS(DRM_TEGRA_GEM_BOTTOM_UP)
> +
> +struct drm_tegra_gem_set_flags {
> +   /* input */
> +   __u32 handle;
> +   /* output */
> +   __u32 flags;
> +};
> +
> +struct drm_tegra_gem_get_flags {
> +   /* input */
> +   __u32 handle;
> +   /* output */
> +   __u32 flags;
> +};
> +
>  #define DRM_TEGRA_GEM_CREATE   0x00
>  #define DRM_TEGRA_GEM_MMAP 0x01
>  #define DRM_TEGRA_SYNCPT_READ  0x02
> @@ -162,6 +179,8 @@ struct drm_tegra_gem_get_tiling {
>  #define DRM_TEGRA_GET_SYNCPT_BASE  0x09
>  #define DRM_TEGRA_GEM_SET_TILING   0x0a
>  #define DRM_TEGRA_GEM_GET_TILING   0x0b
> +#define DRM_TEGRA_GEM_SET_FLAGS0x0c
> +#define DRM_TEGRA_GEM_GET_FLAGS0x0d
>
>  #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
>  #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
> @@ -175,5 +194,7 @@ struct drm_tegra_gem_get_tiling {
>  #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base)
>  #define DRM_IOCTL_TEGRA_GEM_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_SET_TILING, struct drm_tegra_gem_set_tiling)
>  #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
> +#define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
> +#define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)
>
>  #endif
> --
> 

[PATCH v2 2/4] drm/tegra: Add SET/GET_TILING IOCTLs

[Stéphane Marchesin]

On Fri, Jun 27, 2014 at 1:28 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Currently the tiling parameters of buffer objects can only be set at
> allocation time, and only a single tiled mode is supported. This new
> DRM_TEGRA_GEM_SET_TILING IOCTL allows more modes to be set and also
> allows the tiling mode to be changed after the allocation. This will
> enable the Tegra DRM driver to import buffers from a GPU and directly
> scan them out by configuring the display controller appropriately.
>
> To complement this, the DRM_TEGRA_GEM_GET_TILING IOCTL can query the
> current tiling mode of a buffer object. This is necessary when importing
> buffers via handle (as is done in Mesa for example) so that userspace
> can determine the proper parameters for the 2D or 3D engines.
>
> Signed-off-by: Thierry Reding 

Reviewed-by: St?phane Marchesin 

> ---
> Changes in v2:
> - use -ENOENT if no GEM object is found
>
>  drivers/gpu/drm/tegra/drm.c  | 95 
> 
>  include/uapi/drm/tegra_drm.h | 25 
>  2 files changed, 120 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index fd736efd14bd..a029525b598f 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -455,6 +455,99 @@ static int tegra_get_syncpt_base(struct drm_device *drm, 
> void *data,
>
> return 0;
>  }
> +
> +static int tegra_gem_set_tiling(struct drm_device *drm, void *data,
> +   struct drm_file *file)
> +{
> +   struct drm_tegra_gem_set_tiling *args = data;
> +   enum tegra_bo_tiling_mode mode;
> +   struct drm_gem_object *gem;
> +   unsigned long value = 0;
> +   struct tegra_bo *bo;
> +
> +   switch (args->mode) {
> +   case DRM_TEGRA_GEM_TILING_MODE_PITCH:
> +   mode = TEGRA_BO_TILING_MODE_PITCH;
> +
> +   if (args->value != 0)
> +   return -EINVAL;
> +
> +   break;
> +
> +   case DRM_TEGRA_GEM_TILING_MODE_TILED:
> +   mode = TEGRA_BO_TILING_MODE_TILED;
> +
> +   if (args->value != 0)
> +   return -EINVAL;
> +
> +   break;
> +
> +   case DRM_TEGRA_GEM_TILING_MODE_BLOCK:
> +   mode = TEGRA_BO_TILING_MODE_BLOCK;
> +
> +   if (args->value > 5)
> +   return -EINVAL;
> +
> +   value = args->value;
> +   break;
> +
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +
> +   bo->tiling.mode = mode;
> +   bo->tiling.value = value;
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
> +
> +static int tegra_gem_get_tiling(struct drm_device *drm, void *data,
> +   struct drm_file *file)
> +{
> +   struct drm_tegra_gem_get_tiling *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +   int err = 0;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -ENOENT;
> +
> +   bo = to_tegra_bo(gem);
> +
> +   switch (bo->tiling.mode) {
> +   case TEGRA_BO_TILING_MODE_PITCH:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_PITCH;
> +   args->value = 0;
> +   break;
> +
> +   case TEGRA_BO_TILING_MODE_TILED:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_TILED;
> +   args->value = 0;
> +   break;
> +
> +   case TEGRA_BO_TILING_MODE_BLOCK:
> +   args->mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
> +   args->value = bo->tiling.value;
> +   break;
> +
> +   default:
> +   err = -EINVAL;
> +   break;
> +   }
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return err;
> +}
>  #endif
>
>  static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> @@ -469,6 +562,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT, tegra_get_syncpt, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_SUBMIT, tegra_submit, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
> DRM_UNLOCKED),
>  #endif
>  };
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index b75482112428..0829f75eb986 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -129,6 +129,27 @@ struct drm_tegra_submit {
> __u32 reserved[5];  /* future expansion */
>  };
>
> +#define DRM_TEGRA_GEM_TILING_MODE_PITCH 0
> +#define 

[PATCH] drm: Change link order to load modules first

[Ezequiel Garcia]

On 27 Jun 07:14 AM, Thierry Reding wrote:
> On Mon, Jun 23, 2014 at 12:29:09PM -0300, Ezequiel Garcia wrote:
> > > 
> > > No. We don't need to change the link order.
> > 
> > Could you clarify why? I guess you have some case in mind where changing
> > the link order breaks things or makes something mis-behave.
> 
> I said we don't need to change the link order because there is a better
> mechanism in the kernel to handle this type of situation. Saying "we
> need to change" makes it sound like there's a bug that needs to be fixed
> by changing the link order. That's not so. If link order breaks some
> drivers then its those drivers that are broken.
> 

Ah, OK. I understand your point now. On a second read, my commit log isn't
too clear explaining why I want to change the order.

> > > What we need to do is make
> > > sure that modules deal properly with situations where their resources
> > > aren't available yet (i.e. EPROBE_DEFER). There are factors other than
> > > link order that influence probe ordering.
> > > 
> > 
> > While I understand defering is more robust, it would be systematically
> > defering the probe when the DRM driver needs an I2C encoder.
> > 
> > Just to name one example, the tilcdc, armada and others requiring TDA998x
> > encoder will always defered the probe of the DRM, and then re-probe() once
> > the encoder is ready.
> > 
> > So, unless we have a good reason not to do this, it sounds a bit silly
> > to me.
> 
> The problem that I have with working around this issue by changing the
> link order is that it hides bugs in drivers. It's not like probe
> deferral is a very expensive operation, so I very much prefer this as a
> way of forcing drivers to be fixed rather than optimizing for a few
> microseconds of boot time.
> 

That's true. However, in this particular case, I'm not worried about the
extra microseconds wasted in the defered operation, but about the unneeded
delay introduced in the DRM probe.

I know that relying in some particular order is very fragile, but I don't
agree with knowingly and even explicitly have a sub-optimal order of the
drivers.

Or maybe it's just that I dislike deferals a lot.

Anyway, thanks for feedback.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH v2 4/4] drm/tegra: Allow non-authenticated processes to create buffer objects

[Thierry Reding]

From: Thierry Reding 

This matches what other drivers do for equivalent IOCTLs.

Reviewed-by: St?phane Marchesin 
Signed-off-by: Thierry Reding 
---
Changes in v2:
- none

 drivers/gpu/drm/tegra/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 6e2e714a0649..5cba5e736130 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -599,7 +599,7 @@ static int tegra_gem_get_flags(struct drm_device *drm, void 
*data,

 static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
 #ifdef CONFIG_DRM_TEGRA_STAGING
-   DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create, DRM_UNLOCKED | 
DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_gem_mmap, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_READ, tegra_syncpt_read, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_INCR, tegra_syncpt_incr, DRM_UNLOCKED),
-- 
2.0.0

[PATCH v2 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

[Thierry Reding]

From: Thierry Reding 

The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flags of a
buffer object after it has been allocated or imported. Flags associated
with a buffer object can be queried using the DRM_TEGRA_GEM_GET_FLAGS
IOCTL.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- use -ENOENT if no GEM object is found

 drivers/gpu/drm/tegra/drm.c  | 49 
 include/uapi/drm/tegra_drm.h | 21 +++
 2 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index a029525b598f..6e2e714a0649 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -548,6 +548,53 @@ static int tegra_gem_get_tiling(struct drm_device *drm, 
void *data,

return err;
 }
+
+static int tegra_gem_set_flags(struct drm_device *drm, void *data,
+  struct drm_file *file)
+{
+   struct drm_tegra_gem_set_flags *args = data;
+   struct drm_gem_object *gem;
+   struct tegra_bo *bo;
+
+   if (args->flags & ~DRM_TEGRA_GEM_FLAGS)
+   return -EINVAL;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -ENOENT;
+
+   bo = to_tegra_bo(gem);
+   bo->flags = 0;
+
+   if (args->flags & DRM_TEGRA_GEM_BOTTOM_UP)
+   bo->flags |= TEGRA_BO_BOTTOM_UP;
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
+
+static int tegra_gem_get_flags(struct drm_device *drm, void *data,
+  struct drm_file *file)
+{
+   struct drm_tegra_gem_get_flags *args = data;
+   struct drm_gem_object *gem;
+   struct tegra_bo *bo;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -ENOENT;
+
+   bo = to_tegra_bo(gem);
+   args->flags = 0;
+
+   if (bo->flags & TEGRA_BO_BOTTOM_UP)
+   args->flags |= DRM_TEGRA_GEM_BOTTOM_UP;
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
 #endif

 static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
@@ -564,6 +611,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
DRM_UNLOCKED),
 #endif
 };

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 0829f75eb986..c15d781ecc0f 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -150,6 +150,23 @@ struct drm_tegra_gem_get_tiling {
__u32 pad;
 };

+#define DRM_TEGRA_GEM_BOTTOM_UP(1 << 0)
+#define DRM_TEGRA_GEM_FLAGS(DRM_TEGRA_GEM_BOTTOM_UP)
+
+struct drm_tegra_gem_set_flags {
+   /* input */
+   __u32 handle;
+   /* output */
+   __u32 flags;
+};
+
+struct drm_tegra_gem_get_flags {
+   /* input */
+   __u32 handle;
+   /* output */
+   __u32 flags;
+};
+
 #define DRM_TEGRA_GEM_CREATE   0x00
 #define DRM_TEGRA_GEM_MMAP 0x01
 #define DRM_TEGRA_SYNCPT_READ  0x02
@@ -162,6 +179,8 @@ struct drm_tegra_gem_get_tiling {
 #define DRM_TEGRA_GET_SYNCPT_BASE  0x09
 #define DRM_TEGRA_GEM_SET_TILING   0x0a
 #define DRM_TEGRA_GEM_GET_TILING   0x0b
+#define DRM_TEGRA_GEM_SET_FLAGS0x0c
+#define DRM_TEGRA_GEM_GET_FLAGS0x0d

 #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
 #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
@@ -175,5 +194,7 @@ struct drm_tegra_gem_get_tiling {
 #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base)
 #define DRM_IOCTL_TEGRA_GEM_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_SET_TILING, struct drm_tegra_gem_set_tiling)
 #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
+#define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
+#define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)

 #endif
-- 
2.0.0

[PATCH v2 2/4] drm/tegra: Add SET/GET_TILING IOCTLs

[Thierry Reding]

From: Thierry Reding 

Currently the tiling parameters of buffer objects can only be set at
allocation time, and only a single tiled mode is supported. This new
DRM_TEGRA_GEM_SET_TILING IOCTL allows more modes to be set and also
allows the tiling mode to be changed after the allocation. This will
enable the Tegra DRM driver to import buffers from a GPU and directly
scan them out by configuring the display controller appropriately.

To complement this, the DRM_TEGRA_GEM_GET_TILING IOCTL can query the
current tiling mode of a buffer object. This is necessary when importing
buffers via handle (as is done in Mesa for example) so that userspace
can determine the proper parameters for the 2D or 3D engines.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- use -ENOENT if no GEM object is found

 drivers/gpu/drm/tegra/drm.c  | 95 
 include/uapi/drm/tegra_drm.h | 25 
 2 files changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index fd736efd14bd..a029525b598f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -455,6 +455,99 @@ static int tegra_get_syncpt_base(struct drm_device *drm, 
void *data,

return 0;
 }
+
+static int tegra_gem_set_tiling(struct drm_device *drm, void *data,
+   struct drm_file *file)
+{
+   struct drm_tegra_gem_set_tiling *args = data;
+   enum tegra_bo_tiling_mode mode;
+   struct drm_gem_object *gem;
+   unsigned long value = 0;
+   struct tegra_bo *bo;
+
+   switch (args->mode) {
+   case DRM_TEGRA_GEM_TILING_MODE_PITCH:
+   mode = TEGRA_BO_TILING_MODE_PITCH;
+
+   if (args->value != 0)
+   return -EINVAL;
+
+   break;
+
+   case DRM_TEGRA_GEM_TILING_MODE_TILED:
+   mode = TEGRA_BO_TILING_MODE_TILED;
+
+   if (args->value != 0)
+   return -EINVAL;
+
+   break;
+
+   case DRM_TEGRA_GEM_TILING_MODE_BLOCK:
+   mode = TEGRA_BO_TILING_MODE_BLOCK;
+
+   if (args->value > 5)
+   return -EINVAL;
+
+   value = args->value;
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -ENOENT;
+
+   bo = to_tegra_bo(gem);
+
+   bo->tiling.mode = mode;
+   bo->tiling.value = value;
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
+
+static int tegra_gem_get_tiling(struct drm_device *drm, void *data,
+   struct drm_file *file)
+{
+   struct drm_tegra_gem_get_tiling *args = data;
+   struct drm_gem_object *gem;
+   struct tegra_bo *bo;
+   int err = 0;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -ENOENT;
+
+   bo = to_tegra_bo(gem);
+
+   switch (bo->tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   args->mode = DRM_TEGRA_GEM_TILING_MODE_PITCH;
+   args->value = 0;
+   break;
+
+   case TEGRA_BO_TILING_MODE_TILED:
+   args->mode = DRM_TEGRA_GEM_TILING_MODE_TILED;
+   args->value = 0;
+   break;
+
+   case TEGRA_BO_TILING_MODE_BLOCK:
+   args->mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
+   args->value = bo->tiling.value;
+   break;
+
+   default:
+   err = -EINVAL;
+   break;
+   }
+
+   drm_gem_object_unreference(gem);
+
+   return err;
+}
 #endif

 static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
@@ -469,6 +562,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT, tegra_get_syncpt, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_SUBMIT, tegra_submit, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
DRM_UNLOCKED),
 #endif
 };

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index b75482112428..0829f75eb986 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -129,6 +129,27 @@ struct drm_tegra_submit {
__u32 reserved[5];  /* future expansion */
 };

+#define DRM_TEGRA_GEM_TILING_MODE_PITCH 0
+#define DRM_TEGRA_GEM_TILING_MODE_TILED 1
+#define DRM_TEGRA_GEM_TILING_MODE_BLOCK 2
+
+struct drm_tegra_gem_set_tiling {
+   /* input */
+   __u32 handle;
+   __u32 mode;
+   __u32 value;
+   __u32 pad;
+};
+
+struct drm_tegra_gem_get_tiling {
+   /* input */
+   __u32 handle;
+   /* output */
+   __u32 mode;
+   __u32 value;
+   

[PATCH v2 1/4] drm/tegra: Implement more tiling modes

[Thierry Reding]

From: Thierry Reding 

Tegra124 supports a block-linear mode in addition to the regular pitch
linear and tiled modes. Add support for these by moving the internal
representation into a structure rather than a simple flag.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- none

 drivers/gpu/drm/tegra/dc.c  | 102 +---
 drivers/gpu/drm/tegra/dc.h  |   5 +++
 drivers/gpu/drm/tegra/drm.h |   8 +++-
 drivers/gpu/drm/tegra/fb.c  |   9 ++--
 drivers/gpu/drm/tegra/gem.c |   2 +-
 drivers/gpu/drm/tegra/gem.h |  16 ++-
 6 files changed, 118 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index ef40381f3909..afcca04f5367 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -18,6 +18,7 @@
 struct tegra_dc_soc_info {
bool supports_interlacing;
bool supports_cursor;
+   bool supports_block_linear;
 };

 struct tegra_plane {
@@ -212,15 +213,44 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
tegra_dc_writel(dc, h_offset, DC_WINBUF_ADDR_H_OFFSET);
tegra_dc_writel(dc, v_offset, DC_WINBUF_ADDR_V_OFFSET);

-   if (window->tiled) {
-   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
-   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   if (dc->soc->supports_block_linear) {
+   unsigned long height = window->tiling.value;
+
+   switch (window->tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   value = DC_WINBUF_SURFACE_KIND_PITCH;
+   break;
+
+   case TEGRA_BO_TILING_MODE_TILED:
+   value = DC_WINBUF_SURFACE_KIND_TILED;
+   break;
+
+   case TEGRA_BO_TILING_MODE_BLOCK:
+   value = DC_WINBUF_SURFACE_KIND_BLOCK_HEIGHT(height) |
+   DC_WINBUF_SURFACE_KIND_BLOCK;
+   break;
+   }
+
+   tegra_dc_writel(dc, value, DC_WINBUF_SURFACE_KIND);
} else {
-   value = DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV |
-   DC_WIN_BUFFER_ADDR_MODE_LINEAR;
-   }
+   switch (window->tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   value = DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV |
+   DC_WIN_BUFFER_ADDR_MODE_LINEAR;
+   break;

-   tegra_dc_writel(dc, value, DC_WIN_BUFFER_ADDR_MODE);
+   case TEGRA_BO_TILING_MODE_TILED:
+   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
+   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   break;
+
+   case TEGRA_BO_TILING_MODE_BLOCK:
+   DRM_ERROR("hardware doesn't support block linear 
mode\n");
+   return -EINVAL;
+   }
+
+   tegra_dc_writel(dc, value, DC_WIN_BUFFER_ADDR_MODE);
+   }

value = WIN_ENABLE;

@@ -288,6 +318,7 @@ static int tegra_plane_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
struct tegra_dc *dc = to_tegra_dc(crtc);
struct tegra_dc_window window;
unsigned int i;
+   int err;

memset(, 0, sizeof(window));
window.src.x = src_x >> 16;
@@ -301,7 +332,10 @@ static int tegra_plane_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
window.format = tegra_dc_format(fb->pixel_format, );
window.bits_per_pixel = fb->bits_per_pixel;
window.bottom_up = tegra_fb_is_bottom_up(fb);
-   window.tiled = tegra_fb_is_tiled(fb);
+
+   err = tegra_fb_get_tiling(fb, );
+   if (err < 0)
+   return err;

for (i = 0; i < drm_format_num_planes(fb->pixel_format); i++) {
struct tegra_bo *bo = tegra_fb_get_plane(fb, i);
@@ -402,8 +436,14 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
 {
struct tegra_bo *bo = tegra_fb_get_plane(fb, 0);
unsigned int h_offset = 0, v_offset = 0;
+   struct tegra_bo_tiling tiling;
unsigned int format, swap;
unsigned long value;
+   int err;
+
+   err = tegra_fb_get_tiling(fb, );
+   if (err < 0)
+   return err;

tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);

@@ -417,15 +457,44 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
tegra_dc_writel(dc, format, DC_WIN_COLOR_DEPTH);
tegra_dc_writel(dc, swap, DC_WIN_BYTE_SWAP);

-   if (tegra_fb_is_tiled(fb)) {
-   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
-   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   if (dc->soc->supports_block_linear) {
+   unsigned long height = tiling.value;
+
+   switch (tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   value = 

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Christian König]

Am 27.06.2014 04:31, schrieb Michel D?nzer:
> On 25.06.2014 12:59, Michel D?nzer wrote:
>> On 24.06.2014 19:14, Christian K?nig wrote:
>>> Am 24.06.2014 08:49, schrieb Michel D?nzer:
 On 23.06.2014 18:56, Christian K?nig wrote:
> Am 23.06.2014 10:15, schrieb Michel D?nzer:
>> On 19.06.2014 18:45, Christian K?nig wrote:
>>
>>> I think even when we revert to the old code we have a couple of
>>> unsolved
>>> problems with the VM support or in the driver in general where we
>>> should
>>> try to understand the underlying reason for it instead of applying
>>> more
>>> workarounds.
>> I'm not suggesting applying more workarounds but going back to a known
>> more stable state. It seems like we've maneuvered ourselves to a rather
>> uncomfortable position from there, with no clear way to a better place.
>> But if we basically started from the 3.14 state again, we have a few
>> known hurdles like mine and Marek's Bonaire etc. which we know any
>> further improvements will have to pass before they can be considered
>> for
>> general consumption.
> Yeah agree, especially on the uncomfortable position.
>
> Please try with the two attached patches applied on top of 3.15 and
> retest. They should revert back to the old implementation.
 Unfortunately, X fails to start with these, see the attached excerpt
 from dmesg.
>>> My fault, incorrectly solved a merge conflict and then failed to test
>>> the right kernel.
>>>
>>> [...]
>>>
>>> Please try attached patches instead,
>> With these patches, 3.15 just survived two piglit runs on my Bonaire,
>> one with the GART poisoning fix and one without. It never survived a
>> single run before.
>>
>> Acked-and-Tested-by: Michel D?nzer 
> So, are these patches going to 3.16 and 3.15?

We could send them in for 3.15, but for 3.16 we have some new features 
that depend on the new code.

We could backport them to the old code, but I really want to work on 
figuring out what's wrong with the new approach instead.

Going to prepare a branch for you to test over the weekend, would be 
nice if you could give it a try on Monday and see if that fixes the 
issues as well.

Thanks,
Christian.

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #17 from theamazingjanet at googlemail.com ---
>Thanks, but this doesn't have anything about a GPU lockup or anything like 
>that.

I looked through it and figured as much but attached anyway as maybe I just
wasn't looking for the right thing. It's the output given when the game locked
up the display, so I don't know what else to do besides apitrace.

-- 
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/20140627/dddbeadc/attachment.html>

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Christian König]

Am 27.06.2014 04:58, schrieb Michel D?nzer:
> On 26.06.2014 19:39, Christian K?nig wrote:
>> Am 26.06.2014 11:29, schrieb Michel D?nzer:
>>> From: Michel D?nzer 
>>>
>>> Prevents radeon_crtc_handle_flip() from running before
>>> radeon_flip_work_func(), resulting in a kernel panic due to the BUG_ON()
>>> in drm_vblank_put().
>>>
>>> Tested-by: Dieter N?tzel 
>>> Signed-off-by: Michel D?nzer 
>> Does patch #2 alone fixes the problem as well?
> It should avoid the panic as well.
>
>
>> I would rather want to avoid turning the pflip interrupt on and off.
> What's the problem with that? It's not like we're saving any register
> writes by not doing it.

We don't? As far as I can see we reprogram all interrupt registers if 
any of the interrupts changed, this has already lead to quite some 
additional overhead in the fence waiting code.

>
> The diagnostic messages Dieter was getting with only patch #2 show that
> the pflip interrupt often triggers unnecessarily, potentially wasting
> power by waking up the CPU from a power saving state pointlessly.
That's a really good point, but my question would rather be why does the 
pflip interrupt fires if there isn't any pflip?

Turning the vblank and other interrupts off makes sense because they 
fire anyway, but pflip should only fire if we really made a request for 
it to do so.

Regards,
Christian.

[PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver

[Jingoo Han]

On Thursday, June 26, 2014 11:37 PM, Ajay Kumar wrote:
> 
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
> 
> Signed-off-by: Ajay Kumar 

It looks better than V1 patch.

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> Changes since V1:
>  - Remove usage of driver_data to configure DP CLKCON register
>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 2 ++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  | 8 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
>  include/video/samsung_fimd.h | 4 
>  4 files changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 2e77a15..d8868f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
> 
>   platform_set_drvdata(pdev, _dp_display);
> 
> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
> +
>   return exynos_drm_create_enc_conn(drm_dev, _dp_display);
>  }
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 36535f3..1089744 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
>   EXYNOS_DISPLAY_TYPE_VIDI,
>  };
> 
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_MIPI,
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DP,
> +};
> +
>  /*
>   * Exynos drm common overlay structure.
>   *
> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
>  extern struct platform_driver rotator_driver;
>  extern struct platform_driver gsc_driver;
>  extern struct platform_driver ipp_driver;
> +
> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
>  #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bb45ab2..a46a9c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .has_shadowcon = 1,
>  };
> 
> +enum exynos_fimd_output_type exynos_fimd_output_type;
> +
>  struct fimd_win_data {
>   unsigned intoffset_x;
>   unsigned intoffset_y;
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
> 
> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
>   writel(val, ctx->regs + VIDCON0);
>  }
> 
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
> 
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 4
> --
> 1.8.3.2

[PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed

[Michel Dänzer]

On 27.06.2014 09:53, Dieter N?tzel wrote:
> Am 26.06.2014 12:39, schrieb Christian K?nig:
>> Am 26.06.2014 11:29, schrieb Michel D?nzer:
>>> From: Michel D?nzer 
>>>
>>> Prevents radeon_crtc_handle_flip() from running before
>>> radeon_flip_work_func(), resulting in a kernel panic due to the BUG_ON()
>>> in drm_vblank_put().
>>>
>>> Tested-by: Dieter N?tzel 
>>> Signed-off-by: Michel D?nzer 
>>
>> Does patch #2 alone fixes the problem as well?
> 
> With #2 alone I get this during boot up (before plymouth):

[...]

> [   15.259867] [drm:radeon_crtc_handle_flip] *ERROR*
> radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2)

That's the original patch I sent to you along with two others for
testing. The patch I submitted in this series has these messages
downgraded to debugging messages, as they just show the patch preventing
bad stuff from happening as designed.

The question is, can you reproduce the panic or the 'impossible msc'
lines in the Xorg log with only patch #2?


> But with Michel's #1+2 and 3 I got this in Xorg.0.log:
> (See Xorg.0.log.old.xz)
> 
> (EE) [mi] EQ overflowing.  Additional events will be discarded until
> existing events are processed.

That may not be directly related to the page flipping issues.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[Bug 76998] hang on CEDAR right after log on

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

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

--- Comment #5 from tcl_de at gmx.net ---
The result of the bisect is
d4788db30a1a66255b592dd12613dda80c1443f7 is the first bad commit
commit d4788db30a1a66255b592dd12613dda80c1443f7
Author: Alex Deucher
Date:   Thu Feb 28 14:40:09 2013 -0500

drm/radeon/evergreen: add support for golden register init

Signed-off-by: Alex Deucher

-- 
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/20140627/0b766b23/attachment.html>

[PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver

[Andreas Färber]

Am 26.06.2014 16:36, schrieb Ajay Kumar:
> Add the missing setting for DP CLKCON register.
> 
> This register is present on Exynos5 based FIMD controllers,
> and needs to be used if we are using DP.
> 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>  - Remove usage of driver_data to configure DP CLKCON register
>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 2 ++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  | 8 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
>  include/video/samsung_fimd.h | 4 
>  4 files changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 2e77a15..d8868f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>  
>   platform_set_drvdata(pdev, _dp_display);
>  
> + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
> +
>   return exynos_drm_create_enc_conn(drm_dev, _dp_display);
>  }
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 36535f3..1089744 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
>   EXYNOS_DISPLAY_TYPE_VIDI,
>  };
>  
> +enum exynos_fimd_output_type {
> + EXYNOS_FIMD_OUTPUT_MIPI,
> + EXYNOS_FIMD_OUTPUT_DPI,
> + EXYNOS_FIMD_OUTPUT_DP,
> +};
> +
>  /*
>   * Exynos drm common overlay structure.
>   *
> @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
>  extern struct platform_driver rotator_driver;
>  extern struct platform_driver gsc_driver;
>  extern struct platform_driver ipp_driver;
> +
> +extern enum exynos_fimd_output_type exynos_fimd_output_type;
>  #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bb45ab2..a46a9c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
>   .has_shadowcon = 1,
>  };
>  
> +enum exynos_fimd_output_type exynos_fimd_output_type;

This is a non-static variable - doesn't that mean it's only ever
initialized to DP above and uninitialized in C99 otherwise? Unless I'm
missing something, the if below may trigger at random.

Regards,
Andreas

> +
>  struct fimd_win_data {
>   unsigned intoffset_x;
>   unsigned intoffset_y;
> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>   if (clkdiv > 1)
>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>  
> + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> +
>   writel(val, ctx->regs + VIDCON0);
>  }
>  
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b039320..d8f4b0b 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -435,6 +435,10 @@
>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
>  
> +/* Video clock enable for DP */
> +#define DP_CLKCON0x27C
> +#define DP_CLK_ENABLE0x2
> +
>  /* Notes on per-window bpp settings
>   *
>   * Value Win0 Win1 Win2 Win3 Win 4

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git

[Ed Tomlinson]

Hi

Got the following panic runing 16-rc2 + git.  The latest commit was:

commit d91d66e88ea95b6dd21958834414009614385153
Merge: 07f4695 6663a4f
Author: Linus Torvalds 
Date:   Wed Jun 25 05:44:17 2014 -0700

I was not doing anything interesting (displaying a photo from facebook with 
firefox) 
when this happened.  The distribution is arch at is up to date as of june 26th.

Thanks
Ed Tomlinson

[Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

[Steve Aarnio]

On 06/11/2014 08:41 AM, Jesse Barnes wrote:
> On Wed, 11 Jun 2014 17:39:29 +0200
> Daniel Vetter  wrote:
>
>> On Wed, Jun 11, 2014 at 5:13 PM, Jesse Barnes  
>> wrote:
 - If you have a machine which uses tiled framebuffers and enables
swizzling in the BIOS your code will a) drop the swizzle setup in
gem_init_hw, breaking resume b) not set the swizzle settings correctly
in swizzle_detect, breaking swap in/out and pwrite/pread. Not sure such
a machine exists, but still.
>>>
>>> This would affect krh's MBA, which is why I wanted testing here...
>>> anyway I'll spin a new one and ask krh to test again.
>>
>> Hm, I've thought the issue with the MBA is that it used tiled fbs, but
>> non-swizzled. And then a mess ensued when we've enabled it. But yeah,
>> unfortunately with the new logic we need to retest :(
>
> Ah yeah I think you're right, either way, need more testing.
>
> Maybe we should have just gone with the first patch to never enable
> swizzling based on Art's assertion that it didn't matter.
>

I hate to jump into the middle of a conversation that may or may not be related 
to a patch I just posted... but...

There was a very long internal discussion that the Windows guys had with H/W. 
For Gen8+ H/W recommends disabling CSX swizzle.  Technically, BDW still 
supports 
it, but there is a bug _somewhere_ that makes it problematic.  In any case it 
goes away for sure with Gen9+, so disabling on Gen8 doesn't hurt.

According to the other discussion, the H/W guys say that enabling actually 
hurts 
performance slightly, and the driver should leave the swizzle decisions to the 
memory controller.

Stevo

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #16 from Michel D?nzer  ---
(In reply to comment #15)
> SSH'd and tried dmesg like you said and attached.

Thanks, but this doesn't have anything about a GPU lockup or anything like
that.

-- 
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/20140627/6774b9ef/attachment.html>

[Bug 80584] XCOM: Eenemy Unknown incorrect hair rendering

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

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

theamazingjanet at googlemail.com changed:

   What|Removed |Added

 Attachment #101847|0   |1
is obsolete||

--- Comment #3 from theamazingjanet at googlemail.com ---
Created attachment 101849
  --> https://bugs.freedesktop.org/attachment.cgi?id=101849=edit
XCOM: Enemy Unknown Screenshot 2

-- 
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/20140627/3f6cb4aa/attachment.html>

[Bug 80584] XCOM: Eenemy Unknown incorrect hair rendering

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

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

theamazingjanet at googlemail.com changed:

   What|Removed |Added

 Attachment #101846|0   |1
is obsolete||

--- Comment #2 from theamazingjanet at googlemail.com ---
Created attachment 101848
  --> https://bugs.freedesktop.org/attachment.cgi?id=101848=edit
XCOM: Enemy Unknown Screenshot 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/20140627/9a6678bf/attachment.html>

[Bug 80584] XCOM: Eenemy Unknown incorrect hair rendering

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

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

--- Comment #1 from theamazingjanet at googlemail.com ---
Created attachment 101847
  --> https://bugs.freedesktop.org/attachment.cgi?id=101847=edit
XCOM: Enemy Unknown Screenshot 2

-- 
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/20140627/0cc04543/attachment.html>

[Bug 80584] New: XCOM: Eenemy Unknown incorrect hair rendering

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

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

  Priority: medium
Bug ID: 80584
  Assignee: dri-devel at lists.freedesktop.org
   Summary: XCOM: Eenemy Unknown incorrect hair rendering
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: theamazingjanet at googlemail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 101846
  --> https://bugs.freedesktop.org/attachment.cgi?id=101846=edit
XCOM: Enemy Unknown Screenshot 1

Hair on certain characters in XCOM: Enemy Unknown does not look correct. See
the attached screenshots. This occurs on both Mesa 10.1.3 + LLVM 3.4 and Mesa
git + LLVM 3.4.2 via Oibaf PPA, Ubuntu 14.04.

-- 
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/20140627/f3c68856/attachment.html>

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

On Fri, Jun 27, 2014 at 1:10 AM, Russell King - ARM Linux
 wrote:
> On Thu, Jun 26, 2014 at 11:53:20PM +0900, Alexandre Courbot wrote:
>> We don't plan to rely on CMA for too long. IOMMU support is on the way
>> and should make our life easier, although no matter the source of
>> memory, we will still have the issue of the lowmem mappings.
>
> When it comes to DMA memory, talking about lowmem vs highmem is utterly
> meaningless.
>
> The lowmem/highmem split is entirely a software concept and is completely
> adjustable.  An extreme example is that you can boot any platform with
> more than 32MB of memory with 32MB of lowmem and the remainder as
> highmem.

True, but isn't it also the case that all lowmem is already mapped in
the kernel address space, and that re-mapping this memory with
different cache settings (e.g. by creating a WC mapping for user-space
to write into) is undefined on ARM and must be avoided? That is the
issue I was referring to.

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #15 from theamazingjanet at googlemail.com ---
SSH'd and tried dmesg like you said and attached. I've been trying apitrace but
the game depends on Steam and uses a seperate launcher to start the game and
can't figure out how to get a proper trace becaue of it. Launching what looks
like the game binary directly (game.x86_64) and it still brings up the
launcher.

Just this morning I was able to play without incident for ~ 1 hour for the
first time, then locked up almost immediately in a mission again after
restarting.

-- 
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/20140627/0b4effa9/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #14 from theamazingjanet at googlemail.com ---
Created attachment 101844
  --> https://bugs.freedesktop.org/attachment.cgi?id=101844=edit
Dmesg 2

-- 
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/20140627/40e9984f/attachment.html>