[PULL] drm coverity patches for 3.16

[Daniel Vetter]

Hi Dave,

So first of a few pull requests for drm-next for 3.16 this week from me.

This here is the coverity stuff, all nicely reviewed. As discussed on irc
I've dropped the ast patch since you have the proper fix. Nothing in here
is imo -fixes material, especially with an already grumpy Linus ;-)

Cheers, Daniel

The following changes since commit a798c10faf62a505d24e5f6213fbaf904a39623f:

  Linux 3.15-rc2 (2014-04-20 11:08:50 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm drm-coverity-fixes

for you to fetch changes up to 10e6856983c21b76d03282b6da86709bdc23eb77:

  drm: Fix error handling in drm_master_create (2014-04-22 15:39:42 +0200)


Daniel Vetter (12):
  drm/mgag200: Remove unecessary NULL check in bo_unref
  drm/mgag200: Remove unecessary NULL check in gem_free
  drm/cirrus: Remove unnecessary NULL check in bo_unref
  drm/cirrus: Remove unecessary NULL check in gem_free
  drm/ast: Remove unnecessary NULL check in bo_unref
  drm/ast: Remove unecessary NULL check in gem_free
  drm/via: Remove unecessary NULL check
  drm/udl: Initialize ret in udl_driver_load
  drm/bochs: Remove unnecessary NULL check in bo_unref
  drm/bochs: Remove unecessary NULL check in gem_free
  drm/i2c/tda998x: Fix signed overflow issue
  drm: Fix error handling in drm_master_create

 drivers/gpu/drm/ast/ast_main.c | 7 ++-
 drivers/gpu/drm/bochs/bochs_mm.c   | 6 +-
 drivers/gpu/drm/cirrus/cirrus_main.c   | 6 +-
 drivers/gpu/drm/drm_stub.c | 5 -
 drivers/gpu/drm/i2c/tda998x_drv.c  | 6 +++---
 drivers/gpu/drm/mgag200/mgag200_main.c | 6 +-
 drivers/gpu/drm/udl/udl_main.c | 1 +
 drivers/gpu/drm/via/via_mm.c   | 2 +-
 8 files changed, 14 insertions(+), 25 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH V2 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

[Ajay kumar]

Hi Thierry,


On Tue, Apr 22, 2014 at 2:57 PM, Thierry Reding
 wrote:
> On Tue, Apr 22, 2014 at 04:09:18AM +0530, Ajay Kumar wrote:
>> This patch adds ps8622 lvds bridge discovery code to the dp driver.
>>
>> Signed-off-by: Rahul Sharma 
>> Signed-off-by: Ajay Kumar 
>> ---
>> Changes since V1:
>>   Pushing V1 for this as V2 because this patch holds good in this series.
>>
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4853f31..0006412 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -30,6 +30,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "exynos_drm_drv.h"
>>  #include "exynos_dp_core.h"
>> @@ -999,7 +1000,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
>> drm_device *dev,
>>   panel);
>>   if (!ret)
>>   return 1;
>> + } else if (find_bridge("parade,ps8625", )) {
>
> So this is where the inspiration for the of_find_compatible_node() in
> the earlier patch came from.
>
I shall use phandle for that as suggested by you for previous patches.

>> + ret = ps8622_init(dev, encoder, bridge.client, bridge.node,
>> + panel);
>
> Long-term I don't think this is going to scale very well. In my opinion
> it would be much more useful to have the bridge driver initialize what
> it can and then have the DRM driver call a generic initialization
> function to bind it to the DRM device or encoder. Otherwise we have to
> keep knowledge about the type of bridge in each driver that uses it,
> whereas the goal (I think) would be to create a proper abstraction so
> that the DRM driver doesn't have to know that kind of detail.
Well, having a generic initialization function makes more sense when
we have multiple platforms supporting the 2 available bridge chips.
Then we can let the bridge chip initialize first, and then call a drm_bridge
search and bind function to search the bridge_list to find the bridge which has
already got registered.
But, this again poses a challenge that the bridge chip driver should
be probed before
the corresponding drm_encoder is trying to bind the bridge with
drm_device/encoder.

So, I think the current way of explicitly calling bridgeXXX_init is
fine, at least
till multiple platforms start keeping track of all possible bridges
they support,
inside their respective drivers.

Thanks and regards,
Ajay Kumar

[PATCH] drm: Rip out totally bogus vga_switcheroo->can_switch locking

[Daniel Vetter]

So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.

Unfortunately the vga switcheroo callbacks took this comment at face
value. The problem is that we can't just take the drm_global_mutex
because:
- It would lead to a locking inversion with the driver load/unload
  paths.
- It wouldn't actually protect anything, for that we'd need to wrap
  the entire vga switcheroo code in the drm_global_mutex. And I'm not
  sure whether that would actually solve anything.

What we probably want is a try_to_grab_switcheroo reference kind of
thing which is used in the driver's ->open callback. Then we could
move all that ->can_switch madness into the vga switcheroo core where
it really belongs.

But since that would amount to real work take the easy way out and
just add a comment. It's definitely not going to make anything worse
since doing switcheroo state changes while restarting X just isn't
recommended. Even though the delayed switching code does exactly that.

v2:
- Simplify the ->can_switch implementations more (Thierry)
- Fix comment about the dev->open_count locking (Thierry)

Cc: Thierry Reding 
Reviewed-by: Laurent Pinchart  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_dma.c| 11 ++-
 drivers/gpu/drm/nouveau/nouveau_vga.c  | 11 ++-
 drivers/gpu/drm/radeon/radeon_device.c | 11 ++-
 include/drm/drmP.h |  2 +-
 4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 96177eec0a0e..283ff06001bc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1277,12 +1277,13 @@ static void i915_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switcheroo_
 static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-   bool can_switch;

-   spin_lock(>count_lock);
-   can_switch = (dev->open_count == 0);
-   spin_unlock(>count_lock);
-   return can_switch;
+   /*
+* FIXME: open_count is protected by drm_global_mutex but that would 
lead to
+* locking inversion with the driver load path. And the access here is
+* completely racy anyway. So don't bother with locking for now.
+*/
+   return dev->open_count == 0;
 }

 static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index fb84da3cb50d..4f4c3fec6916 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -64,12 +64,13 @@ static bool
 nouveau_switcheroo_can_switch(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-   bool can_switch;

-   spin_lock(>count_lock);
-   can_switch = (dev->open_count == 0);
-   spin_unlock(>count_lock);
-   return can_switch;
+   /*
+* FIXME: open_count is protected by drm_global_mutex but that would 
lead to
+* locking inversion with the driver load path. And the access here is
+* completely racy anyway. So don't bother with locking for now.
+*/
+   return dev->open_count == 0;
 }

 static const struct vga_switcheroo_client_ops
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 511fe26198e4..9aa1afd1786e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1125,12 +1125,13 @@ static void radeon_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switchero
 static bool radeon_switcheroo_can_switch(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-   bool can_switch;

-   spin_lock(>count_lock);
-   can_switch = (dev->open_count == 0);
-   spin_unlock(>count_lock);
-   return can_switch;
+   /*
+* FIXME: open_count is protected by drm_global_mutex but that would 
lead to
+* locking inversion with the driver load path. And the access here is
+* completely racy anyway. So don't bother with locking for now.
+*/
+   return dev->open_count == 0;
 }

 static const struct vga_switcheroo_client_ops radeon_switcheroo_ops = {
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9f1fb8d36b67..a20d882ca265 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1076,7 +1076,7 @@ struct drm_device {

/** \name Usage Counters */
/*@{ */
-   int open_count; /**< Outstanding files open */
+   int open_count; /**< Outstanding files open, protected 
by drm_global_mutex. */
int buf_use;/**< Buffers in use -- cannot alloc */
atomic_t buf_alloc; 

[PATCH] drm/irq: track the irq installed in drm_irq_install in dev->irq

[Daniel Vetter]

To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.

v2: Add the hunk lost in an earlier patch to this one (Thierry).

v3: Fix up the totally fumbled logic in drm_irq_install and use the
local variable consistently. Spotted by both Thierry and Laurent.
Shame on me for failing to properly test the rebase version of this
patch ...

Cc: Thierry Reding 
Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 18 +++---
 include/drm/drmP.h|  2 ++
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 589e865832cd..7cf407bbfed5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -249,14 +249,16 @@ static inline int drm_dev_to_irq(struct drm_device *dev)
  */
 int drm_irq_install(struct drm_device *dev)
 {
-   int ret;
+   int ret, irq;
unsigned long sh_flags = 0;
char *irqname;

+   irq = drm_dev_to_irq(dev);
+
if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
return -EINVAL;

-   if (drm_dev_to_irq(dev) == 0)
+   if (irq == 0)
return -EINVAL;

/* Driver must have been initialized */
@@ -267,7 +269,7 @@ int drm_irq_install(struct drm_device *dev)
return -EBUSY;
dev->irq_enabled = true;

-   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
+   DRM_DEBUG("irq=%d\n", irq);

/* Before installing handler */
if (dev->driver->irq_preinstall)
@@ -282,7 +284,7 @@ int drm_irq_install(struct drm_device *dev)
else
irqname = dev->driver->name;

-   ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
+   ret = request_irq(irq, dev->driver->irq_handler,
  sh_flags, irqname, dev);

if (ret < 0) {
@@ -301,7 +303,9 @@ int drm_irq_install(struct drm_device *dev)
dev->irq_enabled = false;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
vga_client_register(dev->pdev, NULL, NULL, NULL);
-   free_irq(drm_dev_to_irq(dev), dev);
+   free_irq(irq, dev);
+   } else {
+   dev->irq = irq;
}

return ret;
@@ -344,7 +348,7 @@ int drm_irq_uninstall(struct drm_device *dev)
if (!irq_enabled)
return -EINVAL;

-   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
+   DRM_DEBUG("irq=%d\n", dev->irq);

if (!drm_core_check_feature(dev, DRIVER_MODESET))
vga_client_register(dev->pdev, NULL, NULL, NULL);
@@ -352,7 +356,7 @@ int drm_irq_uninstall(struct drm_device *dev)
if (dev->driver->irq_uninstall)
dev->driver->irq_uninstall(dev);

-   free_irq(drm_dev_to_irq(dev), dev);
+   free_irq(dev->irq, dev);

return 0;
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 85682d959c7e..8e8c392d6fa8 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1107,6 +1107,8 @@ struct drm_device {
/** \name Context support */
/*@{ */
bool irq_enabled;   /**< True if irq handler is enabled */
+   int irq;
+
__volatile__ long context_flag; /**< Context swapping flag */
int last_context;   /**< Last current context */
/*@} */
-- 
1.9.2

[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed

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

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

--- Comment #2 from Luzipher  ---
Update: no change in kernel 3.15-rc1, same messages occur.

-- 
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/20140422/2b8c7d86/attachment-0001.html>

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

--- Comment #5 from smoki  ---

 Tried 10.0.5 now also have this issue, so all 10.x.x are affected... not sure
how far backwards i can go with kabini, but also maybe it is not regression :).

-- 
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/20140422/4714cbf4/attachment.html>

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

--- Comment #4 from smoki  ---
Created attachment 97786
  --> https://bugs.freedesktop.org/attachment.cgi?id=97786=edit
good case (swrast)

 Oh, wrong screenshot earlier... forgot to turn on headlights with swrast :).
So this good one with swrast, how it need to be ;).

-- 
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/20140422/db5d649d/attachment.html>

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

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

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

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

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

[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes

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

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

--- Comment #9 from Alex Deucher  ---
Do you still get lockups without forcing the power level to high?  You
shouldn't need to force it.  On auto the hw will automatically switch between
levels based on load.

-- 
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/20140422/f9de221f/attachment.html>

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

smoki  changed:

   What|Removed |Added

  Attachment #97781|text/plain  |image/png
  mime type||

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

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

--- Comment #3 from smoki  ---
Created attachment 97781
  --> https://bugs.freedesktop.org/attachment.cgi?id=97781=edit
good case (swrast)

-- 
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/20140422/e158ef05/attachment-0001.html>

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

--- Comment #2 from smoki  ---
Created attachment 97780
  --> https://bugs.freedesktop.org/attachment.cgi?id=97780=edit
bad case

-- 
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/20140422/7644dbec/attachment.html>

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

--- Comment #1 from smoki  ---
Created attachment 97778
  --> https://bugs.freedesktop.org/attachment.cgi?id=97778=edit
good case

-- 
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/20140422/ee293a16/attachment.html>

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

smoki  changed:

   What|Removed |Added

  Attachment #9|text/plain  |image/png
  mime type||

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

[Bug 77785] New: (radeonsi) Some lighting issues in games, textures goes black

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

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

  Priority: medium
Bug ID: 77785
  Assignee: dri-devel at lists.freedesktop.org
   Summary: (radeonsi) Some lighting issues in games, textures
goes black
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: smoki00790 at gmail.com
  Hardware: x86 (IA32)
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 9
  --> https://bugs.freedesktop.org/attachment.cgi?id=9=edit
bad case

Athlon 5350 (so Radeon R3 or Radeon 8400), current Debian Sid and mesa 10.1. I
also tried current mesa git master 10-devel, kernel 3.15-rc3, etc... the same
issue with lighting appear. hyperz (enabled/disabled) does not metter here.

 So, in wine with some opengl games (i guess native are also affected, but not
found example) for example AirStrike3D or 18 WoS: Pedal to the Metal games. In
18 WoS: Pedal to the Metal. issue appear when i turn on truck headlights,
everything beside headlights goes black of course until i turn off
headlights... some screenshots i will attach.

 And yeah swrast works OK, fglrx too :)

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

[Bug 77784] New: Certain mono based games hang the system with radeonsi (probably llvm backend)

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

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

  Priority: medium
Bug ID: 77784
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Certain mono based games hang the system with radeonsi
(probably llvm backend)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: j.suarez.agapito at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

My system specs are as follows (taken from Steam system information):

Processor Information:
Vendor:  AuthenticAMD
CPU Family:  0x15
CPU Model:  0x1
CPU Stepping:  0x2
CPU Type:  0x0
Speed:  3600 Mhz
8 logical processors
8 physical processors
HyperThreading:  Unsupported
FCMOV:  Supported
SSE2:  Supported
SSE3:  Supported
SSSE3:  Supported
SSE4a:  Supported
SSE41:  Supported
SSE42:  Supported

Network Information:
Network Speed:  

Operating System Version:
Ubuntu 14.04 LTS (64 bit)
Kernel Name:  Linux
Kernel Version:  3.15.0-031500rc2-generic
X Server Vendor:  The X.Org Foundation
X Server Release:  11501000
X Window Manager:  KWin
Steam Runtime Version:  steam-runtime-release_2014-02-05

Video Card:
Driver:  X.Org Gallium 0.4 on AMD PITCAIRN

Driver Version:  3.0 Mesa 10.2.0-devel (git-7cb3bbf trusty-oibaf-ppa)
OpenGL Version: 3.0
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID:  0x1002
DeviceID:  0x6818
Number of Monitors:  1
Number of Logical Video Cards:  1
Primary Display Resolution:  1920 x 1080
Desktop Resolution: 1920 x 1080
Primary Display Size: 18,78" x 10,55"  (21,54" diag)
47,7cm x 26,8cm  (54,7cm diag)
Primary VRAM Not Detected

Sound card:
Audio device: Realtek ALC889

Memory:
RAM:  15865 Mb

Miscellaneous:
UI Language:  English
LANG:  es_ES.UTF-8
Microphone:  Not set
Total Hard Disk Space Available:  469324 Mb
Largest Free Hard Disk Block:  35328 Mb

Installed software:

Recent Failure Reports:

GPU is a Radeon HD 7870, using radeonsi git 2014.04.21 (7cb3bbf) from oibaf ppa
recompiled with llvm 3.5 (svn 206757).

Even after bug #60929 was fixed I have been experiencing system hangs with
LITTLE Racers Street, which is based on mono. The hang usually happens randomly
after a few races have been played and results in the image in the screen
getting its colors corrupted (just like when in old times you changed the color
depth in windows 95 -I'll try to get a picture with a camera because the system
is hard locked-) and a loop in the sound. So just a hard lock.

I did not know what was to blame and was waiting for a game update in order to
see if things got solved.

However, I have recently bought Foosball Street Edition (also based on mono).
The game launches and shows the menus OK, but hangs the system at about 5-10
secs after the kick-off of any match. The hang is not like LITTLE Racers
Street, but rather like a series of GPU hangs and recoveries (screen goes black
and then shows the game a few times in a row) which end up in the system
totally frozen. During that time there is no sound playing. So probably not a
lock as hard as in LITTLE Racers Street.

I'm not sure how to debug this but I am quite convinced that this could be
another case of mono + llvm backend incompatibility. The reason for that belief
is that (i) I have tested this game on this same PC with catalyst and the game
does not hang and everything works wonderfully, (ii) I obtained the same good
results in a laptop with a Radeon HD 4570 (r600g, not llvm) (mesa git from
around 10 April); and (iii) both games are based on mono.

As stated above, I'm not sure how to debug this because when the system hangs,
it does not allow VT switching to check the logs or the dmesg output. I would
be happy to help with any further information needed.

Regards

-- 
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/20140422/e7df4d0d/attachment.html>

[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes

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

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

--- Comment #8 from nine at detonation.org ---
Created attachment 97776
  --> https://bugs.freedesktop.org/attachment.cgi?id=97776=edit
dmesg after GPU lockup on setting power profile to high

-- 
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/20140422/474ae78f/attachment-0001.html>

[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes

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

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

--- Comment #7 from nine at detonation.org ---
I can easily reproduce GPU lockups by switching the power profile to high. I
bought a new power supply that has power to spare, but it did not change
anything.

Should I file a separate bug report for these lockups?

-- 
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/20140422/06ff2b22/attachment.html>

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Ajay kumar]

Hi Thierry,

On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
 wrote:
> On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
>> Register exynos_dp_panel before the list of exynos crtcs and
>> connectors are probed.
>>
>> This is needed because exynos_dp_panel should be registered to
>> the drm_panel list via panel-exynos-dp probe, i.e much before
>> exynos_dp_bind calls of_drm_find_panel().
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>> Changes since V1:
>>   Added platform_driver_unregister(_dp_panel_driver) to
>>   exynos_drm_platform_remove as per Jingoo Han's correction
>>
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>>  2 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 1d653f8..2db7f67 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
>> platform_device *pdev)
>>   goto err_unregister_ipp_drv;
>>  #endif
>>
>> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
>> + ret = platform_driver_register(_dp_panel_driver);
>> + if (ret < 0)
>> + goto err_unregister_dp_panel;
>> +#endif
>
> No, this is not how you're supposed to use DRM panel drivers. The idea
> is that you write a standalone driver for a given panel.
>
> What you do here has a number of problems. For one it's a driver that's
> tightly coupled to Exynos SoCs. But if I have a different SoC that uses
> the same panel I want to be able to use the same driver, and not have to
> rewrite the driver for my SoC.
>
> Another problem is that you're assuming here that the driver is built in
> and it will break if you try to build either Exynos DRM or the panel
> driver as a module. This is perhaps nothing you care about right now,
> but eventually people will want to ship a single kernel that can run on
> a number of SoCs. But if we keep adding things like this, that kernel
> will keep growing in size until it no longer fits in any kind of memory.
>
> Thierry

I completely agree with you in this!

Yes, this is not acceptable, but I want to know an "acceptable"
workaround for the situation below:
I register the driver using module_init().
And, exynos_drm gets probed much before the panel driver probe happens.
So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
tries to call
"of_drm_find_panel" which always returns NULL.

Thanks and regards,
Ajay Kumar

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Ajay kumar]

Hi Thierry,


On Tue, Apr 22, 2014 at 1:56 PM, Thierry Reding
 wrote:
> On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote:
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/eDP-LVDS panels
>> supported on exynos boards.
>>
>> The LCD and LED units are usually powered up via regulators,
>> and almost on all boards, we will have a BL_EN pin to enable/
>> disable the backlight. Sometimes, we can have LCD_EN switches
>> as well. The routines in this driver can be used to control
>> panel power sequence on such boards.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>> Changes since V1:
>>   Added routine for post_disable, removed few unwanted headers.
>>   Refactored a lot of code.
>>
>>  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
>>  drivers/gpu/drm/panel/Kconfig  |9 +
>>  drivers/gpu/drm/panel/Makefile |1 +
>>  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
>> 
>>  4 files changed, 306 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
>
> What this patch does is in no way Exynos specific. It is also not eDP
> specific.
>
Right. This is not at all writing into any "exynos" specific register,
but can't this be just a placeholder for all the panel controls
which can serve boards which use exynos_dp?

> This conflates panel drivers with board drivers in a strange way. Panel
> drivers should be for *panels*, not for a given SoC or specific outputs
> on that SoC.
>
Right. But for that matter, even the "panel-simple" driver is doing the same,
which is just a placeholder for "generic" panel controls which serves
multiple boards.
I din't choose to reuse that because the boards which I have expect more
control over the panel sequence as mentioned before.
If you don't mind, I can fit in all these settings into panel-simple
driver itself ;)
But again, I should be able to register the panel driver much before
exynos_dp gets probed, That's the actual catch!


Thanks and regards,
Ajay Kumar

[Bug 73901] Kernel crash after modprobe radeon runpm=1

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

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

--- Comment #16 from Pali Roh?r  ---
My bad, I'm using tlp which calling:
$ echo on > /sys/bus/pci/devices/:01:00.0/power/control
when notebook is running on ac. And this prevent runpm to work correctly. After
I blacklisted radeon card in tlp then runpm started working correctly.

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

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Ajay kumar]

Hi Jingoo,


On Tue, Apr 22, 2014 at 12:52 PM, Jingoo Han  wrote:
>
> On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> >
> > This patch adds a simple driver to handle all the LCD and LED
> > powerup/down routines needed to support eDP/eDP-LVDS panels
> > supported on exynos boards.
> >
> > The LCD and LED units are usually powered up via regulators,
> > and almost on all boards, we will have a BL_EN pin to enable/
> > disable the backlight. Sometimes, we can have LCD_EN switches
> > as well. The routines in this driver can be used to control
> > panel power sequence on such boards.
> >
> > Signed-off-by: Ajay Kumar 
> > ---
> > Changes since V1:
> >   Added routine for post_disable, removed few unwanted headers.
> >   Refactored a lot of code.
> >
> >  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
> >  drivers/gpu/drm/panel/Kconfig  |9 +
> >  drivers/gpu/drm/panel/Makefile |1 +
> >  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
> > 
> >  4 files changed, 306 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> >  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
> >
> > diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> > b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> > new file mode 100644
> > index 000..3fbca54
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> > @@ -0,0 +1,45 @@
> > +exynos_DP_panel/DP_to_LVDS_panel
>
> Please fix it as below.
>
> +Exynos DP panel/DP to LVDS panel
>
Ok.

> []
>
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 4ec874d..ea9d5ac 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0
> >   select DRM_MIPI_DSI
> >   select VIDEOMODE_HELPERS
> >
> > +config DRM_PANEL_EXYNOS_DP
> > + tristate "support for DP panels"
>
> It looks very general. Please fix it as below.
>
> +   tristate "support for Exynos DP panels"
>
Ok.

> Best regards,
> Jingoo Han
>
> > + depends on OF && DRM_PANEL && DRM_EXYNOS_DP
> > + help
> > +   DRM panel driver for DP panels and LVDS connected via DP bridges
> > +   that need at most a regulator for LCD unit, a regulator for LED unit
> > +   and/or enable GPIOs for LCD or LED units. Delay values can also be
> > +   specified to support powerup and powerdown process.
> > +
>
> [.]
>
>

Thanks and Regards,
Ajay Kumar

[PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

[Ajay kumar]

Hi Thierry,


On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding 
wrote:
> On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote:
>> Most of the panels need an init sequence as mentioned below:
>>   -- poweron LCD unit/LCD_EN
>>   -- start video data
>>   -- poweron LED unit/BL_EN
>> And, a de-init sequence as mentioned below:
>>   -- poweroff LED unit/BL_EN
>>   -- stop video data
>>   -- poweroff LCD unit/LCD_EN
>> With existing callbacks for drm panel, we cannot accomodate such panels,
>> since only two callbacks, i.e "panel_enable" and panel_disable are
supported.
>>
>> This patch adds:
>>   -- "pre_enable" callback which can be called before
>>   the actual video data is on, and then call the "enable"
>>   callback after the video data is available.
>>
>>   -- "post_disable" callback which can be called after
>>   the video data is off, and use "disable" callback
>>   to do something before switching off the video data.
>>
>> Now, we can easily map the above scenario as shown below:
>>   poweron LCD unit/LCD_EN = "pre_enable" callback
>>   poweron LED unit/BL_EN = "enable" callback
>>   poweroff LED unit/BL_EN = "disable" callback
>>   poweroff LCD unit/LCD_EN = "post_disable" callback
>
> I don't like this. What happens when the next panel comes around that
> has a yet slightly different requirement? Will we introduce a new
> pre_pre_enable() and post_post_disable() function then?
>
As I have already explained, these 2 callbacks are sufficient enough to
take care
the power up/down sequence for LVDS and eDP panels. And, definitely having
just 2 callbacks "enable" and "disable" is not at all sufficient.

I initially thought of using panel_simple_enable from panel-simple driver.
But it doesn't go well with case wherein there are 2 regulators(one for LCD
and one for LED)
a BL_EN signal etc. And, often(Believe me, I have referred to both eDP
panel datasheets
and LVDS panel datasheets) proper powerup sequence for such panels is as
mentioned below:

powerup:
-- power up the supply (LCD_VCC).
-- start video data.
-- enable backlight.

powerdown
-- disable backlight.
-- stop video data.
-- power off the supply (LCD VCC)

For the above cases, if I have to somehow fit in all the required settings,
it breaks the sequence and I end up getting glitches during bootup/DPMS.

Also, when the drm_bridge can support pre_enable and post_disable, why not
drm_panel provide that both should work in tandem?

> There's got to be a better way to solve this.
>
> Thierry


Thanks and Regards,
Ajay Kumar
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/366ae5de/attachment.html>

[PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver

[Ajay kumar]

Hi Sean,


On Tue, Apr 22, 2014 at 7:01 PM, Sean Paul  wrote:
>
> On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar  
> wrote:
> > This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
> > bridge chip.
> >
> > Signed-off-by: Andrew Bresticker 
> > Signed-off-by: Sean Paul 
> > Signed-off-by: Rahul Sharma 
> > Signed-off-by: Ajay Kumar 
>
> Hi Ajay,
> I don't think that you should be claiming authorship of this driver, I
> don't see any commits from you in the chromium tree ([1] & [2]). The
> driver was originally written by vpalatin at chromium.org (who's
> completely missing from SoB), it should probably be attributed to him.
>
> Sean
>
Oops. I am really sorry and I didn't really want to claim the authorship
for this patch. I missed it while doing "git format-patch".
And,  thanks for letting me know that Vincent was the actual author.
I will add his authorship.

Regards,
Ajay Kumar

>
>
> [1]- 
> https://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=history;f=drivers/auxdisplay/ps8622.c;hb=fac579ad884d064d2c3cda988117e7dd66fc30c4
> [2]- 
> https://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=history;f=drivers/gpu/drm/bridge/ps8622.c;hb=refs/heads/chromeos-3.8
>
>
>
> > ---
> > Changes since V1:
> > Pushing V1 for this as V2 because this patch holds good in this 
> > series.
> >
> >  drivers/gpu/drm/bridge/Kconfig  |7 +
> >  drivers/gpu/drm/bridge/Makefile |1 +
> >  drivers/gpu/drm/bridge/ps8622.c |  566 
> > +++
> >  include/drm/bridge/ps8622.h |   42 +++
> >  4 files changed, 616 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
> >  create mode 100644 include/drm/bridge/ps8622.h
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3bc6845..aba21fc 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -4,3 +4,10 @@ config DRM_PTN3460
> > select DRM_KMS_HELPER
> > select DRM_PANEL
> > ---help---
> > +
> > +config DRM_PS8622
> > +   tristate "Parade eDP/LVDS bridge"
> > +   depends on DRM
> > +   select DRM_KMS_HELPER
> > +   select DRM_PANEL
> > +   ---help---
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index b4733e1..d1b5daa 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -1,3 +1,4 @@
> >  ccflags-y := -Iinclude/drm
> >
> >  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
> > +obj-$(CONFIG_DRM_PS8622) += ps8622.o
> > diff --git a/drivers/gpu/drm/bridge/ps8622.c 
> > b/drivers/gpu/drm/bridge/ps8622.c
> > new file mode 100644
> > index 000..1e6b3ca
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/ps8622.c
> > @@ -0,0 +1,566 @@
> > +/*
> > + * Parade PS8622 eDP/LVDS bridge driver
> > + *
> > + * Copyright (C) 2014 Google, Inc.
> > + *
> > + * This software is licensed under the terms of the GNU General Public
> > + * License version 2, as published by the Free Software Foundation, and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "drmP.h"
> > +#include "drm_crtc.h"
> > +#include "drm_crtc_helper.h"
> > +
> > +struct ps8622_bridge {
> > +   struct drm_connector connector;
> > +   struct drm_bridge *bridge;
> > +   struct drm_encoder *encoder;
> > +   struct drm_panel *panel;
> > +   struct i2c_client *client;
> > +   struct regulator *v12;
> > +   struct backlight_device *bl;
> > +   struct mutex enable_mutex;
> > +
> > +   int gpio_slp_n;
> > +   int gpio_rst_n;
> > +
> > +   u8 max_lane_count;
> > +   u8 lane_count;
> > +
> > +   bool enabled;
> > +
> > +   struct drm_display_mode mode;
> > +};
> > +
> > +struct ps8622_device_data {
> > +   u8 max_lane_count;
> > +};
> > +
> > +static const struct ps8622_device_data ps8622_data = {
> > +   .max_lane_count = 1,
> > +};
> > +
> > +static const struct ps8622_device_data ps8625_data = {
> > +   .max_lane_count = 2,
> > +};
> > +
> > +/* Brightness scale on the Parade chip */
> > +#define PS8622_MAX_BRIGHTNESS 0xff
> > +
> > +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
> > +#define PS8622_POWER_RISE_T1_MIN_US 10
> > +#define PS8622_POWER_RISE_T1_MAX_US 1
> > +#define PS8622_RST_HIGH_T2_MIN_US 3000
> > +#define PS8622_RST_HIGH_T2_MAX_US 3
> > +#define PS8622_PWMO_END_T12_MS 200
> > +#define 

[PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver

[Ajay kumar]

   * */
> > + err |= ps8622_set(cl, 0x04, 0x10, 0x16); /* Set SSC enabled and
> +/-1%
> > +   * central spreading */
> > + /* Logic end */
> > + err |= ps8622_set(cl, 0x04, 0x59, 0x60); /* MPU Clock source: LC
> => RCO
> > +   * */
> > + err |= ps8622_set(cl, 0x04, 0x54, 0x14); /* LC -> RCO */
> > + err |= ps8622_set(cl, 0x02, 0xa1, 0x91); /* HPD high */
> > +
> > + return err ? -EIO : 0;
> > +}
> > +
>
> [.]
>
> > +
> > +static void ps8622_pre_enable(struct drm_bridge *bridge)
> > +{
> > + struct ps8622_bridge *ps_bridge = bridge->driver_private;
> > + int ret;
> > +
> > + mutex_lock(_bridge->enable_mutex);
> > + if (ps_bridge->enabled)
> > + goto out;
> > +
> > + if (gpio_is_valid(ps_bridge->gpio_rst_n))
> > + gpio_set_value(ps_bridge->gpio_rst_n, 0);
> > +
> > + if (ps_bridge->v12) {
> > + ret = regulator_enable(ps_bridge->v12);
> > + if (ret)
> > + DRM_ERROR("fails to enable ps_bridge->v12");
> > + }
> > +
> > + drm_panel_pre_enable(ps_bridge->panel);
> > +
> > + if (gpio_is_valid(ps_bridge->gpio_slp_n))
> > + gpio_set_value(ps_bridge->gpio_slp_n, 1);
> > +
> > + /*
> > +  * T1 is the range of time that it takes for the power to rise
> after we
> > +  * enable the lcd fet. T2 is the range of time in which the data
> sheet
> > +  * specifies we should deassert the reset pin.
> > +  *
> > +  * If it takes T1.max for the power to rise, we need to wait
> atleast
> > +  * T2.min before deasserting the reset pin. If it takes T1.min for
> the
> > +  * power to rise, we need to wait at most T2.max before
> deasserting the
> > +  * reset pin.
> > +  */
> > + usleep_range(PS8622_RST_HIGH_T2_MIN_US +
> PS8622_POWER_RISE_T1_MAX_US,
> > +  PS8622_RST_HIGH_T2_MAX_US +
> PS8622_POWER_RISE_T1_MIN_US);
> > +
> > + if (gpio_is_valid(ps_bridge->gpio_rst_n))
> > + gpio_set_value(ps_bridge->gpio_rst_n, 1);
> > +
> > + ret = ps8622_send_config(ps_bridge);
> > + if (ret)
> > + DRM_ERROR("Failed to send config to bridge (%d)\n", ret);
> > +
> > + ps_bridge->enabled = true;
> > +
> > + mutex_unlock(_bridge->enable_mutex);
> > + return;
> > +
> > +out:
> > +
> > + mutex_unlock(_bridge->enable_mutex);
> > +}
>
> mutex_unlock() is duplicated. Also, 'return' is unnecessary.
> Please fix it as below.
>
> +   ps_bridge->enabled = true;
> +
> +out:
> +   mutex_unlock(_bridge->enable_mutex);
> +}
>
Right. Will change it.


>
> > +
> > +static void ps8622_enable(struct drm_bridge *bridge)
> > +{
> > + struct ps8622_bridge *ps_bridge = bridge->driver_private;
> > +
> > + mutex_lock(_bridge->enable_mutex);
> > + if (ps_bridge->enabled)
> > + drm_panel_enable(ps_bridge->panel);
> > + mutex_unlock(_bridge->enable_mutex);
> > +}
> > +
> > +static void ps8622_disable(struct drm_bridge *bridge)
> > +{
> > + struct ps8622_bridge *ps_bridge = bridge->driver_private;
> > +
> > + mutex_lock(_bridge->enable_mutex);
> > +
> > + if (!ps_bridge->enabled)
> > + goto out;
> > +
> > + ps_bridge->enabled = false;
> > +
> > + drm_panel_disable(ps_bridge->panel);
> > + msleep(PS8622_PWMO_END_T12_MS);
> > +
> > + /*
> > +  * This doesn't matter if the regulators are turned off, but
> something
> > +  * else might keep them on. In that case, we want to assert the
> slp gpio
> > +  * to lower power.
> > +  */
> > + if (gpio_is_valid(ps_bridge->gpio_slp_n))
> > + gpio_set_value(ps_bridge->gpio_slp_n, 0);
> > +
> > + drm_panel_post_disable(ps_bridge->panel);
> > + if (ps_bridge->v12)
> > + regulator_disable(ps_bridge->v12);
> > +
> > + /*
> > +  * Sleep for at least the amount of time that it takes the power
> rail to
> > +  * fall to prevent asserting the rst gpio from doing anything.
> > +  */
> > + usleep_range(PS8622_POWER_FALL_T16_MAX_US,
> > +  2 * PS8622_POWER_FALL_T16_MAX_US);
> > + if (gpio_is_valid(ps_bridge->gpio_rst_n))
> > + gpio_set_value(ps_bridge->gpio_rst_n, 0);
> > +
> > + msleep(PS8622_POWER_OFF_T17_MS);
> > +
> > +out:
> > + mutex_unlock(_bridge->enable_mutex);
> > +}
> > +
> > +static void ps8622_post_disable(struct drm_bridge *bridge)
> > +{
> > +}
>
> How about just removing this empty function?

That is not possible. Because the bridge callbacks are called in this
fashion:
   bridge->funcs->post_disable(bridge);
So, if that particular callback turns NULL, it will crash!


>
[.]
>
> Best regards,
> Jingoo Han
>
>
Regards,
Ajay Kumar
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/5c712e01/attachment-0001.html>

[pull] radeon drm-fixes-3.15

[Christian König]

Hi Dave,

this is the first pull request for stashed radeon fixes for 3.15. 
Highlights:
1. Further PLL parameter fixes.
2. Fixes for HPD on DP
3. Could of different PM fixes
4. Disabling DPM on RV770

The following changes since commit a42892ed10585c5511e8a3e53f0350b4e2242050:

   Merge branch 'drm-next-3.15-wip' of 
git://people.freedesktop.org/~deathsimple/linux into drm-next 
(2014-04-19 11:16:02 +1000)

are available in the git repository at:


   git://people.freedesktop.org/~deathsimple/linux drm-fixes-3.15

for you to fetch changes up to 73acacc7397fe854ed2ab75f1c940fa00faaf15e:

   drm/radeon: don't allow runpm=1 on systems with out ATPX (2014-04-22 
16:51:21 +0200)


Alex Deucher (7):
   drm/radeon: disable dpm on rv770 by default
   drm/radeon/aux: fix hpd assignment for aux bus
   drm/radeon: fix count in cik_sdma_ring_test()
   drm/radeon: properly unregister hwmon interface (v2)
   drm/radeon/pm: don't walk the crtc list before it has been 
initialized (v2)
   drm/radeon: fix ATPX detection on non-VGA GPUs
   drm/radeon: don't allow runpm=1 on systems with out ATPX

Christian K?nig (2):
   drm/radeon: use fixed PPL ref divider if needed
   drm/radeon: improve PLL limit handling in post div calculation

  drivers/gpu/drm/radeon/atombios_dp.c |  1 +
  drivers/gpu/drm/radeon/cik_sdma.c|  2 +-
  drivers/gpu/drm/radeon/r600_dpm.c| 35 
+++
  drivers/gpu/drm/radeon/radeon_atpx_handler.c |  7 +++
  drivers/gpu/drm/radeon/radeon_display.c  | 84 
+---
  drivers/gpu/drm/radeon/radeon_kms.c  |  8 +++-
  drivers/gpu/drm/radeon/radeon_pm.c   | 51 
---
  7 files changed, 120 insertions(+), 68 deletions(-)

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Matt Roper]

On Tue, Apr 22, 2014 at 04:19:45PM +0200, Daniel Vetter wrote:
> The introduction of primary planes has apparently caused a bit of fb
> refcounting fun for people. That makes it a good time to clean up the
> arcane rules and slight differences between ->update_plane and
> ->set_config. The new rules are:
> 
> - The core holds a reference for both the new and the old fb (if
>   they're non-NULL of course) while calling into the driver through
>   either ->update_plane or ->set_config.
> 
> - Drivers may not clobber plane->fb if their callback fails. If they
>   do that, they need to store a pointer to the old fb in it again.
>   When calling into the driver plane->fb still points at the current
>   (old) framebuffer.
> 
> - The core will update the plane->fb pointer on success. Drivers can
>   do that themselves too, but aren't required to any more for the
>   primary plane.
> 
> - The core will update fb refcounts for the plane->fb pointer,
>   presuming the drivers hold up their end of the bargain.
> 
> v2: Remove now unused tmpfb (Thierry)
> 
> v3: Drop broken changes from drm_mode_setplane (Ville). Also polish
> the commit message a bit.

It looks like we might have some problems around setplane with fbid=0.
It looks like we're assuming that disabling a plane always succeeds
(which is no longer true for helper-based primary planes --- they just
return -EINVAL on disable now), so we wind up setting old_fb to the
currently scanned out framebuffer and then unref it at the end of the
function if I'm reading things correctly.  We also clobber the
plane->crtc and plane->fb pointers too when this happens.

I think the real problem here was introduced on b6ccd7b9 and I gave you
an r-b tag on that email, so that's my bad for not catching it before.
:-(


Matt

> 
> Cc: Thierry Reding 
> Cc: Ville Syrj?l? 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c |  8 
>  drivers/gpu/drm/drm_plane_helper.c | 16 
>  2 files changed, 4 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d8b7099abece..a76000ee2a43 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2187,16 +2187,18 @@ int drm_mode_setplane(struct drm_device *dev, void 
> *data,
>   }
>  
>   drm_modeset_lock_all(dev);
> + old_fb = plane->fb;
>   ret = plane->funcs->update_plane(plane, crtc, fb,
>plane_req->crtc_x, plane_req->crtc_y,
>plane_req->crtc_w, plane_req->crtc_h,
>plane_req->src_x, plane_req->src_y,
>plane_req->src_w, plane_req->src_h);
>   if (!ret) {
> - old_fb = plane->fb;
>   plane->crtc = crtc;
>   plane->fb = fb;
>   fb = NULL;
> + } else {
> + old_fb = NULL;
>   }
>   drm_modeset_unlock_all(dev);
>  
> @@ -2239,9 +2241,7 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> *set)
>   ret = crtc->funcs->set_config(set);
>   if (ret == 0) {
>   crtc->primary->crtc = crtc;
> -
> - /* crtc->fb must be updated by ->set_config, enforces this. */
> - WARN_ON(fb != crtc->primary->fb);
> + crtc->primary->fb = fb;
>   }
>  
>   list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 9540ff9f97fe..b72736d5541d 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -124,7 +124,6 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   .y2 = crtc->mode.vdisplay,
>   };
>   struct drm_connector **connector_list;
> - struct drm_framebuffer *tmpfb;
>   int num_connectors, ret;
>  
>   if (!crtc->enabled) {
> @@ -177,22 +176,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   set.connectors = connector_list;
>   set.num_connectors = num_connectors;
>  
> - /*
> -  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> -  * code that called us expects to handle the framebuffer update and
> -  * reference counting; save and restore the current fb before
> -  * calling it.
> -  *
> -  * N.B., we call set_config() directly here rather than using
> -  * drm_mode_set_config_internal.  We're reprogramming the same
> -  * connectors that were already in use, so we shouldn't need the extra
> -  * cross-CRTC fb refcounting to accomodate stealing connectors.
> -  * drm_mode_setplane() already handles the basic refcounting for the
> -  * framebuffers involved in this operation.
> -  */

I think there's still some value in the part of this comment that
explains why we're choosing not to call 

[PATCH 1/3] ARM: tegra: Deprecate nvidia,hpd-gpio property

[Lucas Stach]

Am Dienstag, den 22.04.2014, 09:23 +0200 schrieb Thierry Reding:
> On Mon, Apr 21, 2014 at 01:43:18PM -0600, Stephen Warren wrote:
> > On 04/17/2014 06:02 AM, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > Properties referencing GPIOs should use the plural suffix -gpios. This
> > > convention is encoded in the device tree backend of gpiod_get(), which
> > > we'll eventually want to migrate to.
> > 
> > Wouldn't it be simpler to fix the GPIO binding documentation and
> > gpiod_get() code to allow the -gpio suffix in addition to -gpios? It
> > always struck me as silly that the binding required a plural property
> > name when only a single entry made sense.
> > 
> > (For something like "clocks", since the property name applies to any
> > clock, and there certainly can be many clocks, a plural property name
> > makes sense. However, since each type of GPIO is "foo-gpios" rather than
> > an "foo" entry in "gpios", that same argument doesn't apply, and a
> > singular property name seems much more correct).
> 
> Yeah, it's somewhat unfortunate that this is done inconsistently across
> different subsystems. GPIO isn't the only exception here. Regulators use
> a similar pattern.
> 
> For consistency it'd be nice if we could get everyone to agree to one
> scheme, but I suspect that by now we're far beyond that being a viable
> option.
> 
> I don't have a strong feeling either way, so if allowing both *-gpios
> and *-gpio properties is what we want, then I can certainly come up with
> a patch.
> 
I agree with Stephen, allowing the singular form in the property name
seems like a nicer solution (it makes for a less irritating property
name), without the need to break existing DTs.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[Bug 74878] DRI_PRIME not working correctly

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

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

Iaroslav  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Iaroslav  ---
fixed after update

-- 
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/20140422/b1a42992/attachment-0001.html>

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

[Daniel Vetter]

On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> To implement hotplug detection in a race-free manner, drivers must call
> drm_kms_helper_poll_init() before hotplug events can be triggered. Such
> events can be triggered right after any of the encoders or connectors
> are initialized. At the same time, if the drm_fb_helper_hotplug_event()
> helper is used by a driver, then the poll helper requires some parts of
> the FB helper to be initialized to prevent a crash.
> 
> At the same time, drm_fb_helper_init() requires information that is not
> necessarily available at such an early stage (number of CRTCs and
> connectors), so it cannot be used yet.
> 
> Add a new helper, drm_fb_helper_prepare(), that initializes the bare
> minimum needed to allow drm_kms_helper_poll_init() to execute and any
> subsequent hotplug events to be processed properly.
> 
> Signed-off-by: Thierry Reding 

Some bikeshed on the kerneldoc below, with that addressed this is

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/armada/armada_fbdev.c |  2 +-
>  drivers/gpu/drm/ast/ast_fb.c  |  4 ++-
>  drivers/gpu/drm/bochs/bochs_fbdev.c   |  3 ++-
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  4 ++-
>  drivers/gpu/drm/drm_fb_cma_helper.c   |  3 ++-
>  drivers/gpu/drm/drm_fb_helper.c   | 43 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  3 ++-
>  drivers/gpu/drm/gma500/framebuffer.c  |  3 ++-
>  drivers/gpu/drm/i915/intel_fbdev.c|  3 ++-
>  drivers/gpu/drm/mgag200/mgag200_fb.c  |  3 ++-
>  drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  3 ++-
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  |  2 +-
>  drivers/gpu/drm/qxl/qxl_fb.c  |  5 +++-
>  drivers/gpu/drm/radeon/radeon_fb.c|  4 ++-
>  drivers/gpu/drm/tegra/fb.c|  4 +--
>  drivers/gpu/drm/udl/udl_fb.c  |  3 ++-
>  include/drm/drm_fb_helper.h   |  2 ++
>  18 files changed, 68 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 21aa1261dba2..9437e11d5df1 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -149,7 +149,7 @@ int armada_fbdev_init(struct drm_device *dev)
>  
>   priv->fbdev = fbh;
>  
> - fbh->funcs = _fb_helper_funcs;
> + drm_fb_helper_prepare(dev, fbh, _fb_helper_funcs);
>  
>   ret = drm_fb_helper_init(dev, fbh, 1, 1);
>   if (ret) {
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index 2113894e4ff8..cba45c774552 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -328,8 +328,10 @@ int ast_fbdev_init(struct drm_device *dev)
>   return -ENOMEM;
>  
>   ast->fbdev = afbdev;
> - afbdev->helper.funcs = _fb_helper_funcs;
>   spin_lock_init(>dirty_lock);
> +
> + drm_fb_helper_prepare(dev, >helper, _fb_helper_funcs);
> +
>   ret = drm_fb_helper_init(dev, >helper,
>1, 1);
>   if (ret) {
> diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
> b/drivers/gpu/drm/bochs/bochs_fbdev.c
> index 17e5c17f2730..19cf3e9413b6 100644
> --- a/drivers/gpu/drm/bochs/bochs_fbdev.c
> +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
> @@ -189,7 +189,8 @@ int bochs_fbdev_init(struct bochs_device *bochs)
>  {
>   int ret;
>  
> - bochs->fb.helper.funcs = _fb_helper_funcs;
> + drm_fb_helper_prepare(bochs->dev, >fb.helper,
> +   _fb_helper_funcs);
>  
>   ret = drm_fb_helper_init(bochs->dev, >fb.helper,
>1, 1);
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 2bd0291168e4..2a135f253e29 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -306,9 +306,11 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
>   return -ENOMEM;
>  
>   cdev->mode_info.gfbdev = gfbdev;
> - gfbdev->helper.funcs = _fb_helper_funcs;
>   spin_lock_init(>dirty_lock);
>  
> + drm_fb_helper_prepare(cdev->dev, >helper,
> +   _fb_helper_funcs);
> +
>   ret = drm_fb_helper_init(cdev->dev, >helper,
>cdev->num_crtc, CIRRUSFB_CONN_LIMIT);
>   if (ret) {
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index b74f9e58b69d..acbbd230e081 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -354,9 +354,10 @@ struct drm_fbdev_cma *drm_fbdev_cma_init(struct 
> drm_device *dev,
>   return ERR_PTR(-ENOMEM);
>   }
>  
> - fbdev_cma->fb_helper.funcs = _fb_cma_helper_funcs;
>   helper = _cma->fb_helper;
>  
> + drm_fb_helper_prepare(dev, helper, 

[RFC 4/5] drm: Introduce drm_set_unique()

[Daniel Vetter]

On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Add a helper function that allows drivers to statically set the unique
> name of the device. This will allow platform and USB drivers to get rid
> of their DRM bus implementations and directly use drm_dev_alloc() and
> drm_dev_register().
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 37 +++--
>  drivers/gpu/drm/drm_stub.c  |  1 +
>  include/drm/drmP.h  |  3 +++
>  3 files changed, 35 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 2dd3a6d8382b..371db3bef60c 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -42,6 +42,20 @@
>  #include 
>  #endif
>  
> +int drm_set_unique(struct drm_device *dev, const char *fmt, ...)

Can you please add a bit of kerneldoc for this? drm_ioctl.c isn't yet
pulled into the drm reference docbook, but better to have it there
already. With that fixed this is

Reviewed-by: Daniel Vetter 

> +{
> + va_list ap;
> +
> + kfree(dev->unique);
> +
> + va_start(ap, fmt);
> + dev->unique = kvasprintf(GFP_KERNEL, fmt, ap);
> + va_end(ap);
> +
> + return dev->unique ? 0 : -ENOMEM;
> +}
> +EXPORT_SYMBOL(drm_set_unique);
> +
>  /**
>   * Get the bus id.
>   *
> @@ -131,13 +145,24 @@ static int drm_set_busid(struct drm_device *dev, struct 
> drm_file *file_priv)
>   if (master->unique != NULL)
>   drm_unset_busid(dev, master);
>  
> - ret = dev->driver->bus->set_busid(dev, master);
> - if (ret)
> - goto err;
> + if (dev->driver->bus && dev->driver->bus->set_busid) {
> + ret = dev->driver->bus->set_busid(dev, master);
> + if (ret) {
> + drm_unset_busid(dev, master);
> + return ret;
> + }
> + } else {
> + WARN(dev->unique == NULL,
> +  "No drm_bus.set_busid() implementation provided by %ps. "
> +  "Set the unique name explicitly using drm_set_unique().",
> +  dev->driver);
> +
> + master->unique = kstrdup(dev->unique, GFP_KERNEL);
> + if (master->unique)
> + master->unique_len = strlen(dev->unique);
> + }
> +
>   return 0;
> -err:
> - drm_unset_busid(dev, master);
> - return ret;
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 3a8e832ad151..9465cf766fe7 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -646,6 +646,7 @@ static void drm_dev_release(struct kref *ref)
>   drm_minor_free(dev, DRM_MINOR_CONTROL);
>  
>   mutex_destroy(>master_mutex);
> + kfree(dev->unique);
>   kfree(dev);
>  }
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 8c80c1894b41..8fdefcdc4036 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1158,6 +1158,8 @@ struct drm_device {
>   struct drm_vma_offset_manager *vma_offset_manager;
>   /*@} */
>   int switch_power_state;
> +
> + char *unique;
>  };
>  
>  #define DRM_SWITCH_POWER_ON 0
> @@ -1238,6 +1240,7 @@ extern unsigned int drm_poll(struct file *filp, struct 
> poll_table_struct *wait);
>   /* Misc. IOCTL support (drm_ioctl.h) */
>  extern int drm_irq_by_busid(struct drm_device *dev, void *data,
>   struct drm_file *file_priv);
> +extern int drm_set_unique(struct drm_device *dev, const char *fmt, ...);
>  extern int drm_getunique(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
>  extern int drm_setunique(struct drm_device *dev, void *data,
> -- 
> 1.9.2
> 
> ___
> 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 V2 8/9] drm/bridge: Add PS8622 bridge driver

[Jingoo Han]

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> 
> This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
> bridge chip.
> 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Pushing V1 for this as V2 because this patch holds good in this series.
> 
>  drivers/gpu/drm/bridge/Kconfig  |7 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/ps8622.c |  566 
> +++
>  include/drm/bridge/ps8622.h |   42 +++
>  4 files changed, 616 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>  create mode 100644 include/drm/bridge/ps8622.h
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3bc6845..aba21fc 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -4,3 +4,10 @@ config DRM_PTN3460
>   select DRM_KMS_HELPER
>   select DRM_PANEL
>   ---help---
> +
> +config DRM_PS8622
> + tristate "Parade eDP/LVDS bridge"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_PANEL

Please add the following select.

+   select BACKLIGHT_LCD_SUPPORT
+   select BACKLIGHT_CLASS_DEVICE

Without this, the following build issues happen.

drivers/gpu/drm/bridge/ps8622.c:353: undefined reference to 
`backlight_device_unregister'
drivers/built-in.o: In function `ps8622_init':
drivers/gpu/drm/bridge/ps8622.c:559: undefined reference to 
`backlight_device_unregister'
drivers/gpu/drm/bridge/ps8622.c:507: undefined reference to 
`backlight_device_register'

> + ---help---
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b4733e1..d1b5daa 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,3 +1,4 @@
>  ccflags-y := -Iinclude/drm
> 
>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 000..1e6b3ca
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c

[.]

> +static int ps8622_send_config(struct ps8622_bridge *ps_bridge)
> +{
> + struct i2c_client *cl = ps_bridge->client;
> + int err = 0;
> +
> + /* wait 20ms after power ON */
> + usleep_range(2, 3);
> +
> + err |= ps8622_set(cl, 0x02, 0xa1, 0x01); /* HPD low */
> + /* SW setting */
> + err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V voltage
> +   * is lower to 96% */

The comment style looks awkward.
Please choose one of two options. And change all comments in this file.

1. 

+   /* SW setting */
+   err |= ps8622_set(cl, 0x04, 0x14, 0x01); /* [1:0] SW output 1.2V 
voltage is lower to 96% */

2. 

+   /* SW setting */
+   /* [1:0] SW output 1.2V voltage is lower to 96% */
+   err |= ps8622_set(cl, 0x04, 0x14, 0x01);


> + /* RCO SS setting */
> + err |= ps8622_set(cl, 0x04, 0xe3, 0x20); /* [5:4] = b01 0.5%, b10 1%,
> +   * b11 1.5% */
> + err |= ps8622_set(cl, 0x04, 0xe2, 0x80); /* [7] RCO SS enable */
> + /* RPHY Setting */
> + err |= ps8622_set(cl, 0x04, 0x8a, 0x0c); /* [3:2] CDR tune wait cycle
> +   * before measure for fine tune
> +   * b00: 1us b01: 0.5us b10:2us
> +   * b11: 4us */
> + err |= ps8622_set(cl, 0x04, 0x89, 0x08); /* [3] RFD always on */
> + err |= ps8622_set(cl, 0x04, 0x71, 0x2d); /* CTN lock in/out:
> +   * 2ppm/8ppm.
> +   * Lock out 2 times. */
> + /* 2.7G CDR settings */
> + err |= ps8622_set(cl, 0x04, 0x7d, 0x07); /* NOF=40LSB for HBR CDR
> +   * setting */
> + err |= ps8622_set(cl, 0x04, 0x7b, 0x00); /* [1:0] Fmin=+4bands */
> + err |= ps8622_set(cl, 0x04, 0x7a, 0xfd); /* [7:5] DCO_FTRNG=+-40% */
> + /* 1.62G CDR settings */
> + err |= ps8622_set(cl, 0x04, 0xc0, 0x12); /* [5:2]NOF=64LSB [1:0]DCO
> +   * scale is 2/5 */
> + err |= ps8622_set(cl, 0x04, 0xc1, 0x92); /* Gitune=-37% */
> + err |= ps8622_set(cl, 0x04, 0xc2, 0x1c); /* Fbstep=100% */
> + err |= ps8622_set(cl, 0x04, 0x32, 0x80); /* [7] LOS signal disable */
> + /* RPIO Setting */
> + err |= ps8622_set(cl, 0x04, 0x00, 0xb0); /* [7:4] LVDS driver bias
> +   * current : 75% (250mV swing)
> +   * */
> + err |= ps8622_set(cl, 0x04, 0x15, 0x40); /* [7:6] Right-bar GPIO output
> +   * 

[PATCH 2/4] drm: Constify struct drm_fb_helper_funcs

[Daniel Vetter]

On Tue, Apr 22, 2014 at 04:42:19PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> There's no need for this to be modifiable. Make it const so that it can
> be put into the .rodata section.
> 
> Signed-off-by: Thierry Reding 

Reviewed-by: Daniel Vetter 


> ---
>  drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
>  drivers/gpu/drm/ast/ast_fb.c  | 2 +-
>  drivers/gpu/drm/bochs/bochs_fbdev.c   | 2 +-
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
>  drivers/gpu/drm/drm_fb_cma_helper.c   | 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
>  drivers/gpu/drm/gma500/framebuffer.c  | 2 +-
>  drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
>  drivers/gpu/drm/mgag200/mgag200_fb.c  | 2 +-
>  drivers/gpu/drm/msm/msm_fbdev.c   | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 2 +-
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 +-
>  drivers/gpu/drm/qxl/qxl_fb.c  | 2 +-
>  drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
>  drivers/gpu/drm/tegra/fb.c| 2 +-
>  drivers/gpu/drm/udl/udl_fb.c  | 2 +-
>  include/drm/drm_fb_helper.h   | 2 +-
>  17 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 948cb14c561e..21aa1261dba2 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -131,7 +131,7 @@ static int armada_fb_probe(struct drm_fb_helper *fbh,
>   return ret;
>  }
>  
> -static struct drm_fb_helper_funcs armada_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs armada_fb_helper_funcs = {
>   .gamma_set  = armada_drm_crtc_gamma_set,
>   .gamma_get  = armada_drm_crtc_gamma_get,
>   .fb_probe   = armada_fb_probe,
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index a28640f47c27..2113894e4ff8 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -287,7 +287,7 @@ static void ast_fb_gamma_get(struct drm_crtc *crtc, u16 
> *red, u16 *green,
>   *blue = ast_crtc->lut_b[regno] << 8;
>  }
>  
> -static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs ast_fb_helper_funcs = {
>   .gamma_set = ast_fb_gamma_set,
>   .gamma_get = ast_fb_gamma_get,
>   .fb_probe = astfb_create,
> diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
> b/drivers/gpu/drm/bochs/bochs_fbdev.c
> index 561b84474122..17e5c17f2730 100644
> --- a/drivers/gpu/drm/bochs/bochs_fbdev.c
> +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
> @@ -179,7 +179,7 @@ void bochs_fb_gamma_get(struct drm_crtc *crtc, u16 *red, 
> u16 *green,
>   *blue  = regno;
>  }
>  
> -static struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs bochs_fb_helper_funcs = {
>   .gamma_set = bochs_fb_gamma_set,
>   .gamma_get = bochs_fb_gamma_get,
>   .fb_probe = bochsfb_create,
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 32bbba0a787b..2bd0291168e4 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -288,7 +288,7 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
>   return 0;
>  }
>  
> -static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
>   .gamma_set = cirrus_crtc_fb_gamma_set,
>   .gamma_get = cirrus_crtc_fb_gamma_get,
>   .fb_probe = cirrusfb_create,
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 61b5a47ad239..b74f9e58b69d 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -327,7 +327,7 @@ err_drm_gem_cma_free_object:
>   return ret;
>  }
>  
> -static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
> +static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
>   .fb_probe = drm_fbdev_cma_create,
>  };
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index addbf7536da4..7ccf04917f47 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -233,7 +233,7 @@ out:
>   return ret;
>  }
>  
> -static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
>   .fb_probe = exynos_drm_fbdev_create,
>  };
>  
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index e7fcc148f333..76e4d777d01d 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -561,7 +561,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
>   return psbfb_create(psb_fbdev, sizes);
>  }
>  
> -static struct 

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Ville Syrjälä]

On Tue, Apr 22, 2014 at 04:09:09PM +0200, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote:
> > On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> > > The introduction of primary planes has apparently caused a bit of fb
> > > refcounting fun for people. That makes it a good time to clean up the
> > > arcane rules and slight differences between ->update_plane and
> > > ->set_config. The new rules are:
> > > 
> > > - The core holds a reference for both the new and the old fb (if their
> > >   non-NULL of course) while calling into the driver through either
> > >   ->update_plane or ->set_config.
> > > 
> > > - Drivers may not clobber plane->fb if their callback fails. If they
> > >   do that, they need to store a pointer to the old fb in it again.
> > >   When calling into the driver plane->fb still points at the current
> > >   (old) framebuffer.
> > > 
> > > - The core will update the plane->fb pointer on success. Drivers can
> > >   do that themselves too.
> > > 
> > > - The core will update fb refcounts for the plane->fb pointer,
> > >   presuming the drivers hold up their end of the bargain.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_crtc.c | 12 +---
> > >  drivers/gpu/drm/drm_plane_helper.c | 15 ---
> > >  2 files changed, 5 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index d8b7099abece..966b480ed543 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, 
> > > void *data,
> > >   }
> > >  
> > >   drm_modeset_lock_all(dev);
> > > + old_fb = plane->fb;
> > >   ret = plane->funcs->update_plane(plane, crtc, fb,
> > >plane_req->crtc_x, plane_req->crtc_y,
> > >plane_req->crtc_w, plane_req->crtc_h,
> > >plane_req->src_x, plane_req->src_y,
> > >plane_req->src_w, plane_req->src_h);
> > >   if (!ret) {
> > > - old_fb = plane->fb;
> > >   plane->crtc = crtc;
> > >   plane->fb = fb;
> > > - fb = NULL;
> > >   }
> > >   drm_modeset_unlock_all(dev);
> > >  
> > >  out:
> > > - if (fb)
> > > - drm_framebuffer_unreference(fb);
> > > + if (plane->fb)
> > > + drm_framebuffer_reference(old_fb);
> >   ^^
> > 
> > That doesn't look right.
> > 
> > Also you're now dereferencing plane->fb after you drop the locks.
> 
> Oops, will fix.
> 
> > Also i915 fb destruction seems buggy as we do
> > intel_fb->obj->framebuffer_references-- w/o holding struct_mutex.
> 
> Hm, this indeed looks fishy. And the offending patch was actually r-b:
> you.

Dang. I suck.

> Not sure what to do here really.

Just s/drm_gem_object_unreference_unlocked/drm_gem_object_unreference/
and grab struct_mutex by hand around both operations?

> -Daniel
> 
> > 
> > >   if (old_fb)
> > >   drm_framebuffer_unreference(old_fb);
> > > + drm_framebuffer_unreference(fb);
> > >  
> > >   return ret;
> > >  }
> > > @@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct 
> > > drm_mode_set *set)
> > >   ret = crtc->funcs->set_config(set);
> > >   if (ret == 0) {
> > >   crtc->primary->crtc = crtc;
> > > -
> > > - /* crtc->fb must be updated by ->set_config, enforces this. */
> > > - WARN_ON(fb != crtc->primary->fb);
> > > + crtc->primary->fb = fb;
> > >   }
> > >  
> > >   list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
> > > diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> > > b/drivers/gpu/drm/drm_plane_helper.c
> > > index e768d35ff22e..8db129c44fea 100644
> > > --- a/drivers/gpu/drm/drm_plane_helper.c
> > > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > > @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane 
> > > *plane, struct drm_crtc *crtc,
> > >   set.connectors = connector_list;
> > >   set.num_connectors = num_connectors;
> > >  
> > > - /*
> > > -  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> > > -  * code that called us expects to handle the framebuffer update and
> > > -  * reference counting; save and restore the current fb before
> > > -  * calling it.
> > > -  *
> > > -  * N.B., we call set_config() directly here rather than using
> > > -  * drm_mode_set_config_internal.  We're reprogramming the same
> > > -  * connectors that were already in use, so we shouldn't need the extra
> > > -  * cross-CRTC fb refcounting to accomodate stealing connectors.
> > > -  * drm_mode_setplane() already handles the basic refcounting for the
> > > -  * framebuffers involved in this operation.
> > > -  */
> > > - tmpfb = plane->fb;
> > >   ret = crtc->funcs->set_config();
> > > - plane->fb = tmpfb;
> > >  
> > >   kfree(connector_list);
> > >   

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Thierry Reding]

On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
> Hi Thierry,
> 
> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
>  wrote:
> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
> >> Register exynos_dp_panel before the list of exynos crtcs and
> >> connectors are probed.
> >>
> >> This is needed because exynos_dp_panel should be registered to
> >> the drm_panel list via panel-exynos-dp probe, i.e much before
> >> exynos_dp_bind calls of_drm_find_panel().
> >>
> >> Signed-off-by: Ajay Kumar 
> >> ---
> >> Changes since V1:
> >>   Added platform_driver_unregister(_dp_panel_driver) to
> >>   exynos_drm_platform_remove as per Jingoo Han's correction
> >>
> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
> >>  2 files changed, 16 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> index 1d653f8..2db7f67 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
> >> platform_device *pdev)
> >>   goto err_unregister_ipp_drv;
> >>  #endif
> >>
> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
> >> + ret = platform_driver_register(_dp_panel_driver);
> >> + if (ret < 0)
> >> + goto err_unregister_dp_panel;
> >> +#endif
> >
> > No, this is not how you're supposed to use DRM panel drivers. The idea
> > is that you write a standalone driver for a given panel.
> >
> > What you do here has a number of problems. For one it's a driver that's
> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses
> > the same panel I want to be able to use the same driver, and not have to
> > rewrite the driver for my SoC.
> >
> > Another problem is that you're assuming here that the driver is built in
> > and it will break if you try to build either Exynos DRM or the panel
> > driver as a module. This is perhaps nothing you care about right now,
> > but eventually people will want to ship a single kernel that can run on
> > a number of SoCs. But if we keep adding things like this, that kernel
> > will keep growing in size until it no longer fits in any kind of memory.
> >
> > Thierry
> 
> I completely agree with you in this!
> 
> Yes, this is not acceptable, but I want to know an "acceptable"
> workaround for the situation below:
> I register the driver using module_init().
> And, exynos_drm gets probed much before the panel driver probe happens.
> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
> tries to call
> "of_drm_find_panel" which always returns NULL.

That's a situation that your driver needs to be able to deal with. The
driver registration order doesn't matter one bit. It may happen to work
most of the time, but as soon as one of the resources that your panel
driver needs isn't there when the panel is probed, then it won't be
registered and of_drm_find_panel() will still return NULL.

Usually the right thing to do in that case would be to return (and
propagate) -EPROBE_DEFER so that your driver's probe is deferred and
retried when other drivers have been probed. That way it should
eventually get a non-NULL panel.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/392c4797/attachment.sig>

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Thierry Reding]

On Tue, Apr 22, 2014 at 08:23:03PM +0530, Ajay kumar wrote:
> Hi Thierry,
> 
> 
> On Tue, Apr 22, 2014 at 1:56 PM, Thierry Reding
>  wrote:
> > On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote:
> >> This patch adds a simple driver to handle all the LCD and LED
> >> powerup/down routines needed to support eDP/eDP-LVDS panels
> >> supported on exynos boards.
> >>
> >> The LCD and LED units are usually powered up via regulators,
> >> and almost on all boards, we will have a BL_EN pin to enable/
> >> disable the backlight. Sometimes, we can have LCD_EN switches
> >> as well. The routines in this driver can be used to control
> >> panel power sequence on such boards.
> >>
> >> Signed-off-by: Ajay Kumar 
> >> ---
> >> Changes since V1:
> >>   Added routine for post_disable, removed few unwanted headers.
> >>   Refactored a lot of code.
> >>
> >>  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
> >>  drivers/gpu/drm/panel/Kconfig  |9 +
> >>  drivers/gpu/drm/panel/Makefile |1 +
> >>  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
> >> 
> >>  4 files changed, 306 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> >>  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
> >
> > What this patch does is in no way Exynos specific. It is also not eDP
> > specific.
> >
> Right. This is not at all writing into any "exynos" specific register,
> but can't this be just a placeholder for all the panel controls
> which can serve boards which use exynos_dp?

No, it shouldn't. Like I said, if I have a panel that happens to be used
on an Exynos board but I use it on a different board, then I don't want
to have to know that the panel might be supported by Exynos so that I
know which driver to use.

So ideally there should be one driver per panel. panel-simple was
introduced because of the five panels that I had access to at the time,
five panels could be supported using the same code.

> > This conflates panel drivers with board drivers in a strange way. Panel
> > drivers should be for *panels*, not for a given SoC or specific outputs
> > on that SoC.
> >
> Right. But for that matter, even the "panel-simple" driver is doing the same,
> which is just a placeholder for "generic" panel controls which serves
> multiple boards.

panel-simple is meant for panels that require only the parameters that
are specified for those. Anything that needs more is by definition no
longer "simple".

And the difference here is that panel-simple is a true wildcard, but it
isn't specific to one SoC. And the name doesn't imply that either. Also
each panel is still identified by the specific compatible value, which
makes it easier to find out which driver supports the panel.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/a60d37de/attachment.sig>

[RFC 5/5] drm/tegra: Convert to master/component framework

[Thierry Reding]

From: Thierry Reding 

Instead of the current implementation, reuse the recently introduced
master/component framework, which is equivalent in most regards. One
issue is that there is no device to bind the DRM driver to. In order
to still allow the driver to be probed, expose an interface from the
host1x device and provide an interface driver to bind to that.

The interface driver then registers (or removes) the master that will be
used to instantiate and bind the DRM driver. Since the drm_host1x bus
implementation is now gone the dummy device instantiated by it can no
longer be used as the parent for the DRM device. However since the
parent device doesn't need to be modified, the host1x parent device that
exposes the interface can be used instead.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/Makefile |   1 -
 drivers/gpu/drm/tegra/bus.c|  64 -
 drivers/gpu/drm/tegra/dc.c |  58 ++---
 drivers/gpu/drm/tegra/drm.c| 171 +
 drivers/gpu/drm/tegra/drm.h|  27 +-
 drivers/gpu/drm/tegra/dsi.c| 144 +--
 drivers/gpu/drm/tegra/gr2d.c   |  78 +++---
 drivers/gpu/drm/tegra/gr3d.c   |  77 +++---
 drivers/gpu/drm/tegra/hdmi.c   |  69 ++---
 drivers/gpu/drm/tegra/sor.c|  71 ++
 drivers/gpu/host1x/Makefile|   1 -
 drivers/gpu/host1x/bus.c   | 553 -
 drivers/gpu/host1x/bus.h   |  29 ---
 drivers/gpu/host1x/dev.c   |  21 +-
 drivers/gpu/host1x/dev.h   |   7 +-
 include/linux/host1x.h |  64 +
 16 files changed, 332 insertions(+), 1103 deletions(-)
 delete mode 100644 drivers/gpu/drm/tegra/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.h

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 905f6cad1061..e24584eb2e58 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -1,7 +1,6 @@
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG

 tegra-drm-y := \
-   bus.o \
drm.o \
gem.o \
fb.o \
diff --git a/drivers/gpu/drm/tegra/bus.c b/drivers/gpu/drm/tegra/bus.c
deleted file mode 100644
index b3a66d65cb53..
--- a/drivers/gpu/drm/tegra/bus.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Copyright (C) 2013 NVIDIA Corporation
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include "drm.h"
-
-static int drm_host1x_set_busid(struct drm_device *dev,
-   struct drm_master *master)
-{
-   const char *device = dev_name(dev->dev);
-   const char *bus = dev->dev->bus->name;
-
-   master->unique_len = strlen(bus) + 1 + strlen(device);
-   master->unique_size = master->unique_len;
-
-   master->unique = kmalloc(master->unique_len + 1, GFP_KERNEL);
-   if (!master->unique)
-   return -ENOMEM;
-
-   snprintf(master->unique, master->unique_len + 1, "%s:%s", bus, device);
-
-   return 0;
-}
-
-static struct drm_bus drm_host1x_bus = {
-   .set_busid = drm_host1x_set_busid,
-};
-
-int drm_host1x_init(struct drm_driver *driver, struct host1x_device *device)
-{
-   struct drm_device *drm;
-   int ret;
-
-   driver->bus = _host1x_bus;
-
-   drm = drm_dev_alloc(driver, >dev);
-   if (!drm)
-   return -ENOMEM;
-
-   ret = drm_dev_register(drm, 0);
-   if (ret)
-   goto err_free;
-
-   DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n", driver->name,
-driver->major, driver->minor, driver->patchlevel,
-driver->date, drm->primary->index);
-
-   return 0;
-
-err_free:
-   drm_dev_unref(drm);
-   return ret;
-}
-
-void drm_host1x_exit(struct drm_driver *driver, struct host1x_device *device)
-{
-   struct tegra_drm *tegra = dev_get_drvdata(>dev);
-
-   drm_put_dev(tegra->drm);
-}
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 3a54cf01e9fc..fc97d8a64cb6 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1102,10 +1102,10 @@ static int tegra_dc_debugfs_exit(struct tegra_dc *dc)
return 0;
 }

-static int tegra_dc_init(struct host1x_client *client)
+static int tegra_dc_bind(struct device *dev, struct master *master, void *data)
 {
-   struct tegra_drm *tegra = dev_get_drvdata(client->parent);
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_drm *tegra = master_get_drvdata(master);
+   struct tegra_dc *dc = dev_get_drvdata(dev);
int err;

drm_crtc_init(tegra->drm, >base, _crtc_funcs);
@@ -1114,7 +1114,7 @@ static int tegra_dc_init(struct host1x_client *client)

err = tegra_dc_rgb_init(tegra->drm, dc);
if (err < 0 && err != -ENODEV) {
-   dev_err(dc->dev, "failed to initialize RGB output: %d\n", err);
+ 

[RFC 4/5] drm: Introduce drm_set_unique()

[Thierry Reding]

From: Thierry Reding 

Add a helper function that allows drivers to statically set the unique
name of the device. This will allow platform and USB drivers to get rid
of their DRM bus implementations and directly use drm_dev_alloc() and
drm_dev_register().

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_ioctl.c | 37 +++--
 drivers/gpu/drm/drm_stub.c  |  1 +
 include/drm/drmP.h  |  3 +++
 3 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 2dd3a6d8382b..371db3bef60c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -42,6 +42,20 @@
 #include 
 #endif

+int drm_set_unique(struct drm_device *dev, const char *fmt, ...)
+{
+   va_list ap;
+
+   kfree(dev->unique);
+
+   va_start(ap, fmt);
+   dev->unique = kvasprintf(GFP_KERNEL, fmt, ap);
+   va_end(ap);
+
+   return dev->unique ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL(drm_set_unique);
+
 /**
  * Get the bus id.
  *
@@ -131,13 +145,24 @@ static int drm_set_busid(struct drm_device *dev, struct 
drm_file *file_priv)
if (master->unique != NULL)
drm_unset_busid(dev, master);

-   ret = dev->driver->bus->set_busid(dev, master);
-   if (ret)
-   goto err;
+   if (dev->driver->bus && dev->driver->bus->set_busid) {
+   ret = dev->driver->bus->set_busid(dev, master);
+   if (ret) {
+   drm_unset_busid(dev, master);
+   return ret;
+   }
+   } else {
+   WARN(dev->unique == NULL,
+"No drm_bus.set_busid() implementation provided by %ps. "
+"Set the unique name explicitly using drm_set_unique().",
+dev->driver);
+
+   master->unique = kstrdup(dev->unique, GFP_KERNEL);
+   if (master->unique)
+   master->unique_len = strlen(dev->unique);
+   }
+
return 0;
-err:
-   drm_unset_busid(dev, master);
-   return ret;
 }

 /**
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 3a8e832ad151..9465cf766fe7 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -646,6 +646,7 @@ static void drm_dev_release(struct kref *ref)
drm_minor_free(dev, DRM_MINOR_CONTROL);

mutex_destroy(>master_mutex);
+   kfree(dev->unique);
kfree(dev);
 }

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 8c80c1894b41..8fdefcdc4036 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1158,6 +1158,8 @@ struct drm_device {
struct drm_vma_offset_manager *vma_offset_manager;
/*@} */
int switch_power_state;
+
+   char *unique;
 };

 #define DRM_SWITCH_POWER_ON 0
@@ -1238,6 +1240,7 @@ extern unsigned int drm_poll(struct file *filp, struct 
poll_table_struct *wait);
/* Misc. IOCTL support (drm_ioctl.h) */
 extern int drm_irq_by_busid(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int drm_set_unique(struct drm_device *dev, const char *fmt, ...);
 extern int drm_getunique(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
 extern int drm_setunique(struct drm_device *dev, void *data,
-- 
1.9.2

[RFC 3/5] drivers/base: Add interface framework

[Thierry Reding]

From: Thierry Reding 

Some drivers, such as graphics drivers in the DRM subsystem, do not have
a real device that they can bind to. They are often composed of several
devices, each having their own driver. The master/component framework
can be used in these situations to collect the devices pertaining to one
logical device, wait until all of them have registered and then bind
them all at once.

For some situations this is only a partial solution. An implementation
of a master still needs to be registered with the system somehow. Many
drivers currently resort to creating a dummy device that a driver can
bind to and register the master against. This is problematic since it
requires (and presumes) knowledge about the system within drivers.

Furthermore there are setups where a suitable device already exists, but
is already bound to a driver. For example, on Tegra the following device
tree extract (simplified) represents the host1x device along with child
devices:

host1x {
display-controller {
...
};

display-controller {
...
};

hdmi {
...
};

dsi {
...
};

csi {
...
};

video-input {
...
};
};

Each of the child devices is in turn a client of host1x, in that it can
request resources (command stream DMA channels and syncpoints) from it.
To implement the DMA channel and syncpoint infrastructure, host1x comes
with its own driver. Children are implemented in separate drivers. In
Linux this set of devices would be exposed by DRM and V4L2 drivers.

However, neither the DRM nor the V4L2 drivers have a single device that
they can bind to. The DRM device is composed of the display controllers
and the various output devices, whereas the V4L2 device is composed of
one or more video input devices.

This patch introduces the concept of an interface and drivers that can
bind to a given interface. An interface can be exposed by any device,
and interface drivers can bind to these interfaces. Multiple drivers can
bind against a single interface. When a device is removed, interfaces
exposed by it will be removed as well, thereby removing the drivers that
were bound to those interfaces.

In the example above, the host1x device would expose the "tegra-host1x"
interface. DRM and V4L2 drivers can then bind to that interface and
instantiate the respective subsystem objects from there.

Signed-off-by: Thierry Reding 
---
 drivers/base/Makefile |   2 +-
 drivers/base/interface.c  | 186 ++
 include/linux/interface.h |  40 ++
 3 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/interface.c
 create mode 100644 include/linux/interface.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e0fa51..b5278904e443 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o
+  topology.o container.o interface.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/interface.c b/drivers/base/interface.c
new file mode 100644
index ..411f6cdf90e7
--- /dev/null
+++ b/drivers/base/interface.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (C) 2014 NVIDIA Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "interface: " fmt
+
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_MUTEX(interfaces_lock);
+static LIST_HEAD(interfaces);
+static LIST_HEAD(drivers);
+
+struct interface_attachment {
+   struct interface_driver *driver;
+   struct list_head list;
+};
+
+static bool interface_match(struct interface *intf,
+   struct interface_driver *driver)
+{
+   return strcmp(intf->name, driver->name) == 0;
+}
+
+static bool interface_attached(struct interface *intf,
+  struct interface_driver *driver)
+{
+   struct interface_attachment *attach;
+
+   list_for_each_entry(attach, >drivers, list)
+   if (attach->driver == driver)
+   return true;
+
+   return false;
+}
+
+static int interface_attach(struct interface *intf,
+

[RFC 2/5] drivers/base: Allow driver-data to be attached to a master

[Thierry Reding]

From: Thierry Reding 

Similarly to what can be done for device drivers, allow driver-specific
data to be attached to a master. This is necessary for masters whose
device is already bound to by a different driver and therefore cannot be
used to store the driver-specific data.

Signed-off-by: Thierry Reding 
---
 drivers/base/component.c  | 13 +
 include/linux/component.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 14fe81bf5ed2..e3693c6d552f 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -25,6 +25,8 @@ struct master {

const struct component_master_ops *ops;
struct device *dev;
+
+   void *drvdata;
 };

 struct component {
@@ -53,6 +55,17 @@ static struct master *__master_find(struct device *dev,
return NULL;
 }

+void master_set_drvdata(struct master *master, void *data)
+{
+   if (master)
+   master->drvdata = data;
+}
+
+void *master_get_drvdata(struct master *master)
+{
+   return master ? master->drvdata : NULL;
+}
+
 /* Attach an unattached component to a master. */
 static void component_attach_master(struct master *master, struct component *c)
 {
diff --git a/include/linux/component.h b/include/linux/component.h
index 89fe8bb35053..9c2ec9fe48d6 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -25,6 +25,9 @@ int component_master_add(struct device *, const struct 
component_master_ops *);
 void component_master_del(struct device *,
const struct component_master_ops *);

+void master_set_drvdata(struct master *, void *);
+void *master_get_drvdata(struct master *);
+
 int component_master_add_child(struct master *master,
int (*compare)(struct device *, void *), void *compare_data);

-- 
1.9.2

[RFC 1/5] drivers/base: Allow multiple masters per device

[Thierry Reding]

From: Thierry Reding 

Currently the component/master framework allows only a single master to
be registered against a struct device. A master is uniquely identified
by the device and the master operations table, but the current API does
not pass enough information along to allow a master to be uniquely
identified when calling component_unbind_all().

To make it possible to register multiple masters on one device, instead
of passing around the device associated with a master, pass around the
master directly. That way it can always be uniquely identified.

Signed-off-by: Thierry Reding 
---
 drivers/base/component.c  | 18 +++---
 include/linux/component.h | 17 -
 2 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index c4778995cd72..14fe81bf5ed2 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -120,7 +120,7 @@ static int try_to_bring_up_master(struct master *master,
 * Search the list of components, looking for components that
 * belong to this master, and attach them to the master.
 */
-   if (master->ops->add_components(master->dev, master)) {
+   if (master->ops->add_components(master, master->dev)) {
/* Failed to find all components */
master_remove_components(master);
ret = 0;
@@ -139,7 +139,7 @@ static int try_to_bring_up_master(struct master *master,
}

/* Found all components */
-   ret = master->ops->bind(master->dev);
+   ret = master->ops->bind(master, master->dev);
if (ret < 0) {
devres_release_group(master->dev, NULL);
dev_info(master->dev, "master bind failed: %d\n", ret);
@@ -172,7 +172,7 @@ static int try_to_bring_up_masters(struct component 
*component)
 static void take_down_master(struct master *master)
 {
if (master->bound) {
-   master->ops->unbind(master->dev);
+   master->ops->unbind(master, master->dev);
devres_release_group(master->dev, NULL);
master->bound = false;
}
@@ -233,21 +233,19 @@ static void component_unbind(struct component *component,
 {
WARN_ON(!component->bound);

-   component->ops->unbind(component->dev, master->dev, data);
+   component->ops->unbind(component->dev, master, data);
component->bound = false;

/* Release all resources claimed in the binding of this component */
devres_release_group(component->dev, component);
 }

-void component_unbind_all(struct device *master_dev, void *data)
+void component_unbind_all(struct master *master, void *data)
 {
-   struct master *master;
struct component *c;

WARN_ON(!mutex_is_locked(_mutex));

-   master = __master_find(master_dev, NULL);
if (!master)
return;

@@ -282,7 +280,7 @@ static int component_bind(struct component *component, 
struct master *master,
dev_dbg(master->dev, "binding %s (ops %ps)\n",
dev_name(component->dev), component->ops);

-   ret = component->ops->bind(component->dev, master->dev, data);
+   ret = component->ops->bind(component->dev, master, data);
if (!ret) {
component->bound = true;

@@ -308,15 +306,13 @@ static int component_bind(struct component *component, 
struct master *master,
return ret;
 }

-int component_bind_all(struct device *master_dev, void *data)
+int component_bind_all(struct master *master, void *data)
 {
-   struct master *master;
struct component *c;
int ret = 0;

WARN_ON(!mutex_is_locked(_mutex));

-   master = __master_find(master_dev, NULL);
if (!master)
return -EINVAL;

diff --git a/include/linux/component.h b/include/linux/component.h
index 68870182ca1e..89fe8bb35053 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -2,24 +2,23 @@
 #define COMPONENT_H

 struct device;
+struct master;

 struct component_ops {
-   int (*bind)(struct device *, struct device *, void *);
-   void (*unbind)(struct device *, struct device *, void *);
+   int (*bind)(struct device *, struct master *, void *);
+   void (*unbind)(struct device *, struct master *, void *);
 };

 int component_add(struct device *, const struct component_ops *);
 void component_del(struct device *, const struct component_ops *);

-int component_bind_all(struct device *, void *);
-void component_unbind_all(struct device *, void *);
-
-struct master;
+int component_bind_all(struct master *, void *);
+void component_unbind_all(struct master *, void *);

 struct component_master_ops {
-   int (*add_components)(struct device *, struct master *);
-   int (*bind)(struct device *);
-   void (*unbind)(struct 

[RFC 0/5] drm/tegra: Convert to master/component framework

[Thierry Reding]

From: Thierry Reding 

Hi,

This series converts the Tegra DRM driver to the master/component
framework. The length of the series and the list of people in Cc is
mostly due to the fact that Tegra has some special requirements as
opposed to other drivers and therefore requires some changes outside
of DRM.

Patches 1 and 2 make some changes to the master/component framework
which are necessary to convert Tegra DRM to use it. Note that since I'm
looking for early review I haven't converted any of the existing users
since I'm not sure if these are acceptable changes.

Patch 3 adds a new interface framework that supplements the master/
component framework and can be used in situations where there is no
struct device * that a driver can bind to.

A new function is introduced in patch 4 which can be used to get rid of
the DRM bus infrastructure in individual drivers. It should be able to
replace the requirement of having a drm_bus for all USB and platform
DRM drivers. For backwards-compatibility with legacy PCI drivers some-
thing different will probably be needed.

Finally, patch 5 converts the Tegra DRM driver over to using the master/
component framework using the above four patches.

Each patch has a somewhat more elaborate description of why it is needed
or what problem it solves. The patchset applies on top of linux-next
with Daniel's DRM cleanup series applied.

I welcome any questions or comments you might have.

Thierry

Thierry Reding (5):
  drivers/base: Allow multiple masters per device
  drivers/base: Allow driver-data to be attached to a master
  drivers/base: Add interface framework
  drm: Introduce drm_set_unique()
  drm/tegra: Convert to master/component framework

 drivers/base/Makefile  |   2 +-
 drivers/base/component.c   |  31 ++-
 drivers/base/interface.c   | 186 ++
 drivers/gpu/drm/drm_ioctl.c|  37 ++-
 drivers/gpu/drm/drm_stub.c |   1 +
 drivers/gpu/drm/tegra/Makefile |   1 -
 drivers/gpu/drm/tegra/bus.c|  64 -
 drivers/gpu/drm/tegra/dc.c |  58 ++---
 drivers/gpu/drm/tegra/drm.c| 171 +
 drivers/gpu/drm/tegra/drm.h|  27 +-
 drivers/gpu/drm/tegra/dsi.c| 144 +--
 drivers/gpu/drm/tegra/gr2d.c   |  78 +++---
 drivers/gpu/drm/tegra/gr3d.c   |  77 +++---
 drivers/gpu/drm/tegra/hdmi.c   |  69 ++---
 drivers/gpu/drm/tegra/sor.c|  71 ++
 drivers/gpu/host1x/Makefile|   1 -
 drivers/gpu/host1x/bus.c   | 553 -
 drivers/gpu/host1x/bus.h   |  29 ---
 drivers/gpu/host1x/dev.c   |  21 +-
 drivers/gpu/host1x/dev.h   |   7 +-
 include/drm/drmP.h |   3 +
 include/linux/component.h  |  20 +-
 include/linux/host1x.h |  64 +
 include/linux/interface.h  |  40 +++
 24 files changed, 625 insertions(+), 1130 deletions(-)
 create mode 100644 drivers/base/interface.c
 delete mode 100644 drivers/gpu/drm/tegra/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.c
 delete mode 100644 drivers/gpu/host1x/bus.h
 create mode 100644 include/linux/interface.h

-- 
1.9.2

[PATCH] drm/radeon: Fix num_banks calculation for SI

[Michel Dänzer]

From: Michel D?nzer 

The way the tile mode array index was calculated only makes sense for
the CIK specific macrotile mode array. For SI, we need to use one of the
tile mode array indices reserved for displayable surfaces.

This happened to result in correct display most if not all of the time
because most of the SI tiling modes use the same number of banks.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/atombios_crtc.c | 46 +++---
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index fb187c7..2b8039b 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1177,27 +1177,43 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,

/* Set NUM_BANKS. */
if (rdev->family >= CHIP_TAHITI) {
-   unsigned tileb, index, num_banks, tile_split_bytes;
+   unsigned index, num_banks;

-   /* Calculate the macrotile mode index. */
-   tile_split_bytes = 64 << tile_split;
-   tileb = 8 * 8 * target_fb->bits_per_pixel / 8;
-   tileb = min(tile_split_bytes, tileb);
+   if (rdev->family >= CHIP_BONAIRE) {
+   unsigned tileb, tile_split_bytes;

-   for (index = 0; tileb > 64; index++) {
-   tileb >>= 1;
-   }
+   /* Calculate the macrotile mode index. */
+   tile_split_bytes = 64 << tile_split;
+   tileb = 8 * 8 * target_fb->bits_per_pixel / 8;
+   tileb = min(tile_split_bytes, tileb);

-   if (index >= 16) {
-   DRM_ERROR("Wrong screen bpp (%u) or tile split 
(%u)\n",
- target_fb->bits_per_pixel, 
tile_split);
-   return -EINVAL;
-   }
+   for (index = 0; tileb > 64; index++)
+   tileb >>= 1;
+
+   if (index >= 16) {
+   DRM_ERROR("Wrong screen bpp (%u) or 
tile split (%u)\n",
+ target_fb->bits_per_pixel, 
tile_split);
+   return -EINVAL;
+   }

-   if (rdev->family >= CHIP_BONAIRE)
num_banks = 
(rdev->config.cik.macrotile_mode_array[index] >> 6) & 0x3;
-   else
+   } else {
+   switch (target_fb->bits_per_pixel) {
+   case 8:
+   index = 10;
+   break;
+   case 16:
+   index = 
SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP;
+   break;
+   default:
+   case 32:
+   index = 
SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP;
+   break;
+   }
+
num_banks = 
(rdev->config.si.tile_mode_array[index] >> 20) & 0x3;
+   }
+
fb_format |= EVERGREEN_GRPH_NUM_BANKS(num_banks);
} else {
/* NI and older. */
-- 
1.9.2

[PATCH 1/4] drm/radeon: properly unregister hwmon interface (v2)

[Christian König]

Am 15.04.2014 18:44, schrieb Alex Deucher:
> Need to properly unregister the hwmon device on driver
> unload.
>
> v2: minor clean up
>
> bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=73931
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

Added to my 3.15 queue.

Sorry for the delay, those patches somehow got lost in my inbox.

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_pm.c | 21 +++--
>   1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index ee738a5..e0a664d 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -603,7 +603,6 @@ static const struct attribute_group *hwmon_groups[] = {
>   static int radeon_hwmon_init(struct radeon_device *rdev)
>   {
>   int err = 0;
> - struct device *hwmon_dev;
>   
>   switch (rdev->pm.int_thermal_type) {
>   case THERMAL_TYPE_RV6XX:
> @@ -616,11 +615,11 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
>   case THERMAL_TYPE_KV:
>   if (rdev->asic->pm.get_temperature == NULL)
>   return err;
> - hwmon_dev = hwmon_device_register_with_groups(rdev->dev,
> -   "radeon", rdev,
> -   hwmon_groups);
> - if (IS_ERR(hwmon_dev)) {
> - err = PTR_ERR(hwmon_dev);
> + rdev->pm.int_hwmon_dev = 
> hwmon_device_register_with_groups(rdev->dev,
> +
> "radeon", rdev,
> +
> hwmon_groups);
> + if (IS_ERR(rdev->pm.int_hwmon_dev)) {
> + err = PTR_ERR(rdev->pm.int_hwmon_dev);
>   dev_err(rdev->dev,
>   "Unable to register hwmon device: %d\n", err);
>   }
> @@ -632,6 +631,12 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
>   return err;
>   }
>   
> +static void radeon_hwmon_fini(struct radeon_device *rdev)
> +{
> + if (rdev->pm.int_hwmon_dev)
> + hwmon_device_unregister(rdev->pm.int_hwmon_dev);
> +}
> +
>   static void radeon_dpm_thermal_work_handler(struct work_struct *work)
>   {
>   struct radeon_device *rdev =
> @@ -1353,6 +1358,8 @@ static void radeon_pm_fini_old(struct radeon_device 
> *rdev)
>   device_remove_file(rdev->dev, _attr_power_method);
>   }
>   
> + radeon_hwmon_fini(rdev);
> +
>   if (rdev->pm.power_state)
>   kfree(rdev->pm.power_state);
>   }
> @@ -1372,6 +1379,8 @@ static void radeon_pm_fini_dpm(struct radeon_device 
> *rdev)
>   }
>   radeon_dpm_fini(rdev);
>   
> + radeon_hwmon_fini(rdev);
> +
>   if (rdev->pm.power_state)
>   kfree(rdev->pm.power_state);
>   }

[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps

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

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

--- Comment #13 from Peter Fr?hberger  ---
No. And one note here: This is not xbmc forum. We are so kind there (cause we
have too much time), that we sort out "different issues" and codrivers. This
here is an official bugtracker. Every mail is forwarded to the Mailinglist.


So please, don't spam Christian and Alex. Your bug is fundamentally different
as you already have noted. So please, don't post "me toos" into a bugreport
which has some activity.

-- 
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/20140422/07b16def/attachment.html>

[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps

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

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

--- Comment #12 from bgunteriv at gmail.com ---
 @fritsch, 
is the kernel you posted on the XBMC forum -- 3.14.1-amdfixes2
considered "mainline"?

-- 
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/20140422/8811c326/attachment.html>

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

[Thierry Reding]

From: Thierry Reding 

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

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

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

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

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 6f5b6e2f552e..4d36debe3de6 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -41,6 +41,12 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)

drm_mode_config_init(drm);

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

-   drm_kms_helper_poll_init(drm);
-
return 0;
 }

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 126332c3ecbb..c2d9705de1f9 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -288,6 +288,7 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer 
*framebuffer,
unsigned int index);
 bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer);
 bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer);
+int tegra_drm_fb_prepare(struct drm_device *drm);
 extern int tegra_drm_fb_init(struct drm_device *drm);
 extern void tegra_drm_fb_exit(struct drm_device *drm);
 #ifdef CONFIG_DRM_TEGRA_FBDEV
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 2e3758542c89..70d0e07d353c 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -271,13 +271,9 @@ static const struct drm_fb_helper_funcs 
tegra_fb_helper_funcs = {
.fb_probe = tegra_fbdev_probe,
 };

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

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

drm_fb_helper_prepare(drm, >base, _fb_helper_funcs);

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

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

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

-   return fbdev;
+   return 0;

 fini:

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

[Thierry Reding]

From: Thierry Reding 

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

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

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

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

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

priv->fbdev = fbh;

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

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

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

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

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

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

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

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

+   drm_fb_helper_prepare(dev, helper, _fb_cma_helper_funcs);
+
ret = drm_fb_helper_init(dev, helper, num_crtc, max_conn_count);
if (ret < 0) {
dev_err(dev->dev, "Failed to initialize drm fb helper.\n");
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 80ce92ab91f9..7788f110fcbf 100644
--- 

[PATCH 2/4] drm: Constify struct drm_fb_helper_funcs

[Thierry Reding]

From: Thierry Reding 

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

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

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

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

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

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

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

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

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

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

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

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

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

[Thierry Reding]

From: Daniel Vetter 

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

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

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

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

drm/fb-helper: improve drm_fb_helper_initial_config locking

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

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

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

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 11 +--
 drivers/gpu/drm/i915/i915_dma.c |  3 ---
 drivers/gpu/drm/i915/i915_drv.c |  2 --
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_irq.c |  4 
 5 files changed, 5 insertions(+), 16 deletions(-)

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

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

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

return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 254b3236200b..dee36a5b7fae 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -448,7 +448,6 @@ static int i915_drm_freeze(struct drm_device *dev)
cancel_delayed_work_sync(_priv->rps.delayed_resume_work);

drm_irq_uninstall(dev);
-   dev_priv->enable_hotplug_processing = false;
/*
 * Disable CRTCs directly since we want to preserve sw state
 * for _thaw.
@@ -589,7 +588,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)
 * notifications.
 * */
intel_hpd_init(dev);
-   dev_priv->enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
intel_resume_hotplug(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d6acb401fd9..41094d6357b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1321,7 +1321,6 @@ struct drm_i915_private {
u32 pipestat_irq_mask[I915_MAX_PIPES];

[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps

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

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

--- Comment #11 from bgunteriv at gmail.com ---
Created attachment 97757
  --> https://bugs.freedesktop.org/attachment.cgi?id=97757=edit
old XBMC log file

I will try to get you more logs. i will need to load on a mainline kernel
first.

-- 
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/20140422/a7b6a0a1/attachment.html>

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

On Tue, Apr 22, 2014 at 4:28 PM, Ville Syrj?l?
 wrote:
>> Not sure what to do here really.
>
> Just s/drm_gem_object_unreference_unlocked/drm_gem_object_unreference/
> and grab struct_mutex by hand around both operations?

I was kinda hoping for someone to go ahead and fix the entire fb
tracking locking madness while at it ;-) I'll do the fixup.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps

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

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

--- Comment #10 from bgunteriv at gmail.com ---
i too suffer from this issue.
it's been going on for me as you will see from my log since kernel 3.13

i'm posting my XBMC log file since this is the only thing that I run on my
system.

My situation is a little different. 
with my system, the sound will be fine. Even certain streams will play just
fine for a while. then when something "interrupts" the stream, I start to get
the distortion/ echoing sounds. this is both audio and video streams.
sometimes I can play a 30 minute clip, and never get it. other times it will
start to happen in the first 5 minutes.

i have been wondering about ways to increase the buffer size / period size. but
have not had any luck.

I have also not tried PA as an option to see if it "fixes" the problem.

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

[PATCH] drm/radeon: fix count in cik_sdma_ring_test()

[Christian König]

Am 22.04.2014 14:17, schrieb Alex Deucher:
> Should be 5 rather than 4.
>
> Noticed-by: Mathias Fr?hlich 
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

Added to my 3.15 queue.

Christian.

> ---
>   drivers/gpu/drm/radeon/cik_sdma.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
> b/drivers/gpu/drm/radeon/cik_sdma.c
> index 89b4afa..f7e46cf 100644
> --- a/drivers/gpu/drm/radeon/cik_sdma.c
> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
> @@ -597,7 +597,7 @@ int cik_sdma_ring_test(struct radeon_device *rdev,
>   tmp = 0xCAFEDEAD;
>   writel(tmp, ptr);
>   
> - r = radeon_ring_lock(rdev, ring, 4);
> + r = radeon_ring_lock(rdev, ring, 5);
>   if (r) {
>   DRM_ERROR("radeon: dma failed to lock ring %d (%d).\n", 
> ring->idx, r);
>   return r;

[Bug 74121] [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

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

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

--- Comment #2 from Alan  ---
(Please also email the driver maintainers or relevant list)

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

[Bug 74121] [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
 Regression|No  |Yes

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

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

[Jingoo Han]

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> 
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/eDP-LVDS panels
> supported on exynos boards.
> 
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BL_EN pin to enable/
> disable the backlight. Sometimes, we can have LCD_EN switches
> as well. The routines in this driver can be used to control
> panel power sequence on such boards.
> 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Added routine for post_disable, removed few unwanted headers.
>   Refactored a lot of code.
> 
>  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
>  drivers/gpu/drm/panel/Kconfig  |9 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
> 
>  4 files changed, 306 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
> 
> diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> new file mode 100644
> index 000..3fbca54
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
> @@ -0,0 +1,45 @@
> +exynos_DP_panel/DP_to_LVDS_panel

Please fix it as below.

+Exynos DP panel/DP to LVDS panel

[]

> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..ea9d5ac 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0
>   select DRM_MIPI_DSI
>   select VIDEOMODE_HELPERS
> 
> +config DRM_PANEL_EXYNOS_DP
> + tristate "support for DP panels"

It looks very general. Please fix it as below.

+   tristate "support for Exynos DP panels"

Best regards,
Jingoo Han

> + depends on OF && DRM_PANEL && DRM_EXYNOS_DP
> + help
> +   DRM panel driver for DP panels and LVDS connected via DP bridges
> +   that need at most a regulator for LCD unit, a regulator for LED unit
> +   and/or enable GPIOs for LCD or LED units. Delay values can also be
> +   specified to support powerup and powerdown process.
> +

[.]

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:

- The core holds a reference for both the new and the old fb (if
  they're non-NULL of course) while calling into the driver through
  either ->update_plane or ->set_config.

- Drivers may not clobber plane->fb if their callback fails. If they
  do that, they need to store a pointer to the old fb in it again.
  When calling into the driver plane->fb still points at the current
  (old) framebuffer.

- The core will update the plane->fb pointer on success. Drivers can
  do that themselves too, but aren't required to any more for the
  primary plane.

- The core will update fb refcounts for the plane->fb pointer,
  presuming the drivers hold up their end of the bargain.

v2: Remove now unused tmpfb (Thierry)

v3: Drop broken changes from drm_mode_setplane (Ville). Also polish
the commit message a bit.

Cc: Thierry Reding 
Cc: Ville Syrj?l? 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c |  8 
 drivers/gpu/drm/drm_plane_helper.c | 16 
 2 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d8b7099abece..a76000ee2a43 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2187,16 +2187,18 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
}

drm_modeset_lock_all(dev);
+   old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
 plane_req->crtc_x, plane_req->crtc_y,
 plane_req->crtc_w, plane_req->crtc_h,
 plane_req->src_x, plane_req->src_y,
 plane_req->src_w, plane_req->src_h);
if (!ret) {
-   old_fb = plane->fb;
plane->crtc = crtc;
plane->fb = fb;
fb = NULL;
+   } else {
+   old_fb = NULL;
}
drm_modeset_unlock_all(dev);

@@ -2239,9 +2241,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
ret = crtc->funcs->set_config(set);
if (ret == 0) {
crtc->primary->crtc = crtc;
-
-   /* crtc->fb must be updated by ->set_config, enforces this. */
-   WARN_ON(fb != crtc->primary->fb);
+   crtc->primary->fb = fb;
}

list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 9540ff9f97fe..b72736d5541d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -124,7 +124,6 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
.y2 = crtc->mode.vdisplay,
};
struct drm_connector **connector_list;
-   struct drm_framebuffer *tmpfb;
int num_connectors, ret;

if (!crtc->enabled) {
@@ -177,22 +176,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
set.connectors = connector_list;
set.num_connectors = num_connectors;

-   /*
-* set_config() adjusts crtc->primary->fb; however the DRM setplane
-* code that called us expects to handle the framebuffer update and
-* reference counting; save and restore the current fb before
-* calling it.
-*
-* N.B., we call set_config() directly here rather than using
-* drm_mode_set_config_internal.  We're reprogramming the same
-* connectors that were already in use, so we shouldn't need the extra
-* cross-CRTC fb refcounting to accomodate stealing connectors.
-* drm_mode_setplane() already handles the basic refcounting for the
-* framebuffers involved in this operation.
-*/
-   tmpfb = plane->fb;
ret = crtc->funcs->set_config();
-   plane->fb = tmpfb;

kfree(connector_list);
return ret;
-- 
1.9.2

[Bug 74331] Screen goes blank when closing the lid of my notebook

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

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

--- Comment #1 from Alan  ---
Reporting it here is fine for an upstream kernel, but this is mostly used to
track bugs not necessarily fix them.

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

[Bug 74331] Screen goes blank when closing the lid of my notebook

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|x86-64  |Video(DRI - non Intel)
   Assignee|platform_x86_64 at kernel-bugs |drivers_video-dri at 
kernel-bu
   |.osdl.org   |gs.osdl.org
Product|Platform Specific/Hardware  |Drivers

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

[PATCH V2 1/9] drm/exynos: dp: support hotplug detection via GPIO

[Jingoo Han]

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> 
> From: Andrew Bresticker 
> 
> Certain bridge chips use a GPIO to indicate the cable status instead
> of the I_DP_HPD pin.  This adds an optional device-tree property,
> "samsung,hpd-gpio", to the exynos-dp controller which indicates that
> the specified GPIO should be used for hotplug detection.
> The GPIO is then set up as an edge-triggered interrupt where the
> rising edge indicates hotplug-in and the falling edge indicates hotplug-out.
> 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> Changes since V1:
>   Address reiew comments from Jingoo Han
> 
>  .../devicetree/bindings/video/exynos_dp.txt|4 ++
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   32 --
>  drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
>  drivers/gpu/drm/exynos/exynos_dp_reg.c |   44 
> ++--
>  4 files changed, 66 insertions(+), 15 deletions(-)

[.]

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote:
> On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> > The introduction of primary planes has apparently caused a bit of fb
> > refcounting fun for people. That makes it a good time to clean up the
> > arcane rules and slight differences between ->update_plane and
> > ->set_config. The new rules are:
> > 
> > - The core holds a reference for both the new and the old fb (if their
> >   non-NULL of course) while calling into the driver through either
> >   ->update_plane or ->set_config.
> > 
> > - Drivers may not clobber plane->fb if their callback fails. If they
> >   do that, they need to store a pointer to the old fb in it again.
> >   When calling into the driver plane->fb still points at the current
> >   (old) framebuffer.
> > 
> > - The core will update the plane->fb pointer on success. Drivers can
> >   do that themselves too.
> > 
> > - The core will update fb refcounts for the plane->fb pointer,
> >   presuming the drivers hold up their end of the bargain.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 12 +---
> >  drivers/gpu/drm/drm_plane_helper.c | 15 ---
> >  2 files changed, 5 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d8b7099abece..966b480ed543 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, void 
> > *data,
> > }
> >  
> > drm_modeset_lock_all(dev);
> > +   old_fb = plane->fb;
> > ret = plane->funcs->update_plane(plane, crtc, fb,
> >  plane_req->crtc_x, plane_req->crtc_y,
> >  plane_req->crtc_w, plane_req->crtc_h,
> >  plane_req->src_x, plane_req->src_y,
> >  plane_req->src_w, plane_req->src_h);
> > if (!ret) {
> > -   old_fb = plane->fb;
> > plane->crtc = crtc;
> > plane->fb = fb;
> > -   fb = NULL;
> > }
> > drm_modeset_unlock_all(dev);
> >  
> >  out:
> > -   if (fb)
> > -   drm_framebuffer_unreference(fb);
> > +   if (plane->fb)
> > +   drm_framebuffer_reference(old_fb);
>   ^^
> 
> That doesn't look right.
> 
> Also you're now dereferencing plane->fb after you drop the locks.

Oops, will fix.

> Also i915 fb destruction seems buggy as we do
> intel_fb->obj->framebuffer_references-- w/o holding struct_mutex.

Hm, this indeed looks fishy. And the offending patch was actually r-b:
you. Not sure what to do here really.
-Daniel

> 
> > if (old_fb)
> > drm_framebuffer_unreference(old_fb);
> > +   drm_framebuffer_unreference(fb);
> >  
> > return ret;
> >  }
> > @@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> > *set)
> > ret = crtc->funcs->set_config(set);
> > if (ret == 0) {
> > crtc->primary->crtc = crtc;
> > -
> > -   /* crtc->fb must be updated by ->set_config, enforces this. */
> > -   WARN_ON(fb != crtc->primary->fb);
> > +   crtc->primary->fb = fb;
> > }
> >  
> > list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
> > diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> > b/drivers/gpu/drm/drm_plane_helper.c
> > index e768d35ff22e..8db129c44fea 100644
> > --- a/drivers/gpu/drm/drm_plane_helper.c
> > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> > struct drm_crtc *crtc,
> > set.connectors = connector_list;
> > set.num_connectors = num_connectors;
> >  
> > -   /*
> > -* set_config() adjusts crtc->primary->fb; however the DRM setplane
> > -* code that called us expects to handle the framebuffer update and
> > -* reference counting; save and restore the current fb before
> > -* calling it.
> > -*
> > -* N.B., we call set_config() directly here rather than using
> > -* drm_mode_set_config_internal.  We're reprogramming the same
> > -* connectors that were already in use, so we shouldn't need the extra
> > -* cross-CRTC fb refcounting to accomodate stealing connectors.
> > -* drm_mode_setplane() already handles the basic refcounting for the
> > -* framebuffers involved in this operation.
> > -*/
> > -   tmpfb = plane->fb;
> > ret = crtc->funcs->set_config();
> > -   plane->fb = tmpfb;
> >  
> > kfree(connector_list);
> > return ret;
> > -- 
> > 1.9.2
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrj?l?
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu timings.
> 
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properties (commented by Laurent Pinchart)
> - Adds OLED detection, TE gpio properties
> Changelog v4:
> - Moves CPU timings relevant properties from FIMD DT
>   (commeted by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 
> 
>  1 file changed, 63 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt 
> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> new file mode 100644
> index 000..9eeb38b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> @@ -0,0 +1,63 @@
> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3fa0"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: a GPIO spec for the reset pin
> +  - det-gpio: a GPIO spec for the OLED detection pin
> +  - te-gpio: a GPIO spec for the TE pin

Just FYI, according to DT documentation [1] gpio spec should be in form
[name]-gpios, however there is plenty bindings with -gpio suffix, so I
am not sure if it is really enforced. On the other side it is enforced
by descriptor based gpio framework[2]. Integer-based gpio framework
used in your driver is obsolete according to [2].

[1]: Documentation/devicetree/bindings/gpio/gpio.txt
[2]: Documentation/gpio/gpio.txt

Regards
Andrzej

> +  - display-timings: timings for the connected panel as described by [1]
> +  - cpu-timings: CPU interface timings for the connected panel, and it 
> contains
> +following optional properties.
> +  - cs-setup: clock cycles for the active period of address signal
> +enable until chip select is enable in CPU interface
> +  - wr-setup: clock cycles for the active period of CS signal enable
> +until write signal is enable in CPU interface
> +  - wr-act: clock cycles for the active period of CS enable in CPU
> +interface
> +  - wr-hold: clock cycles for the active period of CS disable until
> +write signal is disable in CPU interface
> +
> +Optional properties:
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + panel at 0 {
> + compatible = "samsung,s6e3fa0";
> + reg = <0>;
> + vdd3-supply = <_reg>;
> + vci-supply = <_reg>;
> + reset-gpio = < 4 0>;
> + det-gpio = < 6 0>;
> + te-gpio = < 7 0>;
> +
> + display-timings {
> + timing0: timing-0 {
> + clock-frequency = <0>;
> + hactive = <1080>;
> + vactive = <1920>;
> + hfront-porch = <2>;
> + hback-porch = <2>;
> + hsync-len = <1>;
> + vfront-porch = <1>;
> + vback-porch = <4>;
> + vsync-len = <1>;
> + };
> + };
> +
> + cpu-timings {
> + cs-setup = <0>;
> + wr-setup = <0>;
> + wr-act = <1>;
> + wr-hold = <0>;
> + };
> + };
> 

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

[Daniel Vetter]

On Tue, Apr 22, 2014 at 07:34:03AM -0400, Rob Clark wrote:
> So what about, rather than adding drm_panel support to each bridge
> individually, we introduce a drm_panel_bridge (with a form of
> chaining).. ie:
> 
>   struct drm_panel_bridge {
> struct drm_bridge base;
> struct drm_panel *panel;
> struct drm_bridge *bridge; /* optional */
>   };
> 
>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>   {
> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
> if (pb->bridge)
>   pb->bridge->funcs->enable(pb->bridge);
> pb->panel->funcs->enable(pb->panel);
>   }
> 
> ... and so on.
> 
> If you don't need a real bridge, just create one of these w/
> pb->bridge==NULL, otherwise create it as a wrapper for your real
> bridge.

Yeah I think that's how I'd have implemented some generic abstraction for
drivers using the crtc helpers. This allows you to keep bridge drivers,
panel drivers and anything else you might have in your driver to feed the
pixel stream to those 2 guys separate. And it also allows you to set it
all up in different ways, e.g. using device tree metadata, or acpi or some
other table hardcoded in a video rom somewhere.

Imo we also should have something similar to chain up drm_bridge devices.
tbh I'm not terribly happy about how the current integration with the crtc
modeset helpers is done ...
-Daniel

> 
> BR,
> -R
> 
> On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar  
> wrote:
> > attach ptn3460 connector to drm_panel and support drm_panel routines,
> > if a valid drm_panel object is passed to ptn3460_init.
> >
> > Signed-off-by: Ajay Kumar 
> > ---
> > Changes since V1:
> > Address few coding style comments from Jingoo Han
> >
> >  drivers/gpu/drm/bridge/Kconfig  |1 +
> >  drivers/gpu/drm/bridge/ptn3460.c|   20 +++-
> >  drivers/gpu/drm/exynos/exynos_dp_core.c |   16 
> >  include/drm/bridge/ptn3460.h|6 --
> >  4 files changed, 36 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 884923f..3bc6845 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -2,4 +2,5 @@ config DRM_PTN3460
> > tristate "PTN3460 DP/LVDS bridge"
> > depends on DRM
> > select DRM_KMS_HELPER
> > +   select DRM_PANEL
> > ---help---
> > diff --git a/drivers/gpu/drm/bridge/ptn3460.c 
> > b/drivers/gpu/drm/bridge/ptn3460.c
> > index f1d2afc..3920202 100644
> > --- a/drivers/gpu/drm/bridge/ptn3460.c
> > +++ b/drivers/gpu/drm/bridge/ptn3460.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "drmP.h"
> >  #include "drm_edid.h"
> > @@ -38,6 +39,7 @@ struct ptn3460_bridge {
> > struct i2c_client *client;
> > struct drm_encoder *encoder;
> > struct drm_bridge *bridge;
> > +   struct drm_panel *panel;
> > struct edid *edid;
> > int gpio_pd_n;
> > int gpio_rst_n;
> > @@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge 
> > *bridge)
> > gpio_set_value(ptn_bridge->gpio_rst_n, 1);
> > }
> >
> > +   drm_panel_pre_enable(ptn_bridge->panel);
> > +
> > /*
> >  * There's a bug in the PTN chip where it falsely asserts hotplug 
> > before
> >  * it is fully functional. We're forced to wait for the maximum 
> > start up
> > @@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge 
> > *bridge)
> >
> >  static void ptn3460_enable(struct drm_bridge *bridge)
> >  {
> > +   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> > +
> > +   if (ptn_bridge->enabled)
> > +   drm_panel_enable(ptn_bridge->panel);
> >  }
> >
> >  static void ptn3460_disable(struct drm_bridge *bridge)
> > @@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)
> >
> > ptn_bridge->enabled = false;
> >
> > +   drm_panel_disable(ptn_bridge->panel);
> > +   drm_panel_post_disable(ptn_bridge->panel);
> > +
> > if (gpio_is_valid(ptn_bridge->gpio_rst_n))
> > gpio_set_value(ptn_bridge->gpio_rst_n, 1);
> >
> > @@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)
> >
> > power_off = !ptn_bridge->enabled;
> > ptn3460_pre_enable(ptn_bridge->bridge);
> > +   ptn3460_enable(ptn_bridge->bridge);
> >
> > edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
> > if (!edid) {
> > @@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
> >  };
> >
> >  int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> > -   struct i2c_client *client, struct device_node *node)
> > +   struct i2c_client *client, struct device_node *node,
> > +   struct drm_panel *panel)
> >  {
> > int ret;
> > struct drm_bridge *bridge;
> > @@ -324,6 

[Bug 74551] Unable to enable ACPI

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Other   |Video(DRI - non Intel)
   Assignee|acpi_other at kernel-bugs.osdl |drivers_video-dri at 
kernel-bu
   |.org|gs.osdl.org
Product|ACPI|Drivers
 Regression|No  |Yes

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

[Intel-gfx] Design review request: DRM color manager

[Daniel Vetter]

On Tue, Apr 22, 2014 at 12:07:41PM +, Sharma, Shashank wrote:
> Thanks again David, 
> Comments inline. 

Three things:
- Please don't send out .pptx files to upstream/public mailing lists,
  that's just not how the upstream community works.

- Please either fix up ms outlook to do proper in-line quoting or switch
  to a proper mail client for discussions on dri-devel. I'm ok with this
  on intel-gfx to some extend since that's our own turf, but on dri-devel
  the usual rules apply.

- I think we should discuss this internally first or at least just on
  intel-gfx.

David, thanks for taking a look at this but imo this shouldn't have
escaped yet to the public. My apologies for wasting your time trying to
review this proposal.

Thanks, Daniel

> 
> Regards
> Shashank
> -Original Message-
> From: David Herrmann [mailto:dh.herrmann at gmail.com] 
> Sent: Tuesday, April 22, 2014 5:10 PM
> To: Sharma, Shashank
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
> Ville Syrj?l?; Thierry Reding; Alex Deucher; Sean Paul; robdclark at 
> gmail.com; Mukherjee, Indranil; Jindal, Sonika; Korjani, Vikas; Shankar, Uma; 
> Cn, Ramakrishnan
> Subject: Re: Design review request: DRM color manager
> 
> Hi
> 
> On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank  intel.com> wrote:
> > 1) Why do you register only a single property? Why not register a separate 
> > property for each color-correction that is available? This way you can drop 
> > the property-id and use the high-level DRM-prop IDs/names.
> >>> That?s the whole idea of color manager. If we keep on creating properties 
> >>> for each color correction, there would be a big list and a lot of 
> >>> properties will be exposed. Instead one common blob which can represent 
> >>> all the properties, correction values and identifiers. It would be easy 
> >>> to club with atomic modeset kind-of designs also I believe.
> 
> Where is the difference? With one _well-defined_ property for each type we 
> simply move the identification one level up. With your approach you just move 
> the type-id one level down into the blob.
> 
> Or in other words: Where is the difference between calling
> SetProperty() n-times, or calling it once but with a parameter describing 
> n-properties? With atomic-modesetting we can set as many properties as we 
> want and make the kernel apply them atomically.
> 
> >>> Actually we also do not want to populate the property space also, as if 
> >>> there are 10 color correction methods possible for a hardware, we might 
> >>> end up listing 10 properties.  And there won't be common properties 
> >>> across all the hardwares also. For example, Hardware A can have 
> >>> properties X Y Z but Hardware B can have W X and Z. This will make the 
> >>> property space inconsistent. But if we provide one common interface which 
> >>> will cover for all the properties, for all the hardwares in a single 
> >>> blob. The driver will dynamically register its property, in its own 
> >>> preferred name. A get_prop() will always list down all the supported 
> >>> color property by this hardware and driver.   
> 
> > 2) What is the CRTC-ID for? DRM properties can be set on a specific CRTC 
> > and/or plane. Isn't that enough information for the driver?
> >>> This is to make it HW agonist. Actually that's CRTC ID / Plane ID / PIPE 
> >>> ID / all together an identifier. For example if I want to set gamma 
> >>> correction for sprite planes only, not on primary plane or pipe level, on 
> >>> VLV, its possible. This gives me flexibility to mention fine-tuned 
> >>> correction even in a CRTC.  The driver's .enable method can take decision 
> >>> on this identifier based on the hardware capabilities.
> 
> Yeah, but I meant the drmModeObjectSetProperty() ioctl already tales a 
> CRTC/Plane/Connector ID. So why duplicate that information in the blob? And 
> more importantly, what happens if you call
> drmModeObjectSetProperty() on a plane but specify a CRTC ID in the blob? 
> Seems weird to me to support such setups.
> 
> >>> The design is to register color-manager as a CRTC property, to make it 
> >>> consistent, and then give the fine tuning via this identifier byte. 
> Else we have to keep track of this in userspace, that which property is valid 
> for which extent. For example, Hue and saturation correction, on VLV, can be 
> applied on Sprite planes only(not on primary plane). So we have to send a 
> plane as an object here. 
> Rather in color manager case, we will always send the CRTC as an object to 
> IOCTL, but will specify SPRITE_PLANE as identifier. Does this sound less 
> weird now  :) ? 
> 
> > 3) Please document the payload for each of the properties you define.
> > If the property is a blob, there is no reason to make the properties 
> > generic. User-space requires a common syntax across all drivers, otherwise, 
> > it cannot make use of generic properties and you should use 
> > driver-dependent properties instead.
> >>> 

[PATCH 0/6] File Sealing & memfd_create()

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 2:44 PM, Florian Weimer  wrote:
> I didn't find that very convincing.  But in v2, seals are monotonic, so
> checking them should be reliable enough.

Ok.

> What happens when you create a loop device on a write-sealed descriptor?

Any write-back to the loop-device will fail with EPERM as soon as the
fd gets write-sealed. See __do_lo_send_write() in
drivers/block/loop.c. It's up to the loop-device to forward the error
via bio_endio() to the caller for proper error-handling.

Thanks
David

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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/20140422/c1b91c86/attachment.html>

[PATCH] drm/exynos: use %pad for dma_addr_t

[Jingoo Han]

Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.

Signed-off-by: Jingoo Han 
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 59827cc..9cf71fa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -263,7 +263,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
buffer->sgt = sgt;
exynos_gem_obj->base.import_attach = attach;

-   DRM_DEBUG_PRIME("dma_addr = 0x%x, size = 0x%lx\n", buffer->dma_addr,
+   DRM_DEBUG_PRIME("dma_addr = %pad, size = 0x%lx\n", >dma_addr,
buffer->size);

return _gem_obj->base;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3319289..e4689ef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -221,7 +221,7 @@ static void vidi_win_commit(struct exynos_drm_manager *mgr, 
int zpos)

win_data->enabled = true;

-   DRM_DEBUG_KMS("dma_addr = 0x%x\n", win_data->dma_addr);
+   DRM_DEBUG_KMS("dma_addr = %pad\n", _data->dma_addr);

if (ctx->vblank_on)
schedule_work(>work);
-- 
1.7.10.4

[PATCH 0/6] File Sealing & memfd_create()

[Florian Weimer]

On 04/22/2014 01:55 PM, David Herrmann wrote:
> Hi
>
> On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer  
> wrote:
>> Ah.  What do you recommend for recipient to recognize such descriptors?
>> Would they just try to seal them and reject them if this fails?
>
> This highly depends on your use-case. Please see the initial email in
> this thread. It describes 2 example use-cases. In both cases, the
> recipients read the current set of seals and verify that a given set
> of seals is set.

I didn't find that very convincing.  But in v2, seals are monotonic, so 
checking them should be reliable enough.

What happens when you create a loop device on a write-sealed descriptor?

-- 
Florian Weimer / Red Hat Product Security Team

[RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[Andrzej Hajda]

Hi YoungJun,

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> Some phy control registers are not kept after software reset.
> So this patch makes the clocks containing phy control to be set
> after software reset.
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 956e5f3..2cf1f0b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
>  
>  static int exynos_dsi_init(struct exynos_dsi *dsi)
>  {
> - exynos_dsi_enable_clock(dsi);
>   exynos_dsi_reset(dsi);
>   enable_irq(dsi->irq);
>   exynos_dsi_wait_for_reset(dsi);
> + exynos_dsi_enable_clock(dsi);
>   exynos_dsi_init_link(dsi);
>  
>   return 0;

I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.

I will comment your previous answer here to make the discussion easier:
> As I mentioned in description, it came from phy control registers.
> Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
> DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
> affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
>
> So this patch is required for Exynos5 SoCs.

In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.

Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?

Regards
Andrzej

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

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

--- Comment #6 from Jaime Rave  ---
Is there any way I can create a more useful apitrace? Let me know if there's
something else I can attach to help fix this 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/20140422/bb6e4646/attachment.html>

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

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

--- Comment #5 from Jaime Rave  ---
Created attachment 97751
  --> https://bugs.freedesktop.org/attachment.cgi?id=97751=edit
Xorg.0.log

-- 
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/20140422/3a6dd10d/attachment.html>

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

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

--- Comment #4 from Jaime Rave  ---
Created attachment 97750
  --> https://bugs.freedesktop.org/attachment.cgi?id=97750=edit
Wine Console Output

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

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

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

--- Comment #3 from Jaime Rave  ---
Created attachment 97749
  --> https://bugs.freedesktop.org/attachment.cgi?id=97749=edit
dmesg

-- 
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/20140422/fd4aea29/attachment.html>

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

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

--- Comment #2 from Jaime Rave  ---
Created attachment 97748
  --> https://bugs.freedesktop.org/attachment.cgi?id=97748=edit
glxinfo

-- 
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/20140422/bc631898/attachment.html>

[PATCH 0/6] File Sealing & memfd_create()

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer  wrote:
> Ah.  What do you recommend for recipient to recognize such descriptors?
> Would they just try to seal them and reject them if this fails?

This highly depends on your use-case. Please see the initial email in
this thread. It describes 2 example use-cases. In both cases, the
recipients read the current set of seals and verify that a given set
of seals is set.

Thanks
David

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

[Daniel Vetter]

On Tue, Apr 22, 2014 at 12:08 PM, Thierry Reding
 wrote:
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
> *helper,
>const struct drm_fb_helper_funcs *funcs)
> {
> helper->funcs = funcs;
> helper->dev = dev;
> }
>
> So I wonder if that's still what we want or whether drivers should
> simply be doing that manually if they need to. Having a function for it
> gives us a place to document things, though, and perhaps at some point
> we'll have to extend this, so it may be a good idea after all, even if
> it's just the two lines currently.

Yeah the usefulness of this will be in the documentation that explains
how to use it, not in the code sharing/extraction. For critical code
we could just plunk it into a static inline, but since this is init
code I wouldn't really care with that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Design review request: DRM color manager

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank
 wrote:
> 1) Why do you register only a single property? Why not register a separate 
> property for each color-correction that is available? This way you can drop 
> the property-id and use the high-level DRM-prop IDs/names.
>>> That?s the whole idea of color manager. If we keep on creating properties 
>>> for each color correction, there would be a big list and a lot of 
>>> properties will be exposed. Instead one common blob which can represent all 
>>> the properties, correction values and identifiers. It would be easy to club 
>>> with atomic modeset kind-of designs also I believe.

Where is the difference? With one _well-defined_ property for each
type we simply move the identification one level up. With your
approach you just move the type-id one level down into the blob.

Or in other words: Where is the difference between calling
SetProperty() n-times, or calling it once but with a parameter
describing n-properties? With atomic-modesetting we can set as many
properties as we want and make the kernel apply them atomically.

> 2) What is the CRTC-ID for? DRM properties can be set on a specific CRTC 
> and/or plane. Isn't that enough information for the driver?
>>> This is to make it HW agonist. Actually that's CRTC ID / Plane ID / PIPE ID 
>>> / all together an identifier. For example if I want to set gamma correction 
>>> for sprite planes only, not on primary plane or pipe level, on VLV, its 
>>> possible. This gives me flexibility to mention fine-tuned correction even 
>>> in a CRTC.  The driver's .enable method can take decision on this 
>>> identifier based on the hardware capabilities.

Yeah, but I meant the drmModeObjectSetProperty() ioctl already tales a
CRTC/Plane/Connector ID. So why duplicate that information in the
blob? And more importantly, what happens if you call
drmModeObjectSetProperty() on a plane but specify a CRTC ID in the
blob? Seems weird to me to support such setups.

> 3) Please document the payload for each of the properties you define.
> If the property is a blob, there is no reason to make the properties generic. 
> User-space requires a common syntax across all drivers, otherwise, it cannot 
> make use of generic properties and you should use driver-dependent properties 
> instead.
>>> Can you please elaborate a bit more ? I believe that a blob is a superset 
>>> of single and multi-valued properties. So we can use the byte defined for 
>>>  and specify both single value and multi value 
>>> correction using the same interface, >> method and protocol.  So any 
>>> userspace can just follow this, any can give commands to any driver.

Well, your document doesn't describe the payload at all. I just wanted
a description of what kind of information is expected. Number of
arguments, argument size, argument types, argument description.. and
so on.

> 4) We have a tuple-type for properties. So in case you only need 32bit 
> payloads for a given property, you can combine enable/disable and value in a 
> single 64bit property.
>>> But properties like CSC and Gamma correction need multiple correction 
>>> values, up to 256 32-bit values. For this we need more no of values. AM I 
>>> getting it right ?

Sure.

Thanks
David

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Andrzej Hajda]

On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
> On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
>> Separation of the interfaces exposed by the device from the device itself
>> seems to me a good thing. I would even consider it as a biggest
>> advantage of this solution :)
>>
>> The problem of re-initialization does not seems to be relevant here, it
>> is classic
>> problem of coding correctness nothing more, it can appear here and in
>> many different
>> places.
> It may be a problem of coding correctless, but it's also a maintainability
> problem too - it makes it _much_ more difficult to ensure that everything
> is correct.

But forcibly re-initializing all component devices instead of fixing bugs
in specific drivers seems to be 'absolutely absurd' as classic says.
>> Anyway it seems we have different point of view on the problem, your say
>> about devices with two stage initialization. I see it more as devices
>> registering interfaces and superdevice using it.
> Right, so please make this exynos-specific, because from what I can see it
> has no reason to pretend to be generic.  As I've already pointed out, it
> can't be used in the general case because it ties sub-components directly
> to their main driver, which is absolutely absurd.  Please keep this
> absurdness in exynos and don't spread it around.  Thanks.

As I wrote already, this framework was proposed for drivers which
are tied together anyway, and this is case of many drivers, not only exynos.
Standalone drivers were not at my sight but I have also described in
other mail
how the framework can be 'improved' to support standalone drivers also.

Regards
Andrzej

>

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Ville Syrjälä]

On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> The introduction of primary planes has apparently caused a bit of fb
> refcounting fun for people. That makes it a good time to clean up the
> arcane rules and slight differences between ->update_plane and
> ->set_config. The new rules are:
> 
> - The core holds a reference for both the new and the old fb (if their
>   non-NULL of course) while calling into the driver through either
>   ->update_plane or ->set_config.
> 
> - Drivers may not clobber plane->fb if their callback fails. If they
>   do that, they need to store a pointer to the old fb in it again.
>   When calling into the driver plane->fb still points at the current
>   (old) framebuffer.
> 
> - The core will update the plane->fb pointer on success. Drivers can
>   do that themselves too.
> 
> - The core will update fb refcounts for the plane->fb pointer,
>   presuming the drivers hold up their end of the bargain.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c | 12 +---
>  drivers/gpu/drm/drm_plane_helper.c | 15 ---
>  2 files changed, 5 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d8b7099abece..966b480ed543 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, void 
> *data,
>   }
>  
>   drm_modeset_lock_all(dev);
> + old_fb = plane->fb;
>   ret = plane->funcs->update_plane(plane, crtc, fb,
>plane_req->crtc_x, plane_req->crtc_y,
>plane_req->crtc_w, plane_req->crtc_h,
>plane_req->src_x, plane_req->src_y,
>plane_req->src_w, plane_req->src_h);
>   if (!ret) {
> - old_fb = plane->fb;
>   plane->crtc = crtc;
>   plane->fb = fb;
> - fb = NULL;
>   }
>   drm_modeset_unlock_all(dev);
>  
>  out:
> - if (fb)
> - drm_framebuffer_unreference(fb);
> + if (plane->fb)
> + drm_framebuffer_reference(old_fb);
  ^^

That doesn't look right.

Also you're now dereferencing plane->fb after you drop the locks.

Also i915 fb destruction seems buggy as we do
intel_fb->obj->framebuffer_references-- w/o holding struct_mutex.

>   if (old_fb)
>   drm_framebuffer_unreference(old_fb);
> + drm_framebuffer_unreference(fb);
>  
>   return ret;
>  }
> @@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> *set)
>   ret = crtc->funcs->set_config(set);
>   if (ret == 0) {
>   crtc->primary->crtc = crtc;
> -
> - /* crtc->fb must be updated by ->set_config, enforces this. */
> - WARN_ON(fb != crtc->primary->fb);
> + crtc->primary->fb = fb;
>   }
>  
>   list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index e768d35ff22e..8db129c44fea 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   set.connectors = connector_list;
>   set.num_connectors = num_connectors;
>  
> - /*
> -  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> -  * code that called us expects to handle the framebuffer update and
> -  * reference counting; save and restore the current fb before
> -  * calling it.
> -  *
> -  * N.B., we call set_config() directly here rather than using
> -  * drm_mode_set_config_internal.  We're reprogramming the same
> -  * connectors that were already in use, so we shouldn't need the extra
> -  * cross-CRTC fb refcounting to accomodate stealing connectors.
> -  * drm_mode_setplane() already handles the basic refcounting for the
> -  * framebuffers involved in this operation.
> -  */
> - tmpfb = plane->fb;
>   ret = crtc->funcs->set_config();
> - plane->fb = tmpfb;
>  
>   kfree(connector_list);
>   return ret;
> -- 
> 1.9.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

[Russell King - ARM Linux]

On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
> On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
> > On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
> >> Separation of the interfaces exposed by the device from the device itself
> >> seems to me a good thing. I would even consider it as a biggest
> >> advantage of this solution :)
> >>
> >> The problem of re-initialization does not seems to be relevant here, it
> >> is classic
> >> problem of coding correctness nothing more, it can appear here and in
> >> many different
> >> places.
> > It may be a problem of coding correctless, but it's also a maintainability
> > problem too - it makes it _much_ more difficult to ensure that everything
> > is correct.
> 
> But forcibly re-initializing all component devices instead of fixing bugs
> in specific drivers seems to be 'absolutely absurd' as classic says.

They're *unnecessary* bugs that wouldn't even exist if it weren't for
the forced-splitup of the initialisation into two separate parts that
your approach mandates.

Yes, I know that you're desperate to play that down, but you can't get
away from this fact: your approach _forces_ a split up of the
initialisation into dependent two stages and that fact _alone_ adds
additional complexity, and along with that additional complexity comes
more opportunity for bugs.  Also with that additional complexity comes
the need to perform more tests to find those bugs, and given that most
people just say "okay, it boots and seems to work, that's good enough
for me" there is a high possibility that these kinds of bugs will take
a long time to find.

> As I wrote already, this framework was proposed for drivers which
> are tied together anyway, and this is case of many drivers, not
> only exynos.

Please name them.

> Standalone drivers were not at my sight but I have also described in
> other mail how the framework can be 'improved' to support standalone
> drivers also.

At the moment, I don't see a justification for your "simplified"
and restrictive solution, which if used will lock drivers into that
simplisitic method, and which can't ever be extended without lots of
ifdeffery to having other components (such as TDA998x) attached.

My objections are entirely based on where imx-drm and armada DRM are
going, neither of which could ever use your implementation.

Before you say that it isn't meant to deal with stuff like the TDA998x,
take a moment to think about this - the Dove video subsystem was
designed to support OLPC.  It was primerly designed to drive a LCD
screen plus an on-board VGA DAC.  Everything for that is on-SoC.  With
that, the hardware is well known, and your solution could be used.

However, then SolidRun came along and dropped a TDA998x on the LCD output
pins.  Suddenly, things aren't that simple, and your solution falls
apart, because it can't cope with a generic component that has no knowledge
of the rest of its "master".

This kind of scenario can happen /any/ time, and any time it does happen,
your simple solution falls apart.

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

[PATCH 10/18] drm/irq: track the irq installed in drm_irq_install in dev->irq

[Thierry Reding]

On Tue, Apr 22, 2014 at 11:46:45AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 12:02:07AM +0200, Laurent Pinchart wrote:
> > And another comment...
> > 
> > On Friday 11 April 2014 23:36:07 Daniel Vetter wrote:
> > > To get rid of the dev->bus->get_irq callback we need to pass in the
> > > desired irq explicitly into drm_irq_install. To avoid having to do the
> > > same for drm_irq_unistall just track it internally. That leaves
> > > drivers with less room to botch things up.
> > > 
> > > v2: Add the hunk lost in an earlier patch to this one (Thierry).
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_irq.c | 18 +++---
> > >  include/drm/drmP.h|  2 ++
> > >  2 files changed, 13 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index 330e85b19115..1c3b6229363d 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -249,14 +249,16 @@ static inline int drm_dev_to_irq(struct drm_device
> > > *dev) */
> > >  int drm_irq_install(struct drm_device *dev)
> > >  {
> > > - int ret;
> > > + int ret, irq;
> > >   unsigned long sh_flags = 0;
> > >   char *irqname;
> > > 
> > > + irq = drm_dev_to_irq(dev);
> > > +
> > >   if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
> > >   return -EINVAL;
> > > 
> > > - if (drm_dev_to_irq(dev) == 0)
> > > + if (irq == 0)
> > 
> > Isn't 0 a valid IRQ number ? Shouldn't you check for irq < 0 instead ? At 
> > least platform_get_irq() returns a negative error value on failure.
> 
> tbh I'm not really clear on how this works. If we want to change this then
> I think that should be a separate patch. Also it might be better to
> extract this check into drm_control, which is the only function that
> really needs it since it is called by userspace.
> 
> For all other places it is a simple driver bug and I'm not sure how much
> we should care - request_irq should catch any abuse already.
> 
> In any case this should be a separate patch.

I agree. This patch mostly mechanically replaces things and this bug did
already exist previously. So let's fix it separately (if at all).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/45302ad3/attachment.sig>

[PATCH v2 04/10] drm/nouveau/fb: add GK20A support

[Thierry Reding]

On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote:
[...]
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c 
> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
[...]
> + pages = dma_alloc_from_contiguous(dev, ncmin, order);
> + if (!pages) {
> + gk20a_ram_put(pfb, );
> + return -ENOMEM;
> + }
> +
> + dma_addr = pfn_to_dma(nv_device_base(nv_device(pfb)),
> +   page_to_pfn(pages));

This breaks compilation on x86 because neither pfn_to_dma() nor
dma_to_pfn() are available. Is there some other way this can be
allocated so that these functions don't need to be called?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bc54b184/attachment.sig>

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

[Thierry Reding]

On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> > > Current drivers only enable hotplug processing after the call to
> > > drm_fb_helper_initial_config which leaves a tiny but important race.
> > > 
> > > This race is especially noticable on embedded platforms where the
> > > driver itself enables the voltage for the hdmi output, since only then
> > > will monitors (after a bit of delay, as usual) respond by asserting
> > > the hpd pin.
> > > 
> > > Most of the infrastructure is already there with the split-out
> > > drm_fb_helper_init. And drm_fb_helper_initial_config already has all
> > > the required locking to handle concurrent hpd events since
> > > 
> > > commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
> > > Author: Daniel Vetter 
> > > Date:   Thu Mar 20 14:26:35 2014 +0100
> > > 
> > > drm/fb-helper: improve drm_fb_helper_initial_config locking
> > > 
> > > The only missing bit is making drm_fb_helper_hotplug_event save
> > > against concurrent calls of drm_fb_helper_initial_config. The only
> > > unprotected bit is the check for fb_helper->fb.
> > > 
> > > With that drivers can first initialize the fb helper, then enabel
> > > hotplug processing and then set up the initial config all in a
> > > completely race-free manner. Update kerneldoc and convert i915 as a
> > > proof of concept.
> > > 
> > > Feature requested by Thierry since his tegra driver atm reliably boots
> > > slowly enough to misses the hotplug event for an external hdmi screen,
> > > but also reliably boots to quickly for the hpd pin to be asserted when
> > > the fb helper calls into the hdmi ->detect function.
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_fb_helper.c | 11 +--
> > >  drivers/gpu/drm/i915/i915_dma.c |  3 ---
> > >  drivers/gpu/drm/i915/i915_drv.c |  2 --
> > >  drivers/gpu/drm/i915/i915_drv.h |  1 -
> > >  drivers/gpu/drm/i915/i915_irq.c |  4 
> > >  5 files changed, 5 insertions(+), 16 deletions(-)
> > 
> > The FB helper parts:
> > 
> > Tested-by: Thierry Reding 
> > 
> > But I have one comment below...
> > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > [...]
> > > - * Note that the driver must ensure that this is only called _after_ the 
> > > fb has
> > > - * been fully set up, i.e. after the call to 
> > > drm_fb_helper_initial_config.
> > > + * Note that drivers may call this even before calling
> > > + * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This 
> > > allows
> > 
> > I don't think the requirement is that strict. To elaborate: on Tegra we
> > cannot call drm_fb_helper_init() because the number of CRTCs and
> > connectors isn't known this early. We determine that dynamically after
> > all sub-devices have been initialized. So instead of calling
> > drm_fb_helper_init() before drm_kms_helper_poll_init(), I did something
> > more minimal (see attached patch). It's kind of difficult to tell
> > because of the context, but tegra_drm_fb_prepare() sets up the mode
> > config and functions and allocate memory for the FB helper and sets the
> > FB helper functions.
> > 
> > This may not be enough for all drivers, but on Tegra the implementation
> > of .output_poll_changed() simply calls drm_fb_helper_hotplug_event(),
> > which will work fine with just that rudimentary initialization.
> 
> Hm yeah I think this should be sufficient, too. It would be good to
> extract this minimal initialization into a new drm_fb_helper_prepare
> function and update the kerneldoc a bit more. Maybe as a patch on top of
> mine?

It would be essentially this:

void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
   const struct drm_fb_helper_funcs *funcs)
{
    helper->funcs = funcs;
helper->dev = dev;
}

So I wonder if that's still what we want or whether drivers should
simply be doing that manually if they need to. Having a function for it
gives us a place to document things, though, and perhaps at some point
we'll have to extend this, so it may be a good idea after all, even if
it's just the two lines currently.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/b398c072/attachment.sig>

Design review request: DRM color manager

[Sharma, Shashank]

Thanks again David, 
Comments inline. 

Regards
Shashank
-Original Message-
From: David Herrmann [mailto:dh.herrm...@gmail.com] 
Sent: Tuesday, April 22, 2014 5:10 PM
To: Sharma, Shashank
Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
Ville Syrj?l?; Thierry Reding; Alex Deucher; Sean Paul; robdclark at gmail.com; 
Mukherjee, Indranil; Jindal, Sonika; Korjani, Vikas; Shankar, Uma; Cn, 
Ramakrishnan
Subject: Re: Design review request: DRM color manager

Hi

On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank  wrote:
> 1) Why do you register only a single property? Why not register a separate 
> property for each color-correction that is available? This way you can drop 
> the property-id and use the high-level DRM-prop IDs/names.
>>> That?s the whole idea of color manager. If we keep on creating properties 
>>> for each color correction, there would be a big list and a lot of 
>>> properties will be exposed. Instead one common blob which can represent all 
>>> the properties, correction values and identifiers. It would be easy to club 
>>> with atomic modeset kind-of designs also I believe.

Where is the difference? With one _well-defined_ property for each type we 
simply move the identification one level up. With your approach you just move 
the type-id one level down into the blob.

Or in other words: Where is the difference between calling
SetProperty() n-times, or calling it once but with a parameter describing 
n-properties? With atomic-modesetting we can set as many properties as we want 
and make the kernel apply them atomically.

>>> Actually we also do not want to populate the property space also, as if 
>>> there are 10 color correction methods possible for a hardware, we might end 
>>> up listing 10 properties.  And there won't be common properties across all 
>>> the hardwares also. For example, Hardware A can have properties X Y Z but 
>>> Hardware B can have W X and Z. This will make the property space 
>>> inconsistent. But if we provide one common interface which will cover for 
>>> all the properties, for all the hardwares in a single blob. The driver will 
>>> dynamically register its property, in its own preferred name. A get_prop() 
>>> will always list down all the supported color property by this hardware and 
>>> driver.   

> 2) What is the CRTC-ID for? DRM properties can be set on a specific CRTC 
> and/or plane. Isn't that enough information for the driver?
>>> This is to make it HW agonist. Actually that's CRTC ID / Plane ID / PIPE ID 
>>> / all together an identifier. For example if I want to set gamma correction 
>>> for sprite planes only, not on primary plane or pipe level, on VLV, its 
>>> possible. This gives me flexibility to mention fine-tuned correction even 
>>> in a CRTC.  The driver's .enable method can take decision on this 
>>> identifier based on the hardware capabilities.

Yeah, but I meant the drmModeObjectSetProperty() ioctl already tales a 
CRTC/Plane/Connector ID. So why duplicate that information in the blob? And 
more importantly, what happens if you call
drmModeObjectSetProperty() on a plane but specify a CRTC ID in the blob? Seems 
weird to me to support such setups.

>>> The design is to register color-manager as a CRTC property, to make it 
>>> consistent, and then give the fine tuning via this identifier byte. 
Else we have to keep track of this in userspace, that which property is valid 
for which extent. For example, Hue and saturation correction, on VLV, can be 
applied on Sprite planes only(not on primary plane). So we have to send a plane 
as an object here. 
Rather in color manager case, we will always send the CRTC as an object to 
IOCTL, but will specify SPRITE_PLANE as identifier. Does this sound less weird 
now  :) ? 

> 3) Please document the payload for each of the properties you define.
> If the property is a blob, there is no reason to make the properties generic. 
> User-space requires a common syntax across all drivers, otherwise, it cannot 
> make use of generic properties and you should use driver-dependent properties 
> instead.
>>> Can you please elaborate a bit more ? I believe that a blob is a superset 
>>> of single and multi-valued properties. So we can use the byte defined for 
>>>  and specify both single value and multi value 
>>> correction using the same interface, >> method and protocol.  So any 
>>> userspace can just follow this, any can give commands to any driver.

Well, your document doesn't describe the payload at all. I just wanted a 
description of what kind of information is expected. Number of arguments, 
argument size, argument types, argument description.. and so on.
 Sure, I will further document it very clearly about arguments and 
 descriptions. Actually we have discussed the protocol in the color EDID 
 section, which tells us about the 4 byte protocol and expectation, but 
 that?s elementary. 

> 4) We have a tuple-type for properties. So in case you only 

[Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()

[Ben Skeggs]

On Tue, Apr 22, 2014 at 4:07 AM, Ilia Mirkin  wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot  
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the 3D Controller ones, and I guess even some that come up as VGA
> controller in PCI but don't have any outputs in their VBIOS)? i.e.
> what's wrong with just doing the same thing that GK1xx does? Note that
> there are sw methods that don't deal with display as well.
The mp_control() methods are the only ones I see, and, in my opinion,
they should really have been implemented using reserved methods on a
graphics class, and *not* in a purely software object..  If we need
them on GK20A too, we should reimplement them in gr, and bump the
minor version number so userspace knows.

Ben.

>
>   -ilia
>
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index ddd83756b9a2..5b46148ffd32 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> @@ -208,6 +208,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
>> return;
>> }
>>
>> +   /* Need to figure out how to handle sw for gk20a */
>> +   if (device->chipset == 0xea)
>> +   goto skip_sw_init;
>> +
>> ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
>>  nouveau_abi16_swclass(drm), NULL, 0, 
>> );
>> if (ret == 0) {
>> @@ -234,6 +238,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
>> return;
>> }
>>
>> +skip_sw_init:
>> if (device->card_type < NV_C0) {
>> ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>> >notify);
>> --
>> 1.9.2
>>
>> ___
>> Nouveau mailing list
>> Nouveau at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

[Deucher, Alexander]

> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Tuesday, April 22, 2014 5:17 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus
> 
> Am 22.04.2014 08:02, schrieb Alex Deucher:
> > The hpd (hot plug detect) pin assignment got lost
> > in the conversion to to the common i2c over aux
> > code.  Without this information, aux transactions
> > do not work properly.  Fixes DP failures.
> >
> > Signed-off-by: Alex Deucher 
> 
> Added to my 3.15 queue.
> 
> Does this also fix the issue Ed Tomlinson  reported about?

It should fix the issue Ed and Ken reported and bug:
https://bugs.freedesktop.org/show_bug.cgi?id=77751

Alex

> 
> Christian.
> 
> > ---
> >   drivers/gpu/drm/radeon/atombios_dp.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> > index 1593652..bc0119f 100644
> > --- a/drivers/gpu/drm/radeon/atombios_dp.c
> > +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> > @@ -209,6 +209,7 @@ void radeon_dp_aux_init(struct radeon_connector
> *radeon_connector)
> >   {
> > int ret;
> >
> > +   radeon_connector->ddc_bus->rec.hpd = radeon_connector-
> >hpd.hpd;
> > radeon_connector->ddc_bus->aux.dev = radeon_connector-
> >base.kdev;
> > radeon_connector->ddc_bus->aux.transfer =
> radeon_dp_aux_transfer;
> > ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus-
> >aux);

[PATCH 10/18] drm/irq: track the irq installed in drm_irq_install in dev->irq

[Daniel Vetter]

On Thu, Apr 17, 2014 at 12:02:07AM +0200, Laurent Pinchart wrote:
> And another comment...
> 
> On Friday 11 April 2014 23:36:07 Daniel Vetter wrote:
> > To get rid of the dev->bus->get_irq callback we need to pass in the
> > desired irq explicitly into drm_irq_install. To avoid having to do the
> > same for drm_irq_unistall just track it internally. That leaves
> > drivers with less room to botch things up.
> > 
> > v2: Add the hunk lost in an earlier patch to this one (Thierry).
> > 
> > Cc: Thierry Reding 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 18 +++---
> >  include/drm/drmP.h|  2 ++
> >  2 files changed, 13 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 330e85b19115..1c3b6229363d 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -249,14 +249,16 @@ static inline int drm_dev_to_irq(struct drm_device
> > *dev) */
> >  int drm_irq_install(struct drm_device *dev)
> >  {
> > -   int ret;
> > +   int ret, irq;
> > unsigned long sh_flags = 0;
> > char *irqname;
> > 
> > +   irq = drm_dev_to_irq(dev);
> > +
> > if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
> > return -EINVAL;
> > 
> > -   if (drm_dev_to_irq(dev) == 0)
> > +   if (irq == 0)
> 
> Isn't 0 a valid IRQ number ? Shouldn't you check for irq < 0 instead ? At 
> least platform_get_irq() returns a negative error value on failure.

tbh I'm not really clear on how this works. If we want to change this then
I think that should be a separate patch. Also it might be better to
extract this check into drm_control, which is the only function that
really needs it since it is called by userspace.

For all other places it is a simple driver bug and I'm not sure how much
we should care - request_irq should catch any abuse already.

In any case this should be a separate patch.
-Daniel

> 
> > return -EINVAL;
> > 
> > /* Driver must have been initialized */
> > @@ -267,7 +269,7 @@ int drm_irq_install(struct drm_device *dev)
> > return -EBUSY;
> > dev->irq_enabled = true;
> > 
> > -   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
> > +   DRM_DEBUG("irq=%d\n", dev->irq);
> > 
> > /* Before installing handler */
> > if (dev->driver->irq_preinstall)
> > @@ -282,7 +284,7 @@ int drm_irq_install(struct drm_device *dev)
> > else
> > irqname = dev->driver->name;
> > 
> > -   ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
> > +   ret = request_irq(dev->irq, dev->driver->irq_handler,
> >   sh_flags, irqname, dev);
> > 
> > if (ret < 0) {
> > @@ -301,7 +303,9 @@ int drm_irq_install(struct drm_device *dev)
> > dev->irq_enabled = false;
> > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > vga_client_register(dev->pdev, NULL, NULL, NULL);
> > -   free_irq(drm_dev_to_irq(dev), dev);
> > +   free_irq(dev->irq, dev);
> > +   } else {
> > +   dev->irq = irq;
> > }
> > 
> > return ret;
> > @@ -344,7 +348,7 @@ int drm_irq_uninstall(struct drm_device *dev)
> > if (!irq_enabled)
> > return -EINVAL;
> > 
> > -   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
> > +   DRM_DEBUG("irq=%d\n", dev->irq);
> > 
> > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > vga_client_register(dev->pdev, NULL, NULL, NULL);
> > @@ -352,7 +356,7 @@ int drm_irq_uninstall(struct drm_device *dev)
> > if (dev->driver->irq_uninstall)
> > dev->driver->irq_uninstall(dev);
> > 
> > -   free_irq(drm_dev_to_irq(dev), dev);
> > +   free_irq(dev->irq, dev);
> > 
> > return 0;
> >  }
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 8b23a34a103e..6f512cd97cd5 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1107,6 +1107,8 @@ struct drm_device {
> > /** \name Context support */
> > /*@{ */
> > bool irq_enabled;   /**< True if irq handler is enabled */
> > +   int irq;
> > +
> > __volatile__ long context_flag; /**< Context swapping flag */
> > int last_context;   /**< Last current context */
> > /*@} */
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

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

[git pull] drm fixes

[Ed Tomlinson]

On Monday 21 April 2014 17:26:15 Ed Tomlinson wrote:
> On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote:
> > On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote:
> > > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote:
> > > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote:
> > > > > 
> > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd 
> > > > > like, but I included a patch that just moves code from one file to 
> > > > > another 
> > > > > and I'd like to avoid merge conflicts with that later, so it makes it 
> > > > > seem 
> > > > > worse than it is,
> > > > 
> > > > > Christian K?nig (2):
> > > > >   drm/radeon: apply more strict limits for PLL params v2
> > > > >   drm/radeon: improve PLL params if we don't match exactly v2
> > > > 
> > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e
> > > > Author: Christian K?nig 
> > > > Date:   Wed Apr 16 11:54:21 2014 +0200
> > > > 
> > > > drm/radeon: improve PLL params if we don't match exactly v2
> > > > 
> > > > The commit above causes my monitor to just stay blank after boot.
> > > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780.
> 
> Reverting 
> 
> commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef
> Author: Alex Deucher 
> Date:   Mon Apr 7 10:33:46 2014 -0400
> 
> drm/radeon/dp: switch to the common i2c over aux code
> 
> Provides a nice cleanup in radeon.
> 
> Signed-off-by: Alex Deucher 
> Signed-off-by: Christian K?nig 
> 
> Restores the display - no more i2c errors

This fixed here without reverts by the patch from Alex Deucher attached in the 
thread: 
"Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display"

Thanks
Ed

> > > I have the same symptoms with rc2 and a r7 260x using display port.  I 
> > > cannot 
> > > seem to get a dmesg of a failure (I _really_ need to figure out how to add
> > > a serial console).  I'll try reverting once I figure out how to get 
> > > pacman to
> > > do a revert when building from git.
> > 
> > Neither reverting the above patch or add the fix from 
> > "https://bugs.freedesktop.org/show_bug.cgi?id=77673;
> > helps here.  I managed to get dmesg(s) from 14.1 and 15-rc2.  The major 
> > difference has to do with i2c.  On the
> > 14.1 kernel I see:

Design review request: DRM color manager

[David Herrmann]

Hi

On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank
 wrote:
> Gentle reminder

Usual approach is to send any proposals as inline plain-text. It's
really hard to comment on attachments, especially if it's an MS-office
format. Anyhow, some comments on the proposal:

1) Why do you register only a single property? Why not register a
separate property for each color-correction that is available? This
way you can drop the property-id and use the high-level DRM-prop
IDs/names.

2) What is the CRTC-ID for? DRM properties can be set on a specific
CRTC and/or plane. Isn't that enough information for the driver?

3) Please document the payload for each of the properties you define.
If the property is a blob, there is no reason to make the properties
generic. User-space requires a common syntax across all drivers,
otherwise, it cannot make use of generic properties and you should use
driver-dependent properties instead.

4) We have a tuple-type for properties. So in case you only need 32bit
payloads for a given property, you can combine enable/disable and
value in a single 64bit property.

5) Please use common prefixes to group related functions: Use
drm_color_manager_register() instead of drm_register_color_manager().
Similarly, use drm_color_manager_set_property() instead of
drm_set_color_manager_property()..

Thanks
David

[Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()

[Alexandre Courbot]

On 04/22/2014 03:07 AM, Ilia Mirkin wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot  
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the 3D Controller ones, and I guess even some that come up as VGA
> controller in PCI but don't have any outputs in their VBIOS)? i.e.
> what's wrong with just doing the same thing that GK1xx does? Note that
> there are sw methods that don't deal with display as well.

Well, as it turns out... I have tried reverting this patch and enabling 
nvc0_software_oclass for GK20A and things worked like a charm. 0_o

This is definitely different from when I first drafted this patch 
series, where a software class could not be used on GK20A due to hard 
dependencies on display. But it seems like today's code can accommodate 
much better with that situation.

That's great - this will allow us to get rid of this ungraceful patch. 
Thanks for making me check it again.

Probably a v3 will be necessary to enable the software class in patch 10 
(and fix the byte/word typo in patch 7). I will just wait a bit to see 
if this v2 gets more comments before sending it.

>
>-ilia
>
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>   drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index ddd83756b9a2..5b46148ffd32 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> @@ -208,6 +208,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
>>  return;
>>  }
>>
>> +   /* Need to figure out how to handle sw for gk20a */
>> +   if (device->chipset == 0xea)
>> +   goto skip_sw_init;
>> +
>>  ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
>>   nouveau_abi16_swclass(drm), NULL, 0, 
>> );
>>  if (ret == 0) {
>> @@ -234,6 +238,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
>>  return;
>>  }
>>
>> +skip_sw_init:
>>  if (device->card_type < NV_C0) {
>>  ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>>  >notify);
>> --
>> 1.9.2
>>
>> ___
>> Nouveau mailing list
>> Nouveau at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH V2 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

[Thierry Reding]

On Tue, Apr 22, 2014 at 04:09:18AM +0530, Ajay Kumar wrote:
> This patch adds ps8622 lvds bridge discovery code to the dp driver.
> 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
>   Pushing V1 for this as V2 because this patch holds good in this series.
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4853f31..0006412 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "exynos_drm_drv.h"
>  #include "exynos_dp_core.h"
> @@ -999,7 +1000,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
> drm_device *dev,
>   panel);
>   if (!ret)
>   return 1;
> + } else if (find_bridge("parade,ps8625", )) {

So this is where the inspiration for the of_find_compatible_node() in
the earlier patch came from.

> + ret = ps8622_init(dev, encoder, bridge.client, bridge.node,
> + panel);

Long-term I don't think this is going to scale very well. In my opinion
it would be much more useful to have the bridge driver initialize what
it can and then have the DRM driver call a generic initialization
function to bind it to the DRM device or encoder. Otherwise we have to
keep knowledge about the type of bridge in each driver that uses it,
whereas the goal (I think) would be to create a proper abstraction so
that the DRM driver doesn't have to know that kind of detail.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/cd96a7aa/attachment.sig>

[PATCH] modetest: add cursor support

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
Note: I move the position of the getchar() at the end, so we don't
stop the cursor test immediately if not testing w/ vblank sync
flipping.  The previous position of the getchar() seemed to make
no sense, but please let me know if there was a legit reason for
the way it was before.

 tests/modetest/Makefile.am |   4 +-
 tests/modetest/cursor.c| 207 +
 tests/modetest/cursor.h|  33 
 tests/modetest/modetest.c  |  71 +++-
 4 files changed, 310 insertions(+), 5 deletions(-)
 create mode 100644 tests/modetest/cursor.c
 create mode 100644 tests/modetest/cursor.h

diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 6e7ff14..fd6ebb2 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -14,7 +14,9 @@ noinst_PROGRAMS = \
 endif

 modetest_SOURCES = \
-   buffers.c modetest.c buffers.h
+   buffers.c buffers.h \
+   cursor.c cursor.h \
+   modetest.c

 modetest_LDADD = \
$(top_builddir)/libdrm.la \
diff --git a/tests/modetest/cursor.c b/tests/modetest/cursor.c
new file mode 100644
index 000..7077f20
--- /dev/null
+++ b/tests/modetest/cursor.c
@@ -0,0 +1,207 @@
+/*
+ * DRM based mode setting test program
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xf86drm.h"
+#include "xf86drmMode.h"
+
+#include "buffers.h"
+#include "cursor.h"
+
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+struct cursor {
+   int fd;
+   uint32_t bo_handle;
+   uint32_t crtc_id;
+   uint32_t crtc_w, crtc_h;
+   uint32_t w, h;
+
+   /* current state */
+   uint32_t enabled, x, y;
+   int32_t dx, dy;
+};
+
+#define MAX_CURSORS 8
+static struct cursor cursors[MAX_CURSORS];
+static int ncursors;
+
+/*
+ * Timer driven program loops through these steps to move/enable/disable
+ * the cursor
+ */
+
+struct cursor_step {
+   void (*run)(struct cursor *cursor, struct cursor_step *step);
+   uint32_t msec;
+   uint32_t repeat;
+   int arg;
+};
+
+static uint32_t indx, count;
+
+static void set_cursor(struct cursor *cursor, struct cursor_step *step)
+{
+   int enabled = (step->arg ^ count) & 0x1;
+   uint32_t handle = 0;
+
+   if (enabled)
+   handle = cursor->bo_handle;
+
+   cursor->enabled = enabled;
+
+   drmModeSetCursor(cursor->fd, cursor->crtc_id, handle, cursor->w, 
cursor->h);
+}
+
+static void move_cursor(struct cursor *cursor, struct cursor_step *step)
+{
+   int x = cursor->x;
+   int y = cursor->y;
+
+   if (!cursor->enabled)
+   drmModeSetCursor(cursor->fd, cursor->crtc_id,
+   cursor->bo_handle, cursor->w, cursor->h);
+
+   /* calculate new cursor position: */
+   x += cursor->dx * step->arg;
+   y += cursor->dy * step->arg;
+
+   if (x < 0) {
+   x = 0;
+   cursor->dx = 1;
+   } else if (x > (int)cursor->crtc_w) {
+   x = cursor->crtc_w - 1;
+   cursor->dx = -1;
+   }
+
+   if (y < 0) {
+   y = 0;
+   cursor->dy = 1;
+   } else if (y > (int)cursor->crtc_h) {
+   y = cursor->crtc_h - 1;
+   cursor->dy = -1;
+   }
+
+   cursor->x = x;
+   cursor->y = y;
+
+   drmModeMoveCursor(cursor->fd, cursor->crtc_id, x, y);
+}
+
+static struct cursor_step steps[] = {
+   {  set_cursor, 10,   0,  1 },  /* enable */
+   { move_cursor,  1, 100,  1 },
+   { move_cursor,  1,  10, 10 },
+   {  set_cursor,  1, 100,  0 },  /* disable/enable loop */
+   { move_cursor,  1,  10, 10 },
+  

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

[Christian König]

Am 22.04.2014 08:02, schrieb Alex Deucher:
> The hpd (hot plug detect) pin assignment got lost
> in the conversion to to the common i2c over aux
> code.  Without this information, aux transactions
> do not work properly.  Fixes DP failures.
>
> Signed-off-by: Alex Deucher 

Added to my 3.15 queue.

Does this also fix the issue Ed Tomlinson  reported about?

Christian.

> ---
>   drivers/gpu/drm/radeon/atombios_dp.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 1593652..bc0119f 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -209,6 +209,7 @@ void radeon_dp_aux_init(struct radeon_connector 
> *radeon_connector)
>   {
>   int ret;
>   
> + radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
>   radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
>   radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
>   ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Thierry Reding]

On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index e768d35ff22e..8db129c44fea 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   set.connectors = connector_list;
>   set.num_connectors = num_connectors;
>  
> - /*
> -  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> -  * code that called us expects to handle the framebuffer update and
> -  * reference counting; save and restore the current fb before
> -  * calling it.
> -  *
> -  * N.B., we call set_config() directly here rather than using
> -  * drm_mode_set_config_internal.  We're reprogramming the same
> -  * connectors that were already in use, so we shouldn't need the extra
> -  * cross-CRTC fb refcounting to accomodate stealing connectors.
> -  * drm_mode_setplane() already handles the basic refcounting for the
> -  * framebuffers involved in this operation.
> -  */
> - tmpfb = plane->fb;
>   ret = crtc->funcs->set_config();
> - plane->fb = tmpfb;

This makes tmpfb unused. Other than that this looks sane to me and it
doesn't make things worse from what I can tell:

Tested-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bbdd43b3/attachment.sig>

[PATCH 0/6] File Sealing & memfd_create()

[Florian Weimer]

On 04/09/2014 11:31 PM, David Herrmann wrote:

> On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer  wrote:
>> How do you keep these promises on network and FUSE file systems?
>
> I don't. This is shmem only.

Ah.  What do you recommend for recipient to recognize such descriptors? 
  Would they just try to seal them and reject them if this fails?

-- 
Florian Weimer / Red Hat Product Security Team

[PATCH v2 07/10] drm/nouveau/graph: pad firmware code at load time

[Alexandre Courbot]

On 04/22/2014 08:48 AM, Ben Skeggs wrote:
> On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin  wrote:
>> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot  
>> wrote:
>>> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will
>>
>> bytes or u32's? From the code, I'm guessing the latter. (Similar
>> concern about comment in the code.)
>>
>>> fail to run from non-prepadded firmware files.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> Reviewed-by: Thierry Reding 
>>> ---
>>>   drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
>>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> index e5b75f189988..013475c62986 100644
>>> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> @@ -894,6 +894,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 
>>> fuc_base,
>>>  nv_wr32(priv, fuc_base + 0x0188, i >> 6);
>>>  nv_wr32(priv, fuc_base + 0x0184, code->data[i]);
>>>  }
>>> +
>>> +   /* code must be padded to 0x40 bytes */
>>> +   for (; i & 0x3f; i++)
>>> +   nv_wr32(priv, fuc_base + 0x0184, 0);
> It's 256 bytes indeed.

Fixed, thanks!

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

[Daniel Vetter]

The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:

- The core holds a reference for both the new and the old fb (if their
  non-NULL of course) while calling into the driver through either
  ->update_plane or ->set_config.

- Drivers may not clobber plane->fb if their callback fails. If they
  do that, they need to store a pointer to the old fb in it again.
  When calling into the driver plane->fb still points at the current
  (old) framebuffer.

- The core will update the plane->fb pointer on success. Drivers can
  do that themselves too.

- The core will update fb refcounts for the plane->fb pointer,
  presuming the drivers hold up their end of the bargain.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 12 +---
 drivers/gpu/drm/drm_plane_helper.c | 15 ---
 2 files changed, 5 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d8b7099abece..966b480ed543 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
}

drm_modeset_lock_all(dev);
+   old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
 plane_req->crtc_x, plane_req->crtc_y,
 plane_req->crtc_w, plane_req->crtc_h,
 plane_req->src_x, plane_req->src_y,
 plane_req->src_w, plane_req->src_h);
if (!ret) {
-   old_fb = plane->fb;
plane->crtc = crtc;
plane->fb = fb;
-   fb = NULL;
}
drm_modeset_unlock_all(dev);

 out:
-   if (fb)
-   drm_framebuffer_unreference(fb);
+   if (plane->fb)
+   drm_framebuffer_reference(old_fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
+   drm_framebuffer_unreference(fb);

return ret;
 }
@@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
ret = crtc->funcs->set_config(set);
if (ret == 0) {
crtc->primary->crtc = crtc;
-
-   /* crtc->fb must be updated by ->set_config, enforces this. */
-   WARN_ON(fb != crtc->primary->fb);
+   crtc->primary->fb = fb;
}

list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index e768d35ff22e..8db129c44fea 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -175,22 +175,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
set.connectors = connector_list;
set.num_connectors = num_connectors;

-   /*
-* set_config() adjusts crtc->primary->fb; however the DRM setplane
-* code that called us expects to handle the framebuffer update and
-* reference counting; save and restore the current fb before
-* calling it.
-*
-* N.B., we call set_config() directly here rather than using
-* drm_mode_set_config_internal.  We're reprogramming the same
-* connectors that were already in use, so we shouldn't need the extra
-* cross-CRTC fb refcounting to accomodate stealing connectors.
-* drm_mode_setplane() already handles the basic refcounting for the
-* framebuffers involved in this operation.
-*/
-   tmpfb = plane->fb;
ret = crtc->funcs->set_config();
-   plane->fb = tmpfb;

kfree(connector_list);
return ret;
-- 
1.9.2

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

[Thierry Reding]

On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> > > Current drivers only enable hotplug processing after the call to
> > > drm_fb_helper_initial_config which leaves a tiny but important race.
> > > 
> > > This race is especially noticable on embedded platforms where the
> > > driver itself enables the voltage for the hdmi output, since only then
> > > will monitors (after a bit of delay, as usual) respond by asserting
> > > the hpd pin.
> > > 
> > > Most of the infrastructure is already there with the split-out
> > > drm_fb_helper_init. And drm_fb_helper_initial_config already has all
> > > the required locking to handle concurrent hpd events since
> > > 
> > > commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f
> > > Author: Daniel Vetter 
> > > Date:   Thu Mar 20 14:26:35 2014 +0100
> > > 
> > > drm/fb-helper: improve drm_fb_helper_initial_config locking
> > > 
> > > The only missing bit is making drm_fb_helper_hotplug_event save
> > > against concurrent calls of drm_fb_helper_initial_config. The only
> > > unprotected bit is the check for fb_helper->fb.
> > > 
> > > With that drivers can first initialize the fb helper, then enabel
> > > hotplug processing and then set up the initial config all in a
> > > completely race-free manner. Update kerneldoc and convert i915 as a
> > > proof of concept.
> > > 
> > > Feature requested by Thierry since his tegra driver atm reliably boots
> > > slowly enough to misses the hotplug event for an external hdmi screen,
> > > but also reliably boots to quickly for the hpd pin to be asserted when
> > > the fb helper calls into the hdmi ->detect function.
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_fb_helper.c | 11 +--
> > >  drivers/gpu/drm/i915/i915_dma.c |  3 ---
> > >  drivers/gpu/drm/i915/i915_drv.c |  2 --
> > >  drivers/gpu/drm/i915/i915_drv.h |  1 -
> > >  drivers/gpu/drm/i915/i915_irq.c |  4 
> > >  5 files changed, 5 insertions(+), 16 deletions(-)
> > 
> > The FB helper parts:
> > 
> > Tested-by: Thierry Reding 
> > 
> > But I have one comment below...
> > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > [...]
> > > - * Note that the driver must ensure that this is only called _after_ the 
> > > fb has
> > > - * been fully set up, i.e. after the call to 
> > > drm_fb_helper_initial_config.
> > > + * Note that drivers may call this even before calling
> > > + * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This 
> > > allows
> > 
> > I don't think the requirement is that strict. To elaborate: on Tegra we
> > cannot call drm_fb_helper_init() because the number of CRTCs and
> > connectors isn't known this early. We determine that dynamically after
> > all sub-devices have been initialized. So instead of calling
> > drm_fb_helper_init() before drm_kms_helper_poll_init(), I did something
> > more minimal (see attached patch). It's kind of difficult to tell
> > because of the context, but tegra_drm_fb_prepare() sets up the mode
> > config and functions and allocate memory for the FB helper and sets the
> > FB helper functions.
> > 
> > This may not be enough for all drivers, but on Tegra the implementation
> > of .output_poll_changed() simply calls drm_fb_helper_hotplug_event(),
> > which will work fine with just that rudimentary initialization.
> 
> Hm yeah I think this should be sufficient, too. It would be good to
> extract this minimal initialization into a new drm_fb_helper_prepare
> function and update the kerneldoc a bit more. Maybe as a patch on top of
> mine?
> 
> Then we could merge this all as an early tegra-next pull to Dave.

Sounds like a good idea. I'll go prepare a patch.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/29d75edf/attachment.sig>