[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

[Bug 92850] Segfault loading War Thunder

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

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

bellamorte42 at gmail.com changed:

   What|Removed |Added

 Attachment #119564|0   |1
is obsolete||

--- Comment #12 from bellamorte42 at gmail.com ---
Created attachment 120003
  --> https://bugs.freedesktop.org/attachment.cgi?id=120003=edit
backtrace

Figured out how to keep my debugging symbols.  New backtrace.

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

[Bug 92953] Segfault loading UT4 map/server

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

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

bellamorte42 at gmail.com changed:

   What|Removed |Added

 Attachment #11|0   |1
is obsolete||

--- Comment #13 from bellamorte42 at gmail.com ---
Created attachment 120002
  --> https://bugs.freedesktop.org/attachment.cgi?id=120002=edit
backtrace

Figured out how to keep my debugging symbols. New backtrace.

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

--- Comment #4 from Paulo Dias  ---
i dont get a lockup with civBE, only a segfault

[ 2657.832332] CivBE[4466]: segfault at 0 ip   (null) sp
eef975dc error 14 in CivBE[8048000+2d0c000]

since steam games dont have any symbols, is it worth it to run it with gdb?

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

[PATCH i915 v4 1/2] i915: wait for fences in mmio_flip()

[Alexander Goins]

Alright, will do.

Thanks,
Alex

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, November 20, 2015 12:21 AM
To: Alexander Goins
Cc: dri-devel at lists.freedesktop.org; daniel at fooishbar.org; daniel at 
ffwll.ch; maarten.lankhorst at linux.intel.com; chris at chris-wilson.co.uk
Subject: Re: [PATCH i915 v4 1/2] i915: wait for fences in mmio_flip()

On Thu, Nov 19, 2015 at 07:51:25PM -0800, Alex Goins wrote:
> If a buffer is backed by dmabuf, wait on its reservation object's 
> fences before flipping.
> 
> Signed-off-by: Alex Goins 

When resending patches please add a per-revision changelog to each patch with 
notes what changed. Otherwise reviewers have to recollect all the context 
themselves by digging through old threads.

Can you please resend with that added?

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b2270d5..4867ff0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -44,6 +44,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /* Primary plane formats for gen <= 3 */  static const uint32_t 
> i8xx_primary_formats[] = { @@ -11088,6 +11090,8 @@ static bool 
> use_mmio_flip(struct intel_engine_cs *ring,
>   return true;
>   else if (i915.enable_execlists)
>   return true;
> + else if (obj->base.dma_buf && obj->base.dma_buf->resv->fence_excl)
> + return true;
>   else
>   return ring != i915_gem_request_get_ring(obj->last_write_req);
>  }
> @@ -11170,8 +11174,18 @@ static void ilk_do_mmio_flip(struct 
> intel_crtc *intel_crtc)  static void intel_do_mmio_flip(struct 
> intel_crtc *intel_crtc)  {
>   struct drm_device *dev = intel_crtc->base.dev;
> + struct intel_framebuffer *intel_fb =
> + to_intel_framebuffer(intel_crtc->base.primary->fb);
> + struct drm_i915_gem_object *obj = intel_fb->obj;
>   u32 start_vbl_count;
>  
> + /* For framebuffer backed by dmabuf, wait for fence */
> + if (obj->base.dma_buf) {
> + reservation_object_wait_timeout_rcu(
> + obj->base.dma_buf->resv,
> + false, true, MAX_SCHEDULE_TIMEOUT);
> + }
> +
>   intel_mark_page_flip_active(intel_crtc);
>  
>   intel_pipe_update_start(intel_crtc, _vbl_count);
> --
> 1.9.1
> 
> 
> --
> - This email message is for the sole use of the intended 
> recipient(s) and may contain confidential information.  Any 
> unauthorized review, use, disclosure or distribution is prohibited.  
> If you are not the intended recipient, please contact the sender by 
> reply email and destroy all copies of the original message.
> --
> -

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

[PATCH i915 v4 1/2] i915: wait for fences in mmio_flip()

[Alexander Goins]

Now that the wait happens before marking page flip active, I guess there's no 
reason not to.

Thanks,
Alex

-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
Sent: Friday, November 20, 2015 3:31 AM
To: Alexander Goins
Cc: dri-devel at lists.freedesktop.org
Subject: Re: [PATCH i915 v4 1/2] i915: wait for fences in mmio_flip()

On Thu, Nov 19, 2015 at 07:51:25PM -0800, Alex Goins wrote:
> If a buffer is backed by dmabuf, wait on its reservation object's 
> fences before flipping.
> 
> Signed-off-by: Alex Goins 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b2270d5..4867ff0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -44,6 +44,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /* Primary plane formats for gen <= 3 */  static const uint32_t 
> i8xx_primary_formats[] = { @@ -11088,6 +11090,8 @@ static bool 
> use_mmio_flip(struct intel_engine_cs *ring,
>   return true;
>   else if (i915.enable_execlists)
>   return true;
> + else if (obj->base.dma_buf && obj->base.dma_buf->resv->fence_excl)
> + return true;
>   else
>   return ring != i915_gem_request_get_ring(obj->last_write_req);
>  }
> @@ -11170,8 +11174,18 @@ static void ilk_do_mmio_flip(struct 
> intel_crtc *intel_crtc)  static void intel_do_mmio_flip(struct 
> intel_crtc *intel_crtc)  {
>   struct drm_device *dev = intel_crtc->base.dev;
> + struct intel_framebuffer *intel_fb =
> + to_intel_framebuffer(intel_crtc->base.primary->fb);
> + struct drm_i915_gem_object *obj = intel_fb->obj;
>   u32 start_vbl_count;
>  
> + /* For framebuffer backed by dmabuf, wait for fence */
> + if (obj->base.dma_buf) {
> + reservation_object_wait_timeout_rcu(
> + obj->base.dma_buf->resv,
> + false, true, MAX_SCHEDULE_TIMEOUT);
> + }
> +

Why is this in do_mmio_flip() rather than next to the normal seqno wait at the 
previous level?

>   intel_mark_page_flip_active(intel_crtc);
>  
>   intel_pipe_update_start(intel_crtc, _vbl_count);
> --
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Ville Syrjälä
Intel OTC

[Bug 93015] Tonga Elemental segfault + VM faults since radeon: implement r600_query_hw_get_result via function pointers

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

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

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #7 from Nicolai Hähnle  ---
Thanks for testing! The patches are in Mesa master, and the bug doesn't affect
any of the stable releases, hence closing it.

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

[Bug 93050] Amdgpu, Tonga "IO_PAGE_FAULT" and "[amdgpu]] *ERROR* amdgpu: ring 0 test failed" result in Kernel Panic

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

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

jk  changed:

   What|Removed |Added

   Priority|medium  |high

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

[Bug 93050] Amdgpu, Tonga "IO_PAGE_FAULT" and "[amdgpu]] *ERROR* amdgpu: ring 0 test failed" result in Kernel Panic

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

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

Bug ID: 93050
   Summary: Amdgpu, Tonga "IO_PAGE_FAULT" and "[amdgpu]] *ERROR*
amdgpu: ring 0 test failed" result in Kernel Panic
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: jahnkohl at web.de

Created attachment 12
  --> https://bugs.freedesktop.org/attachment.cgi?id=12=edit
Logfile

Switched from catalyst to amdgpu, Kernel 4.2 and Kernel 4.3 with powerplay
fixes crash, wenn modesetting is enabled (which just has to be, to get
everything working..) 
When booting without modesetting no Kernel Panic occurs, but just nothing else
works really good...

I'm using Archlinux with mesa/llvm etc build from git.
Kernel 4.2 is Archlinux vanilla kernel, 4.3 is build from
http://cgit.freedesktop.org/~agd5f/linux/?h=amdgpu-powerplay

Log files are attached.I've tried with disabled/enabled Iommu, it think this
Log is with disabled Iommu.

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

[Bug 92953] Segfault loading UT4 map/server

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

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

--- Comment #12 from bellamorte42 at gmail.com ---
Created attachment 11
  --> https://bugs.freedesktop.org/attachment.cgi?id=11=edit
backtrace

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

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Inki Dae]

2015년 11월 20일 19:59에 Inki Dae 이(가) 쓴 글:
> Hi Javier,
> 
> 2015년 11월 20일 00:51에 Javier Martinez Canillas 이(가) 쓴 글:
>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>>>
>>>>
>>>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>>>> Chromebook (tested myself) and seems to be the cause of other Exynos
>>>> boards failing to boot: http://kernelci.org/boot/?exynos
>>>>
>>>> [snip]
>>>>
>>>>>   drm/exynos: add pm_runtime to Mixer
>>>>>   drm/exynos: add pm_runtime to FIMD
>>>>
>>>> I had to revert these patches in order to get the machine in a bootable
>>>> state again, the sha1 hash for these patches in next-20151119 are:
>>>>
>>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD
>>
>> On a closer look, only reverting the FIMD patch is enough
>> to make at least the Exynos5800 Peach Pi to boot again.
> 
> Thanks for report.
> 
> I assume that the issue is because above patch removed 'suspended' variable
> for checking the suspend status in runtime so I revived it.
> 
> I'm not sure that the change could resolve the issue. Could you test it
> with the change again? I have no Exynos5800 Peach Pi board. :(
> 
> For this, I pushed it to below exynos-drm/for-next branch,
>   
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c
> 
> If the issue is resolved by the change then I will modify other patches for
> DECON series. And if really so, there may be a corner case we missed.

Oops, I found out one error at the boot log,
http://storage.kernelci.org/next/next-20151120/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-collabora/boot-exynos5800-peach-pi.html

The boot log says,
[5.754493] vdd_ldo9: supplied by vdd_2v
[5.765510] of_graph_get_next_endpoint(): no port node found in 
/dp-controller at 145B

Seems this error is because exynos5800-peach-pit.dts file doesn't have 'ports' 
node in dp node.

Below is dp node description of exynos5420-peach-pit.dts file.
 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
samsung,dynamic-range = <0>;
samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;

ports {
port at 0 {
dp_out: endpoint {
remote-endpoint = <_in>;
};
};
};
};

And below is for exynos5800-peash-pit.dts,
 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
samsung,dynamic-range = <0>;
samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
panel = <>;
};

Thanks,
Inki Dae

> 
> Thanks,
> Inki Dae
> 
>>
>> Best regards,
>>

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Inki Dae]

Hi Javier,

2015년 11월 20일 00:51에 Javier Martinez Canillas 이(가) 쓴 글:
> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:

>>>
>>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>>> Chromebook (tested myself) and seems to be the cause of other Exynos
>>> boards failing to boot: http://kernelci.org/boot/?exynos
>>>
>>> [snip]
>>>
   drm/exynos: add pm_runtime to Mixer
   drm/exynos: add pm_runtime to FIMD
>>>
>>> I had to revert these patches in order to get the machine in a bootable
>>> state again, the sha1 hash for these patches in next-20151119 are:
>>>
>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD
> 
> On a closer look, only reverting the FIMD patch is enough
> to make at least the Exynos5800 Peach Pi to boot again.

Thanks for report.

I assume that the issue is because above patch removed 'suspended' variable
for checking the suspend status in runtime so I revived it.

I'm not sure that the change could resolve the issue. Could you test it
with the change again? I have no Exynos5800 Peach Pi board. :(

For this, I pushed it to below exynos-drm/for-next branch,

https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c

If the issue is resolved by the change then I will modify other patches for
DECON series. And if really so, there may be a corner case we missed.

Thanks,
Inki Dae

> 
> Best regards,
> 

[PATCH 2/2] amdgpu: Make amdgpu_cs_calculate_timeout() return something sensible on error

[Alex Deucher]

From: Tom St Denis 

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 amdgpu/amdgpu_cs.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index aa594c4..6747158 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -291,8 +291,10 @@ drm_private uint64_t amdgpu_cs_calculate_timeout(uint64_t 
timeout)
struct timespec current;
uint64_t current_ns;
r = clock_gettime(CLOCK_MONOTONIC, );
-   if (r)
-   return r;
+   if (r) {
+   fprintf(stderr, "clock_gettime() returned error (%d)!", 
errno);
+   return AMDGPU_TIMEOUT_INFINITE;
+   }

current_ns = ((uint64_t)current.tv_sec) * 10ull;
current_ns += current.tv_nsec;
-- 
1.8.3.1

[PATCH 1/2] amdgpu: fix overflow for timeout calculation

[Alex Deucher]

From: Jammy Zhou 

Set the timeout to AMDGPU_TIMEOUT_INFINITE when overflow happens

Signed-off-by: Jammy Zhou 
Reviewed-by: Christian König 
---
 amdgpu/amdgpu_cs.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 4da9821..aa594c4 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -289,12 +289,16 @@ drm_private uint64_t amdgpu_cs_calculate_timeout(uint64_t 
timeout)

if (timeout != AMDGPU_TIMEOUT_INFINITE) {
struct timespec current;
+   uint64_t current_ns;
r = clock_gettime(CLOCK_MONOTONIC, );
if (r)
return r;

-   timeout += ((uint64_t)current.tv_sec) * 10ull;
-   timeout += current.tv_nsec;
+   current_ns = ((uint64_t)current.tv_sec) * 10ull;
+   current_ns += current.tv_nsec;
+   timeout += current_ns;
+   if (timeout < current_ns)
+   timeout = AMDGPU_TIMEOUT_INFINITE;
}
return timeout;
 }
-- 
1.8.3.1

[Bug 93017] complete system stalls while changing displays resolutions on a hybrid (intel/radeon) system

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

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

--- Comment #7 from Yaroslav Halchenko  ---
aha -- I think I found what triggered it since I did it again and it stalled
probably identically (didn't have remote console :-/):  I have ran

DISPLAY=:0 0install run -c http://gfxmonk.net/dist/0install/shellshape.xml
--replace

to try shellshape and whenever it finished downloading, it did smth which
triggered the bug, and screens went blank.  Probably it is a different,
although possibly related, issue since during original stalls I still have smth
on the screens.  In this case they just go down into suspend mode etc.  Do you
think I should file a separate report on this one?

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

[Bug 93017] complete system stalls while changing displays resolutions on a hybrid (intel/radeon) system

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

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

Yaroslav Halchenko  changed:

   What|Removed |Added

 CC||debian at onerussian.com

--- Comment #6 from Yaroslav Halchenko  ---
Created attachment 119998
  --> https://bugs.freedesktop.org/attachment.cgi?id=119998=edit
cut/paste terminal output for the 2nd crash: BUG: unable to handle kernel NULL
pointer dereference at 0042

The beast crashed again... I don't remember if I had those before -- just that
screen went off due to inactivity (may be it was also locked -- I was away from
the laptop) and when I came back -- it was stalled.  I had ssh session opened
at  another box watching journalctl -f (nothing in the logs on the drive after
reboot).  The last messages 

Nov 20 12:20:04 hopa kernel: [drm:drm_crtc_helper_set_config] attempting to set
mode from userspace
Nov 20 12:20:04 hopa kernel: [drm:drm_mode_debug_printmodeline] Modeline 57:""
0 296400 3840 3888 3920 4000 1200 1203 1209 1235 0x0 0x5
Nov 20 12:20:04 hopa kernel: [drm:radeon_encoder_set_active_device] setting
active device to 0008 from 0008 0008 for encoder 2
Nov 20 12:20:04 hopa kernel: [drm:drm_crtc_helper_set_mode] [CRTC:29]
Nov 20 12:20:04 hopa kernel: [drm:radeon_atom_encoder_dpms] encoder dpms 30 to
mode 3, devices 0080, active_devices 
Nov 20 12:20:04 hopa kernel: BUG: unable to handle kernel NULL pointer
dereference at 0042

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

Funky new vblank counter regressions in Linux 4.4-rc1

[Ville Syrjälä]

On Fri, Nov 20, 2015 at 04:24:50PM +0100, Mario Kleiner wrote:
> 
> 
> On 11/19/2015 08:45 PM, Ville Syrjälä wrote:
> > On Thu, Nov 19, 2015 at 08:12:24PM +0100, Mario Kleiner wrote:
> >> On 11/19/2015 07:20 PM, Ville Syrjälä wrote:
> >>> On Thu, Nov 19, 2015 at 06:46:28PM +0100, Mario Kleiner wrote:
>  Hi Alex and Michel and Ville,
> 
>  it's "fix vblank stuff" time again ;-)
> 
>  Ville's changes to the DRM's drm_handle_vblank() /
>  drm_update_vblank_count() code in Linux 4.4 not only made that code more
>  elegant, but also removed the robustness against the vblank irq quirks
>  in AMD hw and similar hardware. So now i get tons of off-by-one errors 
>  and
> 
>  "[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip
>  completion event has impossible msc 24803 < target_msc 24804" XOrg
>  messages from that kernel.
> >>>
> >>> Argh. Sorry about that.
> >>>
> >>
> >> On the plus side, your "vblank timestamp deltas as fake vblank counters"
> >> code seems to work nicely on nouveau-kms, as far as testing with three
> >> Nvidia's went so far :). And both Intel gpu's (HD Ironlake, and
> >> Ivybridge) i tested checked out nicely.
> >>
> >> And at least the recent nv50+ NVidia Tesla also have 16 bit vblank
> >> counters which we could implement in nouveau, maybe with the same
> >> trickery to allow long trouble-free vblank off periods, hopefully that
> >> would also apply to the Tegra-4 and later Kepler based parts. Tegra-3
> >> will probably also work. I think i read in the Tegra-3 PRM that the sync
> >> points they use to implement vblank counters do increment at leading
> >> edge of vblank.
> >>
> >> The only problem we may have is that some of the embedded gpus may not
> >> have compliant vblank counters and they probably also lack vblank
> >> timestamping, so it might be a good idea to rather not use vblank
> >> counters at all in those drivers - patch their kms drivers to
> >> max_vblank_count = 0;
> >>
> 
>  One of the reasons for trouble is that AMD hw quirk where the hw fires
>  an extra vblank irq shortly after vblank irq's get enabled, not
>  synchronized to vblank, but typically in the middle of active scanout,
>  so we get a redundant call to drm_handle_vblank in the middle of scanout.
> >>>
> >>> I think that should be fine as such. The code should ignore redudntant
> >>> vbl irqs. Well, assuming you have a reliable hw counter or you use the
> >>> timestamp guesstimate mechanism and your scanout position is reported
> >>> accurately. But I guess you have a bit of problem with both.
> >>>
> >>
> >> The problem is i'll need to treat calls to radeon kms
> >> driver->get_vblank_counter differently, depending if the function gets
> >> called from vblank irq, or from regular code, so that hw quirk that
> >> causes spontaneous misfiring of the vblank irq in the middle of scanout
> >> would confuse my hw vblank counter cooking method to produce a fake hw
> >> vblank counter increment. That's why i moved the filtering for redundant
> >> irqs based on vblank timestamps in drm_vblank_update() around to always
> >> apply. Makes us robust against that type of hw quirk in general and
> >> makes life for the vblank counter cooking so much easier.
> >>
> >> It's a beautiful collaboration of different hw bugs to make things
> >> interesting :)
> >>
> 
>  To fix that i have a minor patch to make drm_update_vblank_count() again
>  robust against such redundant calls, which i will send out later to the
>  mailing list. Diff attached for reference.
> 
>  The second quirk of AMD hw is that the vblank interrupt fires a few
>  scanlines before start of vblank, so drm_handle_vblank ->
>  drm_update_vblank_count() -> dev->driver->get_vblank_counter() gets
>  called before the start of the vblank for which the new vblank count
>  should be queried.
> >>>
> >>> Does it fire too soon, or is the scanout position register value(s)
> >>> just offset by a few lines perhaps?
> >>>
> >>> We have that with i915 and I simply fix up the value when reading it
> >>> out. Fortunately for us the offset is constant (or at least seems to
> >>> be) for a given platform/connector combo.
> >>>
> >>
> >> I think they fire too soon, from all i've seen so far on a few cards.
> >
> > That's unfortunate. Firing a bit too late would be perfectly fine for
> > most things. And that's actually what happens on older intel hw. Firing
> > too soon opens up some more races, as in you may have to wait a bit
> > more after getting woken up to make sure you've crossed into the
> > freame you were waiting for.
> >
> > Also not sure how to deal with that sort of thing in a reasonable way in
> > .get_vblank_timestamp(). DRM_CALLED_FROM_VBLIRQ gets passed there, so it
> > could fudge things a bit when the early irq arrives, but then if someone
> > calls drm_update_vblank_count() after the irq was handled but before
> > start of 

[PATCH v4 06/13] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[Thierry Reding]

.
> +  */

You can use longer lines for comments. No need to split it across three
lines if you can make it fit on two.

> + expire = jiffies + msecs_to_jiffies(120);
> + while (time_before(jiffies, expire))
> + cpu_relax();

Again, cpu_relax() isn't really relaxing the CPU to the extent that it
might lead you to think. If you know you want to sleep for 120 ms, just
do msleep(120).

> +
> + dw_mipi_dsi_set_mode(dsi, DW_MIPI_DSI_CMD_MODE);
> + dw_mipi_dsi_disable(dsi);
> + clk_disable_unprepare(dsi->pclk);
> +
> + if (!IS_ERR(dsi->cfg_clk))
> + clk_disable_unprepare(dsi->cfg_clk);
> +
> + dsi->enabled = false;
> +}
> +
> +static void dw_mipi_dsi_bridge_nope(struct drm_bridge *bridge)

Hehe, perhaps dw_mipi_dsi_bridge_nop()? Or simply leave the function
pointers NULL, but I guess you had to add this because the DRM bridge
infrastructure doesn't allow these to be optional. We might want to
change that.

> +{
> + /* do nothing */
> +}
> +
> +static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi)
> +{
> + dsi_write(dsi, DSI_PWR_UP, RESET);
> + dsi_write(dsi, DSI_PHY_RSTZ, PHY_DISFORCEPLL | PHY_DISABLECLK
> +   | PHY_RSTZ | PHY_SHUTDOWNZ);
> + dsi_write(dsi, DSI_CLKMGR_CFG, TO_CLK_DIVIDSION(10) |
> +   TX_ESC_CLK_DIVIDSION(7));
> + dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
> +}
> +
> +static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi,
> +struct drm_display_mode *mode)
> +{
> + u32 val = 0, calor = 0;

"color"?

> +static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct dw_mipi_dsi *dsi = bridge->driver_private;
> + int ret;
> +
> + dsi->mode = adjusted_mode;
> +
> + ret = dw_mipi_dsi_get_lane_bps(dsi);
> + if (ret < 0)
> + return;
> +
> + if (!IS_ERR(dsi->cfg_clk))
> + clk_prepare_enable(dsi->cfg_clk);
> +
> + clk_prepare_enable(dsi->pclk);

Again, check errors from clk_prepare_enable(), ...

> + dw_mipi_dsi_init(dsi);
> + dw_mipi_dsi_dpi_config(dsi, mode);
> + dw_mipi_dsi_packet_handler_config(dsi);
> + dw_mipi_dsi_video_mode_config(dsi);
> + dw_mipi_dsi_video_packet_config(dsi, mode);
> + dw_mipi_dsi_command_mode_config(dsi);
> + dw_mipi_dsi_line_timer_config(dsi);
> + dw_mipi_dsi_vertical_timing_config(dsi);
> + dw_mipi_dsi_dphy_timing_config(dsi);
> + dw_mipi_dsi_dphy_interface_config(dsi);
> + dw_mipi_dsi_clear_err(dsi);
> + dw_mipi_dsi_phy_init(dsi);
> + dw_mipi_dsi_wait_for_two_frames(dsi);
> + drm_panel_prepare(dsi->panel);

... and drm_panel_prepare().

> +static struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {

static const, please.

> +int dw_mipi_dsi_bind(struct device *dev, struct device *master, void *data,
> +  struct drm_encoder *encoder,
> +  const struct dw_mipi_dsi_plat_data *pdata)
> +{
[...]
> + dsi->cfg_clk = devm_clk_get(dev, "cfg");
> + if (IS_ERR(dsi->cfg_clk))
> + dev_warn(dev, "Have no configuration clock\n");

Is this truly optional?

> + dsi->pclk = devm_clk_get(dev, "pclk");
> + if (IS_ERR(dsi->pclk)) {
> + ret = PTR_ERR(dsi->pclk);
> + dev_err(dev, "Unable to get configuration clock: %d\n", ret);

pclk doesn't seem to be a "configuration clock".

> + dev_info(dev, "version number is 0x%08x\n", val);

Do you really need this information? What purpose does it serve to have
this in the kernel log?

> diff --git a/include/drm/bridge/dw_mipi_dsi.h 
> b/include/drm/bridge/dw_mipi_dsi.h
> new file mode 100644
> index 000..2e351e4
> --- /dev/null
> +++ b/include/drm/bridge/dw_mipi_dsi.h
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2014-2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#ifndef __DW_MIPI_DSI__
> +#define __DW_MIPI_DSI__
> +
> +#include 
> +
> +struct dw_mipi_dsi_plat_data {
> + unsigned int max_data_lanes;
> + enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
> +struct drm_display_mode *mode);
> +};
> +
> +int dw_mipi_dsi_get_encoder_pixel_format(struct drm_encoder *encoder);
> +
> +int dw_mipi_dsi_bind(struct device *dev, struct device *master,
> +  void *data, struct drm_encoder *encoder,
> +  const struct dw_mipi_dsi_plat_data *pdata);
> +void dw_mipi_dsi_unbind(struct device *dev, struct device *master, void 
> *data);
> +#endif   /* __DW_MIPI_DSI__ */

Should have a blank line between the two above.

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

[PATCH v4 03/13] drm/rockchip: return a true clock rate to adjusted_mode

[Mark yao]

On 2015年11月20日 16:15, Chris Zhong wrote:
> Since the mipi dsi driver need to use the clock of vop to make the
> calculation of Blanking. But sometimes the clock driver can not set a
> accurate clock_rate for vop, get it by clk_round_rate before mode_set,
> so we can get the true value.
>
> Signed-off-by: Chris Zhong 
>
> ---
>
> Changes in v4:
> use clk_round_rate to check the clock rate in vop_crtc_mode_fixup
>
> Changes in v3: None
> Changes in v2: None
>
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 5d8ae5e..eff545b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1136,9 +1136,14 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
>   const struct drm_display_mode *mode,
>   struct drm_display_mode *adjusted_mode)
>   {
> + struct vop *vop = to_vop(crtc);
> +
>   if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
>   return false;
>   
> + adjusted_mode->clock =
> + clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
> +
>   return true;
>   }
>   
Looks good for me, so
 Acked-by: Mark Yao 


-- 
ï¼­ark Yao

[PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting.

[Russell King - ARM Linux]

On Fri, Nov 20, 2015 at 04:44:55PM +, Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 04:32:59PM +, Russell King - ARM Linux wrote:
> > On Fri, Nov 20, 2015 at 02:24:04PM +, Liviu Dudau wrote:
> > > On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> > > > On Wed, Nov 11, 2015 at 05:51:52PM +, Russell King - ARM Linux 
> > > > wrote:
> > > > > On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> > > > > > While going through the code testing I've noticed an unbalanced
> > > > > > .unbind missing drm_connector_unregister()
> > > > > 
> > > > > That actually doesn't matter, as DRM automatically tears them down 
> > > > > anyway,
> > > > > so this isn't an urgent change.  However, it's good practice to do so.
> > > > 
> > > > It looks like it doesn't, or at least not if the error code is 
> > > > -EPROBE_DEFER.
> > > > On Juno, where the clocks are provided by SCPI and the load order is not
> > > > guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs 
> > > > entry
> > > > is not cleaned up, so on the next attempt the drm_connector_register() 
> > > > call
> > > > will fail.
> > > > 
> > > > Best regards,
> > > > Liviu
> > > 
> > > Gentle ping. Russell, are you happy with this patchset? If so, would you 
> > > mind
> > > giving me your Acks?
> > 
> > As I'm the maintainer for the driver, I'll merge it, thanks.
> 
> Cheers!
> 
> Do I need to do anything?

The easy way to ensure that it doesn't get forgotten is to put it in my
patch system, just like ARM patches do.  It'll then nag me each time I
look at it (and also means I don't have to save it out, copy it across
to the machine with the git tree on it, and then apply it there...)

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 93015] Tonga Elemental segfault + VM faults since radeon: implement r600_query_hw_get_result via function pointers

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

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

--- Comment #6 from Andy Furniss  ---
Patch one fixes it for me and I can't find any regressions with patch one +
patch two.

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

[PATCH 7/8] drm/i915: Fix random aux transactions failures.

[Rodrigo Vivi]

This read wake with retries were initially added by 2 commits:

commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure")
commit 899526d9 ("drm/i915/dp: try to read receiver capabilities 3 times when 
detecting")

Both mentioning section 9.1 of the 1.1a DisplayPort spec, that actually
tell us to retry three times on certain case when "writing 01h to DPCD address 
600h"
and this code is already in place in our driver. Added by:

commit c7ad3810 ("drm/i915/dp: manage sink power state if possible")

At this point we have no visibility if those patches were added to workaround 
certain
corner cases like lazy dongles or what, but also at that time there wasn't 
enough
retries on the proper places.

So my proposal is to remove these retries for now that we have drm handling the 
retries
and if we face any corner case back again we study it to return EAGAIN or EBUSY
to force retries at drm instead of handling them here.

v2: Improve commit message trying to explain the origin of the retries.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Jesse Barnes 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 95 ++---
 1 file changed, 32 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c87e937..2ce6527 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -985,7 +985,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (WARN_ON(rxsize > 20))
return -E2BIG;

-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize,
+ rxbuf, rxsize);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -3150,47 +3151,16 @@ static void chv_dp_post_pll_disable(struct 
intel_encoder *encoder)
 }

 /*
- * Native read with retry for link status and receiver capability reads for
- * cases where the sink may still be asleep.
- *
- * Sinks are *supposed* to come up within 1ms from an off state, but we're also
- * supposed to retry 3 times per the spec.
- */
-static ssize_t
-intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
-   void *buffer, size_t size)
-{
-   ssize_t ret;
-   int i;
-
-   /*
-* Sometime we just get the same incorrect byte repeated
-* over the entire buffer. Doing just one throw away read
-* initially seems to "solve" it.
-*/
-   drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
-
-   for (i = 0; i < 3; i++) {
-   ret = drm_dp_dpcd_read(aux, offset, buffer, size);
-   if (ret == size)
-   return ret;
-   msleep(1);
-   }
-
-   return ret;
-}
-
-/*
  * Fetch AUX CH registers 0x202 - 0x207 which contain
  * link status information
  */
 bool
 intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
 {
-   return intel_dp_dpcd_read_wake(_dp->aux,
-  DP_LANE0_1_STATUS,
-  link_status,
-  DP_LINK_STATUS_SIZE) == 
DP_LINK_STATUS_SIZE;
+   return drm_dp_dpcd_read(_dp->aux,
+   DP_LANE0_1_STATUS,
+   link_status,
+   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
 }

 /* These are source-specific values. */
@@ -3825,8 +3795,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;

-   if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
-   sizeof(intel_dp->dpcd)) < 0)
+   if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
+sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */

DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
intel_dp->dpcd);
@@ -3837,9 +3807,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
-   intel_dp_dpcd_read_wake(_dp->aux, DP_PSR_SUPPORT,
-   intel_dp->psr_dpcd,
-   sizeof(intel_dp->psr_dpcd));
+   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
+intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
@@ -3850,9 +3820,9 @@ intel_dp_get_dpcd(struct 

[PATCH 7/8] drm/i915: Fix random aux transactions failures.

[Rodrigo Vivi]

Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.

Since drm level was already taking care of retries and didn't want
to through random retries on that level the second solution was to
put the retries at aux_transfer layer what was nacked.

So I realized we had so many retries in different places and
started to organize that a bit. During this organization I noticed
that we weren't handing at all the case were the message size was
zeroed. And this was exactly the case that was affecting sink_crc.

Also we weren't respect BSPec who says this size message = 0 or > 20
are forbidden.

It is a fact that we still have no clue why we are getting this
forbidden value there. But anyway we need to handle that for now
so we return -EBUSY and drm level takes care of the retries that
are already in place.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 35048d6..c87e937 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -905,6 +905,17 @@ done:
/* Unload any bytes sent back from the other side */
recv_bytes = ((status & DP_AUX_CH_CTL_MESSAGE_SIZE_MASK) >>
  DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT);
+
+   /*
+* By BSpec: "Message sizes of 0 or >20 are not allowed."
+* We have no idea of what happened so we return -EBUSY so
+* drm layer takes care for the necessary retries.
+*/
+   if (recv_bytes == 0 || recv_bytes > 20) {
+   ret = -EBUSY;
+   goto out;
+   }
+
if (recv_bytes > recv_size)
recv_bytes = recv_size;

-- 
2.4.3

[PATCH 6/8] drm/i915: Remove remaining retries from intel_dp_aux_ch.

[Rodrigo Vivi]

drm level already takes care of the needed retries so instead of
duplicate the effort here.

If the retry is possible immediately we return EAGAIN. Otherwise,
if we have no idea what caused the error let's assume something
was busy and let drm level handle the wait and retries.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 64 ++---
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a8ba243..35048d6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -795,7 +795,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
uint32_t aux_clock_divider;
int i, ret, recv_bytes;
uint32_t status;
-   int try, clock = 0;
+   int clock = 0;
bool has_aux_irq = HAS_AUX_IRQ(dev);
bool vdd;

@@ -835,41 +835,47 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
  send_bytes,
  aux_clock_divider);

-   /* Must try at least 3 times according to DP spec */
-   for (try = 0; try < 5; try++) {
-   /* Load the send data into the aux channel data 
registers */
-   for (i = 0; i < send_bytes; i += 4)
-   I915_WRITE(intel_dp->aux_ch_data_reg[i >> 2],
-  intel_dp_pack_aux(send + i,
-send_bytes - i));
+   /* Load the send data into the aux channel data registers */
+   for (i = 0; i < send_bytes; i += 4)
+   I915_WRITE(intel_dp->aux_ch_data_reg[i >> 2],
+  intel_dp_pack_aux(send + i,
+send_bytes - i));

-   /* Send the command and wait for it to complete */
-   I915_WRITE(ch_ctl, send_ctl);
+   /* Send the command and wait for it to complete */
+   I915_WRITE(ch_ctl, send_ctl);

-   status = intel_dp_aux_wait_done(intel_dp, has_aux_irq);
+   status = intel_dp_aux_wait_done(intel_dp, has_aux_irq);

-   /* Clear done status and any errors */
-   I915_WRITE(ch_ctl,
-  status |
-  DP_AUX_CH_CTL_DONE |
-  DP_AUX_CH_CTL_TIME_OUT_ERROR |
-  DP_AUX_CH_CTL_RECEIVE_ERROR);
+   /* Clear done status and any errors */
+   I915_WRITE(ch_ctl,
+  status |
+  DP_AUX_CH_CTL_DONE |
+  DP_AUX_CH_CTL_TIME_OUT_ERROR |
+  DP_AUX_CH_CTL_RECEIVE_ERROR);

-   if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
-   continue;
+   if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR) {
+   /*
+* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
+* 400us delay required for errors and timeouts
+* Timeout errors from the HW already meet this
+* requirement so skip to next iteration
+*/
+   ret = -EAGAIN;
+   goto out;
+   }

-   /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
-*   400us delay required for errors and timeouts
-*   Timeout errors from the HW already meet this
-*   requirement so skip to next iteration
+   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
+   /*
+* We don't know what caused the error, so let's
+* return -EBUSY so drm level takes care of
+* the necessary wait for recover and retries
 */
-   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
-   usleep_range(400, 500);
-   continue;
-   }
-   if (status & DP_AUX_CH_CTL_DONE)
-   goto done;
+   ret = -EBUSY;
+   goto out;
}
+
+   if (status & DP_AUX_CH_CTL_DONE)
+   goto done;
}

if ((status & DP_AUX_CH_CTL_DONE) == 0) {
-- 
2.4.3

[PATCH 5/8] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

[Rodrigo Vivi]

EBUSY retries are already in place at drm level.
We don't need to replicate the job here.

v2: rebase on top of EAGAIN x EBUSY retries change at drm.
EBUSY retry at DRM is now handling the msleep(1).

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ed07f0a..a8ba243 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -817,25 +817,9 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,

intel_dp_check_edp(intel_dp);

-   /* Try to wait for any previous AUX channel activity */
-   for (try = 0; try < 3; try++) {
-   status = I915_READ_NOTRACE(ch_ctl);
-   if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   break;
-   msleep(1);
-   }
-
-   if (try == 3) {
-   static u32 last_status = -1;
-   const u32 status = I915_READ(ch_ctl);
-
-   if (status != last_status) {
-   WARN(1, "dp_aux_ch not started status 0x%08x\n",
-status);
-   last_status = status;
-   }
-
-   ret = -EAGAIN;
+   status = I915_READ_NOTRACE(ch_ctl);
+   if ((status & DP_AUX_CH_CTL_SEND_BUSY) != 0) {
+   ret = -EBUSY;
goto out;
}

-- 
2.4.3

[PATCH 4/8] drm: Wait 1ms before retrying aux transactions on EBUSY.

[Rodrigo Vivi]

DP Specs isn't really clear about the amount of retries,
but for cases it mentions retries it also mention times that
vary from 300us to 1ms.

For many cases hardware can handled the timeouts before retry
is possible and allowed, but for many other cases it is better
to wait and give time so the aux channels can recover.

For instance one general case there is when downstream device
is waking up from sleep states generating HPD so it might take
up to 1ms before getting responsive.

I believe with this msleep we could minimize the 32 times retries
and still let Dell monitors happy, but I don't have this monitor
to test here so let's just add the sleep for now and still retry
32 times.

Cc: Dave Airlie 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_dp_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ee7c955..1d6016d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -202,9 +202,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
if (err == -EAGAIN)
continue;

-   /* FIXME: On BUSY we could wait before retrying */
-   if (err == -EBUSY)
+   /* Give a time for aux channels to recover */
+   if (err == -EBUSY) {
+   msleep(1);
continue;
+   }

return err;
}
-- 
2.4.3

[PATCH 3/8] drm/i915: Use EAGAIN instead EBUSY for aux retry.

[Rodrigo Vivi]

Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.

This has no functional change if the EAGAIN support is in
place already for drm aux transfer.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bec443a..ed07f0a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -835,7 +835,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
last_status = status;
}

-   ret = -EBUSY;
+   ret = -EAGAIN;
goto out;
}

@@ -890,7 +890,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,

if ((status & DP_AUX_CH_CTL_DONE) == 0) {
DRM_ERROR("dp_aux_ch not done status 0x%08x\n", status);
-   ret = -EBUSY;
+   ret = -EAGAIN;
goto out;
}

-- 
2.4.3

[PATCH 2/8] drm/nouveau: Use EAGAIN instead EBUSY for aux retry.

[Rodrigo Vivi]

Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.

This has no functional change if the EAGAIN support is in
place already for drm aux transfer.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c   | 4 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
index 954f5b7..a6cd729 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
@@ -52,7 +52,7 @@ g94_i2c_aux_init(struct g94_i2c_aux *aux)
udelay(1);
if (!timeout--) {
AUX_ERR(>base, "begin idle timeout %08x", ctrl);
-   return -EBUSY;
+   return -EAGAIN;
}
} while (ctrl & 0x0301);

@@ -65,7 +65,7 @@ g94_i2c_aux_init(struct g94_i2c_aux *aux)
if (!timeout--) {
AUX_ERR(>base, "magic wait %08x", ctrl);
g94_i2c_aux_fini(aux);
-   return -EBUSY;
+   return -EAGAIN;
}
} while ((ctrl & 0x0300) != urep);

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
index bed231b..6814e5b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
@@ -52,7 +52,7 @@ gm204_i2c_aux_init(struct gm204_i2c_aux *aux)
udelay(1);
if (!timeout--) {
AUX_ERR(>base, "begin idle timeout %08x", ctrl);
-   return -EBUSY;
+   return -EAGAIN;
}
} while (ctrl & 0x0301);

@@ -65,7 +65,7 @@ gm204_i2c_aux_init(struct gm204_i2c_aux *aux)
if (!timeout--) {
AUX_ERR(>base, "magic wait %08x", ctrl);
gm204_i2c_aux_fini(aux);
-   return -EBUSY;
+   return -EAGAIN;
}
} while ((ctrl & 0x0300) != urep);

-- 
2.4.3

[PATCH 1/8] drm: Introduce EAGAIN handling for immediatelly aux retries

[Rodrigo Vivi]

The goal here is to offload aux retries handling from the
drivers to drm.

However there are 2 differents cases for retry:
1. Immediately retry - Hardware already took care of needed timeouts
   before answering that a retry is possible.
2. Busy - Wait some time and retry.

This driver introduce the support for EAGAIN that can handle the
first case and a following patch will introduce EBUSY waits,
after all drivers counting on immediately retries are changed.

Cc: Dave Airlie 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_dp_helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 9535c5b..ee7c955 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -198,6 +198,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
err = aux->transfer(aux, );
mutex_unlock(>hw_mutex);
if (err < 0) {
+   /* Immediately retry */
+   if (err == -EAGAIN)
+   continue;
+
+   /* FIXME: On BUSY we could wait before retrying */
if (err == -EBUSY)
continue;

-- 
2.4.3

[PATCH 0/8] Organize and offload aux retries to drm. (v2)

[Rodrigo Vivi]

The goal of this series is to remove many different retries we have
for aux communication and offload them to drm.

However on first attempt I was only returning EBUSY to use drm retries
but there was no waiting there. So this series also introduce a new
approach on drm level to retry on aux communication failures:

1 - EAGAIN: Immediatelly retry since HW might already taken care of the
needed waitings.
2 - EBUSY: Something is probably busy and we are not getting what we
expected so wait 1ms before trying again so we give time to aux
channels to recover.

Thanks,
Rodrigo.

Rodrigo Vivi (8):
  drm: Introduce EAGAIN handling for immediatelly aux retries
  drm/nouveau: Use EAGAIN instead EBUSY for aux retry.
  drm/i915: Use EAGAIN instead EBUSY for aux retry.
  drm: Wait 1ms before retrying aux transactions on EBUSY.
  drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.
  drm/i915: Remove remaining retries from intel_dp_aux_ch.
  drm/i915: Fix random aux transactions failures.
  drm/i915: Kill intel_dp_dpcd_read_wake

 drivers/gpu/drm/drm_dp_helper.c|   9 +-
 drivers/gpu/drm/i915/intel_dp.c| 192 +
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c   |   4 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c |   4 +-
 4 files changed, 93 insertions(+), 116 deletions(-)

-- 
2.4.3

[PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting.

[Liviu Dudau]

On Fri, Nov 20, 2015 at 04:32:59PM +, Russell King - ARM Linux wrote:
> On Fri, Nov 20, 2015 at 02:24:04PM +, Liviu Dudau wrote:
> > On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> > > On Wed, Nov 11, 2015 at 05:51:52PM +, Russell King - ARM Linux wrote:
> > > > On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> > > > > While going through the code testing I've noticed an unbalanced
> > > > > .unbind missing drm_connector_unregister()
> > > > 
> > > > That actually doesn't matter, as DRM automatically tears them down 
> > > > anyway,
> > > > so this isn't an urgent change.  However, it's good practice to do so.
> > > 
> > > It looks like it doesn't, or at least not if the error code is 
> > > -EPROBE_DEFER.
> > > On Juno, where the clocks are provided by SCPI and the load order is not
> > > guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs 
> > > entry
> > > is not cleaned up, so on the next attempt the drm_connector_register() 
> > > call
> > > will fail.
> > > 
> > > Best regards,
> > > Liviu
> > 
> > Gentle ping. Russell, are you happy with this patchset? If so, would you 
> > mind
> > giving me your Acks?
> 
> As I'm the maintainer for the driver, I'll merge it, thanks.

Cheers!

Do I need to do anything?

Liviu

> 
> -- 
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

[PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting.

[Russell King - ARM Linux]

On Fri, Nov 20, 2015 at 02:24:04PM +, Liviu Dudau wrote:
> On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> > On Wed, Nov 11, 2015 at 05:51:52PM +, Russell King - ARM Linux wrote:
> > > On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> > > > While going through the code testing I've noticed an unbalanced
> > > > .unbind missing drm_connector_unregister()
> > > 
> > > That actually doesn't matter, as DRM automatically tears them down anyway,
> > > so this isn't an urgent change.  However, it's good practice to do so.
> > 
> > It looks like it doesn't, or at least not if the error code is 
> > -EPROBE_DEFER.
> > On Juno, where the clocks are provided by SCPI and the load order is not
> > guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs entry
> > is not cleaned up, so on the next attempt the drm_connector_register() call
> > will fail.
> > 
> > Best regards,
> > Liviu
> 
> Gentle ping. Russell, are you happy with this patchset? If so, would you mind
> giving me your Acks?

As I'm the maintainer for the driver, I'll merge it, thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Funky new vblank counter regressions in Linux 4.4-rc1

[Mario Kleiner]

On 11/19/2015 08:45 PM, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 08:12:24PM +0100, Mario Kleiner wrote:
>> On 11/19/2015 07:20 PM, Ville Syrjälä wrote:
>>> On Thu, Nov 19, 2015 at 06:46:28PM +0100, Mario Kleiner wrote:
 Hi Alex and Michel and Ville,

 it's "fix vblank stuff" time again ;-)

 Ville's changes to the DRM's drm_handle_vblank() /
 drm_update_vblank_count() code in Linux 4.4 not only made that code more
 elegant, but also removed the robustness against the vblank irq quirks
 in AMD hw and similar hardware. So now i get tons of off-by-one errors and

 "[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip
 completion event has impossible msc 24803 < target_msc 24804" XOrg
 messages from that kernel.
>>>
>>> Argh. Sorry about that.
>>>
>>
>> On the plus side, your "vblank timestamp deltas as fake vblank counters"
>> code seems to work nicely on nouveau-kms, as far as testing with three
>> Nvidia's went so far :). And both Intel gpu's (HD Ironlake, and
>> Ivybridge) i tested checked out nicely.
>>
>> And at least the recent nv50+ NVidia Tesla also have 16 bit vblank
>> counters which we could implement in nouveau, maybe with the same
>> trickery to allow long trouble-free vblank off periods, hopefully that
>> would also apply to the Tegra-4 and later Kepler based parts. Tegra-3
>> will probably also work. I think i read in the Tegra-3 PRM that the sync
>> points they use to implement vblank counters do increment at leading
>> edge of vblank.
>>
>> The only problem we may have is that some of the embedded gpus may not
>> have compliant vblank counters and they probably also lack vblank
>> timestamping, so it might be a good idea to rather not use vblank
>> counters at all in those drivers - patch their kms drivers to
>> max_vblank_count = 0;
>>

 One of the reasons for trouble is that AMD hw quirk where the hw fires
 an extra vblank irq shortly after vblank irq's get enabled, not
 synchronized to vblank, but typically in the middle of active scanout,
 so we get a redundant call to drm_handle_vblank in the middle of scanout.
>>>
>>> I think that should be fine as such. The code should ignore redudntant
>>> vbl irqs. Well, assuming you have a reliable hw counter or you use the
>>> timestamp guesstimate mechanism and your scanout position is reported
>>> accurately. But I guess you have a bit of problem with both.
>>>
>>
>> The problem is i'll need to treat calls to radeon kms
>> driver->get_vblank_counter differently, depending if the function gets
>> called from vblank irq, or from regular code, so that hw quirk that
>> causes spontaneous misfiring of the vblank irq in the middle of scanout
>> would confuse my hw vblank counter cooking method to produce a fake hw
>> vblank counter increment. That's why i moved the filtering for redundant
>> irqs based on vblank timestamps in drm_vblank_update() around to always
>> apply. Makes us robust against that type of hw quirk in general and
>> makes life for the vblank counter cooking so much easier.
>>
>> It's a beautiful collaboration of different hw bugs to make things
>> interesting :)
>>

 To fix that i have a minor patch to make drm_update_vblank_count() again
 robust against such redundant calls, which i will send out later to the
 mailing list. Diff attached for reference.

 The second quirk of AMD hw is that the vblank interrupt fires a few
 scanlines before start of vblank, so drm_handle_vblank ->
 drm_update_vblank_count() -> dev->driver->get_vblank_counter() gets
 called before the start of the vblank for which the new vblank count
 should be queried.
>>>
>>> Does it fire too soon, or is the scanout position register value(s)
>>> just offset by a few lines perhaps?
>>>
>>> We have that with i915 and I simply fix up the value when reading it
>>> out. Fortunately for us the offset is constant (or at least seems to
>>> be) for a given platform/connector combo.
>>>
>>
>> I think they fire too soon, from all i've seen so far on a few cards.
>
> That's unfortunate. Firing a bit too late would be perfectly fine for
> most things. And that's actually what happens on older intel hw. Firing
> too soon opens up some more races, as in you may have to wait a bit
> more after getting woken up to make sure you've crossed into the
> freame you were waiting for.
>
> Also not sure how to deal with that sort of thing in a reasonable way in
> .get_vblank_timestamp(). DRM_CALLED_FROM_VBLIRQ gets passed there, so it
> could fudge things a bit when the early irq arrives, but then if someone
> calls drm_update_vblank_count() after the irq was handled but before
> start of vblank you'll end up with a -1 diff.
>
> Maybe something like:
> .get_scanout_positon()
> {
>   read frame counter and scaline position
>
>   if ((flags & DRM_CALLED_FROM_VBLIRQ || frame == last_fudge_frame) &&
>

[PATCH v4 13/13] ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

[Chris Zhong]

This tv080wum-nl0 panel is a mipi panel, it can use in MIPI_TX socket
of rk3288 evb board.

Signed-off-by: Chris Zhong 

---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-evb.dtsi | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index f6d2e78..d04878f 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -47,7 +47,7 @@
reg = <0x0 0x8000>;
};

-   backlight {
+   backlight: backlight {
compatible = "pwm-backlight";
brightness-levels = <
  0   1   2   3   4   5   6   7
@@ -177,6 +177,21 @@
status = "okay";
 };

+_dsi {
+   status = "okay";
+
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+
+   enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_en>;
+   backlight = <>;
+   status = "okay";
+   };
+};
+
  {
bus-width = <4>;
cap-mmc-highspeed;
@@ -247,6 +262,9 @@
bl_en: bl-en {
rockchip,pins = <7 2 RK_FUNC_GPIO _pull_none>;
};
+   lcd_en: lcd-en {
+   rockchip,pins = <7 3 RK_FUNC_GPIO _pull_none>;
+   };
};

buttons {
-- 
2.6.3

[PATCH v4 12/13] drm/panel: simple: Add boe, tv080wum-nl0 simple panel device tree binding

[Chris Zhong]

This binding specifies a set of common properties for display panels. It
can be used as a basis by bindings for specific panels.
Bindings for three specific panels are provided to show how the
simple panel binding can be used.

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 

---

Changes in v4: None
Changes in v3:
move boe,tv080wum-nl0.txt to bindings/display/panel/

Changes in v2:
As Thierry.Reding comment, add a documentation for this panel.

 .../devicetree/bindings/display/panel/boe,tv080wum-nl0.txt | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt 
b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
new file mode 100644
index 000..50be5e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
@@ -0,0 +1,7 @@
+Boe Corporation 8.0" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,tv080wum-nl0"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.6.3

[PATCH v4 11/13] drm/panel: simple: Add support for BOE TV080WUM-NL0

[Chris Zhong]

This adds support for the BOE TV080WUM-NL0 1200x1920 mipi panel to the
DRM simple panel driver.

Signed-off-by: Chris Zhong 

---

Changes in v4:
Alphabetically arranged the name

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/panel/panel-simple.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73e..e3ac2de 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1263,6 +1263,36 @@ static const struct panel_desc_dsi auo_b080uan01 = {
.lanes = 4,
 };

+static const struct drm_display_mode boe_tv080wum_nl0_mode = {
+   .clock = 16,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 120,
+   .hsync_end = 1200 + 120 + 20,
+   .htotal = 1200 + 120 + 20 + 21,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 21,
+   .vsync_end = 1920 + 21 + 3,
+   .vtotal = 1920 + 21 + 3 + 18,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc_dsi boe_tv080wum_nl0 = {
+   .desc = {
+   .modes = _tv080wum_nl0_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 107,
+   .height = 172,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO |
+MIPI_DSI_MODE_VIDEO_BURST |
+MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static const struct drm_display_mode lg_ld070wx3_sl01_mode = {
.clock = 71000,
.hdisplay = 800,
@@ -1348,11 +1378,15 @@ static const struct panel_desc_dsi 
panasonic_vvx10f004b00 = {
.lanes = 4,
 };

+
 static const struct of_device_id dsi_of_match[] = {
{
.compatible = "auo,b080uan01",
.data = _b080uan01
}, {
+   .compatible = "boe,tv080wum-nl0",
+   .data = _tv080wum_nl0
+   }, {
.compatible = "lg,ld070wx3-sl01",
.data = _ld070wx3_sl01
}, {
-- 
2.6.3

[PATCH v4 10/13] of: add vendor prefix for boe

[Chris Zhong]

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 55df1d4..0f88d6f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -33,6 +33,7 @@ auo   AU Optronics Corporation
 avago  Avago Technologies
 avic   Shanghai AVIC Optoelectronics Co., Ltd.
 axis   Axis Communications AB
+boeBOE Technology Group Co., Ltd.
 bosch  Bosch Sensortec GmbH
 boundary   Boundary Devices Inc.
 brcm   Broadcom Corporation
-- 
2.6.3

[PATCH v4 09/13] ARM: dts: rockchip: add rk3288 mipi_dsi nodes

[Chris Zhong]

Add a mipi_dsi node, and also add mipi_dsi endpoints to vopb and vopl
output port nodes.

Signed-off-by: Chris Zhong 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..a5c5670 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -798,6 +798,10 @@
reg = <0>;
remote-endpoint = <_in_vopb>;
};
+   vopb_out_mipi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_in_vopb>;
+   };
};
};

@@ -831,6 +835,10 @@
reg = <0>;
remote-endpoint = <_in_vopl>;
};
+   vopl_out_mipi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_in_vopl>;
+   };
};
};

@@ -871,6 +879,37 @@
};
};

+   mipi_dsi: mipi at ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_MIPI_24M>, < PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_mipi>;
+   };
+   mipi_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_mipi>;
+   };
+   };
+   };
+   };
+
gic: interrupt-controller at ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.6.3

[PATCH v4 08/13] Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver

[Chris Zhong]

add device tree bindings for rk3288 specific Synopsys DW MIPI DSI driver

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 

---

Changes in v4: None
Changes in v3:
move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/

Changes in v2: None

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
new file mode 100644
index 000..acd9ec9
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -0,0 +1,56 @@
+Rockchip specific extensions to the Synopsys Designware MIPI DSI
+
+
+Required properties:
+- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- ports: contain a port node with endpoint definitions as defined in [1].
+  For vopb,set the reg = <0> and set the reg = <1> for vopl.
+
+For more required properties, please refer to [2].
+
+[1] Documentation/devicetree/bindings/media/video-interfaces.txt
+[2] Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
+
+Example:
+   mipi_dsi: mipi at ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_MIPI_24M>, < PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_mipi>;
+   };
+   mipi_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_mipi>;
+   };
+   };
+   };
+
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+
+   enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_en>;
+   backlight = <>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

[PATCH v4 07/13] drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller

[Chris Zhong]

Add support for Synopsys DesignWare MIPI DSI host controller which is
embedded in the rk3288 SoCs.

Signed-off-by: Chris Zhong 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/Kconfig|  10 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c | 249 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   3 +
 4 files changed, 263 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..24395f3 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,13 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_DW_MIPI_DSI
+   bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
+   depends on DRM_ROCKCHIP
+   select DRM_DW_MIPI_DSI
+   help
+This selects support for Rockchip SoC specific extensions
+for the Synopsys DesignWare HDMI driver. If you want to
+enable MIPI DSI on RK3288 based SoC, you should selet this
+option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..6a97059 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw_mipi_dsi_rockchip.o

 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c 
b/drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
new file mode 100644
index 000..a0bb4eb
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
@@ -0,0 +1,249 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define DRIVER_NAME"rockchip-mipi-dsi"
+
+#define GRF_SOC_CON60x025c
+#define DSI0_SEL_VOP_LIT(1 << 6)
+#define DSI1_SEL_VOP_LIT(1 << 9)
+
+struct rockchip_mipi_dsi {
+   struct drm_encoder encoder;
+   struct device *dev;
+   struct regmap *regmap;
+};
+
+static inline struct rockchip_mipi_dsi *enc_to_dsi(struct drm_encoder *enc)
+{
+   return container_of(enc, struct rockchip_mipi_dsi, encoder);
+}
+
+static struct drm_encoder_funcs rockchip_mipi_dsi_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static int rockchip_mipi_parse_dt(struct rockchip_mipi_dsi *dsi)
+{
+   struct device_node *np = dsi->dev->of_node;
+
+   dsi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+   if (IS_ERR(dsi->regmap)) {
+   dev_err(dsi->dev, "Unable to get rockchip,grf\n");
+   return PTR_ERR(dsi->regmap);
+   }
+
+   return 0;
+}
+
+static bool rockchip_mipi_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void rockchip_mipi_dsi_encoder_prepare(struct drm_encoder *encoder)
+{
+   u32 encoder_pix_fmt, interface_pix_fmt;
+
+   encoder_pix_fmt = dw_mipi_dsi_get_encoder_pixel_format(encoder);
+
+   switch (encoder_pix_fmt) {
+   case MIPI_DSI_FMT_RGB888:
+   interface_pix_fmt = ROCKCHIP_OUT_MODE_P888;
+   break;
+   case MIPI_DSI_FMT_RGB666:
+   interface_pix_fmt = ROCKCHIP_OUT_MODE_P666;
+   break;
+   case MIPI_DSI_FMT_RGB565:
+   interface_pix_fmt = ROCKCHIP_OUT_MODE_P565;
+   break;
+   default:
+   WARN_ON(1);
+   return;
+   }
+
+   rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_DSI,
+ interface_pix_fmt);
+}
+
+static void rockchip_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+}
+
+static void rockchip_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
+{
+   struct rockchip_mipi_dsi *dsi = 

[PATCH v4 06/13] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[Chris Zhong]

add Synopsys DesignWare MIPI DSI host controller driver support.

Signed-off-by: Chris Zhong 
---

Changes in v4:
eliminate some warnning

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/Kconfig   |   11 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/dw_mipi_dsi.c | 1056 ++
 include/drm/bridge/dw_mipi_dsi.h |   27 +
 4 files changed, 1095 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..c0900e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -22,6 +22,17 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.

+config DRM_DW_MIPI_DSI
+   tristate "Synopsys DesignWare MIPI DSI host controller bridge"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   help
+ Choose this if you want to use the Synopsys DesignWare MIPI DSI host
+ controller bridge. If M is selected, the module will be
+ called dw_mipi_dsi. DRM_MIPI_DSI support is required for this driver
+ to work.

 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..d908c4b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,5 +2,6 @@ ccflags-y := -Iinclude/drm

 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw_mipi_dsi.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c 
b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
new file mode 100644
index 000..23b612d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
@@ -0,0 +1,1056 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DSI_VERSION0x00
+
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VID(vid)   (((vid) & 0x3) << 0)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define EN18_LOOSELY   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define EN_CRC_RX  BIT(4)
+#define EN_ECC_RX  BIT(3)
+#define EN_BTA BIT(2)
+#define EN_EOTP_RX BIT(1)
+#define EN_EOTP_TX BIT(0)
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define FRAME_BTA_ACK  BIT(14)
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_BURST_SYNC_PULSES0x2
+#define VID_MODE_TYPE_MASK 0x3
+
+#define DSI_VID_PKT_SIZE   0x3c
+#define VID_PKT_SIZE(p)(((p) & 0x3fff) << 0)
+#define VID_PKT_MAX_SIZE   0x3fff
+
+#define DSI_VID_HSA_TIME   0x48
+#define DSI_VID_HBP_TIME   0x4c
+#define DSI_VID_HLINE_TIME 0x50
+#define DSI_VID_VSA_LINES  0x54
+#define 

[PATCH v4 05/13] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver

[Chris Zhong]

From: Liu Ying 

This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
host controller DRM bridge driver.

Signed-off-by: Liu Ying 
Signed-off-by: Chris Zhong 

---

Changes in v4:
remove gpr property from example, since it is noused now.
add the description about ports

Changes in v3:
move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge

Changes in v2: None

 .../bindings/display/bridge/dw_mipi_dsi.txt| 80 ++
 1 file changed, 80 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..8572ab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,80 @@
+Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
+
+The controller is a digital core that implements all protocol functions
+defined in the MIPI DSI specification, providing an interface between
+the system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The first compatible string should be "fsl,imx6q-mipi-dsi"
+   for i.MX6q/sdl SoCs.  For other SoCs, please refer to their specific
+   device tree binding documentations.  A common compatible string
+   "snps,dw-mipi-dsi" should be appended for all SoCs.
+ - reg: Represent the physical address range of the controller.
+ - interrupts: Represent the controller's interrupt to the CPU(s).
+ - clocks, clock-names: Phandles to the controller's pll reference
+   clock(ref), configuration clock(cfg) and APB clock(pclk), as
+   described in [1].
+ - port@[X]: SoC specific port nodes with endpoint definitions as defined
+   in Documentation/devicetree/bindings/media/video-interfaces.txt,
+   please refer to the SoC specific binding document:
+* 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi-rockchip.txt
+
+
+For more required properties, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+Required sub-nodes:
+ - A node to represent a DSI peripheral as described in [2].
+
+For more required sub-nodes, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+
+example:
+   gpr: iomuxc-gpr at 020e {
+   /* ... */
+   };
+
+   mipi_dsi: mipi at 021e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0x021e 0x4000>;
+   interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_IPG>;
+   clock-names = "ref", "cfg", "pclk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+
+   mipi_mux_0: endpoint {
+   remote-endpoint = <_di0_mipi>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   mipi_mux_1: endpoint {
+   remote-endpoint = <_di1_mipi>;
+   };
+   };
+   };
+
+   panel {
+   compatible = "truly,tft480800-16-e-dsi";
+   reg = <0>;
+   /* ... */
+   };
+   };
-- 
2.6.3

[PATCH v4 04/13] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

[Chris Zhong]

From: Liu Ying 

Signed-off-by: Liu Ying 
Acked-by: Thierry Reding 
Signed-off-by: Chris Zhong 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

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

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

+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt)
+{
+   switch (fmt) {
+   case MIPI_DSI_FMT_RGB888:
+   case MIPI_DSI_FMT_RGB666:
+   return 24;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   return 18;
+   case MIPI_DSI_FMT_RGB565:
+   return 16;
+   }
+   return -EINVAL;
+}
+
 struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node 
*np);
 int mipi_dsi_attach(struct mipi_dsi_device *dsi);
 int mipi_dsi_detach(struct mipi_dsi_device *dsi);
-- 
2.6.3

[PATCH v4 03/13] drm/rockchip: return a true clock rate to adjusted_mode

[Chris Zhong]

Since the mipi dsi driver need to use the clock of vop to make the
calculation of Blanking. But sometimes the clock driver can not set a
accurate clock_rate for vop, get it by clk_round_rate before mode_set,
so we can get the true value.

Signed-off-by: Chris Zhong 

---

Changes in v4:
use clk_round_rate to check the clock rate in vop_crtc_mode_fixup

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..eff545b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1136,9 +1136,14 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
+   struct vop *vop = to_vop(crtc);
+
if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
return false;

+   adjusted_mode->clock =
+   clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
+
return true;
 }

-- 
2.6.3

[PATCH v4 02/13] clk: rockchip: add mipidsi clocks on rk3288

[Chris Zhong]

sclk_mipidsi_24m is the gating of mipi dsi phy.

Signed-off-by: Chris Zhong 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/clk/rockchip/clk-rk3288.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..c7d7ebf 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -709,7 +709,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
GATE(SCLK_LCDC_PWM1, "sclk_lcdc_pwm1", "xin24m", 0, 
RK3288_CLKGATE_CON(13), 11, GFLAGS),
GATE(SCLK_PVTM_CORE, "sclk_pvtm_core", "xin24m", 0, 
RK3288_CLKGATE_CON(5), 9, GFLAGS),
GATE(SCLK_PVTM_GPU, "sclk_pvtm_gpu", "xin24m", 0, 
RK3288_CLKGATE_CON(5), 10, GFLAGS),
-   GATE(0, "sclk_mipidsi_24m", "xin24m", 0, RK3288_CLKGATE_CON(5), 15, 
GFLAGS),
+   GATE(SCLK_MIPI_24M, "sclk_mipidsi_24m", "xin24m", 0, 
RK3288_CLKGATE_CON(5), 15, GFLAGS),

/* sclk_gpu gates */
GATE(ACLK_GPU, "aclk_gpu", "sclk_gpu", 0, RK3288_CLKGATE_CON(18), 0, 
GFLAGS),
-- 
2.6.3

[PATCH v4 01/13] clk: rockchip: add id for mipidsi sclk on rk3288

[Chris Zhong]

Adds a new id for the sclk supplying the mipidsi on rk3288 socs.

Signed-off-by: Chris Zhong 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
add the mipi clk id in a single patch

 include/dt-bindings/clock/rk3288-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..b07cdd3 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
 #define SCLK_USBPHY480M_SRC122
 #define SCLK_PVTM_CORE 123
 #define SCLK_PVTM_GPU  124
+#define SCLK_MIPI_24M  125

 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
2.6.3

[PATCH v4 0/13] Add mipi dsi support for rk3288

[Chris Zhong]

The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM bridge driver and a rockchip MIPI DSI specific DRM
driver.

This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
This panel only use the MIPI DSI video mode.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel v3.14, and it can display normally.

This patchset is base on the patchset from Ying.liu at freescale.com.


Changes in v4:
use clk_round_rate to check the clock rate in vop_crtc_mode_fixup
remove gpr property from example, since it is noused now.
add the description about ports
eliminate some warnning
Alphabetically arranged the name

Changes in v3:
move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge
move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
move boe,tv080wum-nl0.txt to bindings/display/panel/

Changes in v2:
add the mipi clk id in a single patch
As Thierry.Reding comment, add a documentation for this panel.

Chris Zhong (11):
  clk: rockchip: add id for mipidsi sclk on rk3288
  clk: rockchip: add mipidsi clocks on rk3288
  drm/rockchip: return a true clock rate to adjusted_mode
  drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
  drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
  Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
  ARM: dts: rockchip: add rk3288 mipi_dsi nodes
  of: add vendor prefix for boe
  drm/panel: simple: Add support for BOE TV080WUM-NL0
  drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
binding
  ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

Liu Ying (2):
  drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
  Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
bridge driver

 .../bindings/display/bridge/dw_mipi_dsi.txt|   80 ++
 .../bindings/display/panel/boe,tv080wum-nl0.txt|7 +
 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   56 ++
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 arch/arm/boot/dts/rk3288-evb.dtsi  |   20 +-
 arch/arm/boot/dts/rk3288.dtsi  |   39 +
 drivers/clk/rockchip/clk-rk3288.c  |2 +-
 drivers/gpu/drm/bridge/Kconfig |   11 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/dw_mipi_dsi.c   | 1056 
 drivers/gpu/drm/panel/panel-simple.c   |   34 +
 drivers/gpu/drm/rockchip/Kconfig   |   10 +
 drivers/gpu/drm/rockchip/Makefile  |1 +
 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c|  249 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|8 +
 include/drm/bridge/dw_mipi_dsi.h   |   27 +
 include/drm/drm_mipi_dsi.h |   14 +
 include/dt-bindings/clock/rk3288-cru.h |1 +
 18 files changed, 1615 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
 create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
 create mode 100644 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

-- 
2.6.3

[PATCH 5/5] drm/imx: ipuv3 plane: Replace dev_info with dev_dbg if a plane's CRTC changes

[Liu Ying]

This patch changes the dev_info() call to dev_dbg() in ipu_plane_update()
to print out the information that a plane's CRTC is changed, because this
kind of information is only useful for debugging.

Signed-off-by: Liu Ying 
---
This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.

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

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index b3ed207..b24bf94 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -338,7 +338,7 @@ static int ipu_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
}

if (crtc != plane->crtc)
-   dev_info(plane->dev->dev, "crtc change: %p -> %p\n",
+   dev_dbg(plane->dev->dev, "crtc change: %p -> %p\n",
plane->crtc, crtc);
plane->crtc = crtc;

-- 
2.5.0

[PATCH 4/5] drm/imx: ipuv3 plane: Use the helper ipu_plane_cleanup() in ipu_plane_destroy()

[Liu Ying]

To reduce code duplication, we can use the helper ipu_plane_cleanup() in
ipu_plane_destroy().

Signed-off-by: Liu Ying 
---
This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.

 drivers/gpu/drm/imx/ipuv3-plane.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index e60b382..b3ed207 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -369,8 +369,7 @@ 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);
+   ipu_plane_cleanup(ipu_plane);
 }

 static struct drm_plane_funcs ipu_plane_funcs = {
-- 
2.5.0

[PATCH 3/5] drm/imx: ipuv3 crtc: Cleanup ipu planes in ipu_drm_unbind()

[Liu Ying]

To avoid memory leakage, we need to cleanup ipu planes in ipu_drm_unbind().

Signed-off-by: Liu Ying 
---
This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.

 drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 59f44df..467905c 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -446,6 +446,11 @@ static void ipu_drm_unbind(struct device *dev, struct 
device *master,
imx_drm_remove_crtc(ipu_crtc->imx_crtc);

ipu_plane_put_resources(ipu_crtc->plane[0]);
+
+   if (ipu_crtc->plane[1])
+   ipu_plane_cleanup(ipu_crtc->plane[1]);
+   ipu_plane_cleanup(ipu_crtc->plane[0]);
+
ipu_put_resources(ipu_crtc);
 }

-- 
2.5.0

[PATCH 2/5] drm/imx: ipuv3 crtc: Cleanup ipu planes in ipu_crtc_init() when necessary

[Liu Ying]

To avoid memory leakage, we need to cleanup the initialized ipu planes in
the bailout path of ipu_crtc_init().

Signed-off-by: Liu Ying 
---
This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.

 drivers/gpu/drm/imx/ipuv3-crtc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 67813ca..59f44df 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -371,7 +371,7 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
ipu_crtc->dev->of_node);
if (ret) {
dev_err(ipu_crtc->dev, "adding crtc failed with %d.\n", ret);
-   goto err_put_resources;
+   goto err_cleanup_plane0;
}

ret = ipu_plane_get_resources(ipu_crtc->plane[0]);
@@ -402,9 +402,14 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
return 0;

 err_put_plane_res:
+   if (ipu_crtc->plane[1])
+   ipu_plane_cleanup(ipu_crtc->plane[1]);
+
ipu_plane_put_resources(ipu_crtc->plane[0]);
 err_remove_crtc:
imx_drm_remove_crtc(ipu_crtc->imx_crtc);
+err_cleanup_plane0:
+   ipu_plane_cleanup(ipu_crtc->plane[0]);
 err_put_resources:
ipu_put_resources(ipu_crtc);

-- 
2.5.0

[PATCH 1/5] drm/imx: ipuv3 plane: Introduce ipu_plane_cleanup()

[Liu Ying]

This patch adds a helper ipu_plane_cleanup() to cleanup a IPU plane.
It can be used in the bailout path of ipu_crtc_init(), for instance.

Signed-off-by: Liu Ying 
---
This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.

 drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++
 drivers/gpu/drm/imx/ipuv3-plane.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index e2ff410..e60b382 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -410,3 +410,9 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, 
struct ipu_soc *ipu,

return ipu_plane;
 }
+
+void ipu_plane_cleanup(struct ipu_plane *ipu_plane)
+{
+   drm_plane_cleanup(_plane->base);
+   kfree(ipu_plane);
+}
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.h 
b/drivers/gpu/drm/imx/ipuv3-plane.h
index 3a443b4..dd2239c 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.h
+++ b/drivers/gpu/drm/imx/ipuv3-plane.h
@@ -36,6 +36,8 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, 
struct ipu_soc *ipu,
 int dma, int dp, unsigned int possible_crtcs,
 enum drm_plane_type type);

+void ipu_plane_cleanup(struct ipu_plane *ipu_plane);
+
 /* Init IDMAC, DMFC, DP */
 int ipu_plane_mode_set(struct ipu_plane *plane, struct drm_crtc *crtc,
   struct drm_display_mode *mode,
-- 
2.5.0

[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm

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

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

--- Comment #3 from Ernst Sjöstrand  ---
Created attachment 119989
  --> https://bugs.freedesktop.org/attachment.cgi?id=119989=edit
cs-go-llvm.txt

Oh, haven't tried the patch yet. Here's the log with R600_DEBUG=vs,gs,ps
anyway.

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

[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed

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

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

Michael Eagle  changed:

   What|Removed |Added

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

--- Comment #9 from Michael Eagle  ---
Issue is fixed now with fedora 23.

Packages:
kernel 4.4.0-0.rc1.git
mesa-libwayland-egl-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-libglapi-11.1.0-0.devel.34.292df19.fc23.i686
mesa-libxatracker-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-libEGL-11.1.0-0.devel.34.292df19.fc23.i686
mesa-libgbm-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-libgbm-11.1.0-0.devel.34.292df19.fc23.i686
mesa-libEGL-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-libOSMesa-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-libGLU-9.0.0-9.fc23.x86_64
mesa-libGL-11.1.0-0.devel.34.292df19.fc23.i686
mesa-libglapi-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-filesystem-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-dri-drivers-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-libGLES-11.1.0-0.devel.34.292df19.fc23.x86_64
mesa-dri-drivers-11.1.0-0.devel.34.292df19.fc23.i686
mesa-filesystem-11.1.0-0.devel.34.292df19.fc23.i686
mesa-libGL-11.1.0-0.devel.34.292df19.fc23.x86_64
xorg-x11-drv-ati-7.6.99-1.20151115gitdfb5277.fc23.x86_64
xorg-x11-server-Xorg-1.18.0-2.fc23.x86_64
xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64
llvm-libs-3.7.0-1.fc23.i686
llvm-libs-3.7.0-1.fc23.x86_64

now, inxi -G shows both adapters:
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
   Card-2: Advanced Micro Devices [AMD/ATI] Sun XT [Radeon HD
8670A/8670M/8690M / R5 M330]
   Display Server: X.org 1.18.0 drivers: ati,radeon,intel (unloaded:
fbdev,vesa)
   tty size: 211x49 Advanced Data: N/A for root


xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x78 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs:
4 outputs: 5 associated providers: 2 name:Intel
Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon
Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon


glxinfo  | grep 'OpenGL renderer\|Mesa'
client glx vendor string: Mesa Project and SGI
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel
OpenGL version string: 3.0 Mesa 11.1.0-devel
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.1.0-devel

DRI_PRIME=1 glxinfo  | grep 'OpenGL renderer\|Mesa'
client glx vendor string: Mesa Project and SGI
OpenGL renderer string: Gallium 0.4 on AMD HAINAN (DRM 2.43.0, LLVM 3.7.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.1.0-devel
OpenGL version string: 3.0 Mesa 11.1.0-devel
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.1.0-devel


I can also instruct steam to use my secondary adapter to render games.
DRI_PRIME=1 steam

Thank you to all the people involved into solving this!

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

[Bug 93017] complete system stalls while changing displays resolutions on a hybrid (intel/radeon) system

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

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

--- Comment #5 from Yaroslav Halchenko  ---
reporting on "success":  after new patched kernel installation and some
ugprades (kept crashing gnome not kernel, so had to upgrade), caused the stall
with a bit different but overall similar traceback (full output of journalctl
for that boot is attached):

Nov 20 10:04:38 hopa kernel: [drm:intel_hdmi_detect] [CONNECTOR:53:HDMI-A-2]
Nov 20 10:04:38 hopa kernel:  88043c187858 0001
81555c51 88043c678080
Nov 20 10:04:38 hopa kernel: Call Trace:
Nov 20 10:04:38 hopa kernel:  [] ?
wq_worker_sleeping+0xd/0x90
Nov 20 10:04:38 hopa kernel:  [] ? __schedule+0x505/0x8f0
Nov 20 10:04:38 hopa kernel:  [] ? schedule+0x31/0x80
Nov 20 10:04:38 hopa kernel:  [] ? do_exit+0x72c/0xa90
Nov 20 10:04:38 hopa kernel:  [] ? oops_end+0x9c/0xd0
Nov 20 10:04:38 hopa kernel: [drm:intel_hdmi_detect] Live status not up!
Nov 20 10:04:38 hopa kernel:
[drm:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:53:HDMI-A-2] disconnected
Nov 20 10:04:38 hopa kernel:  [] ?
general_protection+0x28/0x30
Nov 20 10:04:38 hopa kernel:  [] ?
reservation_object_test_signaled_rcu+0xcf/0x220
Nov 20 10:04:38 hopa kernel:  [] ?
reservation_object_wait_timeout_rcu+0x219/0x260
Nov 20 10:04:38 hopa kernel:  [] ? ttm_bo_wait+0x29/0x50
[ttm]
Nov 20 10:04:38 hopa kernel:  [] ?
ttm_bo_cleanup_refs_and_unlock+0x27/0x170 [ttm]
Nov 20 10:04:38 hopa kernel:  [] ?
ttm_bo_delayed_delete+0xbf/0x200 [ttm]
Nov 20 10:04:38 hopa kernel:  [] ?
ttm_bo_delayed_workqueue+0x17/0x40 [ttm]
Nov 20 10:04:38 hopa kernel:  [] ?
process_one_work+0x19f/0x3d0
Nov 20 10:04:38 hopa kernel:  [] ? worker_thread+0x4d/0x450
Nov 20 10:04:38 hopa kernel:  [] ?
process_one_work+0x3d0/0x3d0
Nov 20 10:04:38 hopa kernel:  [] ? kthread+0xbd/0xe0
Nov 20 10:04:38 hopa kernel:  [] ?
kthread_create_on_node+0x170/0x170
Nov 20 10:04:38 hopa kernel:  [] ? ret_from_fork+0x3f/0x70
Nov 20 10:04:38 hopa kernel:  [] ?
kthread_create_on_node+0x170/0x170
Nov 20 10:04:38 hopa kernel: Code: 48 c7 c7 b2 07 80 81 e8 83 39 fe ff e9 bf fe
ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 87 40 04
00 00 <48> 8b 40 d8 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 
Nov 20 10:04:38 hopa kernel: RIP  [] kthread_data+0xc/0x20
Nov 20 10:04:38 hopa kernel:  RSP 
Nov 20 10:04:38 hopa kernel: CR2: ffd8
Nov 20 10:04:38 hopa kernel: ---[ end trace 01c0854cd2e7cf2f ]---
Nov 20 10:04:38 hopa kernel: Fixing recursive fault but reboot is needed!

To stall it, I had both displays connected where 2nd one was just mirroring the
first one. And I have turned off the 2nd display which caused all the mess

what could be the next step? ;-)

BTW -- with this recent upgrade, now two attached monitors are also seen as an
extended desktop (3840x1200) which never happened before, and actually works
quite nicely. but then also caused crash (no traceback was recorded and I
didn't have remote session attached) using the same trick of turning the 2nd
display off

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

[Bug 93017] complete system stalls while changing displays resolutions on a hybrid (intel/radeon) system

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

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

--- Comment #4 from Yaroslav Halchenko  ---
Created attachment 119987
  --> https://bugs.freedesktop.org/attachment.cgi?id=119987=edit
journalctl output (a bit annonymized) showing details of the session with the
crash

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

[Bug 93015] Tonga Elemental segfault + VM faults since radeon: implement r600_query_hw_get_result via function pointers

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

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

--- Comment #5 from Mathias Tillman  ---
Had this problem too, and the patch seems to have fixed it for me.

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

[PATCH v3 00/12] Add mipi dsi support for rk3288

[Chris Zhong]

Hi Emil

On 11/19/2015 10:41 PM, Emil Velikov wrote:
> On 19 November 2015 at 03:35, Chris Zhong  wrote:
>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
>> controller DRM bridge driver and a rockchip MIPI DSI specific DRM
>> driver.
>>
>> This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
>> This panel only use the MIPI DSI video mode.
>>
>> The MIPI DSI feature is tested on rk3288 evb board, backport them to
>> chrome os kernel v3.14, and it can display normally.
>>
>> This patchset is base on the patchset from Ying.liu at freescale.com.
>> 
>>
>>
>> Changes in v3:
>> move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge
>> move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
>> move boe,tv080wum-nl0.txt to bindings/display/panel/
>>
>> Changes in v2:
>> add the mipi clk id in a single patch
>> As Thierry.Reding comment, add a documentation for this panel.
>>
>> Chris Zhong (10):
>>clk: rockchip: add id for mipidsi sclk on rk3288
>>clk: rockchip: add mipidsi clocks on rk3288
>>drm/rockchip: return a true clock rate to adjusted_mode
>>drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
> Did you actually rewrite the patch from Liu Ying ?
I modify the dw_mipi_dsi.c based on the patch from Liu Ying.
> Out of curiosity what was the obstacle of this work getting merged ?
There are different version dw controller, and it is too hard to merge them,
since most registers are different.
>
>>drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
>>Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
>>ARM: dts: rockchip: add rk3288 mipi_dsi nodes
>>drm/panel: simple: Add support for BOE TV080WUM-NL0
>>drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
>>  binding
> As the DT people will tell you - there is no BOE vendor in
> bindings/vendor-prefixes.txt.
Yes, I have post a verdor patch in v2 series,

Maybe I should add it back to series with

Acked-by: Rob Herring

>
>>ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb
>>
>> Liu Ying (2):
>>drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
>>Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
>>  bridge driver
>>
> >From the above 12 patches only ~6 reached this mailing list is that
> intentional ? Previously I've seen people CC dri-devel for their
> panel/bridge DT patches.
I use the patman to post the series, forgot to add you and Thierry to 
the to-list.
I will fix in next version series. Thanks for your reply.

>
> Regards,
> Emil
>
>
>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

--- Comment #119 from summerrainbowz101 at gmail.com ---
Created attachment 119985
  --> https://bugs.freedesktop.org/attachment.cgi?id=119985=edit
v2 patch dmesg

No dice with patch, attached another dmesg. Maybe I applied the patch wrong?

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

[Bug 44568] Half-Life 1 engine has poor fps is large areas

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

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

--- Comment #3 from Toni Spets  ---
No hardware to test this anymore, should probably be closed.

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

[PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting.

[Liviu Dudau]

On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> On Wed, Nov 11, 2015 at 05:51:52PM +, Russell King - ARM Linux wrote:
> > On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> > > While going through the code testing I've noticed an unbalanced
> > > .unbind missing drm_connector_unregister()
> > 
> > That actually doesn't matter, as DRM automatically tears them down anyway,
> > so this isn't an urgent change.  However, it's good practice to do so.
> 
> It looks like it doesn't, or at least not if the error code is -EPROBE_DEFER.
> On Juno, where the clocks are provided by SCPI and the load order is not
> guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs entry
> is not cleaned up, so on the next attempt the drm_connector_register() call
> will fail.
> 
> Best regards,
> Liviu

Gentle ping. Russell, are you happy with this patchset? If so, would you mind
giving me your Acks?

Many thanks,
Liviu

> 
> > 
> > -- 
> > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > according to speedtest.net.
> > 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

[PATCH v2 2/2] drm/rockchip: Convert the probe function to the generic drm_of_component_probe()

[Liviu Dudau]

Initial attempt to convert rockchip to drm_of_component_probe() missed the
difference between ports and encoders when using the compare_of() function.
Now that drm_of_component_probe() has been enhanced, let's try again the
conversion.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 98 ++---
 1 file changed, 18 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f22e1e1..574324e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -411,36 +412,6 @@ int rockchip_drm_encoder_get_mux_id(struct device_node 
*node,
 }
 EXPORT_SYMBOL_GPL(rockchip_drm_encoder_get_mux_id);

-static int compare_of(struct device *dev, void *data)
-{
-   struct device_node *np = data;
-
-   return dev->of_node == np;
-}
-
-static void rockchip_add_endpoints(struct device *dev,
-  struct component_match **match,
-  struct device_node *port)
-{
-   struct device_node *ep, *remote;
-
-   for_each_child_of_node(port, ep) {
-   remote = of_graph_get_remote_port_parent(ep);
-   if (!remote || !of_device_is_available(remote)) {
-   of_node_put(remote);
-   continue;
-   } else if (!of_device_is_available(remote->parent)) {
-   dev_warn(dev, "parent device of %s is not available\n",
-remote->full_name);
-   of_node_put(remote);
-   continue;
-   }
-
-   component_match_add(dev, match, compare_of, remote);
-   of_node_put(remote);
-   }
-}
-
 static int rockchip_drm_bind(struct device *dev)
 {
struct drm_device *drm;
@@ -481,63 +452,30 @@ static const struct component_master_ops rockchip_drm_ops 
= {
.unbind = rockchip_drm_unbind,
 };

-static int rockchip_drm_platform_probe(struct platform_device *pdev)
+static int compare_port(struct device *dev, void *data)
 {
-   struct device *dev = >dev;
-   struct component_match *match = NULL;
-   struct device_node *np = dev->of_node;
-   struct device_node *port;
-   int i;
+   struct device_node *np = data;

-   if (!np)
-   return -ENODEV;
-   /*
-* Bind the crtc ports first, so that
-* drm_of_find_possible_crtcs called from encoder .bind callbacks
-* works as expected.
-*/
-   for (i = 0;; i++) {
-   port = of_parse_phandle(np, "ports", i);
-   if (!port)
-   break;
-
-   if (!of_device_is_available(port->parent)) {
-   of_node_put(port);
-   continue;
-   }
+   return dev->of_node == np->parent;
+}

-   component_match_add(dev, , compare_of, port->parent);
-   of_node_put(port);
-   }
+static int compare_encoder(struct device *dev, void *data)
+{
+   struct device_node *np = data;

-   if (i == 0) {
-   dev_err(dev, "missing 'ports' property\n");
-   return -ENODEV;
-   }
+   return dev->of_node == np;
+}

-   if (!match) {
-   dev_err(dev, "No available vop found for display-subsystem.\n");
-   return -ENODEV;
-   }
-   /*
-* For each bound crtc, bind the encoders attached to its
-* remote endpoint.
-*/
-   for (i = 0;; i++) {
-   port = of_parse_phandle(np, "ports", i);
-   if (!port)
-   break;
-
-   if (!of_device_is_available(port->parent)) {
-   of_node_put(port);
-   continue;
-   }
+static int rockchip_drm_platform_probe(struct platform_device *pdev)
+{
+   int ret = drm_of_component_probe(>dev, compare_port,
+compare_encoder, _drm_ops);

-   rockchip_add_endpoints(dev, , port);
-   of_node_put(port);
-   }
+   /* keep compatibility with old code that was returning -ENODEV */
+   if (ret == -EINVAL)
+   return -ENODEV;

-   return component_master_add_with_match(dev, _drm_ops, match);
+   return ret;
 }

 static int rockchip_drm_platform_remove(struct platform_device *pdev)
-- 
2.6.2

[PATCH v2 1/2] drm: Improve drm_of_component_probe() to correctly handle ports and remote ports.

[Liviu Dudau]

Rockchip DRM driver cannot use the same compare_of() function to
match ports and remote ports (aka encoders) as their OF sub-trees
look different. Add a second compare function to be used when encoders
are added to the component framework and patch the existing users of
the function accordingly.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/armada/armada_drv.c |  3 ++-
 drivers/gpu/drm/drm_of.c| 19 ++-
 drivers/gpu/drm/imx/imx-drm-core.c  |  3 ++-
 include/drm/drm_of.h|  6 --
 4 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 77ab93d..3a2a929 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -274,7 +274,8 @@ static int armada_drm_probe(struct platform_device *pdev)
struct device *dev = >dev;
int ret;

-   ret = drm_of_component_probe(dev, compare_dev_name, _master_ops);
+   ret = drm_of_component_probe(dev, compare_dev_name, compare_dev_name,
+_master_ops);
if (ret != -EINVAL)
return ret;

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 493c05c..34589d3 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -77,7 +77,8 @@ EXPORT_SYMBOL(drm_of_find_possible_crtcs);
  * Returns zero if successful, or one of the standard error codes if it fails.
  */
 int drm_of_component_probe(struct device *dev,
-  int (*compare_of)(struct device *, void *),
+  int (*compare_port)(struct device *, void *),
+  int (*compare_encoder)(struct device *, void *),
   const struct component_master_ops *m_ops)
 {
struct device_node *ep, *port, *remote;
@@ -101,8 +102,12 @@ int drm_of_component_probe(struct device *dev,
continue;
}

-   component_match_add(dev, , compare_of, port);
-   of_node_put(port);
+   component_match_add(dev, , compare_port, port);
+   /*
+* component_match_add keeps a reference to the port
+* variable, so we need to keep the reference count
+* increment from of_parse_phandle()
+*/
}

if (i == 0) {
@@ -140,8 +145,12 @@ int drm_of_component_probe(struct device *dev,
continue;
}

-   component_match_add(dev, , compare_of, remote);
-   of_node_put(remote);
+   component_match_add(dev, , compare_encoder, 
remote);
+   /*
+* component_match_add keeps a reference to the port
+* variable, so we need to keep the reference count
+* increment from of_graph_get_remote_port_parent()
+*/
}
of_node_put(port);
}
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 64f16ea..0d36410 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -531,7 +531,8 @@ static const struct component_master_ops imx_drm_ops = {

 static int imx_drm_platform_probe(struct platform_device *pdev)
 {
-   int ret = drm_of_component_probe(>dev, compare_of, _drm_ops);
+   int ret = drm_of_component_probe(>dev, compare_of, compare_of,
+_drm_ops);

if (!ret)
ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 8544665..1c29e42 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -10,7 +10,8 @@ struct device_node;
 extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
   struct device_node *port);
 extern int drm_of_component_probe(struct device *dev,
- int (*compare_of)(struct device *, void *),
+ int (*compare_port)(struct device *, void *),
+ int (*compare_encoder)(struct device *, void 
*),
  const struct component_master_ops *m_ops);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
@@ -21,7 +22,8 @@ static inline uint32_t drm_of_find_possible_crtcs(struct 
drm_device *dev,

 static inline int
 drm_of_component_probe(struct device *dev,
-  int (*compare_of)(struct device *, void *),
+  int (*compare_port)(struct device *, void *),
+  int (*compare_encoder)(struct device *, void *),
   const struct component_master_ops *m_ops)
 {
return -EINVAL;
-- 
2.6.2

[PATCH v2 0/2] Improve drm_of_component_probe() and move rockchip to use it

[Liviu Dudau]

Hello,

This is v2 of the patchset trying to make drm_of_component_probe() cope with 
finding
both local crtc ports and remote encoder ones. Heiko Stübner was nice enough 
to test
an earlier version that was patched following Russell's suggestions on rk3288, 
but
I haven't seen any reports from iMX or Armada users.

Changelog:
 v2: Updated the drm_of_component_probe() comment to explain why the reference 
count
 is not dropped. Fixed the compare_port() function for rockchip as 
described by
 Russell.
 v1: Original submission. 
http://lists.freedesktop.org/archives/dri-devel/2015-November/094546.html

Liviu Dudau (2):
  drm: Improve drm_of_component_probe() to correctly handle ports and remote 
ports.
  drm/rockchip: Convert the probe function to the generic 
drm_of_component_probe()

 drivers/gpu/drm/armada/armada_drv.c |  3 +-
 drivers/gpu/drm/drm_of.c| 19 --
 drivers/gpu/drm/imx/imx-drm-core.c  |  3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 98 ++---
 include/drm/drm_of.h|  6 +-
 5 files changed, 40 insertions(+), 89 deletions(-)

-- 
2.6.2

[PATCH i915 v5 2/2] i915: wait for fence in prepare_plane_fb

[Alex Goins]

In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive
fence

v2: First commit
v3: Remove object_name_lock acquire
Move wait from intel_atomic_commit() to intel_prepare_plane_fb()
v4: Wait only on exclusive fences, interruptible with no timeout
v5: Style tweaks to more closely match rest of file

Signed-off-by: Alex Goins 
---
 drivers/gpu/drm/i915/intel_display.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eef3475..f5ab8a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13347,6 +13347,12 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (!obj)
return 0;

+   /* For framebuffer backed by dmabuf, wait for fence */
+   if (obj->base.dma_buf)
+   reservation_object_wait_timeout_rcu(obj->base.dma_buf->resv,
+   false, true,
+   MAX_SCHEDULE_TIMEOUT);
+
mutex_lock(>struct_mutex);

if (plane->type == DRM_PLANE_TYPE_CURSOR &&
-- 
1.9.1

[PATCH i915 v5 1/2] i915: wait for fence in mmio_flip_work_func

[Alex Goins]

If a buffer is backed by dmabuf, wait on its reservation object's exclusive
fence before flipping.

v2: First commit
v3: Remove object_name_lock acquire
v4: Move wait ahead of mark_page_flip_active
Use crtc->primary->fb to get GEM object instead of pending_flip_obj
use_mmio_flip() return true when exclusive fence is attached
Wait only on exclusive fences, interruptible with no timeout
v5: Move wait from do_mmio_flip to mmio_flip_work_func
Style tweaks to more closely match rest of file

Signed-off-by: Alex Goins 
---
 drivers/gpu/drm/i915/intel_display.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b2270d5..eef3475 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -44,6 +44,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 /* Primary plane formats for gen <= 3 */
 static const uint32_t i8xx_primary_formats[] = {
@@ -11088,6 +11090,8 @@ static bool use_mmio_flip(struct intel_engine_cs *ring,
return true;
else if (i915.enable_execlists)
return true;
+   else if (obj->base.dma_buf && obj->base.dma_buf->resv->fence_excl)
+   return true;
else
return ring != i915_gem_request_get_ring(obj->last_write_req);
 }
@@ -11189,6 +11193,9 @@ static void intel_mmio_flip_work_func(struct 
work_struct *work)
 {
struct intel_mmio_flip *mmio_flip =
container_of(work, struct intel_mmio_flip, work);
+   struct intel_framebuffer *intel_fb =
+   to_intel_framebuffer(mmio_flip->crtc->base.primary->fb);
+   struct drm_i915_gem_object *obj = intel_fb->obj;

if (mmio_flip->req)
WARN_ON(__i915_wait_request(mmio_flip->req,
@@ -11196,6 +11203,12 @@ static void intel_mmio_flip_work_func(struct 
work_struct *work)
false, NULL,
_flip->i915->rps.mmioflips));

+   /* For framebuffer backed by dmabuf, wait for fence */
+   if (obj->base.dma_buf)
+   reservation_object_wait_timeout_rcu(obj->base.dma_buf->resv,
+   false, true,
+   MAX_SCHEDULE_TIMEOUT);
+
intel_do_mmio_flip(mmio_flip->crtc);

i915_gem_request_unreference__unlocked(mmio_flip->req);
-- 
1.9.1

[PATCH i915 v5 0/2] PRIME Synchronization

[Alex Goins]

Hello all,

For a while now, I've been working to fix tearing with PRIME. This is the
fifth version of the DRM component for PRIME synchronization.

v1 was a more complicated patch set that added an additional fenced
interface to page flipping. To avoid adding additional interfaces on top of
a legacy path, v2 scrapped those patches and changed i915 page flipping
paths to wait on fences attached to DMA-BUF-backed fbs. Subsequent versions
involve incremental changes outlined in the patch descriptions.

Repeat of overview below:

I have two patches, one that implements fencing for i915's legacy mmio_flip
path, and one for atomic modesetting for futureproofing. Currently the
mmio_flip path is the one ultimately used by the X patches, due to the lack
of asynchronous atomic modesetting support in i915.

With my synchronization patches to X, it is possible to export two shared
buffers per crtc instead of just one. The sink driver uses the legacy
drmModePageFlip() to flip between the buffers, as the rest of the driver
has yet to be ported to atomics. In the pageflip/vblank event handler, the
sink driver requests a present from the source using the new X ABI function
pScreen->PresentTrackedFlippingPixmap(). If the call returns successfully,
it uses drmModePageFlip() to flip to the updated buffer, otherwise it waits
until the next vblank and tries again.

When the source driver presents on a given buffer, it first attaches a
fence.  The source driver is responsible for either using software
signaling or hardware semaphore-backed fences to ensure the fence is
signaled when the present is finished. If the sink's DRM driver implements
fencing in the flipping path, it will guarantee that that flip won't occur
until the present has finished.

This means that DRM drivers that don't implement fencing in their flipping
paths won't be able to guarantee 100% tear-free PRIME with my X patches.
However, the good news is that even without fencing, tearing is rare.
Generally presenting finishes before the next vblank, so there is no need
to wait on the fence. The X patches are a drastic improvement with or
without fencing, but the fencing is nonetheless important to guarantee
tear-free under all conditions.

To give some greater context, I've uploaded my branches for DRM and the X
server to Github. I'll move forward with upstreaming the X changes if and
when these DRM patches go in.

DRM Tree:https://github.com/GoinsWithTheWind/drm-prime-sync
X Tree:  https://github.com/GoinsWithTheWind/xserver-prime-sync

(branch agoins-prime-v5)

Thanks, Alex @ NVIDIA Linux Driver Team

Alex Goins (2):
  i915: wait for fence in mmio_flip_work_func
  i915: wait for fence in prepare_plane_fb

 drivers/gpu/drm/i915/intel_display.c | 19 +++
 1 file changed, 19 insertions(+)

-- 
1.9.1

[PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Rob Herring]

+Stephen

On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja  
wrote:
> Hi Rob,
>
> On 11/18/2015 6:48 PM, Rob Herring wrote:
>>
>> +dt list
>>
>> On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja 
>> wrote:
>>>
>>> Add additional property info needed for DSIv2 DT.
>>
>>
>> Please use get_maintainers.pl.
>
>
> Sorry about that, missed out doing that posting this time.
>
>>
>>> Signed-off-by: Archit Taneja 
>>> ---
>>>   Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +-
>>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> b/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> index f344b9e..ca65a34 100644
>>> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> @@ -13,18 +13,25 @@ Required properties:
>>>   - power-domains: Should be < MDSS_GDSC>.
>>>   - clocks: device clocks
>>> See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
>>> details.
>>> -- clock-names: the following clocks are required:
>>> +- clock-names: these vary based on the DSI version. For DSI6G:
>>> * "bus_clk"
>>> * "byte_clk"
>>> +  * "byte_clk_src
>>
>>
>> This sounds like the parent of byte_clk. Is that really a clock within
>> the block?
>
>
> byte_clk_src isn't in the block, but byte_clk_src's parent is one of
> the PLLs in this block. We take this clock so that we can re-parent
> it to an appropriate PLL. The decision of what PLL to choose needs to
> be done by the DSI block's driver.

Seems like abuse to me. The list of clocks should match what are
inputs to the block, not what the driver happens to need. Without a
full understanding of the clock tree here, I don't have a suggestion.
Maybe Stephen does.

>>> * "core_clk"
>>> * "core_mmss_clk"
>>> * "iface_clk"
>>> * "mdp_core_clk"
>>> * "pixel_clk"
>>> +  * "pixel_clk_src"
>>> +  For DSIv2, we need a few more:
>>
>>
>> What is the overall order of clocks? As listed?
>
>
> Order in which the driver does clk_get? It uses the clock
> name to get each one individually, so the order doesn't matter
> as such.

The order in DT. You may use the names, but the order should still be specified.

Rob

[PATCH] GPU-DRM-IMX: Delete an unnecessary check before drm_fbdev_cma_restore_mode()

[Philipp Zabel]

Am Sonntag, den 05.07.2015, 22:50 +0200 schrieb SF Markus Elfring:
> From: Markus Elfring 
> Date: Sun, 5 Jul 2015 22:45:23 +0200
> 
> The drm_fbdev_cma_restore_mode() function tests whether its argument
> is NULL and then returns immediately.
> Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 74f505b..9172c0e 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -63,8 +63,7 @@ static void imx_drm_driver_lastclose(struct drm_device *drm)
>  #if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
>   struct imx_drm_device *imxdrm = drm->dev_private;
>  
> - if (imxdrm->fbhelper)
> - drm_fbdev_cma_restore_mode(imxdrm->fbhelper);
> + drm_fbdev_cma_restore_mode(imxdrm->fbhelper);
>  #endif
>  }
>  

Applied, sorry I missed this before.

regards
Philipp

[PATCH] drm/imx: parallel-display: allow to determine bus format from the connected panel

[Philipp Zabel]

Similarly to commit 5e501ed7253b3 ("drm/imx: imx-ldb: allow to determine
bus format from the connected panel"), if a panel is connected to the ldb
output port via the of_graph bindings, the data mapping is determined from
the display_info.bus_format field provided by the panel instead of from the
optional interface_pix_fmt device tree property.

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

diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index b4deb9c..2e9b9f1 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -54,7 +54,11 @@ static int imx_pd_connector_get_modes(struct drm_connector 
*connector)

if (imxpd->panel && imxpd->panel->funcs &&
imxpd->panel->funcs->get_modes) {
+   struct drm_display_info *di = >display_info;
+
num_modes = imxpd->panel->funcs->get_modes(imxpd->panel);
+   if (!imxpd->bus_format && di->num_bus_formats)
+   imxpd->bus_format = di->bus_formats[0];
if (num_modes > 0)
return num_modes;
}
-- 
2.6.2

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello Inki,

On 11/20/2015 08:13 AM, Inki Dae wrote:
> 
> 
> 2015년 11월 20일 19:59에 Inki Dae 이(가) 쓴 글:
>> Hi Javier,
>>
>> 2015년 11월 20일 00:51에 Javier Martinez Canillas 이(가) 쓴 글:
>>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>>>>
>>>>>
>>>>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>>>>> Chromebook (tested myself) and seems to be the cause of other Exynos
>>>>> boards failing to boot: http://kernelci.org/boot/?exynos
>>>>>
>>>>> [snip]
>>>>>
>>>>>>   drm/exynos: add pm_runtime to Mixer
>>>>>>   drm/exynos: add pm_runtime to FIMD
>>>>>
>>>>> I had to revert these patches in order to get the machine in a bootable
>>>>> state again, the sha1 hash for these patches in next-20151119 are:
>>>>>
>>>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD
>>>
>>> On a closer look, only reverting the FIMD patch is enough
>>> to make at least the Exynos5800 Peach Pi to boot again.
>>
>> Thanks for report.
>>
>> I assume that the issue is because above patch removed 'suspended' variable
>> for checking the suspend status in runtime so I revived it.
>>
>> I'm not sure that the change could resolve the issue. Could you test it
>> with the change again? I have no Exynos5800 Peach Pi board. :(
>>
>> For this, I pushed it to below exynos-drm/for-next branch,
>>  
>> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c
>>
>> If the issue is resolved by the change then I will modify other patches for
>> DECON series. And if really so, there may be a corner case we missed.
> 
> Oops, I found out one error at the boot log,
> http://storage.kernelci.org/next/next-20151120/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-collabora/boot-exynos5800-peach-pi.html
> 
> The boot log says,
> [5.754493] vdd_ldo9: supplied by vdd_2v
> [5.765510] of_graph_get_next_endpoint(): no port node found in 
> /dp-controller at 145B
>

This message is a red herring for the reported issue, the message is also
present when the machine boots and the display is brought correctly.

> Seems this error is because exynos5800-peach-pit.dts file doesn't have 
> 'ports' node in dp node.
>
> Below is dp node description of exynos5420-peach-pit.dts file.
>  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
>   samsung,dynamic-range = <0>;
>   samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x06>;
>   samsung,lane-count = <2>;
>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
> 
>   ports {
>   port at 0 {
>   dp_out: endpoint {
>   remote-endpoint = <_in>;
>   };
>   };
>   };
> };
> 
> And below is for exynos5800-peash-pit.dts,
>  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
>   samsung,dynamic-range = <0>;
>   samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x0a>;
>   samsung,lane-count = <2>;
>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>   panel = <>;
> };
> 

The difference is because the Exynos5420 Peach Pit Display Port is not
attached directly to the display panel, there is an eDP/LVDS bridge chip
in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.

The Exynos DP driver lookups for either a panel phandle or an OF graph
endpoint that points to a bridge chip and the bridge enpoint has a port
that points to the panel.

So the DT is correct but of_graph_get_next_endpoint() always prints an
error if the port so OF graph endpoints it seems can't be optional as
used in this driver. Maybe that message should be change to debug then?

Another option is to extend the DP driver DT binding to be more generic
supporting having a port to a panel besides a bridge, so we could have
something like this for Exynos5800 Peach and be consistent in both cases:

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e451880..9c6fd7314ee0 100644
--- a/arch/arm/boot/d

[PATCH i915 v4 1/2] i915: wait for fences in mmio_flip()

[Ville Syrjälä]

On Thu, Nov 19, 2015 at 07:51:25PM -0800, Alex Goins wrote:
> If a buffer is backed by dmabuf, wait on its reservation object's fences
> before flipping.
> 
> Signed-off-by: Alex Goins 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b2270d5..4867ff0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -44,6 +44,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /* Primary plane formats for gen <= 3 */
>  static const uint32_t i8xx_primary_formats[] = {
> @@ -11088,6 +11090,8 @@ static bool use_mmio_flip(struct intel_engine_cs 
> *ring,
>   return true;
>   else if (i915.enable_execlists)
>   return true;
> + else if (obj->base.dma_buf && obj->base.dma_buf->resv->fence_excl)
> + return true;
>   else
>   return ring != i915_gem_request_get_ring(obj->last_write_req);
>  }
> @@ -11170,8 +11174,18 @@ static void ilk_do_mmio_flip(struct intel_crtc 
> *intel_crtc)
>  static void intel_do_mmio_flip(struct intel_crtc *intel_crtc)
>  {
>   struct drm_device *dev = intel_crtc->base.dev;
> + struct intel_framebuffer *intel_fb =
> + to_intel_framebuffer(intel_crtc->base.primary->fb);
> + struct drm_i915_gem_object *obj = intel_fb->obj;
>   u32 start_vbl_count;
>  
> + /* For framebuffer backed by dmabuf, wait for fence */
> + if (obj->base.dma_buf) {
> + reservation_object_wait_timeout_rcu(
> + obj->base.dma_buf->resv,
> + false, true, MAX_SCHEDULE_TIMEOUT);
> + }
> +

Why is this in do_mmio_flip() rather than next to the normal seqno wait
at the previous level?

>   intel_mark_page_flip_active(intel_crtc);
>  
>   intel_pipe_update_start(intel_crtc, _vbl_count);
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello Inki,

On 11/20/2015 07:59 AM, Inki Dae wrote:
> Hi Javier,
> 
> 2015년 11월 20일 00:51에 Javier Martinez Canillas 이(가) 쓴 글:
>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>

 This series causes a boot failure on at least an Exynos5800 Peach Pi
 Chromebook (tested myself) and seems to be the cause of other Exynos
 boards failing to boot: http://kernelci.org/boot/?exynos

 [snip]

>   drm/exynos: add pm_runtime to Mixer
>   drm/exynos: add pm_runtime to FIMD

 I had to revert these patches in order to get the machine in a bootable
 state again, the sha1 hash for these patches in next-20151119 are:

 045febd5f813 drm/exynos: add pm_runtime to FIMD
>>
>> On a closer look, only reverting the FIMD patch is enough
>> to make at least the Exynos5800 Peach Pi to boot again.
> 
> Thanks for report.
>

Thanks to you for the quick answer and providing a fix.

> I assume that the issue is because above patch removed 'suspended' variable
> for checking the suspend status in runtime so I revived it.
>

It seems your assumption was correct...

> I'm not sure that the change could resolve the issue. Could you test it
> with the change again? I have no Exynos5800 Peach Pi board. :(
> 
> For this, I pushed it to below exynos-drm/for-next branch,
>   
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c
> 
> If the issue is resolved by the change then I will modify other patches for
> DECON series. And if really so, there may be a corner case we missed.
>

... since I reverted the offending commit and cherry-picked the one
in your for-next branch and the machine booted again.

> Thanks,
> Inki Dae
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[Bug 93039] [APITRACE] Google earth bad colors when tilted

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

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

Christoph Brill  changed:

   What|Removed |Added

 Attachment #119982|text/plain  |image/jpg
  mime type||

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

[Bug 93039] [APITRACE] Google earth bad colors when tilted

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

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

Bug ID: 93039
   Summary: [APITRACE] Google earth bad colors when tilted
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: egore at gmx.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 119982
  --> https://bugs.freedesktop.org/attachment.cgi?id=119982=edit
Screenshot of the problem

When tilting the view in Google Maps the color turn yellow and red. Work for
non-tilted and slightly tilted. Also works on i965.

APITRACE can be found at:
https://drive.google.com/file/d/0BxAIK4wsKm_YNXgzbXRObDdveE0/view?usp=sharing

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

[Bug 93015] Tonga Elemental segfault + VM faults since radeon: implement r600_query_hw_get_result via function pointers

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

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

--- Comment #4 from Nicolai Hähnle  ---
Created attachment 119981
  --> https://bugs.freedesktop.org/attachment.cgi?id=119981=edit
related patch

Okay, so I understand what failed and why it worked before.

Could you please test both patches? The first one should fix your problem, the
second one is a related cleanup on top of it that hopefully contains no
regressions.

[I have apparently unrelated weirdness going on right now which prevents me
from testing this properly.]

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

[Bug 93015] Tonga Elemental segfault + VM faults since radeon: implement r600_query_hw_get_result via function pointers

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

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

--- Comment #3 from Nicolai Hähnle  ---
Created attachment 119980
  --> https://bugs.freedesktop.org/attachment.cgi?id=119980=edit
patch that should fix the bug

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

[PATCH v3 00/12] Add mipi dsi support for rk3288

[Emil Velikov]

On 20 November 2015 at 07:02, Chris Zhong  wrote:
> Hi Emil
>
> On 11/19/2015 10:41 PM, Emil Velikov wrote:
>>
>> On 19 November 2015 at 03:35, Chris Zhong  wrote:
>>>
>>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>>> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
>>> controller DRM bridge driver and a rockchip MIPI DSI specific DRM
>>> driver.
>>>
>>> This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
>>> This panel only use the MIPI DSI video mode.
>>>
>>> The MIPI DSI feature is tested on rk3288 evb board, backport them to
>>> chrome os kernel v3.14, and it can display normally.
>>>
>>> This patchset is base on the patchset from Ying.liu at freescale.com.
>>> 
>>>
>>>
>>> Changes in v3:
>>> move the dw_mipi_dsi.txt to
>>> Documentation/devicetree/bindings/display/bridge
>>> move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
>>> move boe,tv080wum-nl0.txt to bindings/display/panel/
>>>
>>> Changes in v2:
>>> add the mipi clk id in a single patch
>>> As Thierry.Reding comment, add a documentation for this panel.
>>>
>>> Chris Zhong (10):
>>>clk: rockchip: add id for mipidsi sclk on rk3288
>>>clk: rockchip: add mipidsi clocks on rk3288
>>>drm/rockchip: return a true clock rate to adjusted_mode
>>>drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
>>
>> Did you actually rewrite the patch from Liu Ying ?
>
> I modify the dw_mipi_dsi.c based on the patch from Liu Ying.
If you base your work on top of (i.e. you rework) someone else's patch
you should retain this authorship and signed-off-by line. This of
course is not limited to the above patch but a general rule, afaik.

>>
>> Out of curiosity what was the obstacle of this work getting merged ?
>
> There are different version dw controller, and it is too hard to merge them,
> since most registers are different.
Have you discussed this limitation with Liu ? Does your work handle
both versions of the controller ? If so your commit message should say
something about that. Here are some good sources on the whats and whys
wrt writing good commit messages [1] [2]

[1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html
[2] http://chris.beams.io/posts/git-commit/

>>
>>
>>>drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
>>>Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
>>>ARM: dts: rockchip: add rk3288 mipi_dsi nodes
>>>drm/panel: simple: Add support for BOE TV080WUM-NL0
>>>drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
>>>  binding
>>
>> As the DT people will tell you - there is no BOE vendor in
>> bindings/vendor-prefixes.txt.
>
> Yes, I have post a verdor patch in v2 series,
> 
> Maybe I should add it back to series with
>
> Acked-by: Rob Herring
>
If a patch has been reviewed/acked that's great. Add the tag, but
please do not drop patches until they are merged. In the latter case
you can mention that your series depends on branch X from repo Y.

>>
>>>ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb
>>>
>>> Liu Ying (2):
>>>drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
>>>Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
>>>  bridge driver
>>>
>> >From the above 12 patches only ~6 reached this mailing list is that
>> intentional ? Previously I've seen people CC dri-devel for their
>> panel/bridge DT patches.
>
> I use the patman to post the series, forgot to add you and Thierry to the
> to-list.
> I will fix in next version series. Thanks for your reply.
>
No need to add me bth. Thierry on the other hand should be Cc'd on the
patches where he's the maintainer.

As the To/Cc list is already quite excessive - I'd suggest following
the approach used by veterans in kernel development.

I'm not a veteran kernel dev, but this is what I've noticed over the years:
 - Subsystem foo - mailing-list, maintainer(s), and optionally the top
1-2 developers
 - Other subsystems - mailing-list and optionally the maintainer(s).

Thus in the case of the panel driver you'll get - dri-devel, Thierry
and optionally(?) devicetree
For the DT binding for the panel driver - devicetree, Rob, dri-devel, Thierry.

...I think you get the idea :-)

Regards,
Emil

[PATCH RFC] drm/crtc_helper: Add drm_crtc_helper_disable_planes()

[Jyri Sarha]

Add drm_crtc_helper_disable_planes() for disabling all planes
associated with the given CRTC and having disable callback. This can
be used for instance in CRTC helper disable callback.

Signed-off-by: Jyri Sarha 
---
So it appears that this is the only missing piece for disabling and
enabling planes with their associated CRTCs for the times when the
CRTCs are blanked or otherwise unused.

 drivers/gpu/drm/drm_crtc_helper.c | 26 ++
 include/drm/drm_crtc_helper.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index ef53475..335 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -410,6 +410,32 @@ done:
 }
 EXPORT_SYMBOL(drm_crtc_helper_set_mode);

+/**
+ * drm_crtc_helper_disable_planes - helper to disable CRTC's planes
+ * @crtc: CRTC
+ *
+ * Disables all planes associated with the given CRTC and having
+ * disable callback. This can be used for instance in CRTC helper
+ * disable callback.
+ */
+void drm_crtc_helper_disable_planes(struct drm_crtc *crtc)
+{
+   struct drm_plane *plane;
+   int i;
+
+   drm_for_each_plane(plane, crtc->dev) {
+   const struct drm_plane_helper_funcs *plane_funcs =
+   plane->helper_private;
+
+   if (plane->state->crtc != crtc || !plane_funcs)
+   continue;
+
+   if (plane_funcs->atomic_disable)
+   plane_funcs->atomic_disable(plane, NULL);
+   }
+}
+EXPORT_SYMBOL(drm_crtc_helper_disable_planes);
+
 static void
 drm_crtc_helper_disable(struct drm_crtc *crtc)
 {
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 3febb4b..d47051f 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -189,6 +189,7 @@ extern bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
 struct drm_display_mode *mode,
 int x, int y,
 struct drm_framebuffer *old_fb);
+extern void drm_crtc_helper_disable_planes(struct drm_crtc *crtc);
 extern bool drm_helper_crtc_in_use(struct drm_crtc *crtc);
 extern bool drm_helper_encoder_in_use(struct drm_encoder *encoder);

-- 
1.9.1

[PATCH] [drm-fixes] drm/ttm: Fixed a read/write lock imbalance

[Sinclair Yeh]

From: Thomas Hellstrom 

In ttm_write_lock(), the uninterruptible path should call
__ttm_write_lock() not __ttm_read_lock().  This fixes a vmwgfx hang
on F23 start up.

syeh: Extracted this from one of Thomas' internal patches.

Cc: 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/ttm/ttm_lock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_lock.c b/drivers/gpu/drm/ttm/ttm_lock.c
index 6a95454..f154fb1 100644
--- a/drivers/gpu/drm/ttm/ttm_lock.c
+++ b/drivers/gpu/drm/ttm/ttm_lock.c
@@ -180,7 +180,7 @@ int ttm_write_lock(struct ttm_lock *lock, bool 
interruptible)
spin_unlock(>lock);
}
} else
-   wait_event(lock->queue, __ttm_read_lock(lock));
+   wait_event(lock->queue, __ttm_write_lock(lock));

return ret;
 }
-- 
1.9.1

[PATCH RFC] drm/crtc_helper: Add drm_crtc_helper_disable_planes()

[Daniel Vetter]

On Fri, Nov 20, 2015 at 12:03:41PM +0200, Jyri Sarha wrote:
> Add drm_crtc_helper_disable_planes() for disabling all planes
> associated with the given CRTC and having disable callback. This can
> be used for instance in CRTC helper disable callback.
> 
> Signed-off-by: Jyri Sarha 
> ---
> So it appears that this is the only missing piece for disabling and
> enabling planes with their associated CRTCs for the times when the
> CRTCs are blanked or otherwise unused.
> 
>  drivers/gpu/drm/drm_crtc_helper.c | 26 ++
>  include/drm/drm_crtc_helper.h |  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index ef53475..335 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -410,6 +410,32 @@ done:
>  }
>  EXPORT_SYMBOL(drm_crtc_helper_set_mode);
>  
> +/**
> + * drm_crtc_helper_disable_planes - helper to disable CRTC's planes
> + * @crtc: CRTC
> + *
> + * Disables all planes associated with the given CRTC and having
> + * disable callback. This can be used for instance in CRTC helper

s/in CRTC/in the CRTC/


> + * disable callback.

"... to disable all planes before shutting down the display pipeline."
just to clarify usage.

One open is whether we should call the crtc-level atomic_begin/flush
functions. I think adding that would be good, to avoid tearing while
disabling planes. If drivers need different behaviour we can always add a
knob to select the right one (i.e. with or without atomic_begin/flush).

> + */
> +void drm_crtc_helper_disable_planes(struct drm_crtc *crtc)

This function only makes sense for atomic drivers, so should be in
drm_atomic_helper.c. drm_crtc_helper.c is the legacy helper library for
non-atomic drivers.

Also needs a different name then, for example
drm_atomic_helper_disable_planes_on_crtc, for consistency with
drm_atomic_helper_commit_planes_on_crtc

> +{
> + struct drm_plane *plane;
> + int i;
> +
> + drm_for_each_plane(plane, crtc->dev) {
> + const struct drm_plane_helper_funcs *plane_funcs =
> + plane->helper_private;
> +
> + if (plane->state->crtc != crtc || !plane_funcs)
> + continue;
> +
> + if (plane_funcs->atomic_disable)
> + plane_funcs->atomic_disable(plane, NULL);

Imo WARN_ON(!plane_funcs->atomic_disable); since calling this function
without having disable hooks really doesn't make sense. Please also update
the kerneldoc with something like "It is a bug to call this function
without having implemented the ->atomic_disable() plane hook."

Cheers, Daniel

> + }
> +}
> +EXPORT_SYMBOL(drm_crtc_helper_disable_planes);
> +
>  static void
>  drm_crtc_helper_disable(struct drm_crtc *crtc)
>  {
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 3febb4b..d47051f 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -189,6 +189,7 @@ extern bool drm_crtc_helper_set_mode(struct drm_crtc 
> *crtc,
>struct drm_display_mode *mode,
>int x, int y,
>struct drm_framebuffer *old_fb);
> +extern void drm_crtc_helper_disable_planes(struct drm_crtc *crtc);
>  extern bool drm_helper_crtc_in_use(struct drm_crtc *crtc);
>  extern bool drm_helper_encoder_in_use(struct drm_encoder *encoder);
>  
> -- 
> 1.9.1
> 

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

[Bug 106901] Brightness / WIFI Key does not generate any events

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

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

--- Comment #17 from Roman Gruber  ---
Basically same .config for this 4.3.0 kernel

I can upload it when someone needs it.

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

[Bug 106901] Brightness / WIFI Key does not generate any events

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

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

Roman Gruber  changed:

   What|Removed |Added

 Kernel Version|Linux ASUS-G75VW|Linux ASUS-G75VW
   |4.2.5-gentoo_2015-10-29 #2  |4.3.0-gentoo_2015-11-19 #1
   |SMP Thu Oct 29 19:00:18 CET |SMP Thu Nov 19 13:21:56 CET
   |2015 x86_64 Intel(R)|2015 x86_64 Intel(R)
   |Core(TM) i7-3610QM CPU @|Core(TM) i7-3610QM CPU @
   |2.30GHz GenuineIntel|2.30GHz GenuineIntel
   |GNU/Linux   |GNU/Linux

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

[Bug 106901] Brightness / WIFI Key does not generate any events

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

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

--- Comment #16 from Roman Gruber  ---
I updated the kernel, same behaviour

uname -a;dmesg|tail -20
Linux ASUS-G75VW 4.3.0-gentoo_2015-11-19 #1 SMP Thu Nov 19 13:21:56 CET 2015
x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux
[  147.642024] vgaarb: device changed decodes:
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[  147.642250] NVLINK: Nvlink Core is being initialized, major device number
245
[  147.642354] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on
minor 0
[  147.642359] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  355.11  Wed Aug
26 16:35:41 PDT 2015
[  147.646814] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.646868] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.646903] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.646935] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.646983] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.647019] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.647051] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.647086] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.647163] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  147.997987] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  148.183638] i2c i2c-0: adapter [NVIDIA i2c adapter 0 at 1:00.0] registered
[  148.183856] i2c i2c-1: adapter [NVIDIA i2c adapter 1 at 1:00.0] registered
[  148.183923] i2c i2c-2: adapter [NVIDIA i2c adapter 2 at 1:00.0] registered
[  148.184025] i2c i2c-3: adapter [NVIDIA i2c adapter 6 at 1:00.0] registered
[  148.184084] i2c i2c-4: adapter [NVIDIA i2c adapter 8 at 1:00.0] registered
[  148.184254] i2c i2c-5: adapter [NVIDIA i2c adapter 10 at 1:00.0] registered

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

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[cp...@redhat.com]

From: Stephen Chandler Paul 

HPD signals on DVI ports can be fired off before the pins required for
DDC probing actually make contact, due to the pins for HPD making
contact first. This results in a HPD signal being asserted but DDC
probing failing, resulting in hotplugging occasionally failing.

This is somewhat rare on most cards (depending on what angle you plug
the DVI connector in), but on some cards it happens constantly. The
Radeon R5 on the machine used for testing this patch for instance, runs
into this issue just about every time I try to hotplug a DVI monitor and
as a result hotplugging almost never works.

Rescheduling the hotplug work for a second when we run into an HPD
signal with a failing DDC probe usually gives enough time for the rest
of the connector's pins to make contact, and fixes this issue.

Signed-off-by: Stephen Chandler Paul 
---
So this one has kind of been a tough sell with Jerome, mostly because it's
somewhat of a hack. Unfortunately however I've managed to find machines where
DVI hotplugging literally doesn't work without a patch like this. We've already
tried a couple of ways of handling the situation of retriggering ddc probes:

* Trying the DDC probe in the radeon_dvi_detect() function multiple times.
* Trying to reschedule the hotplug_work task whenever DDC probing fails on DVI
  but we got a hpd signal (this ended up being a much more complicated patch
  then anticipated)
* Doing what we do right now, which is just triggering userspace to rescan all
  the ports when the hpd signal is asserted by the DVI port but there's no DDC
  probe, and repeating until at least a second passes.

All of these actually work, but I guess it's a question of which one is less of
a hack. If anyone here can think of a cleaner way of handling this feel free to
let me know.

 drivers/gpu/drm/radeon/radeon.h|  3 +++
 drivers/gpu/drm/radeon/radeon_connectors.c | 20 +---
 drivers/gpu/drm/radeon/radeon_irq_kms.c|  2 ++
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b6cbd81..d63f0fe 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2460,6 +2460,9 @@ struct radeon_device {
/* amdkfd interface */
struct kfd_dev  *kfd;

+   /* last time we received an hpd signal */
+   unsigned long hpd_time;
+
struct mutexmn_lock;
DECLARE_HASHTABLE(mn_hash, 7);
 };
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5a2cafb..4ee9440 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1228,19 +1228,33 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
force)
const struct drm_encoder_helper_funcs *encoder_funcs;
int i, r;
enum drm_connector_status ret = connector_status_disconnected;
-   bool dret = false, broken_edid = false;
+   bool dret = false, broken_edid = false, hpd_unchanged;

r = pm_runtime_get_sync(connector->dev->dev);
if (r < 0)
return connector_status_disconnected;

-   if (!force && radeon_check_hpd_status_unchanged(connector)) {
+   hpd_unchanged = radeon_check_hpd_status_unchanged(connector);
+   if (!force && hpd_unchanged) {
ret = connector->status;
goto exit;
}

-   if (radeon_connector->ddc_bus)
+   if (radeon_connector->ddc_bus) {
dret = radeon_ddc_probe(radeon_connector, false);
+
+   /* Sometimes the pins required for the DDC probe on DVI
+* connectors don't make contact at the same time that the ones
+* for HPD do. If the DDC probe fails even though we had an HPD
+* signal, signal userspace to try again */
+   if (!dret && !hpd_unchanged &&
+   connector->status != connector_status_connected &&
+   time_before(jiffies, rdev->hpd_time + 
msecs_to_jiffies(1000))) {
+   DRM_DEBUG_KMS("%s: hpd asserted but ddc probe failed, 
retrying\n",
+ connector->name);
+   drm_sysfs_hotplug_event(dev);
+   }
+   }
if (dret) {
radeon_connector->detected_by_load = false;
radeon_connector_free_edid(connector);
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 171d3e4..579c22c 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,6 +79,8 @@ static void radeon_hotplug_work_func(struct work_struct *work)
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;

+   rdev->hpd_time = jiffies;
+
/* we can race here at startup, some boards seem to 

[Bug 93015] Tonga Elemental segfault + VM faults since radeon: implement r600_query_hw_get_result via function pointers

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

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

--- Comment #2 from Nicolai Hähnle  ---
Hi Andy, thanks for the report! I can reproduce the crash, it does indeed seem
to be related to buffer handling, I am investigating.

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

[PATCH] drm/exynos: only run atomic_check() if crtc is active

[Andrzej Hajda]

On 11/17/2015 05:12 PM, Daniel Vetter wrote:

(...)
> 
> Check crtc_state->enable, skip if false. That's the "is this pipeline
> configured" knob. For plane/connector it's state->crtc, but with the same
> role.
> 
> I guess we could check that in the helpers, but we need to be careful to
> still call ->atomic_check for the disabling transition, in case userspace
> is asking for a vblank-synced flip that disables a plane but somehow
> that's not possible. I somewhat prefer to handle that all in drivers
> though.
> -Daniel
> 

Thanks for the explanation, Gustavo will you update your patch?

Regards
Andrzej

[PATCH] drm/sysfs: Send out uevent when connector->force changes

[Chris Wilson]

On Fri, Nov 20, 2015 at 09:11:00AM +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2015 at 09:06:04PM +, Chris Wilson wrote:
> > On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> > > To avoid even more code duplication punt this all to the probe worker,
> > > which needs some slight adjustment to also generate a uevent when the
> > > status has changed to due connector->force.
> > > 
> > > v2: Instead of running the output_poll_work (which is kinda the wrong
> > > thing and a layering violation since it's an internal of the probe
> > > helpers), or calling ->detect (which is again a layering violation
> > > since it's used only by probe helpers) just call the official
> > > ->fill_modes function, like a GET_CONNECTOR ioctl call.
> > > 
> > > v3: Restore the accidentally removed forced-probe for echo "detect" >
> > > force.
> > > 
> > 
> > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > index 9ac4ffa6cce3..df66d9447cb0 100644
> > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > @@ -167,47 +167,35 @@ static ssize_t status_store(struct device *device,
> > >  {
> > >   struct drm_connector *connector = to_drm_connector(device);
> > >   struct drm_device *dev = connector->dev;
> > > - enum drm_connector_status old_status;
> > > + enum drm_connector_force old_force;
> > >   int ret;
> > >  
> > >   ret = mutex_lock_interruptible(>mode_config.mutex);
> > >   if (ret)
> > >   return ret;
> > >  
> > > - old_status = connector->status;
> > > + old_force = connector->force;
> > >  
> > > - if (sysfs_streq(buf, "detect")) {
> > > + if (sysfs_streq(buf, "detect"))
> > >   connector->force = 0;
> > > - connector->status = connector->funcs->detect(connector, true);
> > > - } else if (sysfs_streq(buf, "on")) {
> > > + else if (sysfs_streq(buf, "on"))
> > >   connector->force = DRM_FORCE_ON;
> > > - } else if (sysfs_streq(buf, "on-digital")) {
> > > + else if (sysfs_streq(buf, "on-digital"))
> > >   connector->force = DRM_FORCE_ON_DIGITAL;
> > > - } else if (sysfs_streq(buf, "off")) {
> > > + else if (sysfs_streq(buf, "off"))
> > >   connector->force = DRM_FORCE_OFF;
> > > - } else
> > > + else
> > >   ret = -EINVAL;
> > >  
> > > - if (ret == 0 && connector->force) {
> > > - if (connector->force == DRM_FORCE_ON ||
> > > - connector->force == DRM_FORCE_ON_DIGITAL)
> > > - connector->status = connector_status_connected;
> > > - else
> > > - connector->status = connector_status_disconnected;
> > > - if (connector->funcs->force)
> > > - connector->funcs->force(connector);
> > > - }
> > > -
> > > - if (old_status != connector->status) {
> > > - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> > > %d\n",
> > > + if (old_force != connector->force || !connector->force) {
> > > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force updated from %d to %d or 
> > > reprobing\n",
> > > connector->base.id,
> > > connector->name,
> > > -   old_status, connector->status);
> > > +   old_force, connector->force);
> > >  
> > > - dev->mode_config.delayed_event = true;
> > > - if (dev->mode_config.poll_enabled)
> > > - 
> > > schedule_delayed_work(>mode_config.output_poll_work,
> > > -   0);
> > > + connector->funcs->fill_modes(connector,
> > > +  dev->mode_config.max_width,
> > > +  dev->mode_config.max_height);
> > 
> > This now does fill_modes() before we call detect(). We rely on the
> > ordering of detect() before doing fill_modes() as in many cases we use
> > the EDID gathered in detect() to generate the modes (if I am not
> > mistaken, I think we merged those patches to cache the EDID for a
> > detection cycle).
> 
> ->fill_modes = drm_helper_probe_single_connector_modes which then calls
> ->detect. By going this way we avoid duplicating the "send uevent if
> anything changed" logic all over the place, and ->detect becomes purely a
> helper internal callback to get at the mode list for hotpluggeable
> outputs.

Ok, that struck me as a little surprising - I was thinking of lower level
get_modes apparently.

With that resolved,
Reviewed-by: Chris Wilson 

> Yes this means that ->detect should become a helper function, but that's
> quite an invasive change.

And something like .fill_modes -> .probe (after removing .detect).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH i915 v4 1/2] i915: wait for fences in mmio_flip()

[Daniel Vetter]

On Thu, Nov 19, 2015 at 07:51:25PM -0800, Alex Goins wrote:
> If a buffer is backed by dmabuf, wait on its reservation object's fences
> before flipping.
> 
> Signed-off-by: Alex Goins 

When resending patches please add a per-revision changelog to each patch
with notes what changed. Otherwise reviewers have to recollect all the
context themselves by digging through old threads.

Can you please resend with that added?

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b2270d5..4867ff0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -44,6 +44,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /* Primary plane formats for gen <= 3 */
>  static const uint32_t i8xx_primary_formats[] = {
> @@ -11088,6 +11090,8 @@ static bool use_mmio_flip(struct intel_engine_cs 
> *ring,
>   return true;
>   else if (i915.enable_execlists)
>   return true;
> + else if (obj->base.dma_buf && obj->base.dma_buf->resv->fence_excl)
> + return true;
>   else
>   return ring != i915_gem_request_get_ring(obj->last_write_req);
>  }
> @@ -11170,8 +11174,18 @@ static void ilk_do_mmio_flip(struct intel_crtc 
> *intel_crtc)
>  static void intel_do_mmio_flip(struct intel_crtc *intel_crtc)
>  {
>   struct drm_device *dev = intel_crtc->base.dev;
> + struct intel_framebuffer *intel_fb =
> + to_intel_framebuffer(intel_crtc->base.primary->fb);
> + struct drm_i915_gem_object *obj = intel_fb->obj;
>   u32 start_vbl_count;
>  
> + /* For framebuffer backed by dmabuf, wait for fence */
> + if (obj->base.dma_buf) {
> + reservation_object_wait_timeout_rcu(
> + obj->base.dma_buf->resv,
> + false, true, MAX_SCHEDULE_TIMEOUT);
> + }
> +
>   intel_mark_page_flip_active(intel_crtc);
>  
>   intel_pipe_update_start(intel_crtc, _vbl_count);
> -- 
> 1.9.1
> 
> 
> ---
> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information.  Any unauthorized review, use, disclosure or 
> distribution
> is prohibited.  If you are not the intended recipient, please contact the 
> sender by
> reply email and destroy all copies of the original message.
> ---

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

[PATCH] drm/sysfs: Send out uevent when connector->force changes

[Daniel Vetter]

On Thu, Nov 19, 2015 at 09:06:04PM +, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> > To avoid even more code duplication punt this all to the probe worker,
> > which needs some slight adjustment to also generate a uevent when the
> > status has changed to due connector->force.
> > 
> > v2: Instead of running the output_poll_work (which is kinda the wrong
> > thing and a layering violation since it's an internal of the probe
> > helpers), or calling ->detect (which is again a layering violation
> > since it's used only by probe helpers) just call the official
> > ->fill_modes function, like a GET_CONNECTOR ioctl call.
> > 
> > v3: Restore the accidentally removed forced-probe for echo "detect" >
> > force.
> > 
> 
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index 9ac4ffa6cce3..df66d9447cb0 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -167,47 +167,35 @@ static ssize_t status_store(struct device *device,
> >  {
> > struct drm_connector *connector = to_drm_connector(device);
> > struct drm_device *dev = connector->dev;
> > -   enum drm_connector_status old_status;
> > +   enum drm_connector_force old_force;
> > int ret;
> >  
> > ret = mutex_lock_interruptible(>mode_config.mutex);
> > if (ret)
> > return ret;
> >  
> > -   old_status = connector->status;
> > +   old_force = connector->force;
> >  
> > -   if (sysfs_streq(buf, "detect")) {
> > +   if (sysfs_streq(buf, "detect"))
> > connector->force = 0;
> > -   connector->status = connector->funcs->detect(connector, true);
> > -   } else if (sysfs_streq(buf, "on")) {
> > +   else if (sysfs_streq(buf, "on"))
> > connector->force = DRM_FORCE_ON;
> > -   } else if (sysfs_streq(buf, "on-digital")) {
> > +   else if (sysfs_streq(buf, "on-digital"))
> > connector->force = DRM_FORCE_ON_DIGITAL;
> > -   } else if (sysfs_streq(buf, "off")) {
> > +   else if (sysfs_streq(buf, "off"))
> > connector->force = DRM_FORCE_OFF;
> > -   } else
> > +   else
> > ret = -EINVAL;
> >  
> > -   if (ret == 0 && connector->force) {
> > -   if (connector->force == DRM_FORCE_ON ||
> > -   connector->force == DRM_FORCE_ON_DIGITAL)
> > -   connector->status = connector_status_connected;
> > -   else
> > -   connector->status = connector_status_disconnected;
> > -   if (connector->funcs->force)
> > -   connector->funcs->force(connector);
> > -   }
> > -
> > -   if (old_status != connector->status) {
> > -   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> > %d\n",
> > +   if (old_force != connector->force || !connector->force) {
> > +   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force updated from %d to %d or 
> > reprobing\n",
> >   connector->base.id,
> >   connector->name,
> > - old_status, connector->status);
> > + old_force, connector->force);
> >  
> > -   dev->mode_config.delayed_event = true;
> > -   if (dev->mode_config.poll_enabled)
> > -   
> > schedule_delayed_work(>mode_config.output_poll_work,
> > - 0);
> > +   connector->funcs->fill_modes(connector,
> > +dev->mode_config.max_width,
> > +dev->mode_config.max_height);
> 
> This now does fill_modes() before we call detect(). We rely on the
> ordering of detect() before doing fill_modes() as in many cases we use
> the EDID gathered in detect() to generate the modes (if I am not
> mistaken, I think we merged those patches to cache the EDID for a
> detection cycle).

->fill_modes = drm_helper_probe_single_connector_modes which then calls
->detect. By going this way we avoid duplicating the "send uevent if
anything changed" logic all over the place, and ->detect becomes purely a
helper internal callback to get at the mode list for hotpluggeable
outputs.

Yes this means that ->detect should become a helper function, but that's
quite an invasive change.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 92923] SGPR spilling

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

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

--- Comment #4 from Michel Dänzer  ---
(In reply to pat from comment #3)
> Steam seems to mess with stderr, I hope this game log has the info you need.

It does, thanks.

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

--- Comment #3 from Michel Dänzer  ---
One report per issue, please. Since there are already several reports about
lockups with XCOM: Enemy Unknown, let's focus on the Civilization Beyond Earth
segfault here? Please attach a backtrace of the segfault.

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

[PATCH v4 05/13] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver

[Rob Herring]

On Fri, Nov 20, 2015 at 04:15:31PM +0800, Chris Zhong wrote:
> From: Liu Ying 
> 
> This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
> host controller DRM bridge driver.
> 
> Signed-off-by: Liu Ying 
> Signed-off-by: Chris Zhong 

One nit, but:

Acked-by: Rob Herring 

> Changes in v4:
> remove gpr property from example, since it is noused now.
> add the description about ports

[...]

> +example:
> + gpr: iomuxc-gpr at 020e {
> + /* ... */
> + };

This is still lingering.

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

 None
0x09b 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x09c 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x09d 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x09e 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x09f 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x0a0 24 tc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x0a1 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0a2 24 tc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0a3  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x0a4  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x0a5 32 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0a6 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x0a7 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0a8 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x0a9  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  4 1 None
0x0aa  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  8 1 None
0x0ab  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  4 1 None
0x0ac  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  8 1 None
0x0ad 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x0ae 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x0af 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None
0x0b0 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x0b1 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  4 1 None
0x0b2 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  8 1 None
0x0b3 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  4 1 None
0x0b4 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  8 1 None
0x0b5  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x0b6  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x0b7  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x0b8  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x0b9  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0ba  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0bb 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0bc 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0bd 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0be 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0bf 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x0c0 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x0c1 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0c2 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0c3  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x0c4  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x0c5 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0c6 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x0c7 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0c8 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x0c9  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  4 1 None
0x0ca  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  8 1 None
0x0cb  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  4 1 None
0x0cc  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  8 1 None
0x0cd 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x0ce 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x0cf 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None
0x0d0 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x0d1 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  4 1 None
0x0d2 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  8 1 None
0x0d3 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  4 1 None
0x0d4 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  8 1 None

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

--- Comment #1 from Paulo Dias  ---
forgot to add, llvm is 3.8 git

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

Paulo Dias  changed:

   What|Removed |Added

   Severity|normal  |critical

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

Paulo Dias  changed:

   What|Removed |Added

   Priority|medium  |high

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

Paulo Dias  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

nts/20151120/1d27a1f9/attachment.html>

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

A varied bunch of fixes, the radeon pull is probably a bit larger than I'd 
like, but it contains 2 weeks of stuff, and the Fiji fixes are a bit 
large, but they are Fiji specific.

Otherwise:

mgag200: One cursor regression oops fix.
vc4: A few small fixes and cleanups.
core: Atomic fixes and Atomic helper fixes
i915: Revert for the backlight regression along with a bunch of fixes.

Dave.

The following changes since commit 34258a32d9a9fc9e38fb549efe1692301cc31f85:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2015-11-18 08:59:29 
-0800)

are available in the git repository at:

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

for you to fetch changes up to 2d591ab18a77e25def2c483b495e07b42a3ea79f:

  Merge tag 'drm-intel-fixes-2015-11-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-11-20 09:45:31 
+1000)


Alex Deucher (1):
  drm/radeon: unconditionally set sysfs_initialized

Arnd Bergmann (1):
  drm/amdgpu: fix seq_printf format string

Christian König (16):
  drm/amdgpu: remove fence trace points
  drm/amdgpu: use a timer for fence fallback
  drm/amdgpu: use fence_is_later() for vm_flush as well v2
  drm/amdgpu: use common fence for amdgpu_vm_fence
  drm/amdgpu: fix leaking the IBs on error
  drm/amdgpu: cleanup amdgpu_cs_parser handling
  drm/amdgpu: cleanup scheduler fence get/put dance
  drm/amdgpu: fix incorrect mutex usage v3
  drm/amdgpu: fix handling order in scheduler CS
  drm/amdgpu: wait interruptible when semaphores are disabled v2
  drm/amdgpu: fix typo in firmware name
  drm/amdgpu: cleanup scheduler command submission
  drm/amdgpu: remove unused VM manager field
  drm/amdgpu: cleanup VM coding style
  drm/amdgpu: move VM manager clean into the VM code again
  drm/amdgpu: keep the owner for VMIDs

Chunming Zhou (7):
  drm/amdgpu: add kmem cache for amdgpu fence
  drm/amd: add kmem cache for sched fence
  drm/amdgpu: add command submission workflow tracepoint
  drm/amdgpu: update pd while updating vm as well
  drm/amdgpu: add lock for interval tree in vm
  drm/amdgpu: move bo_reserve out of amdgpu_vm_clear_bo
  drm/amdgpu: reserve/unreserve objects out of map/unmap operations

Dan Carpenter (1):
  drm/vc4: checking for NULL instead of IS_ERR

Daniel Vetter (1):
  drm/atomic-helper: Check encoder/crtc constraints

Dave Airlie (4):
  Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'drm-vc4-fixes' of git://github.com/anholt/linux into 
drm-fixes
  Merge tag 'topic/drm-fixes-2015-11-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge tag 'drm-intel-fixes-2015-11-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Eric Anholt (2):
  drm/vc4: Fix some failure to track __iomem decorations on pointers.
  drm/vc4: Make sure that planes aren't scaled.

Flora Cui (3):
  drm/amdgpu: update Fiji's mmPA_SC_RASTER_CONFIG value
  drm/amdgpu: update fiji_mgcg_cgcg_init table
  drm/amdgpu: update Fiji's tiling mode table

Imre Deak (1):
  drm/i915: get runtime PM reference around GEM set_caching IOCTL

Jani Nikula (2):
  drm/i915: quirk backlight present on Macbook 4, 1
  Revert "drm/i915: skip modeset if compatible for everyone."

Jay Cornwall (1):
  drm/amdgpu: Fix default page access routing

Julia Lawall (2):
  drm/vc4: fix platform_no_drv_owner.cocci warnings
  drm/vc4: fix itnull.cocci warnings

Junwei Zhang (1):
  drm/amdgpu: remove the unnecessary parameter adev for amdgpu_sa_bo_new()

Maarten Lankhorst (7):
  drm/core: Set legacy_cursor_update in drm_atomic_helper_disable_plane.
  drm/core: Fix old_fb handling in drm_mode_atomic_ioctl.
  drm/atomic: add a drm_atomic_clean_old_fb helper.
  drm/core: Fix old_fb handling in restore_fbdev_mode_atomic.
  drm/core: Fix old_fb handling in pan_display_atomic.
  drm/i915: Clear intel_crtc->atomic before updating it.
  drm/i915: Consider SPLL as another shared pll, v2.

Maxim Sheviakov (1):
  drm/radeon: fix quirk for MSI R7 370 Armor 2X

Michel Dänzer (3):
  drm/radeon: Disable uncacheable CPU mappings of GTT with RV6xx
  drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC
  drm/radeon: Only prompt for enabling PAT when we'd allow write-combining

Mika Kuoppala (2):
  drm/i915: Fix GT frequency rounding
  drm/i915: Fix gpu frequency change tracing

Rex Zhu (1):
  drm/amdgpu: fix bug that can't enter thermal interrupt for bonaire.

Ville Syrjälä (3):
  drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()
  drm: Fix primary plane size for stereo doubled modes for legacy setcrtc
  drm/i915: Don't clobber the addfb2 ioctl params

Wang, Rui Y (1):