date:20150204

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

--- Comment #5 from dex+fdobugzilla at dragonslave.de ---
(In reply to dex+fdobugzilla from comment #4)
> So this is either a LLVM or Mesa Issue.
> 
> I will now compile latest Mesa with LLVM 225080 and see if that works.

I tried LLVm 22508 with Mesa Git(2335153) with Changeset
a8ef880a1b38cbcfc26e9f829338739d16cece99 reverted:

No Lockups

I guess its LLVM then. I continue with LLVM bisecting

-- 
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/20150204/9ad854b7/attachment.html>

[PATCH] GPU-DRM-OMAP: Delete unnecessary checks before two function calls

2015-02-04 Thread SF Markus Elfring

From: Markus Elfring 
Date: Wed, 4 Feb 2015 22:22:36 +0100

The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around their calls is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +--
 drivers/gpu/drm/omapdrm/omap_gem.c   | 5 ++---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index d292d24..fcc02b0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -270,8 +270,7 @@ fail_unlock:
 fail:

if (ret) {
-   if (fbi)
-   framebuffer_release(fbi);
+   framebuffer_release(fbi);
if (fb) {
drm_framebuffer_unregister_private(fb);
drm_framebuffer_remove(fb);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index aeb91ed..18a4137 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1292,12 +1292,11 @@ void omap_gem_free_object(struct drm_gem_object *obj)
if (omap_obj->pages)
omap_gem_detach_pages(obj);

-   if (!is_shmem(obj)) {
+   if (!is_shmem(obj))
dma_free_writecombine(dev->dev, obj->size,
omap_obj->vaddr, omap_obj->paddr);
-   } else if (omap_obj->vaddr) {
+   else
vunmap(omap_obj->vaddr);
-   }
}

/* don't free externally allocated syncobj */
-- 
2.2.2

[PATCH] GPU-DRM-Exynos: Delete unnecessary checks before two function calls

2015-02-04 Thread SF Markus Elfring

From: Markus Elfring 
Date: Wed, 4 Feb 2015 21:54:45 +0100

The functions phy_power_on() and vunmap() perform also input
parameter validation. Thus the test around their calls is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c   | 6 ++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 34d46aa..306cf1d 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1057,14 +1057,12 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,

 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-   if (dp->phy)
-   phy_power_on(dp->phy);
+   phy_power_on(dp->phy);
 }

 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-   if (dp->phy)
-   phy_power_off(dp->phy);
+   phy_power_off(dp->phy);
 }

 static void exynos_dp_poweron(struct exynos_drm_display *display)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e12ea90..0dd448a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -313,7 +313,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd->exynos_gem_obj;
struct drm_framebuffer *fb;

-   if (is_drm_iommu_supported(dev) && exynos_gem_obj->buffer->kvaddr)
+   if (is_drm_iommu_supported(dev))
vunmap(exynos_gem_obj->buffer->kvaddr);

/* release drm framebuffer and real buffer */
-- 
2.2.2

[Intel-gfx] [regression in linux-next] i915: broken graphics on laptop

2015-02-04 Thread Andrey Skvortsov

On Tue, Feb 03, 2015 at 08:21:52PM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote:
> > Hi,
> > 
> > tested next-20150202. System boots, but graphic output is broken (empty 
> > black screen).
> > Booted five times the same kernel, always got the same result. The system 
> > works with 3.19-rc7.
> 
> Those two warnings are more or less symptoms of the black screen (well
> the first is just overzealous). More important would be the drm.debug=6
> dmesg from boot along with the gdm.log (or equivalent) aned Xorg.0.log
> as my guess is that X (or the display server) is crashing.

Requested logs with drm.debug=6 are attached. lightdm was running after 
WARN_ON, but I couldn't restart it.
The command hanged.

As I booted next-20150202 system crashed several times with a lot of drm_ calls 
in the backtrace, but I couldn't catch kernel logs,
because I have not serial port on the laptop.

If you need to get other information or to test patches, I would be glad to 
help.

-- 
Best regards,
Andrey Skvortsov

PGP Key ID: 0x57A3AEAD
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.19.0-rc6-next-20150202-150201- (developer at 
ST-37) (gcc version 4.7.2 (Debian 4.7.2-5) ) #4 SMP PREEMPT Mon Feb 2 17:53:17 
MSK 2015
[0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-3.19.0-rc6-next-20150202-150201- 
root=UUID=b8e95798-f113-470b-b415-323e51da7052 ro drm.debug=6
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xdf66d7ff] usable
[0.00] BIOS-e820: [mem 0xdf66d800-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfed18000-0xfed1bfff] reserved
[0.00] BIOS-e820: [mem 0xfed2-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfeda-0xfeda5fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee0] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00019fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Dell Inc. Vostro 1500 /0NX907, BIOS A06 
04/21/2008
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x1a max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-E uncachable
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0C000 mask FE000 write-back
[0.00]   3 base 1 mask F write-back
[0.00]   4 base 0DF80 mask FFF80 uncachable
[0.00]   5 base 0DF70 mask 0 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] PAT configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC  
[0.00] e820: update [mem 0xdf70-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xdf66d max_arch_pfn = 0x4
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x01d0, 0x01d00fff] PGTABLE
[0.00] BRK [0x01d01000, 0x01d01fff] PGTABLE
[0.00] BRK [0x01d02000, 0x01d02fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x19fe0-0x19fff]
[0.00]  [mem 0x19fe0-0x19fff] page 2M
[0.00] BRK [0x01d03000, 0x01d03fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x18000-0x19fdf]
[0.00]  [mem 0x18000-0x19fdf] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0xdf66cfff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0xdf5f] page 2M
[0.00]  [mem 0xdf60-0xdf66cfff] page 4k
[0.00] init_memory_mapping: [mem 0x1-0x17fff]
[0.00]  [mem 0x1-0x17fff] page 2M
[0.00] BRK [0x01d04000, 0x01d04fff] PGTABLE
[0.00] BRK [0x01d05000, 0x0

[PATCH] drm: atmel-hlcdc: Atomic mode-setting conversion

Convert the HLCDC driver to atomic mode-setting.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 142 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |   4 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |   5 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c  |   4 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h  |   3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |   3 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 556 +--
 7 files changed, 383 insertions(+), 334 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 0409b90..a69c966 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -114,25 +114,17 @@ static void atmel_hlcdc_crtc_dpms(struct drm_crtc *c, int 
mode)
crtc->dpms = mode;
 }

-static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c,
-struct drm_display_mode *mode,
-struct drm_display_mode *adj,
-int x, int y,
-struct drm_framebuffer *old_fb)
+static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
 {
struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
struct regmap *regmap = crtc->dc->hlcdc->regmap;
-   struct drm_plane *plane = c->primary;
-   struct drm_framebuffer *fb;
+   struct drm_display_mode *adj = &c->state->adjusted_mode;
unsigned long mode_rate;
struct videomode vm;
unsigned long prate;
unsigned int cfg;
int div;

-   if (atmel_hlcdc_dc_mode_valid(crtc->dc, adj) != MODE_OK)
-   return -EINVAL;
-
vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end;
vm.vsync_len = adj->crtc_vsync_end - adj->crtc_vsync_start;
@@ -156,7 +148,7 @@ static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c,
cfg = ATMEL_HLCDC_CLKPOL;

prate = clk_get_rate(crtc->dc->hlcdc->sys_clk);
-   mode_rate = mode->crtc_clock * 1000;
+   mode_rate = adj->crtc_clock * 1000;
if ((prate / 2) < mode_rate) {
prate *= 2;
cfg |= ATMEL_HLCDC_CLKSEL;
@@ -174,10 +166,10 @@ static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c,

cfg = 0;

-   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+   if (adj->flags & DRM_MODE_FLAG_NVSYNC)
cfg |= ATMEL_HLCDC_VSPOL;

-   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+   if (adj->flags & DRM_MODE_FLAG_NHSYNC)
cfg |= ATMEL_HLCDC_HSPOL;

regmap_update_bits(regmap, ATMEL_HLCDC_CFG(5),
@@ -187,34 +179,6 @@ static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c,
   ATMEL_HLCDC_VSPSU | ATMEL_HLCDC_VSPHO |
   ATMEL_HLCDC_GUARDTIME_MASK,
   cfg);
-
-   fb = plane->fb;
-   plane->fb = old_fb;
-
-   return atmel_hlcdc_plane_update_with_mode(plane, c, fb, 0, 0,
- adj->hdisplay, adj->vdisplay,
- x << 16, y << 16,
- adj->hdisplay << 16,
- adj->vdisplay << 16,
- adj);
-}
-
-int atmel_hlcdc_crtc_mode_set_base(struct drm_crtc *c, int x, int y,
-  struct drm_framebuffer *old_fb)
-{
-   struct drm_plane *plane = c->primary;
-   struct drm_framebuffer *fb = plane->fb;
-   struct drm_display_mode *mode = &c->hwmode;
-
-   plane->fb = old_fb;
-
-   return plane->funcs->update_plane(plane, c, fb,
- 0, 0,
- mode->hdisplay,
- mode->vdisplay,
- x << 16, y << 16,
- mode->hdisplay << 16,
- mode->vdisplay << 16);
 }

 static void atmel_hlcdc_crtc_prepare(struct drm_crtc *crtc)
@@ -250,14 +214,48 @@ static void atmel_hlcdc_crtc_disable(struct drm_crtc 
*crtc)
}
 }

+static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc *c,
+struct drm_crtc_state *s)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+
+   if (atmel_hlcdc_dc_mode_valid(crtc->dc, &s->adjusted_mode) != MODE_OK)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+
+   if (c->state->event) {
+   c->state->event->pipe = drm_crtc_index

Atmel HLCDC + Atomic operations: hook for internal atomic state change

Hi Ville,

On Wed, 4 Feb 2015 20:02:27 +0200
Ville SyrjÃ¤lÃ¤  wrote:

> On Wed, Feb 04, 2015 at 06:23:15PM +0100, Boris Brezillon wrote:
> > Hello,
> > 
> > I'm currently adding support for atomic operations (or atomic
> > modesetting) in the Atmel HLCDC driver.
> > Everything is pretty much in place, and all the features provided by the
> > current driver are working as expected.
> > However, there's one feature I'd like to add (actually I was hoping
> > atomic support could help me deal with this feature), and I not sure
> > how to do it.
> > 
> > The HLCDC IP provides a way to discard a specific area on the primary
> > plane (in case at least one of the overlay is activated and alpha
> > blending is disabled).
> > Doing this will reduce the amount of data to transfer from the main
> > memory to the Display Controller, and thus alleviate the load on the
> > memory bus (since this link is quite limited on such hardware,
> > this kind of optimization is really important).
> > 
> > My problem here is that there is no way, in the current atomic
> > implementation, to internally ask for a plane state modification.
> > 
> > Is there a plan to add such hooks that would be called after the
> > requested state modifications (i.e. operations done before the
> > drm_atomic_commit call in all helper functions), but before the atomic
> > checks begin (i.e. call to drm_atomic_check_only) ?
> > Such hooks would let me ask for a primary plane update (modifying the
> > discard area property) if needed.
> > 
> > Maybe I'm totally mistaken in my approach to solve this problem, so
> > please let me know if you see other solutions.
> 
> So this looks pretty much exactly like the overlay optimization feature
> in OMAPs. I don't really see why you need to treat is as some kind of
> plane property. It's just an internal implementation detail so can't you
> just compute the discard area at commit() time based on what planes are
> going to be active? Or if you want to take it into account in some
> bandwidth calculation you can compute it already at check() time.
> 

Okay, I'll have a look at the OMAP driver, but I'd really like to
apply the discard area setting as part of the primary plane
atomic_update function (the discard area registers are part of the
primary plane registers, and plane settings are updated by setting a
specific bit to 1).

I tried to update the primary plane discard settings as part of the
atomic_update, but when nothing touches the primary plane (an
update_plane on one of the overlay planes), the primary plane is kept
unchanged, and thus the new primary settings are never applied.

Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Atmel HLCDC + Atomic operations: hook for internal atomic state change

On Wed, 4 Feb 2015 12:49:19 -0500
Rob Clark  wrote:

> On Wed, Feb 4, 2015 at 12:23 PM, Boris Brezillon
>  wrote:
> > Hello,
> >
> > I'm currently adding support for atomic operations (or atomic
> > modesetting) in the Atmel HLCDC driver.
> > Everything is pretty much in place, and all the features provided by the
> > current driver are working as expected.
> > However, there's one feature I'd like to add (actually I was hoping
> > atomic support could help me deal with this feature), and I not sure
> > how to do it.
> >
> > The HLCDC IP provides a way to discard a specific area on the primary
> > plane (in case at least one of the overlay is activated and alpha
> > blending is disabled).
> > Doing this will reduce the amount of data to transfer from the main
> > memory to the Display Controller, and thus alleviate the load on the
> > memory bus (since this link is quite limited on such hardware,
> > this kind of optimization is really important).
> >
> > My problem here is that there is no way, in the current atomic
> > implementation, to internally ask for a plane state modification.
> >
> > Is there a plan to add such hooks that would be called after the
> > requested state modifications (i.e. operations done before the
> > drm_atomic_commit call in all helper functions), but before the atomic
> > checks begin (i.e. call to drm_atomic_check_only) ?
> > Such hooks would let me ask for a primary plane update (modifying the
> > discard area property) if needed.
> 
> Maybe just wrap drm_atomic_helper_commit() w/ your own fxn that did
> extra fixup and then called drm_atomic_helper_commit()?

Yes, that's something I considered, but this implies modifying/creating
a plane state (calling drm_atomic_get_plane_state and modifying the
discard area fields) after everything has been checked.
If that's fine, then I think I'll go for this solution.

Thanks.

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank

2015-02-04 Thread Andrey Skvortsov

On Wed, Feb 04, 2015 at 01:32:14PM +0100, Paul Bolle wrote:
> Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]:
> > this warning exist in v3.19-rc6 and does not in v3.18. Bisection
> > points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait".
> > I have two machines with integrated Intel graphics and the problem
> > happens only on the old one with  GM965 chipset and X3100 integrated 
> > graphics.
> 
> I see this too, since v3.19-rc1, on an (outdated) ThinkPad X41.
> 
> > backtrace information:
> > 
> > [   31.780813] WARNING: CPU: 0 PID: 718 at drivers/gpu/drm/drm_irq.c:1077 
> > drm_wait_one_vblank+0x33/0x141 [drm]()
> 
> But it also prints
> vblank not available on crtc 0, ret=-22
> 
> after the WARNING line, on that machine.

I have "vblank not available on crtc 1, ret=-22" there.


> > [   31.780862]  thermal_sys(E)
> > [   31.780866] CPU: 0 PID: 718 Comm: kworker/u4:3 Tainted: GE  
> > 3.17.0-rc5-150116--00578-g51e31d4 #16
> > [   31.780868] Hardware name: Dell Inc. Vostro 1500 
> > /0NX907, BIOS A06 04/21/2008
> > [   31.780873] Workqueue: events_unbound async_run_entry_fn
> > [   31.780875]   a0544b9d 813d4e81 
> > 
> > [   31.780879]  8103dec3 8800d84e0068 a0521c73 
> > 00070008
> > [   31.780882]  8800d84e 8801973e0800  
> > 6014
> > [   31.780886] Call Trace:
> > [   31.780890]  [] ? dump_stack+0x4a/0x75
> > [   31.780894]  [] ? warn_slowpath_common+0x7e/0x97
> > [   31.781050]  [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> > [   31.781078]  [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> > [   31.781122]  [] ? intel_enable_tv+0x22/0x58 [i915]
> > [   31.781153]  [] ? i9xx_crtc_enable+0x33b/0x397 [i915]
> > [   31.781184]  [] ? __intel_set_mode+0x1160/0x1209 [i915]
> > [   31.781216]  [] ? intel_set_mode+0x12/0x2c [i915]
> > [   31.781247]  [] ? 
> > intel_get_load_detect_pipe+0x367/0x408 [i915]
> > [   31.781281]  [] ? intel_tv_detect+0x103/0x444 [i915]
> > [   31.781289]  [] ? 
> > drm_helper_probe_single_connector_modes_merge_bits+0xc0/0x327 
> > [drm_kms_helper]
> > [   31.781296]  [] ? 
> > drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper]
> > [   31.781303]  [] ? 
> > drm_fb_helper_initial_config+0x3d/0x303 [drm_kms_helper]
> > [   31.781306]  [] ? async_run_entry_fn+0x5a/0x110
> > [   31.781310]  [] ? process_one_work+0x194/0x292
> > [   31.781313]  [] ? worker_thread+0x236/0x298
> > [   31.781316]  [] ? process_scheduled_works+0x2a/0x2a
> > [   31.781319]  [] ? kthread+0x9e/0xa6
> > [   31.781322]  [] ? 
> > kthread_freezable_should_stop+0x36/0x36
> > [   31.781326]  [] ? ret_from_fork+0x7c/0xb0
> > [   31.781329]  [] ? 
> > kthread_freezable_should_stop+0x36/0x36
> > [   31.782726] ---[ end trace e2b78017f1a10054 ]---
> > 

-- 
Best regards,
Andrey Skvortsov

PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/0a69cdc4/attachment-0001.sig>

Atmel HLCDC + Atomic operations: hook for internal atomic state change

2015-02-04 Thread Ville Syrjälä

On Wed, Feb 04, 2015 at 06:23:15PM +0100, Boris Brezillon wrote:
> Hello,
> 
> I'm currently adding support for atomic operations (or atomic
> modesetting) in the Atmel HLCDC driver.
> Everything is pretty much in place, and all the features provided by the
> current driver are working as expected.
> However, there's one feature I'd like to add (actually I was hoping
> atomic support could help me deal with this feature), and I not sure
> how to do it.
> 
> The HLCDC IP provides a way to discard a specific area on the primary
> plane (in case at least one of the overlay is activated and alpha
> blending is disabled).
> Doing this will reduce the amount of data to transfer from the main
> memory to the Display Controller, and thus alleviate the load on the
> memory bus (since this link is quite limited on such hardware,
> this kind of optimization is really important).
> 
> My problem here is that there is no way, in the current atomic
> implementation, to internally ask for a plane state modification.
> 
> Is there a plan to add such hooks that would be called after the
> requested state modifications (i.e. operations done before the
> drm_atomic_commit call in all helper functions), but before the atomic
> checks begin (i.e. call to drm_atomic_check_only) ?
> Such hooks would let me ask for a primary plane update (modifying the
> discard area property) if needed.
> 
> Maybe I'm totally mistaken in my approach to solve this problem, so
> please let me know if you see other solutions.

So this looks pretty much exactly like the overlay optimization feature
in OMAPs. I don't really see why you need to treat is as some kind of
plane property. It's just an internal implementation detail so can't you
just compute the discard area at commit() time based on what planes are
going to be active? Or if you want to take it into account in some
bandwidth calculation you can compute it already at check() time.

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH V3] drm/exynos: Add DECON driver

2015-02-04 Thread Ajay kumar

Hi Inki,

On Mon, Dec 8, 2014 at 7:09 PM, Inki Dae  wrote:
>
>
> On 2014ë 12ì 07ì¼ 21:04, Ajay Kumar wrote:
>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> DECON(Display and Enhancement Controller) is the new IP
>> in exynos7 SOC for generating video signals using pixel data.
>>
>> DECON driver can be used to drive 2 different interfaces on Exynos7:
>> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>>
>> The existing FIMD driver code was used as a template to create
>> DECON driver. Only DECON-INT is supported as of now, and
>> DECON-EXT support will be added later.
>>
>> Signed-off-by: Akshu Agrawal 
>> Signed-off-by: Ajay Kumar 
>> ---
>> Changes since V1:
>>   -- Address comments from Pankaj and do few cleanups.
>> Changes since V2:
>>   -- Address more comments from Pankaj and cleanup.
>>
>>  .../devicetree/bindings/video/exynos7-decon.txt|   67 ++
>>  drivers/gpu/drm/exynos/Kconfig |   13 +-
>>  drivers/gpu/drm/exynos/Makefile|1 +
>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1042
> 
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
>>  include/video/exynos7_decon.h  |  346 +++
>>  7 files changed, 1471 insertions(+), 3 deletions(-)
>>  create mode 100644
> Documentation/devicetree/bindings/video/exynos7-decon.txt
>>  create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>  create mode 100644 include/video/exynos7_decon.h
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
> b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> new file mode 100644
>> index 000..14db519
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> @@ -0,0 +1,67 @@
>> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
>> +
>> +DECON (Display and Enhancement Controller) is the Display Controller
> for the
>> +Exynos7 series of SoCs which transfers the image data from a video memory
>> +buffer to an external LCD interface.
>> +
>> +Required properties:
>> +- compatible: value should be "samsung,exynos7-decon";
>> +
>> +- reg: physical base address and length of the DECON registers set.
>> +
>> +- interrupt-parent: should be the phandle of the decon controller's
>> + parent interrupt controller.
>> +
>> +- interrupts: should contain a list of all DECON IP block interrupts
> in the
>> +  order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
>> +  format depends on the interrupt controller used.
>> +
>> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
>> + "lcd_sys", in the same order as they were listed in the interrupts
>> +property.
>> +
>> +- pinctrl-0: pin control group to be used for this controller.
>> +
>> +- pinctrl-names: must contain a "default" entry.
>> +
>> +- clocks: must include clock specifiers corresponding to entries in the
>> + clock-names property.
>> +
>> +- clock-names: list of clock names sorted in the same order as the clocks
>> +   property. Must contain "pclk_decon0", "aclk_decon0",
>> +"decon0_eclk", "decon0_vclk".
>
> Should the DECON driver really care about decon0_eclk and decon0_vclk?
> If so then What is the purpose of these special clocks? I'm not sure
> that these clocks should be cared by driver. Until now, Exynos driver
> has cared about only video source and core source clocks.
>
> Can you give me more details about the use of the special clocks?
All these 4 clocks are definitely needed for the DECON to function properly.
pclk_decon0 and aclk_decon0 are clocks needed for normal
operation of DECON.
decon0_eclk and decon0_vclk are like pixel clocks.
The clock diagram is present in the Exynos7 user manual in clock
generation chapter.

>> +
>> +Optional Properties:
>> +- samsung,power-domain: a phandle to DECON power domain node.
>> +- 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.
>> +
>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>> +
>> +Example:
>> +
>> +SoC specific DT entry:
>> +
>> + decon at 1393 {
>> + compatible = "samsung,exynos7-decon";
>> + interrupt-parent = <&combiner>;
>> + reg = <0x1393 0x1000>;
>> + interrupt-names = "lcd_sys", "vsync", "fifo";
>> + interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
>> + clocks = <&clock_disp PCLK_DECON_INT>,
>> +  <&clock_disp ACLK_DECON_INT>,
>> +  <&clock_disp SCLK_DECON_INT_ECLK>,
>> +  <&clock_disp SCLK_DECON_I

[PATCH 2/2] modetest: add null check before destory the buffer object

2015-02-04 Thread Hyungwon Hwang

When setting a plane is turned on without setting a mode, modetest
terminates with segmentation fault like below. So this patch adds
null check for the variable storing the buffer object in set_mode()
which is null in this case.

[ 4759.016695] modetest[619]: unhandled level 2 translation fault (11) at 
0x, esr 0x9206
[ 4759.016959] pgd = ffc0b25e1000
[ 4759.017062] [] *pgd=d3492003, *pud=d3492003, 
*pmd=
[ 4759.017312]
[ 4759.017365] CPU: 0 PID: 619 Comm: modetest Not tainted 
3.19.0-rc7-00347-g458583e-dirty #56
[ 4759.024713] Hardware name: XXX board (DT)
[ 4759.029629] task: ffc0b24d5e80 ti: ffc0b2a3c000 task.ti: 
ffc0b2a3c000
[ 4759.037071] PC is at 0x404610
[ 4759.039992] LR is at 0x4027f4
[ 4759.042962] pc : [<00404610>] lr : [<004027f4>] pstate: 
6000
[ 4759.050356] sp : 007fe65a6f90
[ 4759.053620] x29: 007fe65a6f90 x28: 00421060
[ 4759.058912] x27: 0041f000 x26: 004226d0
[ 4759.064207] x25: 00421200 x24: 0006
[ 4759.069502] x23: 0040e790 x22: 0041f6f0
[ 4759.074797] x21: 00421060 x20: 004216a0
[ 4759.080091] x19:  x18: 
[ 4759.085386] x17: 0041f2c8 x16: 
[ 4495.006841] x15: 5798 x14: 007f93691968
[ 4495.006850] x13: 5500 x12: 0005
[ 4495.006855] x11: 16170f12001a1311 x10: 00010004157f1c03
[ 4495.006860] x9 : 083b x8 : 003f
[ 4495.006865] x7 : 18b2 x6 : 004226d0
[ 4495.006870] x5 :  x4 : 000a
[ 4495.006875] x3 :  x2 : 0001
[ 4495.006880] x1 : 64b4 x0 : 
[ 4495.006881]
Segmentation fault  (core dumped) ./modetest -P 13:200x200+0+0

Signed-off-by: Hyungwon Hwang 
---
 tests/modetest/modetest.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 6ce8717..5fcf2a4 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1636,7 +1636,8 @@ int main(int argc, char **argv)
if (test_cursor)
clear_cursors(&dev);

-   bo_destroy(dev.mode.bo);
+   if (dev.mode.bo)
+   bo_destroy(dev.mode.bo);
}

free_resources(dev.resources);
-- 
1.9.1

[PATCH 1/2] modetest: tab/whitespace cleanup

2015-02-04 Thread Hyungwon Hwang

This patch removes the trailing tabs and whitespaces.

Signed-off-by: Hyungwon Hwang 
---
 tests/modetest/modetest.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 4b9cf2f..6ce8717 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1210,7 +1210,7 @@ static void test_page_flip(struct device *dev, struct 
pipe_arg *pipes, unsigned
evctx.version = DRM_EVENT_CONTEXT_VERSION;
evctx.vblank_handler = NULL;
evctx.page_flip_handler = page_flip_handler;
-   
+
while (1) {
 #if 0
struct pollfd pfd[2];
@@ -1521,7 +1521,7 @@ int main(int argc, char **argv)
if (parse_connector(&pipe_args[count], optarg) < 0)
usage(argv[0]);

-   count++;  
+   count++;
break;
case 'C':
test_cursor = 1;
-- 
1.9.1

[Intel-gfx] [regression in linux-next] i915: broken graphics on laptop

2015-02-04 Thread Chris Wilson

On Wed, Feb 04, 2015 at 09:26:27PM +0300, Andrey Skvortsov wrote:
> On Tue, Feb 03, 2015 at 08:21:52PM +, Chris Wilson wrote:
> > On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote:
> > > Hi,
> > > 
> > > tested next-20150202. System boots, but graphic output is broken (empty 
> > > black screen).
> > > Booted five times the same kernel, always got the same result. The system 
> > > works with 3.19-rc7.
> > 
> > Those two warnings are more or less symptoms of the black screen (well
> > the first is just overzealous). More important would be the drm.debug=6
> > dmesg from boot along with the gdm.log (or equivalent) aned Xorg.0.log
> > as my guess is that X (or the display server) is crashing.
> 
> Requested logs with drm.debug=6 are attached. lightdm was running after 
> WARN_ON, but I couldn't restart it.
> The command hanged.
> 
> As I booted next-20150202 system crashed several times with a lot of drm_ 
> calls in the backtrace, but I couldn't catch kernel logs,
> because I have not serial port on the laptop.
> 
> If you need to get other information or to test patches, I would be glad to 
> help.

Right, here it looks like it freezing in intel_get_load_detect_pipe()
during the initial configuration probe of X. Given the other crashes,
we're back to worring about memory corruption.

> [   29.292333] [drm:intel_tv_detect] [CONNECTOR:33:SVIDEO-1] force=1
> [   29.292336] [drm:intel_get_load_detect_pipe] [CONNECTOR:33:SVIDEO-1], 
> [ENCODER:34:TV-34]
> [   29.292339] [drm:intel_get_load_detect_pipe] creating tmp fb for 
> load-detection
> [   29.292396] [drm:intel_modeset_affected_pipes] set mode pipe masks: 
> modeset: 1, prepare: 1, disable: 0
> [   29.292408] [drm:connected_sink_compute_bpp] [CONNECTOR:33:SVIDEO-1] 
> checking for sink bpp constrains
> [   29.292413] [drm:intel_tv_compute_config] forcing bpc to 8 for TV
> [   29.292416] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, 
> dithering: 0
> [   29.292418] [drm:intel_dump_pipe_config] [CRTC:20][modeset] config for 
> pipe A
> [   29.292419] [drm:intel_dump_pipe_config] cpu_transcoder: A
> [   29.292421] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
> [   29.292423] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, 
> gmch_n: 0, link_m: 0, link_n: 0, tu: 0
> [   29.292425] [drm:intel_dump_pipe_config] dp: 0, gmch_m: 0, gmch_n: 0, 
> link_m: 0, link_n: 0, tu: 0
> [   29.292428] [drm:intel_dump_pipe_config] dp: 0, gmch_m2: 0, gmch_n2: 0, 
> link_m2: 0, link_n2: 0, tu2: 0
> [   29.292429] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0
> [   29.292431] [drm:intel_dump_pipe_config] requested mode:
> [   29.292433] [drm:drm_mode_debug_printmodeline] Modeline 0:"NTSC 480i" 0 
> 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0
> [   29.292435] [drm:intel_dump_pipe_config] adjusted mode:
> [   29.292438] [drm:drm_mode_debug_printmodeline] Modeline 0:"NTSC 480i" 0 
> 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0
> [   29.292440] [drm:intel_dump_crtc_timings] crtc timings: 108000 1280 1368 
> 1496 1712 1024 1027 1034 1104, type: 0x40 flags: 0x0
> [   29.292442] [drm:intel_dump_pipe_config] port clock: 108000
> [   29.292444] [drm:intel_dump_pipe_config] pipe src size: 1280x1024
> [   29.292446] [drm:intel_dump_pipe_config] gmch pfit: control: 0x, 
> ratios: 0x, lvds border: 0x
> [   29.292447] [drm:intel_dump_pipe_config] pch pfit: pos: 0x, size: 
> 0x, disabled
> [   29.292449] [drm:intel_dump_pipe_config] ips: 0
> [   29.292451] [drm:intel_dump_pipe_config] double wide: 0
> [   29.292565] [ cut here ]
> [   29.293785] WARNING: CPU: 0 PID: 53 at include/linux/kref.h:47 
> drm_framebuffer_reference+0x5b/0x64 [drm]()
> [   29.295032] Modules linked in: bnep(E) cfg80211(E) cpufreq_stats(E) 
> cpufreq_powersave(E) cpufreq_userspace(E) cpufreq_conservative(E) nfsd(E) 
> auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) cdc_wdm(E) cdc_acm(E) 
> cdc_ether(E) usbnet(E) joydev(E) coretemp(E) kvm_intel(E) kvm(E) i8k(E) 
> btusb(E) psmouse(E) snd_pcsp(E) i915(E) evdev(E) bluetooth(E) i2c_i801(E) 
> snd_hda_codec_generic(E) lpc_ich(E) mfd_core(E) xhci_pci(E) xhci_hcd(E) 
> serio_raw(E) rfkill(E) drm_kms_helper(E) drm(E) i2c_algo_bit(E) i2c_core(E) 
> snd_hda_intel(E) snd_hda_controller(E) snd_hda_codec(E) button(E) 
> snd_hwdep(E) battery(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) video(E) 
> ac(E) acpi_cpufreq(E) processor(E) fuse(E) parport_pc(E) ppdev(E) lp(E) 
> parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E) sd_mod(E) 
> ata_generic(E)
> [   29.295080]  ahci(E) libahci(E) ata_piix(E) libata(E) scsi_mod(E) b44(E) 
> firewire_ohci(E) sdhci_pci(E) sdhci(E) firewire_core(E) crc_itu_t(E) mii(E) 
> ssb(E) mmc_core(E) libphy(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) thermal(E) 
> thermal_sys(E) usbcore(E) usb_common(E)
> [   29.296301] CPU: 0 PID: 53 Comm: kworker/0:3 Tainted: GW   E   
> 3.19.0-rc6-next-2015

Atmel HLCDC + Atomic operations: hook for internal atomic state change

Hello,

I'm currently adding support for atomic operations (or atomic
modesetting) in the Atmel HLCDC driver.
Everything is pretty much in place, and all the features provided by the
current driver are working as expected.
However, there's one feature I'd like to add (actually I was hoping
atomic support could help me deal with this feature), and I not sure
how to do it.

The HLCDC IP provides a way to discard a specific area on the primary
plane (in case at least one of the overlay is activated and alpha
blending is disabled).
Doing this will reduce the amount of data to transfer from the main
memory to the Display Controller, and thus alleviate the load on the
memory bus (since this link is quite limited on such hardware,
this kind of optimization is really important).

My problem here is that there is no way, in the current atomic
implementation, to internally ask for a plane state modification.

Is there a plan to add such hooks that would be called after the
requested state modifications (i.e. operations done before the
drm_atomic_commit call in all helper functions), but before the atomic
checks begin (i.e. call to drm_atomic_check_only) ?
Such hooks would let me ask for a primary plane update (modifying the
discard area property) if needed.

Maybe I'm totally mistaken in my approach to solve this problem, so
please let me know if you see other solutions.

Thanks.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH] drm: Use static attribute groups for managing connector sysfs entries

On Wed, Feb 04, 2015 at 11:58:53AM +0100, Takashi Iwai wrote:
> Instead of manual calls of device_create_file() and
> device_remove_file(), assign the static attribute groups to the device
> with device_create_with_groups().  The conditionally built sysfs
> entries are handled via is_visible callback.
> 
> This simplifies the code and also avoids the possible races.
> 
> Signed-off-by: Takashi Iwai 

lgtm, pulled into my drm-misc branch.
-Daniel

> ---
>  drivers/gpu/drm/drm_sysfs.c | 132 
> ++--
>  1 file changed, 67 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index cc3d6d6d67e0..5c99d3773212 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -339,19 +339,51 @@ static ssize_t select_subconnector_show(struct device 
> *device,
>   drm_get_dvi_i_select_name((int)subconnector));
>  }
>  
> -static struct device_attribute connector_attrs[] = {
> - __ATTR_RO(status),
> - __ATTR_RO(enabled),
> - __ATTR_RO(dpms),
> - __ATTR_RO(modes),
> +static DEVICE_ATTR_RO(status);
> +static DEVICE_ATTR_RO(enabled);
> +static DEVICE_ATTR_RO(dpms);
> +static DEVICE_ATTR_RO(modes);
> +
> +static struct attribute *connector_dev_attrs[] = {
> + &dev_attr_status.attr,
> + &dev_attr_enabled.attr,
> + &dev_attr_dpms.attr,
> + &dev_attr_modes.attr,
> + NULL
>  };
>  
>  /* These attributes are for both DVI-I connectors and all types of tv-out. */
> -static struct device_attribute connector_attrs_opt1[] = {
> - __ATTR_RO(subconnector),
> - __ATTR_RO(select_subconnector),
> +static DEVICE_ATTR_RO(subconnector);
> +static DEVICE_ATTR_RO(select_subconnector);
> +
> +static struct attribute *connector_opt_dev_attrs[] = {
> + &dev_attr_subconnector.attr,
> + &dev_attr_select_subconnector.attr,
> + NULL
>  };
>  
> +static umode_t connector_opt_dev_is_visible(struct kobject *kobj,
> + struct attribute *attr, int idx)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct drm_connector *connector = to_drm_connector(dev);
> +
> + /*
> +  * In the long run it maybe a good idea to make one set of
> +  * optionals per connector type.
> +  */
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_DVII:
> + case DRM_MODE_CONNECTOR_Composite:
> + case DRM_MODE_CONNECTOR_SVIDEO:
> + case DRM_MODE_CONNECTOR_Component:
> + case DRM_MODE_CONNECTOR_TV:
> + return attr->mode;
> + }
> +
> + return 0;
> +}
> +
>  static struct bin_attribute edid_attr = {
>   .attr.name = "edid",
>   .attr.mode = 0444,
> @@ -359,6 +391,27 @@ static struct bin_attribute edid_attr = {
>   .read = edid_show,
>  };
>  
> +static struct bin_attribute *connector_bin_attrs[] = {
> + &edid_attr,
> + NULL
> +};
> +
> +static const struct attribute_group connector_dev_group = {
> + .attrs = connector_dev_attrs,
> + .bin_attrs = connector_bin_attrs,
> +};
> +
> +static const struct attribute_group connector_opt_dev_group = {
> + .attrs = connector_opt_dev_attrs,
> + .is_visible = connector_opt_dev_is_visible,
> +};
> +
> +static const struct attribute_group *connector_dev_groups[] = {
> + &connector_dev_group,
> + &connector_opt_dev_group,
> + NULL
> +};
> +
>  /**
>   * drm_sysfs_connector_add - add a connector to sysfs
>   * @connector: connector to add
> @@ -371,73 +424,27 @@ static struct bin_attribute edid_attr = {
>  int drm_sysfs_connector_add(struct drm_connector *connector)
>  {
>   struct drm_device *dev = connector->dev;
> - int attr_cnt = 0;
> - int opt_cnt = 0;
> - int i;
> - int ret;
>  
>   if (connector->kdev)
>   return 0;
>  
> - connector->kdev = device_create(drm_class, dev->primary->kdev,
> - 0, connector, "card%d-%s",
> - dev->primary->index, connector->name);
> + connector->kdev =
> + device_create_with_groups(drm_class, dev->primary->kdev, 0,
> +   connector, connector_dev_groups,
> +   "card%d-%s", dev->primary->index,
> +   connector->name);
>   DRM_DEBUG("adding \"%s\" to sysfs\n",
> connector->name);
>  
>   if (IS_ERR(connector->kdev)) {
>   DRM_ERROR("failed to register connector device: %ld\n", 
> PTR_ERR(connector->kdev));
> - ret = PTR_ERR(connector->kdev);
> - goto out;
> - }
> -
> - /* Standard attributes */
> -
> - for (attr_cnt = 0; attr_cnt < ARRAY_SIZE(connector_attrs); attr_cnt++) {
> - ret = device_create_file(connector->kdev, 
> &connector_attrs[attr_cnt]);
> - if (ret)
> - goto err_out_files;
> + return

[PATCH] drm/radeon: Don't try to enable write-combining without PAT

2015-02-04 Thread Alex Deucher

On Wed, Feb 4, 2015 at 4:49 AM, Christian KÃ¶nig  
wrote:
> Am 04.02.2015 um 02:19 schrieb Michel DÃ¤nzer:
>>
>> From: Michel DÃ¤nzer 
>>
>> Doing so can cause things to become slow.
>>
>> Print a warning at compile time and an informative message at runtime in
>> that case.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Michel DÃ¤nzer 
>
>
> Interesting I wonder what the rational behind this is. I mean CONFIG_X86_PAT
> will obviously affect write combining, but why does it slow down things if
> we request something that the kernel isn't configured for?
>
> Anyway, patch is Reviewed-by: Christian KÃ¶nig 

Applied to my 3.20 tree.

Thanks!

Alex

>
> Regards,
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/radeon/radeon_object.c | 12 
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>> b/drivers/gpu/drm/radeon/radeon_object.c
>> index 7d68223..bd3df10 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -238,6 +238,18 @@ int radeon_bo_create(struct radeon_device *rdev,
>>  * See https://bugs.freedesktop.org/show_bug.cgi?id=84627
>>  */
>> bo->flags &= ~RADEON_GEM_GTT_WC;
>> +#elif defined(CONFIG_X86) && !defined(CONFIG_X86_PAT)
>> +   /* Don't try to enable write-combining when it can't work, or
>> things
>> +* may be slow
>> +* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
>> +*/
>> +
>> +#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better
>> performance \
>> +thanks to write-combining
>> +
>> +   DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
>> + "better performance thanks to write-combining\n");
>> +   bo->flags &= ~RADEON_GEM_GTT_WC;
>>   #endif
>> radeon_ttm_placement_from_domain(bo, domain);
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: hdmi: replace fb size with mode size from win commit

On 2015ë 01ì 30ì¼ 17:30, Seung-Woo Kim wrote:
> For default graphic window, mixer_win_commit() sets display size
> register as fb size. Calling setplane with smaller fb size than
> mode size to default window causes distorted display result. So
> this patch replaces fb size with mode size for display size from
> the mixer_win_commit().

Applied.

Thanks,
Inki Dae

> 
> Signed-off-by: Seung-Woo Kim 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 6766271..086fe0e 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -584,8 +584,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
> int win)
>   /* setup display size */
>   if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
>   win == MIXER_DEFAULT_WIN) {
> - val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> - val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + val  = MXR_MXR_RES_HEIGHT(win_data->mode_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->mode_width);
>   mixer_reg_write(res, MXR_RESOLUTION, val);
>   }
>  
>

[PATCH] drm/radeon: use 0-255 rather than 0-100 for pwm fan range

2015-02-04 Thread Alex Deucher

0-255 seems to be the preferred range for the pwm interface.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_pm.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 91e1bd2..9f758d3 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -585,7 +585,7 @@ static ssize_t radeon_hwmon_set_pwm1_enable(struct device 
*dev,
if (err)
return err;

-   switch(value) {
+   switch (value) {
case 1: /* manual, percent-based */
rdev->asic->dpm.fan_ctrl_set_mode(rdev, FDO_PWM_MODE_STATIC);
break;
@@ -608,7 +608,7 @@ static ssize_t radeon_hwmon_get_pwm1_max(struct device *dev,
 struct device_attribute *attr,
 char *buf)
 {
-   return sprintf(buf, "%i\n", 100); /* pwm uses percent-based fan-control 
*/
+   return sprintf(buf, "%i\n", 255);
 }

 static ssize_t radeon_hwmon_set_pwm1(struct device *dev,
@@ -623,6 +623,8 @@ static ssize_t radeon_hwmon_set_pwm1(struct device *dev,
if (err)
return err;

+   value = (value * 100) / 255;
+
err = rdev->asic->dpm.set_fan_speed_percent(rdev, value);
if (err)
return err;
@@ -642,6 +644,8 @@ static ssize_t radeon_hwmon_get_pwm1(struct device *dev,
if (err)
return err;

+   speed = (speed * 255) / 100;
+
return sprintf(buf, "%i\n", speed);
 }

-- 
1.8.3.1

[PATCH -next] drm/nouveau/clk: Use plain "/" for 32-bit division

2015-02-04 Thread Geert Uytterhoeven

On 32-bit platforms using asm-generic/div64.h:

drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function 
'gk20a_pllg_calc_rate':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison of 
distinct pointer types lacks a cast
  do_div(rate, divider);
   ^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right shift 
count >= width of type
  do_div(rate, divider);
  ^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing 
argument 1 of '__div64_32' from incompatible pointer type
  do_div(rate, divider);


  ^
In file included from arch/parisc/include/generated/asm/div64.h:1:0,
 from include/linux/kernel.h:124,
 from include/linux/list.h:8,
 from include/linux/preempt.h:10,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from include/linux/slab.h:14,
 from drivers/gpu/drm/nouveau/include/nvif/os.h:5,
 from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
 from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
 from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3,
 from drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3,
 from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25:
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is 
of type 'u32 *'
 extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
 ^

do_div() is meant for 64-bit by 32-bit division, but both the dividend
and divisor are 32-bit here. Hence use plain "/" instead.

Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.

parisc/allmodconfig:
http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
index 65c532742b08d1c6..022595876ea4dc85 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
@@ -144,9 +144,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv)

rate = priv->parent_rate * priv->n;
divider = priv->m * pl_to_div[priv->pl];
-   do_div(rate, divider);

-   return rate / 2;
+   return rate / divider / 2;
 }

 static int
-- 
1.9.1

[PATCH 11/14] drm/exynos: atomic phase 2: keep track of framebuffer pointer

Hi,

On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
> track of the framebuffer pointer and reference.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 660ad64..2edc73c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -211,6 +211,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
> *crtc,
>   crtc_w, crtc_h, crtc->x, crtc->y,
>   crtc_w, crtc_h);
>  
> + if (crtc->primary->state)
> + drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
> +

I'm not sure whether this needs, how about go to
drm_atomic_helper_page_flip?

Thanks.

[PATCH 09/14] drm/exynos: atomic phase 1: add .mode_set_nofb() callback

Hi,

On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> The new atomic infrastructure needs the .mode_set_nofb() callback to
> update CRTC timings before setting any plane.
> 
> Signed-off-by: Gustavo Padovan 
> 
> Conflicts:
>   drivers/gpu/drm/exynos/exynos_drm_crtc.c
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 55 
> +++-
>  1 file changed, 11 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index be36cca..17b64f8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -81,53 +81,19 @@ exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
>   return true;
>  }
>  
> -static int
> -exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode 
> *mode,
> -   struct drm_display_mode *adjusted_mode, int x, int y,
> -   struct drm_framebuffer *old_fb)
> -{
> - struct drm_framebuffer *fb = crtc->primary->fb;
> - unsigned int crtc_w;
> - unsigned int crtc_h;
> - int ret;
> -
> - ret = exynos_check_plane(crtc->primary, fb);
> - if (ret < 0)
> - return ret;
> -
> - crtc_w = fb->width - x;
> - crtc_h = fb->height - y;
> - exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> -   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
> -
> - return 0;
> -}
> -
> -static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> -   struct drm_framebuffer *old_fb)
> +static void
> +exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
>  {
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct drm_framebuffer *fb = crtc->primary->fb;
> - unsigned int crtc_w;
> - unsigned int crtc_h;
> - int ret;
> + struct drm_display_mode *adjusted_mode;
>  
> - /* when framebuffer changing is requested, crtc's dpms should be on */
> - if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
> - DRM_ERROR("failed framebuffer changing request.\n");
> - return -EPERM;
> - }
> -
> - ret = exynos_check_plane(crtc->primary, fb);
> - if (ret)
> - return ret;
> + if (WARN_ON(!crtc->state))
> + return;
>  
> - crtc_w = fb->width - x;
> - crtc_h = fb->height - y;
> - exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
> - crtc_w, crtc_h, x, y, crtc_w, crtc_h);
> + adjusted_mode = &crtc->state->adjusted_mode;
>  
> - return 0;
> + if (exynos_crtc->ops->commit)
> + exynos_crtc->ops->commit(exynos_crtc);

This already should be executed by .commit of struct
drm_crtc_helper_funcs, not here.

Thanks.

>  }
>  
>  static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
> @@ -184,8 +150,9 @@ static struct drm_crtc_helper_funcs 
> exynos_crtc_helper_funcs = {
>   .prepare= exynos_drm_crtc_prepare,
>   .commit = exynos_drm_crtc_commit,
>   .mode_fixup = exynos_drm_crtc_mode_fixup,
> - .mode_set   = exynos_drm_crtc_mode_set,
> - .mode_set_base  = exynos_drm_crtc_mode_set_base,
> + .mode_set   = drm_helper_crtc_mode_set,
> + .mode_set_nofb  = exynos_drm_crtc_mode_set_nofb,
> + .mode_set_base  = drm_helper_crtc_mode_set_base,
>   .disable= exynos_drm_crtc_disable,
>   .atomic_begin   = exynos_crtc_atomic_begin,
>   .atomic_flush   = exynos_crtc_atomic_flush,
>

[PATCH 08/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()

Hi,

On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
> unprotect the windows before the commit and protects it after based on
> a plane mask tha store which plane will be updated.
> 

I don't think they need now.

Thanks.

> For that we create two new exynos_crtc callbacks: .win_protect() and
> .win_unprotect(). The only driver that implement those now is FIMD.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 34 ++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 57 
> ++-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 +++
>  4 files changed, 82 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 09d4780..be36cca 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -147,6 +147,38 @@ static void exynos_drm_crtc_disable(struct drm_crtc 
> *crtc)
>   }
>  }
>  
> +static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
> +{
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
> + int index = 0;
> +
> + list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
> + if (exynos_crtc->ops->win_protect &&
> + exynos_crtc->plane_mask & (0x01 << index))
> + exynos_crtc->ops->win_protect(exynos_crtc, index);
> +
> + index++;
> + }
> +}
> +
> +static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
> +{
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
> + int index = 0;
> +
> + list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
> + if (exynos_crtc->ops->win_unprotect &&
> + exynos_crtc->plane_mask & (0x01 << index))
> + exynos_crtc->ops->win_unprotect(exynos_crtc, index);
> +
> + index++;
> + }
> +
> + exynos_crtc->plane_mask = 0;
> +}
> +
>  static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
>   .dpms   = exynos_drm_crtc_dpms,
>   .prepare= exynos_drm_crtc_prepare,
> @@ -155,6 +187,8 @@ static struct drm_crtc_helper_funcs 
> exynos_crtc_helper_funcs = {
>   .mode_set   = exynos_drm_crtc_mode_set,
>   .mode_set_base  = exynos_drm_crtc_mode_set_base,
>   .disable= exynos_drm_crtc_disable,
> + .atomic_begin   = exynos_crtc_atomic_begin,
> + .atomic_flush   = exynos_crtc_atomic_flush,
>  };
>  
>  static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index cad54e7..43efd9f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -194,6 +194,8 @@ struct exynos_drm_crtc_ops {
>   void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
>   void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
>   void (*te_handler)(struct exynos_drm_crtc *crtc);
> + void (*win_protect)(struct exynos_drm_crtc *crtc, int zpos);
> + void (*win_unprotect)(struct exynos_drm_crtc *crtc, int zpos);
>  };
>  
>  enum exynos_crtc_mode {
> @@ -214,6 +216,7 @@ enum exynos_crtc_mode {
>   *   we can refer to the crtc to current hardware interrupt occurred through
>   *   this pipe value.
>   * @dpms: store the crtc dpms value
> + * @plane_mask: store planes to be updated on atomic modesetting
>   * @mode: store the crtc mode value
>   * @event: vblank event that is currently queued for flip
>   * @ops: pointer to callbacks for exynos drm specific functionality
> @@ -224,6 +227,7 @@ struct exynos_drm_crtc {
>   enum exynos_drm_output_type type;
>   unsigned intpipe;
>   unsigned intdpms;
> + unsigned intplane_mask;
>   enum exynos_crtc_mode   mode;
>   wait_queue_head_t   pending_flip_queue;
>   struct drm_pending_vblank_event *event;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index ebb4cdc..f498d86 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -585,6 +585,16 @@ static void fimd_shadow_protect_win(struct fimd_context 
> *ctx,
>  {
>   u32 reg, bits, val;
>  
> + /*
> +  * SHADOWCON/PRTCON register is used for enabling timing.
> +  *
> +  * for example, once only width value of a register is set,
> +  * if the dma is started then fimd hardware could malfunction so
> +  * with protect window setting, the register fields with prefix '_F'
> +  * wouldn't be updated at vsync

[PATCH 07/14] drm/exynos: atomic phase 1: use drm_plane_helper_disable()

Hi,

On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> The atomic helper to disable planes also uses the optional
> .atomic_disable() helper. The unique operation it does is calling
> .win_disable()
> 

Is there any reason to split this patch from patch 06/14?

> exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.
> 

This is not related with this patch purpose.

> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index d346d1e..470456d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -136,7 +136,7 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct 
> drm_framebuffer *fb)
>  
>   exynos_fb = to_exynos_fb(fb);
>  
> - return exynos_fb->buf_cnt;
> + return exynos_fb ? exynos_fb->buf_cnt : 0;

I don't think exynos_fb can be NULL.

Thanks.

>  }
>  
>  struct drm_framebuffer *
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 2c356b9..a3b0687 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -219,7 +219,7 @@ static int exynos_plane_set_property(struct drm_plane 
> *plane,
>  
>  static struct drm_plane_funcs exynos_plane_funcs = {
>   .update_plane   = drm_plane_helper_update,
> - .disable_plane  = exynos_disable_plane,
> + .disable_plane  = drm_plane_helper_disable,
>   .destroy= exynos_plane_destroy,
>   .set_property   = exynos_plane_set_property,
>  };
> @@ -242,9 +242,21 @@ static void exynos_plane_atomic_update(struct drm_plane 
> *plane,
>   state->src_w >> 16, state->src_h >> 16);
>  }
>  
> +static void exynos_plane_atomic_disable(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(old_state->crtc);
> +
> + if (exynos_crtc->ops->win_disable)
> + exynos_crtc->ops->win_disable(exynos_crtc,
> +   exynos_plane->zpos);
> +}
> +
>  static const struct drm_plane_helper_funcs plane_helper_funcs = {
>   .atomic_check = exynos_plane_atomic_check,
>   .atomic_update = exynos_plane_atomic_update,
> + .atomic_disable = exynos_plane_atomic_disable,
>  };
>  
>  static void exynos_plane_attach_zpos_property(struct drm_plane *plane)
>

[PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes

Hi,

On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> directly.
> 
> It changes how planes are created and remove .win_mode_set() callback
> that was only filling all *_win_data structs.
> 

I commented already on prior patch.

Thanks.

> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   9 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  14 --
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |   5 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 182 ++---
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  20 +--
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 123 +
>  drivers/gpu/drm/exynos/exynos_mixer.c | 212 
> +++---
>  9 files changed, 183 insertions(+), 389 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index ad675fb..d504f0b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -296,13 +296,13 @@ static void exynos_drm_crtc_attach_mode_property(struct 
> drm_crtc *crtc)
>  }
>  
>  struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
> +struct drm_plane *plane,
>  int pipe,
>  enum exynos_drm_output_type type,
>  struct exynos_drm_crtc_ops *ops,
>  void *ctx)
>  {
>   struct exynos_drm_crtc *exynos_crtc;
> - struct drm_plane *plane;
>   struct exynos_drm_private *private = drm_dev->dev_private;
>   struct drm_crtc *crtc;
>   int ret;
> @@ -318,12 +318,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
> drm_device *drm_dev,
>   exynos_crtc->type = type;
>   exynos_crtc->ops = ops;
>   exynos_crtc->ctx = ctx;
> - plane = exynos_plane_init(drm_dev, 1 << pipe,
> -   DRM_PLANE_TYPE_PRIMARY);
> - if (IS_ERR(plane)) {
> - ret = PTR_ERR(plane);
> - goto err_plane;
> - }
>  
>   crtc = &exynos_crtc->base;
>  
> @@ -342,7 +336,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
> drm_device *drm_dev,
>  
>  err_crtc:
>   plane->funcs->destroy(plane);
> -err_plane:
>   kfree(exynos_crtc);
>   return ERR_PTR(ret);
>  }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> index 628b787..0ecd8fc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> @@ -18,6 +18,7 @@
>  #include "exynos_drm_drv.h"
>  
>  struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
> +struct drm_plane *plane,
>  int pipe,
>  enum exynos_drm_output_type type,
>  struct exynos_drm_crtc_ops *ops,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 737164d..778c91e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -55,7 +55,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
> long flags)
>  {
>   struct exynos_drm_private *private;
>   int ret;
> - int nr;
>  
>   private = kzalloc(sizeof(struct exynos_drm_private), GFP_KERNEL);
>   if (!private)
> @@ -80,19 +79,6 @@ static int exynos_drm_load(struct drm_device *dev, 
> unsigned long flags)
>  
>   exynos_drm_mode_config_init(dev);
>  
> - for (nr = 0; nr < MAX_PLANE; nr++) {
> - struct drm_plane *plane;
> - unsigned long possible_crtcs = (1 << MAX_CRTC) - 1;
> -
> - plane = exynos_plane_init(dev, possible_crtcs,
> -   DRM_PLANE_TYPE_OVERLAY);
> - if (!IS_ERR(plane))
> - continue;
> -
> - ret = PTR_ERR(plane);
> - goto err_mode_config_cleanup;
> - }
> -
>   /* setup possible_clones. */
>   exynos_drm_encoder_setup(dev);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 7411af2..cad54e7 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -78,6 +78,7 @@ enum exynos_drm_output_type {
>   * @transparency: transparency on or off.
>   * @activated: activated or not.
>   * @enabled: enabled or not.
> + * @resume: to resume or not.
>   *
>

[PATCH] drm: Add support to find drm_panel by name

2015-02-04 Thread Shobhit Kumar

For scenarios where OF is not available, we can use panel identification by
name.

v2: Use const char *name instead of name[NAME_MAX] (Thierry)

CC: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/drm_panel.c | 18 ++
 include/drm/drm_panel.h |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..7b4f559 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -95,6 +95,24 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
 EXPORT_SYMBOL(of_drm_find_panel);
 #endif

+struct drm_panel *drm_find_panel_by_name(const char *name)
+{
+   struct drm_panel *panel;
+
+   mutex_lock(&panel_lock);
+
+   list_for_each_entry(panel, &panel_list, list) {
+   if (panel->name && strcmp(panel->name, name) == 0) {
+   mutex_unlock(&panel_lock);
+   return panel;
+   }
+   }
+
+   mutex_unlock(&panel_lock);
+   return NULL;
+}
+EXPORT_SYMBOL(drm_find_panel_by_name);
+
 MODULE_AUTHOR("Thierry Reding ");
 MODULE_DESCRIPTION("DRM panel infrastructure");
 MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 1fbcc96..43b9004 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -74,6 +74,7 @@ struct drm_panel {
struct drm_device *drm;
struct drm_connector *connector;
struct device *dev;
+   const char *name;

const struct drm_panel_funcs *funcs;

@@ -137,4 +138,6 @@ static inline struct drm_panel *of_drm_find_panel(struct 
device_node *np)
 }
 #endif

+struct drm_panel *drm_find_panel_by_name(const char *name);
+
 #endif
-- 
1.9.1

[PATCH 02/14] drm/exynos: Remove exynos_plane_dpms() call with no effect

Hi,

On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
> from the underlying layer. However neither one of these layers implement
> win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms()
> is pointless.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index b2a4b84..ad675fb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -65,8 +65,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>  
>   if (exynos_crtc->ops->commit)
>   exynos_crtc->ops->commit(exynos_crtc);
> -
> - exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);

As i said, this needs to keep pair enabled flag of struct
exynos_drm_plane.

Thanks.

[PATCH v2 05/10] Add RGB666_1X24_CPADHI media bus format

2015-02-04 Thread Sakari Ailus

Hi Philipp,

Could you add linux-media next time you send the set, please? I think 
that's the most relevant list for the format related patches.

Philipp Zabel wrote:
> Commit 9e74d2926a28 ("staging: imx-drm: add LVDS666 support for parallel
> display") describes a 24-bit bus format where three 6-bit components each
> take the lower part of 8 bits with the two high bits zero padded. Add a
> component-wise padded media bus format RGB666_1X24_CPADHI to support this
> connection.
>
> Cc: Emil Renner Berthing 
> Signed-off-by: Philipp Zabel 
> ---
>   Documentation/DocBook/media/v4l/subdev-formats.xml | 30 
> ++
>   include/uapi/linux/media-bus-format.h  |  3 ++-
>   2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
> b/Documentation/DocBook/media/v4l/subdev-formats.xml
> index 8d1f624..c02af7a 100644
> --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
> +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
> @@ -480,6 +480,36 @@ see .
> b1
> b0
>   
> + 
> +   MEDIA_BUS_FMT_RGB666_1X24_CPADHI

Could you add a note on "C" in front of PADHI to the explanation in 
media-bus-format.h?

> +   0x1015
> +   
> +   &dash-ent-8;
> +   0
> +   0
> +   r5
> +   r4
> +   r3
> +   r2
> +   r1
> +   r0
> +   0
> +   0
> +   g5
> +   g4
> +   g3
> +   g2
> +   g1
> +   g0
> +   0
> +   0
> +   b5
> +   b4
> +   b3
> +   b2
> +   b1
> +   b0
> + 
>   
> MEDIA_BUS_FMT_BGR888_1X24
> 0x1013
> diff --git a/include/uapi/linux/media-bus-format.h 
> b/include/uapi/linux/media-bus-format.h
> index 8dbf16c..83ea46f 100644
> --- a/include/uapi/linux/media-bus-format.h
> +++ b/include/uapi/linux/media-bus-format.h
> @@ -33,7 +33,7 @@
>
>   #define MEDIA_BUS_FMT_FIXED 0x0001
>
> -/* RGB - next is 0x1015 */
> +/* RGB - next is 0x1016 */
>   #define MEDIA_BUS_FMT_RGB444_1X12   0x100e
>   #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE   0x1001
>   #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE   0x1002
> @@ -45,6 +45,7 @@
>   #define MEDIA_BUS_FMT_RGB565_2X8_BE 0x1007
>   #define MEDIA_BUS_FMT_RGB565_2X8_LE 0x1008
>   #define MEDIA_BUS_FMT_RGB666_1X18   0x1009
> +#define MEDIA_BUS_FMT_RGB666_1X24_CPADHI 0x1015
>   #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG 0x1010
>   #define MEDIA_BUS_FMT_BGR888_1X24   0x1013
>   #define MEDIA_BUS_FMT_GBR888_1X24   0x1014
>

-- 
Kind regards,

Sakari Ailus
sakari.ailus at linux.intel.com

[PATCH 00/14] drm/exynos: cleanups + atomic phases 1 and 2

Hi,

On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> This series clean ups a few more paths from exynos-drm with the most important
> being the removal of the global page flip queue and the removal in driver
> internal data (struct *_win_data) that was replicating plane data.
> 
> Following these patches comes the first step torwards atomic modesetting
> support on exynos.
> 

It's better to split cleanup and atomic support, not one patchset.

Thanks.

> This series is applied on top of 3 patches[0][1][2] that were sent recently to
> dri-devel.
> 
>   Gustavo
> 
> ---
> [0] http://www.spinics.net/lists/linux-samsung-soc/msg41867.html
> [1] http://lists.freedesktop.org/archives/dri-devel/2015-January/076504.html
> [2] http://lists.freedesktop.org/archives/dri-devel/2015-January/076505.html
> 
> 
> Daniel Kurtz (1):
>   drm/exynos: do not copy adjusted mode into mode during crtc mode_set
> 
> Gustavo Padovan (12):
>   drm/exynos: Remove exynos_plane_dpms() call with no effect
>   drm/exynos: remove leftover functions declarations
>   drm/exynos: remove struct *_win_data abstraction on planes
>   drm/exynos: atomic phase 1: use drm_plane_helper_update()
>   drm/exynos: atomic phase 1: use drm_plane_helper_disable()
>   drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
>   drm/exynos: atomic phase 1: add .mode_set_nofb() callback
>   drm/exynos: atomic phase 2: wire up state reset(), duplicate() and
> destroy()
>   drm/exynos: atomic phase 2: keep track of framebuffer pointer
>   drm/exynos: make exynos_plane_mode_set() static
>   drm/exynos: use correct pipe number on vblank event
>   drm/exynos: remove exynos_disable_plane()
> 
> Mandeep Singh Baines (1):
>   drm/exynos: track vblank events on a per crtc basis
> 
>  drivers/gpu/drm/bridge/ptn3460.c  |   4 +
>  drivers/gpu/drm/exynos/exynos_dp_core.c   |   4 +
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |   4 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 203 +++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |   4 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  29 +---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  15 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |   4 +
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 235 
> --
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  99 ++-
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  13 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 127 --
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |   4 +
>  drivers/gpu/drm/exynos/exynos_mixer.c | 212 ---
>  16 files changed, 408 insertions(+), 558 deletions(-)
>

[PATCH] drm/exynos: use driver internal struct

On 2015ë 01ì 30ì¼ 16:43, Joonyoung Shim wrote:
> Use driver internal struct as argument instead of struct exynos_drm_crtc
> except functions of exynos_drm_crtc_ops and instead of struct
> exynos_drm_display except functions of exynos_drm_display_ops.

Agree. Reasonable to use a driver context as an argument in case of
internal functions. Applied.

Thanks,
Inki Dae

> 
> It can reduce unnecessary variable declaration.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 14 ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 43 
> +---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c | 19 ++
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 12 -
>  drivers/gpu/drm/exynos/exynos_mixer.c| 26 ---
>  5 files changed, 47 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 34d46aa..11fd893 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1067,10 +1067,8 @@ static void exynos_dp_phy_exit(struct exynos_dp_device 
> *dp)
>   phy_power_off(dp->phy);
>  }
>  
> -static void exynos_dp_poweron(struct exynos_drm_display *display)
> +static void exynos_dp_poweron(struct exynos_dp_device *dp)
>  {
> - struct exynos_dp_device *dp = display_to_dp(display);
> -
>   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
>   return;
>  
> @@ -1085,13 +1083,11 @@ static void exynos_dp_poweron(struct 
> exynos_drm_display *display)
>   exynos_dp_phy_init(dp);
>   exynos_dp_init_dp(dp);
>   enable_irq(dp->irq);
> - exynos_dp_commit(display);
> + exynos_dp_commit(&dp->display);
>  }
>  
> -static void exynos_dp_poweroff(struct exynos_drm_display *display)
> +static void exynos_dp_poweroff(struct exynos_dp_device *dp)
>  {
> - struct exynos_dp_device *dp = display_to_dp(display);
> -
>   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
>   return;
>  
> @@ -1119,12 +1115,12 @@ static void exynos_dp_dpms(struct exynos_drm_display 
> *display, int mode)
>  
>   switch (mode) {
>   case DRM_MODE_DPMS_ON:
> - exynos_dp_poweron(display);
> + exynos_dp_poweron(dp);
>   break;
>   case DRM_MODE_DPMS_STANDBY:
>   case DRM_MODE_DPMS_SUSPEND:
>   case DRM_MODE_DPMS_OFF:
> - exynos_dp_poweroff(display);
> + exynos_dp_poweroff(dp);
>   break;
>   default:
>   break;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 39f7fa7..925fc69 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -253,9 +253,8 @@ static void fimd_enable_shadow_channel_path(struct 
> fimd_context *ctx, int win,
>   writel(val, ctx->regs + SHADOWCON);
>  }
>  
> -static void fimd_clear_channel(struct exynos_drm_crtc *crtc)
> +static void fimd_clear_channel(struct fimd_context *ctx)
>  {
> - struct fimd_context *ctx = crtc->ctx;
>   int win, ch_enabled = 0;
>  
>   DRM_DEBUG_KMS("%s\n", __FILE__);
> @@ -280,7 +279,7 @@ static void fimd_clear_channel(struct exynos_drm_crtc 
> *crtc)
>   unsigned int state = ctx->suspended;
>  
>   ctx->suspended = 0;
> - fimd_wait_for_vblank(crtc);
> + fimd_wait_for_vblank(ctx->crtc);
>   ctx->suspended = state;
>   }
>  }
> @@ -302,7 +301,7 @@ static int fimd_ctx_initialize(struct fimd_context *ctx,
>* If any channel is already active, iommu will throw
>* a PAGE FAULT when enabled. So clear any channel if enabled.
>*/
> - fimd_clear_channel(ctx->crtc);
> + fimd_clear_channel(ctx);
>   ret = drm_iommu_attach_device(ctx->drm_dev, ctx->dev);
>   if (ret) {
>   DRM_ERROR("drm_iommu_attach failed.\n");
> @@ -823,9 +822,8 @@ static void fimd_win_disable(struct exynos_drm_crtc 
> *crtc, int zpos)
>   win_data->enabled = false;
>  }
>  
> -static void fimd_window_suspend(struct exynos_drm_crtc *crtc)
> +static void fimd_window_suspend(struct fimd_context *ctx)
>  {
> - struct fimd_context *ctx = crtc->ctx;
>   struct fimd_win_data *win_data;
>   int i;
>  
> @@ -833,13 +831,12 @@ static void fimd_window_suspend(struct exynos_drm_crtc 
> *crtc)
>   win_data = &ctx->win_data[i];
>   win_data->resume = win_data->enabled;
>   if (win_data->enabled)
> - fimd_win_disable(crtc, i);
> + fimd_win_disable(ctx->crtc, i);
>   }
>  }
>  
> -static void fimd_window_resume(struct exynos_drm_crtc *crtc)
> +static void fimd_window_resume(struct fimd_context *ctx)
>  {
> - struct fimd_context *ctx = crtc->ctx;
>   struct fimd_win_data *win_data;
>   int i;

[PATCH] drm/exynos: fix wrong pipe calculation for crtc

On 2015ë 01ì 30ì¼ 16:43, Joonyoung Shim wrote:
> We get wrong pipe value for crtc since commit 93bca243ec96 ("drm/exynos:
> remove struct exynos_drm_manager"). We should should increase pipe value
> before call exynos_drm_crtc_create.

Right, applied.

Thanks,
Inki Dae

> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 +++--
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c |  4 ++--
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 682806e..39f7fa7 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1065,18 +1065,19 @@ static int fimd_bind(struct device *dev, struct 
> device *master, void *data)
>   struct drm_device *drm_dev = data;
>   int ret;
>  
> - ctx->crtc = exynos_drm_crtc_create(drm_dev, ctx->pipe,
> -EXYNOS_DISPLAY_TYPE_LCD,
> -&fimd_crtc_ops, ctx);
> - if (IS_ERR(ctx->crtc))
> - return PTR_ERR(ctx->crtc);
> -
>   ret = fimd_ctx_initialize(ctx, drm_dev);
>   if (ret) {
>   DRM_ERROR("fimd_ctx_initialize failed.\n");
>   return ret;
>   }
>  
> + ctx->crtc = exynos_drm_crtc_create(drm_dev, ctx->pipe,
> +EXYNOS_DISPLAY_TYPE_LCD,
> +&fimd_crtc_ops, ctx);
> + if (IS_ERR(ctx->crtc)) {
> + fimd_ctx_remove(ctx);
> + return PTR_ERR(ctx->crtc);
> + }
>  
>   if (ctx->display)
>   exynos_drm_create_enc_conn(drm_dev, ctx->display);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 9c8300e..fb68d3c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -548,6 +548,8 @@ static int vidi_bind(struct device *dev, struct device 
> *master, void *data)
>   struct drm_device *drm_dev = data;
>   int ret;
>  
> + vidi_ctx_initialize(ctx, drm_dev);
> +
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, ctx->pipe,
>  EXYNOS_DISPLAY_TYPE_VIDI,
>  &vidi_crtc_ops, ctx);
> @@ -556,8 +558,6 @@ static int vidi_bind(struct device *dev, struct device 
> *master, void *data)
>   return PTR_ERR(ctx->crtc);
>   }
>  
> - vidi_ctx_initialize(ctx, drm_dev);
> -
>   ret = exynos_drm_create_enc_conn(drm_dev, &ctx->display);
>   if (ret) {
>   ctx->crtc->base.funcs->destroy(&ctx->crtc->base);
>

[Bug 88658] (bisected) Slow video playback on Kabini

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

--- Comment #11 from jtossenb  ---
(In reply to Michel DÃ¤nzer from comment #10)
> Does this Mesa patch help?

Yes, it does!
mesa-10.4.3 + this patch works fine.
Thank you very much!

-- 
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/20150204/19754f32/attachment.html>

[Bug 88968] Unit mouseover in World of Warcraft (wine, D3D) freezes up the entire system

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

Bug ID: 88968
Summary: Unit mouseover in World of Warcraft (wine, D3D)
freezes up the entire system
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: rubykuby at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

I'm not sure if I selected all the right bug tracker things, or whether this is
a Mesa or X11 bug.

I have an AMD Radeon HD 7950, which is practically identical to the R9 280.
When running World of Warcraft in wine, everything works fine until I mouseover
a unit. This mouseover should trigger a glow effect around the unit, but
instead freezes up the entire system, forcing me to reboot.

This bug does not occur in standard Ubuntu 14.10. It does occur in Ubuntu 14.10
with the oibaf/graphics-drivers PPA added. It also occurs in Manjaro 0.9.

Ubuntu 14.10 versions:
libgl1-mesa-glx - 10.3.0-0ubuntu3
xserver-xorg-video-ati - 1:7.4.0-2ubuntu2

Oibaf versions:
mesa - 10.5~git1502040730.6fd4a6~gd~u
xserver-xorg-video-ati - 1:7.5.99+git1501140731.c80ea1~gd~u

Manjaro 0.9 versions:
mesa - 10.4.3-1
xf86-video-ati - 1:7.5.0-1

This bug does not occur when turning on the OpenGL mode within WoW. This bug
does not occur in the Catalyst drivers.

I do not know how to gather debug information, but I'd be glad to provide them
if given instructions.

--
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/20150204/de368210/attachment-0001.html>

[PATCH 00/14] drm/exynos: cleanups + atomic phases 1 and 2

Hi all,

I've gone through some of the contentions point in this patch review. With
my community guy hat on I really want to make drm atomic a success, exynos
atomic is important for that.

On Wed, Feb 04, 2015 at 04:37:04PM +0900, Joonyoung Shim wrote:
> Hi,
> 
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Hi,
> > 
> > This series clean ups a few more paths from exynos-drm with the most 
> > important
> > being the removal of the global page flip queue and the removal in driver
> > internal data (struct *_win_data) that was replicating plane data.
> > 
> > Following these patches comes the first step torwards atomic modesetting
> > support on exynos.
> > 
> 
> It's better to split cleanup and atomic support, not one patchset.

Imo the cleanups make perfect sense as prep work for atomic. They're
definitely needed afaict from what I've seen reading exynos code and these
patches here before we can implement atomic.

Personally I'd have delayered even more aggressively before going into the
atomic stuff. But in the end I guess Padovan wants to be able to ship
exynos atomic preferrably sooner than later.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

DELL Latitude e5540 Intel 4400 3rd display problem

2015-02-04 Thread Jani Nikula

On Mon, 02 Feb 2015, Gergely NÃ³grÃ¡di  wrote:
> I can't configure the 2nd or 3rd display on my Dell Latitude e5540
> notebook and Dell NB Port Replicator.
> I tried to connect DVI, DP and VGA to Port Replicator and it is
> working only in mirror mode.
> The only way to use 2 external display if I connect the DVI or DP to
> Port Replicator and HDMI to notebook.
> I send the logs and system environment.

The replicator probably needs DP MST support. Please try a newer kernel,
say v3.18 or v3.19-rc7, and see what happens. Attach dmesg with
drm.debug=14 module parameter set, running the new kernel.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 11/14] drm/exynos: atomic phase 2: keep track of framebuffer pointer

On Wed, Feb 04, 2015 at 04:53:12PM +0900, Joonyoung Shim wrote:
> Hi,
> 
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
> > track of the framebuffer pointer and reference.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > index 660ad64..2edc73c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > @@ -211,6 +211,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
> > *crtc,
> > crtc_w, crtc_h, crtc->x, crtc->y,
> > crtc_w, crtc_h);
> >  
> > +   if (crtc->primary->state)
> > +   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
> > +
> 
> I'm not sure whether this needs, how about go to
> drm_atomic_helper_page_flip?

You can only do that once you have full async atomic commit support, which
is done in phase 3. Until that's the case you need to keep this little bit
of temporary fixup code around.

I've had the same in my exynos branch, we have the same now in i915 (well
it looks a bit different since we dont use all the helpers but roll some
things ourselves).

Reviewed-by: Daniel Vetter 

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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 08/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()

On Wed, Feb 04, 2015 at 04:49:25PM +0900, Joonyoung Shim wrote:
> Hi,
> 
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
> > unprotect the windows before the commit and protects it after based on
> > a plane mask tha store which plane will be updated.
> > 
> 
> I don't think they need now.

This does exactly what I wanted to do in my atomic poc but couldn't
because of the massive layer hell that was still around in atomic. Haven't
looked into the patch in details, so no full r-b but good enough for an

Acked-by: Daniel Vetter 

Aside: If you think something doesn't need to be done please explain what
you mean or at least ask about what you don't understand in a patch. As-is
your review is pretty much unactionable.

Cheers, Daniel

> 
> Thanks.
> 
> > For that we create two new exynos_crtc callbacks: .win_protect() and
> > .win_unprotect(). The only driver that implement those now is FIMD.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 34 ++
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 +++
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 57 
> > ++-
> >  drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 +++
> >  4 files changed, 82 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > index 09d4780..be36cca 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > @@ -147,6 +147,38 @@ static void exynos_drm_crtc_disable(struct drm_crtc 
> > *crtc)
> > }
> >  }
> >  
> > +static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
> > +{
> > +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> > +   struct drm_plane *plane;
> > +   int index = 0;
> > +
> > +   list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
> > +   if (exynos_crtc->ops->win_protect &&
> > +   exynos_crtc->plane_mask & (0x01 << index))
> > +   exynos_crtc->ops->win_protect(exynos_crtc, index);
> > +
> > +   index++;
> > +   }
> > +}
> > +
> > +static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
> > +{
> > +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> > +   struct drm_plane *plane;
> > +   int index = 0;
> > +
> > +   list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
> > +   if (exynos_crtc->ops->win_unprotect &&
> > +   exynos_crtc->plane_mask & (0x01 << index))
> > +   exynos_crtc->ops->win_unprotect(exynos_crtc, index);
> > +
> > +   index++;
> > +   }
> > +
> > +   exynos_crtc->plane_mask = 0;
> > +}
> > +
> >  static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
> > .dpms   = exynos_drm_crtc_dpms,
> > .prepare= exynos_drm_crtc_prepare,
> > @@ -155,6 +187,8 @@ static struct drm_crtc_helper_funcs 
> > exynos_crtc_helper_funcs = {
> > .mode_set   = exynos_drm_crtc_mode_set,
> > .mode_set_base  = exynos_drm_crtc_mode_set_base,
> > .disable= exynos_drm_crtc_disable,
> > +   .atomic_begin   = exynos_crtc_atomic_begin,
> > +   .atomic_flush   = exynos_crtc_atomic_flush,
> >  };
> >  
> >  static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > index cad54e7..43efd9f 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > @@ -194,6 +194,8 @@ struct exynos_drm_crtc_ops {
> > void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
> > void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
> > void (*te_handler)(struct exynos_drm_crtc *crtc);
> > +   void (*win_protect)(struct exynos_drm_crtc *crtc, int zpos);
> > +   void (*win_unprotect)(struct exynos_drm_crtc *crtc, int zpos);
> >  };
> >  
> >  enum exynos_crtc_mode {
> > @@ -214,6 +216,7 @@ enum exynos_crtc_mode {
> >   * we can refer to the crtc to current hardware interrupt occurred through
> >   * this pipe value.
> >   * @dpms: store the crtc dpms value
> > + * @plane_mask: store planes to be updated on atomic modesetting
> >   * @mode: store the crtc mode value
> >   * @event: vblank event that is currently queued for flip
> >   * @ops: pointer to callbacks for exynos drm specific functionality
> > @@ -224,6 +227,7 @@ struct exynos_drm_crtc {
> > enum exynos_drm_output_type type;
> > unsigned intpipe;
> > unsigned intdpms;
> > +   unsigned intplane_mask;
> > enum exynos_crtc_mode   mode;
> > wait_queue_head_t   pending_flip_queue;
> > struct drm_pending_vblank_event *event;
> > diff --git a/drivers/gpu/drm/exynos/exynos_dr

[PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes

On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
> Hi,
> 
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > struct {fimd,mixer,vidi}_win_data was just keeping the same data
> > as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> > directly.
> > 
> > It changes how planes are created and remove .win_mode_set() callback
> > that was only filling all *_win_data structs.
> > 
> 
> I commented already on prior patch.

I think you don't quite understand how this primary/overlay plane stuff
works in drm core. The entire point of the drm core primary plane is to
work _exactly_ like an overlay plane and allow userspace to mangle the
primary plane configuration through the overlay plane. The only reason we
have primary planes is so that old userspace keeps working.

When I've done the testconversion with exynos to validate my atomic
helpers I've noticed that exynos makes a mess here, and on a quick look
Padovan seems to fix this up here. Not a detailed review, but this has my
Ack.
-Daniel

> 
> Thanks.
> 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   9 +-
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   1 +
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  14 --
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h   |   5 +-
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 182 ++---
> >  drivers/gpu/drm/exynos/exynos_drm_plane.c |  20 +--
> >  drivers/gpu/drm/exynos/exynos_drm_plane.h |   6 +-
> >  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 123 +
> >  drivers/gpu/drm/exynos/exynos_mixer.c | 212 
> > +++---
> >  9 files changed, 183 insertions(+), 389 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > index ad675fb..d504f0b 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > @@ -296,13 +296,13 @@ static void 
> > exynos_drm_crtc_attach_mode_property(struct drm_crtc *crtc)
> >  }
> >  
> >  struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
> > +  struct drm_plane *plane,
> >int pipe,
> >enum exynos_drm_output_type type,
> >struct exynos_drm_crtc_ops *ops,
> >void *ctx)
> >  {
> > struct exynos_drm_crtc *exynos_crtc;
> > -   struct drm_plane *plane;
> > struct exynos_drm_private *private = drm_dev->dev_private;
> > struct drm_crtc *crtc;
> > int ret;
> > @@ -318,12 +318,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
> > drm_device *drm_dev,
> > exynos_crtc->type = type;
> > exynos_crtc->ops = ops;
> > exynos_crtc->ctx = ctx;
> > -   plane = exynos_plane_init(drm_dev, 1 << pipe,
> > - DRM_PLANE_TYPE_PRIMARY);
> > -   if (IS_ERR(plane)) {
> > -   ret = PTR_ERR(plane);
> > -   goto err_plane;
> > -   }
> >  
> > crtc = &exynos_crtc->base;
> >  
> > @@ -342,7 +336,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
> > drm_device *drm_dev,
> >  
> >  err_crtc:
> > plane->funcs->destroy(plane);
> > -err_plane:
> > kfree(exynos_crtc);
> > return ERR_PTR(ret);
> >  }
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
> > b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> > index 628b787..0ecd8fc 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> > @@ -18,6 +18,7 @@
> >  #include "exynos_drm_drv.h"
> >  
> >  struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
> > +  struct drm_plane *plane,
> >int pipe,
> >enum exynos_drm_output_type type,
> >struct exynos_drm_crtc_ops *ops,
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > index 737164d..778c91e 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > @@ -55,7 +55,6 @@ static int exynos_drm_load(struct drm_device *dev, 
> > unsigned long flags)
> >  {
> > struct exynos_drm_private *private;
> > int ret;
> > -   int nr;
> >  
> > private = kzalloc(sizeof(struct exynos_drm_private), GFP_KERNEL);
> > if (!private)
> > @@ -80,19 +79,6 @@ static int exynos_drm_load(struct drm_device *dev, 
> > unsigned long flags)
> >  
> > exynos_drm_mode_config_init(dev);
> >  
> > -   for (nr = 0; nr < MAX_PLANE; nr++) {
> > -   struct drm_plane *plane;
> > -   unsigned long possible_crtcs = (1 << MAX_CRTC) - 1;
> > -
> > -   plane =

[PATCH 02/14] drm/exynos: Remove exynos_plane_dpms() call with no effect

On Wed, Feb 04, 2015 at 04:42:57PM +0900, Joonyoung Shim wrote:
> Hi,
> 
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
> > from the underlying layer. However neither one of these layers implement
> > win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms()
> > is pointless.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > index b2a4b84..ad675fb 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > @@ -65,8 +65,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
> >  
> > if (exynos_crtc->ops->commit)
> > exynos_crtc->ops->commit(exynos_crtc);
> > -
> > -   exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
> 
> As i said, this needs to keep pair enabled flag of struct
> exynos_drm_plane.

The reason exynos needs that exynos_plane->enable is because it has its
own per-plane dpms state. There's two problems with that:
- It's highyl non-standard, the drm kms way is to just disable the plane
  and not have some additional knob on top.
- The atomic helpers will not be able to handle this. They assume that
  there's only one dpms knob for the entire display pipeline, and
  per-plane enable/disable is handled by setting plane->state->crtc, which
  must be set iff plane->state->fb is set right now.

I recommend we rip this all out if we can adjust existing userspace to
stop using the "mode" property on planes and crtcs.

And with that non-standard exynos plane mode thing gone we can indeed rip
out exynos_plane_dpms and exynos_plane->enabled and just directly call
manager->ops->win_enable/disble. And then rip out the win_enable since
it's unused.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v5 RESEND 3/9] ARM: dts: exynos4: add hdmi related nodes

2015-02-04 Thread Marek Szyprowski

This patch adds entries for HDMI, Mixer and i2c with hdmi-phy modules
found in Exynos 4210 and 4x12 SoCs.

Signed-off-by: Marek Szyprowski 
---
Resend reason: rebased onto latest kgene/v3.20-next/dt-samsung-4 branch
---
 arch/arm/boot/dts/exynos4.dtsi| 40 +++
 arch/arm/boot/dts/exynos4210.dtsi |  8 
 arch/arm/boot/dts/exynos4x12.dtsi | 11 +++
 3 files changed, 59 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index d1759bf5202f..c6e72041cc55 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -38,6 +38,7 @@
i2c5 = &i2c_5;
i2c6 = &i2c_6;
i2c7 = &i2c_7;
+   i2c8 = &i2c_8;
csis0 = &csis_0;
csis1 = &csis_1;
fimc0 = &fimc_0;
@@ -545,6 +546,22 @@
status = "disabled";
};

+   i2c_8: i2c at 138E {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "samsung,s3c2440-hdmiphy-i2c";
+   reg = <0x138E 0x100>;
+   interrupts = <0 93 0>;
+   clocks = <&clock CLK_I2C_HDMI>;
+   clock-names = "i2c";
+   status = "disabled";
+
+   hdmi_i2c_phy: hdmiphy at 38 {
+   compatible = "exynos4210-hdmiphy";
+   reg = <0x38>;
+   };
+   };
+
spi_0: spi at 1392 {
compatible = "samsung,exynos4210-spi";
reg = <0x1392 0x100>;
@@ -654,6 +671,29 @@
status = "disabled";
};

+   hdmi: hdmi at 12D0 {
+   compatible = "samsung,exynos4210-hdmi";
+   reg = <0x12D0 0x7>;
+   interrupts = <0 92 0>;
+   clock-names = "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy",
+   "mout_hdmi";
+   clocks = <&clock CLK_HDMI>, <&clock CLK_SCLK_HDMI>,
+   <&clock CLK_SCLK_PIXEL>, <&clock CLK_SCLK_HDMIPHY>,
+   <&clock CLK_MOUT_HDMI>;
+   phy = <&hdmi_i2c_phy>;
+   power-domains = <&pd_tv>;
+   samsung,syscon-phandle = <&pmu_system_controller>;
+   status = "disabled";
+   };
+
+   mixer: mixer at 12C1 {
+   compatible = "samsung,exynos4210-mixer";
+   interrupts = <0 91 0>;
+   reg = <0x12C1 0x2100>, <0x12c0 0x300>;
+   power-domains = <&pd_tv>;
+   status = "disabled";
+   };
+
ppmu_dmc0: ppmu_dmc0 at 106a {
compatible = "samsung,exynos-ppmu";
reg = <0x106a 0x2000>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 7c15880bc8ba..1ef40f6f6e08 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -194,6 +194,14 @@
};
};

+   mixer: mixer at 12C1 {
+   clock-names = "mixer", "hdmi", "sclk_hdmi", "vp", "mout_mixer",
+   "sclk_mixer";
+   clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
+   <&clock CLK_SCLK_HDMI>, <&clock CLK_VP>,
+   <&clock CLK_MOUT_MIXER>, <&clock CLK_SCLK_MIXER>;
+   };
+
ppmu_lcd1: ppmu_lcd1 at 1224 {
compatible = "samsung,exynos-ppmu";
reg = <0x1224 0x2000>;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index af59cab53bd9..2824a5c0e28d 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -283,4 +283,15 @@
clock-names = "tmu_apbif";
status = "disabled";
};
+
+   hdmi: hdmi at 12D0 {
+   compatible = "samsung,exynos4212-hdmi";
+   };
+
+   mixer: mixer at 12C1 {
+   compatible = "samsung,exynos4212-mixer";
+   clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
+   clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
+<&clock CLK_SCLK_HDMI>, <&clock CLK_VP>;
+   };
 };
-- 
1.9.2

[Bug 85564] Dead Island rendering issues

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

--- Comment #11 from Sven Arvidsson  ---
That's odd, I can run the game, but it crashes when loading the second level on
the main campaign. However the "Ryder" campaign seems to work fine.

I'm also using r600g, but with a 5670.

-- 
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/20150204/7c80d93a/attachment.html>

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_DMABUF config

On 2015ë 01ì 27ì¼ 20:40, Joonyoung Shim wrote:
> The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
> to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
> prevent that user selects the option unnecessarily.

Applied two patches, 1 and 2.

Thanks,
Inki Dae.

> 
> Signed-off-by: Joonyoung Shim 
> ---
> This patch can be conflicted below link patch of Marek to remove
> selection of DRM_EXYNOS_IOMMU.

Yes, conflicted so merged it manually. :)

> 
> http://www.spinics.net/lists/linux-samsung-soc/msg41392.html
> 
>  drivers/gpu/drm/exynos/Kconfig | 6 --
>  drivers/gpu/drm/exynos/Makefile| 3 +--
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.h | 5 -
>  3 files changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 7f9f6f9..c8385f7 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -18,12 +18,6 @@ config DRM_EXYNOS_IOMMU
>   help
> Choose this option if you want to use IOMMU feature for DRM.
>  
> -config DRM_EXYNOS_DMABUF
> - bool "EXYNOS DRM DMABUF"
> - depends on DRM_EXYNOS
> - help
> -   Choose this option if you want to use DMABUF feature for DRM.
> -
>  config DRM_EXYNOS_FIMD
>   bool "Exynos DRM FIMD"
>   depends on DRM_EXYNOS && !FB_S3C
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 33ae365..0856891 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -6,10 +6,9 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
>  exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
>   exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
>   exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
> - exynos_drm_plane.o
> + exynos_drm_plane.o exynos_drm_dmabuf.o
>  
>  exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
> -exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)  += exynos_drm_fimd.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_DPI)   += exynos_drm_dpi.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_DSI)   += exynos_drm_dsi.o
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h 
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
> index 49acfaf..886de9f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
> @@ -12,14 +12,9 @@
>  #ifndef _EXYNOS_DRM_DMABUF_H_
>  #define _EXYNOS_DRM_DMABUF_H_
>  
> -#ifdef CONFIG_DRM_EXYNOS_DMABUF
>  struct dma_buf *exynos_dmabuf_prime_export(struct drm_device *drm_dev,
>   struct drm_gem_object *obj, int flags);
>  
>  struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
>   struct dma_buf *dma_buf);
> -#else
> -#define exynos_dmabuf_prime_export   NULL
> -#define exynos_dmabuf_prime_import   NULL
> -#endif
>  #endif
>

[PATCH] drm/exynos: IOMMU support should not be selectable by user

On 2015ë 01ì 20ì¼ 23:31, Marek Szyprowski wrote:
> If system provides IOMMU feature, Exynos DRM should use it by default,
> because the Exynos DRM subdrivers don't work correctly when Exynos IOMMU
> driver has been enabled and no IOMMU support has been compiled into Exynos
> DRM driver.

Applied.

Thanks,
Inki Dae

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/Kconfig | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 7f9f6f9e9b7e..39fe490efcd4 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -13,10 +13,9 @@ config DRM_EXYNOS
> If M is selected the module will be called exynosdrm.
>  
>  config DRM_EXYNOS_IOMMU
> - bool "EXYNOS DRM IOMMU Support"
> + bool
>   depends on DRM_EXYNOS && EXYNOS_IOMMU && ARM_DMA_USE_IOMMU
> - help
> -   Choose this option if you want to use IOMMU feature for DRM.
> + default y
>  
>  config DRM_EXYNOS_DMABUF
>   bool "EXYNOS DRM DMABUF"
>

[PATCH v5 9/9] drm/exynos: add support for 'hdmi' clock

Hi Marek,

On 2015ë 02ì 02ì¼ 22:20, Marek Szyprowski wrote:
> Mixed need to have hdmi clock enabled to properly perform power on/off
> sequences, so add handling of this clock directly to the mixer driver.
> Dependency between hdmi clock and mixer module has been observed on
> Exynos4 based boards.

Picked it up.

Thanks,
Inki Dae.

> 
> Suggested-by: Andrzej Hajda 
> Reviewed-by: Javier Martinez Canillas 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Marek Szyprowski 
> ---
>  Documentation/devicetree/bindings/video/exynos_mixer.txt | 1 +
>  drivers/gpu/drm/exynos/exynos_mixer.c| 9 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 08b394b1edbf..3e38128f866b 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -15,6 +15,7 @@ Required properties:
>   a) mixer: Gate of Mixer IP bus clock.
>   b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of
> mixer mux.
> + c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi.
>  
>  Example:
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 820b76234ef4..8212c8299625 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -72,6 +72,7 @@ struct mixer_resources {
>   spinlock_t  reg_slock;
>   struct clk  *mixer;
>   struct clk  *vp;
> + struct clk  *hdmi;
>   struct clk  *sclk_mixer;
>   struct clk  *sclk_hdmi;
>   struct clk  *mout_mixer;
> @@ -774,6 +775,12 @@ static int mixer_resources_init(struct mixer_context 
> *mixer_ctx)
>   return -ENODEV;
>   }
>  
> + mixer_res->hdmi = devm_clk_get(dev, "hdmi");
> + if (IS_ERR(mixer_res->hdmi)) {
> + dev_err(dev, "failed to get clock 'hdmi'\n");
> + return PTR_ERR(mixer_res->hdmi);
> + }
> +
>   mixer_res->sclk_hdmi = devm_clk_get(dev, "sclk_hdmi");
>   if (IS_ERR(mixer_res->sclk_hdmi)) {
>   dev_err(dev, "failed to get clock 'sclk_hdmi'\n");
> @@ -1095,6 +1102,7 @@ static void mixer_poweron(struct exynos_drm_manager 
> *mgr)
>   pm_runtime_get_sync(ctx->dev);
>  
>   clk_prepare_enable(res->mixer);
> + clk_prepare_enable(res->hdmi);
>   if (ctx->vp_enabled) {
>   clk_prepare_enable(res->vp);
>   if (ctx->has_sclk)
> @@ -1134,6 +1142,7 @@ static void mixer_poweroff(struct exynos_drm_manager 
> *mgr)
>   ctx->powered = false;
>   mutex_unlock(&ctx->mixer_mutex);
>  
> + clk_disable_unprepare(res->hdmi);
>   clk_disable_unprepare(res->mixer);
>   if (ctx->vp_enabled) {
>   clk_disable_unprepare(res->vp);
>

[PATCH] drm: remove DRM_FORMAT_NV12MT

2015-02-04 Thread Seung-Woo Kim

Hello Daniel,

On 2015ë 02ì 04ì¼ 00:48, Daniel Vetter wrote:
> So this has been merged originally in
> 
> commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> Author: Seung-Woo Kim 
> Date:   Thu Dec 15 15:40:55 2011 +0900
> 
> drm: Add multi buffer plane pixel formats
> 
> which hasn't seen a lot of review really. The problem is that it's not
> a real pixel format, but just a different way to lay out NV12 pixels
> in macroblocks, i.e. a tiling format.
> 
> The new way of doing this is with the soon-to-be-merge fb modifiers.
> 
> This was brough up in some long irc discussion around the entire
> topic, as an example of where things have gone wrong. Luckily we can
> correct the mistake:
> - The kms side support for NV12MT is all dead code because
>   format_check in drm_crtc.c never accepted NV12MT.

Yes, you are right. I sent patch to add the format to check function,
but it was not accepted. Anyway fb_modifier patch supports tiled option,
so kms with NV12MT can be change with some fix with fb_modifier.

> - The gem side for the gsc support doesn't look better: The code
>   forgets to set the pixel format and makes a big mess with the tiling
>   mode bits, inadvertedly setting them all.

Case of NV12MT in fimc is worked because it just passes fourcc format
with set_property instead fb. So it cannot be directly replaced with
fb_modifier way, but property to set tiled flag can be added to handle
tiled format.

So I agree about the remove of the internal format.

> 
> Conclusion: This never really worked (at least not in upstream) and
> hence we can savely correct our mistake here.
> 
> Cc: Seung-Woo Kim 
> Cc: Inki Dae 
> Cc: Kyungmin Park 
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Damien Lespiau 
> Signed-off-by: Daniel Vetter 

Acked-by: Seung-Woo Kim 

> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 14 ++
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  6 --
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  1 -
>  drivers/gpu/drm/exynos/exynos_mixer.c |  2 --
>  include/uapi/drm/drm_fourcc.h |  3 ---
>  5 files changed, 2 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 835b6af00970..842d6b8dc3c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -461,7 +461,6 @@ static int fimc_src_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_MSCTRL_C_INT_IN_3PLANE;
>   break;
>   case DRM_FORMAT_NV12:
> - case DRM_FORMAT_NV12MT:
>   case DRM_FORMAT_NV16:
>   cfg |= (EXYNOS_MSCTRL_ORDER2P_LSB_CBCR |
>   EXYNOS_MSCTRL_C_INT_IN_2PLANE);
> @@ -511,7 +510,6 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   case DRM_FORMAT_YVU420:
>   case DRM_FORMAT_NV12:
>   case DRM_FORMAT_NV21:
> - case DRM_FORMAT_NV12MT:
>   cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
>   break;
>   default:
> @@ -524,10 +522,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   cfg = fimc_read(ctx, EXYNOS_CIDMAPARAM);
>   cfg &= ~EXYNOS_CIDMAPARAM_R_MODE_MASK;
>  
> - if (fmt == DRM_FORMAT_NV12MT)
> - cfg |= EXYNOS_CIDMAPARAM_R_MODE_64X32;
> - else
> - cfg |= EXYNOS_CIDMAPARAM_R_MODE_LINEAR;
> + cfg |= EXYNOS_CIDMAPARAM_R_MODE_LINEAR;
>  
>   fimc_write(ctx, cfg, EXYNOS_CIDMAPARAM);
>  
> @@ -812,7 +807,6 @@ static int fimc_dst_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_CIOCTRL_YCBCR_3PLANE;
>   break;
>   case DRM_FORMAT_NV12:
> - case DRM_FORMAT_NV12MT:
>   case DRM_FORMAT_NV16:
>   cfg |= EXYNOS_CIOCTRL_ORDER2P_LSB_CBCR;
>   cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
> @@ -867,7 +861,6 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   case DRM_FORMAT_YUV420:
>   case DRM_FORMAT_YVU420:
>   case DRM_FORMAT_NV12:
> - case DRM_FORMAT_NV12MT:
>   case DRM_FORMAT_NV21:
>   cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
>   break;
> @@ -883,10 +876,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   cfg = fimc_read(ctx, EXYNOS_CIDMAPARAM);
>   cfg &= ~EXYNOS_CIDMAPARAM_W_MODE_MASK;
>  
> - if (fmt == DRM_FORMAT_NV12MT)
> - cfg |= EXYNOS_CIDMAPARAM_W_MODE_64X32;
> - else
> - cfg |= EXYNOS_CIDMAPARAM_W_MODE_LINEAR;
> + cfg |= EXYNOS_CIDMAPARAM_W_MODE_LINEAR;
>  
>   fimc_write(ctx, cfg, EXYNOS_CIDMAPARAM);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 0261468c8019..8040ed2a831f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -542,9 +542,6 @@ static int gsc_src_set_fmt(struct device *dev, u32 f

[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank

2015-02-04 Thread Paul Bolle

Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]:
> this warning exist in v3.19-rc6 and does not in v3.18. Bisection
> points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait".
> I have two machines with integrated Intel graphics and the problem
> happens only on the old one with  GM965 chipset and X3100 integrated graphics.

I see this too, since v3.19-rc1, on an (outdated) ThinkPad X41.

> backtrace information:
> 
> [   31.780813] WARNING: CPU: 0 PID: 718 at drivers/gpu/drm/drm_irq.c:1077 
> drm_wait_one_vblank+0x33/0x141 [drm]()

But it also prints
vblank not available on crtc 0, ret=-22

after the WARNING line, on that machine.

> [   31.780815] Modules linked in: ecb(E) i915(E+) snd_hda_codec_generic(E) 
> coretemp(E) btusb(E) kvm_intel(E) snd_hda_intel(E) snd_hda_controller(E) 
> kvm(E) drm_kms_helper(E) snd_hda_code
> c(E) snd_pcsp(E) bluetooth(E) snd_hwdep(E) drm(E) lpc_ich(E) evdev(E) 
> mfd_core(E) snd_pcm(E) snd_timer(E) snd(E) psmouse(E) serio_raw(E) 
> i2c_algo_bit(E) i2c_i801(E) rfkill(E) soundcore(
>   
>   
>  E) battery(E) button(E) video(E) ac(E) 
> i2ccore(E) acpi_cpufreq(E) processor(E) fuse(E) parport_pc(E) ppdev(E) lp(E) 
> parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E) sd_mod(E) a
> ta_generic(E) ahci(E) libahci(E) sdhci_pci(E) sdhci(E) firewire_ohci(E) 
> b44(E) mii(E) ssb(E) ata_piix(E) firewire_core(E) crc_itu_t(E) mmc_core(E) 
> libphy(E) libata(E) scsi_mod(E) xhci_h
> cd(E) ehci_pci(E) uhci_hcd(E) ehci_hcd(E) usbcore(E) usb_common(E) thermal(E)
> [   31.780862]  thermal_sys(E)
> [   31.780866] CPU: 0 PID: 718 Comm: kworker/u4:3 Tainted: GE  
> 3.17.0-rc5-150116--00578-g51e31d4 #16
> [   31.780868] Hardware name: Dell Inc. Vostro 1500 
> /0NX907, BIOS A06 04/21/2008
> [   31.780873] Workqueue: events_unbound async_run_entry_fn
> [   31.780875]   a0544b9d 813d4e81 
> 
> [   31.780879]  8103dec3 8800d84e0068 a0521c73 
> 00070008
> [   31.780882]  8800d84e 8801973e0800  
> 6014
> [   31.780886] Call Trace:
> [   31.780890]  [] ? dump_stack+0x4a/0x75
> [   31.780894]  [] ? warn_slowpath_common+0x7e/0x97
> [   31.781050]  [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [   31.781078]  [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [   31.781122]  [] ? intel_enable_tv+0x22/0x58 [i915]
> [   31.781153]  [] ? i9xx_crtc_enable+0x33b/0x397 [i915]
> [   31.781184]  [] ? __intel_set_mode+0x1160/0x1209 [i915]
> [   31.781216]  [] ? intel_set_mode+0x12/0x2c [i915]
> [   31.781247]  [] ? intel_get_load_detect_pipe+0x367/0x408 
> [i915]
> [   31.781281]  [] ? intel_tv_detect+0x103/0x444 [i915]
> [   31.781289]  [] ? 
> drm_helper_probe_single_connector_modes_merge_bits+0xc0/0x327 [drm_kms_helper]
> [   31.781296]  [] ? 
> drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper]
> [   31.781303]  [] ? 
> drm_fb_helper_initial_config+0x3d/0x303 [drm_kms_helper]
> [   31.781306]  [] ? async_run_entry_fn+0x5a/0x110
> [   31.781310]  [] ? process_one_work+0x194/0x292
> [   31.781313]  [] ? worker_thread+0x236/0x298
> [   31.781316]  [] ? process_scheduled_works+0x2a/0x2a
> [   31.781319]  [] ? kthread+0x9e/0xa6
> [   31.781322]  [] ? kthread_freezable_should_stop+0x36/0x36
> [   31.781326]  [] ? ret_from_fork+0x7c/0xb0
> [   31.781329]  [] ? kthread_freezable_should_stop+0x36/0x36
> [   31.782726] ---[ end trace e2b78017f1a10054 ]---
> 
> 
> lspci:
> 
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 
> GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 0c)
> 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 
> Integrated Graphics Controller (secondary) [8086:2a03] (rev 0c)

A naive revert, on top of v3.19-rc7, of commit 51e31d49c890552
("drm/i915: Use generic vblank wait") clashes with later changes. It
seems intel_wait_for_vblank() became an one line inline function in a
later commit.

Anyhow, is a fix for this queued somewhere?

Thanks,


Paul Bolle

[PATCH v5] drm/rockchip: vop: power off until vop standby take effect

2015-02-04 Thread Mark Yao

Vop standby will take effect at end of current frame,
if dsp_hold_valid_irq happen, it means vop standby complete.

we must wait standby complete when we want to disable aclk,
if not, memory bus maybe dead.

Reviewed-by: Heiko Stuebner 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Mark Yao 
---
Changes in v5:
- reuse WARN_ON with if (cond) so that WARN_ON have a chance to output.

Changes in v4:
- fix comment syntax error

Changes in v3:
- if vop write vop regs when vop clocks is disabled, WARN_ON maybe
  have no chance to do crash dump, so reuse BUG_ON.
- dsp hold irq only happen when standby bit 0->1 take effect, no need
  to do completion check.

Changes in v2:
- use WARN_ON instead of BUG_ON.

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   75 ++-
 1 file changed, 62 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb25836..20fa8a1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -89,6 +89,7 @@ struct vop {
/* mutex vsync_ work */
struct mutex vsync_mutex;
bool vsync_work_pending;
+   struct completion dsp_hold_completion;

const struct vop_data *data;

@@ -382,6 +383,36 @@ static bool is_alpha_support(uint32_t format)
}
 }

+static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(&vop->irq_lock, flags);
+
+   vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+  DSP_HOLD_VALID_INTR_EN(1));
+
+   spin_unlock_irqrestore(&vop->irq_lock, flags);
+}
+
+static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(&vop->irq_lock, flags);
+
+   vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+  DSP_HOLD_VALID_INTR_EN(0));
+
+   spin_unlock_irqrestore(&vop->irq_lock, flags);
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
@@ -454,26 +485,36 @@ static void vop_disable(struct drm_crtc *crtc)

drm_vblank_off(crtc->dev, vop->pipe);

-   disable_irq(vop->irq);
-
/*
-* TODO: Since standby doesn't take effect until the next vblank,
-* when we turn off dclk below, the vop is probably still active.
+* Vop standby will take effect at end of current frame,
+* if dsp hold valid irq happen, it means standby complete.
+*
+* we must wait standby complete when we want to disable aclk,
+* if not, memory bus maybe dead.
 */
+   reinit_completion(&vop->dsp_hold_completion);
+   vop_dsp_hold_valid_irq_enable(vop);
+
spin_lock(&vop->reg_lock);

VOP_CTRL_SET(vop, standby, 1);

spin_unlock(&vop->reg_lock);

+   wait_for_completion(&vop->dsp_hold_completion);
+
+   vop_dsp_hold_valid_irq_disable(vop);
+
+   disable_irq(vop->irq);
+
vop->is_enabled = false;
+
/*
-* disable dclk to stop frame scan, so we can safely detach iommu,
+* vop standby complete, so iommu detach is safe.
 */
-   clk_disable(vop->dclk);
-
rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev);

+   clk_disable(vop->dclk);
clk_disable(vop->aclk);
clk_disable(vop->hclk);
 }
@@ -1086,6 +1127,7 @@ static irqreturn_t vop_isr(int irq, void *data)
struct vop *vop = data;
uint32_t intr0_reg, active_irqs;
unsigned long flags;
+   int ret = IRQ_NONE;

/*
 * INTR_CTRL0 register has interrupt status, enable and clear bits, we
@@ -1104,15 +1146,23 @@ static irqreturn_t vop_isr(int irq, void *data)
if (!active_irqs)
return IRQ_NONE;

-   /* Only Frame Start Interrupt is enabled; other irqs are spurious. */
-   if (!(active_irqs & FS_INTR)) {
-   DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs);
-   return IRQ_NONE;
+   if (active_irqs & DSP_HOLD_VALID_INTR) {
+   complete(&vop->dsp_hold_completion);
+   active_irqs &= ~DSP_HOLD_VALID_INTR;
+   ret = IRQ_HANDLED;
}

-   drm_handle_vblank(vop->drm_dev, vop->pipe);
+   if (active_irqs & FS_INTR) {
+   drm_handle_vblank(vop->drm_dev, vop->pipe);
+   active_irqs &= ~FS_INTR;
+   ret = (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED;
+   }

-   return (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED;
+   /* Unhandled irqs are spurious. */
+   if (active_irqs)
+   DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs);
+
+   return ret;
 }

 static int vop_create_crtc(struct vop *vop)
@@ -1194,6 +1244,7 @@ static int v

[PULL] drm-intel-next

Hi Dave,

As discussed on irc one more pull for a bit of atomic goodies. Otherwise
just random all over. Plus one fixup on top of the tag because we've
accidentally broken thread-safety for the hangcheck.

drm-intel-next-2015-01-30:
- chv rps improvements from Ville
- atomic state handling prep work from Ander
- execlist request tracking refactoring from Nick Hoath
- forcewake code consolidation from Chris&Mika
- fastboot plane config refactoring and skl support from Damien
- some more skl pm patches all over (Damien)
- refactor dsi code to use drm dsi helpers and drm_panel infrastructure (Jani)
- first cut at experimental atomic plane updates (Matt Roper)
- piles of smaller things all over, as usual

>From now on Jani will take care of 3.20, and apparently he already has
some fun with amdkfd conflicts ...

Cheers, Daniel


The following changes since commit 1da30627fc511a57c9bd23a02c97f0576379f761:

  drm: Add rotation value to plane state (2015-01-27 18:48:53 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel drm-intel-next

for you to fetch changes up to b838cbee0d6f0234406e435032b2304f3d05515d:

  drm/i915: Remove bogus locking check in the hangcheck code (2015-02-03 
17:13:04 +0100)


Ander Conselvan de Oliveira (9):
  drm/i915: Rename struct intel_crtc_config to intel_crtc_state
  drm/i915: Embedded struct drm_crtc_state in intel_crtc_state
  drm/i915: Pass new_config down do crtc_compute_clock
  drm/i915: Use local pipe_config varariable when available
  drm/i915: Make intel_crtc->config a pointer
  drm/i915: Improve how the memory for crtc state is allocated
  drm/i915: Keep drm_crtc->state in sync with intel_crtc->config
  drm/i915: Split shared dpll setup out of __intel_set_mode()
  drm/i915: Use pipe_config's cpu_transcoder for reading encoder hw state

Chris Wilson (9):
  drm/i915: Rebalance runtime pm vs forcewake
  drm/i915: Assert that runtime pm is active on user fw access
  drm/i915: Skip uncore lock on earlier gens
  drm/i915: Reduce duplicated forcewake logic
  drm/i915: Performed deferred clflush inside set-cache-level
  agp/intel: Serialise after GTT updates
  drm/i915: Convert hangcheck from a timer into a delayed work item
  drm/i915: Display current hangcheck status in debugfs
  Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"

Damien Lespiau (12):
  drm/i915/skl: Retrieve the frequency limits
  drm/i915: Change plane_config to store a tiling_mode
  drm/i915: Use a common function for computing the fb height alignment
  drm/i915: Unclutter the get_plane() functions
  drm/i915: Don't use crtc->plane in ILK+ get_config()
  drm/i915: Use pipe_name() in the get_plane_config() functions
  drm/i915: Make intel_format_to_fourcc() static
  drm/i915/skl: intel_format_to_fourcc() doesn't work for SKL planes
  drm/i915/skl: Provide a Skylake version of get_plane_config()
  drm/i915: Rename plane_config to initial_plane_config
  drm/i915: Fix kzalloc() smatch warnings in get_initial_plane_config()
  drm/i915: Use sizeof(*fb) not sizeof(struct ...) in 
get_initial_plane_config()

Daniel Vetter (4):
  drm/i915: Simplify flush_cpu_write_domain
  drm/i915: Use symbolic irqreturn for ->hpd_pulse
  drm/i915: Update DRIVER_DATE to 20150130
  drm/i915: Remove bogus locking check in the hangcheck code

Deepak S (3):
  drm/i915/chv: Populate total EU count on Cherryview
  drm/i915: Increase the range of sideband address.
  drm/i915: New offset for reading frequencies on CHV.

Jani Nikula (12):
  drm/i915/dsi: call dpi_send_cmd() for each dsi port at a higher level
  drm/i915/dsi: set max return packet size for each dsi port
  drm/i915/dsi: move wait_for_dsi_fifo_empty to intel_dsi.c
  drm/i915/dsi: call wait_for_dsi_fifo_empty() for each dsi port
  drm/i915/dsi: remove unnecessary dsi device callbacks
  drm/i915/dsi: add some constness to vbt panel driver
  drm/i915/dsi: switch to drm_panel interface
  drm/i915/dsi: add drm mipi dsi host support
  drm/i915/dsi: make the vbt panel driver use mipi_dsi_device for transfers
  drm/i915/dsi: remove old read/write functions in favor of new stuff
  drm/i915/dsi: move dpi_send_cmd() to intel_dsi.c and make it static
  drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein

Jesse Barnes (1):
  drm/i915/skl: add turbo support

Kumar Amit Mehta (1):
  drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment

Matt Roper (10):
  drm/i915: Don't cleanup plane state in intel_plane_destroy()
  drm/i915: Move rotation from intel_plane to drm_plane_state
  drm/i915: Consolidate plane handler vtables
  drm/i915: Add .atomic_{get, set}_property() entrypoints to planes
  drm/i915: Add main atomic entrypo

Atmel HLCDC + Atomic operations: hook for internal atomic state change

2015-02-04 Thread Rob Clark

On Wed, Feb 4, 2015 at 12:23 PM, Boris Brezillon
 wrote:
> Hello,
>
> I'm currently adding support for atomic operations (or atomic
> modesetting) in the Atmel HLCDC driver.
> Everything is pretty much in place, and all the features provided by the
> current driver are working as expected.
> However, there's one feature I'd like to add (actually I was hoping
> atomic support could help me deal with this feature), and I not sure
> how to do it.
>
> The HLCDC IP provides a way to discard a specific area on the primary
> plane (in case at least one of the overlay is activated and alpha
> blending is disabled).
> Doing this will reduce the amount of data to transfer from the main
> memory to the Display Controller, and thus alleviate the load on the
> memory bus (since this link is quite limited on such hardware,
> this kind of optimization is really important).
>
> My problem here is that there is no way, in the current atomic
> implementation, to internally ask for a plane state modification.
>
> Is there a plan to add such hooks that would be called after the
> requested state modifications (i.e. operations done before the
> drm_atomic_commit call in all helper functions), but before the atomic
> checks begin (i.e. call to drm_atomic_check_only) ?
> Such hooks would let me ask for a primary plane update (modifying the
> discard area property) if needed.

Maybe just wrap drm_atomic_helper_commit() w/ your own fxn that did
extra fixup and then called drm_atomic_helper_commit()?

BR,
-R

> Maybe I'm totally mistaken in my approach to solve this problem, so
> please let me know if you see other solutions.
>
> Thanks.
>
> Best Regards,
>
> Boris
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

[Bug 85564] Dead Island rendering issues

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

--- Comment #10 from Laurent carlier  ---
I can see this in some lines:
m_Platform = OpenGL4

Probably the origin of the crash

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

[Bug 85564] Dead Island rendering issues

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

--- Comment #9 from Laurent carlier  ---
Created attachment 113154
  --> https://bugs.freedesktop.org/attachment.cgi?id=113154&action=edit
gdb backtrace

backtrace grabbed with gdb attached to the pid

-- 
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/20150204/a4020ea8/attachment.html>

[RFC v3 3/4] drm/i915: Add new panel driver based on crystal cove pmic

2015-02-04 Thread Shobhit Kumar

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/03/2015 06:46 PM, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:48:12PM +0530, Shobhit Kumar wrote:
>> This driver provides support for the "crystal_cove_panel" cell
>> device. On BYT-T pmic has to be used to enable/disable panel.
>> 
>> v2: Addressed Jani's comments - Moved inside i915 - Correct
>> licensing - Remove unused stuff - Do not initialize
>> prepare/unprepare as they are not needed as of now - Correct
>> backlight off delay
>> 
>> Signed-off-by: Shobhit Kumar  --- 
>> drivers/gpu/drm/i915/Kconfig   |  12 ++ 
>> drivers/gpu/drm/i915/Makefile  |   3 + 
>> drivers/gpu/drm/i915/intel-panel-crystalcove.c | 159
>> + 3 files changed, 174 insertions(+) 
>> create mode 100644
>> drivers/gpu/drm/i915/intel-panel-crystalcove.c
>> 
>> diff --git a/drivers/gpu/drm/i915/Kconfig
>> b/drivers/gpu/drm/i915/Kconfig index 4e39ab3..0510ef0 100644 ---
>> a/drivers/gpu/drm/i915/Kconfig +++
>> b/drivers/gpu/drm/i915/Kconfig @@ -69,3 +69,15 @@ config
>> DRM_I915_PRELIMINARY_HW_SUPPORT option changes the default for
>> that module option.
>> 
>> If in doubt, say "N". + +config DRM_I915_PANEL_CRYSTALCOVE_PMIC +
>> bool "Enable drm panel for crystal cove pmic based control" +
>> depends on DRM_I915 +depends on DRM_PANEL +  default n
> 
> n is the default default.

Okay.

> 
>> diff --git a/drivers/gpu/drm/i915/intel-panel-crystalcove.c
>> b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
> [...]
>> +#define PMIC_PANEL_EN   0x52 +#define PMIC_PWM_EN   
>> 0x51 +#define
>> PMIC_BKL_EN  0x4B +#define PMIC_PWM_LEVEL0x4E
> 
> These look like they should be GPIOs/regulators and a PWM instead.
> So I think you'd need to further split up the MFD device to
> accomodate for this.

Yes these are I2C addresses for the PWM and Panel control registers on
PMIC. The PMIC driver is a I2C slave device and all control for
Crystal cove is through i2c. Till now there is no situation where
either of the two PWM and Panel control are through interfaces other
than PMIC. Either both are through PMIC or none. With that in mind, I
think can have one common MFD device for PWM and Panel control. Also I
was planning to add Backlight control via backlight class driver in
this same panel driver.

> 
>> +static inline struct crystalcove_panel
>> *to_crystalcove_panel(struct drm_panel *panel)
> 
> Please wrap this so it doesn't cross the 80-character boundary.
> 
>> +static int crystalcove_panel_disable(struct drm_panel *panel) 
>> +{ + struct crystalcove_panel *p = to_crystalcove_panel(panel); 
>> + +  if (!p->enabled) +  return 0; + +   DRM_DEBUG_KMS("\n"); + 
>> +/*
>> invoke the pmic driver */ +  regmap_write(p->regmap,
>> PMIC_PANEL_EN, 0x00);
> 
> A datasheet would be really good to determine whether this is the 
> correct place to write this. There are ->prepare() and
> ->unprepare() callbacks that get the panel into a state where you
> can communicate with it. This being a DSI panel I would assume that
> you need to enable the panel to some degree so you can send DSI
> commands. So most likely this enable "GPIO" should be set in
> ->unprepare().

This is just a mechanism to enable needed signals which are routed
through PMIC, I kept the logic as per enable and disable signals in
enable/disable. But yes actually it is preparing the panel to receive
DCS commands. I can move this into prepare/unprepare. In that case
there would be no need for any enable/disable callbacks.

> 
>> +static int crystalcove_panel_enable(struct drm_panel *panel) +{ 
>> +struct crystalcove_panel *p = to_crystalcove_panel(panel); + +
>> if (p->enabled) +return 0; + +   DRM_DEBUG_KMS("\n"); + +
>> /*
>> invoke the pmic driver */ +  regmap_write(p->regmap,
>> PMIC_PANEL_EN, 0x01);
> 
> Similarly I'd expect this to go into ->prepare() to make sure that
> you can communicate with the panel after ->prepare().

Can do as I mentioned above.

> 
>> +/* Enable BKL as well */ +  regmap_write(p->regmap, PMIC_BKL_EN,
>> 0xFF);
> 
> Writing 0xff to an "enable" register seems weird. Again the
> datasheet would help in determining the right thing to do here.

Actually, I think I made a mistake in naming the register. It is
actually the PWMCLKDIV which has to be programmed as per needed
divider. I will correct this. Spec is not available in public.

> 
>> +regmap_write(p->regmap, PMIC_PWM_EN, 0x01); +   msleep(20); +
>> regmap_write(p->regmap, PMIC_PWM_LEVEL, 255);
> 
> This definitely looks like it should be a PWM driver. Also how do
> you handle backlight brightness control? You only set things to
> either full off or full on in this driver.

As of now I did just enable and disable to save power leakage during
Suspend/Resume. I am planning to add a backlight class driver as well
as pert of this itself. As I said this should be okay as either both
Panel and PWM control is

drm: sti: add DVO output connector

2015-02-04 Thread Dan Carpenter

Hello Benjamin Gaignard,

The patch f32c4c506f9b: "drm: sti: add DVO output connector" from Dec
30, 2014, leads to the following static checker warning:

drivers/gpu/drm/sti/sti_awg_utils.c:63 awg_generate_instr()
warn: no-op. '(arg << 24) >> 24'

drivers/gpu/drm/sti/sti_awg_utils.c
46  switch (opcode) {
47  case SKIP:
48  /* leave 'arg' + 1 pixel elapsing without 
changing
49   * output bus */
50  arg--; /* pixel adjustment */
51  arg_tmp--;
52  
53  if (arg < 0) {
54  /* SKIP instruction not needed */
55  return 0;
56  }
57  
58  if (arg == 0) {
59  /* SKIP 0 not permitted but we want to 
skip 1
60   * pixel. So we transform SKIP into SET
61   * instruction */
62  opcode = SET;
63  arg = (arg << 24) >> 24;

64  arg &= (0x0ff);
^^^
Since "arg" is zero then the shift/mask operations are a no-op.  I'm not
sure what was intented.

65  break;
66  }
67  
68  mux = 0;
69  data_enable = 0;
70  arg = (arg << 22) >> 22;
71  arg &= (0x3ff);
72  break;
73  case REPEAT:

regards,
dan carpenter

[PATCH] drm: Use static attribute groups for managing connector sysfs entries

2015-02-04 Thread Takashi Iwai

Instead of manual calls of device_create_file() and
device_remove_file(), assign the static attribute groups to the device
with device_create_with_groups().  The conditionally built sysfs
entries are handled via is_visible callback.

This simplifies the code and also avoids the possible races.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/drm_sysfs.c | 132 ++--
 1 file changed, 67 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index cc3d6d6d67e0..5c99d3773212 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -339,19 +339,51 @@ static ssize_t select_subconnector_show(struct device 
*device,
drm_get_dvi_i_select_name((int)subconnector));
 }

-static struct device_attribute connector_attrs[] = {
-   __ATTR_RO(status),
-   __ATTR_RO(enabled),
-   __ATTR_RO(dpms),
-   __ATTR_RO(modes),
+static DEVICE_ATTR_RO(status);
+static DEVICE_ATTR_RO(enabled);
+static DEVICE_ATTR_RO(dpms);
+static DEVICE_ATTR_RO(modes);
+
+static struct attribute *connector_dev_attrs[] = {
+   &dev_attr_status.attr,
+   &dev_attr_enabled.attr,
+   &dev_attr_dpms.attr,
+   &dev_attr_modes.attr,
+   NULL
 };

 /* These attributes are for both DVI-I connectors and all types of tv-out. */
-static struct device_attribute connector_attrs_opt1[] = {
-   __ATTR_RO(subconnector),
-   __ATTR_RO(select_subconnector),
+static DEVICE_ATTR_RO(subconnector);
+static DEVICE_ATTR_RO(select_subconnector);
+
+static struct attribute *connector_opt_dev_attrs[] = {
+   &dev_attr_subconnector.attr,
+   &dev_attr_select_subconnector.attr,
+   NULL
 };

+static umode_t connector_opt_dev_is_visible(struct kobject *kobj,
+   struct attribute *attr, int idx)
+{
+   struct device *dev = kobj_to_dev(kobj);
+   struct drm_connector *connector = to_drm_connector(dev);
+
+   /*
+* In the long run it maybe a good idea to make one set of
+* optionals per connector type.
+*/
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_DVII:
+   case DRM_MODE_CONNECTOR_Composite:
+   case DRM_MODE_CONNECTOR_SVIDEO:
+   case DRM_MODE_CONNECTOR_Component:
+   case DRM_MODE_CONNECTOR_TV:
+   return attr->mode;
+   }
+
+   return 0;
+}
+
 static struct bin_attribute edid_attr = {
.attr.name = "edid",
.attr.mode = 0444,
@@ -359,6 +391,27 @@ static struct bin_attribute edid_attr = {
.read = edid_show,
 };

+static struct bin_attribute *connector_bin_attrs[] = {
+   &edid_attr,
+   NULL
+};
+
+static const struct attribute_group connector_dev_group = {
+   .attrs = connector_dev_attrs,
+   .bin_attrs = connector_bin_attrs,
+};
+
+static const struct attribute_group connector_opt_dev_group = {
+   .attrs = connector_opt_dev_attrs,
+   .is_visible = connector_opt_dev_is_visible,
+};
+
+static const struct attribute_group *connector_dev_groups[] = {
+   &connector_dev_group,
+   &connector_opt_dev_group,
+   NULL
+};
+
 /**
  * drm_sysfs_connector_add - add a connector to sysfs
  * @connector: connector to add
@@ -371,73 +424,27 @@ static struct bin_attribute edid_attr = {
 int drm_sysfs_connector_add(struct drm_connector *connector)
 {
struct drm_device *dev = connector->dev;
-   int attr_cnt = 0;
-   int opt_cnt = 0;
-   int i;
-   int ret;

if (connector->kdev)
return 0;

-   connector->kdev = device_create(drm_class, dev->primary->kdev,
-   0, connector, "card%d-%s",
-   dev->primary->index, connector->name);
+   connector->kdev =
+   device_create_with_groups(drm_class, dev->primary->kdev, 0,
+ connector, connector_dev_groups,
+ "card%d-%s", dev->primary->index,
+ connector->name);
DRM_DEBUG("adding \"%s\" to sysfs\n",
  connector->name);

if (IS_ERR(connector->kdev)) {
DRM_ERROR("failed to register connector device: %ld\n", 
PTR_ERR(connector->kdev));
-   ret = PTR_ERR(connector->kdev);
-   goto out;
-   }
-
-   /* Standard attributes */
-
-   for (attr_cnt = 0; attr_cnt < ARRAY_SIZE(connector_attrs); attr_cnt++) {
-   ret = device_create_file(connector->kdev, 
&connector_attrs[attr_cnt]);
-   if (ret)
-   goto err_out_files;
+   return PTR_ERR(connector->kdev);
}

-   /* Optional attributes */
-   /*
-* In the long run it maybe a good idea to make one set of
-* optionals per connector type.
-*/
-   switch (connector->connector_type) {
-   c

[PATCH] drm/rockchip: vop: power off until vop standby take effect

2015-02-04 Thread Mark yao

On 2015å¹´02æ04æ¥ 11:48, Daniel Kurtz wrote:
> On Feb 4, 2015 11:38 AM, "Mark yao"  wrote:
>> On 2015å¹´02æ02æ¥ 15:53, Daniel Vetter wrote:
>>> On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote:
 On 2015å¹´02æ02æ¥ 10:07, Daniel Kurtz wrote:
> Hi Mark, Heiko,
>
> On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao  
> wrote:
>> Vop standby will take effect end of current frame,
>> if dsp_hold_valid_irq happen, it means vop standby complete.
>>
>> we must wait standby complete when we want to disable aclk,
>> if not, memory bus maybe dead.
>>
>> Signed-off-by: Mark Yao 
>> ---
>>drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   76 
>> ++-
>>1 file changed, 63 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index fb25836..47ea61f 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -89,6 +89,7 @@ struct vop {
>>   /* mutex vsync_ work */
>>   struct mutex vsync_mutex;
>>   bool vsync_work_pending;
>> +   struct completion dsp_hold_completion;
>>
>>   const struct vop_data *data;
>>
>> @@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
>>   }
>>}
>>
>> +static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
>> +{
>> +   unsigned long flags;
>> +
>> +   BUG_ON(!vop->is_enabled);
> Re: Heiko "use a WARN_ON":
>
> If the VOP clock is off, then the system will just hang when trying to
> write the VOP register so in this case, BUG_ON gives a more reliable
> crash dump than the hang.
 In this way, you are right, if vop clocks is disabled, write vop 
 register
 will hang system, and the WARN_ON
>>> if (WARN_ON(cond))
>>>  return;
>>>
>>> is what we commonly use in i915. Because it's really not any good to use
>>> BUG_ON in drm drivers, at least if you expect anyone to use fbcon on top
>>> of it (i.e. anything even remotely resembling a normal distro): Then the
>>> intial modeset is all done under console_lock, which means that _none_ of
>>> your BUG_ON will ever get out over serial console.
>>>
>>> The problem is fbcon locking, but no fool yet signed up to fix it (it's
>>> horrible, I looked ...).
>>> -Daniel
>> I know this problem, if fbcon locking, and BUG_ON, we can't get any log from 
>> serial console, Trouble
>> me many times. So know, if no drm log output, the first thing I do is remove 
>> the fbcon lock, and then
>> we can see the crash dump.
>>
>> But here, I expect to use BUG_ON, because if BUG happen, vop register will 
>> hang system, and WARN_ON
>> may be have no chance to output.
> Yeah, but danvet is suggesting we just return immediately on the
> WARN_ON condition, to avoid accessing the vop registers and hanging.
>
> Thus, the WARN_ON will have a chance to put out (unless the early
> return path goes off and finds some other unprotected path goes to
> access unlocked registers).
>
> -Dan
All right, I got it.
>> Mark
>>
>
>


-- 
ï¼ark Yao å§æºæ

Rockchip ç¦å·çè¯å¾®çµåæéå¬å¸

Fuzhou Headquarters

Addr:No.21 Building, A District, Fuzhou

Software Park, 89 Soft Avenue, Tongpan Road,

Gulou District, Fuzhou (350003)

å°å:ç¦å»ºçç¦å·å¸éçè·¯è½¯ä»¶å¤§é89å·è½¯ä»¶åAåº21å·æ¥¼ 
(350003)

Tel:ï¼86-0591ï¼83991906 - 8296

E-mail:mark.yao at rock-chips.com

[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal

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

--- Comment #2 from Marek OlÅ¡Ã¡k  ---
Does the issue occur in any freely-available Steam game like Team Fortress 2
and DOTA 2? If not, could you please create an apitrace file reproducing the
issue?

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

[PATCH] drm/rockchip: vop: power off until vop standby take effect

2015-02-04 Thread Daniel Kurtz

On Feb 4, 2015 11:38 AM, "Mark yao"  wrote:
>
> On 2015å¹´02æ02æ¥ 15:53, Daniel Vetter wrote:
>>
>> On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote:
>>>
>>> On 2015å¹´02æ02æ¥ 10:07, Daniel Kurtz wrote:

 Hi Mark, Heiko,

 On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao  
 wrote:
>
> Vop standby will take effect end of current frame,
> if dsp_hold_valid_irq happen, it means vop standby complete.
>
> we must wait standby complete when we want to disable aclk,
> if not, memory bus maybe dead.
>
> Signed-off-by: Mark Yao 
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   76 
> ++-
>   1 file changed, 63 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb25836..47ea61f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -89,6 +89,7 @@ struct vop {
>  /* mutex vsync_ work */
>  struct mutex vsync_mutex;
>  bool vsync_work_pending;
> +   struct completion dsp_hold_completion;
>
>  const struct vop_data *data;
>
> @@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
>  }
>   }
>
> +static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
> +{
> +   unsigned long flags;
> +
> +   BUG_ON(!vop->is_enabled);

 Re: Heiko "use a WARN_ON":

 If the VOP clock is off, then the system will just hang when trying to
 write the VOP register so in this case, BUG_ON gives a more reliable
 crash dump than the hang.
>>>
>>>In this way, you are right, if vop clocks is disabled, write vop register
>>> will hang system, and the WARN_ON
>>
>> if (WARN_ON(cond))
>> return;
>>
>> is what we commonly use in i915. Because it's really not any good to use
>> BUG_ON in drm drivers, at least if you expect anyone to use fbcon on top
>> of it (i.e. anything even remotely resembling a normal distro): Then the
>> intial modeset is all done under console_lock, which means that _none_ of
>> your BUG_ON will ever get out over serial console.
>>
>> The problem is fbcon locking, but no fool yet signed up to fix it (it's
>> horrible, I looked ...).
>> -Daniel
>
> I know this problem, if fbcon locking, and BUG_ON, we can't get any log from 
> serial console, Trouble
> me many times. So know, if no drm log output, the first thing I do is remove 
> the fbcon lock, and then
> we can see the crash dump.
>
> But here, I expect to use BUG_ON, because if BUG happen, vop register will 
> hang system, and WARN_ON
> may be have no chance to output.

Yeah, but danvet is suggesting we just return immediately on the
WARN_ON condition, to avoid accessing the vop registers and hanging.

Thus, the WARN_ON will have a chance to put out (unless the early
return path goes off and finds some other unprotected path goes to
access unlocked registers).

-Dan

>
> Mark
>

[PATCH v4] drm/rockchip: vop: power off until vop standby take effect

2015-02-04 Thread Mark Yao

Vop standby will take effect at end of current frame,
if dsp_hold_valid_irq happen, it means vop standby complete.

we must wait standby complete when we want to disable aclk,
if not, memory bus maybe dead.

Reviewed-by: Heiko Stuebner 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Mark Yao 
---
Changes in v4:
- fix comment syntax error

Changes in v3:
- if vop write vop regs when vop clocks is disabled, WARN_ON maybe
  have no chance to do crash dump, so reuse BUG_ON.
- dsp hold irq only happen when standby bit 0->1 take effect, no need
  to do completion check.

Changes in v2:
- use WARN_ON instead of BUG_ON.

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   75 ++-
 1 file changed, 62 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb25836..8032071 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -89,6 +89,7 @@ struct vop {
/* mutex vsync_ work */
struct mutex vsync_mutex;
bool vsync_work_pending;
+   struct completion dsp_hold_completion;

const struct vop_data *data;

@@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
}
 }

+static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
+{
+   unsigned long flags;
+
+   BUG_ON(!vop->is_enabled);
+
+   spin_lock_irqsave(&vop->irq_lock, flags);
+
+   vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+  DSP_HOLD_VALID_INTR_EN(1));
+
+   spin_unlock_irqrestore(&vop->irq_lock, flags);
+}
+
+static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
+{
+   unsigned long flags;
+
+   BUG_ON(!vop->is_enabled);
+
+   spin_lock_irqsave(&vop->irq_lock, flags);
+
+   vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
+  DSP_HOLD_VALID_INTR_EN(0));
+
+   spin_unlock_irqrestore(&vop->irq_lock, flags);
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
@@ -454,26 +483,36 @@ static void vop_disable(struct drm_crtc *crtc)

drm_vblank_off(crtc->dev, vop->pipe);

-   disable_irq(vop->irq);
-
/*
-* TODO: Since standby doesn't take effect until the next vblank,
-* when we turn off dclk below, the vop is probably still active.
+* Vop standby will take effect at end of current frame,
+* if dsp hold valid irq happen, it means standby complete.
+*
+* we must wait standby complete when we want to disable aclk,
+* if not, memory bus maybe dead.
 */
+   reinit_completion(&vop->dsp_hold_completion);
+   vop_dsp_hold_valid_irq_enable(vop);
+
spin_lock(&vop->reg_lock);

VOP_CTRL_SET(vop, standby, 1);

spin_unlock(&vop->reg_lock);

+   wait_for_completion(&vop->dsp_hold_completion);
+
+   vop_dsp_hold_valid_irq_disable(vop);
+
+   disable_irq(vop->irq);
+
vop->is_enabled = false;
+
/*
-* disable dclk to stop frame scan, so we can safely detach iommu,
+* vop standby complete, so iommu detach is safe.
 */
-   clk_disable(vop->dclk);
-
rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev);

+   clk_disable(vop->dclk);
clk_disable(vop->aclk);
clk_disable(vop->hclk);
 }
@@ -1086,6 +1125,7 @@ static irqreturn_t vop_isr(int irq, void *data)
struct vop *vop = data;
uint32_t intr0_reg, active_irqs;
unsigned long flags;
+   int ret = IRQ_NONE;

/*
 * INTR_CTRL0 register has interrupt status, enable and clear bits, we
@@ -1104,15 +1144,23 @@ static irqreturn_t vop_isr(int irq, void *data)
if (!active_irqs)
return IRQ_NONE;

-   /* Only Frame Start Interrupt is enabled; other irqs are spurious. */
-   if (!(active_irqs & FS_INTR)) {
-   DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs);
-   return IRQ_NONE;
+   if (active_irqs & DSP_HOLD_VALID_INTR) {
+   complete(&vop->dsp_hold_completion);
+   active_irqs &= ~DSP_HOLD_VALID_INTR;
+   ret = IRQ_HANDLED;
}

-   drm_handle_vblank(vop->drm_dev, vop->pipe);
+   if (active_irqs & FS_INTR) {
+   drm_handle_vblank(vop->drm_dev, vop->pipe);
+   active_irqs &= ~FS_INTR;
+   ret = (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED;
+   }

-   return (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED;
+   /* Unhandled irqs are spurious. */
+   if (active_irqs)
+   DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs);
+
+   return ret;
 }

 static int vop_create_crtc(struct vop *vop)
@@ -1194,6 +1242,7 @@ static int vop_create_crtc(struct vop *vop)
goto err_cleanup_crtc;
}

+   init_completion(&vop->dsp_hold_completion);
crtc

[PATCH] drm/rockchip: vop: power off until vop standby take effect

2015-02-04 Thread Mark yao

On 2015å¹´02æ02æ¥ 15:53, Daniel Vetter wrote:
> On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote:
>> On 2015å¹´02æ02æ¥ 10:07, Daniel Kurtz wrote:
>>> Hi Mark, Heiko,
>>>
>>> On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao  
>>> wrote:
 Vop standby will take effect end of current frame,
 if dsp_hold_valid_irq happen, it means vop standby complete.

 we must wait standby complete when we want to disable aclk,
 if not, memory bus maybe dead.

 Signed-off-by: Mark Yao 
 ---
   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   76 
 ++-
   1 file changed, 63 insertions(+), 13 deletions(-)

 diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
 b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 index fb25836..47ea61f 100644
 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 @@ -89,6 +89,7 @@ struct vop {
  /* mutex vsync_ work */
  struct mutex vsync_mutex;
  bool vsync_work_pending;
 +   struct completion dsp_hold_completion;

  const struct vop_data *data;

 @@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format)
  }
   }

 +static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
 +{
 +   unsigned long flags;
 +
 +   BUG_ON(!vop->is_enabled);
>>> Re: Heiko "use a WARN_ON":
>>>
>>> If the VOP clock is off, then the system will just hang when trying to
>>> write the VOP register so in this case, BUG_ON gives a more reliable
>>> crash dump than the hang.
>>In this way, you are right, if vop clocks is disabled, write vop register
>> will hang system, and the WARN_ON
> if (WARN_ON(cond))
>   return;
>
> is what we commonly use in i915. Because it's really not any good to use
> BUG_ON in drm drivers, at least if you expect anyone to use fbcon on top
> of it (i.e. anything even remotely resembling a normal distro): Then the
> intial modeset is all done under console_lock, which means that _none_ of
> your BUG_ON will ever get out over serial console.
>
> The problem is fbcon locking, but no fool yet signed up to fix it (it's
> horrible, I looked ...).
> -Daniel
I know this problem, if fbcon locking, and BUG_ON, we can't get any log 
from serial console, Trouble
me many times. So know, if no drm log output, the first thing I do is 
remove the fbcon lock, and then
we can see the crash dump.

But here, I expect to use BUG_ON, because if BUG happen, vop register 
will hang system, and WARN_ON
may be have no chance to output.

Mark

[Intel-gfx] [PATCH 1/4] drm/irq: Add drm_crtc_vblank_reset

2015-02-04 Thread Ville Syrjälä

On Tue, Feb 03, 2015 at 11:30:11AM +0100, Daniel Vetter wrote:
> At driver load we need to tell the vblank code about the state of the
> pipes, so that the logic around reject vblank_get when the pipe is off
> works correctly.
> 
> Thus far i915 used drm_vblank_off, but one of the side-effects of it
> is that it also saves the vblank counter. And for that it calls down
> into the ->get_vblank_counter hook. Which isn't really a good idea
> when the pipe is off for a few reasons:
> - With runtime pm the register might not respond.
> - If the pipe is off some datastructures might not be around or
>   unitialized.
> 
> The later is what blew up on gen3: We look at intel_crtc->config to
> compute the vblank counter, and for a disabled pipe at boot-up that's
> just not there. Thus far this was papered over by a check for
> intel_crtc->active, but I want to get rid of that (since it's fairly
> race, vblank hooks are called from all kinds of places).
> 
> So prep for that by adding a _reset functions which only does what we
> really need to be done at driver load: Mark the vblank pipe as off,
> but don't do any vblank counter saving or event flushing - neither of
> that is required.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c| 32 
>  drivers/gpu/drm/i915/intel_display.c |  4 ++--
>  include/drm/drmP.h   |  1 +
>  3 files changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 75647e7f012b..1e5fb1b994d7 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1226,6 +1226,38 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
>  EXPORT_SYMBOL(drm_crtc_vblank_off);
>  
>  /**
> + * drm_crtc_vblank_reset - reset vblank state to off on a CRTC
> + * @crtc: CRTC in question
> + *
> + * Drivers can use this function to reset the vblank state to off at load 
> time.
> + * Drivers should use this together with the drm_crtc_vblank_off() and
> + * drm_crtc_vblank_on() functions. The diffrence comparet to
> + * drm_crtc_vblank_off() is that this function doesn't save the vblank 
> counter
> + * and hence doesn't need to call any driver hooks.
> + */
> +void drm_crtc_vblank_reset(struct drm_crtc *drm_crtc)
> +{
> + struct drm_device *dev = drm_crtc->dev;
> + unsigned long irqflags;
> + int crtc = drm_crtc_index(drm_crtc);
> + struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
> +
> + spin_lock_irqsave(&dev->vbl_lock, irqflags);
> + /*
> +  * Prevent subsequent drm_vblank_get() from enabling the vblank
> +  * interrupt by bumping the refcount.
> +  */
> + if (!vblank->inmodeset) {
> + atomic_inc(&vblank->refcount);
> + vblank->inmodeset = 1;
> + }
> + spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> +
> + WARN_ON(!list_empty(&dev->vblank_event_list));
> +}
> +EXPORT_SYMBOL(drm_crtc_vblank_reset);
> +
> +/**
>   * drm_vblank_on - enable vblank events on a CRTC
>   * @dev: DRM device
>   * @crtc: CRTC in question
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 423ef959264d..f8871a184747 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13296,9 +13296,9 @@ static void intel_sanitize_crtc(struct intel_crtc 
> *crtc)
>   /* restore vblank interrupts to correct state */
>   if (crtc->active) {
>   update_scanline_offset(crtc);
> - drm_vblank_on(dev, crtc->pipe);
> + drm_crtc_vblank_on(&crtc->base);
>   } else
> - drm_vblank_off(dev, crtc->pipe);
> + drm_crtc_vblank_reset(&crtc->base);

Maybe

drm_vblank_reset()
if (active)
drm_vblank_on()

?


>  
>   /* We need to sanitize the plane -> pipe mapping first because this will
>* disable the crtc (and hence change the state) if it is wrong. Note
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index e928625a9da0..54c6ea1e5866 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -922,6 +922,7 @@ extern void drm_crtc_wait_one_vblank(struct drm_crtc 
> *crtc);
>  extern void drm_vblank_off(struct drm_device *dev, int crtc);
>  extern void drm_vblank_on(struct drm_device *dev, int crtc);
>  extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
> +extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
>  extern void drm_vblank_cleanup(struct drm_device *dev);
>  
> -- 
> 1.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH] drm: remove DRM_FORMAT_NV12MT

+Cc Inki,

Hi,

On 02/04/2015 12:48 AM, Daniel Vetter wrote:
> So this has been merged originally in
> 
> commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> Author: Seung-Woo Kim 
> Date:   Thu Dec 15 15:40:55 2011 +0900
> 
> drm: Add multi buffer plane pixel formats
> 
> which hasn't seen a lot of review really. The problem is that it's not
> a real pixel format, but just a different way to lay out NV12 pixels
> in macroblocks, i.e. a tiling format.
> 
> The new way of doing this is with the soon-to-be-merge fb modifiers.
> 
> This was brough up in some long irc discussion around the entire
> topic, as an example of where things have gone wrong. Luckily we can
> correct the mistake:
> - The kms side support for NV12MT is all dead code because
>   format_check in drm_crtc.c never accepted NV12MT.

So it was tried to support NV12MT in format_check. I really welcome the
new way.

Acked-by: Joonyoung Shim 

Thanks.

> - The gem side for the gsc support doesn't look better: The code
>   forgets to set the pixel format and makes a big mess with the tiling
>   mode bits, inadvertedly setting them all.
> 
> Conclusion: This never really worked (at least not in upstream) and
> hence we can savely correct our mistake here.
> 
> Cc: Seung-Woo Kim 
> Cc: Inki Dae 
> Cc: Kyungmin Park 
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Damien Lespiau 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 14 ++
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  6 --
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  1 -
>  drivers/gpu/drm/exynos/exynos_mixer.c |  2 --
>  include/uapi/drm/drm_fourcc.h |  3 ---
>  5 files changed, 2 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 835b6af00970..842d6b8dc3c4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -461,7 +461,6 @@ static int fimc_src_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_MSCTRL_C_INT_IN_3PLANE;
>   break;
>   case DRM_FORMAT_NV12:
> - case DRM_FORMAT_NV12MT:
>   case DRM_FORMAT_NV16:
>   cfg |= (EXYNOS_MSCTRL_ORDER2P_LSB_CBCR |
>   EXYNOS_MSCTRL_C_INT_IN_2PLANE);
> @@ -511,7 +510,6 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   case DRM_FORMAT_YVU420:
>   case DRM_FORMAT_NV12:
>   case DRM_FORMAT_NV21:
> - case DRM_FORMAT_NV12MT:
>   cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
>   break;
>   default:
> @@ -524,10 +522,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   cfg = fimc_read(ctx, EXYNOS_CIDMAPARAM);
>   cfg &= ~EXYNOS_CIDMAPARAM_R_MODE_MASK;
>  
> - if (fmt == DRM_FORMAT_NV12MT)
> - cfg |= EXYNOS_CIDMAPARAM_R_MODE_64X32;
> - else
> - cfg |= EXYNOS_CIDMAPARAM_R_MODE_LINEAR;
> + cfg |= EXYNOS_CIDMAPARAM_R_MODE_LINEAR;
>  
>   fimc_write(ctx, cfg, EXYNOS_CIDMAPARAM);
>  
> @@ -812,7 +807,6 @@ static int fimc_dst_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_CIOCTRL_YCBCR_3PLANE;
>   break;
>   case DRM_FORMAT_NV12:
> - case DRM_FORMAT_NV12MT:
>   case DRM_FORMAT_NV16:
>   cfg |= EXYNOS_CIOCTRL_ORDER2P_LSB_CBCR;
>   cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
> @@ -867,7 +861,6 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   case DRM_FORMAT_YUV420:
>   case DRM_FORMAT_YVU420:
>   case DRM_FORMAT_NV12:
> - case DRM_FORMAT_NV12MT:
>   case DRM_FORMAT_NV21:
>   cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
>   break;
> @@ -883,10 +876,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   cfg = fimc_read(ctx, EXYNOS_CIDMAPARAM);
>   cfg &= ~EXYNOS_CIDMAPARAM_W_MODE_MASK;
>  
> - if (fmt == DRM_FORMAT_NV12MT)
> - cfg |= EXYNOS_CIDMAPARAM_W_MODE_64X32;
> - else
> - cfg |= EXYNOS_CIDMAPARAM_W_MODE_LINEAR;
> + cfg |= EXYNOS_CIDMAPARAM_W_MODE_LINEAR;
>  
>   fimc_write(ctx, cfg, EXYNOS_CIDMAPARAM);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 0261468c8019..8040ed2a831f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -542,9 +542,6 @@ static int gsc_src_set_fmt(struct device *dev, u32 fmt)
>   cfg |= (GSC_IN_CHROMA_ORDER_CBCR |
>   GSC_IN_YUV420_2P);
>   break;
> - case DRM_FORMAT_NV12MT:
> - cfg |= (GSC_IN_TILE_C_16x8 | GSC_IN_TILE_MODE);
> - break;
>   default:
>   dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
> @@ -809,9 +806,6 @@ static int g

[RFC v3 2/4] mfd: Add a new cell device for panel controlled by crystal cove pmic

2015-02-04 Thread Shobhit Kumar

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/03/2015 06:35 PM, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:48:11PM +0530, Shobhit Kumar wrote:
>> On BYT-T configuration, panel enable/disable signals are routed
>> through PMIC. Add a cell device for the same.
>> 
>> Signed-off-by: Shobhit Kumar  --- 
>> drivers/mfd/intel_soc_pmic_crc.c | 3 +++ 1 file changed, 3
>> insertions(+)
>> 
>> diff --git a/drivers/mfd/intel_soc_pmic_crc.c
>> b/drivers/mfd/intel_soc_pmic_crc.c index c85e2ec..c8ccc24 100644 
>> --- a/drivers/mfd/intel_soc_pmic_crc.c +++
>> b/drivers/mfd/intel_soc_pmic_crc.c @@ -109,6 +109,9 @@ static
>> struct mfd_cell crystal_cove_dev[] = { { .name =
>> "crystal_cove_pmic", }, +{ + .name = "crystal_cove_panel", +
>> }, };
>> 
>> static struct regmap_config crystal_cove_regmap_config = {
> 
> This doesn't look at all right. A PMIC doesn't typically contain a
> panel so this likely is a wrong description of the hardware. Is the
> datasheet for the Crystal Cove PMIC available somewhere? Google
> doesn't turn any- thing useful up.

Perhaps the naming makes it look like wrong, but only the Panel
En/Disable and Back light En/Disable/Control signals for any DSI
panels on this platform are routed through PMIC. Not sure if any spec
is available publicly.

Regards
Shobhit

> 
> Thierry
> 
> 
> 
> ___ dri-devel mailing
> list dri-devel at lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU0bU7AAoJEHuQFv2//5KqGh8H/jbr2hjyhW8/omPC+vEgDHTr
f8Vh8bsgtEW8YQ89YVJJ8vvioBuhBvRDx8KrxS2122Om0KS4dlEgLBICELWy2Kaw
Lf25QfZlZ9+a/OeksJSL6uhwvOwDipUaUGTVSZCZHrUlCk+8YvkFqAEqB/Xv4d5Q
3vUr7OqzTp4hk1BNrZFoXNtal41EPvN8EGcnj/Zixfph1RQhJhpvxexpds2Aznz2
SEH5huOosuGI/rjfch89hvr6yI0UWhzi6i77e5/sN0QkCa07+0imNNDUx53IXmj4
2nXaPvf7myL8WuITYQ5Bj0DNgFkn+TgR1/2THNv3IQHqiofn3bBvsdQBR+5ttzY=
=reVa
-END PGP SIGNATURE-

Kernel 3.19rc6 flooding intel_check_page_flip warnings when using compton

2015-02-04 Thread Jani Nikula

On Mon, 02 Feb 2015, Sakari Kapanen  wrote:
> Dear maintainers,
>
> On an Asus Zenbook UX32VD laptop with an i5-3317U CPU and Intel HD4000 
> graphics, I'm experiencing the following with the latest 3.19rc6 
> mainline kernel (built from the Arch Linux AUR package: 
> https://aur.archlinux.org/packages/linux-mainline/ ). The problem is 
> related to the compton compositor: https://github.com/chjj/compton

Hi, a full dmesg from boot to the problem with drm.debug=14 module
parameter set might be useful. Also, you may get fastest results if you
do a git bisect from a good to bad kernel.

BR,
Jani.


>
> Booting to X goes very normally. Then, I start compton with the command 
> `compton --backend glx`. As soon as I do that, the dmesg log starts 
> getting filled with these warnings. This is a snippet from my journalctl 
> log:
>
>  1 Feb 02 00:06:44 stroemsoe kernel: WARNING: CPU: 0 PID: 273 at 
> drivers/gpu/drm/i915/intel_display.c:9705 
> intel_check_page_flip+0xa2/0xf0 [i915]()
> 1421  Feb 02 00:06:44 stroemsoe kernel: WARN_ON(!in_irq())
>  1 Feb 02 00:06:44 stroemsoe kernel: Modules linked in:
>  2 Feb 02 00:06:44 stroemsoe kernel:  joydev mousedev msr uvcvideo 
> rtsx_usb_sdmmc videobuf2_vmalloc rtsx_usb_ms videobuf2_memops mmc_core 
> memstick videobuf2_core n ls_iso8859_1 rtsx_usb v4l2_common nls_cp437 
> videodev vfat fat coretemp intel_rapl media iosf_mbi 
> x86_pkg_temp_thermal intel_powerclamp arc4 kvm_intel kvm iwldvm   
> crct10dif_pclmul crc32_pclmul iTCO_wdt mac80211 iTCO_vendor_support 
> crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi nouveau aesni_intel 
> i915 aes_x86_64 snd  _hda_codec_realtek glue_helper lrw gf128mul 
> ablk_helper snd_hda_codec_generic cryptd iwlwifi pcspkr evdev mac_hid 
> snd_hda_intel psmouse serio_raw snd_hda_contro  ller snd_hda_codec 
> snd_hwdep mxm_wmi snd_pcm ttm snd_timer cfg80211 snd lpc_ich soundcore 
> mfd_core i2c_i801 fan int3403_thermal button i2c_algo_bit mei_me 
> drm_k  ms_helper mei drm battery tpm_tis
>  3 Feb 02 00:06:44 stroemsoe kernel:  thermal tpm shpchp ac 
> int3402_thermal i2c_core intel_gtt int3400_thermal acpi_thermal_rel 
> processor sch_fq_codel overlay ext4   crc16 mbcache jbd2 sd_mod 
> atkbd libps2 ahci libahci libata ehci_pci xhci_pci ehci_hcd xhci_hcd 
> scsi_mod usbcore usb_common i8042 serio asus_nb_wmi asus_wmi hwm  on 
> video rfkill sparse_keymap wmi led_class
>  4 Feb 02 00:06:44 stroemsoe kernel: CPU: 0 PID: 273 Comm: 
> irq/32-i915 Tainted: GW  3.19.0-1-mainline #1
>  5 Feb 02 00:06:44 stroemsoe kernel: Hardware name: ASUSTeK COMPUTER 
> INC. UX32VD/UX32VD, BIOS UX32VD.213 11/16/2012
>  6 Feb 02 00:06:44 stroemsoe kernel:   
> b983161a 8800c88afc78 8153537c
>  7 Feb 02 00:06:44 stroemsoe kernel:   
> 8800c88afcd0 8800c88afcb8 81075a9a
>  8 Feb 02 00:06:44 stroemsoe kernel:  8800c88afcb8 
> 8800c7d99000 8800c8e05000 8800c8e05000
>  9 Feb 02 00:06:44 stroemsoe kernel: Call Trace:
> 10 Feb 02 00:06:44 stroemsoe kernel:  [] 
> dump_stack+0x4c/0x6e
> 11 Feb 02 00:06:44 stroemsoe kernel:  [] 
> warn_slowpath_common+0x8a/0xc0
> 12 Feb 02 00:06:44 stroemsoe kernel:  [] 
> warn_slowpath_fmt+0x55/0x70
> 13 Feb 02 00:06:44 stroemsoe kernel:  [] 
> intel_check_page_flip+0xa2/0xf0 [i915]
> 14 Feb 02 00:06:44 stroemsoe kernel:  [] 
> ironlake_irq_handler+0x428/0x1000 [i915]
> 15 Feb 02 00:06:44 stroemsoe kernel:  [] ? 
> do_set_cpus_allowed+0x4a/0x60
> 16 Feb 02 00:06:44 stroemsoe kernel:  [] ? 
> irq_thread_fn+0x50/0x50
> 17 Feb 02 00:06:44 stroemsoe kernel:  [] 
> irq_forced_thread_fn+0x2d/0x70
> 18 Feb 02 00:06:44 stroemsoe kernel:  [] 
> irq_thread+0x157/0x180
> 19 Feb 02 00:06:44 stroemsoe kernel:  [] ? 
> wake_threads_waitq+0x30/0x30
> 20 Feb 02 00:06:44 stroemsoe kernel:  [] ? 
> irq_thread_dtor+0xc0/0xc0
> 21 Feb 02 00:06:44 stroemsoe kernel:  [] 
> kthread+0xea/0x100
> 22 Feb 02 00:06:44 stroemsoe kernel:  [] ? 
> kthread_create_on_node+0x1c0/0x1c0
> 23 Feb 02 00:06:44 stroemsoe kernel:  [] 
> ret_from_fork+0x7c/0xb0
> 24 Feb 02 00:06:44 stroemsoe kernel:  [] ? 
> kthread_create_on_node+0x1c0/0x1c0
> 25 Feb 02 00:06:44 stroemsoe kernel: ---[ end trace 46f2548918f46443 
> ]---
>
> I get about 4-5 of them per second as long as compton is running. 
> Starting compton with `--backend xrender` doesn't cause any warnings. 
> I'm using the SNA AccelMethod (the default), but switching to UXA or 
> Glamor didn't seem to have any effect. I haven't set any i915 specific 
> kernel flags.
>
> I don't see this on the current stable 3.18.5 kernel. The first time I 
> saw this was on 3.19rc3 when I tried it due to another bug in the 3.18 
> series. I haven't gone through all the 3.19 release candidates, but the 
> behaviour with 3.19rc6 seems identical to what I saw with 3.19rc3.
>
> Sakari Kapanen
>

-- 
Jani Nikula, Inte

[PATCH 6/6] drm/exynos: do not copy adjusted mode into mode during crtc mode_set

Hi,

On 02/03/2015 11:16 PM, Gustavo Padovan wrote:
> 2015-02-02 Joonyoung Shim :
> 
>> Hi,
>>
>> On 01/30/2015 11:44 PM, Gustavo Padovan wrote:
>>> Hi Joonyoung,
>>>
>>> 2015-01-30 Joonyoung Shim :
>>>
 Hi,

 On 01/23/2015 09:43 PM, Gustavo Padovan wrote:
> From: Daniel Kurtz 
>
> The 'mode' is the modeline information which specifies the ideal mode
> requested by the mode set initiator (usually userspace).
> The 'adjusted_mode' is the actual hardware mode after all the crtcs
> and encoders have had a chance to "fix it up".
>
> The adjusted_mode starts as a duplicate of the mode in
> drm_crtc_helper_set_mode(), and gets modified as required.  There is no
> reason to touch the original requested mode.
>

 Agree, but is there any side effect after this commit? Should we save
 adjusted_mode to other variable and use it?
>>>
>>> I haven't seen any. Tested on peach pi and snow. Do we have any reason to 
>>> save
>>> it now? I don't we have a user for it now.
>>>
>>
>> Because current codes use values of adjusted_mode in exynos drm hw drivers.
> 
> I fail to see where this happen. adjusted_mode is passed to to the mode_set()
> callback and drivers can use it from there as the hdmi one does for example.
> 

Currently adjusted_mode is copied to &crtc->mode, so after if to use
&crtc->mode is same with to use adjusted_mode.

Thanks.

[PATCH] drm/exynos: Fix disharmony when setting plane on/off

Hi,

On 02/03/2015 10:41 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This issue was caused by the latest exynos_update_plane() clean up
> that unified plane operations. After those changes the plane failed
> to go the On state. This patch fix this problem by doing correct account
> of exynos_crtc->enabled.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index a85c451..1dbd0e3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -119,6 +119,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
> *crtc, int x, int y,
>   struct drm_framebuffer *fb = crtc->primary->fb;
>   unsigned int crtc_w;
>   unsigned int crtc_h;
> + int ret;
>  
>   /* when framebuffer changing is requested, crtc's dpms should be on */
>   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
> @@ -129,8 +130,15 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
> *crtc, int x, int y,
>   crtc_w = fb->width - x;
>   crtc_h = fb->height - y;
>  
> - return exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
> -crtc_w, crtc_h, x, y, crtc_w, crtc_h);
> + ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
> +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
> + if (!ret)
> + return ret;
> +
> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
> +
> + return 0;
> +
>  }
>  
>  static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
> 

This patch fails to fix disharmony problem of plane on/off because it
causes the problem when do setplane.

Please test setplane like below and i get errors when terminate it.

Thanks.

# modetest -P 24:1920x1080
trying to open device 'i915'...failed.
trying to open device 'radeon'...failed.
trying to open device 'nouveau'...failed.
trying to open device 'vmwgfx'...failed.
trying to open device 'omapdrm'...failed.
trying to open device 'exynos'...success.
testing 1920x1080 at XR24 overlay plane 17

[   33.766264] PAGE FAULT occurred at 0x20801e80 by 1465.sysmmu(Page table 
base: 0x6e3f)
[   33.773310]  Lv1 entry: 0x6e228801
[   33.776748] [ cut here ]
[   33.781283] kernel BUG at drivers/iommu/exynos-iommu.c:358!
[   33.786829] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[   33.792634] Modules linked in:
[   33.795672] CPU: 0 PID: 1561 Comm: modetest Not tainted 
3.19.0-rc7-00692-g9630be0 #112
[   33.803551] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   33.809620] task: ed4a5400 ti: ed84c000 task.ti: ed84c000
[   33.815002] PC is at exynos_sysmmu_irq+0x180/0x204
[   33.819758] LR is at exynos_sysmmu_irq+0xd4/0x204
[   33.824439] pc : []lr : []psr: 6193
[   33.824439] sp : ed84dce0  ip :   fp : 000b9e4d
[   33.835875] r10: c07ae3a4  r9 : 0208  r8 : 20801e80
[   33.841074] r7 : ee3f  r6 : ee0df128  r5 : ee0df110  r4 : 
[   33.847574] r3 : 6e228801  r2 : 6e228801  r1 : ee379610  r0 : ee13a500
[   33.854074] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
user
[   33.861265] Control: 10c5387d  Table: 6e14c06a  DAC: 0015
[   33.866984] Process modetest (pid: 1561, stack limit = 0xed84c238)
[   33.873136] Stack: (0xed84dce0 to 0xed84e000)
...

[PATCH 2/2] drm/exynos: solve plane on/off disharmory issue

Hi,

On 02/03/2015 10:28 PM, Gustavo Padovan wrote:
> Hi Joonyoung,
> 
> 2015-01-29 Joonyoung Shim :
> 
>> The exynos_update_plane functions can be called from set_plane as well
>> as set_crtc and pageflip. Currently the plane displayed by set_plane
>> isn't called exynos_plane_on function and if plane is disabled, it calls
>> exynos_plane_off, so it causes disharmory of plane on/off.
>>
>> This is caused from commit e7cd8041 ("drm/exynos: Don't touch DPMS
>> when updating overlay planes").
>>
>> Make .update_plane function called only by set_plane and call
>> exynos_plane_on in it.
>>
>> Signed-off-by: Joonyoung Shim 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  4 ++--
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 -
>>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 +-
>>  3 files changed, 23 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index dac8f90..2765f7e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -129,7 +129,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
>> *crtc, int x, int y,
>>  crtc_w = fb->width - x;
>>  crtc_h = fb->height - y;
>>  
>> -return exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
>> +return exynos_plane_update(crtc->primary, crtc, fb, 0, 0,
>> crtc_w, crtc_h, x, y, crtc_w, crtc_h);
> 
> This patch goes in the opposite direction of the clean up to support atomic
> modesetting on exynos (see my patches for atomic modesetting here[0]) In my
> latest series there was an effort to unify all places we update a plane under
> exynos_update_plane() and this is a essential step for atomic modesetting.
> 

No, this change is just to rename function, actually
"exynos_plane_update" is more suitable because use exynos_plane_ prefix
like other functions of plane. This will conflict your patcheset but it
doesn't give any wrong operation effect, just need rename.

Thanks.

[PATCH] drm/radeon: Don't try to enable write-combining without PAT

2015-02-04 Thread Christian König

Am 04.02.2015 um 02:19 schrieb Michel DÃ¤nzer:
> From: Michel DÃ¤nzer 
>
> Doing so can cause things to become slow.
>
> Print a warning at compile time and an informative message at runtime in
> that case.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel DÃ¤nzer 

Interesting I wonder what the rational behind this is. I mean 
CONFIG_X86_PAT will obviously affect write combining, but why does it 
slow down things if we request something that the kernel isn't 
configured for?

Anyway, patch is Reviewed-by: Christian KÃ¶nig 

Regards,
Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_object.c | 12 
>   1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 7d68223..bd3df10 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -238,6 +238,18 @@ int radeon_bo_create(struct radeon_device *rdev,
>* See https://bugs.freedesktop.org/show_bug.cgi?id=84627
>*/
>   bo->flags &= ~RADEON_GEM_GTT_WC;
> +#elif defined(CONFIG_X86) && !defined(CONFIG_X86_PAT)
> + /* Don't try to enable write-combining when it can't work, or things
> +  * may be slow
> +  * See https://bugs.freedesktop.org/show_bug.cgi?id=88758
> +  */
> +
> +#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance 
> \
> +  thanks to write-combining
> +
> + DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
> +   "better performance thanks to write-combining\n");
> + bo->flags &= ~RADEON_GEM_GTT_WC;
>   #endif
>   
>   radeon_ttm_placement_from_domain(bo, domain);

[PATCH] drm/radeon: Don't try to enable write-combining without PAT

2015-02-04 Thread Michel Dänzer

From: Michel DÃ¤nzer 

Doing so can cause things to become slow.

Print a warning at compile time and an informative message at runtime in
that case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
Cc: stable at vger.kernel.org
Signed-off-by: Michel DÃ¤nzer 
---
 drivers/gpu/drm/radeon/radeon_object.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 7d68223..bd3df10 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -238,6 +238,18 @@ int radeon_bo_create(struct radeon_device *rdev,
 * See https://bugs.freedesktop.org/show_bug.cgi?id=84627
 */
bo->flags &= ~RADEON_GEM_GTT_WC;
+#elif defined(CONFIG_X86) && !defined(CONFIG_X86_PAT)
+   /* Don't try to enable write-combining when it can't work, or things
+* may be slow
+* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
+*/
+
+#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
+thanks to write-combining
+
+   DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
+ "better performance thanks to write-combining\n");
+   bo->flags &= ~RADEON_GEM_GTT_WC;
 #endif

radeon_ttm_placement_from_domain(bo, domain);
-- 
2.1.4

[PATCH] drm: remove DRM_FORMAT_NV12MT

On Wed, Feb 04, 2015 at 11:30:23AM +0900, Joonyoung Shim wrote:
> +Cc Inki,
> 
> Hi,
> 
> On 02/04/2015 12:48 AM, Daniel Vetter wrote:
> > So this has been merged originally in
> > 
> > commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> > Author: Seung-Woo Kim 
> > Date:   Thu Dec 15 15:40:55 2011 +0900
> > 
> > drm: Add multi buffer plane pixel formats
> > 
> > which hasn't seen a lot of review really. The problem is that it's not
> > a real pixel format, but just a different way to lay out NV12 pixels
> > in macroblocks, i.e. a tiling format.
> > 
> > The new way of doing this is with the soon-to-be-merge fb modifiers.
> > 
> > This was brough up in some long irc discussion around the entire
> > topic, as an example of where things have gone wrong. Luckily we can
> > correct the mistake:
> > - The kms side support for NV12MT is all dead code because
> >   format_check in drm_crtc.c never accepted NV12MT.
> 
> So it was tried to support NV12MT in format_check. I really welcome the
> new way.

Yeah, the new way should also make sharing buffers between devices easier
since we'll have a fairly rigid standard about things. On irc we've
discussed that we probably need a VENDOR_MPEG modifier range so that we
can have cross-chip-vendor standardized modifiers for the various
macroblock tiling layouts seen in video streams (64x32, 16x16).

> Acked-by: Joonyoung Shim 

Thanks, I've picked the patch up into my drm-misc branch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH RFC v8 02/21] of: Add vendor prefix for Himax Technologies Inc.

2015-02-04 Thread Rob Herring

On Wed, Dec 31, 2014 at 2:23 AM, Liu Ying  wrote:
> Signed-off-by: Liu Ying 

I don't know what the status is for the rest of the series, but I'm
applying this and patch 3 so you don't have to keep sending them.

Rob

> ---
> v7->v8:
>  * None.
>
> v6->v7:
>  * None.
>
> v5->v6:
>  * None.
>
> v4->v5:
>  * None.
>
> v3->v4:
>  * Fix an ordering issue to address Stefan Wahren's comment.
>
> v2->v3:
>  * None.
>
> v1->v2:
>  * None.
>
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 78efebb..f46adb2 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -67,6 +67,7 @@ gumstix   Gumstix, Inc.
>  gw Gateworks Corporation
>  hannstar   HannStar Display Corporation
>  haoyu  Haoyu Microelectronic Co. Ltd.
> +himax  Himax Technologies, Inc.
>  hisilicon  Hisilicon Limited.
>  hitHitachi Ltd.
>  honeywell  Honeywell
> --
> 2.1.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] exynos/drm: fix no hdmi output

2015-02-04 Thread Alban Browaeys

Le vendredi 30 janvier 2015 Ã  16:29 +0900, Joonyoung Shim a Ã©crit :
> Hi,
> 

> OK, i also get blank screen from hdmi after enable vidi.
> 


> The pipe value for crtc is increased in mixer_initialize so it should be
> called before exynos_drm_crtc_create because the pipe value is used in
> exynos_drm_crtc_create.
> 
> Acked-by: Joonyoung Shim 
> 
> Fimd and VIDI driver also have same issue. I will post the patch to fix
> this for Fimd and VIDI driver.
> 

Thank you . I missed the rationale thus the related issues.
My bad the ack will not be included as I took too long, the patch is
already in Inki Dae repository exynos-drm-next branch as is.


Best regards,
Alban

[Bug 85661] planetary annihilation gpu lockup

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

--- Comment #10 from kdj0c at djinvi.net ---
the last apitrace is not crashing anymore with newest mesa (10.4.3) and kernel
3.19, llvm 3.5.1


but the game still has the same hardlockup a few seconds later when running the
game.

I have uploaded a new apitrace at https://djinvi.net/jirafeau/f.php?h=35NcHizE
I checked that with glretrace, the hard lockup is reproductible.


I used to install mesa-git, but I get too much regressions, with the system
unable to boot, so I'm sticking with stable mesa on archlinux.

-- 
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/20150204/bf3e6e6d/attachment.html>

[PATCH V9 10/14] Documentation: devicetree: Add vendor prefix for parade

2015-02-04 Thread Rob Herring

On Tue, Jan 20, 2015 at 10:38 AM, Ajay Kumar  
wrote:
> ps8622 eDP-LVDS converter bridge chip is from parade technologies
>
> Signed-off-by: Ajay Kumar 
> Acked-by: Inki Dae 
> Tested-by: Rahul Sharma 
> Tested-by: Javier Martinez Canillas 
> Tested-by: Gustavo Padovan 
> Tested-by: Sjoerd Simons 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 4df1d78..eca48be 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -125,6 +125,7 @@ nxp NXP Semiconductors
>  onnn   ON Semiconductor Corp.
>  opencores  OpenCores.org
>  panasonic  Panasonic Corporation
> +parade Parade Technologies Inc.
>  pericomPericom Technology Inc.
>  phytec PHYTEC Messtechnik GmbH
>  picochip   Picochip Ltd
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 0/9] Enable HDMI support on Exynos platforms

Hi,

On 02/03/2015 12:58 PM, Kukjin Kim wrote:
> Marek Szyprowski wrote:
>>
>> Hi all,
>>
>> This is yet another update on patchset, which enables HDMI support for
>> Exynos based platforms.
>>
>> Beside DTS changes, this patchset adds parent domain support for Exynos
>> PM domains and add support for 'hdmi' clock directly to Exynos DRM mixer
>> driver.
>>
>> The patchset is based on samsung/for-next branch and 'PM / Domains:
>> Export of_genpd_get_from_provider function' patch merged as commit
>> 7496fcbe8a643097efc061160e1c3b65ee2fa350 to v3.19-rc4.
>>
>> Regards
>> Marek Szyprowski
>>
>>
>> Changelog:
>>
>> v5:
>> - fixed error value for clk_get() in mixer patch
>> - rebased onto samsung/for-next branch
>>
>> v4: (http://www.spinics.net/lists/linux-samsung-soc/msg41375.html)
>> - added patches, which add 'hdmi' clock handling to mixed block, this
>>   finally solves the initialization related issues, thanks for Tobias
>>   Jakobi for testing
>> - added acks/reviewed/tested by tags
>>
>> v3: (http://www.spinics.net/lists/linux-samsung-soc/msg41020.html)
>> - added a note on defining subdomains to generic PM domain binding
>>   documentation (requested by Ulf Hansson)
>>
>> v2: (http://www.spinics.net/lists/linux-samsung-soc/msg40980.html)
>> - rewrote subdomains patch according to suggestions from Geert
>>   Uytterhoeven and Amit Daniel Kachhap.
>>
>> v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html)
>> - added handling of generic 'power-domains' binding in subdomains
>>
>> v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html)
>> - resolved power domain on/off issue with 'clk: samsung: exynos4: set
>>   parent of mixer gate clock to hdmi' patch
>>
>> v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html)
>> - first attempt, used 'always on' power domains hack
>>
>>
>> Patch summary:
>>
>>
>> *** BLURB HERE ***
>>
>> Andrzej Hajda (1):
>>   ARM: dts: exynos5250: add display power domain
>>
>> Marek Szyprowski (7):
>>   PM / Domains: Add a note about power domain subdomains
>>   ARM: Exynos: add support for sub-power domains
>>   ARM: dts: exynos4: add hdmi related nodes
>>   ARM: dts: exynos4: add dependency between TV and LCD0 power domains
>>   ARM: dts: exynos4412-odroid: enable hdmi support
>>   ARM: dts: Exynos: add 'hdmi' clock to mixer nodes
>>   drm/exynos: add support for 'hdmi' clock
>>
>> Tomasz Stanislawski (1):
>>   ARM: dts: exynos4210-universal_c210: enable hdmi support
>>
>>  .../bindings/arm/exynos/power_domain.txt   |  2 +
>>  .../devicetree/bindings/power/power_domain.txt | 29 +++
>>  .../devicetree/bindings/video/exynos_mixer.txt |  1 +
>>  arch/arm/boot/dts/exynos4.dtsi | 41 
>>  arch/arm/boot/dts/exynos4210-universal_c210.dts| 57 
>> ++
>>  arch/arm/boot/dts/exynos4210.dtsi  |  8 +++
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 44 +
>>  arch/arm/boot/dts/exynos4x12.dtsi  | 11 +
>>  arch/arm/boot/dts/exynos5250.dtsi  | 15 +-
>>  arch/arm/boot/dts/exynos5420.dtsi  |  5 +-
>>  arch/arm/mach-exynos/pm_domains.c  | 28 +++
>>  drivers/gpu/drm/exynos/exynos_mixer.c  |  9 
>>  12 files changed, 246 insertions(+), 4 deletions(-)
>>
>> --
> I have no objection on this series, but just wondering my tree should be fine
> without 9/9 drm patch and it will be handled for 3.20?
> 
> I'll take 1 to 8 patches once drm patch is landed for 3.20.
> 

I also hope this patchset merged,

Inki, could you follow up exynos drm part of this patchset?

Thanks.

[Bug 85564] Dead Island rendering issues

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

--- Comment #8 from Thomas Rohloff  ---
I just tried to run the game with gdb to track down the crash but with gdb it
isn't crashing anymore. Anyway, the rendering issues are still there (without
gdb and with the drirc setting it crashes while loading the scene).

Could it be that gdb somehow brings mesa to ignore the drirc settings?

-- 
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/20150204/5101fb49/attachment.html>

[Bug 85564] Dead Island rendering issues

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

Thomas Rohloff  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #7 from Thomas Rohloff  ---
(In reply to Sven Arvidsson from comment #5)
> Does rendering improve if you add this to drirc?
> 
> 
>
> 

No, it just crashes the game.

-- 
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/20150204/44c3252d/attachment.html>

[Bug 87023] Dota 2 crashed and hang on ATi Mobility Radeon HD 5650 (Acer 4745G)

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

-- 
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/20150204/e1797559/attachment.html>

[Bug 88658] (bisected) Slow video playback on Kabini