[Bug 92912] Full GPU lockups in TF2 - R600

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

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

Vedran Miletić  changed:

   What|Removed |Added

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

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

[Bug 92912] Full GPU lockups in TF2 - R600

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

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

--- Comment #8 from hofmann.zachary at gmail.com ---
It's definitely fixed now, just disappointed that in this whole time the bug
never got recognized.

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

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Just tried it and the system didn't freeze. However it will freeze
after some time (few minutes while working).

Seams to be pci_read_config_dword. Where is this exactly defined?


Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
> On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
>> Hi Bjorn,
>>
>> I am using the bbswitch kernel module to switch off/on the GPU and
>> to obtain the GPU power state.
>> Obtaining the GPU state immediately after starting the graphical user
>> session freezes the system.
>>
>> This code triggers something, which is responsible for the freeze.
>>
>> ---
>> // Returns 1 if the card is disabled, 0 if enabled
>> static int is_card_disabled(void) {
>> u32 cfg_word;
>> // read first config word which contains Vendor and Device ID. If all 
>> bits
>> // are enabled, the device is assumed to be off
>> pci_read_config_dword(dis_dev, 0, &cfg_word);
>> // if one of the bits is not enabled (the card is enabled), the inverted
>> // result will be non-zero and hence logical not will make it 0 ("false")
>> return !~cfg_word;
>> }
>>
>> static int bbswitch_proc_show(struct seq_file *seqfp, void *p) {
>> // show the card state. Example output: :01:00:00 ON
>> dis_dev_get();
>> seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev),
>>  is_card_disabled() ? "OFF" : "ON");
>> dis_dev_put();
>> return 0;
>> }
>> ---
>>
>> Either dis_dev_get or pci_read_config_dword is the trigger.
> 
> What happens if you remove the call to is_card_disabled()?  Does the
> system still freeze if you only do the dis_dev_get()/dis_dev_put()?
> 
>> Link to the bbswitch module source code:
>> https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
>>
>>
>> Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
>>> [+cc linux-acpi, linux-kernel, dri-devel]
>>>
>>> Hi Roland,
>>>
>>> I have no idea how to debug this problem.  Are you seeing something
>>> that suggests it may be a PCI problem?
>>>
>>> On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
 Hi,

 hope somebody can help me fix this kernel problem which affects the 
 following machines:

 - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are 
 also affected)
 - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
 - Gigabyte P35V5 (i7-6700HQ/GTX 970M)
 - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)


 The kernel freezes if the graphical user session (Xorg & Wayland) is
 started with a switched off discrete GPU card (NVIDIA).
 If the discrete GPU is switched off after the graphical session start,
 then everything works as expected, until the graphical session is 
 restarted.

 This problem seams to be linked to specific BIOS settings. If the computer
 is started with the following command line:

 acpi_osi=! acpi_osi="Windows 2009"

 then the kernel freeze does not occur anymore. However this required a 
 special
 ACPI DSDT firmware patch for the Razer Blade 2016 laptop:

 https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt

 I strongly recommend to fix this in the kernel and I am ready to help and 
 solve
 this problem with some help.

 Here is a link to the GitHub issue with further information:

 https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-241212595

 Here are some more detailed information:

 https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt

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

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Vladimir Zapolskiy]

Hi Emil,

On 08/29/2016 07:41 PM, Emil Velikov wrote:
> Hi all,
>
> On 24 August 2016 at 06:46, Vladimir Zapolskiy
>  wrote:
>
>>  MODULE_AUTHOR("Sascha Hauer ");
>>  MODULE_AUTHOR("Andy Yan ");
>>  MODULE_AUTHOR("Yakir Yang ");
>> +MODULE_AUTHOR("Vladimir Zapolskiy ");
> Don't meant to start a flame-war or alike but to educate myself:
> Where does one draw the line about adding new author(s) of said
> module/subsystem ?

I support you, let's don't sink. Since it evokes questions I'm
ready to provide you with more background information.

> Afaict this is the most common (?) driver in DRM where the list has
> grown over time. Should we do the same with others ?

If you look into the essense of this change it adds support to
an I2C master controller, which is a part of DW HDMI controller.

Originally this particular change was done as a separate driver
in I2C subsystem about 3 years ago and delivered to the customers,
about 2 years ago I published its RFC version:

  RFC:   https://patchwork.ozlabs.org/patch/405100/
  v1 discussion: http://www.mailbrowse.com/linux-i2c/20949.html

As you may see this was a stand-alone driver, which served as
the fourth I2C master controller on iMX6Q, however I believe
it is better to merge two drivers into one. Does it sound like
a good enough reason to merge lists of authors as well?

Hope it clarifies the situation a bit.

--
With best wishes,
Vladimir

[PATCH v2] drm/nouveau/gr: mark gm107_grctx_generate_tpcid() static

[Baoyou Xie]

We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no previous 
prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
index 6d3c501..4c4b5ab 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -933,7 +933,7 @@ gm107_grctx_generate_attrib(struct gf100_grctx *info)
}
 }

-void
+static void
 gm107_grctx_generate_tpcid(struct gf100_gr *gr)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
-- 
2.7.4

[PATCH v2] drm/nouveau/pm: mark nvkm_perfsig_find() static

[Baoyou Xie]

We get 2 warnings when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:75:1: warning: no previous 
prototype for 'nvkm_perfsig_find' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:703:1: warning: no previous 
prototype for 'nvkm_perfsrc_new' [-Wmissing-prototypes]

In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
so this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
index 8616636..dde89a4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
@@ -71,7 +71,7 @@ nvkm_perfdom_find(struct nvkm_pm *pm, int di)
return NULL;
 }

-struct nvkm_perfsig *
+static struct nvkm_perfsig *
 nvkm_perfsig_find(struct nvkm_pm *pm, u8 di, u8 si, struct nvkm_perfdom **pdom)
 {
struct nvkm_perfdom *dom = *pdom;
@@ -699,7 +699,7 @@ nvkm_pm_oclass_get(struct nvkm_oclass *oclass, int index,
return 1;
 }

-int
+static int
 nvkm_perfsrc_new(struct nvkm_pm *pm, struct nvkm_perfsig *sig,
 const struct nvkm_specsrc *spec)
 {
-- 
2.7.4

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

[Andrea Arcangeli]

On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.

CC'ed Martin who filed the bz, he can reproduce too
https://bugzilla.kernel.org/show_bug.cgi?id=151731

Since you can reproduce would you have the time to test the two above
options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid
I won't be able to test it today and I'll be mostly offline for a week
starting tomorrow.

Thanks,
Andrea

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Hi Bjorn,

I am using the bbswitch kernel module to switch off/on the GPU and
to obtain the GPU power state.
Obtaining the GPU state immediately after starting the graphical user
session freezes the system.

This code triggers something, which is responsible for the freeze.

---
// Returns 1 if the card is disabled, 0 if enabled
static int is_card_disabled(void) {
u32 cfg_word;
// read first config word which contains Vendor and Device ID. If all bits
// are enabled, the device is assumed to be off
pci_read_config_dword(dis_dev, 0, &cfg_word);
// if one of the bits is not enabled (the card is enabled), the inverted
// result will be non-zero and hence logical not will make it 0 ("false")
return !~cfg_word;
}

static int bbswitch_proc_show(struct seq_file *seqfp, void *p) {
// show the card state. Example output: :01:00:00 ON
dis_dev_get();
seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev),
 is_card_disabled() ? "OFF" : "ON");
dis_dev_put();
return 0;
}
---

Either dis_dev_get or pci_read_config_dword is the trigger.

Link to the bbswitch module source code:
https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333


Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
> [+cc linux-acpi, linux-kernel, dri-devel]
> 
> Hi Roland,
> 
> I have no idea how to debug this problem.  Are you seeing something
> that suggests it may be a PCI problem?
> 
> On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
>> Hi,
>>
>> hope somebody can help me fix this kernel problem which affects the 
>> following machines:
>>
>> - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also 
>> affected)
>> - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
>> - Gigabyte P35V5 (i7-6700HQ/GTX 970M)
>> - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
>>
>>
>> The kernel freezes if the graphical user session (Xorg & Wayland) is
>> started with a switched off discrete GPU card (NVIDIA).
>> If the discrete GPU is switched off after the graphical session start,
>> then everything works as expected, until the graphical session is restarted.
>>
>> This problem seams to be linked to specific BIOS settings. If the computer
>> is started with the following command line:
>>
>> acpi_osi=! acpi_osi="Windows 2009"
>>
>> then the kernel freeze does not occur anymore. However this required a 
>> special
>> ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
>>
>> https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
>>
>> I strongly recommend to fix this in the kernel and I am ready to help and 
>> solve
>> this problem with some help.
>>
>> Here is a link to the GitHub issue with further information:
>>
>> https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-241212595
>>
>> Here are some more detailed information:
>>
>> https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
>>
>> Hope somebody can help.

[Bug 92912] Full GPU lockups in TF2 - R600

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

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

--- Comment #7 from Chris Rankin  ---
FWIW, my nephew has played TF2 (Steam's "Team Fortress 2", presumably) for
HOURS recently with HD 6450 and recent Mesa 12.1.0-devel.

If it had locked up even once then I would have known about it... ;-).

The base OS was Fedora 24/x86_64 with LLVM 3.8.0.

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

[PATCH] drm/nouveau/gr/gm107: mark symbols static where possible

[Baoyou Xie]

We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c:312:1: warning: no previous 
prototype for 'gm107_gr_init' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c
index 45f965f..2c67fac 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c
@@ -308,7 +308,7 @@ gm107_gr_init_bios(struct gf100_gr *gr)
}
 }

-int
+static int
 gm107_gr_init(struct gf100_gr *gr)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
-- 
2.7.4

[PATCH v2] drm/nouveau/gr/gf117-: mark symbols static where possible

[Baoyou Xie]

We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous 
prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
index c925ade..74a64e3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
@@ -218,7 +218,7 @@ gf117_grctx_generate_attrib(struct gf100_grctx *info)
}
 }

-void
+static void
 gf117_grctx_generate_main(struct gf100_gr *gr, struct gf100_grctx *info)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
-- 
2.7.4

[PATCH] drm/nouveau/gr: add missing header dependencies

[Baoyou Xie]

We get 2 warnings when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:255:1: warning: no previous 
prototype for 'nv50_grctx_fill' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:265:1: warning: no previous 
prototype for 'nv50_grctx_init' [-Wmissing-prototypes]

In fact, these functions are declared in gr/nv50.h, so this patch
add missing header dependencies

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
index 1e13278..0490ee8 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
@@ -109,6 +109,8 @@

 #include 

+#include "nv50.h"
+
 #define IS_NVA3F(x) (((x) > 0xa0 && (x) < 0xaa) || (x) == 0xaf)
 #define IS_NVAAF(x) ((x) >= 0xaa && (x) <= 0xac)

-- 
2.7.4

[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)

[Chris Wilson]

If we being polled with a timeout of zero, a nonblocking busy query,
we don't need to install any fence callbacks as we will not be waiting.
As we only install the callback once, the overhead comes from the atomic
bit test that also causes serialisation between threads.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
 drivers/dma-buf/sync_file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 486d29c1a830..abb5fdab75fd 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -306,7 +306,8 @@ static unsigned int sync_file_poll(struct file *file, 
poll_table *wait)

poll_wait(file, &sync_file->wq, wait);

-   if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
+   if (!poll_does_not_wait(wait) &&
+   !test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
if (fence_add_callback(sync_file->fence, &sync_file->cb,
   fence_check_cb_func) < 0)
wake_up_all(&sync_file->wq);
-- 
2.9.3

[PATCH v2] drm/nouveau: add missing header dependencies

[Baoyou Xie]

We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/dispnv04/overlay.c:496:1: warning: no previous 
prototype for 'nouveau_overlay_init' [-Wmissing-prototypes]

In fact, this function is declared in disp.h, so this patch
add missing header dependencies

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/dispnv04/overlay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index ec444ea..a79514d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -33,7 +33,7 @@
 #include "nouveau_connector.h"
 #include "nouveau_display.h"
 #include "nvreg.h"
-
+#include "disp.h"

 struct nouveau_plane {
struct drm_plane base;
-- 
2.7.4

[Bug 117581] Celsius H265: suspend does not bring up console unless no_console_suspend is given

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

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

--- Comment #7 from Elmar Stellnberger  ---
  I guess it would already be resolved but Bug 155511 inhibits me from testing
that out correctly.

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

[PATCH] drm/nouveau/gr/gf117-: mark symbols static where possible

[Baoyou Xie]

We get 1 warning when biuld kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous 
prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
index c925ade..74a64e3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
@@ -218,7 +218,7 @@ gf117_grctx_generate_attrib(struct gf100_grctx *info)
}
 }

-void
+static void
 gf117_grctx_generate_main(struct gf100_gr *gr, struct gf100_grctx *info)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
-- 
2.7.4

[PATCH] drm/ttm: Use RCU for ttm_mem_type_manager.move fence

[Christian König]

Am 29.08.2016 um 18:57 schrieb Chris Wilson:
> The ttm_mem_type_manager.move tracks the fence for the last migration on
> the memory manager. Currently it is accessed under its own spinlock to
> ensure that the fence doesn't disappear from underneath it. We can
> translate the reader to acquire a reference to the fence using
> fence_get_rcu_safe() which ensures that the fence cannot be reallocated
> as the reference is acquired.
>
> Suggested-by: Christian König 
> Signed-off-by: Chris Wilson 
> Cc: Christian König 

Reviewed-by: Christian König .

> ---
>   drivers/gpu/drm/ttm/ttm_bo.c  | 24 
>   drivers/gpu/drm/ttm/ttm_bo_util.c | 12 
>   include/drm/ttm/ttm_bo_driver.h   |  2 +-
>   3 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 42c074a9c955..422d9b39d8ae 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -797,9 +797,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object 
> *bo,
>   struct fence *fence;
>   int ret;
>   
> - spin_lock(&man->move_lock);
> - fence = fence_get(man->move);
> - spin_unlock(&man->move_lock);
> + rcu_read_lock();
> + fence = fence_get_rcu_safe(&man->move);
> + rcu_read_unlock();
>   
>   if (fence) {
>   reservation_object_add_shared_fence(bo->resv, fence);
> @@ -1310,9 +1310,9 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
> *bdev,
>   }
>   spin_unlock(&glob->lru_lock);
>   
> - spin_lock(&man->move_lock);
> - fence = fence_get(man->move);
> - spin_unlock(&man->move_lock);
> + rcu_read_lock();
> + fence = fence_get_rcu_safe(&man->move);
> + rcu_read_unlock();
>   
>   if (fence) {
>   ret = fence_wait(fence, false);
> @@ -1332,6 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
> *bdev,
>   int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
>   {
>   struct ttm_mem_type_manager *man;
> + struct fence *last_move;
>   int ret = -EINVAL;
>   
>   if (mem_type >= TTM_NUM_MEM_TYPES) {
> @@ -1345,7 +1346,14 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, 
> unsigned mem_type)
>  mem_type);
>   return ret;
>   }
> - fence_put(man->move);
> +
> + /* The locking here is overkill; but harmless and documentary */
> + spin_lock(&man->move_lock);
> + last_move = rcu_dereference_protected(man->move,
> +   spin_is_locked(&man->move_lock));
> + rcu_assign_pointer(man->move, NULL);
> + spin_unlock(&man->move_lock);
> + fence_put(last_move);
>   
>   man->use_type = false;
>   man->has_type = false;
> @@ -1410,7 +1418,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned 
> type,
>   man->size = p_size;
>   
>   INIT_LIST_HEAD(&man->lru);
> - man->move = NULL;
> + RCU_INIT_POINTER(man->move, NULL);
>   
>   return 0;
>   }
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index f157a9efd220..cd675d503ee4 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -755,6 +755,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>   ttm_bo_unref(&ghost_obj);
>   
>   } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + struct fence *last_move;
>   
>   /**
>* BO doesn't have a TTM we need to bind/unbind. Just remember
> @@ -762,11 +763,14 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>*/
>   
>   spin_lock(&from->move_lock);
> - if (!from->move || fence_is_later(fence, from->move)) {
> - fence_put(from->move);
> - from->move = fence_get(fence);
> - }
> + last_move = rcu_dereference_protected(from->move,
> +   
> spin_is_locked(&from->move_lock));
> + if (!last_move || fence_is_later(fence, last_move))
> + rcu_assign_pointer(from->move, fence_get(fence));
> + else
> + last_move = NULL;
>   spin_unlock(&from->move_lock);
> + fence_put(last_move);
>   
>   ttm_bo_free_old_node(bo);
>   
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 99c6d01d24f2..508d2f428d25 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -305,7 +305,7 @@ struct ttm_mem_type_manager {
>   /*
>* Protected by @move_lock.
>*/
> - struct fence *move;
> + struct fence __rcu *move;
>   };
>   
>   /**

[PATCH] drm/nouveau/gr: mark symbols static where possible

[Baoyou Xie]

We get 1 warning when biuld kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no previous 
prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
index 6d3c501..4c4b5ab 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -933,7 +933,7 @@ gm107_grctx_generate_attrib(struct gf100_grctx *info)
}
 }

-void
+static void
 gm107_grctx_generate_tpcid(struct gf100_gr *gr)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
-- 
2.7.4

Kernel Freeze with American Megatrends BIOS

[Bjorn Helgaas]

On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
> Just tried it and the system didn't freeze. However it will freeze
> after some time (few minutes while working).
> 
> Seams to be pci_read_config_dword. Where is this exactly defined?

pci_read_config_dword() is defined in include/linux/pci.h.  It calls
pci_bus_read_config_dword() which is defined by the PCI_OP_READ() macro
in drivers/pci/access.c.

If I understand correctly, this:

  dis_dev_get();
  pci_read_config_dword(dis_dev, 0, &cfg_word);
  dis_dev_put();

causes an immediate system hang, but if you only do this:

  dis_dev_get();
  dis_dev_put();

the system hangs a few minutes later.  Right?

> Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
> > On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
> >> Hi Bjorn,
> >>
> >> I am using the bbswitch kernel module to switch off/on the GPU and
> >> to obtain the GPU power state.
> >> Obtaining the GPU state immediately after starting the graphical user
> >> session freezes the system.
> >>
> >> This code triggers something, which is responsible for the freeze.
> >>
> >> ---
> >> // Returns 1 if the card is disabled, 0 if enabled
> >> static int is_card_disabled(void) {
> >> u32 cfg_word;
> >> // read first config word which contains Vendor and Device ID. If all 
> >> bits
> >> // are enabled, the device is assumed to be off
> >> pci_read_config_dword(dis_dev, 0, &cfg_word);
> >> // if one of the bits is not enabled (the card is enabled), the 
> >> inverted
> >> // result will be non-zero and hence logical not will make it 0 
> >> ("false")
> >> return !~cfg_word;
> >> }
> >>
> >> static int bbswitch_proc_show(struct seq_file *seqfp, void *p) {
> >> // show the card state. Example output: :01:00:00 ON
> >> dis_dev_get();
> >> seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev),
> >>  is_card_disabled() ? "OFF" : "ON");
> >> dis_dev_put();
> >> return 0;
> >> }
> >> ---
> >>
> >> Either dis_dev_get or pci_read_config_dword is the trigger.
> > 
> > What happens if you remove the call to is_card_disabled()?  Does the
> > system still freeze if you only do the dis_dev_get()/dis_dev_put()?
> > 
> >> Link to the bbswitch module source code:
> >> https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
> >>
> >>
> >> Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
> >>> [+cc linux-acpi, linux-kernel, dri-devel]
> >>>
> >>> Hi Roland,
> >>>
> >>> I have no idea how to debug this problem.  Are you seeing something
> >>> that suggests it may be a PCI problem?
> >>>
> >>> On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
>  Hi,
> 
>  hope somebody can help me fix this kernel problem which affects the 
>  following machines:
> 
>  - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are 
>  also affected)
>  - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
>  - Gigabyte P35V5 (i7-6700HQ/GTX 970M)
>  - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
> 
> 
>  The kernel freezes if the graphical user session (Xorg & Wayland) is
>  started with a switched off discrete GPU card (NVIDIA).
>  If the discrete GPU is switched off after the graphical session start,
>  then everything works as expected, until the graphical session is 
>  restarted.
> 
>  This problem seams to be linked to specific BIOS settings. If the 
>  computer
>  is started with the following command line:
> 
>  acpi_osi=! acpi_osi="Windows 2009"
> 
>  then the kernel freeze does not occur anymore. However this required a 
>  special
>  ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
> 
>  https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
> 
>  I strongly recommend to fix this in the kernel and I am ready to help 
>  and solve
>  this problem with some help.
> 
>  Here is a link to the GitHub issue with further information:
> 
>  https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-241212595
> 
>  Here are some more detailed information:
> 
>  https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
> 
>  Hope somebody can help.
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 

dri-devel@lists.freedesktop.org

[Archit Taneja]

On 08/29/2016 01:57 PM, Daniel Vetter wrote:
> - remove kerneldoc for drm-internal functions
> - drm_property_replace_global_blob isn't actually atomic, and doesn't
>need to be. Update docs&comments to match
> - document all the types and try to link things a bit better
> - nits all over
>

Reviewed-by: Archit Taneja 

> v2: Appease checkpatch in the moved code (Archit)
>
> Reviewed-by: Archit Taneja 
> Signed-off-by: Daniel Vetter 
> ---
>   Documentation/gpu/drm-kms.rst  |  88 +-
>   drivers/gpu/drm/drm_property.c | 153 
>   include/drm/drm_property.h | 196 
> ++---
>   3 files changed, 244 insertions(+), 193 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index e07a2667ab61..f9a991bb87d4 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -304,94 +304,12 @@ KMS Locking
>   KMS Properties
>   ==
>
> -Drivers may need to expose additional parameters to applications than
> -those described in the previous sections. KMS supports attaching
> -properties to CRTCs, connectors and planes and offers a userspace API to
> -list, get and set the property values.
> -
> -Properties are identified by a name that uniquely defines the property
> -purpose, and store an associated value. For all property types except
> -blob properties the value is a 64-bit unsigned integer.
> -
> -KMS differentiates between properties and property instances. Drivers
> -first create properties and then create and associate individual
> -instances of those properties to objects. A property can be instantiated
> -multiple times and associated with different objects. Values are stored
> -in property instances, and all other property information are stored in
> -the property and shared between all instances of the property.
> -
> -Every property is created with a type that influences how the KMS core
> -handles the property. Supported property types are
> -
> -DRM_MODE_PROP_RANGE
> -Range properties report their minimum and maximum admissible values.
> -The KMS core verifies that values set by application fit in that
> -range.
> -
> -DRM_MODE_PROP_ENUM
> -Enumerated properties take a numerical value that ranges from 0 to
> -the number of enumerated values defined by the property minus one,
> -and associate a free-formed string name to each value. Applications
> -can retrieve the list of defined value-name pairs and use the
> -numerical value to get and set property instance values.
> -
> -DRM_MODE_PROP_BITMASK
> -Bitmask properties are enumeration properties that additionally
> -restrict all enumerated values to the 0..63 range. Bitmask property
> -instance values combine one or more of the enumerated bits defined
> -by the property.
> -
> -DRM_MODE_PROP_BLOB
> -Blob properties store a binary blob without any format restriction.
> -The binary blobs are created as KMS standalone objects, and blob
> -property instance values store the ID of their associated blob
> -object.
> -
> -Blob properties are only used for the connector EDID property and
> -cannot be created by drivers.
> -
> -To create a property drivers call one of the following functions
> -depending on the property type. All property creation functions take
> -property flags and name, as well as type-specific arguments.
> -
> --  struct drm_property \*drm_property_create_range(struct
> -   drm_device \*dev, int flags, const char \*name, uint64_t min,
> -   uint64_t max);
> -   Create a range property with the given minimum and maximum values.
> -
> --  struct drm_property \*drm_property_create_enum(struct drm_device
> -   \*dev, int flags, const char \*name, const struct
> -   drm_prop_enum_list \*props, int num_values);
> -   Create an enumerated property. The ``props`` argument points to an
> -   array of ``num_values`` value-name pairs.
> -
> --  struct drm_property \*drm_property_create_bitmask(struct
> -   drm_device \*dev, int flags, const char \*name, const struct
> -   drm_prop_enum_list \*props, int num_values);
> -   Create a bitmask property. The ``props`` argument points to an array
> -   of ``num_values`` value-name pairs.
> -
> -Properties can additionally be created as immutable, in which case they
> -will be read-only for applications but can be modified by the driver. To
> -create an immutable property drivers must set the
> -DRM_MODE_PROP_IMMUTABLE flag at property creation time.
> -
> -When no array of value-name pairs is readily available at property
> -creation time for enumerated or range properties, drivers can create the
> -property using the :c:func:`drm_property_create()` function and
> -manually add enumeration value-name pairs by calling the
> -:c:func:`drm_property_add_enum()` function. Care must be taken to
> -properly specify the property type through the ``flags`` argument.
> -
> -After creating p

[PATCH] drm/nouveau/pm: mark symbols static where possible

[Baoyou Xie]

We get 2 warnings when biuld kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:75:1: warning: no previous 
prototype for 'nvkm_perfsig_find' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:703:1: warning: no previous 
prototype for 'nvkm_perfsrc_new' [-Wmissing-prototypes]

In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
so this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
index 8616636..dde89a4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
@@ -71,7 +71,7 @@ nvkm_perfdom_find(struct nvkm_pm *pm, int di)
return NULL;
 }

-struct nvkm_perfsig *
+static struct nvkm_perfsig *
 nvkm_perfsig_find(struct nvkm_pm *pm, u8 di, u8 si, struct nvkm_perfdom **pdom)
 {
struct nvkm_perfdom *dom = *pdom;
@@ -699,7 +699,7 @@ nvkm_pm_oclass_get(struct nvkm_oclass *oclass, int index,
return 1;
 }

-int
+static int
 nvkm_perfsrc_new(struct nvkm_pm *pm, struct nvkm_perfsig *sig,
 const struct nvkm_specsrc *spec)
 {
-- 
2.7.4

[PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

[Jani Nikula]

On Mon, 29 Aug 2016, Lyude  wrote:
> i915 sometimes needs to disable planes in the middle of an atomic
> commit, and then reenable them later in the same commit. Because of
> this, we can't make the assumption that the state of the plane actually
> changed. Since the state of the plane hasn't actually changed, neither
> have it's watermarks. And if the watermarks hasn't changed then we
> haven't populated skl_results with anything, which means we'll end up
> zeroing out a plane's watermarks in the middle of the atomic commit
> without restoring them later.

I would appreciate a (brief) description of what the failure mode is in
this case.

BR,
Jani.


>
> Changes since v1:
>  - Fix incorrect use of "it's"
>
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
> during plane updates")
>
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 7 ++-
>  drivers/gpu/drm/i915/intel_sprite.c  | 9 +++--
>  2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e4e6141..13e47a7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct 
> drm_plane *primary,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   int pipe = intel_crtc->pipe;
>  
> - skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
> + /*
> +  * We only populate skl_results on watermark updates, and if the
> +  * plane's visiblity isn't actually changing neither is its watermarks.
> +  */
> + if (!crtc->primary->state->visible)
> + skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
>  
>   I915_WRITE(PLANE_CTL(pipe, 0), 0);
>   I915_WRITE(PLANE_SURF(pipe, 0), 0);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 0df783a..73a521f 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct 
> drm_crtc *crtc)
>   const int pipe = intel_plane->pipe;
>   const int plane = intel_plane->plane + 1;
>  
> - skl_write_plane_wm(to_intel_crtc(crtc), &dev_priv->wm.skl_results,
> -plane);
> + /*
> +  * We only populate skl_results on watermark updates, and if the
> +  * plane's visiblity isn't actually changing neither is its watermarks.
> +  */
> + if (!dplane->state->visible)
> + skl_write_plane_wm(to_intel_crtc(crtc),
> +&dev_priv->wm.skl_results, plane);
>  
>   I915_WRITE(PLANE_CTL(pipe, plane), 0);

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

[Jani Nikula]

On Mon, 29 Aug 2016, Andrea Arcangeli  wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> If it's an Iybridge, there's no low vswing, and that explanation is
>> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> on an unpatched kernel.
>
> What I should look for when trying those two settings? Will they
> successfully fix my problem with intel_backlight with upstream 4.8-rc?
>
> I thought it had to be the same issue as on skylake as I get the
> backlight flikering at low frequency but getting brighter and darker
> in a cycle lasting a few seconds and I thought there couldn't be too
> many other random bugs that ends up with the same side effect.

Your Ivybridge does not have low voltage swing *and* low voltage swing
has nothing to do with the backlight. The regressing commit may be the
same for you, but the failure mode appears to be completely different.

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

[Ying Liu]

On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel  
wrote:
> Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
>> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel  
>> wrote:
>> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> >> According to basic tests, it looks there is no issue if we don't wait for
>> >> DMFC FIFO to clear when disabling DMFC channel.  NXP BSP doesn't do that,
>> >> either.  This patch is needed to avoid the annoying warning caused by a
>> >> timeout on waiting for the FIFO to clear after we add the new
>> >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver
>> >> which changes the procedure to disable display channel slightly.
>> >
>> > I suppose the reason this happens is that now DC/DI are disabled first,
>> > so the DC can't drain the FIFO anymore. If the FIFO is properly reset
>> > when reenabling the DMFC, this shouldn't have any ill effects.
>>
>> I found the timeout warning issue by blanking the framebuffer.
>> Ofc, the framebuffer is supported by the fbdev emulation.
>> Before applying this patch set, the planes are not even disabled
>> when the framebuffer is blanked, that is to say, plane_funcs->
>> atomic_disable is not called - the CRTC is disabled alone.
>> After applying this patch set, the planes are always disabled
>> together with the CRTC.  And, yes, DC/DI are disabled first,
>> then the timeout warning happens.
>>
>> Please note the warning happens when the planes are disabled
>> instead of reenabled.  So, I don't get your point by resetting
>> FIFO when _reenabling_  DMFC.
>
> If we disable the DMFC with data still in the FIFO and then reenable it
> and the DC first reads the stale data from the FIFO, that should cause a
> visible artifact in the first frame after reenabling the plane. If that
> doesn't happen, I trust that the hardware resets the FIFO state
> somewhere along the way.

Not sure if the hardware resets the FIFO automatically...
The NXP driver waits for some hardware status/irqs when disabling
the channels, but it doesn't wait for DMFC status.

>
>> And, I don't see the way to reset FIFO.
>
> We could reset the DMFC_WR memory after disabling the DMFC, but I'm not
> sure this is necessary at all.

You mean the register DMFC_WR_CHAN, for instance?
I still don't see how we could reset the FIFO.

Regards,
Liu Ying

>
> regards
> Philipp
>

[PATCH] drm/ttm: Use RCU for ttm_mem_type_manager.move fence

[Chris Wilson]

The ttm_mem_type_manager.move tracks the fence for the last migration on
the memory manager. Currently it is accessed under its own spinlock to
ensure that the fence doesn't disappear from underneath it. We can
translate the reader to acquire a reference to the fence using
fence_get_rcu_safe() which ensures that the fence cannot be reallocated
as the reference is acquired.

Suggested-by: Christian König 
Signed-off-by: Chris Wilson 
Cc: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c  | 24 
 drivers/gpu/drm/ttm/ttm_bo_util.c | 12 
 include/drm/ttm/ttm_bo_driver.h   |  2 +-
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 42c074a9c955..422d9b39d8ae 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -797,9 +797,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object 
*bo,
struct fence *fence;
int ret;

-   spin_lock(&man->move_lock);
-   fence = fence_get(man->move);
-   spin_unlock(&man->move_lock);
+   rcu_read_lock();
+   fence = fence_get_rcu_safe(&man->move);
+   rcu_read_unlock();

if (fence) {
reservation_object_add_shared_fence(bo->resv, fence);
@@ -1310,9 +1310,9 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
}
spin_unlock(&glob->lru_lock);

-   spin_lock(&man->move_lock);
-   fence = fence_get(man->move);
-   spin_unlock(&man->move_lock);
+   rcu_read_lock();
+   fence = fence_get_rcu_safe(&man->move);
+   rcu_read_unlock();

if (fence) {
ret = fence_wait(fence, false);
@@ -1332,6 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
 int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
 {
struct ttm_mem_type_manager *man;
+   struct fence *last_move;
int ret = -EINVAL;

if (mem_type >= TTM_NUM_MEM_TYPES) {
@@ -1345,7 +1346,14 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
   mem_type);
return ret;
}
-   fence_put(man->move);
+
+   /* The locking here is overkill; but harmless and documentary */
+   spin_lock(&man->move_lock);
+   last_move = rcu_dereference_protected(man->move,
+ spin_is_locked(&man->move_lock));
+   rcu_assign_pointer(man->move, NULL);
+   spin_unlock(&man->move_lock);
+   fence_put(last_move);

man->use_type = false;
man->has_type = false;
@@ -1410,7 +1418,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned 
type,
man->size = p_size;

INIT_LIST_HEAD(&man->lru);
-   man->move = NULL;
+   RCU_INIT_POINTER(man->move, NULL);

return 0;
 }
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f157a9efd220..cd675d503ee4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -755,6 +755,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
ttm_bo_unref(&ghost_obj);

} else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
+   struct fence *last_move;

/**
 * BO doesn't have a TTM we need to bind/unbind. Just remember
@@ -762,11 +763,14 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
 */

spin_lock(&from->move_lock);
-   if (!from->move || fence_is_later(fence, from->move)) {
-   fence_put(from->move);
-   from->move = fence_get(fence);
-   }
+   last_move = rcu_dereference_protected(from->move,
+ 
spin_is_locked(&from->move_lock));
+   if (!last_move || fence_is_later(fence, last_move))
+   rcu_assign_pointer(from->move, fence_get(fence));
+   else
+   last_move = NULL;
spin_unlock(&from->move_lock);
+   fence_put(last_move);

ttm_bo_free_old_node(bo);

diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 99c6d01d24f2..508d2f428d25 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -305,7 +305,7 @@ struct ttm_mem_type_manager {
/*
 * Protected by @move_lock.
 */
-   struct fence *move;
+   struct fence __rcu *move;
 };

 /**
-- 
2.9.3

[PATCH] drm/imx: fix crtc vblank state regression

[Lucas Stach]

The atomic conversion lost the notification to let the DRM core
know about the current state of the CRTC vblank interrupts. This
regressed the ability of the core to reject page flip attempts
on currently disabled CRTCs. Add back the notifications.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 08e188bc10fc..462056e4b9e4 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -76,6 +76,8 @@ static void ipu_crtc_disable(struct drm_crtc *crtc)
crtc->state->event = NULL;
}
spin_unlock_irq(&crtc->dev->event_lock);
+
+   drm_crtc_vblank_off(crtc);
 }

 static void imx_drm_crtc_reset(struct drm_crtc *crtc)
@@ -175,6 +177,8 @@ static int ipu_crtc_atomic_check(struct drm_crtc *crtc,
 static void ipu_crtc_atomic_begin(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
+   drm_crtc_vblank_on(crtc);
+
spin_lock_irq(&crtc->dev->event_lock);
if (crtc->state->event) {
WARN_ON(drm_crtc_vblank_get(crtc));
-- 
2.8.1

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

[Daniel Vetter]

On Mon, Aug 29, 2016 at 4:59 PM, Philipp Zabel  
wrote:
> Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
>> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> > This patch adds active plane reconfiguration support for imx-drm.
>> > This may fixes some mode setting failure issues which were introduced
>> > by imx-drm atomic conversion patch set.  The main idea is to disable the
>> > plane in question in CRTC's atomic_disable operation and then the drm
>> > atomic core will enable it again automatically.
>>
>> I have rebased onto drm-misc and picked up the remaining patches (4-7)
>
> Actually, since this is a regression and the new drm-misc patches won't
> make it into 4.8, I'd be inclined to take the v2 patch as a fix for 4.8
> and then apply the remaining patches as relative changes to that on top
> of drm-misc instead.

Just apply the 4.8 to 4.8 and then once that's in an -rc do a
backmerge with -X ours and explain in the commit what you're doing. No
need to rework the patches once more to be incremental on top of the
4.8 fix.

At least that's what we're doing all the time in i915.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes

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

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

Matias N. Goldberg  changed:

   What|Removed |Added

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

--- Comment #18 from Matias N. Goldberg  ---
You're awesome!

I can confirm it works on both the sample repro I provided and my actual real
case.

Small note: We discovered there was a potential for a crash because at certain
points we assume SIMD alignment; so we're now enforcing 16-byte alignment as
minimum in our code. I'm doing this remark because Mesa is the only (or among
the very few) implementations that return alignments <16; which can reveal
hidden bugs in program code that runs fine everywhere else. If you ever see a
bug report of these sorts (e.g. crashing in movaps, movntdqa), this is
something to keep in mind.

I appreciate the 4 byte alignment as 256 reported by others is excessively
wasteful. Thanks.

For the record it was fixed in
https://cgit.freedesktop.org/mesa/mesa/commit/?id=7cd256ce7e4bad680bb77d033cf5dd662abab2dd
and
https://cgit.freedesktop.org/mesa/mesa/commit/?id=325379096f54dde39171d1b8804e29a8003bb3c7

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

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Emil Velikov]

Hi all,

On 24 August 2016 at 06:46, Vladimir Zapolskiy
 wrote:

>  MODULE_AUTHOR("Sascha Hauer ");
>  MODULE_AUTHOR("Andy Yan ");
>  MODULE_AUTHOR("Yakir Yang ");
> +MODULE_AUTHOR("Vladimir Zapolskiy ");
Don't meant to start a flame-war or alike but to educate myself:
Where does one draw the line about adding new author(s) of said
module/subsystem ?

Afaict this is the most common (?) driver in DRM where the list has
grown over time. Should we do the same with others ?

Thanks
Emil

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

[Ying Liu]

On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel  
wrote:
> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> According to basic tests, it looks there is no issue if we don't wait for
>> DMFC FIFO to clear when disabling DMFC channel.  NXP BSP doesn't do that,
>> either.  This patch is needed to avoid the annoying warning caused by a
>> timeout on waiting for the FIFO to clear after we add the new
>> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver
>> which changes the procedure to disable display channel slightly.
>
> I suppose the reason this happens is that now DC/DI are disabled first,
> so the DC can't drain the FIFO anymore. If the FIFO is properly reset
> when reenabling the DMFC, this shouldn't have any ill effects.

I found the timeout warning issue by blanking the framebuffer.
Ofc, the framebuffer is supported by the fbdev emulation.
Before applying this patch set, the planes are not even disabled
when the framebuffer is blanked, that is to say, plane_funcs->
atomic_disable is not called - the CRTC is disabled alone.
After applying this patch set, the planes are always disabled
together with the CRTC.  And, yes, DC/DI are disabled first,
then the timeout warning happens.

Please note the warning happens when the planes are disabled
instead of reenabled.  So, I don't get your point by resetting
FIFO when _reenabling_  DMFC.  And, I don't see the way to
reset FIFO.

Regards,
Liu Ying

>
> regards
> Philipp
>

[PATCH 0/4] Backported vlv fixes for 4.7.y

[Lyude Paul]

drm/i915/vlv: Make intel_crt_reset() per-encoder:
4570d833390b10043d082fe535375d4a0e071d9c
drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init():
4c732e6ee9e71903934d75b12a021eb3520b6197
drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug():
21842ea84f161ae37ba25f0250c377fd19c5b307
drm/i915: Enable polling when we don't have hpd:
84c8e0963da434d37355079b568465cd121af295

On Mon, 2016-08-22 at 16:33 -0400, Greg KH wrote:
> On Mon, Aug 22, 2016 at 11:31:31AM -0400, Lyude wrote:
> > 
> > Hope this didn't take too long! Here's the backported versions of the
> > patches
> > you had trouble applying to stable. The patch for FBC won't be necessary as
> > that is already present in 4.7.y.
> > 
> > Cheers,
> > Lyude
> 
> Thanks, but what are the git commit ids of these patches in Linus's
> tree?  I need those to add to the commits...
> 
> thanks,
> 
> greg k-h

[PATCH v2] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

[Liu Ying]

Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a plane if the CRTC of the old plane state needs a modesetting
operation. Of course, the drivers need to disable the planes in their CRTC
disable callbacks since no one else would do that.

Suggested-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
---
I choose to pick this patch from the patch set[1] so that I may address
Daniel Vetter's comments conveniently by sending v2 for it alone.

[1] http://www.spinics.net/lists/dri-devel/msg116491.html

v1->v2:
* Add a newline in the kernel-doc for drm_atomic_helper_commit_planes()
  to improve readability.
* Remove unecessary check/warn on crtc_state before passing it over to
  drm_atomic_crtc_needs_modeset().
* Wrap plane_funcs->atomic_update with {} to make checkpatch happy.

 drivers/gpu/drm/arm/malidp_drv.c |  3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c  | 43 
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c   |  3 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  6 ++--
 drivers/gpu/drm/msm/msm_atomic.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |  3 +-
 drivers/gpu/drm/sti/sti_drv.c|  2 +-
 drivers/gpu/drm/tegra/drm.c  |  3 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c |  3 +-
 include/drm/drm_atomic_helper.h  |  6 +++-
 16 files changed, 59 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 82171d2..c383d72 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state 
*state)

drm_atomic_helper_commit_modeset_disables(drm, state);
drm_atomic_helper_commit_modeset_enables(drm, state);
-   drm_atomic_helper_commit_planes(drm, state, true);
+   drm_atomic_helper_commit_planes(drm, state,
+   DRM_PLANE_COMMIT_ACTIVE_ONLY);

malidp_atomic_commit_hw_done(state);

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index d4a3d61..8e7483d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit 
*commit)

/* Apply the atomic update. */
drm_atomic_helper_commit_modeset_disables(dev, old_state);
-   drm_atomic_helper_commit_planes(dev, old_state, false);
+   drm_atomic_helper_commit_planes(dev, old_state, 0);
drm_atomic_helper_commit_modeset_enables(dev, old_state);

drm_atomic_helper_wait_for_vblanks(dev, old_state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5f82290..6fdd7ba 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
  *
  * drm_atomic_helper_commit_modeset_enables(dev, state);
  *
- * drm_atomic_helper_commit_planes(dev, state, true);
+ * drm_atomic_helper_commit_planes(dev, state,
+ * DRM_PLANE_COMMIT_ACTIVE_ONLY);
  *
  * for committing the atomic update to hardware.  See the kerneldoc entries for
  * these three functions for more details.
@@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct 
drm_atomic_state *state)

drm_atomic_helper_commit_modeset_disables(dev, state);

-   drm_atomic_helper_commit_planes(dev, state, false);
+   drm_atomic_helper_commit_planes(dev, state, 0);

drm_atomic_helper_commit_modeset_enables(dev, state);

@@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state)
  * drm_atomic_helper_commit_planes - commit plane state
  * @dev: DRM device
  * @old_state: atomic state object with old state structures
- * @active_only: Only commit on active CRTC if set
+ * @flags: flags for committing plane state
  *
  * This function commits the new plane state using the plane and atomic helper
  * functions for planes and crtcs. It assumes that the atomic state has already
@@ -1698,25 +1699,34 @@ bool plane_crtc_active(struct drm_plane_state *state)
  * most drivers don't need to be immediately notified of plan

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

[Philipp Zabel]

Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> > This patch adds active plane reconfiguration support for imx-drm.
> > This may fixes some mode setting failure issues which were introduced
> > by imx-drm atomic conversion patch set.  The main idea is to disable the
> > plane in question in CRTC's atomic_disable operation and then the drm
> > atomic core will enable it again automatically.
> 
> I have rebased onto drm-misc and picked up the remaining patches (4-7)

Actually, since this is a regression and the new drm-misc patches won't
make it into 4.8, I'd be inclined to take the v2 patch as a fix for 4.8
and then apply the remaining patches as relative changes to that on top
of drm-misc instead.

regards
Philipp

[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

[Ying Liu]

On Mon, Aug 29, 2016 at 4:25 PM, Daniel Vetter  wrote:
> On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote:
>> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
>> of the helper drm_atomic_helper_commit_planes() if the relevant display
>> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
>> when the CRTC is disabled. The helper would skip the ->atomic_disable
>> call for a plane if the CRTC of the old plane state needs a modesetting
>> operation. Of course, the drivers need to disable the planes in their CRTC
>> disable callbacks since no one else would do that.
>>
>> Suggested-by: Daniel Vetter 
>> Cc: Philipp Zabel 
>> Cc: David Airlie 
>> Cc: Russell King 
>> Cc: Peter Senna Tschudin 
>> Cc: Lucas Stach 
>> Signed-off-by: Liu Ying 
>
> A few small nits below, otherwise looks good. I merged patches 1&2 into
> drm-misc already.

I'll address all your below comments and send v2 for this one separately.

Thanks.

Regards,
Liu Ying

>
> Thanks, Daniel
>
>> ---
>> v4:
>> * Newly introduced in v4.
>>
>>  drivers/gpu/drm/arm/malidp_drv.c |  3 +-
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>>  drivers/gpu/drm/drm_atomic_helper.c  | 46 
>> 
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>>  drivers/gpu/drm/imx/imx-drm-core.c   |  3 +-
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  6 ++--
>>  drivers/gpu/drm/msm/msm_atomic.c |  2 +-
>>  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
>>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |  3 +-
>>  drivers/gpu/drm/sti/sti_drv.c|  2 +-
>>  drivers/gpu/drm/tegra/drm.c  |  3 +-
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>>  drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
>>  drivers/gpu/drm/virtio/virtgpu_display.c |  3 +-
>>  include/drm/drm_atomic_helper.h  |  6 +++-
>>  16 files changed, 61 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
>> b/drivers/gpu/drm/arm/malidp_drv.c
>> index 82171d2..c383d72 100644
>> --- a/drivers/gpu/drm/arm/malidp_drv.c
>> +++ b/drivers/gpu/drm/arm/malidp_drv.c
>> @@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct 
>> drm_atomic_state *state)
>>
>>   drm_atomic_helper_commit_modeset_disables(drm, state);
>>   drm_atomic_helper_commit_modeset_enables(drm, state);
>> - drm_atomic_helper_commit_planes(drm, state, true);
>> + drm_atomic_helper_commit_planes(drm, state,
>> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
>>
>>   malidp_atomic_commit_hw_done(state);
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index d4a3d61..8e7483d 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct 
>> atmel_hlcdc_dc_commit *commit)
>>
>>   /* Apply the atomic update. */
>>   drm_atomic_helper_commit_modeset_disables(dev, old_state);
>> - drm_atomic_helper_commit_planes(dev, old_state, false);
>> + drm_atomic_helper_commit_planes(dev, old_state, 0);
>>   drm_atomic_helper_commit_modeset_enables(dev, old_state);
>>
>>   drm_atomic_helper_wait_for_vblanks(dev, old_state);
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 30c52a8..cf19b6e 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
>>   *
>>   * drm_atomic_helper_commit_modeset_enables(dev, state);
>>   *
>> - * drm_atomic_helper_commit_planes(dev, state, true);
>> + * drm_atomic_helper_commit_planes(dev, state,
>> + * DRM_PLANE_COMMIT_ACTIVE_ONLY);
>>   *
>>   * for committing the atomic update to hardware.  See the kerneldoc entries 
>> for
>>   * these three functions for more details.
>> @@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct 
>> drm_atomic_state *state)
>>
>>   drm_atomic_helper_commit_modeset_disables(dev, state);
>>
>> - drm_atomic_helper_commit_planes(dev, state, false);
>> + drm_atomic_helper_commit_planes(dev, state, 0);
>>
>>   drm_atomic_helper_commit_modeset_enables(dev, state);
>>
>> @@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state)
>>   * drm_atomic_helper_commit_planes - commit plane state
>>   * @dev: DRM device
>>   * @old_state: atomic state object with old state structures
>> - * @active_only: Only commit on active CRTC if set
>> + * @flags: flags for committing plane state
>>   *
>>   * This function commits the new plane state using the plane and atomic 
>> helper
>>   * functions for planes and crtcs. It assumes that the at

[PATCH 4/4 v2] drm/bridge: adv7511: Initialize audio packet on adv7533

[John Stultz]

From: Andy Green 

Set the initial audio packet settings to allow the audio
driver to work.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Andy Green 
[jstultz: Forward ported to mainline, changed to use register
 names rather then hex values, and removed config values set by
 audio driver.]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7533.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 6798ecf..cced7c9 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -104,6 +104,28 @@ void adv7533_dsi_power_on(struct adv7511 *adv)
/* disable test mode */
regmap_write(adv->regmap_cec, 0x55, 0x00);

+   /* hide Audio infoframe updates */
+   regmap_update_bits(adv->regmap, ADV7511_REG_INFOFRAME_UPDATE,
+   BIT(5), BIT(5));
+   /* enable N/CTS, enable Audio sample packets */
+   regmap_update_bits(adv->regmap, ADV7511_REG_PACKET_ENABLE1,
+   BIT(5), BIT(5));
+   /* enable N/CTS */
+   regmap_update_bits(adv->regmap, ADV7511_REG_PACKET_ENABLE1,
+   BIT(6), BIT(6));
+   /* not copyrighted */
+   regmap_update_bits(adv->regmap, ADV7511_REG_AUDIO_CFG1,
+   BIT(5), BIT(5));
+   /* enable audio infoframes */
+   regmap_update_bits(adv->regmap, ADV7511_REG_PACKET_ENABLE1,
+   BIT(3), BIT(3));
+   /* AV mute disable */
+   regmap_update_bits(adv->regmap, ADV7511_REG_GC(0),
+   BIT(7) | BIT(6), BIT(7));
+   /* use Audio infoframe updated info */
+   regmap_update_bits(adv->regmap, ADV7511_REG_GC(1),
+   BIT(5), 0);
+
regmap_register_patch(adv->regmap_cec, adv7533_cec_fixed_registers,
  ARRAY_SIZE(adv7533_cec_fixed_registers));
 }
-- 
1.9.1

[PATCH 3/4 v2] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

[John Stultz]

From: Srinivas Kandagatla 

This patch enables the Audio Data and Clock pads to the adv7533 bridge.
Without this patch audio can not be played.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7533.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 5eebd15..6798ecf 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -29,6 +29,7 @@ static const struct reg_sequence 
adv7533_cec_fixed_registers[] = {
{ 0x17, 0xd0 },
{ 0x24, 0x20 },
{ 0x57, 0x11 },
+   { 0x05, 0xc8 },
 };

 static const struct regmap_config adv7533_cec_regmap_config = {
-- 
1.9.1

[PATCH 2/4 v2] drm/bridge: adv7511: Add Audio support.

[John Stultz]

This patch adds support to Audio for both adv7511 and adv7533
bridge chips.

This patch was originally from [1] by Lars-Peter Clausen 
and was adapted by Archit Taneja  and
Srinivas Kandagatla .

Then I heavily reworked it to use the hdmi-codec driver. So credit
to them, but blame to me.

[1] 
https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i2c/adv7511_audio.c

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2: Integrated feedback from Srinivas

 drivers/gpu/drm/bridge/adv7511/Kconfig |   1 +
 drivers/gpu/drm/bridge/adv7511/Makefile|   2 +-
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |   5 +
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 199 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   5 +
 5 files changed, 211 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index d2b0499..e3975e9 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -3,6 +3,7 @@ config DRM_I2C_ADV7511
depends on OF
select DRM_KMS_HELPER
select REGMAP_I2C
+   select SND_SOC_HDMI_CODEC if SND_SOC
help
  Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.

diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 9019327..ad7245d 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,3 +1,3 @@
-adv7511-y := adv7511_drv.o
+adv7511-y := adv7511_drv.o adv7511_audio.o
 adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index c7002a0..2e4d340 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -23,6 +23,8 @@ struct adv7511;

 int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
 int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+int adv7511_audio_init(struct device *dev);
+void adv7511_audio_exit(struct device *dev);

 #define ADV7511_REG_CHIP_REVISION  0x00
 #define ADV7511_REG_N0 0x01
@@ -317,6 +319,8 @@ struct adv7511 {
struct drm_display_mode curr_mode;

unsigned int f_tmds;
+   unsigned int f_audio;
+   unsigned int audio_source;

unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -342,6 +346,7 @@ struct adv7511 {
bool use_timing_gen;

enum adv7511_type type;
+   struct platform_device *audio_pdev;
 };

 #ifdef CONFIG_DRM_I2C_ADV7533
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
new file mode 100644
index 000..0e0ea6b
--- /dev/null
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -0,0 +1,199 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ * Copyright (c) 2016, Linaro Limited
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "adv7511.h"
+
+static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs,
+  unsigned int *cts, unsigned int *n)
+{
+   switch (fs) {
+   case 32000:
+   *n = 4096;
+   break;
+   case 44100:
+   *n = 6272;
+   break;
+   case 48000:
+   *n = 6144;
+   break;
+   }
+
+   *cts = ((f_tmds * *n) / (128 * fs)) * 1000;
+}
+
+static int adv7511_update_cts_n(struct adv7511 *adv7511)
+{
+   unsigned int cts = 0;
+   unsigned int n = 0;
+
+   adv7511_calc_cts_n(adv7511->f_tmds, adv7511->f_audio, &cts, &n);
+
+   regmap_write(adv7511->regmap, ADV7511_REG_N0, (n >> 16) & 0xf);
+   regmap_write(adv7511->regmap, ADV7511_REG_N1, (n >> 8) & 0xff);
+   regmap_write(adv7511->regmap, ADV7511_REG_N2, n & 0xff);
+
+   regmap_write(adv7511->regmap, ADV7511_REG_CTS_MANUAL0,
+(cts >> 16) & 0xf);
+   regmap_write(adv7511->regmap, ADV7511_REG_CTS_MANUAL1,
+(cts >> 8) & 0xff);
+   regmap_write(adv7511->regmap, ADV7511_REG_CTS_MANUAL2,
+cts & 0xff);
+
+   return 0;
+}
+
+int adv7511_hdmi_hw_params(struct device *dev, void *data,
+   struct hdmi_codec_daifmt *fmt,
+   struct hdmi_codec_params *hparms)
+{
+   struct adv7511 *adv7511 = dev_get_drvdata(de

[PATCH 1/4 v2] drm/bridge: adv7511: Move the common data structures to header file

[John Stultz]

From: Archit Taneja 

This patch moves the adv7511 data structure to header file so that the
audio driver file could use it.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7511.h | 8 
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 161c923..c7002a0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -16,6 +16,14 @@
 #include 
 #include 

+#include 
+
+struct regmap;
+struct adv7511;
+
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+
 #define ADV7511_REG_CHIP_REVISION  0x00
 #define ADV7511_REG_N0 0x01
 #define ADV7511_REG_N1 0x02
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ec8fb2e..f8eb7f8 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -160,7 +160,7 @@ static void adv7511_set_colormap(struct adv7511 *adv7511, 
bool enable,
   ADV7511_CSC_UPDATE_MODE, 0);
 }

-static int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet)
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet)
 {
if (packet & 0xff)
regmap_update_bits(adv7511->regmap, ADV7511_REG_PACKET_ENABLE0,
@@ -175,7 +175,7 @@ static int adv7511_packet_enable(struct adv7511 *adv7511, 
unsigned int packet)
return 0;
 }

-static int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet)
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet)
 {
if (packet & 0xff)
regmap_update_bits(adv7511->regmap, ADV7511_REG_PACKET_ENABLE0,
-- 
1.9.1

[PATCH 0/4 v2] Audio support for adv7511 hdmi bridge

[John Stultz]

This is another swing at getting the adv7511 hdmi bridge
audio support reviewed.

I've taken the core audio work done by Lars-Peter Clausen, and
adapted by Srinivas Kandagatla and Archit Taneja, and tried to
rework it to use the hdmi-codec sound driver.

This patchset, along with the i2s driver and dts changes allows
HDMI audio to work on the HiKey board.

I'd really appreciate any thoughts or feedback.

New in v2:
* Integrated Srinivas' review feedback

thanks
-john

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org

Andy Green (1):
  drm/bridge: adv7511: Initialize audio packet on adv7533

Archit Taneja (1):
  drm/bridge: adv7511: Move the common data structures to header file

John Stultz (1):
  drm/bridge: adv7511: Add Audio support.

Srinivas Kandagatla (1):
  drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

 drivers/gpu/drm/bridge/adv7511/Kconfig |   1 +
 drivers/gpu/drm/bridge/adv7511/Makefile|   2 +-
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  13 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 199 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   9 +-
 drivers/gpu/drm/bridge/adv7511/adv7533.c   |  23 +++
 6 files changed, 244 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

-- 
1.9.1

[PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling

[Peter Ujfalusi]

On 08/29/16 15:58, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
>> drm_kms_helper_poll_enable_locked() should check if we have delayed event
>> pending and if we have, schedule the work to run without delay.
>>
>> Currently the output_poll_work is only scheduled if any of the connectors
>> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
>> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
>> already registered to be handled. The detection will be delayd by
>> DRM_OUTPUT_POLL_PERIOD in any case.
>> Furthermore if none of the connectors are marked as POLL_CONNECT or
>> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
>> always connected: the output_poll_work will not run at all even if we
>> have delayed event marked.
>>
>> When none of the connectors require polling, their initial status change
>> from unknown to connected/disconnected is not going to be handled until
>> the first kms application starts or if we have fb console enabled.
>>
>> With this change we can react more quickly to output status changes after
>> enabling the poll but most importantly it will correct the behavior when
>> none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
>> are either POLL_HPD or the .polled is 0. The initial status change is going
>> to be handled correctly as well.
> 
> Don't we need to set delayed_event somewhere too first? At least I don't
> really understand how this speeds things up

The delayed_event is set first in the
drm_helper_probe_single_connector_modes_merge_bits() when the force is not set.
The drm_kms_helper_poll_init() is called by drivers when they have their
connectors set up. So when probing the drivers we will first set up the
connectors, they will move from connector_status_unknown to connected or
disconnected and the delayed_event is set.
Later the drm_kms_helper_poll_init() is called and that will schedule the work
with DRM_OUTPUT_POLL_PERIOD. So even if we now know the state of the
connectors, they will be checked by the poll_work when the work is running
with a delay. If we set the delay to 0 the detection will run much faster.

Is this makes more sense?

> ... The patch itself looks
> like a valid bugfix, but the description confuses me a bit. I think if you
> delete the above paragraph (starting with "With this change we can react
> ...") then it's all good.

I can drop the last paragraph.

> -Daniel
> 
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/gpu/drm/drm_probe_helper.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index a0df377d7d1c..f6b64d7d3528 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
>> *dev)
>>  {
>>  bool poll = false;
>>  struct drm_connector *connector;
>> +unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>>  
>>  WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>>  
>> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct 
>> drm_device *dev)
>>  poll = true;
>>  }
>>  
>> +if (dev->mode_config.delayed_event) {
>> +poll = true;
>> +delay = 0;
>> +}
>> +
>>  if (poll)
>> -schedule_delayed_work(&dev->mode_config.output_poll_work, 
>> DRM_OUTPUT_POLL_PERIOD);
>> +schedule_delayed_work(&dev->mode_config.output_poll_work, 
>> delay);
>>  }
>>  EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>>  
>> -- 
>> 2.9.3
>>
> 


-- 
Péter

dri-devel@lists.freedesktop.org

[Daniel Vetter]

On Mon, Aug 29, 2016 at 06:44:46PM +0530, Archit Taneja wrote:
> 
> 
> On 08/29/2016 01:57 PM, Daniel Vetter wrote:
> > - remove kerneldoc for drm-internal functions
> > - drm_property_replace_global_blob isn't actually atomic, and doesn't
> >need to be. Update docs&comments to match
> > - document all the types and try to link things a bit better
> > - nits all over
> > 
> 
> Reviewed-by: Archit Taneja 

All applied to drm-misc, thanks for your review.
-Daniel

> 
> > v2: Appease checkpatch in the moved code (Archit)
> > 
> > Reviewed-by: Archit Taneja 
> > Signed-off-by: Daniel Vetter 
> > ---
> >   Documentation/gpu/drm-kms.rst  |  88 +-
> >   drivers/gpu/drm/drm_property.c | 153 
> >   include/drm/drm_property.h | 196 
> > ++---
> >   3 files changed, 244 insertions(+), 193 deletions(-)
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index e07a2667ab61..f9a991bb87d4 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -304,94 +304,12 @@ KMS Locking
> >   KMS Properties
> >   ==
> > 
> > -Drivers may need to expose additional parameters to applications than
> > -those described in the previous sections. KMS supports attaching
> > -properties to CRTCs, connectors and planes and offers a userspace API to
> > -list, get and set the property values.
> > -
> > -Properties are identified by a name that uniquely defines the property
> > -purpose, and store an associated value. For all property types except
> > -blob properties the value is a 64-bit unsigned integer.
> > -
> > -KMS differentiates between properties and property instances. Drivers
> > -first create properties and then create and associate individual
> > -instances of those properties to objects. A property can be instantiated
> > -multiple times and associated with different objects. Values are stored
> > -in property instances, and all other property information are stored in
> > -the property and shared between all instances of the property.
> > -
> > -Every property is created with a type that influences how the KMS core
> > -handles the property. Supported property types are
> > -
> > -DRM_MODE_PROP_RANGE
> > -Range properties report their minimum and maximum admissible values.
> > -The KMS core verifies that values set by application fit in that
> > -range.
> > -
> > -DRM_MODE_PROP_ENUM
> > -Enumerated properties take a numerical value that ranges from 0 to
> > -the number of enumerated values defined by the property minus one,
> > -and associate a free-formed string name to each value. Applications
> > -can retrieve the list of defined value-name pairs and use the
> > -numerical value to get and set property instance values.
> > -
> > -DRM_MODE_PROP_BITMASK
> > -Bitmask properties are enumeration properties that additionally
> > -restrict all enumerated values to the 0..63 range. Bitmask property
> > -instance values combine one or more of the enumerated bits defined
> > -by the property.
> > -
> > -DRM_MODE_PROP_BLOB
> > -Blob properties store a binary blob without any format restriction.
> > -The binary blobs are created as KMS standalone objects, and blob
> > -property instance values store the ID of their associated blob
> > -object.
> > -
> > -Blob properties are only used for the connector EDID property and
> > -cannot be created by drivers.
> > -
> > -To create a property drivers call one of the following functions
> > -depending on the property type. All property creation functions take
> > -property flags and name, as well as type-specific arguments.
> > -
> > --  struct drm_property \*drm_property_create_range(struct
> > -   drm_device \*dev, int flags, const char \*name, uint64_t min,
> > -   uint64_t max);
> > -   Create a range property with the given minimum and maximum values.
> > -
> > --  struct drm_property \*drm_property_create_enum(struct drm_device
> > -   \*dev, int flags, const char \*name, const struct
> > -   drm_prop_enum_list \*props, int num_values);
> > -   Create an enumerated property. The ``props`` argument points to an
> > -   array of ``num_values`` value-name pairs.
> > -
> > --  struct drm_property \*drm_property_create_bitmask(struct
> > -   drm_device \*dev, int flags, const char \*name, const struct
> > -   drm_prop_enum_list \*props, int num_values);
> > -   Create a bitmask property. The ``props`` argument points to an array
> > -   of ``num_values`` value-name pairs.
> > -
> > -Properties can additionally be created as immutable, in which case they
> > -will be read-only for applications but can be modified by the driver. To
> > -create an immutable property drivers must set the
> > -DRM_MODE_PROP_IMMUTABLE flag at property creation time.
> > -
> > -When no array of value-name pairs is readily available at property
> > -creation time for enumerat

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

[Andrea Arcangeli]

On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.

What I should look for when trying those two settings? Will they
successfully fix my problem with intel_backlight with upstream 4.8-rc?

I thought it had to be the same issue as on skylake as I get the
backlight flikering at low frequency but getting brighter and darker
in a cycle lasting a few seconds and I thought there couldn't be too
many other random bugs that ends up with the same side effect.

It looks like the hardware actually broke, software issue isn't the
first thing that comes to mind. As it's hard to imagine a timer in the
kernel reprogramming the backlight setting higher and lower just to
annoy me :). First in fact I thought at a plasma issue, but I tried to
downgrade the kernel first as that was quicker than downgrading
kde/plasma... I initially thought there were two userland daemons
stepping into each other toes.

Another thing is that if I keep decreasing the brightness the screen
eventually goes off and it returns on as I increase the backlight
level again (then low freq flickering starts). With acpi_video0 even
at the lowest brightness setting of 0, it never turns off the screen
completely.

> Doesn't mean there can't be something else wrong with the mode you get
> using a different panel_type. And this makes me wonder what the point is
> in trying to patch up the commit instead of reverting.

Reverting the whole thing would be sure fine with me, I don't know
what the benefits there should be in using intel_backlight instead of
acpi_video0 like the previous code did, but I couldn't imagine too
many hw to behave like this if intel_backlight clearly has to work
stable for someone or it wouldn't exist in the first place.

This is just a "echo " into a backlight file if I tweak the backlight
settings... doesn't sound performance critical stuff to me, ACPI will
do just fine. However I'm not even sure how this problem could surface
in the first place without the kernel continuously reprogramming the
hw values.

[GIT PULL] drm-vc4-next-2016-08-29

[Eric Anholt]

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  https://github.com/anholt/linux tags/drm-vc4-next-2016-08-29

for you to fetch changes up to 67f13690f447841fb3d2f952a6e49b2b28ae379b:

  drm/vc4: Don't force new binner overflow allocation per draw. (2016-08-19 
19:36:22 -0700)


This pull request brings in interlaced vblank timing and a 3D
rendering memory/CPU overhead reduction.


Eric Anholt (1):
  drm/vc4: Don't force new binner overflow allocation per draw.

Mario Kleiner (5):
  drm/vc4: Disallow interlaced modes on DPI.
  drm/vc4: Fix handling of interlaced video modes.
  drm/vc4: Reject doublescan modes.
  drm/vc4: Enable precise vblank timestamping for interlaced modes.
  drm/vc4: Enable/Disable vblanks properly in crtc en/disable.

 drivers/gpu/drm/vc4/vc4_crtc.c | 52 +++---
 drivers/gpu/drm/vc4/vc4_dpi.c  | 11 +
 drivers/gpu/drm/vc4/vc4_gem.c  |  4 
 drivers/gpu/drm/vc4/vc4_hdmi.c | 29 +--
 4 files changed, 77 insertions(+), 19 deletions(-)

[GIT PULL] drm-vc4-fixes-2016-08-29

[Eric Anholt]

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  https://github.com/anholt/linux drm-vc4-fixes-2016-08-29

for you to fetch changes up to 552416c146fadc67cd9b53ef7adf88d3381c43a6:

  drm/vc4: Fix oops when userspace hands in a bad BO. (2016-08-19 19:17:39 
-0700)


This pull request brings in fixes for VC4 3D in 4.8, most of which are
covered by testcases.


Eric Anholt (6):
  drm/vc4: Use drm_free_large() on handles to match its allocation.
  drm/vc4: Use drm_malloc_ab to fix large rendering jobs.
  drm/vc4: Fix handling of a pm_runtime_get_sync() success case.
  drm/vc4: Free hang state before destroying BO cache.
  drm/vc4: Fix overflow mem unreferencing when the binner runs dry.
  drm/vc4: Fix oops when userspace hands in a bad BO.

 drivers/gpu/drm/vc4/vc4_drv.c |  6 +++---
 drivers/gpu/drm/vc4/vc4_drv.h |  9 +
 drivers/gpu/drm/vc4/vc4_gem.c | 18 +-
 drivers/gpu/drm/vc4/vc4_irq.c |  4 +++-
 4 files changed, 24 insertions(+), 13 deletions(-)

[Bug 97513] clover reports wrong device pointer size

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

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

Vedran Miletić  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |vedran at miletic.net
   |.org|
 QA Contact|dri-devel at lists.freedesktop |vedran at miletic.net
   |.org|

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

[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes

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

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

--- Comment #17 from Marek Olšák  ---
It should be fixed in master already.

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

[Bug 91969] [radeonsi][bonaire] Stalls with Borderlands 2

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

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

Vedran Miletić  changed:

   What|Removed |Added

 Blocks||77449


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/14bd2532/attachment.html>

[Bug 95308] [radeonsi] Hangs after some minutes on Team Fortress 2

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

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

Vedran Miletić  changed:

   What|Removed |Added

 Blocks||77449


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/5e8abd78/attachment.html>

[Bug 97340] [radeonsi] POSTAL 2 freezes during shader compilation

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

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

Vedran Miletić  changed:

   What|Removed |Added

 Blocks||77449


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/8138f61a/attachment.html>

[Bug 97340] [radeonsi] POSTAL 2 freezes during shader compilation

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

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

Vedran Miletić  changed:

   What|Removed |Added

Summary|POSTAL 2 poor performance   |[radeonsi] POSTAL 2 freezes
   |at certain times, RadeonSI  |during shader compilation
   |driver  |

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

[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes

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

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

Vedran Miletić  changed:

   What|Removed |Added

 CC||vedran at miletic.net

--- Comment #16 from Vedran Miletić  ---
(In reply to Marek Olšák from comment #15)
> I'm working on it.

Any news?

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

[PATCH] drm/amdgpu: Add amdkfd softdep

[Michal Marek]

On 2016-08-29 03:37, Michel Dänzer wrote:
> On 26/08/16 06:16 PM, Michal Marek wrote:
>> It's a soft dependency, so it will be silently ignored. /sbin/modprobe
>> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies.
> 
> Thanks for the clarification.
> 
> The radeon driver probably needs this as well?

You are right. I sent a v2 covering radeon as well.

Thanks,
Michal

[PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling

[Daniel Vetter]

On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
> drm_kms_helper_poll_enable_locked() should check if we have delayed event
> pending and if we have, schedule the work to run without delay.
> 
> Currently the output_poll_work is only scheduled if any of the connectors
> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
> already registered to be handled. The detection will be delayd by
> DRM_OUTPUT_POLL_PERIOD in any case.
> Furthermore if none of the connectors are marked as POLL_CONNECT or
> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
> always connected: the output_poll_work will not run at all even if we
> have delayed event marked.
> 
> When none of the connectors require polling, their initial status change
> from unknown to connected/disconnected is not going to be handled until
> the first kms application starts or if we have fb console enabled.
> 
> With this change we can react more quickly to output status changes after
> enabling the poll but most importantly it will correct the behavior when
> none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
> are either POLL_HPD or the .polled is 0. The initial status change is going
> to be handled correctly as well.

Don't we need to set delayed_event somewhere too first? At least I don't
really understand how this speeds things up ... The patch itself looks
like a valid bugfix, but the description confuses me a bit. I think if you
delete the above paragraph (starting with "With this change we can react
...") then it's all good.
-Daniel

> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index a0df377d7d1c..f6b64d7d3528 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
> *dev)
>  {
>   bool poll = false;
>   struct drm_connector *connector;
> + unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>  
>   WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>  
> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
> *dev)
>   poll = true;
>   }
>  
> + if (dev->mode_config.delayed_event) {
> + poll = true;
> + delay = 0;
> + }
> +
>   if (poll)
> - schedule_delayed_work(&dev->mode_config.output_poll_work, 
> DRM_OUTPUT_POLL_PERIOD);
> + schedule_delayed_work(&dev->mode_config.output_poll_work, 
> delay);
>  }
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>  
> -- 
> 2.9.3
> 

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

[PATCH v2] amdgpu, radeon: Add amdkfd softdep

[Michal Marek]

Both amdgpu and radeon load amdkfd via symbol_request(). Add a softdep
hint so that userspace knows that each of them needs amdkfd in the
initrd.

Reported-and-tested-by: Martin Jambor  [amdgpu]
Reported-by: Michel Dänzer  [radeon]
Signed-off-by: Michal Marek 
---
v2: Also patch radeon

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
 drivers/gpu/drm/radeon/radeon_drv.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 9aa533cf4ad1..9c469cd311ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index c01a7c6abb49..0a60125c0138 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -617,3 +617,4 @@ module_exit(radeon_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
-- 
2.6.6

[PATCH v2] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

[Daniel Vetter]

On Mon, Aug 29, 2016 at 05:12:03PM +0800, Liu Ying wrote:
> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
> of the helper drm_atomic_helper_commit_planes() if the relevant display
> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
> when the CRTC is disabled. The helper would skip the ->atomic_disable
> call for a plane if the CRTC of the old plane state needs a modesetting
> operation. Of course, the drivers need to disable the planes in their CRTC
> disable callbacks since no one else would do that.
> 
> Suggested-by: Daniel Vetter 
> Cc: Philipp Zabel 
> Cc: David Airlie 
> Cc: Russell King 
> Cc: Peter Senna Tschudin 
> Cc: Lucas Stach 
> Signed-off-by: Liu Ying 

Applied to drm-misc, thanks. I'll send a pull request with it to Dave
later this week to avoid blocking any driver pulls from you side.
-Daniel

> ---
> I choose to pick this patch from the patch set[1] so that I may address
> Daniel Vetter's comments conveniently by sending v2 for it alone.
> 
> [1] http://www.spinics.net/lists/dri-devel/msg116491.html
> 
> v1->v2:
> * Add a newline in the kernel-doc for drm_atomic_helper_commit_planes()
>   to improve readability.
> * Remove unecessary check/warn on crtc_state before passing it over to
>   drm_atomic_crtc_needs_modeset().
> * Wrap plane_funcs->atomic_update with {} to make checkpatch happy.
> 
>  drivers/gpu/drm/arm/malidp_drv.c |  3 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c  | 43 
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c   |  3 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  6 ++--
>  drivers/gpu/drm/msm/msm_atomic.c |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |  3 +-
>  drivers/gpu/drm/sti/sti_drv.c|  2 +-
>  drivers/gpu/drm/tegra/drm.c  |  3 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
>  drivers/gpu/drm/virtio/virtgpu_display.c |  3 +-
>  include/drm/drm_atomic_helper.h  |  6 +++-
>  16 files changed, 59 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 82171d2..c383d72 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_commit_modeset_disables(drm, state);
>   drm_atomic_helper_commit_modeset_enables(drm, state);
> - drm_atomic_helper_commit_planes(drm, state, true);
> + drm_atomic_helper_commit_planes(drm, state,
> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
>  
>   malidp_atomic_commit_hw_done(state);
>  
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index d4a3d61..8e7483d 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct 
> atmel_hlcdc_dc_commit *commit)
>  
>   /* Apply the atomic update. */
>   drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_planes(dev, old_state, false);
> + drm_atomic_helper_commit_planes(dev, old_state, 0);
>   drm_atomic_helper_commit_modeset_enables(dev, old_state);
>  
>   drm_atomic_helper_wait_for_vblanks(dev, old_state);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5f82290..6fdd7ba 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
>   *
>   * drm_atomic_helper_commit_modeset_enables(dev, state);
>   *
> - * drm_atomic_helper_commit_planes(dev, state, true);
> + * drm_atomic_helper_commit_planes(dev, state,
> + * DRM_PLANE_COMMIT_ACTIVE_ONLY);
>   *
>   * for committing the atomic update to hardware.  See the kerneldoc entries 
> for
>   * these three functions for more details.
> @@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_commit_modeset_disables(dev, state);
>  
> - drm_atomic_helper_commit_planes(dev, state, false);
> + drm_atomic_helper_commit_planes(dev, state, 0);
>  
>   drm_atomic_helper_commit_modeset_enables(dev, state);
>  
> @@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state)
>   * drm_atomic_helper_commit_planes - commit plane state
>   * @dev: DRM device
>   * @old_state: atomic state object with old state structures
> 

[PATCH] drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y

[Daniel Vetter]

On Mon, Aug 29, 2016 at 02:34:07PM +0200, Arnd Bergmann wrote:
> When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
> in which some DRM drivers are built-in, but the framebuffer core is a
> loadable module. This results in a link error, such as:
> 
> drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
> radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to 
> `remove_conflicting_framebuffers'
> drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe':
> amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to 
> `remove_conflicting_framebuffers'
> drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init':
> mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to 
> `remove_conflicting_framebuffers'
> drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe':
> mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to 
> `remove_conflicting_framebuffers'
> Makefile:969: recipe for target 'vmlinux' failed
> 
> This changes the compile-time check to IS_REACHABLE, which means we end up
> not calling remove_conflicting_framebuffers() in the configuration, which
> seems good enough, as we know that no framebuffer driver is loaded by the
> time that the built-in DRM driver calls remove_conflicting_framebuffers.
> 
> We could alternatively avoid the link error by forcing CONFIG_FB to not
> be a module in this case, but that wouldn't change anything at runtime,
> and just make the already convoluted set of dependencies worse here.
> 
> I could not find out what happens if the fbdev driver gets loaded as
> a module after the DRM driver is already initialized, but that is a case
> that can happen with or without this patch.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 0a3bfe29f816 ("drm/fb-helper: Fix the dummy 
> remove_conflicting_framebuffers")

Applied to drm-misc, thanks.
-Daniel

> ---
>  include/drm/drm_fb_helper.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index edc6cfd3aa34..797fb5f80c45 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -491,7 +491,7 @@ static inline int
>  drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary)
>  {
> -#if IS_ENABLED(CONFIG_FB)
> +#if IS_REACHABLE(CONFIG_FB)
>   return remove_conflicting_framebuffers(a, name, primary);
>  #else
>   return 0;
> -- 
> 2.9.0
> 

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

[PATCH] drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y

[Arnd Bergmann]

When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
in which some DRM drivers are built-in, but the framebuffer core is a
loadable module. This results in a link error, such as:

drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to 
`remove_conflicting_framebuffers'
drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe':
amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to 
`remove_conflicting_framebuffers'
drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init':
mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to 
`remove_conflicting_framebuffers'
drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe':
mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to 
`remove_conflicting_framebuffers'
Makefile:969: recipe for target 'vmlinux' failed

This changes the compile-time check to IS_REACHABLE, which means we end up
not calling remove_conflicting_framebuffers() in the configuration, which
seems good enough, as we know that no framebuffer driver is loaded by the
time that the built-in DRM driver calls remove_conflicting_framebuffers.

We could alternatively avoid the link error by forcing CONFIG_FB to not
be a module in this case, but that wouldn't change anything at runtime,
and just make the already convoluted set of dependencies worse here.

I could not find out what happens if the fbdev driver gets loaded as
a module after the DRM driver is already initialized, but that is a case
that can happen with or without this patch.

Signed-off-by: Arnd Bergmann 
Fixes: 0a3bfe29f816 ("drm/fb-helper: Fix the dummy 
remove_conflicting_framebuffers")
---
 include/drm/drm_fb_helper.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index edc6cfd3aa34..797fb5f80c45 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -491,7 +491,7 @@ static inline int
 drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
  const char *name, bool primary)
 {
-#if IS_ENABLED(CONFIG_FB)
+#if IS_REACHABLE(CONFIG_FB)
return remove_conflicting_framebuffers(a, name, primary);
 #else
return 0;
-- 
2.9.0

[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)

[Gustavo Padovan]

Hi Chris,

2016-08-29 Chris Wilson :

> If we being polled with a timeout of zero, a nonblocking busy query,
> we don't need to install any fence callbacks as we will not be waiting.
> As we only install the callback once, the overhead comes from the atomic
> bit test that also causes serialisation between threads.
> 
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Gustavo Padovan 
> Cc: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> ---
>  drivers/dma-buf/sync_file.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Indeed, we can shortcut this.

Reviewed-by: Gustavo Padovan 

Gustavo

Kernel Freeze with American Megatrends BIOS

[Bjorn Helgaas]

On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
> Hi Bjorn,
> 
> I am using the bbswitch kernel module to switch off/on the GPU and
> to obtain the GPU power state.
> Obtaining the GPU state immediately after starting the graphical user
> session freezes the system.
> 
> This code triggers something, which is responsible for the freeze.
> 
> ---
> // Returns 1 if the card is disabled, 0 if enabled
> static int is_card_disabled(void) {
> u32 cfg_word;
> // read first config word which contains Vendor and Device ID. If all bits
> // are enabled, the device is assumed to be off
> pci_read_config_dword(dis_dev, 0, &cfg_word);
> // if one of the bits is not enabled (the card is enabled), the inverted
> // result will be non-zero and hence logical not will make it 0 ("false")
> return !~cfg_word;
> }
> 
> static int bbswitch_proc_show(struct seq_file *seqfp, void *p) {
> // show the card state. Example output: :01:00:00 ON
> dis_dev_get();
> seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev),
>  is_card_disabled() ? "OFF" : "ON");
> dis_dev_put();
> return 0;
> }
> ---
> 
> Either dis_dev_get or pci_read_config_dword is the trigger.

What happens if you remove the call to is_card_disabled()?  Does the
system still freeze if you only do the dis_dev_get()/dis_dev_put()?

> Link to the bbswitch module source code:
> https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
> 
> 
> Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
> > [+cc linux-acpi, linux-kernel, dri-devel]
> > 
> > Hi Roland,
> > 
> > I have no idea how to debug this problem.  Are you seeing something
> > that suggests it may be a PCI problem?
> > 
> > On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
> >> Hi,
> >>
> >> hope somebody can help me fix this kernel problem which affects the 
> >> following machines:
> >>
> >> - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are 
> >> also affected)
> >> - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
> >> - Gigabyte P35V5 (i7-6700HQ/GTX 970M)
> >> - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
> >>
> >>
> >> The kernel freezes if the graphical user session (Xorg & Wayland) is
> >> started with a switched off discrete GPU card (NVIDIA).
> >> If the discrete GPU is switched off after the graphical session start,
> >> then everything works as expected, until the graphical session is 
> >> restarted.
> >>
> >> This problem seams to be linked to specific BIOS settings. If the computer
> >> is started with the following command line:
> >>
> >> acpi_osi=! acpi_osi="Windows 2009"
> >>
> >> then the kernel freeze does not occur anymore. However this required a 
> >> special
> >> ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
> >>
> >> https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
> >>
> >> I strongly recommend to fix this in the kernel and I am ready to help and 
> >> solve
> >> this problem with some help.
> >>
> >> Here is a link to the GitHub issue with further information:
> >>
> >> https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-241212595
> >>
> >> Here are some more detailed information:
> >>
> >> https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
> >>
> >> Hope somebody can help.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 97504] Enabling SDMA on CIK (0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes corruption on a mobile Bonaire with AMDGPU DDX / video desktop recording

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

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

--- Comment #1 from Vedran Miletić  ---
It's a long shot, but does
https://lists.freedesktop.org/archives/mesa-dev/2016-August/127318.html fix it?

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

"Fixes" for page flipping under PRIME on AMD & nouveau

[Deucher, Alexander]

> -Original Message-
> From: Michel Dänzer [mailto:michel at daenzer.net]
> Sent: Sunday, August 28, 2016 11:17 PM
> To: Mario Kleiner
> Cc: dri-devel at lists.freedesktop.org; jglisse at redhat.com;
> bskeggs at redhat.com; Deucher, Alexander; airlied at redhat.com
> Subject: Re: "Fixes" for page flipping under PRIME on AMD & nouveau
> 
> On 27/08/16 04:57 AM, Mario Kleiner wrote:
> > On 08/18/2016 04:23 AM, Michel Dänzer wrote:
> >> On 18/08/16 01:12 AM, Mario Kleiner wrote:
> >
> > One thing that confuses me so far is that visual results and measurment
> > suggest it works nicely, properly serializing the rendering/detiling
> > blit and the pageflip. But when i ftrace the Intel drivers
> > reservation_object_wait_timeout_rcu() call where it normally waits for
> > the dmabuf fence to complete then i never see it blocking for more than
> > a few dozen microseconds, and i couldn't find any other place where it
> > blocks on detiling blit completion yet. Iow. it seems to work correctly
> > in practice, but i don't know where it actually blocks.
> 
> It actually doesn't work correctly in all cases yet:
> https://bugs.freedesktop.org/show_bug.cgi?id=95472
> 
> 
> >>> Turns out that prime + page flipping currently doesn't work
> >>> on nouveau and amd. The first offload rendered images from
> >>> the imported dmabufs show up properly, but then the display
> >>> is stuck alternating between the first two or three rendered
> >>> frames.
> >>>
> >>> The problem is that during the pageflip ioctl we pin the
> >>> dmabuf into VRAM in preparation for scanout, then unpin it
> >>> when we are done with it at next flip, but the buffer stays
> >>> in the VRAM memory domain.
> >>
> >> Sounds like you found a bug here: BOs which are being shared between
> >> different GPUs should always be pinned to GTT, moving them to VRAM
> (and
> >> consequently the page flip) should fail.
> >
> > Seems so, although i hoped i was fixing a bug, not exploiting a
> > loophole. In practice i haven't observed trouble with the hack so far. I
> > havent't looked deeply enough into how the dma api below dmabuf
> > operates, so this is just guesswork, but i suspect the reason that this
> > doesn't blow up in an obvious way is that if the render offload gpu
> > exports the dmabuf then the pages get pinned/locked into system RAM,
> so
> > the pages can't move around or get paged out to swap, as long as the
> > dmabuf stays exported. When the dmabuf importing AMD or nouveau
> display
> > gpu then moves the bo from GTT to VRAM (or pseudo-moves it back with
> my
> > hack) all that changes is some pin refcount for the RAM pages, but the
> > refcount always stays non-zero and system RAM isn't freed or moved
> > around during the session. I just wonder if this bug couldn't somehow be
> > turned into a proper feature?
> 
> I'm afraid not; BOs which are being shared between devices are supposed
> to be pinned to GTT, and pinned BOs aren't supposed to move.
> 
> However, something similar to your patches could be done in the DDX
> drivers, using the dedicated scanout pixmap mechanism.
> 
> 
> >> The latest versions of DCE support scanning out from GTT, so that might
> >> be a good solution at least for Carrizo and newer APUs, not sure it
> >> makes sense for dGPUs though.
> >
> > That would be good to have. But that means DCE-11 or later only? What is
> > the constraint on older parts, does it need contiguous memory?
> 
> Presumably. Anyway, from Christian's description it sounds like it'll be
> tricky to get this working even with current APUs. :(

It only works for DCE11 APUs (not dGPUs) using single level page tables for 
gart and has fairly strict alignment requirements.  The watermark setup and 
bandwidth management also have much stricter requirements.  I think DAL has 
most of what is needed in place on the display side assuming the rest of the 
stack provides a buffer with the right alignment.

Alex

[PATCH 1/5] drm/imx: don't call disable_plane in plane destroy path

[Philipp Zabel]

Am Donnerstag, den 11.08.2016, 11:18 +0200 schrieb Lucas Stach:
> When the destroy path is called the plane should already be
> disabled. If not, this is a core bug and should not be worked
> around in the driver.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 4ad67d015ec7..6cc809e1ca55 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -242,7 +242,6 @@ static void ipu_plane_destroy(struct drm_plane *plane)
>  
>   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>  
> - ipu_disable_plane(plane);
>   drm_plane_cleanup(plane);
>   kfree(ipu_plane);
>  }

Applied all 5.

regards
Philipp

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

[Philipp Zabel]

Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> This patch adds active plane reconfiguration support for imx-drm.
> This may fixes some mode setting failure issues which were introduced
> by imx-drm atomic conversion patch set.  The main idea is to disable the
> plane in question in CRTC's atomic_disable operation and then the drm
> atomic core will enable it again automatically.

I have rebased onto drm-misc and picked up the remaining patches (4-7)

regards
Philipp

> v3->v4:
> * Change the bool active_only parameter of commit_planes() to an uint32_t
>   parameter named 'flags' and add two flags - DRM_PLANE_COMMIT_ACTIVE_ONLY
>   and DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET.  This way, the drm atomic
>   core is able to skip the atomic_disable call for the planes which are
>   committed with the NO_DISABLE_AFTER_MODESET flag set.
> * Fix the helper disable_planes_on_crtc(), which is needed for CRTC's
>   atomic_disable callback to disable planes.
> * Improve kernel-doc of CRTC's atomic_disable callback to address Daniel
>   Vetter's comment.
> * Do not wait for DMFC FIFO to clear to avoid timeout warning, as the
>   precedure to disable display channel is changed slightly after the
>   NO_DISABLE_AFTER_MODESET flag is used.
> 
> v2->v3:
> * Disable all appropriate affected planes(when necessary) in CRTC's
>   ->atomic_disable callback, but not in each plane's ->atomic_update callback,
>   as suggested by Daniel Vetter.
> * +Cc Lucas Stach, as he tested the patch v2.
> 
> v1->v2:
> * Do not reject reconfiguring an active overlay plane.
> 
> Liu Ying (7):
>   drm/atomic-helper: Add atomic_disable CRTC helper callback
>   drm/atomic-helper: Disable appropriate planes in
> disable_planes_on_crtc()
>   drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane
> commit
>   gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC
> channel
>   drm/imx: ipuv3-crtc: Use the callback ->atomic_disable instead of
> ->disable
>   drm/imx: Use DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag
>   drm/imx: Add active plane reconfiguration support
> 
>  drivers/gpu/drm/arm/malidp_drv.c |  3 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c  | 64 
> +++-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c   | 30 -
>  drivers/gpu/drm/imx/ipuv3-crtc.c |  8 +++-
>  drivers/gpu/drm/imx/ipuv3-plane.c| 21 ++---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  6 ++-
>  drivers/gpu/drm/msm/msm_atomic.c |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |  3 +-
>  drivers/gpu/drm/sti/sti_drv.c|  2 +-
>  drivers/gpu/drm/tegra/drm.c  |  3 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
>  drivers/gpu/drm/virtio/virtgpu_display.c |  3 +-
>  drivers/gpu/ipu-v3/ipu-dmfc.c| 18 +---
>  include/drm/drm_atomic_helper.h  | 11 +++--
>  include/drm/drm_modeset_helper_vtables.h | 24 +++
>  20 files changed, 146 insertions(+), 65 deletions(-)
> 

[PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling

[Peter Ujfalusi]

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

With this change we can react more quickly to output status changes after
enabling the poll but most importantly it will correct the behavior when
none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
are either POLL_HPD or the .polled is 0. The initial status change is going
to be handled correctly as well.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/drm_probe_helper.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index a0df377d7d1c..f6b64d7d3528 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
*dev)
 {
bool poll = false;
struct drm_connector *connector;
+   unsigned long delay = DRM_OUTPUT_POLL_PERIOD;

WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));

@@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
*dev)
poll = true;
}

+   if (dev->mode_config.delayed_event) {
+   poll = true;
+   delay = 0;
+   }
+
if (poll)
-   schedule_delayed_work(&dev->mode_config.output_poll_work, 
DRM_OUTPUT_POLL_PERIOD);
+   schedule_delayed_work(&dev->mode_config.output_poll_work, 
delay);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);

-- 
2.9.3

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

[Lucas Stach]

Am Freitag, den 26.08.2016, 17:10 +0100 schrieb Russell King - ARM
Linux:
> On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote:
> > The devicetree documentation states that those are required properties,
> > so the driver should refuse to probe if those are absent to be
> > consistent. This will also allow to drop some error checking from the
> > clock enable/disable paths.
> 
> NAK.
> 
> Thanks for reviewing the existing DT files before proposing this change
> and noticing that you're going to wilfully end up breaking existing users.
> A simple grep would have sufficed.
> 
Gah, thanks for pointing this out.

> The DT binding doc is wrong: there is only one documented clock on Dove
> and that's for the GPU core.  (The Dove documentation as far as clocks
> go is very poor.)  So, what's Dove supposed to do - make up some
> ficticious clock?
> 
Core, bus and shader are all module input clocks. If the SoC integration
provides the same clock for all inputs, the DT should reflect this by
supplying the same clock for all 3 inputs.

I'm going to change this patch to keep things working for the Dove DTs,
but I think they really should be changed to supply all 3 input clocks.
I'm sorry for not noticing this when you proposed the Dove GPU DT
support.

Regards,
Lucas

[Bug 97249] R290x combined with Mg279q, Dp link fail in ubuntu-multihead setup.

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

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

Vedran Miletić  changed:

   What|Removed |Added

 CC||vedran at miletic.net

--- Comment #6 from Vedran Miletić  ---
Can you try a newer kernel? 4.7 at least.

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

i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

[Meelis Roos]

Tried 4.8-rc4 on my i5-2400 PC, got this warning:

[   14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   15.847321] [ cut here ]
[   15.847346] WARNING: CPU: 0 PID: 208 at drivers/gpu/drm/i915/intel_pm.c:7866 
sandybridge_pcode_write+0x109/0x1f0 [i915]
[   15.847348] Missing switch case (16) in gen6_check_mailbox_status
[   15.847349] Modules linked in: cpufreq_powersave cpufreq_userspace 
cpufreq_conservative joydev hid_generic usbhid hid x86_pkg_temp_thermal 
kvm_intel kvm irqbypass crc32c_intel aesni_intel snd_hda_codec_realtek 
snd_hda_codec_generic iTCO_wdt i915 aes_x86_64 iTCO_vendor_support glue_helper 
lrw ablk_helper cryptd video i2c_algo_bit drm_kms_helper psmouse pcspkr 
syscopyarea sysfillrect sysimgblt fb_sys_fops ehci_pci ehci_hcd snd_hda_intel 
xhci_pci xhci_hcd e1000e snd_hda_codec snd_hwdep usbcore drm snd_hda_core 
usb_common i2c_i801 ptp pps_core i2c_smbus snd_pcm_oss snd_mixer_oss snd_pcm 
snd_timer evdev snd tpm_tis lpc_ich parport_pc tpm_tis_core mfd_core parport 
nuvoton_cir rc_core tpm soundcore floppy w83627ehf hwmon_vid coretemp hwmon 
eeprom i2c_core loop ip_tables x_tables autofs4
[   15.847395] CPU: 0 PID: 208 Comm: kworker/0:2 Not tainted 4.8.0-rc4 #213
[   15.847396] Hardware name:  /DQ67OW, BIOS 
SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
[   15.847412] Workqueue: events intel_gen6_powersave_work [i915]
[   15.847414]   812d8198 88023191fd70 

[   15.847417]  81056d1e 88022ea4 88023191fdc0 

[   15.847419]  88022ea4a3c8 88022ea487c0 088023e21ba0 
81056d8f
[   15.847422] Call Trace:
[   15.847427]  [] ? dump_stack+0x46/0x5e
[   15.847429]  [] ? __warn+0xbe/0xe0
[   15.847431]  [] ? warn_slowpath_fmt+0x4f/0x60
[   15.847446]  [] ? sandybridge_pcode_write+0x109/0x1f0 
[i915]
[   15.847459]  [] ? intel_gen6_powersave_work+0x2a8/0x1400 
[i915]
[   15.847462]  [] ? process_one_work+0x1eb/0x480
[   15.847465]  [] ? worker_thread+0x47/0x4c0
[   15.847467]  [] ? __schedule+0x1d7/0x660
[   15.847469]  [] ? process_one_work+0x480/0x480
[   15.847472]  [] ? kthread+0xbd/0xe0
[   15.847475]  [] ? ret_from_fork+0x1f/0x40
[   15.847478]  [] ? kthread_worker_fn+0x160/0x160
[   15.847487] ---[ end trace ad9e991297d99be1 ]---

-- 
Meelis Roos (mroos at linux.ee)

[PATCH] fix:overlay: add missing header dependencies

[Arnd Bergmann]

On Sunday, August 28, 2016 1:02:52 PM CEST Baoyou Xie wrote:
> We get 1 warning when build kernel with W=1:
> drivers/gpu/drm/nouveau/dispnv04/overlay.c:496:1: warning: no previous 
> prototype for 'nouveau_overlay_init' [-Wmissing-prototypes]
> 
> In fact, this function is declared in disp.h, so this patch
> add missing header dependencies
> 
> Signed-off-by: Baoyou Xie 
> 

Acked-by: Arnd Bergmann 

a few general notes:

- please use my arnd at arndb.de address on patch submissions, not the linaro
  address.

- for the email subject lines, have a look at what the typical style
  is for the file. "overlay:" is not a good name here because it's not
  unique to the driver, so better use "drm/nouveau", which will also
  get the attention of the right people.

- please drop the "fix:" prefix in the subject.

Arnd

imx-drm: Possible regression after update to atomic

[Ying Liu]

Hi Thorsten,

On Sun, Aug 28, 2016 at 6:17 PM, Thorsten Leemhuis
 wrote:
> Lo! Dave, below report made it to the list of regression for 4.8, but
> afaics nothing happened after the initial report. Was it discussed (and
> maybe even fixed?) elsewhere? Or is there some reason why it shouldn't
> be on the list of regressions at all?

We've got a patch set[1] to fix this.

[1] http://www.spinics.net/lists/dri-devel/msg116491.html

Regards,
Liu Ying

>
> Ciao, Thorsten
>
> On 13.08.2016 14:37, Peter Senna Tschudin wrote:
>>
>> d7868cb7ac58640e9c0383205ba31bd6a985cc6f is the last commit that works for 
>> me. I'm experiencing black screen after Weston starts in two different i.MX 
>> based devices:
>>
>>  - i.MX6 -> arch/arm/boot/dts/imx6q-b850v3.dts
>>  - i.MX53 based device
>>
>> Weston starts, but nothing is shown on screen. fb works fine. Disabling fb 
>> on Kconfig or simply commenting out drm_fbdev_cma_init() solves the black 
>> screen issue.
>>
>> The tests that are causing the black screen:
>>
>> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
>> b/drivers/gpu/drm/imx/ipuv3-plane.c
>> index 4ad67d0..52dc1b7 100644
>> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
>> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
>> @@ -325,7 +325,7 @@ static int ipu_plane_atomic_check(struct drm_plane 
>> *plane,
>> if (old_fb && (state->src_w != old_state->src_w ||
>>   state->src_h != old_state->src_h ||
>>   fb->pixel_format != old_fb->pixel_format))
>> -   return -EINVAL;
>>
>> eba = drm_plane_state_to_eba(state);
>>
>> @@ -336,7 +336,7 @@ static int ipu_plane_atomic_check(struct drm_plane 
>> *plane,
>> return -EINVAL;
>>
>> if (old_fb && fb->pitches[0] != old_fb->pitches[0])
>> -   return -EINVAL;
>>
>> switch (fb->pixel_format) {
>> case DRM_FORMAT_YUV420:
>> @@ -372,7 +372,7 @@ static int ipu_plane_atomic_check(struct drm_plane 
>> *plane,
>> return -EINVAL;
>>
>> if (old_fb && old_fb->pitches[1] != fb->pitches[1])
>> -   return -EINVAL;
>> }
>>
>> I tried to replace the return -EINVAL by crtc_state->mode_changed = true 
>> with no positive results.
>>
>> I'm trying to understand what is the difference with and without fb, but I 
>> have no conclusions yet.
>>
>> Hints on what could be the cause here?
>>
>> Thank you,
>>
>> Peter
>>
>> P.S. This is what I get after replacing the return -EINVAL(the mode is 
>> correct): https://goo.gl/photos/1eRdcco9GpszgvzM8

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

[Philipp Zabel]

Am Montag, den 29.08.2016, 17:57 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel  
> wrote:
> > Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
> >> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel  
> >> wrote:
> >> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> >> >> According to basic tests, it looks there is no issue if we don't wait 
> >> >> for
> >> >> DMFC FIFO to clear when disabling DMFC channel.  NXP BSP doesn't do 
> >> >> that,
> >> >> either.  This patch is needed to avoid the annoying warning caused by a
> >> >> timeout on waiting for the FIFO to clear after we add the new
> >> >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver
> >> >> which changes the procedure to disable display channel slightly.
> >> >
> >> > I suppose the reason this happens is that now DC/DI are disabled first,
> >> > so the DC can't drain the FIFO anymore. If the FIFO is properly reset
> >> > when reenabling the DMFC, this shouldn't have any ill effects.
> >>
> >> I found the timeout warning issue by blanking the framebuffer.
> >> Ofc, the framebuffer is supported by the fbdev emulation.
> >> Before applying this patch set, the planes are not even disabled
> >> when the framebuffer is blanked, that is to say, plane_funcs->
> >> atomic_disable is not called - the CRTC is disabled alone.
> >> After applying this patch set, the planes are always disabled
> >> together with the CRTC.  And, yes, DC/DI are disabled first,
> >> then the timeout warning happens.
> >>
> >> Please note the warning happens when the planes are disabled
> >> instead of reenabled.  So, I don't get your point by resetting
> >> FIFO when _reenabling_  DMFC.
> >
> > If we disable the DMFC with data still in the FIFO and then reenable it
> > and the DC first reads the stale data from the FIFO, that should cause a
> > visible artifact in the first frame after reenabling the plane. If that
> > doesn't happen, I trust that the hardware resets the FIFO state
> > somewhere along the way.
> 
> Not sure if the hardware resets the FIFO automatically...
> The NXP driver waits for some hardware status/irqs when disabling
> the channels, but it doesn't wait for DMFC status.
> 
> >
> >> And, I don't see the way to reset FIFO.
> >
> > We could reset the DMFC_WR memory after disabling the DMFC, but I'm not
> > sure this is necessary at all.
> 
> You mean the register DMFC_WR_CHAN, for instance?
> I still don't see how we could reset the FIFO.

I mean via IPU_MEM_RST. I'll send a patch to illustrate, but as I said,
I don't know if this is really useful.

regards
Philipp

[RFC 2/2] gpu: ipu-v3: reset DMFC memory when disabling

[Philipp Zabel]

Reset the write FIFO memories after disabling the DMFC
to make sure no stale data is kept around.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
index a40f211..e1e5506 100644
--- a/drivers/gpu/ipu-v3/ipu-dmfc.c
+++ b/drivers/gpu/ipu-v3/ipu-dmfc.c
@@ -131,8 +131,10 @@ void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc)

priv->use_count--;

-   if (!priv->use_count)
+   if (!priv->use_count) {
ipu_module_disable(priv->ipu, IPU_CONF_DMFC_EN);
+   ipu_memory_reset(priv->ipu, IPU_RST_MEM_DMFC_WR);
+   }

if (priv->use_count < 0)
priv->use_count = 0;
-- 
2.8.1

[RFC 1/2] gpu: ipu-v3: export memory reset function

[Philipp Zabel]

Add defines for the memory reset bits and export the memory reset
function to IPU modules.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c | 17 +
 drivers/gpu/ipu-v3/ipu-prv.h| 24 
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 5e7af61..1ad33df 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -706,14 +706,14 @@ void ipu_idmac_enable_watermark(struct ipuv3_channel 
*channel, bool enable)
 }
 EXPORT_SYMBOL_GPL(ipu_idmac_enable_watermark);

-static int ipu_memory_reset(struct ipu_soc *ipu)
+int ipu_memory_reset(struct ipu_soc *ipu, u32 rst_mem)
 {
unsigned long timeout;

-   ipu_cm_write(ipu, 0x807F, IPU_MEM_RST);
+   ipu_cm_write(ipu, rst_mem | IPU_RST_MEM_START, IPU_MEM_RST);

timeout = jiffies + msecs_to_jiffies(1000);
-   while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
+   while (ipu_cm_read(ipu, IPU_MEM_RST) & IPU_RST_MEM_START) {
if (time_after(jiffies, timeout))
return -ETIME;
cpu_relax();
@@ -1363,7 +1363,16 @@ static int ipu_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to reset: %d\n", ret);
goto out_failed_reset;
}
-   ret = ipu_memory_reset(ipu);
+   ret = ipu_memory_reset(ipu, IPU_RST_MEM_SRM | IPU_RST_MEM_ALPHA |
+  IPU_RST_MEM_CPMEM | IPU_RST_MEM_TPM |
+  IPU_RST_MEM_MPM | IPU_RST_MEM_BM |
+  IPU_RST_MEM_RM | IPU_RST_MEM_DSTM |
+  IPU_RST_MEM_DSOM | IPU_RST_MEM_LUT0 |
+  IPU_RST_MEM_LUT1 | IPU_RST_MEM_RAM_SMFC |
+  IPU_RST_MEM_VDI_FIFO2 | IPU_RST_MEM_VDI_FIFO3 |
+  IPU_RST_MEM_ICB | IPU_RST_MEM_VDI_FIFO1 |
+  IPU_RST_MEM_DC_TEMPLATE | IPU_RST_MEM_DMFC_RD |
+  IPU_RST_MEM_DMFC_WR);
if (ret)
goto out_failed_reset;
 #endif
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index 6803cc7..8e9ef56 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -75,6 +75,28 @@ struct ipu_soc;
 #define IPU_INT_CTRL(n)IPU_CM_REG(0x003C + 4 * (n))
 #define IPU_INT_STAT(n)IPU_CM_REG(0x0200 + 4 * (n))

+#define IPU_RST_MEM_SRMBIT(0)
+#define IPU_RST_MEM_ALPHA  BIT(1)
+#define IPU_RST_MEM_CPMEM  BIT(2)
+#define IPU_RST_MEM_TPMBIT(3)
+#define IPU_RST_MEM_MPMBIT(4)
+#define IPU_RST_MEM_BM BIT(5)
+#define IPU_RST_MEM_RM BIT(6)
+#define IPU_RST_MEM_DSTM   BIT(7)
+#define IPU_RST_MEM_DSOM   BIT(8)
+#define IPU_RST_MEM_LUT0   BIT(9)
+#define IPU_RST_MEM_LUT1   BIT(10)
+#define IPU_RST_MEM_RAM_SMFC   BIT(11)
+#define IPU_RST_MEM_VDI_FIFO2  BIT(12)
+#define IPU_RST_MEM_VDI_FIFO3  BIT(13)
+#define IPU_RST_MEM_ICBBIT(14)
+#define IPU_RST_MEM_VDI_FIFO1  BIT(15)
+#define IPU_RST_MEM_DC_TEMPLATEBIT(20)
+#define IPU_RST_MEM_DMFC_RDBIT(21)
+#define IPU_RST_MEM_DMFC_WRBIT(22)
+
+#define IPU_RST_MEM_START  BIT(31)
+
 #define IPU_DI0_COUNTER_RELEASE(1 << 24)
 #define IPU_DI1_COUNTER_RELEASE(1 << 25)

@@ -401,6 +423,8 @@ static inline void ipu_idmac_write(struct ipu_soc *ipu, u32 
value,

 void ipu_srm_dp_sync_update(struct ipu_soc *ipu);

+int ipu_memory_reset(struct ipu_soc *ipu, u32 rst_mem);
+
 int ipu_module_enable(struct ipu_soc *ipu, u32 mask);
 int ipu_module_disable(struct ipu_soc *ipu, u32 mask);

-- 
2.8.1

[PATCH v3] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

[Lyude]

i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.

Simple reproduction recipe:
 - Get a SKL laptop, launch any kind of X session
 - Get two extra monitors
 - Keep hotplugging both displays (so that the display configuration
   jumps from 1 active pipe to 3 active pipes and back)
 - Eventually underrun

Changes since v1:
 - Fix incorrect use of "it's"
Changes since v2:
 - Add reproduction recipe

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
during plane updates")

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 drivers/gpu/drm/i915/intel_sprite.c  | 9 +++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..13e47a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;

-   skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!crtc->primary->state->visible)
+   skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);

I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a..73a521f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct 
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;

-   skl_write_plane_wm(to_intel_crtc(crtc), &dev_priv->wm.skl_results,
-  plane);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!dplane->state->visible)
+   skl_write_plane_wm(to_intel_crtc(crtc),
+  &dev_priv->wm.skl_results, plane);

I915_WRITE(PLANE_CTL(pipe, plane), 0);

-- 
2.7.4

"Fixes" for page flipping under PRIME on AMD & nouveau

[Michel Dänzer]

On 27/08/16 04:57 AM, Mario Kleiner wrote:
> On 08/18/2016 04:23 AM, Michel Dänzer wrote:
>> On 18/08/16 01:12 AM, Mario Kleiner wrote:
> 
> One thing that confuses me so far is that visual results and measurment
> suggest it works nicely, properly serializing the rendering/detiling
> blit and the pageflip. But when i ftrace the Intel drivers
> reservation_object_wait_timeout_rcu() call where it normally waits for
> the dmabuf fence to complete then i never see it blocking for more than
> a few dozen microseconds, and i couldn't find any other place where it
> blocks on detiling blit completion yet. Iow. it seems to work correctly
> in practice, but i don't know where it actually blocks.

It actually doesn't work correctly in all cases yet:
https://bugs.freedesktop.org/show_bug.cgi?id=95472


>>> Turns out that prime + page flipping currently doesn't work
>>> on nouveau and amd. The first offload rendered images from
>>> the imported dmabufs show up properly, but then the display
>>> is stuck alternating between the first two or three rendered
>>> frames.
>>>
>>> The problem is that during the pageflip ioctl we pin the
>>> dmabuf into VRAM in preparation for scanout, then unpin it
>>> when we are done with it at next flip, but the buffer stays
>>> in the VRAM memory domain.
>>
>> Sounds like you found a bug here: BOs which are being shared between
>> different GPUs should always be pinned to GTT, moving them to VRAM (and
>> consequently the page flip) should fail.
> 
> Seems so, although i hoped i was fixing a bug, not exploiting a
> loophole. In practice i haven't observed trouble with the hack so far. I
> havent't looked deeply enough into how the dma api below dmabuf
> operates, so this is just guesswork, but i suspect the reason that this
> doesn't blow up in an obvious way is that if the render offload gpu
> exports the dmabuf then the pages get pinned/locked into system RAM, so
> the pages can't move around or get paged out to swap, as long as the
> dmabuf stays exported. When the dmabuf importing AMD or nouveau display
> gpu then moves the bo from GTT to VRAM (or pseudo-moves it back with my
> hack) all that changes is some pin refcount for the RAM pages, but the
> refcount always stays non-zero and system RAM isn't freed or moved
> around during the session. I just wonder if this bug couldn't somehow be
> turned into a proper feature?

I'm afraid not; BOs which are being shared between devices are supposed
to be pinned to GTT, and pinned BOs aren't supposed to move.

However, something similar to your patches could be done in the DDX
drivers, using the dedicated scanout pixmap mechanism.


>> The latest versions of DCE support scanning out from GTT, so that might
>> be a good solution at least for Carrizo and newer APUs, not sure it
>> makes sense for dGPUs though.
> 
> That would be good to have. But that means DCE-11 or later only? What is
> the constraint on older parts, does it need contiguous memory?

Presumably. Anyway, from Christian's description it sounds like it'll be
tricky to get this working even with current APUs. :(


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

"Fixes" for page flipping under PRIME on AMD & nouveau

[Michel Dänzer]

On 27/08/16 05:07 AM, Mario Kleiner wrote:
> On 08/18/2016 04:32 AM, Michel Dänzer wrote:
>> On 18/08/16 08:51 AM, Mario Kleiner wrote:
>>>
>>> and the offload gpu imports those and renders into them. That saves
>>> one extra copy, so should be somewhat more efficient.
>>
>> Using two shared buffers actually isn't as efficient as possible wrt
>> inter-GPU bandwidth.
> 
> Out of interest, why? You'd have only one detiling copy VRAM -> RAM?

Yeah, that's basically it. With a single shared buffer, only the parts
which have changed since last time need to be copied between the GPUs;
the slave GPU can copy the other changed parts from its other local
scanout pixmap (with TearFree enabled; note that this isn't quite
implemented yet in our drivers for slave output, but I'm planning to do
it soon). With two shared pixmaps, some changed parts have to be copied
between GPUs several times.


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

[PATCH v2] drm/nouveau/gr: mark gm107_grctx_generate_tpcid() static

[Sean Paul]

On Mon, Aug 29, 2016 at 9:02 AM, Baoyou Xie  wrote:
> We get 1 warning when build kernel with W=1:
> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no previous 
> prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> so this patch marks this function with 'static'.
>

It would make things a lot easier if you either consolidated all of
these static changes into one patch, or released them as a series.

Sean


> Signed-off-by: Baoyou Xie 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
> index 6d3c501..4c4b5ab 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
> @@ -933,7 +933,7 @@ gm107_grctx_generate_attrib(struct gf100_grctx *info)
> }
>  }
>
> -void
> +static void
>  gm107_grctx_generate_tpcid(struct gf100_gr *gr)
>  {
> struct nvkm_device *device = gr->base.engine.subdev.device;
> --
> 2.7.4
>

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

[Russell King - ARM Linux]

On Mon, Aug 29, 2016 at 12:47:20PM +0200, Lucas Stach wrote:
> Core, bus and shader are all module input clocks. If the SoC integration
> provides the same clock for all inputs, the DT should reflect this by
> supplying the same clock for all 3 inputs.

You're making an assertion that we don't know is true.  There is no
evidence that the GC600 has three input clocks.  Just because iMX
Vivante GPUs have three clocks does not mean that all Vivante IP has
three clock inputs.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/2] drm/imx: parallel-display: detach bridge or panel on unbind

[Philipp Zabel]

Don't leave any bridge or panel attached to a stale driver instance
when unbinding, to allow reattachment on a rebind.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/parallel-display.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index f203337..d796ada 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -293,6 +293,11 @@ static void imx_pd_unbind(struct device *dev, struct 
device *master,
 {
struct imx_parallel_display *imxpd = dev_get_drvdata(dev);

+   if (imxpd->bridge)
+   drm_bridge_detach(imxpd->bridge);
+   if (imxpd->panel)
+   drm_panel_detach(imxpd->panel);
+
kfree(imxpd->edid);
 }

-- 
2.8.1

[PATCH 1/2] drm/imx: imx-ldb: detach bridge on unbind

[Philipp Zabel]

Don't leave the bridge attached to a stale driver instance when
unbinding, to allow reattachment on a rebind.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-ldb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 33a7613..b300998 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -745,6 +745,8 @@ static void imx_ldb_unbind(struct device *dev, struct 
device *master,
for (i = 0; i < 2; i++) {
struct imx_ldb_channel *channel = &imx_ldb->channel[i];

+   if (channel->bridge)
+   drm_bridge_detach(channel->bridge);
if (channel->panel)
drm_panel_detach(channel->panel);

-- 
2.8.1

[PATCH] modetest: Adding amdgpu to module list

[Michel Dänzer]

On 26/08/16 11:52 PM, Alex Deucher wrote:
> From: satsahu 
> 
> Signed-off-by: Alex Deucher 
> ---
>  tests/util/kms.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/util/kms.c b/tests/util/kms.c
> index 650b23b..c20134e 100644
> --- a/tests/util/kms.c
> +++ b/tests/util/kms.c
> @@ -127,6 +127,7 @@ const char *util_lookup_connector_type_name(unsigned int 
> type)
>  
>  static const char * const modules[] = {
>   "i915",
> + "amdgpu",
>   "radeon",
>   "nouveau",
>   "vmwgfx",
> 

Reviewed-by: Michel Dänzer 


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

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

[Philipp Zabel]

Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel  
> wrote:
> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> >> According to basic tests, it looks there is no issue if we don't wait for
> >> DMFC FIFO to clear when disabling DMFC channel.  NXP BSP doesn't do that,
> >> either.  This patch is needed to avoid the annoying warning caused by a
> >> timeout on waiting for the FIFO to clear after we add the new
> >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver
> >> which changes the procedure to disable display channel slightly.
> >
> > I suppose the reason this happens is that now DC/DI are disabled first,
> > so the DC can't drain the FIFO anymore. If the FIFO is properly reset
> > when reenabling the DMFC, this shouldn't have any ill effects.
> 
> I found the timeout warning issue by blanking the framebuffer.
> Ofc, the framebuffer is supported by the fbdev emulation.
> Before applying this patch set, the planes are not even disabled
> when the framebuffer is blanked, that is to say, plane_funcs->
> atomic_disable is not called - the CRTC is disabled alone.
> After applying this patch set, the planes are always disabled
> together with the CRTC.  And, yes, DC/DI are disabled first,
> then the timeout warning happens.
> 
> Please note the warning happens when the planes are disabled
> instead of reenabled.  So, I don't get your point by resetting
> FIFO when _reenabling_  DMFC.

If we disable the DMFC with data still in the FIFO and then reenable it
and the DC first reads the stale data from the FIFO, that should cause a
visible artifact in the first frame after reenabling the plane. If that
doesn't happen, I trust that the hardware resets the FIFO state
somewhere along the way.

> And, I don't see the way to reset FIFO.

We could reset the DMFC_WR memory after disabling the DMFC, but I'm not
sure this is necessary at all.

regards
Philipp

Kernel Freeze with American Megatrends BIOS

[Bjorn Helgaas]

[+cc linux-acpi, linux-kernel, dri-devel]

Hi Roland,

I have no idea how to debug this problem.  Are you seeing something
that suggests it may be a PCI problem?

On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
> Hi,
> 
> hope somebody can help me fix this kernel problem which affects the following 
> machines:
> 
> - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also 
> affected)
> - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
> - Gigabyte P35V5 (i7-6700HQ/GTX 970M)
> - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
> 
> 
> The kernel freezes if the graphical user session (Xorg & Wayland) is
> started with a switched off discrete GPU card (NVIDIA).
> If the discrete GPU is switched off after the graphical session start,
> then everything works as expected, until the graphical session is restarted.
> 
> This problem seams to be linked to specific BIOS settings. If the computer
> is started with the following command line:
> 
> acpi_osi=! acpi_osi="Windows 2009"
> 
> then the kernel freeze does not occur anymore. However this required a special
> ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
> 
> https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
> 
> I strongly recommend to fix this in the kernel and I am ready to help and 
> solve
> this problem with some help.
> 
> Here is a link to the GitHub issue with further information:
> 
> https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-241212595
> 
> Here are some more detailed information:
> 
> https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
> 
> Hope somebody can help.

[PATCH/RFC] drm: tilcdc: Evaluate pixelclk-active property from display-timings

[Teresa Remmet]

The pixel clock "polarity" is set for tilcdc panels with
the invert-pxl-clk property. But if we have several display-timings
with different pixel clock setups we need to set the values depending
on the selected display-timing. Check for the pixelclk-active property
and invert the value if invert-pxl-clk is set. The pixelclk-active
is not included in the drm_display_mode and has to be taken from the
drm bus flags.

Signed-off-by: Teresa Remmet 
---
This is probably not the right way to go. As I just took some unused
private flag to pass the bus flags. I appreciate a hint to the right
direction.

Regards,
Teresa

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c  | 13 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c |  1 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 25d6b220..3334dd1 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -305,6 +305,7 @@ static void tilcdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
uint32_t reg, hbp, hfp, hsw, vbp, vfp, vsw;
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
struct drm_framebuffer *fb = crtc->primary->state->fb;
+   bool invert_pxlclk = 0;

if (WARN_ON(!info))
return;
@@ -424,7 +425,17 @@ static void tilcdc_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
reg |= info->fdd < 12;
tilcdc_write(dev, LCDC_RASTER_CTRL_REG, reg);

-   if (info->invert_pxl_clk)
+   /* The invert_pxl_clk property sets up the pixel clock for all available
+* display-timings. But in some cases a per display-timing pixel clock
+* setup is needed. Check the "pixelclk-active" property and invert this
+* value if invert_pxl_clk is set.
+*/
+   if (mode->private_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+   invert_pxlclk = 1;
+
+   invert_pxlclk = (info->invert_pxl_clk ? !invert_pxlclk : invert_pxlclk);
+
+   if (invert_pxlclk)
tilcdc_set(dev, LCDC_RASTER_TIMING_2_REG, 
LCDC_INVERT_PIXEL_CLOCK);
else
tilcdc_clear(dev, LCDC_RASTER_TIMING_2_REG, 
LCDC_INVERT_PIXEL_CLOCK);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 4ac1d25..2e12d871 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -165,6 +165,7 @@ static int panel_connector_get_modes(struct drm_connector 
*connector)
break;

drm_display_mode_from_videomode(&vm, mode);
+   drm_bus_flags_from_videomode(&vm, &(mode->private_flags));

mode->type = DRM_MODE_TYPE_DRIVER;

-- 
1.9.1

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Rob Herring]

On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
> 
> The main purpose of this functionality is to support reading EDID from
> an HDMI monitor on boards, which don't have an I2C bus connected to
> DDC pins.
> 
> The current implementation does not support "I2C Master Interface
> Extended Read Mode" to read data addressed by non-zero segment
> pointer, this means that if EDID has more than 1 extension blocks,
> EDID reading operation won't succeed, in my practice all tested HDMI
> monitors have at maximum one extension block.
> 
> Signed-off-by: Vladimir Zapolskiy 
> ---
> The change is based on top of v4.8.0-rc1 and a fix in DW HDMI driver
> https://patchwork.kernel.org/patch/9284717/
> 
> Changes from v5 to v6:
> * rebased on top of v4.8.0-rc1
> * fixed one improper resource deallocation on error path of dw_hdmi_bind()
> * added a comment describing a mutex asked by checkpatch.pl --strict
> 
> Link to version v5: https://patchwork.kernel.org/patch/7279831/
> 
> Changes from v4 to v5:
> * do I2C bus controller initialization only once in bind() as it was done
>   in v1-v3 of the change.
> 
> Changes from v3 to v4, thanks to Doug and Philipp for review:
> * set speed mode after software reset in dw_hdmi_i2c_init()
> * by default set standard speed mode instead of fast speed mode, on iMX6Q
>   this configures SCL to 100 KHz, which is compliant with HDMI 1.3a spec
> * do I2C bus controller reinitialization on every data transfer,
>   this change hopefully solves some observed problems on RK3288 platform
> * added short functional change description to dw_hdmi.txt
> 
> v3 of the change was
> 
>   Tested-by: Philipp Zabel 
> 
> Changes from v2 to v3, thanks to Russell:
> * moved register field value definitions to dw_hdmi.h
> * made completions uninterruptible to avoid transfer retries if interrupted
> * use one completion for both read and write transfers as in v1,
>   operation_reg is removed
> * redundant i2c->stat = 0 is removed from dw_hdmi_i2c_read/write()
> * struct i2c_algorithm dw_hdmi_algorithm is qualified as const
> * dw_hdmi_i2c_adapter() does not modify struct dw_hdmi on error path
> * dw_hdmi_i2c_irq() does not modify hdmi->i2c->stat, if interrupt is
>   not for I2CM
> * spin lock is removed from dw_hdmi_i2c_irq()
> * removed spin lock from dw_hdmi_i2c_xfer() around write to
>   HDMI_IH_MUTE_I2CM_STAT0 register
> * split loop over message array in dw_hdmi_i2c_xfer() to validation
>   and transfer parts
> * added a mutex to serialize I2C transfer requests, i2c->lock is
>   completely removed
> * removed if(len) check from dw_hdmi_i2c_write(), hardware supports
>   only len>0 transfers
> * described extension blocks <= 1 limitation in the commit message
> * a number of minor clean ups
> 
> Changes from v1 to v2:
> * fixed a devm_kfree() signature
> * split completions for read and write operations
> 
>  .../devicetree/bindings/display/bridge/dw_hdmi.txt |   4 +-

Acked-by: Rob Herring 

>  drivers/gpu/drm/bridge/dw-hdmi.c   | 265 
> -
>  drivers/gpu/drm/bridge/dw-hdmi.h   |  19 ++
>  3 files changed, 281 insertions(+), 7 deletions(-)

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

[Philipp Zabel]

Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> According to basic tests, it looks there is no issue if we don't wait for
> DMFC FIFO to clear when disabling DMFC channel.  NXP BSP doesn't do that,
> either.  This patch is needed to avoid the annoying warning caused by a
> timeout on waiting for the FIFO to clear after we add the new
> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver
> which changes the procedure to disable display channel slightly.

I suppose the reason this happens is that now DC/DI are disabled first,
so the DC can't drain the FIFO anymore. If the FIFO is properly reset
when reenabling the DMFC, this shouldn't have any ill effects.

regards
Philipp

[PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

[Lyude]

i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.

Changes since v1:
 - Fix incorrect use of "it's"

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
during plane updates")

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 drivers/gpu/drm/i915/intel_sprite.c  | 9 +++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..13e47a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;

-   skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!crtc->primary->state->visible)
+   skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);

I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a..73a521f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct 
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;

-   skl_write_plane_wm(to_intel_crtc(crtc), &dev_priv->wm.skl_results,
-  plane);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!dplane->state->visible)
+   skl_write_plane_wm(to_intel_crtc(crtc),
+  &dev_priv->wm.skl_results, plane);

I915_WRITE(PLANE_CTL(pipe, plane), 0);

-- 
2.7.4

[PATCH RFC] drm/tilcdc: Write DMA base and ceiling address with single instruction

[Jyri Sarha]

Write DMA base and ceiling address with a single instruction, if
available. This should make it more unlikely that LCDC would fetch the
DMA addresses in the middle of an update. Having bad combination of
addresses in dma base and ceiling (e.g base > ceiling) can cause
unpredictaple behavior in LCDC.

Signed-off-by: Jyri Sarha 
---
I am not sure what would be the least ugly way of utilizing ARM7 strd
instruction. Using inline assebler would be the most straight forward
way, but this looks less ugly to me.

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  9 +++--
 drivers/gpu/drm/tilcdc/tilcdc_regs.h | 13 +
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 6350f2a..41ec5b3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -70,6 +70,7 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
struct drm_gem_cma_object *gem;
unsigned int depth, bpp;
dma_addr_t start, end;
+   u64 dma_base_and_ceiling;

drm_fb_get_bpp_depth(fb->pixel_format, &depth, &bpp);
gem = drm_fb_cma_get_gem_obj(fb, 0);
@@ -80,8 +81,12 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)

end = start + (crtc->mode.vdisplay * fb->pitches[0]);

-   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, start);
-   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, end - 1);
+   /* Write DMA base and ceiling address with a single insruction,
+* if available. This should make it more unlikely that LCDC would
+* fetch the DMA addresses in the middle of an update.
+*/
+   dma_base_and_ceiling = (u64)(end - 1) << 32 | start;
+   tilcdc_write64(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_base_and_ceiling);

if (tilcdc_crtc->curr_fb)
drm_flip_work_queue(&tilcdc_crtc->unref_work,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 1bf5e25..ea934c9 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -119,6 +119,19 @@ static inline void tilcdc_write(struct drm_device *dev, 
u32 reg, u32 data)
iowrite32(data, priv->mmio + reg);
 }

+static inline void tilcdc_write64(struct drm_device *dev, u32 reg, u64 data)
+{
+   struct tilcdc_drm_private *priv = dev->dev_private;
+   volatile void __iomem *addr = priv->mmio + reg;
+
+#ifdef iowrite64
+   iowrite64(data, addr);
+#else
+   /* This compiles to strd (=64-bit write) on ARM7 */
+   *(volatile u64 __force *)addr = data;
+#endif
+}
+
 static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
-- 
1.9.1

[PATCH] drm/amdgpu: Add amdkfd softdep

[Michel Dänzer]

On 26/08/16 06:16 PM, Michal Marek wrote:
> On 2016-08-26 04:20, Michel Dänzer wrote:
>> On 26/08/16 02:10 AM, Michal Marek wrote:
>>> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
>>> userspace knows that amdgpu needs amdkfd in the initrd.
>>>
>>> Reported-and-tested-by: Martin Jambor 
>>> Signed-off-by: Michal Marek 
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> index 9aa533cf4ad1..9c469cd311ca 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> @@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
>>>  MODULE_AUTHOR(DRIVER_AUTHOR);
>>>  MODULE_DESCRIPTION(DRIVER_DESC);
>>>  MODULE_LICENSE("GPL and additional rights");
>>> +MODULE_SOFTDEP("pre: amdkfd");
>>
>> Will this work if amdkfd isn't built (CONFIG_HSA_AMD=n)?
> 
> It's a soft dependency, so it will be silently ignored. /sbin/modprobe
> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies.

Thanks for the clarification.

The radeon driver probably needs this as well?


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

dri-devel@lists.freedesktop.org

[Daniel Vetter]

- remove kerneldoc for drm-internal functions
- drm_property_replace_global_blob isn't actually atomic, and doesn't
  need to be. Update docs&comments to match
- document all the types and try to link things a bit better
- nits all over

v2: Appease checkpatch in the moved code (Archit)

Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst  |  88 +-
 drivers/gpu/drm/drm_property.c | 153 
 include/drm/drm_property.h | 196 ++---
 3 files changed, 244 insertions(+), 193 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index e07a2667ab61..f9a991bb87d4 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -304,94 +304,12 @@ KMS Locking
 KMS Properties
 ==

-Drivers may need to expose additional parameters to applications than
-those described in the previous sections. KMS supports attaching
-properties to CRTCs, connectors and planes and offers a userspace API to
-list, get and set the property values.
-
-Properties are identified by a name that uniquely defines the property
-purpose, and store an associated value. For all property types except
-blob properties the value is a 64-bit unsigned integer.
-
-KMS differentiates between properties and property instances. Drivers
-first create properties and then create and associate individual
-instances of those properties to objects. A property can be instantiated
-multiple times and associated with different objects. Values are stored
-in property instances, and all other property information are stored in
-the property and shared between all instances of the property.
-
-Every property is created with a type that influences how the KMS core
-handles the property. Supported property types are
-
-DRM_MODE_PROP_RANGE
-Range properties report their minimum and maximum admissible values.
-The KMS core verifies that values set by application fit in that
-range.
-
-DRM_MODE_PROP_ENUM
-Enumerated properties take a numerical value that ranges from 0 to
-the number of enumerated values defined by the property minus one,
-and associate a free-formed string name to each value. Applications
-can retrieve the list of defined value-name pairs and use the
-numerical value to get and set property instance values.
-
-DRM_MODE_PROP_BITMASK
-Bitmask properties are enumeration properties that additionally
-restrict all enumerated values to the 0..63 range. Bitmask property
-instance values combine one or more of the enumerated bits defined
-by the property.
-
-DRM_MODE_PROP_BLOB
-Blob properties store a binary blob without any format restriction.
-The binary blobs are created as KMS standalone objects, and blob
-property instance values store the ID of their associated blob
-object.
-
-Blob properties are only used for the connector EDID property and
-cannot be created by drivers.
-
-To create a property drivers call one of the following functions
-depending on the property type. All property creation functions take
-property flags and name, as well as type-specific arguments.
-
--  struct drm_property \*drm_property_create_range(struct
-   drm_device \*dev, int flags, const char \*name, uint64_t min,
-   uint64_t max);
-   Create a range property with the given minimum and maximum values.
-
--  struct drm_property \*drm_property_create_enum(struct drm_device
-   \*dev, int flags, const char \*name, const struct
-   drm_prop_enum_list \*props, int num_values);
-   Create an enumerated property. The ``props`` argument points to an
-   array of ``num_values`` value-name pairs.
-
--  struct drm_property \*drm_property_create_bitmask(struct
-   drm_device \*dev, int flags, const char \*name, const struct
-   drm_prop_enum_list \*props, int num_values);
-   Create a bitmask property. The ``props`` argument points to an array
-   of ``num_values`` value-name pairs.
-
-Properties can additionally be created as immutable, in which case they
-will be read-only for applications but can be modified by the driver. To
-create an immutable property drivers must set the
-DRM_MODE_PROP_IMMUTABLE flag at property creation time.
-
-When no array of value-name pairs is readily available at property
-creation time for enumerated or range properties, drivers can create the
-property using the :c:func:`drm_property_create()` function and
-manually add enumeration value-name pairs by calling the
-:c:func:`drm_property_add_enum()` function. Care must be taken to
-properly specify the property type through the ``flags`` argument.
-
-After creating properties drivers can attach property instances to CRTC,
-connector and plane objects by calling the
-:c:func:`drm_object_attach_property()`. The function takes a
-pointer to the target object, a pointer to the previously created
-property and an initial instance value.
-
 Property Types an

[PATCH 8/9] drm: Unify handling of blob and object properties

[Daniel Vetter]

They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.

Cc: Daniel Stone 
Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_property.c | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 162cc9032ae5..b5521f705b1c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -911,20 +911,8 @@ bool drm_property_change_valid_get(struct drm_property 
*property,
for (i = 0; i < property->num_values; i++)
valid_mask |= (1ULL << property->values[i]);
return !(value & ~valid_mask);
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
-   struct drm_property_blob *blob;
-
-   if (value == 0)
-   return true;
-
-   blob = drm_property_lookup_blob(property->dev, value);
-   if (blob) {
-   *ref = &blob->base;
-   return true;
-   } else {
-   return false;
-   }
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
+   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB) ||
+  drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
/* a zero value for an object property translates to null: */
if (value == 0)
return true;
@@ -941,13 +929,12 @@ bool drm_property_change_valid_get(struct drm_property 
*property,
 }

 void drm_property_change_valid_put(struct drm_property *property,
-   struct drm_mode_object *ref)
+  struct drm_mode_object *ref)
 {
if (!ref)
return;

-   if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
+   if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT) ||
+   drm_property_type_is(property, DRM_MODE_PROP_BLOB))
drm_mode_object_unreference(ref);
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB))
-   drm_property_unreference_blob(obj_to_blob(ref));
 }
-- 
2.9.3

[PATCH 7/9] drm: Extract drm_property.[hc]

[Daniel Vetter]

This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.

v2: resurrect misplaced hunk (Daniel Stone)

Cc: Daniel Stone 
Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst   |   9 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_crtc.c  | 926 ---
 drivers/gpu/drm/drm_crtc_internal.h |  32 +-
 drivers/gpu/drm/drm_property.c  | 953 
 include/drm/drm_crtc.h  |  88 +---
 include/drm/drm_property.h  | 120 +
 7 files changed, 1102 insertions(+), 1028 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_property.c
 create mode 100644 include/drm/drm_property.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index b164472f2157..e07a2667ab61 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -389,6 +389,15 @@ connector and plane objects by calling the
 pointer to the target object, a pointer to the previously created
 property and an initial instance value.

+Property Types and Blob Property Support
+
+
+.. kernel-doc:: include/drm/drm_property.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_property.c
+   :export:
+
 Blending and Z-Position properties
 --

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8d379565ac8e..439d89b25ae0 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
-   drm_encoder.o drm_mode_object.o
+   drm_encoder.o drm_mode_object.o drm_property.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 59491fc843b6..0fad433f4d2d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1666,932 +1666,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
return drm_mode_cursor_common(dev, req, file_priv);
 }

-static bool drm_property_type_valid(struct drm_property *property)
-{
-   if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
-   return !(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
-   return !!(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
-}
-
-/**
- * drm_property_create - create a new property type
- * @dev: drm device
- * @flags: flags specifying the property type
- * @name: name of the property
- * @num_values: number of pre-defined values
- *
- * This creates a new generic drm property which can then be attached to a drm
- * object with drm_object_attach_property. The returned property object must be
- * freed with drm_property_destroy.
- *
- * Note that the DRM core keeps a per-device list of properties and that, if
- * drm_mode_config_cleanup() is called, it will destroy all properties created
- * by the driver.
- *
- * Returns:
- * A pointer to the newly created property on success, NULL on failure.
- */
-struct drm_property *drm_property_create(struct drm_device *dev, int flags,
-const char *name, int num_values)
-{
-   struct drm_property *property = NULL;
-   int ret;
-
-   property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
-   if (!property)
-   return NULL;
-
-   property->dev = dev;
-
-   if (num_values) {
-   property->values = kcalloc(num_values, sizeof(uint64_t),
-  GFP_KERNEL);
-   if (!property->values)
-   goto fail;
-   }
-
-   ret = drm_mode_object_get(dev, &property->base, 
DRM_MODE_OBJECT_PROPERTY);
-   if (ret)
-   goto fail;
-
-   property->flags = flags;
-   property->num_values = num_values;
-   INIT_LIST_HEAD(&property->enum_list);
-
-   if (name) {
-   strncpy(property->name, name, DRM_PROP_NAME_LEN);
-   property->name[DRM_PROP_NAME_LEN-1] = '\0';
-   }
-
-   list_add_tail(&property->head, &dev->mode_config.property_list);
-
-   WARN_ON(!drm_property_type_valid(property));
-
-   return property;
-fail:
-   kfree(property->values);
-   kfree(property);
-   return NULL;
-}
-EXPORT_SYMBOL(drm_property_create);
-
-/**
- * drm_property_create_enum - create a new enumeration property type
- * @dev: drm device
- * @flags: flags specifying the property type
- * @name: name of the property
- * @props: enumeration lists with property values
- * @num_values: number of pre-defi

[PATCH 6/9] drm: move drm_mode_legacy_fb_format to drm_fourcc.c

[Daniel Vetter]

It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.

Cc: Laurent Pinchart 
Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c   | 43 ---
 drivers/gpu/drm/drm_fourcc.c | 43 +++
 include/drm/drm_crtc.h   |  2 --
 include/drm/drm_fourcc.h |  1 +
 4 files changed, 44 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7ec9f7e7a077..59491fc843b6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1666,49 +1666,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
return drm_mode_cursor_common(dev, req, file_priv);
 }

-/**
- * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
- * @bpp: bits per pixels
- * @depth: bit depth per pixel
- *
- * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
- * Useful in fbdev emulation code, since that deals in those values.
- */
-uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
-{
-   uint32_t fmt;
-
-   switch (bpp) {
-   case 8:
-   fmt = DRM_FORMAT_C8;
-   break;
-   case 16:
-   if (depth == 15)
-   fmt = DRM_FORMAT_XRGB1555;
-   else
-   fmt = DRM_FORMAT_RGB565;
-   break;
-   case 24:
-   fmt = DRM_FORMAT_RGB888;
-   break;
-   case 32:
-   if (depth == 24)
-   fmt = DRM_FORMAT_XRGB;
-   else if (depth == 30)
-   fmt = DRM_FORMAT_XRGB2101010;
-   else
-   fmt = DRM_FORMAT_ARGB;
-   break;
-   default:
-   DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
-   fmt = DRM_FORMAT_XRGB;
-   break;
-   }
-
-   return fmt;
-}
-EXPORT_SYMBOL(drm_mode_legacy_fb_format);
-
 static bool drm_property_type_valid(struct drm_property *property)
 {
if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index c81546c15c93..29c56b4331e0 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -36,6 +36,49 @@ static char printable_char(int c)
 }

 /**
+ * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
+ * @bpp: bits per pixels
+ * @depth: bit depth per pixel
+ *
+ * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
+ * Useful in fbdev emulation code, since that deals in those values.
+ */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+   uint32_t fmt;
+
+   switch (bpp) {
+   case 8:
+   fmt = DRM_FORMAT_C8;
+   break;
+   case 16:
+   if (depth == 15)
+   fmt = DRM_FORMAT_XRGB1555;
+   else
+   fmt = DRM_FORMAT_RGB565;
+   break;
+   case 24:
+   fmt = DRM_FORMAT_RGB888;
+   break;
+   case 32:
+   if (depth == 24)
+   fmt = DRM_FORMAT_XRGB;
+   else if (depth == 30)
+   fmt = DRM_FORMAT_XRGB2101010;
+   else
+   fmt = DRM_FORMAT_ARGB;
+   break;
+   default:
+   DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
+   fmt = DRM_FORMAT_XRGB;
+   break;
+   }
+
+   return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
+/**
  * drm_get_format_name - return a string for drm fourcc format
  * @format: format to compute name of
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b3c3f0c7b449..0c3fa89afd11 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2164,8 +2164,6 @@ extern int drm_mode_crtc_set_gamma_size(struct drm_crtc 
*crtc,

 extern int drm_mode_set_config_internal(struct drm_mode_set *set);

-extern uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
-
 extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device 
*dev,
 char topology[8]);
 extern struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index b106337de1bf..30c30fa87ee8 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,7 @@
 #include 
 #include 

+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
 void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth, int *bpp);
 int drm_format_num_planes(uint32_t format);
 int drm_format_plane_cpp(uint32_t format, int plane);
-- 
2.9.3

[PATCH 5/9] drm/doc: Polish docs for drm_mode_object

[Daniel Vetter]

I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.

v2: Review from Archit:
- Appease checkpatch in moved code.
- Spelling fixes in the kerneldoc.

Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_mode_object.c | 17 +
 include/drm/drm_mode_object.h | 50 ---
 2 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index a92aeed51156..6edda8382a4c 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -97,7 +97,7 @@ void drm_mode_object_register(struct drm_device *dev,
  * for reference counted modeset objects like framebuffers.
  */
 void drm_mode_object_unregister(struct drm_device *dev,
-struct drm_mode_object *object)
+   struct drm_mode_object *object)
 {
mutex_lock(&dev->mode_config.idr_mutex);
if (object->id) {
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(drm_mode_object_find);
  * drm_mode_object_unreference - decr the object refcnt
  * @obj: mode_object
  *
- * This functions decrements the object's refcount if it is a refcounted 
modeset
+ * This function decrements the object's refcount if it is a refcounted modeset
  * object. It is a no-op on any other object. This is used to drop references
  * acquired with drm_mode_object_reference().
  */
@@ -169,7 +169,7 @@ EXPORT_SYMBOL(drm_mode_object_unreference);
  * drm_mode_object_reference - incr the object refcnt
  * @obj: mode_object
  *
- * This functions increments the object's refcount if it is a refcounted 
modeset
+ * This function increments the object's refcount if it is a refcounted modeset
  * object. It is a no-op on any other object. References should be dropped 
again
  * by calling drm_mode_object_unreference().
  */
@@ -218,10 +218,16 @@ EXPORT_SYMBOL(drm_object_attach_property);
  * @property: property to set
  * @val: value the property should be set to
  *
- * This functions sets a given property on a given object. This function only
+ * This function sets a given property on a given object. This function only
  * changes the software state of the property, it does not call into the
  * driver's ->set_property callback.
  *
+ * Note that atomic drivers should not have any need to call this, the core 
will
+ * ensure consistency of values reported back to userspace through the
+ * appropriate ->atomic_get_property callback. Only legacy drivers should call
+ * this function to update the tracked value (after clamping and other
+ * restrictions have been applied).
+ *
  * Returns:
  * Zero on success, error code on failure.
  */
@@ -252,6 +258,9 @@ EXPORT_SYMBOL(drm_object_property_set_value);
  * value this might be out of sync with the hardware, depending upon the driver
  * and property.
  *
+ * Atomic drivers should never call this function directly, the core will read
+ * out property values through the various ->atomic_get_property callbacks.
+ *
  * Returns:
  * Zero on success, error code on failure.
  */
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index b8adb6425f2a..be3d93839ae2 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -27,6 +27,28 @@
 struct drm_object_properties;
 struct drm_property;

+/**
+ * struct drm_mode_object - base structure for modeset objects
+ * @id: userspace visible identifier
+ * @type: type of the object, one of DRM_MODE_OBJECT\_\*
+ * @properties: properties attached to this object, including values
+ * @refcount: reference count for objects which with dynamic lifetime
+ * @free_cb: free function callback, only set for objects with dynamic lifetime
+ *
+ * Base structure for modeset objects visible to userspace. Objects can be
+ * looked up using drm_mode_object_find(). Besides basic uapi interface
+ * properties like @id and @type it provides two services:
+ *
+ * - It tracks attached properties and their values. This is used by &drm_crtc,
+ *   &drm_plane and &drm_connector. Properties are attached by calling
+ *   drm_object_attach_property() before the object is visible to userspace.
+ *
+ * - For objects with dynamic lifetimes (as indicated by a non-NULL @free_cb) 
it
+ *   provides reference counting through drm_mode_object_reference() and
+ *   drm_mode_object_unreference(). This is used by &drm_framebuffer,
+ *   &drm_connector and &drm_property_blob. These objects provide specialized
+ *   reference counting wrappers.
+ */
 struct drm_mode_object {
uint32_t id;
uint32_t type;
@@ -36,16 +58,38 @@ struct drm_mode_object {
 };

 #define DRM_OBJECT_MAX_PROPERTY 24
+/**
+ * struct drm_object_properties - property tracking for &drm_mode_object
+ */
 struct drm_object_properties {
+   /**
+* @count: number of valid properties, must be less than or equal to
+* DRM_OBJECT_MAX_PROPERT

[PATCH 4/9] drm: Remove drm_mode_object->atomic_count

[Daniel Vetter]

It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.

Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_mode_object.c | 31 ---
 include/drm/drm_mode_object.h |  2 +-
 2 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index cef9104e8285..a92aeed51156 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -209,8 +209,6 @@ void drm_object_attach_property(struct drm_mode_object *obj,
obj->properties->properties[count] = property;
obj->properties->values[count] = init_val;
obj->properties->count++;
-   if (property->flags & DRM_MODE_PROP_ATOMIC)
-   obj->properties->atomic_count++;
 }
 EXPORT_SYMBOL(drm_object_attach_property);

@@ -288,35 +286,30 @@ int drm_mode_object_get_properties(struct drm_mode_object 
*obj, bool atomic,
   uint64_t __user *prop_values,
   uint32_t *arg_count_props)
 {
-   int props_count;
-   int i, ret, copied;
+   int i, ret, count;

-   props_count = obj->properties->count;
-   if (!atomic)
-   props_count -= obj->properties->atomic_count;
+   for (i = 0, count = 0; i < obj->properties->count; i++) {
+   struct drm_property *prop = obj->properties->properties[i];
+   uint64_t val;

-   if ((*arg_count_props >= props_count) && props_count) {
-   for (i = 0, copied = 0; copied < props_count; i++) {
-   struct drm_property *prop = 
obj->properties->properties[i];
-   uint64_t val;
-
-   if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
-   continue;
+   if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
+   continue;

+   if (*arg_count_props > count) {
ret = drm_object_property_get_value(obj, prop, &val);
if (ret)
return ret;

-   if (put_user(prop->base.id, prop_ptr + copied))
+   if (put_user(prop->base.id, prop_ptr + count))
return -EFAULT;

-   if (put_user(val, prop_values + copied))
+   if (put_user(val, prop_values + count))
return -EFAULT;
-
-   copied++;
}
+
+   count++;
}
-   *arg_count_props = props_count;
+   *arg_count_props = count;

return 0;
 }
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index c0e4414299f7..b8adb6425f2a 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -37,7 +37,7 @@ struct drm_mode_object {

 #define DRM_OBJECT_MAX_PROPERTY 24
 struct drm_object_properties {
-   int count, atomic_count;
+   int count;
/* NOTE: if we ever start dynamically destroying properties (ie.
 * not at drm_mode_config_cleanup() time), then we'd have to do
 * a better job of detaching property from mode objects to avoid
-- 
2.9.3

[PATCH 3/9] drm: Extract drm_mode_object.[hc]

[Daniel Vetter]

Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.

v2:
- Also move the generic get/set property ioctls. At first this seemed
  like a bad idea since it requires making drm_mode_crtc_set_obj_prop
  non-static. But eventually that will get split away too (like
  the connector version already is) for both crtc and planes. Hence I
  reconsidered.

- drm_mode_object.[hc] instead of drm_modeset.[hc], which requires
  renaming the drm_modeset.h header I already started building up.
  This is more consistent (matches the name of the main structure),
  and I want to be able to use drm_modeset.[hc] for the basic modeset
  init/cleanup functionality like drm_mode_config_init.

Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst|   9 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_crtc.c   | 413 +
 drivers/gpu/drm/drm_crtc_internal.h  |  52 +--
 drivers/gpu/drm/drm_mode_object.c| 435 +++
 include/drm/drm_connector.h  |   2 +-
 include/drm/drm_crtc.h   |  12 +-
 include/drm/drm_encoder.h|   2 +-
 include/drm/drm_framebuffer.h|   2 +-
 include/drm/{drm_modeset.h => drm_mode_object.h} |  10 +
 include/drm/drm_modes.h  |   2 +-
 11 files changed, 492 insertions(+), 449 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_mode_object.c
 rename include/drm/{drm_modeset.h => drm_mode_object.h} (87%)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 47c2835b7c2d..b164472f2157 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -15,6 +15,15 @@ be setup by initializing the following fields.
 -  struct drm_mode_config_funcs \*funcs;
Mode setting functions.

+Modeset Base Object Abstraction
+===
+
+.. kernel-doc:: include/drm/drm_mode_object.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
+   :export:
+
 KMS Data Structures
 ===

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8aa3a7800560..8d379565ac8e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
-   drm_encoder.o
+   drm_encoder.o drm_mode_object.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 389d013dcb36..7ec9f7e7a077 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -57,162 +57,6 @@ static const struct drm_prop_enum_list 
drm_plane_type_enum_list[] = {
 /*
  * Optional properties
  */
-/*
- * Internal function to assign a slot in the object idr and optionally
- * register the object into the idr.
- */
-int drm_mode_object_get_reg(struct drm_device *dev,
-   struct drm_mode_object *obj,
-   uint32_t obj_type,
-   bool register_obj,
-   void (*obj_free_cb)(struct kref *kref))
-{
-   int ret;
-
-   mutex_lock(&dev->mode_config.idr_mutex);
-   ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL, 
1, 0, GFP_KERNEL);
-   if (ret >= 0) {
-   /*
-* Set up the object linking under the protection of the idr
-* lock so that other users can't see inconsistent state.
-*/
-   obj->id = ret;
-   obj->type = obj_type;
-   if (obj_free_cb) {
-   obj->free_cb = obj_free_cb;
-   kref_init(&obj->refcount);
-   }
-   }
-   mutex_unlock(&dev->mode_config.idr_mutex);
-
-   return ret < 0 ? ret : 0;
-}
-
-/**
- * drm_mode_object_get - allocate a new modeset identifier
- * @dev: DRM device
- * @obj: object pointer, used to generate unique ID
- * @obj_type: object type
- *
- * Create a unique identifier based on @ptr in @dev's identifier space.  Used
- * for tracking modes, CRTCs and connectors. Note that despite the _get postfix
- * modeset identifiers are _not_ reference counted. Hence don't use this for
- * reference counted modeset objects like framebuffers.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_mode_object_get(struct drm_device *dev,
-   struct drm_mode_object *obj, uint32_t obj_type)
-{
-   return drm_mode_object_get_reg(dev, obj, obj_type, true, NULL);
-}
-
-void drm_mode

[PATCH 2/9] drm/doc: Polish kerneldoc for encoders

[Daniel Vetter]

- Move missing bits into struct drm_encoder docs.
- Explain that encoders are 95% internal and only 5% uapi, and that in
  general the uapi part is broken.
- Remove verbose comments for functions not exposed to drivers.

v2: Review from Archit:
- Appease checkpatch in the moved code.
- Make it clearer that bridges are not exposed to userspace.

Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst | 46 
 drivers/gpu/drm/drm_encoder.c | 48 ++---
 include/drm/drm_encoder.h | 70 +++
 3 files changed, 101 insertions(+), 63 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 7f788caebea3..47c2835b7c2d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -128,6 +128,12 @@ Connector Functions Reference
 Encoder Abstraction
 ===

+.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
+   :doc: overview
+
+Encoder Functions Reference
+---
+
 .. kernel-doc:: include/drm/drm_encoder.h
:internal:

@@ -207,46 +213,6 @@ future); drivers that do not wish to provide special 
handling for
 primary planes may make use of the helper functions described in ? to
 create and register a primary plane with standard capabilities.

-Encoders (:c:type:`struct drm_encoder `)
--
-
-An encoder takes pixel data from a CRTC and converts it to a format
-suitable for any attached connectors. On some devices, it may be
-possible to have a CRTC send data to more than one encoder. In that
-case, both encoders would receive data from the same scanout buffer,
-resulting in a "cloned" display configuration across the connectors
-attached to each encoder.
-
-Encoder Initialization
-~~
-
-As for CRTCs, a KMS driver must create, initialize and register at least
-one :c:type:`struct drm_encoder ` instance. The
-instance is allocated and zeroed by the driver, possibly as part of a
-larger structure.
-
-Drivers must initialize the :c:type:`struct drm_encoder
-` possible_crtcs and possible_clones fields before
-registering the encoder. Both fields are bitmasks of respectively the
-CRTCs that the encoder can be connected to, and sibling encoders
-candidate for cloning.
-
-After being initialized, the encoder must be registered with a call to
-:c:func:`drm_encoder_init()`. The function takes a pointer to the
-encoder functions and an encoder type. Supported types are
-
--  DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
--  DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
--  DRM_MODE_ENCODER_LVDS for display panels
--  DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
-   Component, SCART)
--  DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
-
-Encoders must be attached to a CRTC to be used. DRM drivers leave
-encoders unattached at initialization time. Applications (or the fbdev
-compatibility layer when implemented) are responsible for attaching the
-encoders they want to use to a CRTC.
-
 Cleanup
 ---

diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index bce781b7bb5f..998a6743a586 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -26,6 +26,30 @@

 #include "drm_crtc_internal.h"

+/**
+ * DOC: overview
+ *
+ * Encoders represent the connecting element between the CRTC (as the overall
+ * pixel pipeline, represented by struct &drm_crtc) and the connectors (as the
+ * generic sink entity, represented by struct &drm_connector). Encoders are
+ * objects exposed to userspace, originally to allow userspace to infer cloning
+ * and connector/CRTC restrictions. Unfortunately almost all drivers get this
+ * wrong, making the uabi pretty much useless. On top of that the exposed
+ * restrictions are too simple for todays hardware, and the recommend way to
+ * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the
+ * atomic IOCTL.
+ *
+ * Otherwise encoders aren't used in the uapi at all (any modeset request from
+ * userspace directly connects a connector with a CRTC), drivers are therefore
+ * free to use them however they wish. Modeset helper libraries make strong use
+ * of encoders to facilitate code sharing. But for more complex settings it is
+ * usually better to move shared code into a separate &drm_bridge. Compared to
+ * encoders bridges also have the benefit of not being purely an internal
+ * abstraction since they are not exposed to userspace at all.
+ *
+ * Encoders are initialized with drm_encoder_init() and cleaned up using
+ * drm_encoder_cleanup().
+ */
 static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
{ DRM_MODE_ENCODER_NONE, "None" },
{ DRM_MODE_ENCODER_DAC, "DAC" },
@@ -71,16 +95,17 @@ void drm_encoder_unregister_all(struct drm_device *dev)
  * @encoder_type: user visible type of the

[PATCH 1/9] drm: Extract drm_encoder.[hc]

[Daniel Vetter]

Same treatment as before. Only hiccup is drm_crtc_mask, which
unfortunately can't be resolved until drm_crtc.h is less of a monster.
Untangle the header loop with a forward declaration for that static
inline.

Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst   |   9 ++
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/drm_crtc.c  | 193 ---
 drivers/gpu/drm/drm_crtc_internal.h |  10 +-
 drivers/gpu/drm/drm_encoder.c   | 220 
 include/drm/drm_crtc.h  | 134 +-
 include/drm/drm_encoder.h   | 167 +++
 7 files changed, 407 insertions(+), 329 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_encoder.c
 create mode 100644 include/drm/drm_encoder.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index fa948b4e029b..7f788caebea3 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -125,6 +125,15 @@ Connector Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:export:

+Encoder Abstraction
+===
+
+.. kernel-doc:: include/drm/drm_encoder.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
+   :export:
+
 KMS Initialization and Cleanup
 ==

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4054c94a2301..8aa3a7800560 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,7 +13,8 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
-   drm_framebuffer.o drm_connector.o drm_blend.o
+   drm_framebuffer.o drm_connector.o drm_blend.o \
+   drm_encoder.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7ebe549051a6..389d013dcb36 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -54,18 +54,6 @@ static const struct drm_prop_enum_list 
drm_plane_type_enum_list[] = {
{ DRM_PLANE_TYPE_CURSOR, "Cursor" },
 };

-static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
-   { DRM_MODE_ENCODER_NONE, "None" },
-   { DRM_MODE_ENCODER_DAC, "DAC" },
-   { DRM_MODE_ENCODER_TMDS, "TMDS" },
-   { DRM_MODE_ENCODER_LVDS, "LVDS" },
-   { DRM_MODE_ENCODER_TVDAC, "TV" },
-   { DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
-   { DRM_MODE_ENCODER_DSI, "DSI" },
-   { DRM_MODE_ENCODER_DPMST, "DP MST" },
-   { DRM_MODE_ENCODER_DPI, "DPI" },
-};
-
 /*
  * Optional properties
  */
@@ -419,117 +407,6 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_cleanup);

-static int drm_encoder_register_all(struct drm_device *dev)
-{
-   struct drm_encoder *encoder;
-   int ret = 0;
-
-   drm_for_each_encoder(encoder, dev) {
-   if (encoder->funcs->late_register)
-   ret = encoder->funcs->late_register(encoder);
-   if (ret)
-   return ret;
-   }
-
-   return 0;
-}
-
-static void drm_encoder_unregister_all(struct drm_device *dev)
-{
-   struct drm_encoder *encoder;
-
-   drm_for_each_encoder(encoder, dev) {
-   if (encoder->funcs->early_unregister)
-   encoder->funcs->early_unregister(encoder);
-   }
-}
-
-/**
- * drm_encoder_init - Init a preallocated encoder
- * @dev: drm device
- * @encoder: the encoder to init
- * @funcs: callbacks for this encoder
- * @encoder_type: user visible type of the encoder
- * @name: printf style format string for the encoder name, or NULL for default 
name
- *
- * Initialises a preallocated encoder. Encoder should be
- * subclassed as part of driver encoder objects.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_encoder_init(struct drm_device *dev,
- struct drm_encoder *encoder,
- const struct drm_encoder_funcs *funcs,
- int encoder_type, const char *name, ...)
-{
-   int ret;
-
-   drm_modeset_lock_all(dev);
-
-   ret = drm_mode_object_get(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
-   if (ret)
-   goto out_unlock;
-
-   encoder->dev = dev;
-   encoder->encoder_type = encoder_type;
-   encoder->funcs = funcs;
-   if (name) {
-   va_list ap;
-
-   va_start(ap, name);
-   encoder->name = kvasprintf(GFP_KERNEL, name, ap);
-   va_end(ap);
-   } else {
-   encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
- 
drm_encoder_enum_list[encoder_type].name,
-   

[PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

[Jose Abreu]

On 29-08-2016 10:21, Russell King - ARM Linux wrote:
> On Mon, Aug 29, 2016 at 10:17:04AM +0100, Jose Abreu wrote:
>> Colorspace and scan information values were being written in wrong
>> offsets. This patch corrects this and writes the values at the
>> offsets specified in the databook.
>>
>> Signed-off-by: Jose Abreu 
>> Acked-by: Russel King 
> That's "Russell King" please.
>

Sorry. Will send again.

Best regards,
Jose Miguel Abreu

[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

[Daniel Vetter]

On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote:
> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
> of the helper drm_atomic_helper_commit_planes() if the relevant display
> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
> when the CRTC is disabled. The helper would skip the ->atomic_disable
> call for a plane if the CRTC of the old plane state needs a modesetting
> operation. Of course, the drivers need to disable the planes in their CRTC
> disable callbacks since no one else would do that.
> 
> Suggested-by: Daniel Vetter 
> Cc: Philipp Zabel 
> Cc: David Airlie 
> Cc: Russell King 
> Cc: Peter Senna Tschudin 
> Cc: Lucas Stach 
> Signed-off-by: Liu Ying 

A few small nits below, otherwise looks good. I merged patches 1&2 into
drm-misc already.

Thanks, Daniel

> ---
> v4:
> * Newly introduced in v4.
> 
>  drivers/gpu/drm/arm/malidp_drv.c |  3 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c  | 46 
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c   |  3 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  6 ++--
>  drivers/gpu/drm/msm/msm_atomic.c |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |  3 +-
>  drivers/gpu/drm/sti/sti_drv.c|  2 +-
>  drivers/gpu/drm/tegra/drm.c  |  3 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
>  drivers/gpu/drm/virtio/virtgpu_display.c |  3 +-
>  include/drm/drm_atomic_helper.h  |  6 +++-
>  16 files changed, 61 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 82171d2..c383d72 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_commit_modeset_disables(drm, state);
>   drm_atomic_helper_commit_modeset_enables(drm, state);
> - drm_atomic_helper_commit_planes(drm, state, true);
> + drm_atomic_helper_commit_planes(drm, state,
> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
>  
>   malidp_atomic_commit_hw_done(state);
>  
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index d4a3d61..8e7483d 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct 
> atmel_hlcdc_dc_commit *commit)
>  
>   /* Apply the atomic update. */
>   drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_planes(dev, old_state, false);
> + drm_atomic_helper_commit_planes(dev, old_state, 0);
>   drm_atomic_helper_commit_modeset_enables(dev, old_state);
>  
>   drm_atomic_helper_wait_for_vblanks(dev, old_state);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 30c52a8..cf19b6e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
>   *
>   * drm_atomic_helper_commit_modeset_enables(dev, state);
>   *
> - * drm_atomic_helper_commit_planes(dev, state, true);
> + * drm_atomic_helper_commit_planes(dev, state,
> + * DRM_PLANE_COMMIT_ACTIVE_ONLY);
>   *
>   * for committing the atomic update to hardware.  See the kerneldoc entries 
> for
>   * these three functions for more details.
> @@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_commit_modeset_disables(dev, state);
>  
> - drm_atomic_helper_commit_planes(dev, state, false);
> + drm_atomic_helper_commit_planes(dev, state, 0);
>  
>   drm_atomic_helper_commit_modeset_enables(dev, state);
>  
> @@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state)
>   * drm_atomic_helper_commit_planes - commit plane state
>   * @dev: DRM device
>   * @old_state: atomic state object with old state structures
> - * @active_only: Only commit on active CRTC if set
> + * @flags: flags for committing plane state
>   *
>   * This function commits the new plane state using the plane and atomic 
> helper
>   * functions for planes and crtcs. It assumes that the atomic state has 
> already
> @@ -1698,25 +1699,33 @@ bool plane_crtc_active(struct drm_plane_state *state)
>   * most drivers don't need to be immediately notified of plane updates for a
>   * disabled CRTC.
>   *
> - * Unless otherwise needed, drivers ar

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

[Jani Nikula]

On Sun, 28 Aug 2016, Andrea Arcangeli  wrote:
> Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> model which is based on IvyBridge.
>
> The commit that introduced the regression is
> 1d6da87a3241deb13d073c4125d19ed0e5a0c62c

That's a merge commit, the real one is

commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä 
Date:   Mon Apr 11 10:23:51 2016 +0300

drm/i915: Get panel_type from OpRegion panel details

> The Skylake workaround for the regression was introduced in commit
> aeddda06c1a704bb97c8a7bfe7a472120193bd56
>
> Signed-off-by: Andrea Arcangeli 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index adca262..ca17ab6 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1073,12 +1073,14 @@ intel_opregion_get_panel_type(struct drm_i915_private 
> *dev_priv)
>   }
>  
>   /*
> -  * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> -  * low vswing for eDP, whereas the VBT panel type (2) gives us normal
> -  * vswing instead. Low vswing results in some display flickers, so
> -  * let's simply ignore the OpRegion panel type on SKL for now.
> +  * FIXME On Dell XPS 13 9350 and Dell XPS 13 L322X the
> +  * OpRegion panel type (0) gives us low vswing for eDP,
> +  * whereas the VBT panel type (2) gives us normal vswing
> +  * instead. Low vswing results in some display flickers, so
> +  * let's simply ignore the OpRegion panel type on SKL and
> +  * IVYBRIDGE for now.
>*/

If it's an Iybridge, there's no low vswing, and that explanation is
false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
on an unpatched kernel.

Doesn't mean there can't be something else wrong with the mode you get
using a different panel_type. And this makes me wonder what the point is
in trying to patch up the commit instead of reverting.


BR,
Jani.



> - if (IS_SKYLAKE(dev_priv)) {
> + if (IS_SKYLAKE(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center