[GIT PULL] Allwinner DRM fixes for 4.7, take 2

2016-07-05 Thread Maxime Ripard
Hi David,

Please pull the following fixes for the 4.7 merge window.

Thanks!
Maxime

The following changes since commit 13fef095bde04228316046f997eb963285d8532e:

  drm: sun4i: do cleanup if RGB output init fails (2016-05-30 08:28:33 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
tags/sunxi-drm-fixes-for-4.7-2

for you to fetch changes up to 3b8e64f6f8e2d437b15572f445b1932a45f9be6a:

  gpu: drm: sun4i_drv: add missing of_node_put after calling of_parse_phandle 
(2016-07-05 09:20:29 +0200)


Allwinner DRM driver fixes for 4.7, take 2

A new set of fixes for the sun4i driver, mostly related to vblank handling,
and a minor fix to release a reference on the device tree nodes we're
parsing in the probe logic.


Maxime Ripard (2):
  drm/sun4i: Report proper vblank
  drm/sun4i: Send vblank event when the CRTC is disabled

Peter Chen (1):
  gpu: drm: sun4i_drv: add missing of_node_put after calling 
of_parse_phandle

 drivers/gpu/drm/sun4i/sun4i_crtc.c | 8 
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 3 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160705/b9eb6ad5/attachment.sig>


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

Dmitrii Tcvetkov  changed:

   What|Removed |Added

 Resolution|CODE_FIX|PATCH_ALREADY_AVAILABLE

--- Comment #9 from Dmitrii Tcvetkov  ---
Thank you, that fix helped.

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


[PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Markus Mayer
On 5 July 2016 at 15:56, Joe Perches  wrote:
> On Tue, 2016-07-05 at 15:36 -0700, Markus Mayer wrote:
>> On 5 July 2016 at 15:14, Joe Perches  wrote:
>> > On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
>> > > This series introduces a family of generic string case conversion
>> > > functions. This kind of functionality is needed in several places in
>> > > the kernel. Right now, everybody seems to be implementing their own
>> > > copy of this functionality.
>> > >
>> > > Based on the discussion of the previous version of this series[1] and
>> > > the use cases found in the kernel, it does look like having several
>> > > flavours of case conversion functions is beneficial. The use cases fall
>> > > into three categories:
>> > > - copying a string and converting the case while specifying a
>> > >   maximum length to mimic strncpy()
>> > > - copying a string and converting the case without specifying a
>> > >   length to mimic strcpy()
>> > > - converting the case of a string in-place (i.e. modifying the
>> > >   string that was passed in)
>> > >
>> > > Consequently, I am proposing these new functions:
>> > > char *strncpytoupper(char *dst, const char *src, size_t len);
>> > > char *strncpytolower(char *dst, const char *src, size_t len);
>> > > char *strcpytoupper(char *dst, const char *src);
>> > > char *strcpytolower(char *dst, const char *src);
>> > > char *strtoupper(char *s);
>> > > char *strtolower(char *s);
>> > I think there isn't much value in anything other
>> > than strto.
>> >
>> > Using str[n]cpy followed by strto is
>> > pretty obvious and rarely used anyway.
>> First time around, folks were proposing the "copy" variants when I
>> submitted just strtolower() by itself[1]. They just asked for source
>> and destination parameters to strtolower(), but looking at the use
>> cases that wouldn't have worked so well. Hence it evolved into these 6
>> functions.
>>
>> Here's a breakdown of how the functions are being used (patches 2-7),
>> see also [2]:
>>
>> Patch 2: strncpytolower()
>> Patch 3: strtolower()
>> Patch 4: strncpytolower() and strtolower()
>> Patch 5: strtolower()
>> Patch 6: strcpytoupper()
>> Patch 7: strcpytoupper()
>>
>> So it does look like the copy + change case variant is more frequently
>> used than just strto.
>
> Are these functions useful?   Not to me, not so much.

The use cases do exist. I'll leave it up to the maintainers to decide
whether duplicate implementations or potentially unused generic
functions are to be preferred.

What I do know is that I have a driver in the wings that also needs a
strolower() implementation. If this ends up not being accepted, I'll
have to add yet another driver-local strtolower() implementation to
the kernel. But if that's the decision then so be it.

> None of the functions would have the strcpy performance of
> the arch / asm
> versions of strcpy and the savings in overall
> code isn't significant (or
> measured?).

100% agreed. These functions won't set any speed records. Keep in mind
also that in 4 out of the 6 cases where I replaced local
implementations of "strcpytoXXX", the code was doing essentially the
same I am proposing here (no assembly code). Only 2 of the 6 called
strncpy() before, benefiting from optimized assembly implementations.
But they still had to walk the string explicitly afterwards to convert
the case, which probably means the overall speed won't change that
much using the functions proposed here.

> Of course none of the uses are runtime performance important.

That is also very true.

> This patch also adds always compiled functions that aren't used
> in many .configs.

It adds 2 functions (strncpytolower() and strncpytoupper()). The other
4 are static inline one-liners and won't show up anywhere if not used
(and if used the compiler will insert calls to strncpyto
instead).

Regards,
-Markus


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

--- Comment #8 from Ilia Mirkin  ---
Ben has a better fix here:

https://github.com/skeggsb/linux/commit/217215041b9285af2193a755b56a8f3ed408bfe2

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


[Bug 89534] radeonsi GPU lockup / crash with wine

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89534

--- Comment #31 from John  ---
Aaaah a dev is back here.
Marek, if you are talking about my traces, they didn't crash my computer
either, but I hoped they might show something... I was out of ideas of what to
add here.

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


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

--- Comment #7 from Dmitrii Tcvetkov  ---
Created attachment 222141
  --> https://bugzilla.kernel.org/attachment.cgi?id=222141=edit
dmesg with reverted 6th patch from a8953c52b95167b5d21a66f0859751570271d834

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


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

Dmitrii Tcvetkov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #6 from Dmitrii Tcvetkov  ---
It works good on kernel 4.6.3 and earlier, problem is since 4.7. I just tried
to find conditions of the bug.

I reverted patch
"0006-drm-nouveau-disp-sor-gf119-both-links-use-the-same-training register"
from commit a8953c52b95167b5d21a66f0859751570271d834 and nouveau loads about 1
second, screen does not become black. System behaves like on 4.6 kernel.

Unfortunately I can't fully understand impact of this reversion on different
video adapters. Can you send it to dri-devel mailing list?

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


[PATCH 2/2] drm/ttm: use RCU to pipeline evictions

2016-07-05 Thread Alex Deucher
On Tue, Jul 5, 2016 at 8:30 AM, Christian König  
wrote:
> From: Christian König 
>
> Could be faster on the read path.
>
> Signed-off-by: Christian König 

Just one style nit pick below.  Beyond that, the series is:
Reviewed-by: Alex Deucher 


> ---
>  drivers/gpu/drm/ttm/ttm_bo.c  | 16 ++--
>  drivers/gpu/drm/ttm/ttm_bo_util.c |  8 +---
>  2 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 66c50ad..7e30f3b 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -797,9 +797,11 @@ static int ttm_bo_add_move_fence(struct 
> ttm_buffer_object *bo,
> struct fence *fence;
> int ret;
>
> -   spin_lock(>move_lock);
> -   fence = fence_get(man->move);
> -   spin_unlock(>move_lock);
> +   rcu_read_lock();
> +   do
> +   fence = rcu_dereference(man->move);
> +   while (unlikely(fence && !fence_get_rcu(fence)));

I generally like to see parens with do/while loops.

> +   rcu_read_unlock();
>
> if (fence) {
> reservation_object_add_shared_fence(bo->resv, fence);
> @@ -1304,9 +1306,11 @@ static int ttm_bo_force_list_clean(struct 
> ttm_bo_device *bdev,
> }
> spin_unlock(>lru_lock);
>
> -   spin_lock(>move_lock);
> -   fence = fence_get(man->move);
> -   spin_unlock(>move_lock);
> +   rcu_read_lock();
> +   do
> +   fence = rcu_dereference(man->move);
> +   while (unlikely(fence && !fence_get_rcu(fence)));

Same here.

> +   rcu_read_unlock();
>
> if (fence) {
> ret = fence_wait(fence, false);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 4da0e78..fcd2431 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -746,6 +746,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> ttm_bo_unref(_obj);
>
> } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> +   struct fence *old;
>
> /**
>  * BO doesn't have a TTM we need to bind/unbind. Just remember
> @@ -753,9 +754,10 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>  */
>
> spin_lock(>move_lock);
> -   if (!from->move || fence_is_later(fence, from->move)) {
> -   fence_put(from->move);
> -   from->move = fence_get(fence);
> +   old = rcu_dereference_protected(from->move, 1);
> +   if (!old || fence_is_later(fence, old)) {
> +   rcu_assign_pointer(from->move, fence_get(fence));
> +   fence_put(old);
> }
> spin_unlock(>move_lock);
>
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-05 Thread Tejun Heo
Hello,

On Mon, Jul 04, 2016 at 12:58:32PM +0900, Michel Dänzer wrote:
> On 02.07.2016 22:46, Tejun Heo wrote:
> > On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote:
> >> alloc_workqueue replaces deprecated create_singlethread_workqueue().
> >>
> >> A dedicated workqueue has been used since work items need to be flushed
> >> as a group rather than individually.

There seem to be two work items involved, the flip one and unpin one.
Provided that there's no ordering requirement between the two, can't
we just flush them individually?

> >> Since the flip_queue workqueue is involved in page-flipping and is not
> >> being used on a memory reclaim path, WQ_MEM_RECLAIM has not been set.
> >>
> >> Since there are only a fixed number of work items, explicit concurrency
> >> limit is unnecessary here.
> > 
> > What are the involved work items?
> 
> drivers/gpu/drm/radeon/radeon_display.c:radeon_flip_work_func()
>
> > Is it safe to run them concurrently?
> 
> Concurrently with what exactly?

The flip and unpin work items.

Thanks.

-- 
tejun


[GIT PULL] etnaviv-next for 4.8

2016-07-05 Thread Lucas Stach
Hi Dave,

etnaviv-next only contains two patches to get rid of a confusing error
message and finally one patch to enable the autonomous GPU clock gating.

Regards,
Lucas

The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:

  Linux 4.7-rc4 (2016-06-19 21:30:02 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/lst/linux.git drm-etnaviv-next

for you to fetch changes up to c1c77b0e07dc6231db3c2c7b847c514849d53b99:

  drm/etnaviv: remove generic GPU init failure reporting (2016-07-05 16:26:38 
+0200)


Lucas Stach (2):
  drm/etnaviv: improve error reporting in GPU init path
  drm/etnaviv: remove generic GPU init failure reporting

Russell King (1):
  drm/etnaviv: enable GPU module level clock gating support

 drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 +---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 54 
--
 drivers/gpu/drm/etnaviv/state_hi.xml.h |  7 +++
 3 files changed, 60 insertions(+), 5 deletions(-)




[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

Ilia Mirkin  changed:

   What|Removed |Added

 CC||imirkin at alum.mit.edu

--- Comment #5 from Ilia Mirkin  ---
Did this ever work for you?

Looks like DP link training fails. If it worked before, I would suspect commit
a8953c52b95167b5d21a66f0859751570271d834 .

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


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

--- Comment #4 from Dmitrii Tcvetkov  ---
Created attachment 222131
  --> https://bugzilla.kernel.org/attachment.cgi?id=222131=edit
lspci

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


[Bug 96786] AMD Display Library (ADL) functionality unavailable/not working

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96786

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #1 from Alex Deucher  ---
ADL is not supported in the amdgpu-pro driver.  The same functionality can be
accessed via standard Linux interfaces (e.g., hwmon for temperature and fan
control, sysfs for clock control, etc..

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


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

--- Comment #3 from Dmitrii Tcvetkov  ---
Created attachment 222121
  --> https://bugzilla.kernel.org/attachment.cgi?id=222121=edit
Xorg.0.log for modprobe nouveau debug=trace

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


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

--- Comment #2 from Dmitrii Tcvetkov  ---
Created attachment 222111
  --> https://bugzilla.kernel.org/attachment.cgi?id=222111=edit
dmesg for modprobe nouveau debug=trace

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


[Bug 121481] No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

Dmitrii Tcvetkov  changed:

   What|Removed |Added

 CC||demfloro at demfloro.ru

--- Comment #1 from Dmitrii Tcvetkov  ---
Created attachment 222101
  --> https://bugzilla.kernel.org/attachment.cgi?id=222101=edit
Xorg.0.log for modprobe nouveau

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


[Bug 121481] New: No video output after loading nouveau module

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121481

Bug ID: 121481
   Summary: No video output after loading nouveau module
   Product: Drivers
   Version: 2.5
Kernel Version: 4.7-rc6
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: demfloro at demfloro.ru
Regression: No

Created attachment 222091
  --> https://bugzilla.kernel.org/attachment.cgi?id=222091=edit
dmesg for just modprobe nouveau

OS: Arch Linux
Video adapter: GeForce GTX 780 Ti

Since 4.7 loading nouveau module results in black screen, but when I load
nouveau module with parameter debug=trace the issue does not appear, screen
successfully switches to correct resolution and Xorg can be successfully
started.

I did following:
- after OS booting I issued command "modprobe nouveau", in this case execution
of the command took about 44 seconds;
- when "modprobe nouveau" returned control to shell I blindly issued command
"startx" on terminal in VT;
- after that machine was rebooted with "reboot"

- after reboot I issued command "modprobe nouveau debug=trace", it took about
11 seconds to finish;
- after that I issued "startx" and Xorg started sucessfully.

If I compile nouveau module in kernel then I lose video output right after
kernel loads if I don't pass nouveau.debug=trace parameter.

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


[PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Joe Perches
On Tue, 2016-07-05 at 15:36 -0700, Markus Mayer wrote:
> On 5 July 2016 at 15:14, Joe Perches  wrote:
> > On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
> > > This series introduces a family of generic string case conversion
> > > functions. This kind of functionality is needed in several places in
> > > the kernel. Right now, everybody seems to be implementing their own
> > > copy of this functionality.
> > > 
> > > Based on the discussion of the previous version of this series[1] and
> > > the use cases found in the kernel, it does look like having several
> > > flavours of case conversion functions is beneficial. The use cases fall
> > > into three categories:
> > >     - copying a string and converting the case while specifying a
> > >       maximum length to mimic strncpy()
> > >     - copying a string and converting the case without specifying a
> > >       length to mimic strcpy()
> > >     - converting the case of a string in-place (i.e. modifying the
> > >       string that was passed in)
> > > 
> > > Consequently, I am proposing these new functions:
> > >     char *strncpytoupper(char *dst, const char *src, size_t len);
> > >     char *strncpytolower(char *dst, const char *src, size_t len);
> > >     char *strcpytoupper(char *dst, const char *src);
> > >     char *strcpytolower(char *dst, const char *src);
> > >     char *strtoupper(char *s);
> > >     char *strtolower(char *s);
> > I think there isn't much value in anything other
> > than strto.
> > 
> > Using str[n]cpy followed by strto is
> > pretty obvious and rarely used anyway.
> First time around, folks were proposing the "copy" variants when I
> submitted just strtolower() by itself[1]. They just asked for source
> and destination parameters to strtolower(), but looking at the use
> cases that wouldn't have worked so well. Hence it evolved into these 6
> functions.
> 
> Here's a breakdown of how the functions are being used (patches 2-7),
> see also [2]:
> 
> Patch 2: strncpytolower()
> Patch 3: strtolower()
> Patch 4: strncpytolower() and strtolower()
> Patch 5: strtolower()
> Patch 6: strcpytoupper()
> Patch 7: strcpytoupper()
> 
> So it does look like the copy + change case variant is more frequently
> used than just strto.

Are these functions useful?   Not to me, not so much.

None of the functions would have the strcpy performance of
the arch / asm
versions of strcpy and the savings in overall
code isn't significant (or
measured?).

Of course none of the uses are runtime performance important.

This patch also adds always compiled functions that aren't used
in many .configs.



[Bug 89534] radeonsi GPU lockup / crash with wine

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89534

--- Comment #30 from Marek Olšák  ---
The GPU no longer hangs with the apitraces for me.

I'm using LLVM git with this fix:
http://reviews.llvm.org/D21961

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


[PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Markus Mayer
On 5 July 2016 at 15:14, Joe Perches  wrote:
> On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
>> This series introduces a family of generic string case conversion
>> functions. This kind of functionality is needed in several places in
>> the kernel. Right now, everybody seems to be implementing their own
>> copy of this functionality.
>>
>> Based on the discussion of the previous version of this series[1] and
>> the use cases found in the kernel, it does look like having several
>> flavours of case conversion functions is beneficial. The use cases fall
>> into three categories:
>> - copying a string and converting the case while specifying a
>>   maximum length to mimic strncpy()
>> - copying a string and converting the case without specifying a
>>   length to mimic strcpy()
>> - converting the case of a string in-place (i.e. modifying the
>>   string that was passed in)
>>
>> Consequently, I am proposing these new functions:
>> char *strncpytoupper(char *dst, const char *src, size_t len);
>> char *strncpytolower(char *dst, const char *src, size_t len);
>> char *strcpytoupper(char *dst, const char *src);
>> char *strcpytolower(char *dst, const char *src);
>> char *strtoupper(char *s);
>> char *strtolower(char *s);
>
> I think there isn't much value in anything other
> than strto.
>
> Using str[n]cpy followed by strto is
> pretty obvious and rarely used anyway.

First time around, folks were proposing the "copy" variants when I
submitted just strtolower() by itself[1]. They just asked for source
and destination parameters to strtolower(), but looking at the use
cases that wouldn't have worked so well. Hence it evolved into these 6
functions.

Here's a breakdown of how the functions are being used (patches 2-7),
see also [2]:

Patch 2: strncpytolower()
Patch 3: strtolower()
Patch 4: strncpytolower() and strtolower()
Patch 5: strtolower()
Patch 6: strcpytoupper()
Patch 7: strcpytoupper()

So it does look like the copy + change case variant is more frequently
used than just strto.

Regards,
-Markus

[1] https://lkml.org/lkml/2016/7/1/652
[2] https://lkml.org/lkml/2016/7/5/542


[PATCH] Android: strip out header files from sources list

2016-07-05 Thread Rob Herring
AOSP master now errors if LOCAL_SRC_FILES contains headers, so filter
out header files from the source lists.

Signed-off-by: Rob Herring 
---
 Android.mk| 4 ++--
 amdgpu/Android.mk | 2 +-
 freedreno/Android.mk  | 2 +-
 intel/Android.mk  | 2 +-
 libkms/Android.mk | 2 +-
 nouveau/Android.mk| 2 +-
 radeon/Android.mk | 2 +-
 tests/modetest/Android.mk | 2 +-
 tests/proptest/Android.mk | 2 +-
 tests/util/Android.mk | 2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/Android.mk b/Android.mk
index 1d8cd65..2aa2bc9 100644
--- a/Android.mk
+++ b/Android.mk
@@ -32,7 +32,7 @@ include $(CLEAR_VARS)
 LOCAL_MODULE := libdrm
 LOCAL_MODULE_TAGS := optional

-LOCAL_SRC_FILES := $(LIBDRM_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_FILES))
 LOCAL_EXPORT_C_INCLUDE_DIRS := \
$(LOCAL_PATH) \
$(LOCAL_PATH)/include/drm
@@ -50,7 +50,7 @@ include $(CLEAR_VARS)
 LOCAL_MODULE := libdrm
 LOCAL_MODULE_TAGS := optional

-LOCAL_SRC_FILES := $(LIBDRM_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_FILES))
 LOCAL_EXPORT_C_INCLUDE_DIRS := \
 $(LOCAL_PATH) \
 $(LOCAL_PATH)/include/drm
diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
index 469df1b..57c53a7 100644
--- a/amdgpu/Android.mk
+++ b/amdgpu/Android.mk
@@ -9,7 +9,7 @@ LOCAL_MODULE_TAGS := optional

 LOCAL_SHARED_LIBRARIES := libdrm

-LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_AMDGPU_FILES))
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)

 LOCAL_CFLAGS := \
diff --git a/freedreno/Android.mk b/freedreno/Android.mk
index 2645f73..fba48f2 100644
--- a/freedreno/Android.mk
+++ b/freedreno/Android.mk
@@ -9,7 +9,7 @@ LOCAL_MODULE_TAGS := optional

 LOCAL_SHARED_LIBRARIES := libdrm

-LOCAL_SRC_FILES := $(LIBDRM_FREEDRENO_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_FREEDRENO_FILES))
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)

 LOCAL_CFLAGS := \
diff --git a/intel/Android.mk b/intel/Android.mk
index 6582dfd..838a93b 100644
--- a/intel/Android.mk
+++ b/intel/Android.mk
@@ -30,7 +30,7 @@ include $(LOCAL_PATH)/Makefile.sources
 LOCAL_MODULE := libdrm_intel
 LOCAL_MODULE_TAGS := optional

-LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_INTEL_FILES))
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)

 LOCAL_CFLAGS := \
diff --git a/libkms/Android.mk b/libkms/Android.mk
index a406782..cf0e9bb 100644
--- a/libkms/Android.mk
+++ b/libkms/Android.mk
@@ -26,7 +26,7 @@ LOCAL_PATH := $(call my-dir)
 include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources

-LOCAL_SRC_FILES := $(LIBKMS_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBKMS_FILES))

 ifneq ($(filter $(vmwgfx_drivers), $(DRM_GPU_DRIVERS)),)
 LOCAL_SRC_FILES += $(LIBKMS_VMWGFX_FILES)
diff --git a/nouveau/Android.mk b/nouveau/Android.mk
index abc6aef..b67d30f 100644
--- a/nouveau/Android.mk
+++ b/nouveau/Android.mk
@@ -9,7 +9,7 @@ LOCAL_MODULE_TAGS := optional

 LOCAL_SHARED_LIBRARIES := libdrm

-LOCAL_SRC_FILES := $(LIBDRM_NOUVEAU_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_NOUVEAU_FILES))
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)

 LOCAL_CFLAGS := \
diff --git a/radeon/Android.mk b/radeon/Android.mk
index ace3408..e704443 100644
--- a/radeon/Android.mk
+++ b/radeon/Android.mk
@@ -9,7 +9,7 @@ LOCAL_MODULE_TAGS := optional

 LOCAL_SHARED_LIBRARIES := libdrm

-LOCAL_SRC_FILES := $(LIBDRM_RADEON_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_RADEON_FILES))
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)

 LOCAL_CFLAGS := \
diff --git a/tests/modetest/Android.mk b/tests/modetest/Android.mk
index e616558..6a7f406 100644
--- a/tests/modetest/Android.mk
+++ b/tests/modetest/Android.mk
@@ -3,7 +3,7 @@ LOCAL_PATH := $(call my-dir)
 include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources

-LOCAL_SRC_FILES := $(MODETEST_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(MODETEST_FILES))

 LOCAL_MODULE := modetest

diff --git a/tests/proptest/Android.mk b/tests/proptest/Android.mk
index d0ab5c9..badeb58 100644
--- a/tests/proptest/Android.mk
+++ b/tests/proptest/Android.mk
@@ -3,7 +3,7 @@ LOCAL_PATH := $(call my-dir)
 include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources

-LOCAL_SRC_FILES := $(PROPTEST_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(PROPTEST_FILES))

 LOCAL_MODULE := proptest

diff --git a/tests/util/Android.mk b/tests/util/Android.mk
index 73bc680..1bd82ae 100644
--- a/tests/util/Android.mk
+++ b/tests/util/Android.mk
@@ -31,7 +31,7 @@ LOCAL_MODULE_TAGS := optional

 LOCAL_SHARED_LIBRARIES := libdrm

-LOCAL_SRC_FILES := $(UTIL_FILES)
+LOCAL_SRC_FILES := $(patsubst %.h, , $(UTIL_FILES))

 # avoid name clashes by requiring users to include util/*.h
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(dir $(LOCAL_PATH))
-- 
2.9.0



[PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Joe Perches
On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
> This series introduces a family of generic string case conversion
> functions. This kind of functionality is needed in several places in
> the kernel. Right now, everybody seems to be implementing their own
> copy of this functionality.
> 
> Based on the discussion of the previous version of this series[1] and
> the use cases found in the kernel, it does look like having several
> flavours of case conversion functions is beneficial. The use cases fall
> into three categories:
>     - copying a string and converting the case while specifying a
>       maximum length to mimic strncpy()
>     - copying a string and converting the case without specifying a
>       length to mimic strcpy()
>     - converting the case of a string in-place (i.e. modifying the
>       string that was passed in)
> 
> Consequently, I am proposing these new functions:
>     char *strncpytoupper(char *dst, const char *src, size_t len);
>     char *strncpytolower(char *dst, const char *src, size_t len);
>     char *strcpytoupper(char *dst, const char *src);
>     char *strcpytolower(char *dst, const char *src);
>     char *strtoupper(char *s);
>     char *strtolower(char *s);

I think there isn't much value in anything other
than strto.

Using str[n]cpy followed by strto is
pretty obvious and rarely used anyway.



[PATCH] drivers: gpu: drm: amd: powerplay: hwmgr: Remove unused variable

2016-07-05 Thread Zhu, Rex

Yes, stretch_amount2 was not used on Polaris.


Patch was Reviewed-by: Rex Zhu 


Thanks.


Best Regards

Rex


From: Matthias Beyer <m...@beyermatthias.de>
Sent: Friday, July 1, 2016 12:38:49 AM
To: linuxdev.baldrick at gmail.com
Cc: Deucher, Alexander; Koenig, Christian; airlied at linux.ie; dri-devel at 
lists.freedesktop.org; dcb314 at hotmail.com; linux-kernel at vger.kernel.org; 
Zhu, Rex; Huang, JinHuiEric; nils.wallmenius at gmail.com; Matthias Beyer
Subject: [PATCH] drivers: gpu: drm: amd: powerplay: hwmgr: Remove unused 
variable

Signed-off-by: Matthias Beyer 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
index 64ee78f..1dcd52d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
@@ -1761,7 +1761,7 @@ static int 
polaris10_populate_clock_stretcher_data_table(struct pp_hwmgr *hwmgr)
 {
 uint32_t ro, efuse, volt_without_cks, volt_with_cks, value, max, min;
 struct polaris10_hwmgr *data = (struct polaris10_hwmgr 
*)(hwmgr->backend);
-   uint8_t i, stretch_amount, stretch_amount2, volt_offset = 0;
+   uint8_t i, stretch_amount, volt_offset = 0;
 struct phm_ppt_v1_information *table_info =
 (struct phm_ppt_v1_information *)(hwmgr->pptable);
 struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table =
@@ -1806,11 +1806,8 @@ static int 
polaris10_populate_clock_stretcher_data_table(struct pp_hwmgr *hwmgr)
 }

 /* Populate CKS Lookup Table */
-   if (stretch_amount == 1 || stretch_amount == 2 || stretch_amount == 5)
-   stretch_amount2 = 0;
-   else if (stretch_amount == 3 || stretch_amount == 4)
-   stretch_amount2 = 1;
-   else {
+   if (stretch_amount != 1 && stretch_amount != 2 && stretch_amount != 3 &&
+   stretch_amount != 4 && stretch_amount != 5) {
 phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
 PHM_PlatformCaps_ClockStretcher);
 PP_ASSERT_WITH_CODE(false,
--
2.9.0

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160705/5d090dab/attachment.html>


ABI changes analysis report for libdrm

2016-07-05 Thread Ponomarenko Andrey
Hello,

I'm working on a new project for backward compatibility analysis of the Linux 
ABIs. The report for libdrm 2.4.25-2.4.68 has been recently added to the 
project and updated every other day: 
http://abi-laboratory.pro/tracker/timeline/libdrm/

The report is generated with the help of the abi-compliance-checker, abi-dumper 
and abi-tracker tools: https://github.com/lvc/abi-tracker

Hope this will help users, maintainers and developers of the library to 
maintain backward compatibility.

Thank you.


[PATCH 2/2] drm/ttm: use RCU to pipeline evictions

2016-07-05 Thread Christian König
From: Christian König 

Could be faster on the read path.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c  | 16 ++--
 drivers/gpu/drm/ttm/ttm_bo_util.c |  8 +---
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 66c50ad..7e30f3b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -797,9 +797,11 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object 
*bo,
struct fence *fence;
int ret;

-   spin_lock(>move_lock);
-   fence = fence_get(man->move);
-   spin_unlock(>move_lock);
+   rcu_read_lock();
+   do
+   fence = rcu_dereference(man->move);
+   while (unlikely(fence && !fence_get_rcu(fence)));
+   rcu_read_unlock();

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

-   spin_lock(>move_lock);
-   fence = fence_get(man->move);
-   spin_unlock(>move_lock);
+   rcu_read_lock();
+   do
+   fence = rcu_dereference(man->move);
+   while (unlikely(fence && !fence_get_rcu(fence)));
+   rcu_read_unlock();

if (fence) {
ret = fence_wait(fence, false);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 4da0e78..fcd2431 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -746,6 +746,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
ttm_bo_unref(_obj);

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

/**
 * BO doesn't have a TTM we need to bind/unbind. Just remember
@@ -753,9 +754,10 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
 */

spin_lock(>move_lock);
-   if (!from->move || fence_is_later(fence, from->move)) {
-   fence_put(from->move);
-   from->move = fence_get(fence);
+   old = rcu_dereference_protected(from->move, 1);
+   if (!old || fence_is_later(fence, old)) {
+   rcu_assign_pointer(from->move, fence_get(fence));
+   fence_put(old);
}
spin_unlock(>move_lock);

-- 
2.5.0



[PATCH 1/2] drm/ttm: remove allow_errors from ttm_bo_force_list_clean

2016-07-05 Thread Christian König
From: Christian König 

That is completely nonsense. If we blindly continue we would end up
in an endless loop trying to evict the same BOs over and over again.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 26 +-
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e340d0d6..66c50ad 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1283,7 +1283,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
 EXPORT_SYMBOL(ttm_bo_create);

 static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
-   unsigned mem_type, bool allow_errors)
+  unsigned mem_type)
 {
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
@@ -1298,13 +1298,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
while (!list_empty(>lru)) {
spin_unlock(>lru_lock);
ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false);
-   if (ret) {
-   if (allow_errors) {
-   return ret;
-   } else {
-   pr_err("Cleanup eviction failed\n");
-   }
-   }
+   if (ret)
+   return ret;
spin_lock(>lru_lock);
}
spin_unlock(>lru_lock);
@@ -1316,13 +1311,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
if (fence) {
ret = fence_wait(fence, false);
fence_put(fence);
-   if (ret) {
-   if (allow_errors) {
-   return ret;
-   } else {
-   pr_err("Cleanup eviction failed\n");
-   }
-   }
+   if (ret)
+   return ret;
}

return 0;
@@ -1351,7 +1341,9 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)

ret = 0;
if (mem_type > 0) {
-   ttm_bo_force_list_clean(bdev, mem_type, false);
+   ret = ttm_bo_force_list_clean(bdev, mem_type);
+   if (ret)
+   pr_err("Cleanup eviction failed (%d)\n", ret);

ret = (*man->func->takedown)(man);
}
@@ -1374,7 +1366,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
return 0;
}

-   return ttm_bo_force_list_clean(bdev, mem_type, true);
+   return ttm_bo_force_list_clean(bdev, mem_type);
 }
 EXPORT_SYMBOL(ttm_bo_evict_mm);

-- 
2.5.0



[PATCH v3 1/4] dma-buf/fence-array: add fence_is_array()

2016-07-05 Thread Christian König
Am 05.07.2016 um 01:57 schrieb Gustavo Padovan:
> From: Gustavo Padovan 
>
> Add helper to check if fence is array.
>
> v2: Comments from Chris Wilson
>   - remove ternary if from ops comparison
>   - add EXPORT_SYMBOL(fence_array_ops)
>
> Cc: Chris Wilson 
> Cc: Christian König 
> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Chris Wilson 

For this patch Reviewed-by: Christian König .

I'm not deep enough into the sync file code to fully judge, but the 
remaining patches look good to me as well.

So for patch #2-#4 Acked-by: Christian König .

Regards,
Christian.

> ---
>   drivers/dma-buf/fence-array.c |  1 +
>   include/linux/fence-array.h   | 10 ++
>   2 files changed, 11 insertions(+)
>
> diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
> index a8731c8..ee50022 100644
> --- a/drivers/dma-buf/fence-array.c
> +++ b/drivers/dma-buf/fence-array.c
> @@ -99,6 +99,7 @@ const struct fence_ops fence_array_ops = {
>   .wait = fence_default_wait,
>   .release = fence_array_release,
>   };
> +EXPORT_SYMBOL(fence_array_ops);
>   
>   /**
>* fence_array_create - Create a custom fence array
> diff --git a/include/linux/fence-array.h b/include/linux/fence-array.h
> index 86baaa4..a44794e 100644
> --- a/include/linux/fence-array.h
> +++ b/include/linux/fence-array.h
> @@ -52,6 +52,16 @@ struct fence_array {
>   extern const struct fence_ops fence_array_ops;
>   
>   /**
> + * fence_is_array - check if a fence is from the array subsclass
> + *
> + * Return true if it is a fence_array and false otherwise.
> + */
> +static inline bool fence_is_array(struct fence *fence)
> +{
> + return fence->ops == _array_ops;
> +}
> +
> +/**
>* to_fence_array - cast a fence to a fence_array
>* @fence: fence to cast to a fence_array
>*



linux-next: build failure after merge of the tip tree (from the drm-intel tree)

2016-07-05 Thread Stephen Rothwell
Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from include/uapi/linux/stddef.h:1:0,
 from include/linux/stddef.h:4,
 from include/uapi/linux/posix_types.h:4,
 from include/uapi/linux/types.h:13,
 from include/linux/types.h:5,
 from include/linux/sysrq.h:18,
 from drivers/gpu/drm/i915/i915_irq.c:31:
drivers/gpu/drm/i915/i915_irq.c: In function 'i915_hangcheck_elapsed':
include/linux/compiler.h:542:50: error: incompatible types when initializing 
type 'const void * const' using type 'bool {aka _Bool}'
  __maybe_unused const void * const _p2 = _p1; \
  ^
drivers/gpu/drm/i915/i915_irq.c:3098:7: note: in expansion of macro 
'lockless_dereference'
  if (!lockless_dereference(dev_priv->gt.awake))
   ^

Caused by commit

  67d97da34917 ("drm/i915: Only start retire worker when idle")

from the drm-intel tree interacting with commit

  331b6d8c7afc ("locking/barriers: Validate lockless_dereference() is used on a 
pointer type")

from the tip tree.


[PATCH v2 6/7] drm/nouveau/fifo/gk104: make use of new strcpytoupper() function

2016-07-05 Thread Markus Mayer
Call strcpytoupper() rather than copying the string explicitly and then
walking it to convert it to uppercase.

Signed-off-by: Markus Mayer 
---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index 743f3a1..8d01032 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -332,10 +332,7 @@ gk104_fifo_intr_fault(struct gk104_fifo *fifo, int unit)
enum nvkm_devidx engidx = nvkm_top_fault(device->top, unit);
if (engidx < NVKM_SUBDEV_NR) {
const char *src = nvkm_subdev_name[engidx];
-   char *dst = en;
-   do {
-   *dst++ = toupper(*src++);
-   } while(*src);
+   strcpytoupper(en, src);
engine = nvkm_device_engine(device, engidx);
}
} else {
-- 
2.7.4



[PATCH v2 2/7] drm/nouveau/core: make use of new strncpytolower() function

2016-07-05 Thread Markus Mayer
Call strncpytolower() rather than copying the string explicitly and
then walking it to convert it to lowercase.

Signed-off-by: Markus Mayer 
---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index 34ecd4a..6f3314f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -36,16 +36,10 @@ nvkm_firmware_get(struct nvkm_device *device, const char 
*fwname,
 {
char f[64];
char cname[16];
-   int i;

/* Convert device name to lowercase */
-   strncpy(cname, device->chip->name, sizeof(cname));
+   strncpytolower(cname, device->chip->name, sizeof(cname));
cname[sizeof(cname) - 1] = '\0';
-   i = strlen(cname);
-   while (i) {
-   --i;
-   cname[i] = tolower(cname[i]);
-   }

snprintf(f, sizeof(f), "nvidia/%s/%s.bin", cname, fwname);
return request_firmware(fw, f, device->dev);
-- 
2.7.4



[PATCH v2 1/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Markus Mayer
Add a collection of generic functions to convert strings to lowercase
or uppercase.

Changing the case of a string (with or without copying it first) seems
to be a recurring requirement in the kernel that is currently being
solved by several duplicated implementations doing the same thing. This
change aims at reducing this code duplication.

The new functions are
char *strncpytoupper(char *dst, const char *src, size_t len);
char *strncpytolower(char *dst, const char *src, size_t len);
char *strcpytoupper(char *dst, const char *src);
char *strcpytolower(char *dst, const char *src);
char *strtoupper(char *s);
char *strtolower(char *s);

The "str[n]cpyto*" versions of the function take a destination string
and a source string as arguments. The "strncpyto*" versions
additionally take a length argument like strncpy() itself. Lastly, the
strto* functions take a single string argument and modify the passed-in
string.

All functions return a pointer to the terminating '\0' character in the
modified string ("dst" or "s", respectively).

Signed-off-by: Markus Mayer 
---
 include/linux/string.h | 48 
 lib/string.c   | 42 ++
 2 files changed, 90 insertions(+)

diff --git a/include/linux/string.h b/include/linux/string.h
index 26b6f6a..c58d510 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -116,6 +116,8 @@ extern void * memchr(const void *,int,__kernel_size_t);
 #endif
 void *memchr_inv(const void *s, int c, size_t n);
 char *strreplace(char *s, char old, char new);
+char *strncpytoupper(char *dst, const char *src, size_t len);
+char *strncpytolower(char *dst, const char *src, size_t len);

 extern void kfree_const(const void *x);

@@ -169,4 +171,50 @@ static inline const char *kbasename(const char *path)
return tail ? tail + 1 : path;
 }

+/**
+ * strcpytoupper - Copy string and convert to uppercase.
+ * @dst: The buffer to store the result.
+ * @src: The string to convert to uppercase.
+ *
+ * Returns pointer to terminating '\0' in @dst.
+ */
+static inline char *strcpytoupper(char *dst, const char *src)
+{
+   return strncpytoupper(dst, src, 0);
+}
+
+/**
+ * strcpytolower - Copy string and convert to lowercase.
+ * @dst: The buffer to store the result.
+ * @src: The string to convert to lowercase.
+ *
+ * Returns pointer to terminating '\0' in @dst.
+ */
+static inline char *strcpytolower(char *dst, const char *src)
+{
+   return strncpytolower(dst, src, 0);
+}
+
+/**
+ * strtoupper - Convert string to uppercase.
+ * @s: The string to operate on.
+ *
+ * Returns pointer to terminating '\0' in @s.
+ */
+static inline char *strtoupper(char *s)
+{
+   return strncpytoupper(s, s, 0);
+}
+
+/**
+ * strtolower - Convert string to lowercase.
+ * @s: The string to operate on.
+ *
+ * Returns pointer to terminating '\0' in @s.
+ */
+static inline char *strtolower(char *s)
+{
+   return strncpytolower(s, s, 0);
+}
+
 #endif /* _LINUX_STRING_H_ */
diff --git a/lib/string.c b/lib/string.c
index ed83562..900f357 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -952,3 +952,45 @@ char *strreplace(char *s, char old, char new)
return s;
 }
 EXPORT_SYMBOL(strreplace);
+
+/**
+ * strncpytoupper - Copy a length-limited string and convert to uppercase.
+ * @dst: The buffer to store the result.
+ * @src: The string to convert to uppercase.
+ * @len: Maximum string length. May be 0 to set no limit.
+ *
+ * Returns pointer to terminating '\0' in @dst.
+ */
+char *strncpytoupper(char *dst, const char *src, size_t len)
+{
+   size_t i;
+
+   for (i = 0; src[i] != '\0' && (i < len || !len); i++)
+   dst[i] = toupper(src[i]);
+   if (i < len || !len)
+   dst[i] = '\0';
+
+   return dst + i;
+}
+EXPORT_SYMBOL(strncpytoupper);
+
+/**
+ * strncpytolower - Copy a length-limited string and convert to lowercase.
+ * @dst: The buffer to store the result.
+ * @src: The string to convert to lowercase.
+ * @len: Maximum string length. May be 0 to set no limit.
+ *
+ * Returns pointer to terminating '\0' in @dst.
+ */
+char *strncpytolower(char *dst, const char *src, size_t len)
+{
+   size_t i;
+
+   for (i = 0; src[i] != '\0' && (i < len || !len); i++)
+   dst[i] = tolower(src[i]);
+   if (i < len || !len)
+   dst[i] = '\0';
+
+   return dst + i;
+}
+EXPORT_SYMBOL(strncpytolower);
-- 
2.7.4



[PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Markus Mayer
This series introduces a family of generic string case conversion
functions. This kind of functionality is needed in several places in
the kernel. Right now, everybody seems to be implementing their own
copy of this functionality.

Based on the discussion of the previous version of this series[1] and
the use cases found in the kernel, it does look like having several
flavours of case conversion functions is beneficial. The use cases fall
into three categories:
- copying a string and converting the case while specifying a
  maximum length to mimic strncpy()
- copying a string and converting the case without specifying a
  length to mimic strcpy()
- converting the case of a string in-place (i.e. modifying the
  string that was passed in)

Consequently, I am proposing these new functions:
char *strncpytoupper(char *dst, const char *src, size_t len);
char *strncpytolower(char *dst, const char *src, size_t len);
char *strcpytoupper(char *dst, const char *src);
char *strcpytolower(char *dst, const char *src);
char *strtoupper(char *s);
char *strtolower(char *s);
They all return a pointer to the terminating '\0' in the destination
string (for strtoupper() and strtolower() that is "s").

Several drivers are being modified to make use of the functions above.
Another driver that also makes use of this functionality will be
submitted upstream shortly, which prompted this whole exercise.

The changes made here have been compile-tested, but not tried out, due
to lack of required hardware.

Changes since v1:
  - expanded strtolower() into a family of functions that cover use
cases when a length argument is or isn't required and that support
copying the string into a new buffer or changing it in-place 
  - changed the function semantics to return a pointer to the
terminating '\0' character of the modified string
  - added strtoupper() functionality mirroring the above
  - dropped the ACPICA patch, since that code is OS independent and
can't rely on a Linux library function (see [2])
  - Added two new patches replacing strtoupper() implementations

[1] https://lkml.org/lkml/2016/6/30/727
[2] https://lkml.org/lkml/2016/7/1/9

Markus Mayer (7):
  lib: string: add functions str[n]cpytolower()/str[n]cpytoupper()
  drm/nouveau/core: make use of new strncpytolower() function
  ACPI / device_sysfs: make use of new strtolower() function
  staging: speakup: replace spk_strlwr() with strncpytolower()
  iscsi-target: replace iscsi_initiatorname_tolower() with
strcpytolower()
  drm/nouveau/fifo/gk104: make use of new strcpytoupper() function
  power_supply: make use of new strcpytoupper() function

 drivers/acpi/device_sysfs.c  |  4 +-
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c |  9 +
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c |  5 +--
 drivers/power/power_supply_sysfs.c   | 13 +++
 drivers/staging/speakup/kobjects.c   |  3 +-
 drivers/staging/speakup/main.c   |  3 +-
 drivers/staging/speakup/speakup.h|  1 -
 drivers/staging/speakup/varhandlers.c| 12 --
 drivers/target/iscsi/iscsi_target_nego.c | 17 +
 include/linux/string.h   | 48 
 lib/string.c | 40 
 11 files changed, 100 insertions(+), 55 deletions(-)

-- 
2.7.4



linux-next: build failure after merge of the tip tree (from the drm-intel tree)

2016-07-05 Thread Paul E. McKenney
On Tue, Jul 05, 2016 at 10:25:12AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index d3502c0603e5..1f91f187b2a8 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3290,7 +3290,7 @@ i915_gem_retire_work_handler(struct work_struct *work)
> >  * We do not need to do this test under locking as in the worst-case
> >  * we queue the retire worker once too often.
> >  */
> > -   if (lockless_dereference(dev_priv->gt.awake))
> > +   if (/*lockless_dereference*/(dev_priv->gt.awake))
> > queue_delayed_work(dev_priv->wq,
> >_priv->gt.retire_work,
> >round_jiffies_up_relative(HZ));
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index f6de8dd567a2..2c1926418691 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3095,7 +3095,7 @@ static void i915_hangcheck_elapsed(struct work_struct 
> > *work)
> > if (!i915.enable_hangcheck)
> > return;
> >  
> > -   if (!lockless_dereference(dev_priv->gt.awake))
> > +   if (!/*lockless_dereference*/(dev_priv->gt.awake))
> > return;
> >  
> > /* As enabling the GPU requires fairly extensive mmio access,
> 
> Right, neither case appears to include a data dependency and thus
> lockless_dereference() seems misguided.

Agreed!  At first glance, this code wants READ_ONCE() rather than
lockless_dereference().

Thanx, Paul



[PATCH] drm: sti: fix prototypes after API change

2016-07-05 Thread Stephen Rothwell
Hi Dave,

On Tue, 5 Jul 2016 09:59:16 +1000 Dave Airlie  wrote:
>
> I think I've done it correctly, I've just pushed out drm-next with the
> pull and the
> two changes amended into the merge.

Looks great, thanks.

-- 
Cheers,
Stephen Rothwell


[Bug 96790] frame stuttering in ut2004

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96790

--- Comment #10 from network723 at rkmail.ru ---
Yes, looks like they do correspond bumps on last graph.

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


linux-next: build failure after merge of the tip tree (from the drm-intel tree)

2016-07-05 Thread Peter Zijlstra
On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d3502c0603e5..1f91f187b2a8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3290,7 +3290,7 @@ i915_gem_retire_work_handler(struct work_struct *work)
>* We do not need to do this test under locking as in the worst-case
>* we queue the retire worker once too often.
>*/
> - if (lockless_dereference(dev_priv->gt.awake))
> + if (/*lockless_dereference*/(dev_priv->gt.awake))
>   queue_delayed_work(dev_priv->wq,
>  _priv->gt.retire_work,
>  round_jiffies_up_relative(HZ));
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f6de8dd567a2..2c1926418691 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3095,7 +3095,7 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>   if (!i915.enable_hangcheck)
>   return;
>  
> - if (!lockless_dereference(dev_priv->gt.awake))
> + if (!/*lockless_dereference*/(dev_priv->gt.awake))
>   return;
>  
>   /* As enabling the GPU requires fairly extensive mmio access,

Right, neither case appears to include a data dependency and thus
lockless_dereference() seems misguided.



[PATCH 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

2016-07-05 Thread Archit Taneja


On 07/01/2016 08:20 PM, Philipp Zabel wrote:
> From: Andrey Gusakov 
>
> Add a drm_bridge driver for the Toshiba TC358767 DPI/DSI to
> eDP/DP bridge. Currently only DPI input with 24-bit RGB is
> supported.
>
> Signed-off-by: Andrey Gusakov 
> Signed-off-by: Philipp Zabel 
> ---
>   drivers/gpu/drm/bridge/Kconfig|8 +
>   drivers/gpu/drm/bridge/Makefile   |1 +
>   drivers/gpu/drm/bridge/tc358767.c | 1419 
> +
>   3 files changed, 1428 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/tc358767.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..04c2b6d 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -50,6 +50,14 @@ config DRM_PARADE_PS8622
>   ---help---
> Parade eDP-LVDS bridge chip driver.
>
> +config DRM_TOSHIBA_TC358767
> + tristate "Toshiba TC358767 eDP bridge"
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + select DRM_PANEL
> + ---help---
> +   Toshiba TC358767 eDP bridge chip driver.
> +
>   source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
>   endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..7c21a3c 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>   obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>   obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> new file mode 100644
> index 000..515f123
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -0,0 +1,1419 @@
> +/*
> + * tc358767 eDP bridge driver
> + *
> + * Copyright (C) 2016 CogentEmbedded Inc
> + * Author: Andrey Gusakov 
> + *
> + * Copyright (C) 2016 Pengutronix, Philipp Zabel 
> + *
> + * Initially based on: drivers/gpu/drm/i2c/tda998x_drv.c
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

This may not be needed.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Registers */
> +
> +/* Display Parallel Interface */
> +#define DPIPXLFMT0x0440
> +#define VS_POL_ACTIVE_LOW(1 << 10)
> +#define HS_POL_ACTIVE_LOW(1 << 9)
> +#define DE_POL_ACTIVE_HIGH   (0 << 8)
> +#define SUB_CFG_TYPE_CONFIG1 (0 << 2) /* LSB aligned */
> +#define SUB_CFG_TYPE_CONFIG2 (1 << 2) /* Loosely Packed */
> +#define SUB_CFG_TYPE_CONFIG3 (2 << 2) /* LSB aligned 8-bit */
> +#define DPI_BPP_RGB888   (0 << 0)
> +#define DPI_BPP_RGB666   (1 << 0)
> +#define DPI_BPP_RGB565   (2 << 0)
> +
> +/* Video Path */
> +#define VPCTRL0  0x0450
> +#define OPXLFMT_RGB666   (0 << 8)
> +#define OPXLFMT_RGB888   (1 << 8)
> +#define FRMSYNC_DISABLED (0 << 4) /* Video Timing Gen Disabled */
> +#define FRMSYNC_ENABLED  (1 << 4) /* Video Timing Gen 
> Enabled */
> +#define MSF_DISABLED (0 << 0) /* Magic Square FRC disabled */
> +#define MSF_ENABLED  (1 << 0) /* Magic Square FRC enabled */
> +#define HTIM01   0x0454
> +#define HTIM02   0x0458
> +#define VTIM01   0x045c
> +#define VTIM02   0x0460
> +#define VFUEN0   0x0464
> +#define VFUENBIT(0)   /* Video Frame Timing 
> Upload */
> +
> +/* System */
> +#define TC_IDREG 0x0500
> +#define SYSCTRL  0x0510
> +#define DP0_AUDSRC_NO_INPUT  (0 << 3)
> +#define DP0_AUDSRC_I2S_RX(1 << 3)
> +#define DP0_VIDSRC_NO_INPUT  (0 << 0)
> +#define DP0_VIDSRC_DSI_RX(1 << 0)
> +#define DP0_VIDSRC_DPI_RX(2 << 0)
> +#define DP0_VIDSRC_COLOR_BAR (3 << 0)
> +
> +/* Control */
> +#define DP0CTL   0x0600
> +#define VID_MN_GEN   BIT(6)   /* Auto-generate M/N values */
> 

[PATCH 7/7] gpu: drm: vc4_hdmi: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Peter Chen
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Eric Anholt 
Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index fd2644d..26b6b06 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -465,12 +465,6 @@ static int vc4_hdmi_bind(struct device *dev, struct device 
*master, void *data)
if (IS_ERR(hdmi->hd_regs))
return PTR_ERR(hdmi->hd_regs);

-   ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
-   if (!ddc_node) {
-   DRM_ERROR("Failed to find ddc node in device tree\n");
-   return -ENODEV;
-   }
-
hdmi->pixel_clock = devm_clk_get(dev, "pixel");
if (IS_ERR(hdmi->pixel_clock)) {
DRM_ERROR("Failed to get pixel clock\n");
@@ -482,7 +476,14 @@ static int vc4_hdmi_bind(struct device *dev, struct device 
*master, void *data)
return PTR_ERR(hdmi->hsm_clock);
}

+   ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
+   if (!ddc_node) {
+   DRM_ERROR("Failed to find ddc node in device tree\n");
+   return -ENODEV;
+   }
+
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
+   of_node_put(ddc_node);
if (!hdmi->ddc) {
DRM_DEBUG("Failed to get ddc i2c adapter by node\n");
return -EPROBE_DEFER;
-- 
1.9.1



[PATCH 6/7] gpu: drm: sun4i_drv: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Peter Chen
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 76e922b..ca291ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -318,6 +318,7 @@ static int sun4i_drv_probe(struct platform_device *pdev)

count += sun4i_drv_add_endpoints(>dev, ,
pipeline);
+   of_node_put(pipeline);

DRM_DEBUG_DRIVER("Queued %d outputs on pipeline %d\n",
 count, i);
-- 
1.9.1



[PATCH 5/7] gpu: drm: sti_vtg: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Peter Chen
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/sti/sti_vtg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
index 6bf4ce4..0100c7c 100644
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -432,6 +432,7 @@ static int vtg_probe(struct platform_device *pdev)
np = of_parse_phandle(pdev->dev.of_node, "st,slave", 0);
if (np) {
vtg->slave = of_vtg_find(np);
+   of_node_put(np);

if (!vtg->slave)
return -EPROBE_DEFER;
-- 
1.9.1



[PATCH 4/7] gpu: drm: sti_hqvdp: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Peter Chen
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 1edec29..4f052fa 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1346,6 +1346,7 @@ static int sti_hqvdp_probe(struct platform_device *pdev)
vtg_np = of_parse_phandle(pdev->dev.of_node, "st,vtg", 0);
if (vtg_np)
hqvdp->vtg = of_vtg_find(vtg_np);
+   of_node_put(vtg_np);

platform_set_drvdata(pdev, hqvdp);

-- 
1.9.1



[PATCH 3/7] gpu: drm: sti_vdo: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Peter Chen
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/sti/sti_dvo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 25f7663..7e211a8 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -602,6 +602,7 @@ static int sti_dvo_probe(struct platform_device *pdev)
dvo->panel_node = of_parse_phandle(np, "sti,panel", 0);
if (!dvo->panel_node)
DRM_ERROR("No panel associated to the dvo output\n");
+   of_node_put(dvo->panel_node);

platform_set_drvdata(pdev, dvo);

-- 
1.9.1



[PATCH 2/7] gpu: drm: sti_compositor: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Peter Chen
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/sti/sti_compositor.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index 3d2fa3a..064de14 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -247,10 +247,12 @@ static int sti_compositor_probe(struct platform_device 
*pdev)
vtg_np = of_parse_phandle(pdev->dev.of_node, "st,vtg", 0);
if (vtg_np)
compo->vtg_main = of_vtg_find(vtg_np);
+   of_node_put(vtg_np);

vtg_np = of_parse_phandle(pdev->dev.of_node, "st,vtg", 1);
if (vtg_np)
compo->vtg_aux = of_vtg_find(vtg_np);
+   of_node_put(vtg_np);

platform_set_drvdata(pdev, compo);

-- 
1.9.1



[PATCH 1/7] gpu: drm: rockchip_drm_drv: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Peter Chen
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Mark Yao 
Cc: Heiko Stuebner 
Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a409d1f..935c5e0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -518,6 +518,7 @@ static int rockchip_drm_platform_probe(struct 
platform_device *pdev)
is_support_iommu = false;
}

+   of_node_put(iommu);
component_match_add(dev, , compare_of, port->parent);
of_node_put(port);
}
-- 
1.9.1



[PATCH 0/7] gpu: drm: remaining missing of_node_put issue fixes

2016-07-05 Thread Peter Chen
Hi David,

This is remaining missing of_node_put issue fix for gpu/drm drivers, the
other fixes I sent yesterday. I think it may be easier for reviewing
using patch set for similar issue, thanks.

Peter Chen (7):
  gpu: drm: rockchip_drm_drv: add missing of_node_put after calling
of_parse_phandle
  gpu: drm: sti_compositor: add missing of_node_put after calling
of_parse_phandle
  gpu: drm: sti_vdo: add missing of_node_put after calling
of_parse_phandle
  gpu: drm: sti_hqvdp: add missing of_node_put after calling
of_parse_phandle
  gpu: drm: sti_vtg: add missing of_node_put after calling
of_parse_phandle
  gpu: drm: sun4i_drv: add missing of_node_put after calling
of_parse_phandle
  gpu: drm: vc4_hdmi: add missing of_node_put after calling
of_parse_phandle

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  1 +
 drivers/gpu/drm/sti/sti_compositor.c|  2 ++
 drivers/gpu/drm/sti/sti_dvo.c   |  1 +
 drivers/gpu/drm/sti/sti_hqvdp.c |  1 +
 drivers/gpu/drm/sti/sti_vtg.c   |  1 +
 drivers/gpu/drm/sun4i/sun4i_drv.c   |  1 +
 drivers/gpu/drm/vc4/vc4_hdmi.c  | 13 +++--
 7 files changed, 14 insertions(+), 6 deletions(-)

-- 
1.9.1



[PATCH 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

2016-07-05 Thread Philipp Zabel
Hi Archit,

thanks for the review!

Am Dienstag, den 05.07.2016, 10:08 +0530 schrieb Archit Taneja:
[...]
> > +#include 
> 
> This may not be needed.

I'll check and remove it.

> > +#ifndef regmap_read_poll_timeout
> > +#define regmap_read_poll_timeout(map, addr, val, cond, sleep_us, 
> > timeout_us) \
> > +({ \
> > +   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> > +   int ret; \
> > +   might_sleep_if(sleep_us); \
> > +   for (;;) { \
> > +   ret = regmap_read((map), (addr), &(val)); \
> > +   if (ret) \
> > +   break; \
> > +   if (cond) \
> > +   break; \
> > +   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
> > +   ret = regmap_read((map), (addr), &(val)); \
> > +   break; \
> > +   } \
> > +   if (sleep_us) \
> > +   usleep_range((sleep_us >> 2) + 1, sleep_us); \
> > +   } \
> > +   ret ?: ((cond) ? 0 : -ETIMEDOUT); \
> > +})
> > +#endif
> 
> Is there a reason why this is wrapped around a #ifndef? I don't see it
> in the current regmap.h headers. It would also be nice if it were made
> into a function.

This is a macro similar to those defined in iopoll.h. It can't be a
function because the "cond"ition is specified by the caller and has to
be evaluated in the loop.
I'll submit this for regmap. If it doesn't get accepted I'll change this
into two properly named functions.

[...]
> > +static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk)
> > +{
> > +   int ret;
> > +   int i_pre, best_pre = 1;
> > +   int i_post, best_post = 1;
> > +   int div, best_div = 1;
> > +   int mul, best_mul = 1;
> > +   int delta, best_delta;
> > +   int ext_div[] = {1, 2, 3, 5, 7};
> > +   int best_pixelclock = 0;
> > +   int vco_hi = 0;
> > +   int pixelclock;
> > +
> > +   pixelclock = tc->pll_clk;
> > +
> > +   dev_dbg(tc->dev, "PLL: requested %d pixelclock, ref %d\n", pixelclock,
> > +   refclk);
> > +   best_delta = pixelclock;
> > +   /* big loops */
> 
> The above comment could be improved.

Will do.

> > +   for (i_pre = 0; i_pre < ARRAY_SIZE(ext_div); i_pre++) {
> > +   /* refclk / ext_pre_div should be in the 1 to 200 MHz range */
> > +   if ((refclk / ext_div[i_pre] > 2) ||
> 
> The > 200 Mhz check seems redundant, since no refclk beyond 38.4 Mhz is
> supported.

Indeed. I'll drop the check and update the comment.

> > +   (refclk / ext_div[i_pre] < 100))
> > +   continue;
> > +   for (i_post = 0; i_post < ARRAY_SIZE(ext_div); i_post++) {
> > +   for (div = 1; div <= 16; div++) {
> > +   u32 clk;
> > +   u64 tmp;
> > +
> > +   tmp = pixelclock * ext_div[i_pre] *
> > + ext_div[i_post] * div;
> > +   do_div(tmp, refclk);
> > +   mul = tmp;
> > +
> > +   clk = refclk / ext_div[i_pre] / div * mul /
> > + ext_div[i_post];
> 
> Some braces for the above expression might help :)

Ok.

> > +   delta = clk - pixelclock;
> > +
> > +   /* check limits */
> > +   if ((mul < 1) ||
> > +   (mul > 128))
> 
> minor comment: the above check could be in a single line.

Oversight, will fix.

[...]
> > +static int tc_aux_link_setup(struct tc_data *tc)
> > +{
> > +   unsigned long rate;
> > +   u32 value;
> > +   int ret;
> > +
> > +   rate = clk_get_rate(tc->refclk);
> 
> Ah, you can discard my comment on the clock binding in the DT patch.
> I guess you needed it to figure out the rate.

Alright, going back to the other mail and updating my answer.

> > +   switch (rate) {
> > +   case 3840:
> > +   value = REF_FREQ_38M4;
> > +   break;
> > +   case 2600:
> > +   value = REF_FREQ_26M;
> > +   break;
> > +   case 1920:
> > +   value = REF_FREQ_19M2;
> > +   break;
> > +   case 1300:
> > +   value = REF_FREQ_13M;
> > +   break;
> > +   default:
> > +   dev_err(tc->dev, "Invalid refclk rate: %lu Hz\n", rate);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Setup DP-PHY / PLL */
> > +   value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
> > +   tc_write(SYS_PLLPARAM, value);
> > +
> > +   tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
> 
> It seems a bit strange to have BIT(2) besides the other predefined
> macros.

I accidentally lost the comment when shortening this, BIT(2) is reserved
but set.

[...]
> > +   /* PXL PLL setup */
> > +   if (tc->test_pattern) {
> 
> I couldn't find out who is setting tc->test_pattern. Is it always
> 0?

Hm, you are right. I wonder what a good mechanism would be to enable a
test pattern for a bridge driver. Module parameters? We don't have
anyhting 

[PATCH 1/2] dt-bindings: tc358767: add DT documentation

2016-07-05 Thread Philipp Zabel
Hi Archit,

thank you for the comments.

Am Dienstag, den 05.07.2016, 08:53 +0530 schrieb Archit Taneja:
[...]
> > +Required properties:
> > + - compatible: "toshiba,tc358767"
> > + - reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap 
> > pins
> > + - clock-names: should be "ref"
> > + - clocks: OF device-tree clock specification for refclk input. The 
> > reference
> 
> Should we have this as an optional property? There could be platforms
> where an oscillator output on the board connects directly to the refclk
> pin, without any option to gate it.

As you said in the other mail, we need to know the refclk frequency. A
fixed-clock should be used to describe the oscillator in this case.

> > +   clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz.
> > +
> > +Optional properties:
> > + - shutdown-gpios: OF device-tree gpio specification for SD pin
> > +   (active high shutdown input)
> > + - reset-gpios: OF device-tree gpio specification for RSTX pin
> > +(active low system reset)
> > + - ports: the ports node can contain video interface port nodes to connect
> > +   to a DPI/DSI source and to an eDP/DP sink according to [1][2].
> 
> Just wondering about the future when DSI is implemented. Would we have
> different port numbers for DSI and DPI? And figure whether the input
> is DSI or DPI based on input the port number? If we go with that
> approach, it might make sense to have the bridge output port number
> as 2.

Good point, these are physically two separate ports and it should be
possible to switch between them at runtime in theory. Since the DSI is
listed first in the documentation, I'll change it to
 - port at 0: MIPI DSI Rx
 - port at 1: DPI Rx
 - port at 2: (e)DP Tx

regards
Philipp



[PATCH] drm: sti: fix prototypes after API change

2016-07-05 Thread Dave Airlie
On 5 July 2016 at 09:46, Stephen Rothwell  wrote:
> Hi Dave,
>
> On Mon, 4 Jul 2016 15:38:10 +0200 Mark Brown  wrote:
>>
>> On Mon, Jul 04, 2016 at 03:36:57PM +0200, Arnd Bergmann wrote:
>> > On Monday, July 4, 2016 3:22:30 PM CEST Mark Brown wrote:
>>
>> > > I sent a pull request for the API change to the DRM people which might
>> > > be easier given that it's a single commit topic branch rather than the
>> > > whole of DRM.
>>
>> > Agreed, that is probably the best way forward. Does your pull request
>> > also contain an equivalent of my two patches?
>>
>> No, I just sent a pull request for the API change - I don't have the new
>> patches in my tree.
>
> So to be very clear, what you would need to do is merge the one commit
> branch that Mark sent you a pull request for:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
> tags/asoc-hdmi-codec-pdata
>
> and as part of the merge commit (so e.g. "git apply ; git commit
> --amend" on top of the merge), add the two patches we are talking about:
>
>   "drm: sti: fix prototypes after API change"
>   "drm: mediatek: fix prototypes after API change"
>
> Then any further conflicts can hopefully be fixed up as they appear in
> your tree (if any).  Or be avoided by people developing against your
> tree.

Thanks Stephen,

I think I've done it correctly, I've just pushed out drm-next with the
pull and the
two changes amended into the merge.

Dave.


[PATCH] drm: sti: fix prototypes after API change

2016-07-05 Thread Stephen Rothwell
Hi Dave,

On Mon, 4 Jul 2016 15:38:10 +0200 Mark Brown  wrote:
>
> On Mon, Jul 04, 2016 at 03:36:57PM +0200, Arnd Bergmann wrote:
> > On Monday, July 4, 2016 3:22:30 PM CEST Mark Brown wrote:  
> 
> > > I sent a pull request for the API change to the DRM people which might
> > > be easier given that it's a single commit topic branch rather than the
> > > whole of DRM.  
> 
> > Agreed, that is probably the best way forward. Does your pull request
> > also contain an equivalent of my two patches?  
> 
> No, I just sent a pull request for the API change - I don't have the new
> patches in my tree.

So to be very clear, what you would need to do is merge the one commit
branch that Mark sent you a pull request for:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
tags/asoc-hdmi-codec-pdata

and as part of the merge commit (so e.g. "git apply ; git commit
--amend" on top of the merge), add the two patches we are talking about:

  "drm: sti: fix prototypes after API change"
  "drm: mediatek: fix prototypes after API change"

Then any further conflicts can hopefully be fixed up as they appear in
your tree (if any).  Or be avoided by people developing against your
tree.

-- 
Cheers,
Stephen Rothwell


[PATCH] drm: sti: fix prototypes after API change

2016-07-05 Thread Stephen Rothwell
Hi Arnd,

On Mon,  4 Jul 2016 15:16:51 +0200 Arnd Bergmann  wrote:
>
> Like the mediatek hdmi driver, the sti driver now suffers from
> an API change in linux-next:
> 
> drivers/gpu/drm/sti/sti_hdmi.c:1250:15: error: initialization from 
> incompatible pointer type [-Werror=incompatible-pointer-types]
>   .hw_params = hdmi_audio_hw_params,
>^~~~
> drivers/gpu/drm/sti/sti_hdmi.c:1250:15: note: (near initialization for 
> 'audio_codec_ops.hw_params')
> 
> This follows the API change, adding the extra function arguments.
> I suppose we want this to be part of the ASoC merge in linux-next
> for now too.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 2c348e505328 ("drm: sti: Add ASoC generic hdmi codec support.")
> Fixes: efc9194bcff8 ("ASoC: hdmi-codec: callback function will be called with 
> private data")
> Link: https://lkml.org/lkml/2016/6/29/441

Added to the sound-asoc merge from today.

-- 
Cheers,
Stephen Rothwell


[Bug 96789] Black screen with R9 290 and Apple Cinema Display 23"

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96789

--- Comment #2 from Benjamin Herrenschmidt  ---
Will it ? I mean, it works with every other driver under the sun ;-) Do you
have ways to know what AMD windows driver picks ? That could be a reasonable
choice for the Linux one...

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


[PATCH 7/7] gpu: drm: vc4_hdmi: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Eric Anholt
Peter Chen  writes:

> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
>
> Cc: Eric Anholt 
> Signed-off-by: Peter Chen 
> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index fd2644d..26b6b06 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -465,12 +465,6 @@ static int vc4_hdmi_bind(struct device *dev, struct 
> device *master, void *data)
>   if (IS_ERR(hdmi->hd_regs))
>   return PTR_ERR(hdmi->hd_regs);
>  
> - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> - if (!ddc_node) {
> - DRM_ERROR("Failed to find ddc node in device tree\n");
> - return -ENODEV;
> - }
> -
>   hdmi->pixel_clock = devm_clk_get(dev, "pixel");
>   if (IS_ERR(hdmi->pixel_clock)) {
>   DRM_ERROR("Failed to get pixel clock\n");
> @@ -482,7 +476,14 @@ static int vc4_hdmi_bind(struct device *dev, struct 
> device *master, void *data)
>   return PTR_ERR(hdmi->hsm_clock);
>   }
>  
> + ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> + if (!ddc_node) {
> + DRM_ERROR("Failed to find ddc node in device tree\n");
> + return -ENODEV;
> + }
> +
>   hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
> + of_node_put(ddc_node);
>   if (!hdmi->ddc) {
>   DRM_DEBUG("Failed to get ddc i2c adapter by node\n");
>   return -EPROBE_DEFER;
> -- 

Reviewed-by: Eric Anholt 

It would be nice if we could just pass the phandle spec directly to the
i2c function.  OF code always seems terribly verbose to me (and
error-prone in this exact way) because of the separate phandle lookup.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160705/7ec93ff2/attachment.sig>


[PATCH 6/7] gpu: drm: sun4i_drv: add missing of_node_put after calling of_parse_phandle

2016-07-05 Thread Maxime Ripard
On Tue, Jul 05, 2016 at 10:04:53AM +0800, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
> 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Signed-off-by: Peter Chen 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160705/6f146862/attachment.sig>


[Bug 96789] Black screen with R9 290 and Apple Cinema Display 23"

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96789

--- Comment #1 from Christian König  ---
Well that is a rather special case. The monitor needs a very precise timing to
work reliable and even with the higher ref/post dividers we don't hit it
completely correct.

Not sure what to do here, cause raising the limit will certainly break others
again.

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


[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

2016-07-05 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #35 from Benjamin Herrenschmidt  ---
https://bugs.freedesktop.org/show_bug.cgi?id=96789

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


[PATCH 1/2] dt-bindings: tc358767: add DT documentation

2016-07-05 Thread Archit Taneja
Hi,

On 07/01/2016 08:20 PM, Philipp Zabel wrote:
> Add DT binding documentation for the Toshiba TC358767 eDP bridge.
>
> Signed-off-by: Philipp Zabel 
> ---
>   .../bindings/display/bridge/toshiba,tc358767.txt   | 48 
> ++
>   1 file changed, 48 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt 
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> new file mode 100644
> index 000..c58a59f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> @@ -0,0 +1,48 @@
> +Toshiba TC358767 eDP bridge bindings
> +
> +Required properties:
> + - compatible: "toshiba,tc358767"
> + - reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins
> + - clock-names: should be "ref"
> + - clocks: OF device-tree clock specification for refclk input. The reference

Should we have this as an optional property? There could be platforms
where an oscillator output on the board connects directly to the refclk
pin, without any option to gate it.

> +   clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz.
> +
> +Optional properties:
> + - shutdown-gpios: OF device-tree gpio specification for SD pin
> +   (active high shutdown input)
> + - reset-gpios: OF device-tree gpio specification for RSTX pin
> +(active low system reset)
> + - ports: the ports node can contain video interface port nodes to connect
> +   to a DPI/DSI source and to an eDP/DP sink according to [1][2].

Just wondering about the future when DSI is implemented. Would we have
different port numbers for DSI and DPI? And figure whether the input
is DSI or DPI based on input the port number? If we go with that
approach, it might make sense to have the bridge output port number
as 2.

Thanks,
Archit

> +
> +[1]: Documentation/devicetree/bindings/graph.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + edp-bridge at 68 {
> + compatible = "toshiba,tc358767";
> + reg = <0x68>;
> + shutdown-gpios = < 23 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 24 GPIO_ACTIVE_LOW>;
> + clock-names = "ref";
> + clocks = <_refclk>;
> +
> + ports {
> + port at 0 {
> + reg = <0>;
> +
> + bridge_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + bridge_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


[PATCH 3/3] drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set

2016-07-05 Thread Sinclair Yeh
Argh, you're right.  I'll send out a patch.  Thanks for catching this!

Sinclair

On Mon, Jul 04, 2016 at 04:51:52PM +0100, Emil Velikov wrote:
> Hi Sinclair,
> 
> On 1 July 2016 at 19:24,   wrote:
> > From: Sinclair Yeh 
> >
> > For the Screen Object display unit, we need to reserve a
> > guest-invisible region equal to the size of the framebuffer for
> > the host.  This region can only be reserved in VRAM, whereas
> > the guest-visible framebuffer can be reserved in either VRAM or
> > GMR.
> >
> > As such priority should be given to the guest-invisible
> > region otherwise in a limited VRAM situation, we can fail to
> > allocate this region.
> >
> > This patch makes it so that vmw_sou_backing_alloc() is called
> > before the framebuffer is pinned.
> >
> > Signed-off-by: Sinclair Yeh 
> > Reviewed-by: Thomas Hellstrom 
> > Cc: 
> > ---
> > This is the last patch of a 3-patch series to fix console black
> > screen issue on Ubuntu 16.04 server
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 47 
> > --
> >  1 file changed, 25 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > index 679a4cb..66eaa30 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > @@ -517,28 +517,6 @@ static int vmw_fb_kms_framebuffer(struct fb_info *info)
> >
> > par->set_fb = >base;
> >
> > -   if (!par->bo_ptr) {
> > -   /*
> > -* Pin before mapping. Since we don't know in what placement
> > -* to pin, call into KMS to do it for us.
> > -*/
> > -   ret = vfb->pin(vfb);
> > -   if (ret) {
> > -   DRM_ERROR("Could not pin the fbdev framebuffer.\n");
> > -   return ret;
> > -   }
> > -
> > -   ret = ttm_bo_kmap(>vmw_bo->base, 0,
> > - par->vmw_bo->base.num_pages, >map);
> > -   if (ret) {
> > -   vfb->unpin(vfb);
> > -   DRM_ERROR("Could not map the fbdev framebuffer.\n");
> > -   return ret;
> > -   }
> > -
> > -   par->bo_ptr = ttm_kmap_obj_virtual(>map, 
> > >bo_iowrite);
> > -   }
> > -
> > return 0;
> >  }
> >
> > @@ -601,6 +579,31 @@ static int vmw_fb_set_par(struct fb_info *info)
> > if (ret)
> > goto out_unlock;
> >
> > +   if (!par->bo_ptr) {
> > +   struct vmw_framebuffer *vfb = 
> > vmw_framebuffer_to_vfb(set.fb);
> > +
> > +   /*
> > +* Pin before mapping. Since we don't know in what placement
> > +* to pin, call into KMS to do it for us.
> > +*/
> > +   ret = vfb->pin(vfb);
> > +   if (ret) {
> > +   DRM_ERROR("Could not pin the fbdev framebuffer.\n");
> > +   return ret;
> > +   }
> > +
> > +   ret = ttm_bo_kmap(>vmw_bo->base, 0,
> > + par->vmw_bo->base.num_pages, >map);
> > +   if (ret) {
> > +   vfb->unpin(vfb);
> > +   DRM_ERROR("Could not map the fbdev framebuffer.\n");
> > +   return ret;
> > +   }
> > +
> > +   par->bo_ptr = ttm_kmap_obj_virtual(>map, 
> > >bo_iowrite);
> > +   }
> > +
> > +
> Seems like you forgot to update the error paths. Thankfully we
> shouldn't be reaching those too often, if at all.
> 
> -Emil


[PATCH v2 1/2] drm/fsl-dcu: rework codes to support of_graph dt binding for panel

2016-07-05 Thread Meng Yi
Hi Stefan,

Those two patches actually can be merged independently. Do you
have some more comments?

Best Regards,
Meng

> -Original Message-
> From: Meng Yi [mailto:meng.yi at nxp.com]
> Sent: Tuesday, June 28, 2016 5:32 PM
> To: stefan at agner.ch
> Cc: airlied at linux.ie; emil.l.velikov at gmail.com; jianwei.wang.chn at 
> gmail.com;
> alexander.stein at systec-electronic.com; dri-devel at lists.freedesktop.org;
> Meng Yi 
> Subject: [PATCH v2 1/2] drm/fsl-dcu: rework codes to support of_graph dt
> binding for panel
> 
> This patch rework the output code to add of_graph dt binding support for
> panel device and also keeps the backward compatibility
> 
> Signed-off-by: Meng Yi 
> ---
> Changes in V2:
> -fix some coding style issue
> -add fsl_dev->connector.panel check
> -use fsl_dev->np and drop fsl_dev->dev->of_node -return 'ret' when
> fsl_dcu_attach_panel failed
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h |  3 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 79 --
> --
>  3 files changed, 60 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> index c564ec6..b48ffa7 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> @@ -43,7 +43,7 @@ int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device
> *fsl_dev)
>   if (ret)
>   goto fail_encoder;
> 
> - ret = fsl_dcu_drm_connector_create(fsl_dev, _dev->encoder);
> + ret = fsl_dcu_create_outputs(fsl_dev);
>   if (ret)
>   goto fail_connector;
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> index 7093109..5a7b88e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> @@ -25,9 +25,8 @@ to_fsl_dcu_connector(struct drm_connector *con)
>: NULL;
>  }
> 
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder);
>  int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev,
>  struct drm_crtc *crtc);
> +int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev);
> 
>  #endif /* __FSL_DCU_DRM_CONNECTOR_H__ */ diff --git
> a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_rgb.c
> index 98c998d..b23cc58 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -10,6 +10,7 @@
>   */
> 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -141,15 +142,15 @@ static const struct drm_connector_helper_funcs
> connector_helper_funcs = {
>   .mode_valid = fsl_dcu_drm_connector_mode_valid,  };
> 
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder)
> +static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
> + struct drm_panel *panel)
>  {
> + struct drm_encoder *encoder = _dev->encoder;
>   struct drm_connector *connector = _dev->connector.base;
>   struct drm_mode_config *mode_config = _dev->drm-
> >mode_config;
> - struct device_node *panel_node;
>   int ret;
> 
> - fsl_dev->connector.encoder = encoder;
> + fsl_dev->connector.encoder = _dev->encoder;
> 
>   ret = drm_connector_init(fsl_dev->drm, connector,
>_dcu_drm_connector_funcs,
> @@ -170,21 +171,7 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
> mode_config->dpms_property,
> DRM_MODE_DPMS_OFF);
> 
> - panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
> - if (!panel_node) {
> - dev_err(fsl_dev->dev, "fsl,panel property not found\n");
> - ret = -ENODEV;
> - goto err_sysfs;
> - }
> -
> - fsl_dev->connector.panel = of_drm_find_panel(panel_node);
> - if (!fsl_dev->connector.panel) {
> - ret = -EPROBE_DEFER;
> - goto err_panel;
> - }
> - of_node_put(panel_node);
> -
> - ret = drm_panel_attach(fsl_dev->connector.panel, connector);
> + ret = drm_panel_attach(panel, connector);
>   if (ret) {
>   dev_err(fsl_dev->dev, "failed to attach panel\n");
>   goto err_sysfs;
> @@ -192,11 +179,61 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
> 
>   return 0;
> 
> -err_panel:
> - of_node_put(panel_node);
>  err_sysfs:
>   drm_connector_unregister(connector);
>  err_cleanup:
>   drm_connector_cleanup(connector);
>   return ret;
>  }
> +
> +static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
> + const 

[Bug 96672] [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96672

Shawn Starr  changed:

   What|Removed |Added

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

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


[Bug 96672] [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96672

Shawn Starr  changed:

   What|Removed |Added

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

--- Comment #4 from Shawn Starr  ---
LLVM regression, fixed in trunk, closing

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


[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96678

--- Comment #8 from Quentin Quaadgras  ---
Created attachment 124900
  --> https://bugs.freedesktop.org/attachment.cgi?id=124900=edit
GDB bt full of the crash (dbg packages installed)

Thanks for providing some information Joost :)

@Nicolai
I have attached the gdb bt full trace.

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


[Bug 96794] VM_CONTEXT1_PROTECTION_FAULT_ADDR

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96794

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #4 from Michel Dänzer  ---


*** This bug has been marked as a duplicate of bug 96731 ***

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


[Bug 96731] [RADEONSI] [LLVM] [bisected] GPU lockups when running Alien: Isolation

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96731

Michel Dänzer  changed:

   What|Removed |Added

 CC||t.hirsch at web.de

--- Comment #14 from Michel Dänzer  ---
*** Bug 96794 has been marked as a duplicate of this bug. ***

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


[Bug 96790] frame stuttering in ut2004

2016-07-05 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96790

--- Comment #9 from Michel Dänzer  ---
Do the drops correspond to the small bumps on the lowermost graph?

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