Re: [Nouveau] [PATCH REBASED 2/2] nouveau/bl: Do not register interface if Apple GMUX detected

2016-04-17 Thread Lukas Wunner
Hi,

On Sun, Apr 17, 2016 at 09:57:42PM +0200, Pierre Moreau wrote:
> The Apple GMUX is the one managing the backlight, so there is no need for
> Nouveau to register its own backlight interface.
> 
> Signed-off-by: Pierre Moreau 
> ---
>  drm/nouveau/nouveau_backlight.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
> index 41330e4..94ac3cb 100644
> --- a/drm/nouveau/nouveau_backlight.c
> +++ b/drm/nouveau/nouveau_backlight.c
> @@ -30,6 +30,7 @@
>   * Register locations derived from NVClock by Roderick Colenbrander
>   */
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -257,6 +258,12 @@ nouveau_backlight_init(struct drm_device *dev)
>   struct nvif_device *device = >device;
>   struct drm_connector *connector;
>  
> + if (apple_gmux_present()) {
> + NV_INFO(drm, "Apple GMUX detected: not registering Nouveau"
> + " backlight interface");

Small nit -- Documentation/CodingStyle, chapter 2 says:

"However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them."

Thanks,

Lukas

> + return 0;
> + }
> +
>   INIT_LIST_HEAD(>bl_connectors);
>  
>   list_for_each_entry(connector, >mode_config.connector_list, head) {
> -- 
> 2.8.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH v2 1/2] nouveau/bl: Assign different names to interfaces

2016-04-17 Thread Pierre Moreau
Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.

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

v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
  suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_backlight.c | 64 ++---
 drm/nouveau/nouveau_display.h   | 10 +++
 drm/nouveau/nouveau_drm.c   |  2 ++
 drm/nouveau/nouveau_drm.h   |  1 +
 4 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 89eb460..41330e4 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -31,11 +31,31 @@
  */
 
 #include 
+#include 
 
 #include "nouveau_drm.h"
 #include "nouveau_reg.h"
 #include "nouveau_encoder.h"
 
+static struct ida bl_ida;
+
+struct backlight_connector {
+   struct list_head head;
+   int id;
+};
+
+static void
+nouveau_get_backlight_name(char backlight_name[15], struct backlight_connector
+   *connector)
+{
+   const int nb = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
+   if (nb > 0 && nb < 100)
+   sprintf(backlight_name, "nv_backlight%d", nb);
+   else
+   sprintf(backlight_name, "nv_backlight");
+   connector->id = nb;
+}
+
 static int
 nv40_get_intensity(struct backlight_device *bd)
 {
@@ -74,6 +94,8 @@ nv40_backlight_init(struct drm_connector *connector)
struct nvif_object *device = >device.object;
struct backlight_properties props;
struct backlight_device *bd;
+   struct backlight_connector bl_connector;
+   char backlight_name[15]; // 12 for name + 2 for digits + 1 for '\0'
 
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return 0;
@@ -81,10 +103,16 @@ nv40_backlight_init(struct drm_connector *connector)
memset(, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 31;
-   bd = backlight_device_register("nv_backlight", connector->kdev, drm,
+   nouveau_get_backlight_name(backlight_name, _connector);
+   bd = backlight_device_register(backlight_name , connector->kdev, drm,
   _bl_ops, );
-   if (IS_ERR(bd))
+
+   if (IS_ERR(bd)) {
+   if (bl_connector.id > 0)
+   ida_simple_remove(_ida, bl_connector.id);
return PTR_ERR(bd);
+   }
+   list_add(_connector.head, >bl_connectors);
drm->backlight = bd;
bd->props.brightness = nv40_get_intensity(bd);
backlight_update_status(bd);
@@ -182,6 +210,8 @@ nv50_backlight_init(struct drm_connector *connector)
struct backlight_properties props;
struct backlight_device *bd;
const struct backlight_ops *ops;
+   struct backlight_connector bl_connector;
+   char backlight_name[15]; // 12 for name + 2 for digits + 1 for '\0'
 
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -203,11 +233,17 @@ nv50_backlight_init(struct drm_connector *connector)
memset(, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 100;
-   bd = backlight_device_register("nv_backlight", connector->kdev,
+   nouveau_get_backlight_name(backlight_name, _connector);
+   bd = backlight_device_register(backlight_name , connector->kdev,
   nv_encoder, ops, );
-   if (IS_ERR(bd))
+
+   if (IS_ERR(bd)) {
+   if (bl_connector.id > 0)
+   ida_simple_remove(_ida, bl_connector.id);
return PTR_ERR(bd);
+   }
 
+   list_add(_connector.head, >bl_connectors);
drm->backlight = bd;
bd->props.brightness = bd->ops->get_brightness(bd);
backlight_update_status(bd);
@@ -221,6 +257,8 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = >device;
struct drm_connector *connector;
 
+   INIT_LIST_HEAD(>bl_connectors);
+
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
@@ -246,9 +284,27 @@ void
 nouveau_backlight_exit(struct drm_device *dev)
 {

[Nouveau] [PATCH REBASED 2/2] nouveau/bl: Do not register interface if Apple GMUX detected

2016-04-17 Thread Pierre Moreau
The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.

Signed-off-by: Pierre Moreau 
---
 drm/nouveau/nouveau_backlight.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 41330e4..94ac3cb 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -30,6 +30,7 @@
  * Register locations derived from NVClock by Roderick Colenbrander
  */
 
+#include 
 #include 
 #include 
 
@@ -257,6 +258,12 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = >device;
struct drm_connector *connector;
 
+   if (apple_gmux_present()) {
+   NV_INFO(drm, "Apple GMUX detected: not registering Nouveau"
+   " backlight interface");
+   return 0;
+   }
+
INIT_LIST_HEAD(>bl_connectors);
 
list_for_each_entry(connector, >mode_config.connector_list, head) {
-- 
2.8.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 91523] [NVE7] driver cannot initialize gpu(failed to parse ramcfg data)

2016-04-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91523

--- Comment #3 from Ilia Bozhinov  ---
It seems that the code that triggers this bug is in
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.cpp around line 1583. It seems
that the assumption in the comment is not true, on my card this condition
obviously doesn't mean that the card should be ignored completely. This maybe
has some other meaning, does anybody know how I can help debugging the problem?
I'm posting the comment in the code:

/* parse bios data for all rammap table entries up-front, and   
 * build information on whether certain fields differ between   
 * any of the entries.  
 *  
 * the binary driver appears to completely ignore some fields   
 * when all entries contain the same value.  at first, it was   
 * hoped that these were mere optimisations and the bios init   
 * tables had configured as per the values here, but there is   
 * evidence now to suggest that this isn't the case and we do   
 * need to treat this condition as a "don't touch" indicator.   
 */

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0

2016-04-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=93458

Ilia Mirkin  changed:

   What|Removed |Added

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

--- Comment #8 from Ilia Mirkin  ---
This should be now upstream with

commit 78a121d82da8aff3aca2a6a1c40f5061081760f0
Author: Ilia Mirkin 
Date:   Sun Mar 6 16:06:06 2016 -0500

drm/nouveau/core: use vzalloc for allocating ramht

Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a
fairly sizeable chunk of memory to be allocated, which may not be
available with kzalloc. Since this is done fairly rarely (once per
channel), use vzalloc instead.

Signed-off-by: Ilia Mirkin 
Signed-off-by: Ben Skeggs 

Zlatko - I didn't realize (or perhaps totally forgot) you had provided the same
patch, didn't mean to steal credit or anything like that. Just ran into the
same issue myself and sent a patch. In the future, feel free to send patches to
the mailing list.

This issue should be resolved in v4.6-rc1+.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 94342] Nvidia G96GLM 3840x2160@30 not functional with nouveau

2016-04-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=94342

--- Comment #4 from Elmar Stellnberger  ---
4.6.0-rc2-ARCH-4-g603539d: As soon as I boot with a hdmimhz=297 I get a
blackscreen though the graphics card is known to work with 3840x2160@30 under
Windows; i.e. that should work.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 93887] [NV96] Amilo Xi 3650: G96M [GeForce 9600M GT]: HDMI monitor stays black after s2ram

2016-04-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=93887

--- Comment #17 from Elmar Stellnberger  ---
Created attachment 123007
  --> https://bugs.freedesktop.org/attachment.cgi?id=123007=edit
journal: delayed wakeup with Celsius on 4.6.0-rc2

  Now I have also tried it with the Celsius; s2ram has significantly improved
since my last test as the machine never crashed. At first bootup 3 s2rams
worked ok and at the second bootup the same problem as before seemed to appear:
the original screen content flashed up then the monitor turning black again
thereafter immediately. However this time Num Lock was still working and I
could make the machine come up again by pressing Ctrl-Alt-Entf on the
integrated keyboard (which I did for both s2ram tests on the second bootup
after a minute or so). External monitor staying black after s2ram; also here
with the Celsius and kernel 4.6.0-rc2.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0

2016-04-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=93458

--- Comment #7 from Matt Whitlock  ---
FYI: Ilia Mirkin submitted the patch from Comment 4 to the Nouveau listserv on
6 Mar 2016. I think I'll apply this patch to my 4.4.7 kernel.

http://permalink.gmane.org/gmane.comp.freedesktop.xorg.nouveau/24081

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces

2016-04-17 Thread Pierre Moreau
[…]

> 
> > +   const int nb = atomic_inc_return(_interfaces_nb) - 1;
> 
> This kinda sucks if you reload nouveau a bunch. How about using an
> "ida". Have a look in drivers/gpu/drm/drm_crtc.c for how I use that
> one.

I had a quick look at drm_crtc.c. This seems to be exactly what I need, except
that I do not see how I can enforce to have one of the active ones being named
`nv_backlight`, to not break (possibly) existing userspace applications. (I’m
guessing that I would be doing the same as in drm_crtc.c: looping over all
connectors and assigning them an ida, regardless of them being active or not,
as they might become active later on.)

There is another issue that I failed to address with this patch, and just
realised about it. Each time `nvXX_backlight_init(connector)` is called on a
connector, a new backlight device is created, and is stored in
`drm->backlight`, which is unique at a device level, not connector level,
meaning the old one just gets overriden (and leaked). Having a list
`drm->backlights` should solve this issue. Would that be fine with you Ben?

Pierre

> 
> > +   if (nb > 0 && nb < 100)
> > +   sprintf(backlight_name, "nv_backlight%d", nb);
> > +   else
> > +   sprintf(backlight_name, "nv_backlight");
> > +   return backlight_name;
> > +}
> > --
> > 2.8.0
> >
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau


signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0

2016-04-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=93458

--- Comment #6 from Matt Whitlock  ---
(In reply to Matt Whitlock from comment #5)
> I would venture a guess that the memory allocated for a GPU FIFO buffer
> needs to be physically continuous, as it will be used for DMA

I take it back. Looking into the source code, the allocation is happening in
nvkm_ramht_new(…), which is allocating a struct nvkm_ramht containing a
variably-sized array of struct nvkm_ramht_data elements. As these elements, in
turn, contain pointers, it seems very unlikely that they'd be DMA'd, so
presumably the struct nvkm_ramht doesn't need to be physically contiguous and
could safely be allocated by vzalloc(…).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0

2016-04-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=93458

Matt Whitlock  changed:

   What|Removed |Added

 CC||freedesk...@mattwhitlock.na
   ||me

--- Comment #5 from Matt Whitlock  ---
I've run into this exact same failure on Linux kernel 4.4.7-gentoo.

01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT]
(rev a1)

systemmonitor: page allocation failure: order:5, mode:0x240c0c0
CPU: 2 PID: 25678 Comm: systemmonitor Not tainted 4.4.7-gentoo #1
Hardware name:  /D975XBX2, BIOS
BX97520J.86A.2836.2008.0728.1946 07/28/2008
  815e2614 0240c0c0 88010005b970
 810bbc14 88019381  81a7cbc0
 0005 0040 88019381 0240c0c0
Call Trace:
 [] ? dump_stack+0x46/0x59
 [] ? warn_alloc_failed+0xd4/0x120
 [] ? __alloc_pages_nodemask+0x16f/0x910
 [] ? alloc_kmem_pages+0x17/0x80
 [] ? kmalloc_order+0xf/0x40
 [] ? nvkm_ramht_new+0x3b/0xe0
 [] ? g84_fifo_chan_ctor+0x13a/0x170
 [] ? g84_fifo_gpfifo_new+0xb9/0x2e0
 [] ? nvkm_udevice_child_get+0x60/0xf0
 [] ? nvkm_ioctl_new+0x11d/0x260
 [] ? nvkm_udevice_map+0x40/0x40
 [] ? nvkm_ioctl+0xf7/0x240
 [] ? nvif_object_init+0xb5/0x120
 [] ? nouveau_channel_new+0xa8/0x660
 [] ? nouveau_abi16_ioctl_channel_alloc+0xd3/0x2d0
 [] ? nvkm_client_notify+0x20/0x20
 [] ? drm_ioctl+0x119/0x480
 [] ? page_add_file_rmap+0x2a/0x50
 [] ? nouveau_abi16_ioctl_setparam+0x10/0x10
 [] ? nouveau_drm_ioctl+0x5b/0xb0
 [] ? do_vfs_ioctl+0x293/0x470
 [] ? __do_page_fault+0x169/0x380
 [] ? SyS_ioctl+0x36/0x70
 [] ? entry_SYSCALL_64_fastpath+0x16/0x6e
Mem-Info:
active_anon:254439 inactive_anon:246298 isolated_anon:0
 active_file:689086 inactive_file:691252 isolated_file:0
 unevictable:44 dirty:24538 writeback:0 unstable:0
 slab_reclaimable:50180 slab_unreclaimable:9054
 mapped:71902 shmem:9819 pagetables:6004 bounce:0
 free:28497 free_pcp:31 free_cma:0
DMA free:15828kB min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:15928kB managed:15844kB mlocked:0kB dirty:0kB
writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:16kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable?
yes
lowmem_reserve[]: 0 3234 7957 7957
DMA32 free:37400kB min:4576kB low:5720kB high:6864kB active_anon:312136kB
inactive_anon:457768kB active_file:1151848kB inactive_file:1153596kB
unevictable:120kB isolated(anon):0kB isolated(file):0kB present:3389592kB
managed:3314852kB mlocked:120kB dirty:26704kB writeback:0kB mapped:122180kB
shmem:15400kB slab_reclaimable:81552kB slab_unreclaimable:13116kB
kernel_stack:2544kB pagetables:9160kB unstable:0kB bounce:0kB free_pcp:4kB
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable?
no
lowmem_reserve[]: 0 0 4722 4722
Normal free:60760kB min:6684kB low:8352kB high:10024kB active_anon:705620kB
inactive_anon:527424kB active_file:1604496kB inactive_file:1611412kB
unevictable:56kB isolated(anon):0kB isolated(file):0kB present:4980736kB
managed:4836224kB mlocked:56kB dirty:71448kB writeback:0kB mapped:165428kB
shmem:23876kB slab_reclaimable:119168kB slab_unreclaimable:23084kB
kernel_stack:4976kB pagetables:14856kB unstable:0kB bounce:0kB free_pcp:120kB
local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable?
no
lowmem_reserve[]: 0 0 0 0
DMA: 1*4kB (U) 0*8kB 1*16kB (U) 0*32kB 1*64kB (U) 1*128kB (U) 1*256kB (U)
0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15828kB
DMA32: 8708*4kB (UME) 334*8kB (UME) 17*16kB (UME) 0*32kB 0*64kB 0*128kB 0*256kB
0*512kB 0*1024kB 0*2048kB 0*4096kB = 37776kB
Normal: 15206*4kB (UME) 3*8kB (U) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 60848kB
1390493 total pagecache pages
276 pages in swap cache
Swap cache stats: add 8903, delete 8627, find 314/531
Free swap  = 8354200kB
Total swap = 8388604kB
2096564 pages RAM
0 pages HighMem/MovableOnly
54834 pages reserved


(In reply to Zlatko Calusic from comment #4)
> I've had lots of success using the attached patch. 4 days and still running
> strong, no page allocation failures. But, some core developer should
> probably confirm that using vmalloc instead of kmalloc is ok in that
> function.

I would venture a guess that the memory allocated for a GPU FIFO buffer needs
to be physically continuous, as it will be used for DMA, so using vmalloc is a
bad idea that may lead to incorrect pages being read/written by DMA.

Aside: Does this bug report belong on this bug tracker, or would it be more
appropriate on the kernel bug tracker? This is a problem in