Re: [Nouveau] [PATCH v2 1/2] drm/nouveau: Fix ida leak

[Pierre Moreau]

Why remove the const modifier on `nb`?

On 2021-05-11 — 16:28, Zhen Lei wrote:
> When the 'nb' value allocated from 'bl_ida' is greater than or equal to
> 100, it will not be released. In fact, we can simplify operations by
> limiting the range of idas that can be applied for.
> 
> By the way, delete the const modifier of the local variable 'nb'.
> 
> Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
> Signed-off-by: Zhen Lei 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 72f35a2babcb20e..d1c998e645fb4b6 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -51,8 +51,9 @@ static bool
>  nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE],
>  struct nouveau_backlight *bl)
>  {
> - const int nb = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> - if (nb < 0 || nb >= 100)
> + int nb = ida_simple_get(_ida, 0, 100, GFP_KERNEL);
> +
> + if (nb < 0)
>   return false;
>   if (nb > 0)
>   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
> -- 
> 2.26.0.106.g9fadedd
> 
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 2/2] drm/nouveau: Fix error return code in nouveau_backlight_init()

[Pierre Moreau]

Reviewed-by: Pierre Moreau 

On 2021-05-11 — 16:28, Zhen Lei wrote:
> Fix to return a negative error code from the error handling case instead
> of 0, as done elsewhere in this function.
> 
> Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
> Suggested-by: Pierre Moreau 
> Signed-off-by: Zhen Lei 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index d1c998e645fb4b6..f0856adbe775624 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -47,20 +47,20 @@ struct nouveau_backlight {
>   int id;
>  };
>  
> -static bool
> +static int
>  nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE],
>  struct nouveau_backlight *bl)
>  {
>   int nb = ida_simple_get(_ida, 0, 100, GFP_KERNEL);
>  
>   if (nb < 0)
> - return false;
> + return nb;
>   if (nb > 0)
>   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
>   else
>   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight");
>   bl->id = nb;
> - return true;
> + return 0;
>  }
>  
>  static int
> @@ -273,7 +273,8 @@ nouveau_backlight_init(struct drm_connector *connector)
>   if (!bl)
>   return -ENOMEM;
>  
> - if (!nouveau_get_backlight_name(backlight_name, bl)) {
> + ret = nouveau_get_backlight_name(backlight_name, bl);
> + if (ret) {
>   NV_ERROR(drm, "Failed to retrieve a unique name for the 
> backlight interface\n");
>   goto fail_alloc;
>   }
> -- 
> 2.26.0.106.g9fadedd
> 
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/1] drm/nouveau: fix error return code in nouveau_backlight_init()

[Pierre Moreau]

Hello Zhen,

There was a similar patch sent in last month, though which does not seem to
have been merged yet; see
https://lists.freedesktop.org/archives/nouveau/2021-April/038451.html.

Whether `ret` should be `-ENOSPC` or `-ENOMEM` is hard to say as
`nouveau_get_backlight_name()` could fail due to either.

I will propose an alternative fix which modifies `nouveau_get_backlight_name()`
to return an int so the actual error code can be propagated back instead of
guessed, as well as fix an ida ID leak which I just spotted.

Best,
Pierre

On 2021-05-08 — 11:48, Zhen Lei wrote:
> Fix to return a negative error code from the error handling case instead
> of 0, as done elsewhere in this function.
> 
> Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
> Reported-by: Hulk Robot 
> Signed-off-by: Zhen Lei 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 72f35a2babcb..097ca344a086 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -273,6 +273,7 @@ nouveau_backlight_init(struct drm_connector *connector)
>   return -ENOMEM;
>  
>   if (!nouveau_get_backlight_name(backlight_name, bl)) {
> + ret = -ENOSPC;
>   NV_ERROR(drm, "Failed to retrieve a unique name for the 
> backlight interface\n");
>   goto fail_alloc;
>   }
> -- 
> 2.25.1
> 
> 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: fix an error code in nouveau_backlight_init()

[Pierre Moreau]

I can not remember why the original code did return 0 rather than an error, but
-ENOMEM seems indeed way more fitting.

Reviewed-by: Pierre Moreau 

On 2021-04-14 — 08:58, Dan Carpenter wrote:
> If nouveau_get_backlight_name() fails then this should return -ENOMEM
> but currently it returns success.
> 
> Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
> Signed-off-by: Dan Carpenter 
> ---
> This is from static analysis.  In the original commit db1a0ae21461
> ("drm/nouveau/bl: Assign different names to interfaces") then returning
> zero seemed to be a very deliberate choice.  I do think it was wrong
> though and -ENOMEM is the currect return.
> 
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 72f35a2babcb..3786b1c85182 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -274,6 +274,7 @@ nouveau_backlight_init(struct drm_connector *connector)
>  
>   if (!nouveau_get_backlight_name(backlight_name, bl)) {
>   NV_ERROR(drm, "Failed to retrieve a unique name for the 
> backlight interface\n");
> + ret = -ENOMEM;
>   goto fail_alloc;
>   }
>  
> -- 
> 2.30.2
> 
> ___
> 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

Re: [Nouveau] [PATCH] drm/nouveau/mmu: Remove unneeded semicolon

[Pierre Moreau]

With the comment further below addressed, this patch is
Reviewed-by: Pierre Moreau 

On 2019-12-16 — 11:48, zhengbin wrote:
> Fixes coccicheck warning:
> 
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded semicolon
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded semicolon
> 
> Reported-by: Hulk Robot 
> Signed-off-by: zhengbin 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> index 41640e0..199f94e 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> @@ -580,7 +580,7 @@ nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct 
> nvkm_vmm_page *page,
>   it.pte[it.lvl]++;
>   }
>   }
> - };
> + }
> 
>   nvkm_vmm_flush();
>   return ~0ULL;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> index 5e55ecb..321bfca 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> @@ -304,7 +304,7 @@ int tu102_vmm_new(struct nvkm_mmu *, bool, u64, u64, void 
> *, u32,
>   FILL(VMM, PT, PTEI, _ptes, MAP, _addr);\
>   PTEI += _ptes; \
>   PTEN -= _ptes; \
> - }; \
> + } \

You are missing one space after the closing curly bracket, to align the
backslash at the end of the line.

Thanks,
Pierre Moreau

>   nvkm_done((PT)->memory);   \
>  } while(0)
> 
> --
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [Nouveau] [PATCH v2] drm/nouveau/mmu: Remove unneeded semicolon

[Pierre Moreau]

Reviewed-by: Pierre Moreau 

On 2019-12-18 — 09:28, zhengbin wrote:
> Fixes coccicheck warning:
> 
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded semicolon
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded semicolon
> 
> Reported-by: Hulk Robot 
> Signed-off-by: zhengbin 
> ---
> v1->v2: add missing one space after the closing curly bracket
>  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> index 41640e0..199f94e 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> @@ -580,7 +580,7 @@ nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct 
> nvkm_vmm_page *page,
>   it.pte[it.lvl]++;
>   }
>   }
> - };
> + }
> 
>   nvkm_vmm_flush();
>   return ~0ULL;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> index 5e55ecb..321bfca 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> @@ -304,7 +304,7 @@ int tu102_vmm_new(struct nvkm_mmu *, bool, u64, u64, void 
> *, u32,
>   FILL(VMM, PT, PTEI, _ptes, MAP, _addr);\
>   PTEI += _ptes; \
>   PTEN -= _ptes; \
> - }; \
> + }  \
>   nvkm_done((PT)->memory);   \
>  } while(0)
> 
> --
> 2.7.4
> 


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

Re: [Nouveau] [PATCH -next] drm/nouveau: fix copy-paste error in nouveau_fence_wait_uevent_handler

[Pierre Moreau]

Friendly ping, Ben.
I see that in `nouveau_fence_done()` there is a check on `chan` not being NULL
prior to passing it to `nouveau_fence_update()`. Would something similar be
needed here?

Pierre

On 2018-11-15 — 12:14, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/gpu/drm/nouveau/nouveau_fence.c: In function 
> 'nouveau_fence_wait_uevent_handler':
> drivers/gpu/drm/nouveau/nouveau_fence.c:156:27: warning:
>  variable 'chan' set but not used [-Wunused-but-set-variable]
> 
> nouveau_fence_update should use rcu protected 'chan'
> rather than 'fence->channel'
> 
> Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and 
> protect with rcu")
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
> b/drivers/gpu/drm/nouveau/nouveau_fence.c
> index d4964f3..91286d0 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> @@ -157,7 +157,7 @@
>  
>   fence = list_entry(fctx->pending.next, typeof(*fence), head);
>   chan = rcu_dereference_protected(fence->channel, 
> lockdep_is_held(>lock));
> - if (nouveau_fence_update(fence->channel, fctx))
> + if (nouveau_fence_update(chan, fctx))
>   ret = NVIF_NOTIFY_DROP;
>   }
>   spin_unlock_irqrestore(>lock, flags);
> 
> 
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/bl: Fix oops on driver unbind

[Pierre Moreau]

Hey Lukas,

> Sorry Pierre, I missed this question and am seeing it only now on
> saving the message away:

No worries, and thank you for the great explanation! I’ll definitely make a
mental note to try unloading Nouveau, whenever writing/testing similar patches.

Thanks,
Pierre


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

Re: [Nouveau] [PATCH v2] bl: fix backlight regression

[Pierre Moreau]

A few words about why this change is needed would be nice, as well as what
changed since the v1 (well, looking back to your original patch, absolutely
everything changed :-D).

On 2018-02-19 — 17:09, Karol Herbst wrote:
> fixes d9c0aadc5aa241df26ce8301d34a8418919fb5ae

The formatting does not follow the kernel guidelines, see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=91ab883eb21325ad80f3473633f794c78ac87f51#n183
Also, you might want to use the commit hash from Linus’ tree, rather than from
Ben’s out-of-tree module.

> 
> Suggested-by: Ben Skeggs 
> Signed-off-by: Karol Herbst 
> ---
>  drm/nouveau/nouveau_backlight.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
> index 380f3402..55172655 100644
> --- a/drm/nouveau/nouveau_backlight.c
> +++ b/drm/nouveau/nouveau_backlight.c
> @@ -134,7 +134,7 @@ nv50_get_intensity(struct backlight_device *bd)
>   struct nouveau_encoder *nv_encoder = bl_get_data(bd);
>   struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>   struct nvif_object *device = >client.device.object;
> - int or = nv_encoder->or;
> + int or = ffs(nv_encoder->dcb->or) - 1;

Since you have that change in a few places, wouldn’t it make sense to have it
in an helper function, that given an nv_encoder object would give you back the
correct or value? The function wouldn’t be doing much, I agree, but it would be
less error-prone to forgetting the -1 or using ffs in some cases.

Pierre

>   u32 div = 1025;
>   u32 val;
>  
> @@ -149,7 +149,7 @@ nv50_set_intensity(struct backlight_device *bd)
>   struct nouveau_encoder *nv_encoder = bl_get_data(bd);
>   struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>   struct nvif_object *device = >client.device.object;
> - int or = nv_encoder->or;
> + int or = ffs(nv_encoder->dcb->or) - 1;
>   u32 div = 1025;
>   u32 val = (bd->props.brightness * div) / 100;
>  
> @@ -170,7 +170,7 @@ nva3_get_intensity(struct backlight_device *bd)
>   struct nouveau_encoder *nv_encoder = bl_get_data(bd);
>   struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>   struct nvif_object *device = >client.device.object;
> - int or = nv_encoder->or;
> + int or = ffs(nv_encoder->dcb->or) - 1;
>   u32 div, val;
>  
>   div  = nvif_rd32(device, NV50_PDISP_SOR_PWM_DIV(or));
> @@ -188,7 +188,7 @@ nva3_set_intensity(struct backlight_device *bd)
>   struct nouveau_encoder *nv_encoder = bl_get_data(bd);
>   struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>   struct nvif_object *device = >client.device.object;
> - int or = nv_encoder->or;
> + int or = ffs(nv_encoder->dcb->or) - 1;
>   u32 div, val;
>  
>   div = nvif_rd32(device, NV50_PDISP_SOR_PWM_DIV(or));
> @@ -228,7 +228,7 @@ nv50_backlight_init(struct drm_connector *connector)
>   return -ENODEV;
>   }
>  
> - if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(nv_encoder->or)))
> + if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) 
> - 1)))
>   return 0;
>  
>   if (drm->client.device.info.chipset <= 0xa0 ||
> -- 
> 2.14.3
> 
> ___
> 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

Re: [Nouveau] [PATCH] drm/nouveau/bl: Fix oops on driver unbind

[Pierre Moreau]

My bad; I did test suspend/resume, but not unbinding. Shouldn’t that
happen on shutdown as well, as the driver gets unloaded? I don’t remember
seeing that issue there though.

On 2018-02-17 — 13:40, Lukas Wunner wrote:
> Unbinding nouveau on a dual GPU MacBook Pro oopses because we iterate
> over the bl_connectors list in nouveau_backlight_exit() but skipped
> initializing it in nouveau_backlight_init().  Stacktrace for posterity:
> 
> BUG: unable to handle kernel NULL pointer dereference at 0010
> IP: nouveau_backlight_exit+0x2b/0x70 [nouveau]
> nouveau_display_destroy+0x29/0x80 [nouveau]
> nouveau_drm_unload+0x65/0xe0 [nouveau]
> drm_dev_unregister+0x3c/0xe0 [drm]
> drm_put_dev+0x2e/0x60 [drm]
> nouveau_drm_device_remove+0x47/0x70 [nouveau]
> pci_device_remove+0x36/0xb0
> device_release_driver_internal+0x157/0x220
> driver_detach+0x39/0x70
> bus_remove_driver+0x51/0xd0
> pci_unregister_driver+0x2a/0xa0
> nouveau_drm_exit+0x15/0xfb0 [nouveau]
> SyS_delete_module+0x18c/0x290
> system_call_fast_compare_end+0xc/0x6f
> 
> Fixes: b53ac1ee12a3 ("drm/nouveau/bl: Do not register interface if Apple GMUX 
> detected")
> Cc: sta...@vger.kernel.org # v4.10+
> Cc: Pierre Moreau <pierre.mor...@free.fr>
> Signed-off-by: Lukas Wunner <lu...@wunner.de>
> ---
> I reviewed the patch causing the oops but unfortunately missed this, sorry!
> 
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 380f340204e8..f56f60f695e1 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -268,13 +268,13 @@ nouveau_backlight_init(struct drm_device *dev)
>   struct nvif_device *device = >client.device;
>   struct drm_connector *connector;
>  
> + INIT_LIST_HEAD(>bl_connectors);
> +

We could instead have an early return in the exit function if
`apple_gmux_present()` or `drm->bl_connectors` is null, but your current fix
seems better.

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

Thank you for the fix!
Pierre

>   if (apple_gmux_present()) {
>   NV_INFO(drm, "Apple GMUX detected: not registering Nouveau 
> backlight interface\n");
>   return 0;
>   }
>  
> - 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)
> -- 
> 2.15.1
> 


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

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Pierre Moreau]

On 2018-02-14 — 09:36, Ilia Mirkin wrote:
> On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin  wrote:
> > On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos  wrote:
> >>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
> >>
> >> NV5 in another PC (secondary card in x86-64) made the systrem crash on
> >> boot, in nvkm_therm_clkgate_fini.
> >
> > Mind booting with nouveau.debug=trace? That should hopefully tell us
> > more exactly which thing is dying. If you have a cross-compile/distcc
> > setup handy, a bisect may be even more useful.
> 
> Erm, sorry, nevermind. You even said it -- nvkm_therm_clkgate_fini is
> somehow mis-hooked up for NV5 now. A bisect result would still make
> the culprit a lot more obvious.

CC’ing Lyude Paul as she hooked up the clockgating support.

Looking at the code, only NV40+ do have a therm engine. Therefore, shouldn’t
nvkm_therm_clkgate_enable(), nvkm_therm_clkgate_fini() and
nvkm_therm_clkgate_oneinit() all check for therm being not NULL, on top of
their check for the clkgate_* hooks being there? Or instead, maybe have the
check in nvkm_device_init() nvkm_device_init()?

Pierre


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

Re: [Nouveau] [PATCH] ramgf100: Fix small typo.

[Pierre Moreau]

Indeed, it looks like the devel-clk branch does not have that typo.

On 2017-12-29 — 13:39, Rosen Penev wrote:
> This is fixed in a different nouveau branch. from Ben Skeggs last I remember.
> 
> On Fri, Dec 29, 2017 at 1:37 PM, Pierre Moreau <pierre.mor...@free.fr> wrote:
> > The typo is still present in master.
> > Not sure whether it will help you Ben, regarding Fermi reclocking, but it
> > shouldn’t harm in reducing possible errors. :-)
> >
> > Regards,
> > Pierre
> >
> > On 2017-07-27 — 18:20, Rosen Penev wrote:
> >> Signed-off by: Rosen Penev <ros...@gmail.com>
> >> ---
> >>  drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c 
> >> b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> >> index 4a9bd4f1..feb8820c 100644
> >> --- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> >> +++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> >> @@ -717,7 +717,7 @@ gf100_ram_new_(const struct nvkm_ram_func *func,
> >>   ram->fuc.r_0x10f9b4 = ramfuc_reg(0x10f9b4);
> >>   ram->fuc.r_0x10fb04 = ramfuc_reg(0x10fb04);
> >>   ram->fuc.r_0x10fb08 = ramfuc_reg(0x10fb08);
> >> - ram->fuc.r_0x137310 = ramfuc_reg(0x137300);
> >> + ram->fuc.r_0x137300 = ramfuc_reg(0x137300);
> >>   ram->fuc.r_0x137310 = ramfuc_reg(0x137310);
> >>   ram->fuc.r_0x137360 = ramfuc_reg(0x137360);
> >>   ram->fuc.r_0x1373ec = ramfuc_reg(0x1373ec);
> >> --
> >> 2.13.3
> >>
> >> ___
> >> Nouveau mailing list
> >> Nouveau@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/nouveau
> ___
> 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

Re: [Nouveau] [PATCH v2] nv50/ir: Initialize all members of GCRA (trivial)

[Pierre Moreau]

On 2017-12-30 — 15:21, Tobias Klausmann wrote:
> v2: use initialization list (Pierre)
> 
> Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
> Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> index 361918a161..a70a54f6b8 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> @@ -1144,7 +1144,9 @@ GCRA::RIG_Node::addRegPreference(RIG_Node *node)
>  GCRA::GCRA(Function *fn, SpillCodeInserter& spill) :
> func(fn),
> regs(fn->getProgram()->getTarget()),
> -   spill(spill)
> +   spill(spill),
> +   nodeCount(0),
> +   nodes(NULL)

The order in the member initialisation list should be the same as the order in
which the attributes are declared within the class, so you should have:

   nodes(NULL)
   nodeCount(0),
   func(fn),
   regs(fn->getProgram()->getTarget()),
   spill(spill)

>  {
> prog = func->getProgram();
>  
> -- 
> 2.15.1
> 


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

Re: [Nouveau] [PATCH] drm/nouveau/hwmon: Uninitialized variables in sysfs

[Pierre Moreau]

Ping: this can still be an issue today as kstrtol() & co haven’t changed their
possible return value since the patch was written.

On 2017-07-22 — 14:13, Pierre Moreau wrote:
> Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>
> 
> On 2017-07-17 — 11:17, Dan Carpenter wrote:
> > kstrtol() and friends can return -EINVAL or -ERANGE.  We have to test
> > for both, otherwise the value is possibly uninitialized.  Also in some
> > of these files we accidentally return "count" on error instead of a
> > negative error code.
> > 
> > Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> > b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > index 7c965648df80..5e75af91c446 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > @@ -68,9 +68,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device 
> > *d,
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > struct nvkm_therm *therm = nvxx_therm(>client.device);
> > long value;
> > +   int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return count;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST,
> > value / 1000);
> > @@ -101,9 +103,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct 
> > device *d,
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > struct nvkm_therm *therm = nvxx_therm(>client.device);
> > long value;
> > +   int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return count;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST_HYST,
> > value / 1000);
> > @@ -156,8 +160,9 @@ nouveau_hwmon_set_pwm1_min(struct device *d, struct 
> > device_attribute *a,
> > long value;
> > int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return -EINVAL;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MIN_DUTY, value);
> > if (ret < 0)
> > @@ -179,8 +184,9 @@ nouveau_hwmon_set_pwm1_max(struct device *d, struct 
> > device_attribute *a,
> > long value;
> > int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return -EINVAL;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MAX_DUTY, value);
> > if (ret < 0)
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau



> ___
> 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

Re: [Nouveau] drm/nouveau: Remove no longer needed local ACPI_VIDEO_NOTIFY_PROBE define

[Pierre Moreau]

Ping

On 2017-07-22 — 13:54, Pierre Moreau wrote:
> Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>
> 
> On 2017-06-21 — 15:19, Hans de Goede wrote:
> > Hi,
> > 
> > On 26-05-17 09:35, Hans De Goede wrote:
> > > The local #define of ACPI_VIDEO_NOTIFY_PROBE was only added temporarily
> > > to avoid a dependency between the acpi and nouveau trees while merging.
> > > 
> > > This is now properly defined in acpi/video.h and the local #define can
> > > be dropped.
> > > 
> > > Signed-off-by: Hans de Goede <hdego...@redhat.com>
> > 
> > ping, what is the status of this patch ?
> > 
> > Regards,
> > 
> > Hans
> > 
> > 
> > > ---
> > >   drivers/gpu/drm/nouveau/nouveau_display.c | 9 -
> > >   1 file changed, 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > index 549763f5e17d..70de2079b2cc 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > @@ -369,15 +369,6 @@ nouveau_display_hpd_work(struct work_struct *work)
> > >   #ifdef CONFIG_ACPI
> > > -/*
> > > - * Hans de Goede: This define belongs in acpi/video.h, I've submitted a 
> > > patch
> > > - * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
> > > - * This should be dropped once that is merged.
> > > - */
> > > -#ifndef ACPI_VIDEO_NOTIFY_PROBE
> > > -#define ACPI_VIDEO_NOTIFY_PROBE  0x81
> > > -#endif
> > > -
> > >   static int
> > >   nouveau_display_acpi_ntfy(struct notifier_block *nb, unsigned long val,
> > > void *data)
> > > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel



> ___
> 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

Re: [Nouveau] [PATCH] ramgf100: Fix small typo.

[Pierre Moreau]

The typo is still present in master.
Not sure whether it will help you Ben, regarding Fermi reclocking, but it
shouldn’t harm in reducing possible errors. :-)

Regards,
Pierre

On 2017-07-27 — 18:20, Rosen Penev wrote:
> Signed-off by: Rosen Penev 
> ---
>  drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c 
> b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> index 4a9bd4f1..feb8820c 100644
> --- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> +++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> @@ -717,7 +717,7 @@ gf100_ram_new_(const struct nvkm_ram_func *func,
>   ram->fuc.r_0x10f9b4 = ramfuc_reg(0x10f9b4);
>   ram->fuc.r_0x10fb04 = ramfuc_reg(0x10fb04);
>   ram->fuc.r_0x10fb08 = ramfuc_reg(0x10fb08);
> - ram->fuc.r_0x137310 = ramfuc_reg(0x137300);
> + ram->fuc.r_0x137300 = ramfuc_reg(0x137300);
>   ram->fuc.r_0x137310 = ramfuc_reg(0x137310);
>   ram->fuc.r_0x137360 = ramfuc_reg(0x137360);
>   ram->fuc.r_0x1373ec = ramfuc_reg(0x1373ec);
> -- 
> 2.13.3
> 
> ___
> 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

Re: [Nouveau] [PATCH] nv50/ir: Initialize all members of GCRA (trivial)

[Pierre Moreau]

It looks like this patch was never merged.

You could initialise “nodeCount” and “nodes” directly in the member
initialisation list. With that changed, this patch is

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-08-12 — 01:45, Tobias Klausmann wrote:
> Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> index 9d70ec3c9c..e4f38c8e46 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> @@ -1146,6 +1146,9 @@ GCRA::GCRA(Function *fn, SpillCodeInserter& spill) :
> regs(fn->getProgram()->getTarget()),
> spill(spill)
>  {
> +   nodeCount = 0;
> +   nodes = NULL;
> +
> prog = func->getProgram();
>  
> // initialize relative degrees array - i takes away from j
> -- 
> 2.14.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

Re: [Nouveau] [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

[Pierre Moreau]

Hey Ard,

It seems that Ben already committed a similar patch to his tree (see [0]). I do
not know whether he is planning to have it part of a pull request of fixes for
4.15.

Best regards,
Pierre

[0]: 
https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa

On 2017-12-18 — 09:27, Ard Biesheuvel wrote:
> On 8 December 2017 at 19:30, Ard Biesheuvel  wrote:
> > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> > into nv04_instobj") introduced some new calls to the refcount api to
> > the nv50 mapping code. In one particular instance, it does the
> > following:
> >
> > if (!refcount_inc_not_zero(>maps)) {
> > ...
> > refcount_inc(>maps);
> > }
> >
> > i.e., it calls refcount_inc() to increment the refcount when it is known
> > to be zero, which is explicitly forbidden by the API. Instead, use
> > refcount_set() to set it to 1.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >
> > Apologies if this was already found and fixed. I don't usually follow
> > the DRM or nouveau mailing lists.
> >
> >  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> > index 1ba7289684aa..db48a1daca0c 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> > @@ -249,7 +249,7 @@ nv50_instobj_acquire(struct nvkm_memory *memory)
> > iobj->base.memory.ptrs = _instobj_fast;
> > else
> > iobj->base.memory.ptrs = _instobj_slow;
> > -   refcount_inc(>maps);
> > +   refcount_set(>maps, 1);
> > }
> >
> > mutex_unlock(>subdev.mutex);
> > --
> > 2.11.0
> >
> 
> Ping?
> ___
> 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

Re: [Nouveau] [PATCH v3] nouveau/compiler: Allow to omit line numbers when printing instructions

[Pierre Moreau]

(Comment is a bit further down)

On 2017-11-24 — 16:55, Tobias Klausmann wrote:
> This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff!
> 
> V2:
>  - Use environmental variable (Karol Herbst)
> V3:
>  - Use the already populated nv50_ir_prog_info to forward information to the
>print pass (Pierre Moreau)
> 
> Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h  |  1 +
>  src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 12 +---
>  src/gallium/drivers/nouveau/nouveau_compiler.c|  2 ++
>  src/gallium/drivers/nouveau/nv50/nv50_program.c   |  2 ++
>  src/gallium/drivers/nouveau/nvc0/nvc0_program.c   |  2 ++
>  5 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> index ffd53c9cd3..604a22ba89 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> @@ -82,6 +82,7 @@ struct nv50_ir_prog_info
>  
> uint8_t optLevel; /* optimization level (0 to 3) */
> uint8_t dbgFlags;
> +   bool omitLineNum;

You could maybe add a comment that it only affects when printing the program
(in debug mode), but the patch is nonetheless:

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

>  
> struct {
>int16_t maxGPR; /* may be -1 if none used */
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> index 9145801b62..eb7e9057b5 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> @@ -691,7 +691,7 @@ void Instruction::print() const
>  class PrintPass : public Pass
>  {
>  public:
> -   PrintPass() : serial(0) { }
> +   PrintPass(bool omitLineNum = false) : serial(0), omit_serial(omitLineNum) 
> { }
>  
> virtual bool visit(Function *);
> virtual bool visit(BasicBlock *);
> @@ -699,6 +699,7 @@ public:
>  
>  private:
> int serial;
> +   bool omit_serial;
>  };
>  
>  bool
> @@ -762,7 +763,12 @@ PrintPass::visit(BasicBlock *bb)
>  bool
>  PrintPass::visit(Instruction *insn)
>  {
> -   INFO("%3i: ", serial++);
> +   if (omit_serial) {
> +  INFO(" ");
> +  serial++;
> +   }
> +   else
> +  INFO("%3i: ", serial++);
> insn->print();
> return true;
>  }
> @@ -777,7 +783,7 @@ Function::print()
>  void
>  Program::print()
>  {
> -   PrintPass pass;
> +   PrintPass pass(driver->omitLineNum);
> init_colours();
> pass.run(this, true, false);
>  }
> diff --git a/src/gallium/drivers/nouveau/nouveau_compiler.c 
> b/src/gallium/drivers/nouveau/nouveau_compiler.c
> index 3151a6f420..1214cf3565 100644
> --- a/src/gallium/drivers/nouveau/nouveau_compiler.c
> +++ b/src/gallium/drivers/nouveau/nouveau_compiler.c
> @@ -122,6 +122,8 @@ nouveau_codegen(int chipset, int type, struct tgsi_token 
> tokens[],
>  
> info.optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
> info.dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
> +   info.omitLineNum =
> + debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
> false;
>  
> ret = nv50_ir_generate_code();
> if (ret) {
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_program.c
> index 6e943a3d94..fb5c9ed777 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_program.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c
> @@ -367,6 +367,8 @@ nv50_program_translate(struct nv50_program *prog, 
> uint16_t chipset,
>  #ifdef DEBUG
> info->optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
> info->dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
> +   info->omitLineNum =
> + debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
> false;
>  #else
> info->optLevel = 3;
>  #endif
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
> index c95a96c717..8dced66437 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
> @@ -575,6 +575,8 @@ nvc0_program_translate(struct nvc0_program *prog, 
> uint16_t chipset,
> info->target = debug_get_num_option("NV50_PROG_CHIPSET", chipset);
> info->optLevel

Re: [Nouveau] [PATCH v2] nouveau/compiler: Allow to omit line numbers when printing instructions

[Pierre Moreau]

The “Program” class keeps a pointer to the “nv50_ir_prog_info” structure, so 
you could
just use that in the “Program::print()” function, rather than passing the flag 
as
an argument to “print”.

Pierre

On 2017-11-17 — 17:21, Tobias Klausmann wrote:
> This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff!
> 
> V2:
>  - Use environmental variable (Karol Herbst)
> 
> Signed-off-by: Tobias Klausmann 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp|  6 +++---
>  src/gallium/drivers/nouveau/codegen/nv50_ir.h  |  2 +-
>  src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h   |  1 +
>  src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp  | 14 ++
>  src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp |  2 +-
>  src/gallium/drivers/nouveau/nouveau_compiler.c |  3 +++
>  src/gallium/drivers/nouveau/nv50/nv50_program.c|  2 ++
>  src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  2 ++
>  8 files changed, 23 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> index e9363101bf..4bf6c73837 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> @@ -1249,7 +1249,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
> if (ret < 0)
>goto out;
> if (prog->dbgFlags & NV50_IR_DEBUG_VERBOSE)
> -  prog->print();
> +  prog->print(info->omitLineNum);
>  
> targ->parseDriverInfo(info);
> prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
> @@ -1257,13 +1257,13 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
> prog->convertToSSA();
>  
> if (prog->dbgFlags & NV50_IR_DEBUG_VERBOSE)
> -  prog->print();
> +  prog->print(info->omitLineNum);
>  
> prog->optimizeSSA(info->optLevel);
> prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
>  
> if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)
> -  prog->print();
> +  prog->print(info->omitLineNum);
>  
> if (!prog->registerAllocation()) {
>ret = -4;
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> index f2ce16d882..a3c7fd2f94 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> @@ -1249,7 +1249,7 @@ public:
> Program(Type type, Target *targ);
> ~Program();
>  
> -   void print();
> +   void print(bool omitLineNum);
>  
> Type getType() const { return progType; }
>  
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> index ffd53c9cd3..604a22ba89 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> @@ -82,6 +82,7 @@ struct nv50_ir_prog_info
>  
> uint8_t optLevel; /* optimization level (0 to 3) */
> uint8_t dbgFlags;
> +   bool omitLineNum;
>  
> struct {
>int16_t maxGPR; /* may be -1 if none used */
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> index 9145801b62..d6fe928af4 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> @@ -691,7 +691,7 @@ void Instruction::print() const
>  class PrintPass : public Pass
>  {
>  public:
> -   PrintPass() : serial(0) { }
> +   PrintPass(bool omitLineNum = false) : serial(0), omit_serial(omitLineNum) 
> { }
>  
> virtual bool visit(Function *);
> virtual bool visit(BasicBlock *);
> @@ -699,6 +699,7 @@ public:
>  
>  private:
> int serial;
> +   bool omit_serial;
>  };
>  
>  bool
> @@ -762,7 +763,12 @@ PrintPass::visit(BasicBlock *bb)
>  bool
>  PrintPass::visit(Instruction *insn)
>  {
> -   INFO("%3i: ", serial++);
> +   if (omit_serial) {
> +  INFO(" ");
> +  serial++;
> +   }
> +   else
> +  INFO("%3i: ", serial++);
> insn->print();
> return true;
>  }
> @@ -775,9 +781,9 @@ Function::print()
>  }
>  
>  void
> -Program::print()
> +Program::print(bool omitLineNum)
>  {
> -   PrintPass pass;
> +   PrintPass pass(omitLineNum);
> init_colours();
> pass.run(this, true, false);
>  }
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> index 298e7c6ef9..96ad70d28a 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> @@ -371,7 +371,7 @@ Program::emitBinary(struct nv50_ir_prog_info *info)
> emit->prepareEmission(this);
>  
> if (dbgFlags & NV50_IR_DEBUG_BASIC)
> -  this->print();
> +  this->print(info->omitLineNum);
>  
> if (!binSize) {
>code = NULL;
> diff 

Re: [Nouveau] [PATCH] nouveau/codegen: dump tgsi floats as hex values

[Pierre Moreau]

This looks like the saner approach, compared to changing tgsi_dump.c to display
more fractional digits. Maybe there could be a second option to display as both
float and hex?

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-11-14 — 15:11, Tobias Klausmann wrote:
> Printing without this could lead to the following output, while the values are
> not exactly zero:
> IMM[5] FLT32 {0., 0., 0., 0.}
> IMM[6] FLT32 {0., 0., 0., 0.}
> IMM[7] FLT32 {0., 0., 0., 0.}
> 
> when printing the values as hex, we can now see the differences:
> IMM[5] FLT32 {0x0019, 0x000f, 0x0005, 0x001e}
> IMM[6] FLT32 {0x001e, 0x0005, 0x000a, 0x0014}
> IMM[7] FLT32 {0x0014, 0x000a, 0x000f, 0x0019}
> 
> Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> index 34351dab51..898031811d 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> @@ -1095,7 +1095,7 @@ Source::Source(struct nv50_ir_prog_info *prog) : 
> info(prog)
> tokens = (const struct tgsi_token *)info->bin.source;
>  
> if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)
> -  tgsi_dump(tokens, 0);
> +  tgsi_dump(tokens, TGSI_DUMP_FLOAT_AS_HEX);
>  }
>  
>  Source::~Source()
> -- 
> 2.15.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

Re: [Nouveau] [RFC PATCH 17/29] clk: thermal throttling

[Pierre Moreau]

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-09-15 — 17:11, Karol Herbst wrote:
> v2: make message about relaxed throttling an info
> rework reporting about current clk state
> 
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h |  1 +
>  drm/nouveau/nvkm/subdev/clk/base.c| 44 
> +--
>  2 files changed, 33 insertions(+), 12 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index f5ff1fd9..b79bf657 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -106,6 +106,7 @@ struct nvkm_clk {
>   u8  temp;
>   u8  max_temp;
>   u8  relax_temp;
> + bool throttled;
>  
>   bool allow_reclock;
>  #define NVKM_CLK_BOOST_NONE 0x0
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index 54e14936..72ca5e0c 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -279,7 +279,7 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstateid)
>   struct nvkm_fb *fb = subdev->device->fb;
>   struct nvkm_pci *pci = subdev->device->pci;
>   struct nvkm_pstate *pstate;
> - int ret;
> + int ret, cstate;
>  
>   if (pstateid == NVKM_CLK_PSTATE_DEFAULT)
>   return 0;
> @@ -308,7 +308,12 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstateid)
>   ram->func->tidy(ram);
>   }
>  
> - return nvkm_cstate_prog(clk, pstate, clk->exp_cstateid);
> + if (clk->throttled)
> + cstate = list_first_entry(>list, struct nvkm_cstate, 
> head)->id;
> + else
> + cstate = clk->exp_cstateid;
> +
> + return nvkm_cstate_prog(clk, pstate, cstate);
>  }
>  
>  static void
> @@ -322,22 +327,20 @@ nvkm_clk_update_work(struct work_struct *work)
>   return;
>   clk->pwrsrc = power_supply_is_system_supplied();
>  
> - if (clk->pstate)
> - pstate = clk->pstate->pstate;
> - else
> - pstate = NVKM_CLK_PSTATE_DEFAULT;
> - nvkm_trace(subdev, "P %d PWR %d U(AC) %d U(DC) %d A %d C %d T %d°C\n",
> -pstate, clk->pwrsrc, clk->ustate_ac, clk->ustate_dc,
> -clk->astate, clk->exp_cstateid, clk->temp);
> -
>   pstate = clk->pwrsrc ? clk->ustate_ac : clk->ustate_dc;
>   if (clk->state_nr && pstate != -1) {
> - pstate = (pstate < 0) ? clk->astate : pstate;
> + if (clk->throttled)
> + pstate = list_first_entry(>states, struct 
> nvkm_pstate, head)->pstate;
> + else
> + pstate = (pstate < 0) ? clk->astate : pstate;
>   } else {
>   pstate = NVKM_CLK_PSTATE_DEFAULT;
>   }
>  
> - nvkm_trace(subdev, "-> %d\n", pstate);
> + nvkm_trace(subdev, "PWR %d U(AC) %d U(DC) %d A %d C %d T %d°C\n",
> +clk->pwrsrc, clk->ustate_ac, clk->ustate_dc,
> +clk->astate, clk->exp_cstateid, clk->temp);
> +
>   if (!clk->pstate || pstate != clk->pstate->pstate) {
>   int ret = nvkm_pstate_prog(clk, pstate);
>   if (ret) {
> @@ -564,9 +567,25 @@ nvkm_clk_astate(struct nvkm_clk *clk, int req, int rel, 
> bool wait)
>  int
>  nvkm_clk_tstate(struct nvkm_clk *clk, u8 temp)
>  {
> + struct nvkm_subdev *subdev = >subdev;
>   if (clk->temp == temp)
>   return 0;
>   clk->temp = temp;
> + if (clk->max_temp && clk->relax_temp) {
> + if (!clk->throttled && temp > clk->max_temp) {
> + nvkm_warn(subdev,
> +   "temperature (%d C) hit the 'downclock' "
> +   "threshold\n",
> +   temp);
> + clk->throttled = true;
> + } else if (clk->throttled && temp < clk->relax_temp) {
> + nvkm_info(subdev,
> +   "temperature (%d C) went below the "
> +   "'relax' threshold\n",
> +   temp);
> + clk->throttled = false;
> + }
> + }
>   return nvkm_clk_update(clk, false);
>  }
>  
> @@ -727,6 +746,7 @@ nvkm_clk_ctor(const struct nvkm_clk_func *func, struct 
> nvkm_device *device,
>   clk->ustate_dc = -1;
>   clk->exp_cstateid = NVKM_CLK_CSTATE_DEFAULT;
>   clk->temp = 90; /* reasonable default value */
> + clk->throttled = false;
>  
>   clk->allow_reclock = allow_reclock;
>  
> -- 
> 2.14.1
> 
> ___
> 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

Re: [Nouveau] [RFC PATCH 15/29] bios: add thermal policies table

[Pierre Moreau]

Looking good. It would be nice to have some defines/enums for the different
modes. Some comments about t0, t1 and t2 would be nice. I saw you are using t0
in patch 16, but I have no idea why use t0 rather than t1 or t2.

Otherwise,
Acked-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-09-15 — 17:11, Karol Herbst wrote:
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> ---
>  .../include/nvkm/subdev/bios/thermal_policies.h| 27 
>  drm/nouveau/nvkm/subdev/bios/Kbuild|  1 +
>  drm/nouveau/nvkm/subdev/bios/thermal_policies.c| 81 
> ++
>  3 files changed, 109 insertions(+)
>  create mode 100644 drm/nouveau/include/nvkm/subdev/bios/thermal_policies.h
>  create mode 100644 drm/nouveau/nvkm/subdev/bios/thermal_policies.c
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/bios/thermal_policies.h 
> b/drm/nouveau/include/nvkm/subdev/bios/thermal_policies.h
> new file mode 100644
> index ..c9215fdd
> --- /dev/null
> +++ b/drm/nouveau/include/nvkm/subdev/bios/thermal_policies.h
> @@ -0,0 +1,27 @@
> +#ifndef __NVBIOS_THERMAL_POLICIES_H__
> +#define __NVBIOS_THERMAL_POLICIES_H__
> +
> +struct nvbios_thermal_policies_header {
> + u32 offset;
> +
> + u8 version;
> + u8 hlen;
> + u8 ecount;
> + u8 elen;
> +};
> +struct nvbios_thermal_policies_entry {
> + u8  mode;
> + u16 t0;
> + u16 t1;
> + u16 t2;
> + s16 down_offset;
> + s16 up_offset;
> +};
> +
> +int nvbios_thermal_policies_parse(struct nvkm_bios *,
> +   struct nvbios_thermal_policies_header *);
> +int nvbios_thermal_policies_entry(struct nvkm_bios *,
> +   struct nvbios_thermal_policies_header *,
> +   u8 idx,
> +   struct nvbios_thermal_policies_entry *);
> +#endif
> diff --git a/drm/nouveau/nvkm/subdev/bios/Kbuild 
> b/drm/nouveau/nvkm/subdev/bios/Kbuild
> index 6b4f1e06..38f31dd0 100644
> --- a/drm/nouveau/nvkm/subdev/bios/Kbuild
> +++ b/drm/nouveau/nvkm/subdev/bios/Kbuild
> @@ -30,6 +30,7 @@ nvkm-y += nvkm/subdev/bios/shadowramin.o
>  nvkm-y += nvkm/subdev/bios/shadowrom.o
>  nvkm-y += nvkm/subdev/bios/timing.o
>  nvkm-y += nvkm/subdev/bios/therm.o
> +nvkm-y += nvkm/subdev/bios/thermal_policies.o
>  nvkm-y += nvkm/subdev/bios/vmap.o
>  nvkm-y += nvkm/subdev/bios/volt.o
>  nvkm-y += nvkm/subdev/bios/vpstate.o
> diff --git a/drm/nouveau/nvkm/subdev/bios/thermal_policies.c 
> b/drm/nouveau/nvkm/subdev/bios/thermal_policies.c
> new file mode 100644
> index ..5105194e
> --- /dev/null
> +++ b/drm/nouveau/nvkm/subdev/bios/thermal_policies.c
> @@ -0,0 +1,81 @@
> +/*
> + * Copyright 2017 Karol Herbst
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: Karol Herbst
> + */
> +#include 
> +#include 
> +#include 
> +
> +static u32
> +nvbios_thermal_policies_offset(struct nvkm_bios *b)
> +{
> + struct bit_entry bit_P;
> +
> + if (!bit_entry(b, 'P', _P)) {
> + if (bit_P.version == 2 && bit_P.length >= 0x50)
> + return nvbios_rd32(b, bit_P.offset + 0x50);
> + }
> +
> + return 0;
> +}
> +
> +int
> +nvbios_thermal_policies_parse(struct nvkm_bios *b, struct 
> nvbios_thermal_policies_header *h)
> +{
> + if (!h)
> + return -EINVAL;
> +
> + h->offset = nvbios_thermal_policies_offset(b);
> + if (!h->offset)
> + return -ENODEV;
> +
> + h->version = nvbios_rd08(b, h->offse

Re: [Nouveau] [RFC PATCH 16/29] clk: parse thermal policies for throttling thresholds

[Pierre Moreau]

On 2017-09-15 — 17:11, Karol Herbst wrote:
> v2: use min_t
> 
> Signed-off-by: Karol Herbst 
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h |  2 ++
>  drm/nouveau/nvkm/subdev/clk/base.c| 42 
> +++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index f35518c3..f5ff1fd9 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -104,6 +104,8 @@ struct nvkm_clk {
>   struct nvkm_cstate *cstate;
>   int exp_cstateid;
>   u8  temp;
> + u8  max_temp;
> + u8  relax_temp;

I guess those should be int, similar to the changes you made in patch 1.

>  
>   bool allow_reclock;
>  #define NVKM_CLK_BOOST_NONE 0x0
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index 54188d2b..54e14936 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -659,6 +660,44 @@ nvkm_clk = {
>   .fini = nvkm_clk_fini,
>  };
>  
> +static void
> +nvkm_clk_parse_max_temp(struct nvkm_clk *clk)
> +{
> + struct nvkm_subdev *subdev = >subdev;
> + struct nvkm_bios *bios = subdev->device->bios;
> + struct nvbios_thermal_policies_header header;
> + struct nvbios_thermal_policies_entry entry;
> + u8 i;
> + s16 mt = 0xff;
> + s16 rt = 0xff;

Why 0xff? I mean, sure, there is a high possibility that the GPU won’t like
temperatures above 255℃, but still.

> +
> + if (nvbios_thermal_policies_parse(bios, ))
> + return;
> +
> + if (!header.ecount)
> + return;
> +
> + for (i = 0; i < header.ecount; i++) {
> + if (nvbios_thermal_policies_entry(bios, , i, ))
> + return;
> +
> + if (entry.mode != 1)
> + continue;
> +
> + mt = min_t(s16, mt, (entry.t0 + entry.down_offset) / 32);
> + rt = min_t(s16, rt, (entry.t0 + entry.up_offset) / 32);
> + }
> +
> + if (mt == 0xff || rt == 0xff)
> + return;
> +
> + clk->max_temp = mt;
> + clk->relax_temp = rt;
> +
> + nvkm_debug(subdev, "setting up sw throttling thresholds (%u/%u°C)\n",
> +clk->max_temp, clk->relax_temp);
> +}
> +
>  int
>  nvkm_clk_ctor(const struct nvkm_clk_func *func, struct nvkm_device *device,
> int index, bool allow_reclock, struct nvkm_clk *clk)
> @@ -733,6 +772,9 @@ nvkm_clk_ctor(const struct nvkm_clk_func *func, struct 
> nvkm_device *device,
>  
>   clk->boost_mode = nvkm_longopt(device->cfgopt, "NvBoost",
>  NVKM_CLK_BOOST_NONE);
> +
> + nvkm_clk_parse_max_temp(clk);
> +
>   return 0;
>  }
>  
> -- 
> 2.14.1
> 
> ___
> 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

Re: [Nouveau] [RFC PATCH 14/29] therm: Trigger reclock in temperature daemon

[Pierre Moreau]

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-09-15 — 17:11, Karol Herbst wrote:
> Depending on the temperature, cstates might become unreachable or the maped
> voltage of a cstate changes. We want to adjust to that.
> 
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> Reviewed-by: Martin Peres <martin.pe...@free.fr>
> ---
>  drm/nouveau/nvkm/subdev/therm/base.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drm/nouveau/nvkm/subdev/therm/base.c 
> b/drm/nouveau/nvkm/subdev/therm/base.c
> index 59f01fec..c90b9cfc 100644
> --- a/drm/nouveau/nvkm/subdev/therm/base.c
> +++ b/drm/nouveau/nvkm/subdev/therm/base.c
> @@ -23,6 +23,8 @@
>   */
>  #include "priv.h"
>  
> +#include 
> +
>  int
>  nvkm_therm_temp_get(struct nvkm_therm *therm, int *val)
>  {
> @@ -168,9 +170,15 @@ nvkm_therm_alarm(struct nvkm_alarm *alarm)
>   int temp;
>   struct nvkm_therm *therm =
>  container_of(alarm, struct nvkm_therm, alarm);
> + struct nvkm_clk *clk = therm->subdev.device->clk;
> +
>   if (nvkm_therm_temp_get(therm, ) >= 0)
>   therm->last_temp = temp;
> +
>   nvkm_therm_update(therm, therm->last_temp, -1);
> +
> + if (clk)
> + nvkm_clk_tstate(clk, therm->last_temp);
>  }
>  
>  int
> -- 
> 2.14.1
> 
> ___
> 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

Re: [Nouveau] [RFC PATCH 09/29] clk: Set clocks to pre suspend state after suspend

[Pierre Moreau]

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-09-15 — 17:11, Karol Herbst wrote:
> The idea is to clear out the saved state, because after a resume we can't
> know what the GPU is clocked to. The reclock is triggered by the call to
> nvkm_clk_update later in nvkm_clk_init.
> 
> v2: convert to C style comments
> 
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> Reviewed-by: Martin Peres <martin.pe...@free.fr>
> ---
>  drm/nouveau/nvkm/subdev/clk/base.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index 1d71bf09..54188d2b 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -625,11 +625,10 @@ nvkm_clk_init(struct nvkm_subdev *subdev)
>   if (clk->func->init)
>   return clk->func->init(clk);
>  
> - clk->astate = NVKM_CLK_PSTATE_DEFAULT;
> + /* after a resume we have no idea what clocks are set, reset the state
> +  */
>   clk->pstate = NULL;
> - clk->exp_cstateid = NVKM_CLK_CSTATE_DEFAULT;
>   clk->cstate = NULL;
> - clk->temp = 90; /* reasonable default value */
>   nvkm_clk_update(clk, true);
>   return 0;
>  }
> @@ -683,8 +682,13 @@ nvkm_clk_ctor(const struct nvkm_clk_func *func, struct 
> nvkm_device *device,
>   clk->func = func;
>   INIT_LIST_HEAD(>states);
>   clk->domains = func->domains;
> +
> + clk->astate = NVKM_CLK_PSTATE_DEFAULT;
>   clk->ustate_ac = -1;
>   clk->ustate_dc = -1;
> + clk->exp_cstateid = NVKM_CLK_CSTATE_DEFAULT;
> + clk->temp = 90; /* reasonable default value */
> +
>   clk->allow_reclock = allow_reclock;
>  
>   INIT_WORK(>work, nvkm_clk_update_work);
> -- 
> 2.14.1
> 
> ___
> 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

Re: [Nouveau] [RFC PATCH 08/29] clk: We should pass the pstate id around not the index in the list

[Pierre Moreau]

On 2017-09-15 — 17:11, Karol Herbst wrote:
> This makes the code easier, because we can compare the id with
> pstate->pstate and saves us from the trouble of iterating over the pstates
> to match the index.

I don’t remember whether I have already done  this comment before, but I am not
sure where your iterating over the pstates savings are, as in this patch at
least, you iterate as much as you did before.

A few more comments below

> v2: reword commit message
> 
> Signed-off-by: Karol Herbst 
> Reviewed-by: Martin Peres 
> ---
>  drm/nouveau/nouveau_debugfs.c  |  6 +--
>  drm/nouveau/nvkm/subdev/clk/base.c | 78 
> +++---
>  2 files changed, 41 insertions(+), 43 deletions(-)
> 
> diff --git a/drm/nouveau/nouveau_debugfs.c b/drm/nouveau/nouveau_debugfs.c
> index 963a4dba..27281c4e 100644
> --- a/drm/nouveau/nouveau_debugfs.c
> +++ b/drm/nouveau/nouveau_debugfs.c
> @@ -96,11 +96,11 @@ nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
>   } while (attr.index);
>  
>   if (state >= 0) {
> - if (info.ustate_ac == state)
> + if (info.ustate_ac == attr.state)
>   seq_printf(m, " AC");
> - if (info.ustate_dc == state)
> + if (info.ustate_dc == attr.state)
>   seq_printf(m, " DC");
> - if (info.pstate == state)
> + if (info.pstate == attr.state)
>   seq_printf(m, " *");
>   } else {
>   if (info.ustate_ac < -1)
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index d37c13b7..1d71bf09 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -272,23 +272,26 @@ nvkm_cstate_new(struct nvkm_clk *clk, int idx, struct 
> nvkm_pstate *pstate)
>   * P-States
>   
> */
>  static int
> -nvkm_pstate_prog(struct nvkm_clk *clk, int pstatei)
> +nvkm_pstate_prog(struct nvkm_clk *clk, int pstateid)
>  {
>   struct nvkm_subdev *subdev = >subdev;
>   struct nvkm_fb *fb = subdev->device->fb;
>   struct nvkm_pci *pci = subdev->device->pci;
>   struct nvkm_pstate *pstate;
> - int ret, idx = 0;
> + int ret;
>  
> - if (pstatei == NVKM_CLK_PSTATE_DEFAULT)
> + if (pstateid == NVKM_CLK_PSTATE_DEFAULT)
>   return 0;
>  
>   list_for_each_entry(pstate, >states, head) {
> - if (idx++ == pstatei)
> + if (pstate->pstate == pstateid)
>   break;
>   }
>  
> - nvkm_debug(subdev, "setting performance state %d\n", pstatei);
> + if (!pstate)
> + return -EINVAL;
> +
> + nvkm_debug(subdev, "setting performance state %x\n", pstateid);
>   clk->pstate = pstate;
>  
>   nvkm_pcie_set_link(pci, pstate->pcie_speed, pstate->pcie_width);
> @@ -329,7 +332,6 @@ nvkm_clk_update_work(struct work_struct *work)
>   pstate = clk->pwrsrc ? clk->ustate_ac : clk->ustate_dc;
>   if (clk->state_nr && pstate != -1) {
>   pstate = (pstate < 0) ? clk->astate : pstate;
> - pstate = min(pstate, clk->state_nr - 1);
>   } else {
>   pstate = NVKM_CLK_PSTATE_DEFAULT;
>   }
> @@ -490,33 +492,10 @@ nvkm_pstate_new(struct nvkm_clk *clk, int idx)
>  
> /**
>   * Adjustment triggers
>   
> */
> -static int
> -nvkm_clk_ustate_update(struct nvkm_clk *clk, int req)
> -{
> - struct nvkm_pstate *pstate;
> - int i = 0;
> -
> - if (!clk->allow_reclock)
> - return -ENOSYS;
> -
> - if (req != -1 && req != -2) {
> - list_for_each_entry(pstate, >states, head) {
> - if (pstate->pstate == req)
> - break;
> - i++;
> - }
> -
> - if (pstate->pstate != req)
> - return -EINVAL;
> - req = i;
> - }
> -
> - return req + 2;
> -}
> -
>  static int
>  nvkm_clk_nstate(struct nvkm_clk *clk, const char *mode, int arglen)
>  {
> + struct nvkm_pstate *pstate;
>   int ret = 1;
>  
>   if (clk->allow_reclock && !strncasecmpz(mode, "auto", arglen))
> @@ -528,27 +507,46 @@ nvkm_clk_nstate(struct nvkm_clk *clk, const char *mode, 
> int arglen)
>  
>   ((char *)mode)[arglen] = '\0';
>   if (!kstrtol(mode, 0, )) {
> - ret = nvkm_clk_ustate_update(clk, v);
> + ret = v;
>   if (ret < 0)
>   ret = 1;
>   }
>   ((char *)mode)[arglen] = save;
>   }
>  
> - return ret - 2;
> + 

Re: [Nouveau] [RFC PATCH 07/29] clk: Hold information about the current cstate status

[Pierre Moreau]

Acked-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-09-15 — 17:11, Karol Herbst wrote:
> Later we will have situations where the expected and the current state
> isn't the same.
> 
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> Reviewed-by: Martin Peres <martin.pe...@free.fr>
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h |  2 ++
>  drm/nouveau/nvkm/subdev/clk/base.c| 32 +---
>  2 files changed, 27 insertions(+), 7 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index ec537e08..f35518c3 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -101,6 +101,8 @@ struct nvkm_clk {
>   int ustate_ac; /* user-requested (-1 disabled, -2 perfmon) */
>   int ustate_dc; /* user-requested (-1 disabled, -2 perfmon) */
>   int astate; /* perfmon adjustment (base) */
> + struct nvkm_cstate *cstate;
> + int exp_cstateid;
>   u8  temp;
>  
>   bool allow_reclock;
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index 0d4d9fdf..d37c13b7 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -146,9 +146,14 @@ static struct nvkm_cstate *
>  nvkm_cstate_get(struct nvkm_clk *clk, struct nvkm_pstate *pstate, int 
> cstatei)
>  {
>   struct nvkm_cstate *cstate;
> - if (cstatei == NVKM_CLK_CSTATE_HIGHEST)
> + switch (cstatei) {
> + case NVKM_CLK_CSTATE_HIGHEST:
>   return list_last_entry(>list, typeof(*cstate), head);
> - else {
> + case NVKM_CLK_CSTATE_BASE:
> + return >base;
> + case NVKM_CLK_CSTATE_DEFAULT:
> + return NULL;
> + default:
>   list_for_each_entry(cstate, >list, head) {
>   if (cstate->id == cstatei)
>   return cstate;
> @@ -167,6 +172,9 @@ nvkm_cstate_prog(struct nvkm_clk *clk, struct nvkm_pstate 
> *pstate, int cstatei)
>   struct nvkm_cstate *cstate;
>   int ret;
>  
> + if (cstatei == NVKM_CLK_CSTATE_DEFAULT)
> + return 0;
> +
>   if (!list_empty(>list)) {
>   cstate = nvkm_cstate_get(clk, pstate, cstatei);
>   cstate = nvkm_cstate_find_best(clk, pstate, cstate);
> @@ -193,6 +201,7 @@ nvkm_cstate_prog(struct nvkm_clk *clk, struct nvkm_pstate 
> *pstate, int cstatei)
>  
>   ret = clk->func->calc(clk, cstate);
>   if (ret == 0) {
> + clk->cstate = cstate;
>   ret = clk->func->prog(clk);
>   clk->func->tidy(clk);
>   }
> @@ -295,7 +304,7 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstatei)
>   ram->func->tidy(ram);
>   }
>  
> - return nvkm_cstate_prog(clk, pstate, NVKM_CLK_CSTATE_HIGHEST);
> + return nvkm_cstate_prog(clk, pstate, clk->exp_cstateid);
>  }
>  
>  static void
> @@ -313,9 +322,9 @@ nvkm_clk_update_work(struct work_struct *work)
>   pstate = clk->pstate->pstate;
>   else
>   pstate = NVKM_CLK_PSTATE_DEFAULT;
> - nvkm_trace(subdev, "P %d PWR %d U(AC) %d U(DC) %d A %d T %d°C\n",
> + nvkm_trace(subdev, "P %d PWR %d U(AC) %d U(DC) %d A %d C %d T %d°C\n",
>  pstate, clk->pwrsrc, clk->ustate_ac, clk->ustate_dc,
> -clk->astate, clk->temp);
> +clk->astate, clk->exp_cstateid, clk->temp);
>  
>   pstate = clk->pwrsrc ? clk->ustate_ac : clk->ustate_dc;
>   if (clk->state_nr && pstate != -1) {
> @@ -536,6 +545,7 @@ nvkm_clk_ustate(struct nvkm_clk *clk, int req, int pwr)
>   if (ret >= 0) {
>   if (ret -= 2, pwr) clk->ustate_ac = ret;
>   else   clk->ustate_dc = ret;
> + clk->exp_cstateid = NVKM_CLK_CSTATE_HIGHEST;
>   return nvkm_clk_update(clk, true);
>   }
>   return ret;
> @@ -548,6 +558,7 @@ nvkm_clk_astate(struct nvkm_clk *clk, int req, int rel, 
> bool wait)
>   if ( rel) clk->astate += rel;
>   clk->astate = min(clk->astate, clk->state_nr - 1);
>   clk->astate = max(clk->astate, 0);
> + clk->exp_cstateid = NVKM_CLK_CSTATE_BASE;
>   return nvkm_clk_update(clk, wait);
>  }
>  
> @@ -618,6 +629,8 @@ nvkm_clk_init(struct nvkm_subdev *subdev)
>  
>   clk->astate = clk->state_nr - 1;
>   clk->pstate = NULL;
> + clk->exp_cstateid = NVKM_CLK_CSTATE_DEFAULT;
> + clk->cstate = NULL;
>

Re: [Nouveau] [RFC PATCH 06/29] clk: Make pstate a pointer to nvkm_pstate

[Pierre Moreau]

The patch seems fine but I found it super confusing that sometimes `pstate` is
a pointer (for example `clk->pstate`), sometimes it is an int (for example
`args->v0.pstate`).

On 2017-09-15 — 17:11, Karol Herbst wrote:
> We will access the current cstate at least every second and this saves us
> some CPU cycles looking them up every second.
> 
> v2: Rewording commit message.
> 
> Signed-off-by: Karol Herbst 
> Reviewed-by: Martin Peres 
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h |  4 +++-
>  drm/nouveau/nvkm/engine/device/ctrl.c |  5 -
>  drm/nouveau/nvkm/subdev/clk/base.c| 17 -
>  drm/nouveau/nvkm/subdev/pmu/gk20a.c   | 18 +++---
>  4 files changed, 26 insertions(+), 18 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index 1340f5b8..ec537e08 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -10,6 +10,8 @@ struct nvkm_pll_vals;
>  #define NVKM_CLK_CSTATE_BASE-2 /* pstate base */
>  #define NVKM_CLK_CSTATE_HIGHEST -3 /* highest possible */
>  
> +#define NVKM_CLK_PSTATE_DEFAULT -1
> +
>  enum nv_clk_src {
>   nv_clk_src_crystal,
>   nv_clk_src_href,
> @@ -95,7 +97,7 @@ struct nvkm_clk {
>  
>   struct nvkm_notify pwrsrc_ntfy;
>   int pwrsrc;
> - int pstate; /* current */
> + struct nvkm_pstate *pstate; /* current */
>   int ustate_ac; /* user-requested (-1 disabled, -2 perfmon) */
>   int ustate_dc; /* user-requested (-1 disabled, -2 perfmon) */
>   int astate; /* perfmon adjustment (base) */
> diff --git a/drm/nouveau/nvkm/engine/device/ctrl.c 
> b/drm/nouveau/nvkm/engine/device/ctrl.c
> index b0ece71a..da70626c 100644
> --- a/drm/nouveau/nvkm/engine/device/ctrl.c
> +++ b/drm/nouveau/nvkm/engine/device/ctrl.c
> @@ -52,7 +52,10 @@ nvkm_control_mthd_pstate_info(struct nvkm_control *ctrl, 
> void *data, u32 size)
>   args->v0.ustate_ac = clk->ustate_ac;
>   args->v0.ustate_dc = clk->ustate_dc;
>   args->v0.pwrsrc = clk->pwrsrc;
> - args->v0.pstate = clk->pstate;
> + if (clk->pstate)
> + args->v0.pstate = clk->pstate->pstate;
> + else
> + args->v0.pstate = NVKM_CLK_PSTATE_DEFAULT;
>   } else {
>   args->v0.count = 0;
>   args->v0.ustate_ac = NVIF_CONTROL_PSTATE_INFO_V0_USTATE_DISABLE;
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index 07d530ed..0d4d9fdf 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -271,13 +271,16 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstatei)
>   struct nvkm_pstate *pstate;
>   int ret, idx = 0;
>  
> + if (pstatei == NVKM_CLK_PSTATE_DEFAULT)
> + return 0;
> +
>   list_for_each_entry(pstate, >states, head) {
>   if (idx++ == pstatei)
>   break;
>   }
>  
>   nvkm_debug(subdev, "setting performance state %d\n", pstatei);
> - clk->pstate = pstatei;
> + clk->pstate = pstate;
>  
>   nvkm_pcie_set_link(pci, pstate->pcie_speed, pstate->pcie_width);
>  
> @@ -306,8 +309,12 @@ nvkm_clk_update_work(struct work_struct *work)
>   return;
>   clk->pwrsrc = power_supply_is_system_supplied();
>  
> + if (clk->pstate)
> + pstate = clk->pstate->pstate;
> + else
> + pstate = NVKM_CLK_PSTATE_DEFAULT;
>   nvkm_trace(subdev, "P %d PWR %d U(AC) %d U(DC) %d A %d T %d°C\n",
> -clk->pstate, clk->pwrsrc, clk->ustate_ac, clk->ustate_dc,
> +pstate, clk->pwrsrc, clk->ustate_ac, clk->ustate_dc,
>  clk->astate, clk->temp);
>  
>   pstate = clk->pwrsrc ? clk->ustate_ac : clk->ustate_dc;

In the if-statement following the previous line, the -1 could be replaced by
NVKM_CLK_PSTATE_DEFAULT.

> @@ -315,11 +322,11 @@ nvkm_clk_update_work(struct work_struct *work)
>   pstate = (pstate < 0) ? clk->astate : pstate;

Can `pstate` have negative values other than -1?

>   pstate = min(pstate, clk->state_nr - 1);
>   } else {
> - pstate = clk->pstate = -1;
> + pstate = NVKM_CLK_PSTATE_DEFAULT;

Shouldn’t you also reset `clk->pstate` to NULL? Or maybe it is
`nvkm_pstate_prog()` which should do it if
`pstatei == NVKM_CLK_PSTATE_DEFAULT`.

>   }
>  
>   nvkm_trace(subdev, "-> %d\n", pstate);
> - if (pstate != clk->pstate) {
> + if (!clk->pstate || pstate != clk->pstate->pstate) {
>   int ret = nvkm_pstate_prog(clk, pstate);
>   if (ret) {
>   nvkm_error(subdev, "error setting pstate %d: %d\n",
> @@ -610,7 +617,7 @@ nvkm_clk_init(struct nvkm_subdev *subdev)
>   return clk->func->init(clk);
>  
>   clk->astate = clk->state_nr - 1;
> - clk->pstate 

Re: [Nouveau] [RFC PATCH 05/29] clk: Remove dstate

[Pierre Moreau]

This patch could be applied before patch 04, that way patch 04 does not need to
update a function (`nvkm_clk_dstate()`) that will be removed in the next patch.

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-09-15 — 17:11, Karol Herbst wrote:
> We won't need it now, because we will adjust the clocks depending on engine
> loads later on anyway or a static lookup table. It also simplifies the
> clocking logic.
> 
> This code was nowhere used anyway and just a mock up.
> 
> v2: fixed typo in commit message
> 
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> Reviewed-by: Martin Peres <martin.pe...@free.fr>
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h |  2 --
>  drm/nouveau/nvkm/subdev/clk/base.c| 16 ++--
>  2 files changed, 2 insertions(+), 16 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index ce3bbcfe..1340f5b8 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -99,7 +99,6 @@ struct nvkm_clk {
>   int ustate_ac; /* user-requested (-1 disabled, -2 perfmon) */
>   int ustate_dc; /* user-requested (-1 disabled, -2 perfmon) */
>   int astate; /* perfmon adjustment (base) */
> - int dstate; /* display adjustment (min+) */
>   u8  temp;
>  
>   bool allow_reclock;
> @@ -121,7 +120,6 @@ struct nvkm_clk {
>  int nvkm_clk_read(struct nvkm_clk *, enum nv_clk_src);
>  int nvkm_clk_ustate(struct nvkm_clk *, int req, int pwr);
>  int nvkm_clk_astate(struct nvkm_clk *, int req, int rel, bool wait);
> -int nvkm_clk_dstate(struct nvkm_clk *, int req, int rel);
>  int nvkm_clk_tstate(struct nvkm_clk *, u8 temperature);
>  int nvkm_clk_update(struct nvkm_clk *, bool wait);
>  
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index ecff3ff3..07d530ed 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -306,15 +306,14 @@ nvkm_clk_update_work(struct work_struct *work)
>   return;
>   clk->pwrsrc = power_supply_is_system_supplied();
>  
> - nvkm_trace(subdev, "P %d PWR %d U(AC) %d U(DC) %d A %d T %d°C D %d\n",
> + nvkm_trace(subdev, "P %d PWR %d U(AC) %d U(DC) %d A %d T %d°C\n",
>  clk->pstate, clk->pwrsrc, clk->ustate_ac, clk->ustate_dc,
> -clk->astate, clk->temp, clk->dstate);
> +clk->astate, clk->temp);
>  
>   pstate = clk->pwrsrc ? clk->ustate_ac : clk->ustate_dc;
>   if (clk->state_nr && pstate != -1) {
>   pstate = (pstate < 0) ? clk->astate : pstate;
>   pstate = min(pstate, clk->state_nr - 1);
> - pstate = max(pstate, clk->dstate);
>   } else {
>   pstate = clk->pstate = -1;
>   }
> @@ -554,16 +553,6 @@ nvkm_clk_tstate(struct nvkm_clk *clk, u8 temp)
>   return nvkm_clk_update(clk, false);
>  }
>  
> -int
> -nvkm_clk_dstate(struct nvkm_clk *clk, int req, int rel)
> -{
> - if (!rel) clk->dstate  = req;
> - if ( rel) clk->dstate += rel;
> - clk->dstate = min(clk->dstate, clk->state_nr - 1);
> - clk->dstate = max(clk->dstate, 0);
> - return nvkm_clk_update(clk, true);
> -}
> -
>  static int
>  nvkm_clk_pwrsrc(struct nvkm_notify *notify)
>  {
> @@ -621,7 +610,6 @@ nvkm_clk_init(struct nvkm_subdev *subdev)
>   return clk->func->init(clk);
>  
>   clk->astate = clk->state_nr - 1;
> - clk->dstate = 0;
>   clk->pstate = -1;
>   clk->temp = 90; /* reasonable default value */
>   nvkm_clk_update(clk, true);
> -- 
> 2.14.1
> 
> ___
> 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

Re: [Nouveau] [RFC PATCH 04/29] clk: Rename nvkm_pstate_calc to nvkm_clk_update and export it

[Pierre Moreau]

On 2017-09-15 — 17:11, Karol Herbst wrote:
> This function will be used to update the current clock state.
> 
> This will happen for various reasons:
>   * Temperature changes
>   * User changes clocking state
>   * Load changes
> 
> v2: remove parameter name
> 
> Signed-off-by: Karol Herbst 
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h |  1 +
>  drm/nouveau/nvkm/subdev/clk/base.c| 26 --
>  2 files changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index e5275f74..ce3bbcfe 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -123,6 +123,7 @@ int nvkm_clk_ustate(struct nvkm_clk *, int req, int pwr);
>  int nvkm_clk_astate(struct nvkm_clk *, int req, int rel, bool wait);
>  int nvkm_clk_dstate(struct nvkm_clk *, int req, int rel);
>  int nvkm_clk_tstate(struct nvkm_clk *, u8 temperature);
> +int nvkm_clk_update(struct nvkm_clk *, bool wait);
>  
>  int nv04_clk_new(struct nvkm_device *, int, struct nvkm_clk **);
>  int nv40_clk_new(struct nvkm_device *, int, struct nvkm_clk **);
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index e4c8d310..ecff3ff3 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -296,7 +296,7 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstatei)
>  }
>  
>  static void
> -nvkm_pstate_work(struct work_struct *work)
> +nvkm_clk_update_work(struct work_struct *work)
>  {
>   struct nvkm_clk *clk = container_of(work, typeof(*clk), work);
>   struct nvkm_subdev *subdev = >subdev;
> @@ -332,9 +332,15 @@ nvkm_pstate_work(struct work_struct *work)
>   nvkm_notify_get(>pwrsrc_ntfy);
>  }
>  
> -static int
> -nvkm_pstate_calc(struct nvkm_clk *clk, bool wait)
> +int
> +nvkm_clk_update(struct nvkm_clk *clk, bool wait)
>  {
> + if (!clk)
> + return -EINVAL;
> +
> + if (!clk->allow_reclock)
> + return -ENODEV;
> +
>   atomic_set(>waiting, 1);
>   schedule_work(>work);
>   if (wait)
> @@ -524,7 +530,7 @@ nvkm_clk_ustate(struct nvkm_clk *clk, int req, int pwr)
>   if (ret >= 0) {
>   if (ret -= 2, pwr) clk->ustate_ac = ret;
>   else   clk->ustate_dc = ret;
> - return nvkm_pstate_calc(clk, true);
> + return nvkm_clk_update(clk, true);
>   }
>   return ret;
>  }
> @@ -536,7 +542,7 @@ nvkm_clk_astate(struct nvkm_clk *clk, int req, int rel, 
> bool wait)
>   if ( rel) clk->astate += rel;
>   clk->astate = min(clk->astate, clk->state_nr - 1);
>   clk->astate = max(clk->astate, 0);
> - return nvkm_pstate_calc(clk, wait);
> + return nvkm_clk_update(clk, wait);
>  }
>  
>  int
> @@ -545,7 +551,7 @@ nvkm_clk_tstate(struct nvkm_clk *clk, u8 temp)
>   if (clk->temp == temp)
>   return 0;
>   clk->temp = temp;
> - return nvkm_pstate_calc(clk, false);
> + return nvkm_clk_update(clk, false);
>  }
>  
>  int
> @@ -555,7 +561,7 @@ nvkm_clk_dstate(struct nvkm_clk *clk, int req, int rel)
>   if ( rel) clk->dstate += rel;
>   clk->dstate = min(clk->dstate, clk->state_nr - 1);
>   clk->dstate = max(clk->dstate, 0);
> - return nvkm_pstate_calc(clk, true);
> + return nvkm_clk_update(clk, true);
>  }
>  
>  static int
> @@ -563,7 +569,7 @@ nvkm_clk_pwrsrc(struct nvkm_notify *notify)
>  {
>   struct nvkm_clk *clk =
>   container_of(notify, typeof(*clk), pwrsrc_ntfy);
> - nvkm_pstate_calc(clk, false);
> + nvkm_clk_update(clk, false);
>   return NVKM_NOTIFY_DROP;

Same here as below, shouldn’t there be some error checking on what
`nvkm_clk_update()` returned, as it can fail?

>  }
>  
> @@ -618,7 +624,7 @@ nvkm_clk_init(struct nvkm_subdev *subdev)
>   clk->dstate = 0;
>   clk->pstate = -1;
>   clk->temp = 90; /* reasonable default value */
> - nvkm_pstate_calc(clk, true);
> + nvkm_clk_update(clk, true);
>   return 0;

`nvkm_pstate_calc()` did not return any error code, but `nvkm_clk_update()` now
can, so shouldn’t the function return the return value of `nvkm_clk_update()`
instead? Or at least do some error checking on what `nvkm_clk_update()`
returned?

>  }
>  
> @@ -675,7 +681,7 @@ nvkm_clk_ctor(const struct nvkm_clk_func *func, struct 
> nvkm_device *device,
>   clk->ustate_dc = -1;
>   clk->allow_reclock = allow_reclock;
>  
> - INIT_WORK(>work, nvkm_pstate_work);
> + INIT_WORK(>work, nvkm_clk_update_work);
>   init_waitqueue_head(>wait);
>   atomic_set(>waiting, 0);
>  
> -- 
> 2.14.1
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


signature.asc
Description: PGP signature
___
Nouveau mailing list

Re: [Nouveau] [RFC PATCH 03/29] subdev/volt/gk104: return error when read fails

[Pierre Moreau]

On 2017-09-15 — 17:11, Karol Herbst wrote:
> While my gpu was powered off, hwmon returned 0.6V as the current voltage.
> If nvkm_rd32 fails for any reason, return the error.
> 
> With that sensors will display a "N/A" instead of 0.6V.

Small nitpick, add a comma between “that” and “sensors”.
Otherwise,

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

> 
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> ---
>  drm/nouveau/nvkm/subdev/volt/gk104.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drm/nouveau/nvkm/subdev/volt/gk104.c 
> b/drm/nouveau/nvkm/subdev/volt/gk104.c
> index 1c744e02..53a7af9d 100644
> --- a/drm/nouveau/nvkm/subdev/volt/gk104.c
> +++ b/drm/nouveau/nvkm/subdev/volt/gk104.c
> @@ -40,10 +40,15 @@ gk104_volt_get(struct nvkm_volt *base)
>  {
>   struct nvbios_volt *bios = _volt(base)->bios;
>   struct nvkm_device *device = base->subdev.device;
> - u32 div, duty;
> + int div, duty;
>  
>   div  = nvkm_rd32(device, 0x20340);
> + if (div < 0)
> + return div;
> +
>   duty = nvkm_rd32(device, 0x20344);
> + if (duty < 0)
> + return duty;
>  
>   return bios->base + bios->pwm_range * duty / div;
>  }
> -- 
> 2.14.1
> 
> ___
> 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

Re: [Nouveau] [RFC PATCH 02/29] hwmon: properly check for errors

[Pierre Moreau]

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-09-15 — 17:11, Karol Herbst wrote:
> Otherwise hwmon interprets error codes as real values.
> 
> Signed-off-by: Karol Herbst <karolher...@gmail.com>
> ---
>  drm/nouveau/nouveau_hwmon.c | 33 ++---
>  1 file changed, 26 insertions(+), 7 deletions(-)
> 
> diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c
> index f1914d9a..0d75c14d 100644
> --- a/drm/nouveau/nouveau_hwmon.c
> +++ b/drm/nouveau/nouveau_hwmon.c
> @@ -470,18 +470,23 @@ nouveau_fan_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
>   struct nouveau_drm *drm = nouveau_drm(drm_dev);
>   struct nvkm_therm *therm = nvxx_therm(>client.device);
> + int ret;
>  
>   if (!therm)
>   return -EOPNOTSUPP;
>  
>   switch (attr) {
>   case hwmon_fan_input:
> - *val = nvkm_therm_fan_sense(therm);
> + ret = nvkm_therm_fan_sense(therm);
>   break;
>   default:
>   return -EOPNOTSUPP;
>   }
>  
> + if (ret < 0)
> + return ret;
> +
> + *val = ret;
>   return 0;
>  }
>  
> @@ -491,7 +496,7 @@ nouveau_in_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
>   struct nouveau_drm *drm = nouveau_drm(drm_dev);
>   struct nvkm_volt *volt = nvxx_volt(>client.device);
> - int ret;
> + int ret = 0;
>  
>   if (!volt)
>   return -EOPNOTSUPP;
> @@ -499,7 +504,8 @@ nouveau_in_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   switch (attr) {
>   case hwmon_in_input:
>   ret = nvkm_volt_get(volt);
> - *val = ret < 0 ? ret : (ret / 1000);
> + if (ret >= 0)
> + *val = ret / 1000;
>   break;
>   case hwmon_in_min:
>   *val = volt->min_uv > 0 ? (volt->min_uv / 1000) : -ENODEV;
> @@ -511,7 +517,7 @@ nouveau_in_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   return -EOPNOTSUPP;
>   }
>  
> - return 0;
> + return ret;
>  }
>  
>  static int
> @@ -520,21 +526,26 @@ nouveau_pwm_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
>   struct nouveau_drm *drm = nouveau_drm(drm_dev);
>   struct nvkm_therm *therm = nvxx_therm(>client.device);
> + int ret;
>  
>   if (!therm || !therm->attr_get || !therm->fan_get)
>   return -EOPNOTSUPP;
>  
>   switch (attr) {
>   case hwmon_pwm_enable:
> - *val = therm->attr_get(therm, NVKM_THERM_ATTR_FAN_MODE);
> + ret = therm->attr_get(therm, NVKM_THERM_ATTR_FAN_MODE);
>   break;
>   case hwmon_pwm_input:
> - *val = therm->fan_get(therm);
> + ret = therm->fan_get(therm);
>   break;
>   default:
>   return -EOPNOTSUPP;
>   }
>  
> + if (ret < 0)
> + return ret;
> +
> + *val = ret;
>   return 0;
>  }
>  
> @@ -544,18 +555,26 @@ nouveau_power_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
>   struct nouveau_drm *drm = nouveau_drm(drm_dev);
>   struct nvkm_iccsense *iccsense = nvxx_iccsense(>client.device);
> + int ret;
>  
>   if (!iccsense)
>   return -EOPNOTSUPP;
>  
>   switch (attr) {
>   case hwmon_power_input:
> - *val = nvkm_iccsense_read_all(iccsense);
> + ret = nvkm_iccsense_read_all(iccsense);
> + if (ret < 0)
> + return ret;
> + *val = ret;
>   break;
>   case hwmon_power_max:
> + if (iccsense->power_w_max <= 0)
> + return -ENODEV;
>   *val = iccsense->power_w_max;
>   break;
>   case hwmon_power_crit:
> + if (iccsense->power_w_crit <= 0)
> + return -ENODEV;
>   *val = iccsense->power_w_crit;
>   break;
>   default:
> -- 
> 2.14.1
> 
> ___
> 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

Re: [Nouveau] [RFC PATCH 01/29] therm: split return code and value in nvkm_get_temp

[Pierre Moreau]

As you changed the return value of `temp_get()` to solely be the error code, or
absence of an error, I would change all those tests that checked whether the
returned value was strictly less, or greater than, 0 to now only compare
against 0 (no error). For example,

  if (therm && therm->attr_get && nvkm_therm_temp_get(therm, ) < 0)
  if (therm->func->temp_get(therm, ) >= 0)

could become

  if (therm && therm->attr_get && nvkm_therm_temp_get(therm, ))
  if (!therm->func->temp_get(therm, ))

to match other error checking code.

More comments below

On 2017-09-15 — 17:11, Karol Herbst wrote:
> The current hwmon code doesn't check if the returned value was actually an
> error.
> 
> Since Kepler temperature sensors are able to report negative values.

I assume those negative values are not for error reporting, but more if you
buried your GPU in the snow somewhere in the Antarctic and still want a valid
temperature to be reported.

> Since Pascal (and maybe earlier) we have sensors with improved precision.
> 
> Adjust the nvkm_get_temp method to be able to deal with those changes
> and let hwmon return an error properly.
> 
> Signed-off-by: Karol Herbst 
> ---
>  drm/nouveau/include/nvkm/subdev/therm.h |  2 +-
>  drm/nouveau/nouveau_hwmon.c | 15 +--
>  drm/nouveau/nvkm/subdev/therm/base.c| 19 ++-
>  drm/nouveau/nvkm/subdev/therm/g84.c | 11 ++-
>  drm/nouveau/nvkm/subdev/therm/gp100.c   |  9 +
>  drm/nouveau/nvkm/subdev/therm/nv40.c|  9 +++--
>  drm/nouveau/nvkm/subdev/therm/nv50.c|  9 +++--
>  drm/nouveau/nvkm/subdev/therm/priv.h|  4 ++--
>  drm/nouveau/nvkm/subdev/therm/temp.c| 16 
>  9 files changed, 55 insertions(+), 39 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/therm.h 
> b/drm/nouveau/include/nvkm/subdev/therm.h
> index 9841f076..8c84017f 100644
> --- a/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -86,7 +86,7 @@ struct nvkm_therm {
>   int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
>  };
>  
> -int nvkm_therm_temp_get(struct nvkm_therm *);
> +int nvkm_therm_temp_get(struct nvkm_therm *, int *);
>  int nvkm_therm_fan_sense(struct nvkm_therm *);
>  int nvkm_therm_cstate(struct nvkm_therm *, int, int);
>  
> diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c
> index 7c965648..f1914d9a 100644
> --- a/drm/nouveau/nouveau_hwmon.c
> +++ b/drm/nouveau/nouveau_hwmon.c
> @@ -326,8 +326,9 @@ nouveau_temp_is_visible(const void *data, u32 attr, int 
> channel)
>  {
>   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
>   struct nvkm_therm *therm = nvxx_therm(>client.device);
> + int val;
>  
> - if (therm && therm->attr_get && nvkm_therm_temp_get(therm) < 0)
> + if (therm && therm->attr_get && nvkm_therm_temp_get(therm, ) < 0)
>   return 0;
>  
>   switch (attr) {
> @@ -421,15 +422,16 @@ nouveau_temp_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
>   struct nouveau_drm *drm = nouveau_drm(drm_dev);
>   struct nvkm_therm *therm = nvxx_therm(>client.device);
> - int ret;
> + int ret = 0;
> + int temp;
>  
>   if (!therm || !therm->attr_get)
>   return -EOPNOTSUPP;
>  
>   switch (attr) {
>   case hwmon_temp_input:
> - ret = nvkm_therm_temp_get(therm);
> - *val = ret < 0 ? ret : (ret * 1000);
> + ret = nvkm_therm_temp_get(therm, );
> + *val = temp * 1000;
>   break;
>   case hwmon_temp_max:
>   *val = therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK)
> @@ -459,7 +461,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int 
> channel, long *val)
>   return -EOPNOTSUPP;
>   }
>  
> - return 0;
> + return ret;
>  }
>  
>  static int
> @@ -713,6 +715,7 @@ nouveau_hwmon_init(struct drm_device *dev)
>   struct device *hwmon_dev;
>   int ret = 0;
>   int i = 0;
> + int val;
>  
>   hwmon = drm->hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
>   if (!hwmon)
> @@ -720,7 +723,7 @@ nouveau_hwmon_init(struct drm_device *dev)
>   hwmon->dev = dev;
>  
>   if (therm && therm->attr_get && therm->attr_set) {
> - if (nvkm_therm_temp_get(therm) >= 0)
> + if (nvkm_therm_temp_get(therm, ) >= 0)
>   special_groups[i++] = _auto_point_sensor_group;
>   if (therm->fan_get && therm->fan_get(therm) >= 0)
>   special_groups[i++] = _fan_sensor_group;
> diff --git a/drm/nouveau/nvkm/subdev/therm/base.c 
> b/drm/nouveau/nvkm/subdev/therm/base.c
> index f27fc6d0..8fa691fb 100644
> --- a/drm/nouveau/nvkm/subdev/therm/base.c
> +++ b/drm/nouveau/nvkm/subdev/therm/base.c
> @@ -24,22 +24,26 @@
>  #include "priv.h"
>  
>  int
> 

Re: [Nouveau] [PATCH] drm/nouveau: Document nouveau support for Tegra in DRIVER_DESC

[Pierre Moreau]

You are right, Tegra should probably be part of the description, even if we do
not support pre-K1 Tegras.

Acked-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-08-11 — 10:56, Rhys Kidd wrote:
> nouveau supports the Tegra K1 and higher after the SoC-based GPUs converged
> with the main GeForce GPU families.
> 
> Signed-off-by: Rhys Kidd <rhysk...@gmail.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index 822fe1d4d35e..fbe42ec0a5f1 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -5,7 +5,7 @@
>  #define DRIVER_EMAIL "nouveau@lists.freedesktop.org"
>  
>  #define DRIVER_NAME  "nouveau"
> -#define DRIVER_DESC  "nVidia Riva/TNT/GeForce/Quadro/Tesla"
> +#define DRIVER_DESC  "nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra"
>  #define DRIVER_DATE  "20120801"
>  
>  #define DRIVER_MAJOR 1
> -- 
> 2.11.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] [PATCH] drm/Makefile: Support custom output dir with O

[Pierre Moreau]

If the `O` variable from Makefile — which allows to specify the output folder
for the build process — is used when building Linux, it needs to be specified
when building Nouveau, even when out-of-tree.

This patch doesn’t fix any issues but let the developers — who uses the `O`
variable — avoid having to keep a custom patch around.

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drm/Makefile b/drm/Makefile
index d5e23738..1f4ef45e 100644
--- a/drm/Makefile
+++ b/drm/Makefile
@@ -11,6 +11,9 @@ endif
 
 KBUILD_OPTS := M=$(CURDIR)/nouveau
 KBUILD_OPTS += KCPPFLAGS="-Iinclude/uapi/drm"
+ifdef OUTPUTDIR
+  KBUILD_OPTS += O=$(OUTPUTDIR)
+endif
 
 all: modules
 
-- 
2.14.1

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

Re: [Nouveau] [RFC PATCH 13/13] clk: thermal throttling

[Pierre Moreau]

On 2017-07-21 — 23:55, Karol Herbst wrote:
> Signed-off-by: Karol Herbst 
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h |  1 +
>  drm/nouveau/nvkm/subdev/clk/base.c| 35 
> +++
>  2 files changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index f5ff1fd9..b79bf657 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -106,6 +106,7 @@ struct nvkm_clk {
>   u8  temp;
>   u8  max_temp;
>   u8  relax_temp;
> + bool throttled;
>  
>   bool allow_reclock;
>  #define NVKM_CLK_BOOST_NONE 0x0
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index 60edb57b..34642000 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -279,7 +279,7 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstateid)
>   struct nvkm_fb *fb = subdev->device->fb;
>   struct nvkm_pci *pci = subdev->device->pci;
>   struct nvkm_pstate *pstate;
> - int ret;
> + int ret, cstate;
>  
>   if (pstateid == NVKM_CLK_PSTATE_DEFAULT)
>   return 0;
> @@ -308,7 +308,12 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstateid)
>   ram->func->tidy(ram);
>   }
>  
> - return nvkm_cstate_prog(clk, pstate, clk->exp_cstateid);
> + if (clk->throttled)
> + cstate = list_first_entry(>list, struct nvkm_cstate, 
> head)->id;
> + else
> + cstate = clk->exp_cstateid;
> +
> + return nvkm_cstate_prog(clk, pstate, cstate);
>  }
>  
>  static void
> @@ -333,12 +338,17 @@ nvkm_clk_update_work(struct work_struct *work)
>  
>   pstate = clk->pwrsrc ? clk->ustate_ac : clk->ustate_dc;
>   if (clk->state_nr && pstate != -1) {
> - pstate = (pstate < 0) ? clk->astate : pstate;
> + if (clk->throttled)
> + pstate = list_first_entry(>states, struct 
> nvkm_pstate, head)->pstate;
> + else
> + pstate = (pstate < 0) ? clk->astate : pstate;
>   } else {
>   pstate = NVKM_CLK_PSTATE_DEFAULT;
>   }
>  
> - nvkm_trace(subdev, "-> %d\n", pstate);
> + nvkm_trace(subdev, "P %d PWR %d U(AC) %d U(DC) %d A %d C %d T %d°C\n",
> +pstate, clk->pwrsrc, clk->ustate_ac, clk->ustate_dc,
> +clk->astate, clk->exp_cstateid, clk->temp);
>  
>   /* only call into the code if the GPU is powered on */
>   if ((!clk->pstate || pstate != clk->pstate->pstate)
> @@ -574,9 +584,25 @@ nvkm_clk_astate(struct nvkm_clk *clk, int req, int rel, 
> bool wait)
>  int
>  nvkm_clk_tstate(struct nvkm_clk *clk, u8 temp)
>  {
> + struct nvkm_subdev *subdev = >subdev;
>   if (clk->temp == temp)
>   return 0;
>   clk->temp = temp;
> + if (clk->max_temp && clk->relax_temp) {
> + if (!clk->throttled && temp > clk->max_temp) {
> + nvkm_warn(subdev,
> +   "temperature (%d C) hit the 'downclock' "
> +   "threshold\n",
> +   temp);
> + clk->throttled = true;
> + } else if (clk->throttled && temp < clk->relax_temp) {
> + nvkm_warn(subdev,
> +   "temperature (%d C) went below the "
> +   "'relax' threshold\n",
> +   temp);
> + clk->throttled = false;

I don't think this should be a warning. Maybe an `nvkm_info()` instead?

Also, should the throttled status be reset/recomputed after suspend/resume 
cycle?

> + }
> + }
>   return nvkm_clk_update(clk, false);
>  }
>  
> @@ -737,6 +763,7 @@ nvkm_clk_ctor(const struct nvkm_clk_func *func, struct 
> nvkm_device *device,
>   clk->ustate_dc = -1;
>   clk->exp_cstateid = NVKM_CLK_CSTATE_DEFAULT;
>   clk->temp = 90; /* reasonable default value */
> + clk->throttled = false;
>  
>   clk->allow_reclock = allow_reclock;
>  
> -- 
> 2.13.2
> 
> ___
> 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

Re: [Nouveau] [PATCH] drm/nouveau/hwmon: Uninitialized variables in sysfs

[Pierre Moreau]

Reviewed-by: Pierre Moreau <pierre.mor...@free.fr>

On 2017-07-17 — 11:17, Dan Carpenter wrote:
> kstrtol() and friends can return -EINVAL or -ERANGE.  We have to test
> for both, otherwise the value is possibly uninitialized.  Also in some
> of these files we accidentally return "count" on error instead of a
> negative error code.
> 
> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 7c965648df80..5e75af91c446 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -68,9 +68,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device *d,
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct nvkm_therm *therm = nvxx_therm(>client.device);
>   long value;
> + int ret;
>  
> - if (kstrtol(buf, 10, ) == -EINVAL)
> - return count;
> + ret = kstrtol(buf, 10, );
> + if (ret)
> + return ret;
>  
>   therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST,
>   value / 1000);
> @@ -101,9 +103,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct 
> device *d,
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct nvkm_therm *therm = nvxx_therm(>client.device);
>   long value;
> + int ret;
>  
> - if (kstrtol(buf, 10, ) == -EINVAL)
> - return count;
> + ret = kstrtol(buf, 10, );
> + if (ret)
> + return ret;
>  
>   therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST_HYST,
>   value / 1000);
> @@ -156,8 +160,9 @@ nouveau_hwmon_set_pwm1_min(struct device *d, struct 
> device_attribute *a,
>   long value;
>   int ret;
>  
> - if (kstrtol(buf, 10, ) == -EINVAL)
> - return -EINVAL;
> + ret = kstrtol(buf, 10, );
> + if (ret)
> + return ret;
>  
>   ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MIN_DUTY, value);
>   if (ret < 0)
> @@ -179,8 +184,9 @@ nouveau_hwmon_set_pwm1_max(struct device *d, struct 
> device_attribute *a,
>   long value;
>   int ret;
>  
> - if (kstrtol(buf, 10, ) == -EINVAL)
> - return -EINVAL;
> + ret = kstrtol(buf, 10, );
> + if (ret)
> + return ret;
>  
>   ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MAX_DUTY, value);
>   if (ret < 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

Re: [Nouveau] GTX 1080 Ti (NV132/GP102)

[Pierre Moreau]

> Another issue is that in Google Chrome I seem have no hardware acceleration
> for anything other than "Multiple Raster Threads". See attached.

Two things: you are using nomodeset, and hardware acceleration for Pascal cards
was only merged in 4.12 (which has not been released yet), as pointed out by
Ilia.

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

Re: [Nouveau] NV130 - gtx 1050 ti

[Pierre Moreau]

Hello,

Acceleration for Pascal cards is coming in Linux 4.12, support for Pascal cards
in xorg-video-nouveau is in 1.0.15, and if I remember correctly, on the
Mesa-side, you will need >=17.0.

Pierre

On 02:04 am - May 04 2017, Karl Schmidt wrote:
> This is probably the problem
> May  3 16:44:45 kernel: [7.068336] nouveau E[  DEVICE][:08:00.0] 
> unknown chipset, 0x137000a1
> May  3 16:44:45 kernel: [7.068401] nouveau E[ DRM] failed to create 
> 0x8080, -22
> May  3 16:44:45 kernel: [7.068723] nouveau: probe of :08:00.0 failed 
> with error -22
> 
> I can make this card available - if you can tell me an older card that can do 
> the
> hdmi2 480x1200 60hz 4:4:4 output that is in
> 
> xserver-xorg-video-nouveau 1:1.0.13-3
> 
> -- 
> 
> Karl Schmidt  EMail k...@xtronics.com
> Transtronics, Inc.  WEB 
> http://secure.transtronics.com
> 3209 West 9th Street Ph (785) 841-3089
> Lawrence, KS 66049  FAX (785) 841-0434
> 
> Coordination does not run in my family,
> it stumbles.
> 
> ___
> 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] [PATCH REBASED 2/2] Do not register interface if Apple GMUX detected

[Pierre Moreau]

From: Pierre Moreau <pierre.mor...@free.fr>

The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.

v2: Do not split information message on two lines as it prevents from grepping
it, as pointed out by Lukas Wunner

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 0e69612..3c91c24 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -30,6 +30,7 @@
  * Register locations derived from NVClock by Roderick Colenbrander
  */
 
+#include 
 #include 
 #include 
 
@@ -258,6 +259,11 @@ 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.10.2

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

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

[Pierre Moreau]

From: Pierre Moreau <pierre.mor...@free.fr>

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.

v3:
* Define a macro for the size of the backlight name, to avoid defining
  it multiple times;
* Use snprintf in place of sprintf.

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 65 +++--
 drivers/gpu/drm/nouveau/nouveau_display.h   | 10 +
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +
 drivers/gpu/drm/nouveau/nouveau_drv.h   |  1 +
 4 files changed, 74 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 5e2c568..0e69612 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -31,11 +31,32 @@
  */
 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_reg.h"
 #include "nouveau_encoder.h"
 
+static struct ida bl_ida;
+#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
+
+struct backlight_connector {
+   struct list_head head;
+   int id;
+};
+
+static void
+nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE], struct
+   backlight_connector *connector)
+{
+   const int nb = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
+   if (nb > 0 && nb < 100)
+   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
+   else
+   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight");
+   connector->id = nb;
+}
+
 static int
 nv40_get_intensity(struct backlight_device *bd)
 {
@@ -74,6 +95,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[BL_NAME_SIZE];
 
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return 0;
@@ -81,10 +104,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 +211,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[BL_NAME_SIZE];
 
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -203,11 +234,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 +258,8 @@ nouveau_backlight_init(st

[Nouveau] [PATCH v3 2/2] Do not register interface if Apple GMUX detected

[Pierre Moreau]

The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.

v2: Do not split information message on two lines as it prevents from grepping
it, as pointed out by Lukas Wunner

v3: Add a missing end-of-line character to the printed message

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/nouveau_backlight.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index a34cd35..8b1ca4a 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 
 
@@ -267,6 +268,11 @@ 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\n");
+   return 0;
+   }
+
INIT_LIST_HEAD(>bl_connectors);
 
list_for_each_entry(connector, >mode_config.connector_list, head) {
-- 
2.10.2

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

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

[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.

v3:
* Define a macro for the size of the backlight name, to avoid defining
  it multiple times;
* Use snprintf in place of sprintf.

v4:
* Do not create similarly named interfaces when reaching the maximum
  amount of unique names, but fail instead, as pointed out by Lukas Wunner

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/nouveau_backlight.c | 74 ++---
 drm/nouveau/nouveau_display.h   | 10 ++
 drm/nouveau/nouveau_drm.c   |  2 ++
 drm/nouveau/nouveau_drv.h   |  1 +
 4 files changed, 83 insertions(+), 4 deletions(-)

diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 5e2c568..a34cd35 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -31,11 +31,35 @@
  */
 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_reg.h"
 #include "nouveau_encoder.h"
 
+static struct ida bl_ida;
+#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
+
+struct backlight_connector {
+   struct list_head head;
+   int id;
+};
+
+static bool
+nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE], struct 
backlight_connector
+   *connector)
+{
+   const int nb = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
+   if (nb < 0 || nb >= 100)
+   return false;
+   if (nb > 0)
+   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
+   else
+   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight");
+   connector->id = nb;
+   return true;
+}
+
 static int
 nv40_get_intensity(struct backlight_device *bd)
 {
@@ -74,6 +98,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[BL_NAME_SIZE];
 
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return 0;
@@ -81,10 +107,19 @@ 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,
+   if (!nouveau_get_backlight_name(backlight_name, _connector)) {
+   NV_ERROR(drm, "Failed to retrieve a unique name for the 
backlight interface\n");
+   return 0;
+   }
+   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 +217,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[BL_NAME_SIZE];
 
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -203,11 +240,20 @@ 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,
+   if (!nouveau_get_backlight_name(backlight_name, _connector)) {
+   NV_ERROR(drm, "Failed to retrieve a unique name for the 
backlight interface\n");
+   return 0;
+   }
+   bd = backlight_device_register(backlight_name , connector->kdev,
   nv_encoder, ops, );
-   if (IS_ERR(bd))
+
+   if (IS_ERR(bd)) {
+

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

[Pierre Moreau]

On 11:17 am - Nov 14 2016, Lukas Wunner wrote:
> On Sun, Nov 13, 2016 at 08:57:06PM +0100, Pierre Moreau wrote:
> > From: Pierre Moreau <pierre.mor...@free.fr>
> > 
> > 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.
> > 
> > v3:
> > * Define a macro for the size of the backlight name, to avoid defining
> >   it multiple times;
> > * Use snprintf in place of sprintf.
> > 
> > Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_backlight.c | 65 
> > +++--
> >  drivers/gpu/drm/nouveau/nouveau_display.h   | 10 +
> >  drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +
> >  drivers/gpu/drm/nouveau/nouveau_drv.h   |  1 +
> >  4 files changed, 74 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> > b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > index 5e2c568..0e69612 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > @@ -31,11 +31,32 @@
> >   */
> >  
> >  #include 
> > +#include 
> >  
> >  #include "nouveau_drv.h"
> >  #include "nouveau_reg.h"
> >  #include "nouveau_encoder.h"
> >  
> > +static struct ida bl_ida;
> > +#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
> > +
> > +struct backlight_connector {
> > +   struct list_head head;
> > +   int id;
> > +};
> > +
> > +static void
> > +nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE], struct
> > +   backlight_connector *connector)
> > +{
> > +   const int nb = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> > +   if (nb > 0 && nb < 100)
> > +   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
> > +   else
> > +   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight");
> > +   connector->id = nb;
> > +}
> > +
> 
> Just a minor issue, in the >= 100 case, backlight creation should probably
> fail rather than reverting to "nv_backlight".  Other than that LGTM.

I don’t see how you could get to more than 100 backlight interfaces, but you
are absolutely right, it should fail rather than reverting to "nv_backlight".
I’ll add a return code to `nouveau_get_backlight_name()` and check for that in
the `nvX0_backlight_init()` functions. If it is non-zero, I’m not sure whether
I should return an error code (and if so, which one) or just a plain 0.

Thanks,
Pierre

PS: I have no idea what went wrong with the e-mail address, and why it decided
to send it from my other e-mail address rather than the usual one… I’ll have to
fix that before sending the updated version.

> 
> Thanks,
> 
> Lukas
> 
> >  static int
> >  nv40_get_intensity(struct backlight_device *bd)
> >  {
> > @@ -74,6 +95,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[BL_NAME_SIZE];
> >  
> > if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
> > return 0;
> > @@ -81,10 +104,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,
> >  

Re: [Nouveau] Atomic modesetting + DisplayPort MST

[Pierre Moreau]

Hello Ben,

You can find below my results; there is a slight over-representation of 1st gen
Tesla cards, but… that’s what I have. :-D No regressions observed, apart from:

* screen rotation on G80, MCP79
* resuming on G86

I’ll retest those cards with your linux-4.10 branch but without the atomic + DP
serie.

Pierre


Tested: linux-4.10 (HEAD at b27add13f "drm/nouveau/fifo/gf100-: protect channel 
preempt with subdev mutex)
Against: 4.8.7
Fullscreen game: Portal
(FAIL is: it is not working, but neither did it before.)


G80:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: REGRESSION (disp: ERROR 5 [INVALID_STATE]
* Suspend:   OK
* Hotplugging:   -
* Fullscreen game:   FAIL (fail ttm_validate, vaildate: -12) (different on 
4.8.7, but still failing)

G84:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   FAIL (DRM: base-0: timeout)
* Hotplugging:   OK
* Fullscreen game:   OK

G86:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   REGRESSION (PGRAPH TLB flush idle timeout fail)
* Hotplugging:   -
* Fullscreen game:   FAIL (gr: TRAP_PROP - TP 0 - 0040 [RT_FAULT] - Address 
004bed) (does not work im 4.8.7 either, though there was no trap, just FAIL 
ttm_validate & cie)

G92:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   -
* Fullscreen game:   OK

G94:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   -
* Fullscreen game:   OK

G96:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   -
* Fullscreen game:   OK

G98:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   OK
* Fullscreen game:   FAIL (fail ttm_validate, vaildate: -12)

MCP79:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: REGRESSION (no freeze, no errors, cursor was correctly 
updated, but screen does not update though switching to TTY works just fine)
* Suspend:   OK
* Hotplugging:   -
* Fullscreen game:   OK

GT200:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   FAIL (PGRAPH TLB idle timeout fail)
* Hotplugging:   -
* Fullscreen game:   OK

GF100:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   -
* Fullscreen game:   OK

GF114:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   -
* Fullscreen game:   OK

GK208:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   OK
* Fullscreen game:   OK

GM206:
* Basic modesetting: OK
* VT switching:  OK
* Changing rotation: OK
* Suspend:   OK
* Hotplugging:   OK
* Fullscreen game:   OK



On 07:41 pm - Nov 04 2016, Ben Skeggs wrote:
> Hey all,
> 
> I've just pushed out the initial Nouveau support for $subject \o/
> 
> As the atomic modesetting transition is basically a rewrite of the KMS
> portion of the driver, I would be very grateful for any additional
> testing that people could provide (even as simple as just booting and
> making sure you get a display is valuable).
> 
> There's a Linux tree at
> https://github.com/skeggsb/linux/tree/linux-4.10, and the code also
> exists in my usual development tree[1] on the master branch (which is
> currently based on Dave's drm-next tree for Linux 4.10).
> 
> There's another branch (devel-kms) in the same repository, which is the
> same code on top of what's currently Linux 4.9.  If you have problems
> with the 4.10 code, I'd definitely be interested in seeing if they exist
> on the 4.9 branch too.
> 
> Thanks in advance!
> Ben.
> 
> [1] https://github.com/skeggsb/nouveau
> 




> ___
> 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

Re: [Nouveau] [PATCH 1/3] nvbios/power_budget: Add basic power budget parsing

[Pierre Moreau]

On 11:55 am - Nov 12 2016, Karol Herbst wrote:
> v2: Set entry to 0xff if not found
> Add cap entry for ver 0x30 tables
> Rework to fix memory leak
> 
> Signed-off-by: Karol Herbst 
> ---
>  .../include/nvkm/subdev/bios/power_budget.h|  24 
>  drm/nouveau/nvkm/subdev/bios/Kbuild|   1 +
>  drm/nouveau/nvkm/subdev/bios/power_budget.c| 122 
> +
>  3 files changed, 147 insertions(+)
>  create mode 100644 drm/nouveau/include/nvkm/subdev/bios/power_budget.h
>  create mode 100644 drm/nouveau/nvkm/subdev/bios/power_budget.c
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/bios/power_budget.h 
> b/drm/nouveau/include/nvkm/subdev/bios/power_budget.h
> new file mode 100644
> index 000..f295cc7
> --- /dev/null
> +++ b/drm/nouveau/include/nvkm/subdev/bios/power_budget.h
> @@ -0,0 +1,24 @@
> +#ifndef __NVBIOS_POWER_BUDGET_H__
> +#define __NVBIOS_POWER_BUDGET_H__
> +
> +#include 
> +
> +struct nvbios_power_budget_entry {
> + u32 min_w;
> + u32 avg_w;
> + u32 max_w;
> +};
> +
> +struct nvbios_power_budget {
> + u32 offset;
> + u8  header_len;
> + u8  entry_len;
> + u8  entry_count;
> + u8  cap_entry;
> +};
> +
> +int nvbios_power_budget_header(struct nvkm_bios *, struct 
> nvbios_power_budget *);
> +int nvbios_power_budget_entry(struct nvkm_bios *, struct nvbios_power_budget 
> *,
> +  u8 idx, struct nvbios_power_budget_entry *);
> +
> +#endif
> diff --git a/drm/nouveau/nvkm/subdev/bios/Kbuild 
> b/drm/nouveau/nvkm/subdev/bios/Kbuild
> index be57220..6b4f1e0 100644
> --- a/drm/nouveau/nvkm/subdev/bios/Kbuild
> +++ b/drm/nouveau/nvkm/subdev/bios/Kbuild
> @@ -19,6 +19,7 @@ nvkm-y += nvkm/subdev/bios/pcir.o
>  nvkm-y += nvkm/subdev/bios/perf.o
>  nvkm-y += nvkm/subdev/bios/pll.o
>  nvkm-y += nvkm/subdev/bios/pmu.o
> +nvkm-y += nvkm/subdev/bios/power_budget.o
>  nvkm-y += nvkm/subdev/bios/ramcfg.o
>  nvkm-y += nvkm/subdev/bios/rammap.o
>  nvkm-y += nvkm/subdev/bios/shadow.o
> diff --git a/drm/nouveau/nvkm/subdev/bios/power_budget.c 
> b/drm/nouveau/nvkm/subdev/bios/power_budget.c
> new file mode 100644
> index 000..ed9760e
> --- /dev/null
> +++ b/drm/nouveau/nvkm/subdev/bios/power_budget.c
> @@ -0,0 +1,122 @@
> +/*
> + * Copyright 2016 Karol Herbst
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: Karol Herbst
> + */
> +#include 
> +#include 
> +#include 
> +
> +static u32
> +nvbios_power_budget_table(struct nvkm_bios *bios, u8 *ver, u8 *hdr, u8 *cnt,
> +   u8 *len)
> +{
> + struct bit_entry bit_P;
> + u32 power_budget;
> +
> + if (bit_entry(bios, 'P', _P) || bit_P.version != 2 ||
> + bit_P.length < 0x2c)
> + return 0;
> +
> + power_budget = nvbios_rd32(bios, bit_P.offset + 0x2c);
> + if (!power_budget)
> + return 0;
> +
> + *ver = nvbios_rd08(bios, power_budget);
> + switch (*ver) {
> + case 0x10:
> + case 0x20:
> + case 0x30:
> + *hdr = nvbios_rd08(bios, power_budget + 0x1);
> + *len = nvbios_rd08(bios, power_budget + 0x2);
> + *cnt = nvbios_rd08(bios, power_budget + 0x3);
> + return power_budget;
> + default:
> + break;
> + }
> +
> + return 0;
> +}
> +
> +int
> +nvbios_power_budget_header(struct nvkm_bios *bios,
> +   struct nvbios_power_budget *budget)
> +{
> + struct nvkm_subdev *subdev = >subdev;
> + u8 ver, hdr, cnt, len, cap_entry;
> + u32 header;
> +
> + header = nvbios_power_budget_table(bios, , , , );
> + if (!header || !cnt)

Should there be a check for `budget` being `NULL` here, similarly to
`nvbios_power_budger_entry()`? (I haven’t looked at the other patches yet.)

> + return -ENODEV;
> +
> + budget->offset = header;
> + budget->header_len = hdr;
> 

Re: [Nouveau] NVAC "No Signal"

[Pierre Moreau]

I retested with both 4.8.4, Ben’s linux-4.9 and linux-4.10 branches (so only
the linux-4.10 branch had the atomic+MST patches).
For all branches, if I bootplug the external screen, I get nothing on the
external screen, and the laptop screen is frozen with some mix of images (but
the laptop itself is not locked up), nothing in dmesg. If I hotplug the screen,
the laptop screen is not frozen, but starting with linux-4.10, I get an EVO
timeout when turning off the external monitor. Adding your patch did not change
anything for me.
Looks like I’ll need to spend some more time testing and bisecting those
issues…

Pierre

On 06:12 am - Nov 08 2016, poma wrote:
> On 21.10.2016 10:56, Pierre Moreau wrote:
> > On 01:15 am - Oct 21 2016, Lukas Wunner wrote:
> >> On Thu, Oct 20, 2016 at 10:08:28AM +0200, Lukas Wunner wrote:
> >>> On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote:
> >>>> For example, my laptop (which also has an NVAC) has been triggering the
> >>>> no-signal message on external monitors way before Ben???s patch landed,
> >>>> but only for some adapters. I haven???t tried Ben???s patch yet, nor
> >>>> yours, but I will certainly do it, and see what effect each of them has.
> >>>
> >>> The external DP port on your MBP5,3 is switchable between GPUs and
> >>> the apple-gmux driver switches it in unison with the panel.  Thus
> >>> the NVAC cannot drive external displays when gmux is switched to
> >>> the MCP79.  (You probably were aware of this, just wanted to mention
> >>   ^
> >> I meant G96, sorry I mixed it up.
> >>
> >> Lukas
> > 
> > Yes, that bit had stayed in my memory, that switching between the two GPUs
> > would not only switch them for the laptop screen, but for the external ones 
> > as
> > well. IIRC, I am getting the no signal in both cases, but I need to retest.
> > 
> > Pierre
> 
> Any news related on your side?
> 
> 
> 


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

Re: [Nouveau] GM108GLM?

[Pierre Moreau]

Hello,

The idea was to use the modesetting DDX instead of Nouveau’s one for Maxwell+
as EXA was [broken][1]. But you can give a try at Ilia’s [patches][2], which
fix the Nouveau DDX for GM10x and GM20x (I don’t think it has been tested on a
GM108 yet).

Best regards,
Pierre Moreau

[1]: 
https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=3e2e0faa2ee1cce9c1bb5c7ad80d0592460f3edc
[2]: https://github.com/imirkin/xf86-video-nouveau/


On 11:29 am - Oct 18 2016, Sune Mølgaard wrote:
> Hi,
> 
> It would seem like it (attachments are from 4.9-rc1, btw), but it
> doesn't look like there is any support in the Xorg driver.
> 
> How can I help with that?
> 
> Best regards,
> 
> Sune Mølgaard
> Translucent ApS
> 
> On 2016-04-22 09:33, Pierre Moreau wrote:
> > Hello,
> > 
> > A patch was merged yesterday to recognise GM108 (see
> > https://github.com/skeggsb/nouveau/commit/3da1f2a19e5e8dc8d68a4400d9cca01c64ecd59e).
> > I guess it will make it into 4.7.
> > 
> > Pierre
> 

> lspci -
> 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
>   Subsystem: Lenovo Broadwell-U Host Bridge -OPI
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-  <MAbort+ >SERR-Latency: 0
>   Capabilities: 
>   Kernel driver in use: bdw_uncore
> 
> 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated 
> Graphics (rev 09) (prog-if 00 [VGA controller])
>   Subsystem: Lenovo Broadwell-U Integrated Graphics
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0
>   Interrupt: pin A routed to IRQ 49
>   Region 0: Memory at f200 (64-bit, non-prefetchable) [size=16M]
>   Region 2: Memory at c000 (64-bit, prefetchable) [size=512M]
>   Region 4: I/O ports at 4000 [size=64]
>   [virtual] Expansion ROM at 000c [disabled] [size=128K]
>   Capabilities: 
>   Kernel driver in use: i915
>   Kernel modules: i915
> 
> 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
>   Subsystem: Lenovo Broadwell-U Audio Controller
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0, Cache Line Size: 64 bytes
>   Interrupt: pin A routed to IRQ 50
>   Region 0: Memory at f423 (64-bit, non-prefetchable) [size=16K]
>   Capabilities: 
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 
> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI 
> Controller (rev 03) (prog-if 30 [XHCI])
>   Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-Latency: 0
>   Interrupt: pin A routed to IRQ 42
>   Region 0: Memory at f422 (64-bit, non-prefetchable) [size=64K]
>   Capabilities: 
>   Kernel driver in use: xhci_hcd
> 
> 00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI 
> Controller #1 (rev 03)
>   Subsystem: Lenovo Wildcat Point-LP MEI Controller
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0
>   Interrupt: pin A routed to IRQ 46
>   Region 0: Memory at f4239000 (64-bit, non-prefetchable) [size=32]
>   Capabilities: 
>   Kernel driver in use: mei_me
>   Kernel modules: mei_me
> 
> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-V 
> (rev 03)
>   Subsystem: Lenovo Ethernet Connection (3) I218-V
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0
>   Interrupt: pin A routed to IRQ 43
>   Region 0: Memory at f420 (32-bit, non-prefetchable) [size=128K]
>   Region 1: Memory at f423e000 (32-bit, non-prefetchable) [size=4K]
>   Region 2: I/O ports at 4080 [size=32]
>   Capabilities: 
>   Kernel driver in use: e1000e
>   Kernel modules: e1000e
> 
> 00:1b.0 Audio dev

Re: [Nouveau] NVAC "No Signal"

[Pierre Moreau]

On 01:15 am - Oct 21 2016, Lukas Wunner wrote:
> On Thu, Oct 20, 2016 at 10:08:28AM +0200, Lukas Wunner wrote:
> > On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote:
> > > For example, my laptop (which also has an NVAC) has been triggering the
> > > no-signal message on external monitors way before Ben???s patch landed,
> > > but only for some adapters. I haven???t tried Ben???s patch yet, nor
> > > yours, but I will certainly do it, and see what effect each of them has.
> > 
> > The external DP port on your MBP5,3 is switchable between GPUs and
> > the apple-gmux driver switches it in unison with the panel.  Thus
> > the NVAC cannot drive external displays when gmux is switched to
> > the MCP79.  (You probably were aware of this, just wanted to mention
>   ^
> I meant G96, sorry I mixed it up.
> 
> Lukas

Yes, that bit had stayed in my memory, that switching between the two GPUs
would not only switch them for the laptop screen, but for the external ones as
well. IIRC, I am getting the no signal in both cases, but I need to retest.

Pierre

> 
> > it in case you weren't.)  (In theory we could change vga_switcheroo
> > and apple-gmux to support switching the panel and the external port
> > separately rather than in unison if there is demand.  It's only
> > supported on MBPs introduced from 2008 to 2010 though, the 2011+
> > models can only drive external ports with the discrete GPU.)


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

Re: [Nouveau] NVAC "No Signal"

[Pierre Moreau]

Hello,

On 07:37 pm - Oct 19 2016, poma wrote:
> On 19.10.2016 17:03, Karol Herbst wrote:
> 
> > You don't get why I try to say. We have to actually find out when to
> > apply this workaround, not to create some silly whitelist/blacklist.
> > It's the last option, we never want to actually use.
> > 
> 
> Well if you do not say, who can understand!? :)
> Besides, you can mock with "silly" whitelist/blacklist", however there is 
> nothing wrong with the method as such, it is used practically everywhere.
> 
> > And even if we would have to create such lists, who tells us, that if
> > affects every GPU with your device id? Usually quirks are applied
> > depending on the sub-vendor-id and sub-device-id if actually required.
> > 
> > In the end we need something like this: If byte X in table Y is set in
> > the vbios or if bits A-B in reg Z in the MMIO space are set to
> > whatever, we have to apply that workaround.
> > 
> > In the end we should also wait until Ben replies, because he might
> > know the exact reasons why this workaround was actually needed.
> > 
> 
> If you eager to leave it broken even more than three months that have already 
> been passed since the original commit ...
> 
> > We might have a GPU with the same chipset like yours and we might be
> > able to verify the issue
> > 
> 
> Ah, I see.
> You do not have confidence in my test results, good to know.

Testing on another GPU with the same chipset does not mean he does not trust
your results. For example, my laptop (which also has an NVAC) has been
triggering the no-signal message on external monitors way before Ben’s patch
landed, but only for some adapters. I haven’t tried Ben’s patch yet, nor yours,
but I will certainly do it, and see what effect each of them has.

Regards,
Pierre

> 
> Oh! Carol
> 
> 
> ___
> 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

Re: [Nouveau] [PATCH] drm/nouveau: add Maxwell to backlight initialization

[Pierre Moreau]

@Ben: ping
I would guess that the same can be done for Pascal as well.

Cheers,
Pierre

On 02:41 PM - May 21 2016, Faris Alsalama wrote:
> Signed-off-by: Faris Alsalama 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 89eb460..dd1cc9b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -232,6 +232,7 @@ nouveau_backlight_init(struct drm_device *dev)
>   case NV_DEVICE_INFO_V0_TESLA:
>   case NV_DEVICE_INFO_V0_FERMI:
>   case NV_DEVICE_INFO_V0_KEPLER:
> + case NV_DEVICE_INFO_V0_MAXWELL:
>   return nv50_backlight_init(connector);
>   default:
>   break;
> -- 
> 2.1.4
> 
> ___
> 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

Re: [Nouveau] XDC2016

[Pierre Moreau]

Hello everyone,

Same place as FOSDEM? XDC is in Helsinki and FOSDEM was in Brussels… (IIRC,
FOSDEM is always located in Brussels.) I would prefer picking an hotel in
Helsinki rather than traveling every day between Helsinki and Brussels. :-p Or
was that what you meant by "more or less"? :-D

I’ve taken days off starting from Tuesday, so I could even arrive on Monday
evening if there are other persons coming that early. :-) And I am planning to
stay until Sunday (could be Sunday evening, I haven’t booked the hotel nor the
transport yet); apart from a short trip back to Sweden between Friday and
Saturday.

Cheers,
Pierre


On 09:35 PM - Aug 13 2016, karol herbst wrote:
> Hi everybody,
> 
> I saw that some more appeared on the list of Attendees, so it might be
> a good time to ask how we want to organize the stay and if we plan to
> book at the same place like we did on fosdem (well more or less).
> 
> Also how does everybody plans to stay? I was thinking about Tuesday to
> Sunday, but if everybody comes at Monday already, I might change my
> plans ;)
> 
> PS: if discussing that in public isn't the best idea, we can switch to
> off-list mails later, but I wanted to catch everybody here ;)
> ___
> 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

Re: [Nouveau] [PATCH] drm/nouveau: add Maxwell to backlight initialization

[Pierre Moreau]

Acked-by: Pierre Moreau <pierre.mor...@free.fr>

On 02:41 PM - May 21 2016, Faris Alsalama wrote:
> Signed-off-by: Faris Alsalama <farisbenbra...@gmail.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 89eb460..dd1cc9b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -232,6 +232,7 @@ nouveau_backlight_init(struct drm_device *dev)
>   case NV_DEVICE_INFO_V0_TESLA:
>   case NV_DEVICE_INFO_V0_FERMI:
>   case NV_DEVICE_INFO_V0_KEPLER:
> + case NV_DEVICE_INFO_V0_MAXWELL:
>   return nv50_backlight_init(connector);
>   default:
>   break;
> -- 
> 2.1.4
> 
> ___
> 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

Re: [Nouveau] [PATCH] gpu/nouveau/nouveau_acpi.c: Fix Type Mismatch ACPI warning

[Pierre Moreau]

Hello Marcos,

I sent a serie a year ago to fix some of the ACPI handling in Nouveau and add
runtime pm support for laptops with an Apple GMUX (see [0], and especially [1]
and [2]). I was told that a more generic work for the runtime pm was in the
work, so I let the whole serie slip away. I was thinking of resubmitting the
serie without the runtime pm additions, to at least fix those warning/error
messages. I thought I had a patch to fix this issue in my serie, but going
through it again, it looks like I did not.
Note that even, though the spec says the 4th argument should be a package, some
old BIOSes expect a different type, like a buffer (see the comment above [5]; I
think there was also a comment about it in the spec, but I can’t find it
anymore).

I added some comments below. I’ll test this patch tonight, to see how it works
on my laptop as I think it expects a buffer as 4th argument.

Thank you!

Regards,
Pierre


[0]: https://lists.freedesktop.org/archives/dri-devel/2015-May/083444.html
[1]: https://lists.freedesktop.org/archives/dri-devel/2015-May/083448.html
[2]: https://lists.freedesktop.org/archives/dri-devel/2015-May/083449.html

On 09:42 PM - May 18 2016, Marcos Paulo de Souza wrote:
> nouveau_optimus_dsm is using ACPI_TYPE_BUFFER, and this triggers warnings on 
> ACPI:
> [7.730564] ACPI: \_SB_.PCI0.RP05.PEGP: failed to evaluate _DSM
> [7.730570] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (201509
> 30/nsarguments-95)
> 
> To fix it, change ACPI_TYPE_BUFFER to ACPI_TYPE_PACKAGE, as the warning tells 
> to do.
> 
> Signed-off-by: Marcos Paulo de Souza 
> ---
> 
> After booting my Asus Laptop, and after a suspend/resume too, dmesg shows 
> warnings:
> [1.633361] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [1.633434] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [7.730176] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [7.730564] ACPI: \_SB_.PCI0.RP05.PEGP: failed to evaluate _DSM
> [7.730570] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [   49.732059] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [   49.732424] ACPI: \_SB_.PCI0.RP05.PEGP: failed to evaluate _DSM
> [   49.732430] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [   74.366300] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [   74.366657] ACPI: \_SB_.PCI0.RP05.PEGP: failed to evaluate _DSM
> [   74.33] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [  140.357789] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
> [  140.358532] ACPI: \_SB_.PCI0.RP05.PEGP: failed to evaluate _DSM
> [  140.358547] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type 
> mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)

Out of curiosity, which GPU(s) do you have in your laptop? I guess there is at
least an NVIDIA one, but is it an Optimus configuration? And if so, does the
unused card go automatically to sleep after a few seconds?

> 
> I don't know if this is the right thing to do, I just looked at intel_acpi.c 
> to check how to use/check for ACPI Package.
> The patch below silenced the "type mismatch" warnings, and some of the 
> "evaluated _DSM" ones.
> 
> If this is not the right approach, please let me know how to fix it, I don't 
> have knowledge in ACPI, but I really want to help.
> 
>  drivers/gpu/drm/nouveau/nouveau_acpi.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index cdf5227..f04aef3 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -73,22 +73,10 @@ static const char nouveau_op_dsm_muid[] = {
>  
>  static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, 
> uint32_t *result)
>  {
> - int i;
>   union acpi_object *obj;
> - char args_buff[4];
> - union acpi_object argv4 = {
> - .buffer.type = ACPI_TYPE_BUFFER,
> - .buffer.length = 4,
> - .buffer.pointer = args_buff
> - };
> -
> - /* ACPI is little 

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

[Pierre Moreau]

On 02:32 PM - May 01 2016, 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.
> 
> v2: Do not split information message on two lines as it prevents from grepping
> it, as pointed out by Hans de Goede

It should be "it, as pointed out by Lukas Wunner", sorry for the mistake… :-/

Pierre

> 
> Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
> ---
>  drm/nouveau/nouveau_backlight.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
> index 41330e4..8429ceb 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,11 @@ 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.2
> 
> ___
> 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] [PATCH v2 2/2] nouveau/bl: Do not register interface if Apple GMUX detected

[Pierre Moreau]

The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.

v2: Do not split information message on two lines as it prevents from grepping
it, as pointed out by Hans de Goede

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/nouveau_backlight.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 41330e4..8429ceb 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,11 @@ 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.2

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

Re: [Nouveau] GM108GLM?

[Pierre Moreau]

Hello,

A patch was merged yesterday to recognise GM108 (see
https://github.com/skeggsb/nouveau/commit/3da1f2a19e5e8dc8d68a4400d9cca01c64ecd59e).
I guess it will make it into 4.7.

Pierre

On 12:14 PM - Apr 18 2016, Sune Mølgaard wrote:
> Is there anything I can do in this regard?
> 
> /smo
> 
> On 2016-03-31 23:12, Pierre Moreau wrote:
> > Oh, hum, GM108 is NV118 and not NV108 which is Gk208… My bad!
> > 
> > SMF from the bug report seemed to have some working setup, and since he 
> > didn't
> > pinged back, I guess it's working nicely. But some more checking might 
> > still be
> > needed?
> > 
> > On 04:59 PM - Mar 31 2016, Ilia Mirkin wrote:
> >> Actually GM108 is not one of the recognized chips. Someone needs to go
> >> through and check that its goldens didn't change. Nobody's done that.
> >>
> >> See https://bugs.freedesktop.org/show_bug.cgi?id=89558
> >>
> >> On Thu, Mar 31, 2016 at 4:57 PM, Pierre Moreau <pierre.mor...@free.fr> 
> >> wrote:
> >>> Hello,
> >>>
> >>> Acceleration support for GM107 was merged in kernel 4.1, and modesetting
> >>> support was added to 3.15. Which kernel version did you try? The GM108 
> >>> chipset
> >>> seems to be recognised since at least 2015/08/20.
> >>>
> >>> Regards,
> >>>
> >>> Pierre Moreau
> >>>
> >>>
> >>> On 02:55 PM - Mar 29 2016, Sune Mølgaard wrote:
> >>>> Hiya,
> >>>>
> >>>> Is there any change for Quadro K620M support at some point in time, and
> >>>> what can I do to help, apart from the info below?
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Sune Mølgaard
> >>>>
> >>>> dmesg |grep -i nouveau
> >>>> [1.164919] nouveau :08:00.0: unknown chipset (1183a0a2)
> >>>> [1.164943] nouveau: probe of :08:00.0 failed with error -12
> >>>>
> >>>> lspci|grep -i nvidi
> >>>> 08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev 
> >>>> a2)
> >>>> ___
> >>>> Nouveau mailing list
> >>>> Nouveau@lists.freedesktop.org
> >>>> https://lists.freedesktop.org/mailman/listinfo/nouveau
> >>>
> >>> ___
> >>> Nouveau mailing list
> >>> Nouveau@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/nouveau
> >>>
> >> ___
> >> Nouveau mailing list
> >> Nouveau@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 
> 




> ___
> 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] [PATCH v2 1/2] nouveau/bl: Assign different names to interfaces

[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 <pierre.mor...@free.fr>
---
 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

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

[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 <pierre.mor...@free.fr>
---
 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

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

[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

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

[Pierre Moreau]

On 02:40 PM - Apr 15 2016, Nick Tenney wrote:
> On Fri, Apr 15, 2016 at 11:25 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> 
> > On Fri, Apr 15, 2016 at 11:22 AM, Pierre Moreau <pierre.mor...@free.fr>
> > wrote:
> > > On 11:06 AM - Apr 15 2016, Ilia Mirkin wrote:
> > >> On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau <pierre.mor...@free.fr>
> > wrote:
> > >> > 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.
> > >> >
> > >> > Fixes: fdo#86539
> >
>  I believe Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539 is
> the preferred format. I think this is picked up by the mesa release scripts
> or some such.

Ack’ed. I’ll fix that in the v2.

Thanks!
Pierre

> 
> > >> > Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
> > >> > ---
> > >> >  drm/nouveau/nouveau_backlight.c | 35
> > +--
> > >> >  1 file changed, 33 insertions(+), 2 deletions(-)
> > >> >
> > >> > diff --git a/drm/nouveau/nouveau_backlight.c
> > b/drm/nouveau/nouveau_backlight.c
> > >> > index 89eb460..914e2cb 100644
> > >> > --- a/drm/nouveau/nouveau_backlight.c
> > >> > +++ b/drm/nouveau/nouveau_backlight.c
> > >> > @@ -36,6 +36,10 @@
> > >> >  #include "nouveau_reg.h"
> > >> >  #include "nouveau_encoder.h"
> > >> >
> > >> > +static atomic_t bl_interfaces_nb = { 0 };
> > >>
> > >> static data is initialized to 0, this should be unnecessary.
> > >
> > > I didn’t know that. But on the other hand, I like having it explicit,
> > and it
> > > should not add any overhead.
> >
> > It increases the size of the object file. I believe it's kernel policy
> > to avoid static initializations to 0. (Note that this doesn't hold in
> > regular user applications, just the kernel.)
> >
> >   -ilia
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >

> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



signature.asc
Description: PGP signature
___
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

[Pierre Moreau]

On 11:06 AM - Apr 15 2016, Ilia Mirkin wrote:
> On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau <pierre.mor...@free.fr> wrote:
> > 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.
> >
> > Fixes: fdo#86539
> > Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
> > ---
> >  drm/nouveau/nouveau_backlight.c | 35 +--
> >  1 file changed, 33 insertions(+), 2 deletions(-)
> >
> > diff --git a/drm/nouveau/nouveau_backlight.c 
> > b/drm/nouveau/nouveau_backlight.c
> > index 89eb460..914e2cb 100644
> > --- a/drm/nouveau/nouveau_backlight.c
> > +++ b/drm/nouveau/nouveau_backlight.c
> > @@ -36,6 +36,10 @@
> >  #include "nouveau_reg.h"
> >  #include "nouveau_encoder.h"
> >
> > +static atomic_t bl_interfaces_nb = { 0 };
> 
> static data is initialized to 0, this should be unnecessary.

I didn’t know that. But on the other hand, I like having it explicit, and it
should not add any overhead.

> 
> I'd also call it "backlights" or something like that. No need for
> multiple words...

I prefer to use a plural noun when talking about a container of those nouns,
rathter than a counter of those nouns. But I’ll change it.

> 
> > +
> > +static char* nouveau_get_backlight_name(void);
> 
> Please organize the code to avoid forward declarations.
> 
> > +
> >  static int
> >  nv40_get_intensity(struct backlight_device *bd)
> >  {
> > @@ -74,6 +78,7 @@ nv40_backlight_init(struct drm_connector *connector)
> > struct nvif_object *device = >device.object;
> > struct backlight_properties props;
> > struct backlight_device *bd;
> > +   char* backlight_name = NULL;
> >
> > if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & 
> > NV40_PMC_BACKLIGHT_MASK))
> > return 0;
> > @@ -81,8 +86,14 @@ 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,
> > +   backlight_name = nouveau_get_backlight_name();
> > +   bd = backlight_device_register(backlight_name , connector->kdev, 
> > drm,
> >_bl_ops, );
> > +
> > +   // backlight_device_register() makes a copy
> > +   kfree(backlight_name);
> > +   backlight_name = NULL;
> > +
> > if (IS_ERR(bd))
> > return PTR_ERR(bd);
> > drm->backlight = bd;
> > @@ -182,6 +193,7 @@ nv50_backlight_init(struct drm_connector *connector)
> > struct backlight_properties props;
> > struct backlight_device *bd;
> > const struct backlight_ops *ops;
> > +   char* backlight_name = NULL;
> >
> > nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
> > if (!nv_encoder) {
> > @@ -203,8 +215,14 @@ 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,
> > +   backlight_name = nouveau_get_backlight_name();
> > +   bd = backlight_device_register(backlight_name, connector->kdev,
> >nv_encoder, ops, );
> > +
> > +   // backlight_device_register() makes a copy
> > +   kfree(backlight_name);
> > +   backlight_name = NULL;
> > +
> > if (IS_ERR(bd))
> > return PTR_ERR(bd);
> >
> > @@ -252,3 +270,16 @@ nouveau_backlight_exit(struct drm_device *dev)
> > drm->backlight = NULL;
> > }
> >  }
> > +
> > +static char*
> > +nouveau_get_backlight_name(void)
> > +{
> > +   // 12 chars for "nv_backlight" + 2 for two digits number + 1 for 
> > '\0'
> > +   char* backlight_name = (char*)kmalloc(sizeof(char[15]), GFP_KERNEL);
> 
> Making this stack-allocated in the caller would be so much simpler...

--" I 

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

[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 <pierre.mor...@free.fr>
---
 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 914e2cb..37a1577 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 "nouveau_drm.h"
@@ -239,6 +240,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;
+   }
+
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)
-- 
2.8.0

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

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

[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.

Fixes: fdo#86539
Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/nouveau_backlight.c | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 89eb460..914e2cb 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -36,6 +36,10 @@
 #include "nouveau_reg.h"
 #include "nouveau_encoder.h"
 
+static atomic_t bl_interfaces_nb = { 0 };
+
+static char* nouveau_get_backlight_name(void);
+
 static int
 nv40_get_intensity(struct backlight_device *bd)
 {
@@ -74,6 +78,7 @@ nv40_backlight_init(struct drm_connector *connector)
struct nvif_object *device = >device.object;
struct backlight_properties props;
struct backlight_device *bd;
+   char* backlight_name = NULL;
 
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return 0;
@@ -81,8 +86,14 @@ 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,
+   backlight_name = nouveau_get_backlight_name();
+   bd = backlight_device_register(backlight_name , connector->kdev, drm,
   _bl_ops, );
+
+   // backlight_device_register() makes a copy
+   kfree(backlight_name);
+   backlight_name = NULL;
+
if (IS_ERR(bd))
return PTR_ERR(bd);
drm->backlight = bd;
@@ -182,6 +193,7 @@ nv50_backlight_init(struct drm_connector *connector)
struct backlight_properties props;
struct backlight_device *bd;
const struct backlight_ops *ops;
+   char* backlight_name = NULL;
 
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -203,8 +215,14 @@ 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,
+   backlight_name = nouveau_get_backlight_name();
+   bd = backlight_device_register(backlight_name, connector->kdev,
   nv_encoder, ops, );
+
+   // backlight_device_register() makes a copy
+   kfree(backlight_name);
+   backlight_name = NULL;
+
if (IS_ERR(bd))
return PTR_ERR(bd);
 
@@ -252,3 +270,16 @@ nouveau_backlight_exit(struct drm_device *dev)
drm->backlight = NULL;
}
 }
+
+static char*
+nouveau_get_backlight_name(void)
+{
+   // 12 chars for "nv_backlight" + 2 for two digits number + 1 for '\0'
+   char* backlight_name = (char*)kmalloc(sizeof(char[15]), GFP_KERNEL);
+   const int nb = atomic_inc_return(_interfaces_nb) - 1;
+   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

Re: [Nouveau] GM108GLM?

[Pierre Moreau]

Oh, hum, GM108 is NV118 and not NV108 which is Gk208… My bad!

SMF from the bug report seemed to have some working setup, and since he didn't
pinged back, I guess it's working nicely. But some more checking might still be
needed?

On 04:59 PM - Mar 31 2016, Ilia Mirkin wrote:
> Actually GM108 is not one of the recognized chips. Someone needs to go
> through and check that its goldens didn't change. Nobody's done that.
> 
> See https://bugs.freedesktop.org/show_bug.cgi?id=89558
> 
> On Thu, Mar 31, 2016 at 4:57 PM, Pierre Moreau <pierre.mor...@free.fr> wrote:
> > Hello,
> >
> > Acceleration support for GM107 was merged in kernel 4.1, and modesetting
> > support was added to 3.15. Which kernel version did you try? The GM108 
> > chipset
> > seems to be recognised since at least 2015/08/20.
> >
> > Regards,
> >
> > Pierre Moreau
> >
> >
> > On 02:55 PM - Mar 29 2016, Sune Mølgaard wrote:
> >> Hiya,
> >>
> >> Is there any change for Quadro K620M support at some point in time, and
> >> what can I do to help, apart from the info below?
> >>
> >> Best regards,
> >>
> >> Sune Mølgaard
> >>
> >> dmesg |grep -i nouveau
> >> [1.164919] nouveau :08:00.0: unknown chipset (1183a0a2)
> >> [1.164943] nouveau: probe of :08:00.0 failed with error -12
> >>
> >> lspci|grep -i nvidi
> >> 08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev a2)
> >> ___
> >> Nouveau mailing list
> >> Nouveau@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
> ___
> 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

Re: [Nouveau] GM108GLM?

[Pierre Moreau]

Hello,

Acceleration support for GM107 was merged in kernel 4.1, and modesetting
support was added to 3.15. Which kernel version did you try? The GM108 chipset
seems to be recognised since at least 2015/08/20.

Regards,

Pierre Moreau


On 02:55 PM - Mar 29 2016, Sune Mølgaard wrote:
> Hiya,
> 
> Is there any change for Quadro K620M support at some point in time, and
> what can I do to help, apart from the info below?
> 
> Best regards,
> 
> Sune Mølgaard
> 
> dmesg |grep -i nouveau
> [1.164919] nouveau :08:00.0: unknown chipset (1183a0a2)
> [1.164943] nouveau: probe of :08:00.0 failed with error -12
> 
> lspci|grep -i nvidi
> 08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev a2)
> ___
> 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

Re: [Nouveau] [Mesa-dev] [PATCH mesa 3/3] nouveau: Add support for clover / OpenCL kernel input parameters

[Pierre Moreau]

On 11:05 AM - Mar 10 2016, Ilia Mirkin wrote:
> On Thu, Mar 10, 2016 at 11:03 AM, Pierre Moreau <pierre.mor...@free.fr> wrote:
> > You might want to increment the address by at least
> > `info->prop.cp.inputOffset`, and if inputs still end up in shared on Tesla,
> 
> There's a cp.sharedOffset just for that :) However it doesn't appear
> to get set anywhere...

Oh really?! I completely missed that one… Well, I have some changes to make on
my own code then! :-D Thanks for pointing that out!

Pierre


> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Nouveau] [PATCH mesa 3/3] nouveau: Add support for clover / OpenCL kernel input parameters

[Pierre Moreau]

On 04:27 PM - Mar 10 2016, Samuel Pitoiset wrote:
> 
> 
> On 03/10/2016 04:23 PM, Ilia Mirkin wrote:
> >On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede  wrote:
> >>Add support for clover / OpenCL kernel input parameters.
> >>
> >>Signed-off-by: Hans de Goede 
> >>---
> >>  .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 18 
> >> +++---
> >>  1 file changed, 15 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
> >>b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> >>index a8258af..de0c72b 100644
> >>--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> >>+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> >>@@ -1523,9 +1523,21 @@ Converter::makeSym(uint tgsiFile, int fileIdx, int 
> >>idx, int c, uint32_t address)
> >>
> >> sym->reg.fileIndex = fileIdx;
> >>
> >>-   if (tgsiFile == TGSI_FILE_MEMORY &&
> >>-   code->memoryFiles[fileIdx].mem_type == TGSI_MEMORY_TYPE_SHARED)
> >>-  sym->setFile(FILE_MEMORY_SHARED);
> >>+   if (tgsiFile == TGSI_FILE_MEMORY) {
> >>+  switch (code->memoryFiles[fileIdx].mem_type) {
> >>+  case TGSI_MEMORY_TYPE_SHARED:
> >>+ sym->setFile(FILE_MEMORY_SHARED);

You might want to increment the address by at least
`info->prop.cp.inputOffset`, and if inputs still end up in shared on Tesla,
then increment further by the input size. This input offset of 0x10 (or is it
0x20?) is due to the card sticking the size of a block and of the grid inside
`s[0x0..0x10]` (or maybe Nouveau is doing that, but I doubt it.). So even if
the user inputs end up somewhere else in memory, you most likely still don't
want to overwrite the grid information. This should be necessary only for Tesla
cards.

> >>+ break;
> >>+  case TGSI_MEMORY_TYPE_INPUT:
> >>+ assert(prog->getType() == Program::TYPE_COMPUTE);
> >>+ assert(idx == -1);
> >>+ sym->setFile(FILE_SHADER_INPUT);
> >>+ address += info->prop.cp.inputOffset;
> >
> >What's the idea here? i.e. what is the inputOffset, how is it set, and why?
> 
> I don't get the idea too, btw.
> 
> But prop.cp.inputOffset is only defined for compute on Kepler. It's the
> offset of input parameters in the screen->parm BO but as you already know,
> it is going to be removed because the idea is to use screen->uniform_bo
> instead. I'll do this change *after* the compute shaders support on Kepler.

If I understand correctly, the goal is to have user inputs in a
`screen->uniform_bo`, and so for all generations?

Pierre


> 
> >
> >   -ilia
> >
> >>+ break;
> >>+  default:
> >>+ assert(0); /* TODO: Add support for global and local memory */
> >>+  }
> >>+   }
> >>
> >> if (idx >= 0) {
> >>if (sym->reg.file == FILE_SHADER_INPUT)
> >>--
> >>2.7.2
> >>
> 
> -- 
> -Samuel
> ___
> 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

Re: [Nouveau] RFC: [PATCH] x86/kmmio: fix mmiotrace for hugepages

[Pierre Moreau]

The secondary hit exception thrown while MMIOtracing NVIDIA's driver is gone
with this patch.

Tested-by: Pierre Moreau <pierre.mor...@free.fr>

On 02:03 AM - Mar 03 2016, Karol Herbst wrote:
> Because Linux might use bigger pages than the 4K pages to handle those mmio
> ioremaps, the kmmio code shouldn't rely on the pade id as it currently does.
> 
> Using the memory address instead of the page id let's us lookup how big the
> page is and what it's base address is, so that we won't get a page fault
> within the same page twice anymore.
> 
> I don't know if I got this right though, so please read this change with
> great care
> 
> v2: use page_level macros
> 
> Signed-off-by: Karol Herbst <nouv...@karolherbst.de>
> ---
>  arch/x86/mm/kmmio.c | 89 
> -
>  1 file changed, 60 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
> index 637ab34..d203beb 100644
> --- a/arch/x86/mm/kmmio.c
> +++ b/arch/x86/mm/kmmio.c
> @@ -33,7 +33,7 @@
>  struct kmmio_fault_page {
>   struct list_head list;
>   struct kmmio_fault_page *release_next;
> - unsigned long page; /* location of the fault page */
> + unsigned long addr; /* the requested address */
>   pteval_t old_presence; /* page presence prior to arming */
>   bool armed;
>  
> @@ -70,9 +70,16 @@ unsigned int kmmio_count;
>  static struct list_head kmmio_page_table[KMMIO_PAGE_TABLE_SIZE];
>  static LIST_HEAD(kmmio_probes);
>  
> -static struct list_head *kmmio_page_list(unsigned long page)
> +static struct list_head *kmmio_page_list(unsigned long addr)
>  {
> - return _page_table[hash_long(page, KMMIO_PAGE_HASH_BITS)];
> + unsigned int l;
> + pte_t *pte = lookup_address(addr, );
> +
> + if (!pte)
> + return NULL;
> + addr &= page_level_mask(l);
> +
> + return _page_table[hash_long(addr, KMMIO_PAGE_HASH_BITS)];
>  }
>  
>  /* Accessed per-cpu */
> @@ -98,15 +105,19 @@ static struct kmmio_probe *get_kmmio_probe(unsigned long 
> addr)
>  }
>  
>  /* You must be holding RCU read lock. */
> -static struct kmmio_fault_page *get_kmmio_fault_page(unsigned long page)
> +static struct kmmio_fault_page *get_kmmio_fault_page(unsigned long addr)
>  {
>   struct list_head *head;
>   struct kmmio_fault_page *f;
> + unsigned int l;
> + pte_t *pte = lookup_address(addr, );
>  
> - page &= PAGE_MASK;
> - head = kmmio_page_list(page);
> + if (!pte)
> + return NULL;
> + addr &= page_level_mask(l);
> + head = kmmio_page_list(addr);
>   list_for_each_entry_rcu(f, head, list) {
> - if (f->page == page)
> + if (f->addr == addr)
>   return f;
>   }
>   return NULL;
> @@ -137,10 +148,10 @@ static void clear_pte_presence(pte_t *pte, bool clear, 
> pteval_t *old)
>  static int clear_page_presence(struct kmmio_fault_page *f, bool clear)
>  {
>   unsigned int level;
> - pte_t *pte = lookup_address(f->page, );
> + pte_t *pte = lookup_address(f->addr, );
>  
>   if (!pte) {
> - pr_err("no pte for page 0x%08lx\n", f->page);
> + pr_err("no pte for addr 0x%08lx\n", f->addr);
>   return -1;
>   }
>  
> @@ -156,7 +167,7 @@ static int clear_page_presence(struct kmmio_fault_page 
> *f, bool clear)
>   return -1;
>   }
>  
> - __flush_tlb_one(f->page);
> + __flush_tlb_one(f->addr);
>   return 0;
>  }
>  
> @@ -176,12 +187,12 @@ static int arm_kmmio_fault_page(struct kmmio_fault_page 
> *f)
>   int ret;
>   WARN_ONCE(f->armed, KERN_ERR pr_fmt("kmmio page already armed.\n"));
>   if (f->armed) {
> - pr_warning("double-arm: page 0x%08lx, ref %d, old %d\n",
> -f->page, f->count, !!f->old_presence);
> + pr_warning("double-arm: addr 0x%08lx, ref %d, old %d\n",
> +f->addr, f->count, !!f->old_presence);
>   }
>   ret = clear_page_presence(f, true);
> - WARN_ONCE(ret < 0, KERN_ERR pr_fmt("arming 0x%08lx failed.\n"),
> -   f->page);
> + WARN_ONCE(ret < 0, KERN_ERR pr_fmt("arming at 0x%08lx failed.\n"),
> +   f->addr);
>   f->armed = true;
>   return ret;
>  }
> @@ -191,7 +202,7 @@ static void disarm_kmmio_fault_page(struct 
> kmmio_fault_page *f)
>  {
>   int ret = clear_page_presence(f, false);
>   WARN_ONCE(ret < 0,

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

[Pierre Moreau]

On 11:43 AM - Feb 23 2016, Hans de Goede wrote:
> Hi,
> 

[snip]

> 
> >You may have to add LOAD64/STORE64 for 64-bit
> >addresses though. Or we could decree that all addressing on global
> >memory shall be 64-bit (and thus read the .xy components of the
> >address source).
> 
> I would prefer to keep LOAD / STORE semantics the same as with
> other LOAD / STORE -s to / from 1d buffers.
> 
> I think that in the end the tgsi backend for llvm will get both
> a 32 bit and a 64 bit mode, like the nvptx backend already has.
> 
> And then the 64 bit backend will use a new LOAD64 / STORE64
> also do not forget that keeping 64 bit pointers takes twice as
> much registers, so 32 bit will likely be optimal in a lot of
> cases. I guess since OpenCL does not give the user a way
> to select which mode to use we will end up with some sort
> of heuristic based on the amount of memory on the card or
> some such.
> 
> After all using 64 bit pointers does not make a lot of sense
> on a card with only 1 GB of RAM (yes I know we're talking virtual
> address space here).
> 
> Anyways this all really is too soon to tell. Maybe the performance
> impact of using 64 bit pointers is negligible. But I think it would
> be good (and consistent) to keep LOAD / STORE taking 32 bit addresses
> even for MEMORY and add a LOAD64 / STORE64 when I get around to
> implementing a 64 bit mode for the llvm tgsi backend (or when others
> need them).
> 
> >>>Another way of looking at it is that instead of having the hacky
> >>>RES[12345] being hardcoded to mean something special, you now have a
> >>>dedicated file called 'MEMORY', which has identical semantics.
> >>
> >>
> >>I'm all for getting rid of the RES[12345] hack :)
> >>
> >>I guess where you write "you now have a dedicated file called 'MEMORY'"
> >>You mean up to X dedicated MEMORY[#] files, one for each of GLOBAL, SHARED
> >>and LOCAL at least, and probably as discussed one for INPUT ?
> >>
> >>This all sounds good to me, as said my worry was that MEMORY would have
> >>an implied base address like BUFFER has, now that you've
> >>made clear that MEMORY does not have this I'm happy :)
> >
> >There's a bit of a wrinkle here, and it's questionable whether we want
> >to allow for this somehow, but... Tesla actually has no way to address
> >global memory. It's always done with a base offset (which can be set
> >to 0). The trick is that it can only address 32 bits at a time,
> >there's no 64-bit addressing. But it has *16* such "global" memory
> >spaces, i.e. which are each base + up to 32-bit offset [and ultimately
> >only 40 bits of addressability]. I don't know if OpenCL provides
> >something good for that, if it does we can use semantic indices on the
> >GLOBAL to make it like
> >
> >DCL MEMORY[0], GLOBAL[0]
> >DCL MEMORY[1], GLOBAL[1]
> >
> >etc. But again, this is pretty optional.
> 
> I think that for Tesla we can just only support the tgsi32 target
> and not the tgsi64 target, at least that is how I envision things
> today, who knows what tomorrow will bring :)

Fermi is the first family supporting 64 bit addresses, on top of 32 bit
addresses, while Kepler can only do 64 bit IIRC (or is it Maxwell which dropped
the 32 bit support?).

Regards,
Pierre

> 
> Regards,
> 
> Hans
> ___
> 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

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

[Pierre Moreau]

- Mail original -
> On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede 
> wrote:
> >> But assuming I'm right, what I'm proposing is that instead of
> >> passing
> >> the input in as a global buffer, to instead pass it in as a const
> >> buffer. As such instead of sticking it into ->set_global_binding,
> >> you'd stick it into ->set_constant_buffer, and then you'll be able
> >> to
> >> refer to it as CONST[0], CONST[1], etc. (Which are, implicitly,
> >> CONST[0][0], CONST[0][1], etc -- it doesn't print the second dim
> >> when
> >> it's 0.) You don't even have to load these, you can use them as
> >> args
> >> directly anywhere you like (except as indirect addresses).
> >>
> >> The old code would actually take the supplied inputs, stick them
> >> into
> >> a constbuf, and then lower RINPUT accesses to load from that
> >> constbuf.
> >> I'm suggesting we cut out the middleman.
> >>
> >> By the way, another term for "constant buffer" is "uniform
> >> buffer", on
> >> the off chance it helps. Basically it's super-cached by the shader
> >> for
> >> values that never change across shader invocations. [And there's
> >> special stuff in the hw to allow running multiple sets of shader
> >> invocations with different "constant" values... or so we think.]
> >
> >
> > I'm fine with using constant buffers for the input, it is not the
> > mechanism I'm worried about it is the tgsi syntax to express
> > things,
> > I think it would be beneficial for the tgsi syntax to be abstract,
> > and
> > not worry about the underlying mechanism, this will i.e. allow us
> > to use shared memory for input on tesla and const bufs on later
> > generations
> > without the part generating the tgsi code needing to worry about
> > this.
> 
> Yeah, I think you're right. I didn't realize that tesla had a special
> form of input for user params, I assumed it was just the usual thing.
> So forget about constbufs, go with the INPUT thing. Which is great,
> since we had one value left over in that (future) 2-bit field :)

I can have a try at using constbufs for user inputs on Tesla. It's just
that the blob was using shared for them, so we kept shared.

Pierre

> 
> >
> > ###
> >
> > Somewhat unrelated to the input problem, I'm also somewhat worried
> > about the addressing method for MEMORY type registers.
> >
> > Looking at the old RES stuff then the "index" passed into say a
> > LOAD
> > was not as much an index as it was simply a 32 bit GPU virtual
> > memory
> > address, which fits well with the OpenCL ways of doing things (the
> > register number as in the 55 in RES[55] was more or less ignored).
> >
> > Where as, e.g. the new BUFFER style "registers" the index really
> > is an index, e.g. doing:
> > LOAD TEMP[0].x, BUFFER[0], IMM[0]
> > resp.
> > LOAD TEMP[0].x, BUFFER[1], IMM[0]
> >
> > Will read from a different memory address, correct ?
> 
> Correct -- BUFFER[0] refers to the buffer at binding point 0, and
> BUFFER[1] refers to the buffer at binding point 1. They might, in
> fact, overlap, or even be the same buffer. But the code doesn't know
> about that.
> 
> >
> > So how will this work for MEMORY type registers ? For OpenCL having
> > the
> > 1-dimensional behavior of RES really is quite useful, and having
> > the
> > address be composed of a hidden base address which gets determined
> > under
> > the hood from the register number, and then adding an index on top
> > of
> > it does not fit so well.
> 
> Not sure what the question is... you have code like
> 
> int *foo = [pointer value from user input];
> *foo = *(foo + 5);
> 
> right?
> 
> So that'd just become
> 
> MOV TEMP[0].x, 
> ADD TEMP[0].y, TEMP[0].x, 5 * 4
> LOAD TEMP[1].x, MEMORY[0] (which is global), TEMP[0].y
> STORE MEMORY[0], TEMP[0].x, TEMP[1].x
> 
> or perhaps I'm misunderstanding something?
> 
> MEMORY, GLOBAL == the global virtual memory address space, not some
> specific buffer. Trying to load address 0 from it will likely lead to
> sadness, unless you happen to have something mapped there. BUFFER has
> an implied base address, based on the binding point, but MEMORY has
> no
> such thing.
> 
>   -ilia
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

[Pierre Moreau]

Hello,

> On 22 Feb 2016, at 15:22, Ilia Mirkin  wrote:
> 
>> On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede  wrote:
>> Hi,
>> 
>>> On 22-02-16 14:47, Ilia Mirkin wrote:
>>> 
 On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin  wrote:
 
 INPUT is for shader inputs which come from fixed function loaders.
 This is not what you want. You want CONST. Stick the input params into
 a constbuf, and you're done.
>>> 
>>> 
>>> Oh, and in case it's not clear, I think this should be done by the st,
>>> not by the driver. Not a big fan of the current interface where the
>>> driver is responsible for uploading the kernel input parameters.
>> 
>> 
>> Moving this to the state-tracker will likely break clover for amd
>> cards, also what is the right place to stick the input params my
> 
> Not really. Could just have a PIPE_CAP. Could make it part of the
> whole TGSI logic in the first place. This functionality isn't used for
> the OpenGL compute shader, and it'd be nice to bring OpenCL in line
> with the OpenGL stuff.
> 
>> differ from one gpu to the other, also the opencl -> tgsi compiler
>> will need to know how to "address" input params without it needing to
>> know too much details of the targetted gpu. So of INPUT is not suitable,
>> then I think we are going to need MEMORY[#], INPUT for this, which
>> nouveau can then just treat as CONST.
> 
> That doesn't make sense... MEMORY is for... memory. Perhaps there's
> something I don't understand about kernel inputs that would make my
> suggestion unworkable? The way I see it is that you stick them into a
> user constbuf (i.e. pipe->set_constant_buffer({cb.user = pointer to
> your thing})), and then launch the grid. Your TGSI would have been
> composed such that it would expect the user params to show up in the
> first constbuf.

Apart from Tesla which uses shared memory for passing the OpenCL user params, 
Fermi+ use const memory for that, and this is what Samuel's patches are doing 
(at least from what I remember). 

Regards,
Pierre

> 
> You *really* want to be using constbufs here -- they're designed for this.
> 
>  -ilia
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

[Pierre Moreau]

Hello all,

> On 01 Feb 2016, at 23:49, Lukas Wunner <lu...@wunner.de> wrote:
> 
> Hi,
> 
>> On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote:
>> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.
> 
> This series hasn't seen any reviews or acks unfortunately.
> Any takers?
> 
> Merging this would allow fdo #61115 to be closed
> (currently assigned to intel-gfx).
> 
> FWIW this series has in the meantime been tested by more folks:
> 
> Tested-by: Pierre Moreau <pierre.mor...@free.fr>
>[MBP  5,3 2009  nvidia MCP79 + G96pre-retina  15"]
> Tested-by: Paul Hordiienko <pvt.g...@gmail.com>
>[MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina  15"]
> Tested-by: William Brown <will...@blackhats.net.au>
>[MBP  8,2 2011  intel SNB + amd turks pre-retina  15"]
> Tested-by: Lukas Wunner <lu...@wunner.de>
>[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
> 
> On the latter three models it worked fine. On Pierre Moreau's machine
> the discrete nvidia G96 locks up when woken. This happened in the past
> as well but not on the first wake but only on the 10th or so. Since it
> works fine on the GT216 and GK107, I'm guessing we've got a regression
> in the wakeup code for the G96 which is somehow triggered by this patch
> set (more specifically: triggered by being able to retrieve the proper
> panel resolution and configure a crtc). It needs to be fixed but isn't
> a showstopper for this series IMHO. (Arguably being able to retrieve
> EDID but then locking up on switching isn't really worse than not being
> able to retrieve EDID in the first place.)

I would say it is slightly worse, since the only "downside" of not retrieving 
the EDID means  TTY is set to a default resolution rather than the screen 
resolution, but this is fixed when starting X.
On the other hand, since DRI_PRIME works fine on the laptop, there isn't much 
reason to switch between cards. 

I'll have a look at the resume this week, now that FOSDEM is off my todo list. 

Regards,
Pierre


> 
> Thanks,
> 
> Lukas
> 
>> 
>> The main obstacle on these machines is that the panel mode in VBIOS
>> is bogus. Fortunately gmux can switch DDC independently from the
>> display, thereby allowing the inactive GPU to probe the panel's EDID.
>> 
>> In short, vga_switcheroo and apple-gmux are amended with hooks to
>> switch DDC, DRM core is amended with a drm_get_edid_switcheroo() helper,
>> and relevant drivers are amended to call that for LVDS outputs.
>> 
>> The retina MacBook Pro (2012 - present) uses eDP and cannot switch
>> AUX independently from the main link. The main obstacle there is link
>> training, I'm currently working on this, it will be addressed in a
>> future patch set.
>> 
>> This series is also reviewable on GitHub:
>> https://github.com/l1k/linux/commits/mbp_switcheroo_v5
>> 
>> Changes:
>> 
>> * New patch [01/12]: vga_switcheroo handler flags
>>  Alex Deucher asked if this series might regress on non-Apple laptops.
>>  To address this concern, I let handlers declare their capabilities in
>>  a bitmask. DRM drivers call drm_get_edid_switcheroo() only if the
>>  handler has set the VGA_SWITCHEROO_CAN_SWITCH_DDC flag.
>>  Currently just one other flag is defined which is used on retinas.
>> 
>> * Changed patch [02/12]: vga_switcheroo DDC locking
>>  Rename ddc_lock to mux_hw_lock, suggested by Daniel Vetter.
>> 
>> * New patch [03/12]: track switch state of apple-gmux
>>  Fixes a bug in previous versions of this series which occurred if
>>  the system was suspended while DDC was temporarily switched:
>>  On resume DDC was switched to the wrong GPU.
>> 
>> * New patches [09/12 - 12/12]: deferred probing
>>  Previously I used connector reprobing if the inactive GPU's driver
>>  loaded before gmux. I've ditched that in favor of deferred driver
>>  probing, which is much simpler. Thanks to Daniel Vetter for the
>>  suggestion.
>> 
>> Caution: Patch [09/12] depends on a new acpi_dev_present() API which
>> will land in 4.5 via Rafael J. Wysocki's tree.
>> 
>> I would particularly be interested in feedback on the handler flags
>> patch [01/12]. I'm not 100% happy with the number of characters
>> required to query the flags (e.g.: if (vga_switcheroo_handler_flags() &
>> VGA_SWITCHEROO_CAN_SWITCH_DDC)), but failed to come up with something
>> shorter. Thierry Reding used a struct of bools instead of a bitmask
>> for his recent drm_dp_link_caps patches. Maybe use that instead?
>> http://lists.freedesktop.org/arch

Re: [Nouveau] nouveau contributor dinner Friday evening before FOSDEM?

[Pierre Moreau]

Hello,

By the way, at what time should we meet at the restaurant? O:-)

See you later!
Pierre


On 11:51 AM - Jan 28 2016, Hans de Goede wrote:
> Hi,
> 
> On 28-01-16 11:48, Emil Velikov wrote:
> >Hi Hans,
> >
> >On 28 January 2016 at 12:31, Hans de Goede <hdego...@redhat.com> wrote:
> >>Hi All,
> >>
> >>On 21-01-16 14:09, Hans de Goede wrote:
> >>>
> >>>Hi All,
> >>>
> >>>$subject says it pretty much all. AFAIk quite a few
> >>>nouveau contributors are coming to Fosdem, and I think it
> >>>would be nice to have dinner together Friday evening
> >>>before FOSDEM.
> >>>
> >>>So any takers? If you want to join please reply to this
> >>>mail thread before coming Thursday, I will try to reserve a table at:
> >>>
> >>>
> >>>http://www.tripadvisor.com/Restaurant_Review-g188644-d802232-Reviews-Le_Falstaff-Brussels.html
> >>>
> >>>Which is not as bad as the reviews there make it out to be,
> >>>note I'm open to better suggestions, esp. from locals, Le Falstaff
> >>>is sort of my fallback place to go to in Brussels.
> >>
> >>
> >>Ok, I've received confirmations from the following people:
> >>
> >>Hans de Goede
> >>Pierre Moreau
> >>Karol Herbst
> >>Roy Spliet
> >>Martin Peres
> >>
> >>So I've gone ahead and reserved a table for 6 at:
> >>
> >>Le Falstaff
> >>Rue Henri Maus 19 / Henri Mausstraat 19
> >>1000 Brussels
> >>
> >>Note this on the "La Bourse" square, which is quite near the Grand Place.
> >>
> >>If anyone else wants to join please let me know then I'll let the restaurant
> >>know that we will be with more beforehand.
> >>
> >Was meant to shout earlier - I'd like you join you guys :-)
> 
> No problem, see you there!
> 
> Regards,
> 
> Hans
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau


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

Re: [Nouveau] nouveau contributor dinner Friday evening before FOSDEM?

[Pierre Moreau]

Hello everyone,

I'm in for the dinner! As for the restaurant, since I never went to Brussels,
I'll follow the group's decision. Some time around 19:30–20:00? Most of us
should be in Brussels' centre by then I think.

Cheers,
Pierre


On 02:09 PM - Jan 21 2016, Hans de Goede wrote:
> Hi All,
> 
> $subject says it pretty much all. AFAIk quite a few
> nouveau contributors are coming to Fosdem, and I think it
> would be nice to have dinner together Friday evening
> before FOSDEM.
> 
> So any takers? If you want to join please reply to this
> mail thread before coming Thursday, I will try to reserve a table at:
> 
> http://www.tripadvisor.com/Restaurant_Review-g188644-d802232-Reviews-Le_Falstaff-Brussels.html
> 
> Which is not as bad as the reviews there make it out to be,
> note I'm open to better suggestions, esp. from locals, Le Falstaff
> is sort of my fallback place to go to in Brussels.
> 
> Regards,
> 
> Hans
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC PATCH v2 0/7] stabilize kepler reclocking

[Pierre Moreau]

Hello,

Maybe my e-mail client is messing with me, but I couldn't find any dmesg output
attached to your e-mail. Could you please try to attach it again?

By the way, since you have a Kepler, you should try booting with
"nouveau.War00C800_0=1". That workaround is enabled by default in 4.4-rc5
(IIRC), but that might not be the case on Karol's branch.

Best regards,
Pierre

On 08:18 AM - Dec 25 2015, Thomas Martitz wrote:
> Hello,
> 
> following up on myself, it was suggested on IRC that I better attach a dmesg
> output. Here's the output of a clean boot & echo 0f > /sys/.../pstate cycle.
> 
> I can't spot a message that relates to the reclock action, and there's only
> one weird "nouveau :04:00.0: clk: base: 7 MHz, boost: 7 MHz" message.
> 
> On the other hand:
> # cat /sys/bus/pci/devices/:04:00.0/pstate
> 07: core 324 MHz memory 648 MHz
> 0a: core 549 MHz memory 1620 MHz
> 0f: core 1032 MHz memory 5400 MHz AC DC *
> DC: core 1032 MHz memory 5400 MHz
> 
> One additional data point: In a gnome3 session it can lock up even without
> starting a game, just by entering the gnome menu (I think the gnome desktop
> is hardware accelerated).
> 
> Hope that helps.
> 
> Best regards
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC PATCH 4/5] subdev/clk: print the base clocks

[Pierre Moreau]

Hi,

On 05:42 PM - Dec 01 2015, Karol Herbst wrote:
> this is just a nice thing to know and there is no harm in printing them
> ---
>  drm/nouveau/nvkm/subdev/clk/base.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index d731bc3..df9173e 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -24,6 +24,7 @@
>  #include "priv.h"
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -562,10 +563,25 @@ int
>  nvkm_clk_ctor(const struct nvkm_clk_func *func, struct nvkm_device *device,
> int index, bool allow_reclock, struct nvkm_clk *clk)
>  {
> + struct nvkm_bios *bios;
>   int ret, idx, arglen;
>   const char *mode;
> + struct nvbios_baseclock_header header;
>  
>   nvkm_subdev_ctor(_clk, device, index, 0, >subdev);
> + bios = device->bios;
> +
> + if (bios && !nvbios_baseclock_parse(bios, )) {
> + struct nvbios_baseclock_entry base_entry, boost_entry;
> + if (nvbios_baseclock_get_entry(bios, , 
> header.base_entry, _entry))
> + nvkm_error(>subdev, "couldn't parse base clock\n");
> + else if (nvbios_baseclock_get_entry(bios, , 
> header.boost_entry, _entry))
> + nvkm_error(>subdev, "couldn't parse boost 
> clock\n");
> + else
> + nvkm_info(>subdev, "base: %i MHz, boost: %i MHz\n",
> + base_entry.clock_mhz / 2, boost_entry.clock_mhz 
> / 2);

This is probably just me missing some elementary electronic knowledge about
clocks, but why do you divide the clock frequency by two?

Regards,
Pierre

> + }
> +
>   clk->func = func;
>   INIT_LIST_HEAD(>states);
>   clk->domains = func->domains;
> -- 
> 2.6.3
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC PATCH 5/5] clk: allow boosting only when NvBoost is set

[Pierre Moreau]

Hi Karol,

I have some comments below.

On 05:42 PM - Dec 01 2015, Karol Herbst wrote:
> 0: disable boosting (cap to base clock from the vbios)
> 1: boost only to boost clock from the vbios
> 2: boost to max clock available
> ---
>  drm/nouveau/include/nvkm/subdev/clk.h | 10 +-
>  drm/nouveau/nvkm/subdev/clk/base.c| 17 -
>  drm/nouveau/nvkm/subdev/clk/gf100.c   |  2 +-
>  drm/nouveau/nvkm/subdev/clk/gk104.c   |  2 +-
>  4 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/clk.h 
> b/drm/nouveau/include/nvkm/subdev/clk.h
> index 8708f0a..8085d81 100644
> --- a/drm/nouveau/include/nvkm/subdev/clk.h
> +++ b/drm/nouveau/include/nvkm/subdev/clk.h
> @@ -64,7 +64,8 @@ struct nvkm_pstate {
>  struct nvkm_domain {
>   enum nv_clk_src name;
>   u8 bios; /* 0xff for none */
> -#define NVKM_CLK_DOM_FLAG_CORE 0x01
> +#define NVKM_CLK_DOM_FLAG_CORE0x01
> +#define NVKM_CLK_DOM_FLAG_BASE_CLOCK_CORE 0x02
>   u8 flags;
>   const char *mname;
>   int mdiv;
> @@ -94,6 +95,13 @@ struct nvkm_clk {
>   int dstate; /* display adjustment (min+) */
>  
>   bool allow_reclock;
> +#define NVKM_CLK_BOOST_MODE_NONE 0x0
> +#define NVKM_CLK_BOOST_MODE_AVG  0x1
> +#define NVKM_CLK_BOOST_MODE_FULL 0x2
> + u8 boost_mode;
> +
> + u32 base_clock;
> + u32 boost_clock;
>  
>   /*XXX: die, these are here *only* to support the completely
>* bat-shit insane what-was-nouveau_hw.c code
> diff --git a/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drm/nouveau/nvkm/subdev/clk/base.c
> index df9173e..ae76601 100644
> --- a/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -166,6 +166,12 @@ nvkm_cstate_new(struct nvkm_clk *clk, int idx, struct 
> nvkm_pstate *pstate)
>   if (domain->flags & NVKM_CLK_DOM_FLAG_CORE) {
>   u32 freq = nvkm_clk_adjust(clk, true, pstate->pstate,
>  domain->bios, cstepX.freq);
> + if (domain->flags & NVKM_CLK_DOM_FLAG_BASE_CLOCK_CORE) {
> + if (clk->boost_mode == 0 && freq > 
> clk->base_clock)
> + goto err;
> + if (clk->boost_mode == 1 && freq > 
> clk->boost_clock)
> + goto err;
> + }
>   cstate->domain[domain->name] = freq;
>   }
>   domain++;
> @@ -173,6 +179,9 @@ nvkm_cstate_new(struct nvkm_clk *clk, int idx, struct 
> nvkm_pstate *pstate)
>  
>   list_add(>head, >list);
>   return 0;
> +err:
> + kfree(cstate);
> + return -EINVAL;
>  }
>  
>  
> /**
> @@ -573,13 +582,19 @@ nvkm_clk_ctor(const struct nvkm_clk_func *func, struct 
> nvkm_device *device,
>  
>   if (bios && !nvbios_baseclock_parse(bios, )) {
>   struct nvbios_baseclock_entry base_entry, boost_entry;
> + clk->boost_mode = nvkm_longopt(device->cfgopt, "NvBoost", 0);
>   if (nvbios_baseclock_get_entry(bios, , 
> header.base_entry, _entry))

If `boost_mode == -1` is some "went wrong, don't use" value, shouldn't you set
`clk->boost_mode = -1;` here too?

>   nvkm_error(>subdev, "couldn't parse base clock\n");
>   else if (nvbios_baseclock_get_entry(bios, , 
> header.boost_entry, _entry))

Same comment as above

>   nvkm_error(>subdev, "couldn't parse boost 
> clock\n");
> - else
> + else {
> + clk->base_clock = base_entry.clock_mhz * 1000;
> + clk->boost_clock = boost_entry.clock_mhz * 1000;
>   nvkm_info(>subdev, "base: %i MHz, boost: %i MHz\n",
>   base_entry.clock_mhz / 2, boost_entry.clock_mhz 
> / 2);
> + }
> + } else {
> + clk->boost_mode = -1;

You only listed values 0, 1, 2 in the commit message, so what is -1 for?
Disabling nvboost is already taken care by 0, so it's something else. runpm
uses it for auto mode, but here you set it if the bios wasn't found or couldn't
be parsed, so not an auto mode. :-D


Regards,
Pierre


>   }
>  
>   clk->func = func;
> diff --git a/drm/nouveau/nvkm/subdev/clk/gf100.c 
> b/drm/nouveau/nvkm/subdev/clk/gf100.c
> index a52b7e7..eaf4f83 100644
> --- a/drm/nouveau/nvkm/subdev/clk/gf100.c
> +++ b/drm/nouveau/nvkm/subdev/clk/gf100.c
> @@ -443,7 +443,7 @@ gf100_clk = {
>   { nv_clk_src_hubk06 , 0x00 },
>   { nv_clk_src_hubk01 , 0x01 },
>   { nv_clk_src_copy   , 0x02 },
> - { nv_clk_src_gpc, 0x03, 0, "core", 2000 },
> + { nv_clk_src_gpc, 0x03, NVKM_CLK_DOM_FLAG_BASE_CLOCK_CORE, 
> "core", 2000 },
>   { nv_clk_src_rop, 0x04 },
>   { nv_clk_src_mem, 

Re: [Nouveau] NV50 compute support questions

[Pierre Moreau]

Hello Hans,

IIRC, Samuel wrote the kernel directly in assembly by hand. 

As for me, I manually wrote the SPIR-V binary for the kernel, hacked clover to 
use it as if it had been produced by the regular LLVM path, and then fed it 
into the WIP SPIR-V to NV50 IR translator. I can send the instructions on how 
to get it working later today. 

(Some more comments below)

> On 20 Nov 2015, at 11:36, Hans de Goede <hdego...@redhat.com> wrote:
> 
> Hi Samual, et al,
> 
> In 
> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd
> you write: "This compute support has been tested by
> Pierre Moreau and myself with some compute kernels."
> 
> Can you provide testing instructions (and the
> necessary files) so that I can try to reproduce
> your tests ?
> 
> And once I've reproduced your tests, the next
> question is where / how did you get the compute
> kernels for testing. I guess you manually wrote them ?
> 
> As you know I'm working on a llvm tgsi backend,
> it actually produces some output now, if you want
> to take a peek it lives here:
> http://cgit.freedesktop.org/~jwrdegoede/llvm
> 
> Before working further on this I want to take
> a bottom up approach, so I want to first make
> sure we've working TGSI -> compute-kernel and
> compute-kernel -> hardware steps. So the next
> question is, do you know if we can go from
> (manually written) TGSI to a compute-kernel
> using say nouveau-compiler ?

IIRC, it should be possible… but I'll have a look at it this evening. 

Regards,
Pierre

> 
> And if not, do you know what is missing to do
> this?
> 
> Thanks & Regards,
> 
> Hans
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

[Pierre Moreau]

Wasn't there some work being done by François Tigeot or Jean-Sébastien Pédron
to port Nouveau to DragonFlyBSD/FreeBSD? Or at least they were talking about 
porting it
at XDC 2014, no idea what the current status is.

Pierre

PS: Looking at François' slides from this year XDC, it seems there isn't much
progress about it.


On 10:44 AM - Nov 04 2015, Martin Peres wrote:
> 
> 
> On 04/11/15 10:38, C Bergström wrote:
> >On Wed, Nov 4, 2015 at 3:33 PM, Martin Peres  wrote:
> >>On 04/11/15 09:08, cbergst...@pathscale.com wrote:
> >>
> >>Is anyone actually and or actively working on this?
> >>Github.com/pathscale/pscnv is totally bitrot but waaay more portable base.
> >>Nouveau made hard Linux assumptions that will be difficult to overcome
> >>afaik.
> >>
> >>
> >>As pointed out by Ilia, this is not true anymore. Nouveau can also partially
> >>run in the userspace, the hard dependencies on Linux have been abstracted.
> >>
> >>Also, pscnv does not support the newest GPUs and receives no further
> >>development because everything it provided is now provided by Nouveau.
> >I did mention pscnv was bitrot, but I'm not yet convinced that some of
> >the key things which are implemented in nouveau were done to a
> >comparable level of quality (would need to evaluate and don't have
> >time/interest)
> >---
> >To bring this conversation back on track - where would someone start
> >*exactly* to port this to another OS? What kernel dependencies are
> >there?
> 
> This needs to be ported to the other OS, along with drm and ttm (which I
> believe have already been ported to all the BSDs):
> http://cgit.freedesktop.org/~darktama/nouveau/tree/lib/include/nvif/os.h
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Chipset & Family

[Pierre Moreau]

Hello poma,

The chipset didn't disappear and is still displayed: it is the G98 you get on 
the "[2.483843] nouveau :02:00.0: NVIDIA G98 (098200a2)" line. The 
"NV98" was the "Nouveau" chipset, but the switch was made to use the same 
naming as NVIDIA. So rather than displaying both the Nouveau version of the 
chipset and the NVIDIA one, it make sense to only use one, and to prefer the 
NVIDIA naming. (FYI, files name has been modified to follow the NVIDIA naming 
as well, along with envytools.)

As for the family, it can be easily deduced from the chipset in most cases: 
GMxxx are Maxwell cards, GKxxx are Kepler cards, GFxxx are Fermi cards, GTxxx 
are Tesla cards, and most reasonably, GPxxx will be Pascal cards. NV50, G8x, 
G9x, MCPxx are also Tesla cards. They do not follow the same pattern as newer 
cards and so it might not be as easy to identify their family. But there is the 
wiki page to help for that. 

Regards,
Pierre

> On 06 Oct 2015, at 15:01, poma  wrote:
> 
>> On 06.10.2015 02:21, poma wrote:
>> 4.1.8-200.fc22.x86_64 dmesg:
>> [   11.809467] nouveau  [  DEVICE][:02:00.0] BOOT0  : 0x098200a2
>> [   11.809493] nouveau  [  DEVICE][:02:00.0] Chipset: G98 (NV98)
>> [   11.809508] nouveau  [  DEVICE][:02:00.0] Family : NV50
>> 
>> 
>> 4.3.0-0.rc4.git0.1.fc24.x86_64 dmesg:
>> [2.483843] nouveau :02:00.0: NVIDIA G98 (098200a2)
>> 
>> 
>> Where vanished these Chipset & Family super cool lines?
> 
> http://cgit.freedesktop.org/~darktama/nouveau/commit/drm/nouveau/nvkm/engine/device/base.c?id=6cc9e47
> 
> commit 6cc9e47f7f574cb3df6b14caebf15b35408b106d
> Author: Ben Skeggs 
> Date:   Thu Aug 20 14:54:13 2015 +1000
> 
>device: switch to dev_printk macros
> 
>Signed-off-by: Ben Skeggs 
> 
> drm/nouveau/nvkm/engine/device/base.c  | 11 +++
> ...
> 
> 
> -nv_info(device, "BOOT0  : 0x%08x\n", boot0);
> -nv_info(device, "Chipset: %s (NV%02X)\n",
> -device->cname, device->chipset);
> -nv_info(device, "Family : NV%02X\n", device->card_type);
> +nvdev_info(device, "NVIDIA %s (%08x)\n", device->cname, boot0);
> 
> 
> 
> These lines were useful as basic device information,
> and as reference to wiki "CodeNames"
> http://nouveau.freedesktop.org/wiki/CodeNames
> 
> "This page contains a list of some NVIDIA chip code names and their 
> corresponding official GeForce number. If you're running a recent version 
> nouveau, you can find your chipset by doing dmesg | grep -i chipset. This 
> will always be correct, whereas the lists below are approximate."
> 
> Notice "dmesg | grep -i chipset"
> 
> BTW "NVIDIA" is already visible via 'lspci' - lspci | grep VGA
> 
> So only gain is unnecessary information reduction and redundancy.
> 
> Please bring Chipset & Family back.
> 
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Pierre Moreau]

The repo is a fork of Linus' tree, with the patches on top of it. So you just 
need to build that modified version of the kernel and boot it. :-)

Pierre

> On 05 Oct 2015, at 16:15, Evan Foss  wrote:
> 
>> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
>> Hi,
>> 
>> I've also pushed this series to GitHub now to ease reviewing:
>> https://github.com/l1k/linux/commits/mbp_switcheroo_v3
> 
> So to test this all someone has to do is pull this and try it? No
> patching required?
> 
>> Thanks,
>> 
>> Lukas
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> 
> 
> 
> -- 
> Home
> http://evanfoss.googlepages.com/
> Work
> http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v5] pci: Handle 5-bit and 8-bit tag field

[Pierre Moreau]

If the hardware supports extended tag field (8-bit ones), then enable it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible number of requests to 32. Apparently bits 7:0 of 0x08841c
stores some number of outstanding requests, so cap it to 32 if extended tag is
unsupported.

Fixes: fdo#86537

v2: Restrict changes to chipsets >= 0x84
v3:
  * Add nvkm_pci_mask to pci.h
  * Mask bit 8 before setting it
v4:
  * Rename `add` argument of nvkm_pci_mask to `value`
  * Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset
checks
v5:
  * Rebase code on latest PCI structure
  * Restore PCIe check
  * Fix namings in nvkm_pci_mask
  * Rephrase part of the commit message

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/include/nvkm/subdev/pci.h |  1 +
 drm/nouveau/nvkm/subdev/pci/base.c|  8 
 drm/nouveau/nvkm/subdev/pci/g84.c | 24 
 drm/nouveau/nvkm/subdev/pci/g94.c |  1 +
 drm/nouveau/nvkm/subdev/pci/gf100.c   |  1 +
 drm/nouveau/nvkm/subdev/pci/priv.h|  2 ++
 6 files changed, 37 insertions(+)

diff --git a/drm/nouveau/include/nvkm/subdev/pci.h 
b/drm/nouveau/include/nvkm/subdev/pci.h
index 39ca88f..fee0a97 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -24,6 +24,7 @@ struct nvkm_pci {
 u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
 void nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data);
 void nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data);
+u32 nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 value);
 void nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
 
 int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
diff --git a/drm/nouveau/nvkm/subdev/pci/base.c 
b/drm/nouveau/nvkm/subdev/pci/base.c
index 2110622..d671dcf 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
 }
 
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 value)
+{
+   u32 data = pci->func->rd32(pci, addr);
+   pci->func->wr32(pci, addr, (data & ~mask) | value);
+   return data;
+}
+
 void
 nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
 {
diff --git a/drm/nouveau/nvkm/subdev/pci/g84.c 
b/drm/nouveau/nvkm/subdev/pci/g84.c
index 8f3b001..3faa6bf 100644
--- a/drm/nouveau/nvkm/subdev/pci/g84.c
+++ b/drm/nouveau/nvkm/subdev/pci/g84.c
@@ -25,8 +25,32 @@
 
 #include 
 
+void
+g84_pci_init(struct nvkm_pci *pci)
+{
+   /* The following only concerns PCIe cards. */
+   if (!pci_is_pcie(pci->pdev))
+   return;
+
+   /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of requests
+* possible, so if EXT_TAG is disabled, limit that requests number to
+* 32
+*
+* Fixes fdo#86537
+*/
+   if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+   nvkm_pci_mask(pci, 0x0080, 0x0100, 0x0100);
+   else
+   nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+}
+
 static const struct nvkm_pci_func
 g84_pci_func = {
+   .init = g84_pci_init,
.rd32 = nv40_pci_rd32,
.wr08 = nv40_pci_wr08,
.wr32 = nv40_pci_wr32,
diff --git a/drm/nouveau/nvkm/subdev/pci/g94.c 
b/drm/nouveau/nvkm/subdev/pci/g94.c
index 1714421..cd311ee 100644
--- a/drm/nouveau/nvkm/subdev/pci/g94.c
+++ b/drm/nouveau/nvkm/subdev/pci/g94.c
@@ -25,6 +25,7 @@
 
 static const struct nvkm_pci_func
 g94_pci_func = {
+   .init = g84_pci_init,
.rd32 = nv40_pci_rd32,
.wr08 = nv40_pci_wr08,
.wr32 = nv40_pci_wr32,
diff --git a/drm/nouveau/nvkm/subdev/pci/gf100.c 
b/drm/nouveau/nvkm/subdev/pci/gf100.c
index 86f8226..25e1ae7 100644
--- a/drm/nouveau/nvkm/subdev/pci/gf100.c
+++ b/drm/nouveau/nvkm/subdev/pci/gf100.c
@@ -31,6 +31,7 @@ gf100_pci_msi_rearm(struct nvkm_pci *pci)
 
 static const struct nvkm_pci_func
 gf100_pci_func = {
+   .init = g84_pci_init,
.rd32 = nv40_pci_rd32,
.wr08 = nv40_pci_wr08,
.wr32 = nv40_pci_wr32,
diff --git a/drm/nouveau/nvkm/subdev/pci/priv.h 
b/drm/nouveau/nvkm/subdev/pci/priv.h
index 1acd4bc..cf46d38 100644
--- a/drm/nouveau/nvkm/subdev/pci/priv.h
+++ b/drm/nouveau/nvkm/subdev/pci/priv.h
@@ -20,4 +20,6 @@ void nv40_pci_wr32(struct nvkm_pci *, u16, u32);
 void nv40_pci_msi_rearm(struct nvkm_pci *);
 
 void nv46_pci_msi_rearm(struct nvkm_pci *);
+
+void g84_pci_init(struct nvkm_pci *pci);
 #endif
-- 
2.6.0

___
Nouveau mailing list
Nouveau@lists.freede

[Nouveau] [PATCH v4] pci: Handle 5-bit and 8-bit tag field

[Pierre Moreau]

If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.

Fixes: fdo#86537

v2: Restrict changes to chipsets >= 0x84
v3:
  * Add nvkm_pci_mask to pci.h
  * Mask bit 8 before setting it
v4:
  * Rename `add` argument of nvkm_pci_mask to `value`
  * Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset
checks

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/include/nvkm/subdev/pci.h |  4 +++
 drm/nouveau/nvkm/engine/device/base.c | 64 +--
 drm/nouveau/nvkm/subdev/pci/Kbuild|  1 +
 drm/nouveau/nvkm/subdev/pci/base.c| 43 ---
 drm/nouveau/nvkm/subdev/pci/g84.c | 55 ++
 drm/nouveau/nvkm/subdev/pci/gf100.c   |  6 
 drm/nouveau/nvkm/subdev/pci/nv40.c|  6 
 drm/nouveau/nvkm/subdev/pci/nv50.c|  6 
 drm/nouveau/nvkm/subdev/pci/priv.h| 11 ++
 9 files changed, 159 insertions(+), 37 deletions(-)
 create mode 100644 drm/nouveau/nvkm/subdev/pci/g84.c

diff --git a/drm/nouveau/include/nvkm/subdev/pci.h 
b/drm/nouveau/include/nvkm/subdev/pci.h
index 5b3c054..ab79fd0 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -24,11 +24,15 @@ struct nvkm_pci {
 u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
 void nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data);
 void nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data);
+u32 nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 value);
 void nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
 
 int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
 int nv40_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
+int nv40_pci_new_g84_init(struct nvkm_device *, int, struct nvkm_pci **);
 int nv4c_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
 int nv50_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
+int nv50_pci_new_g84_init(struct nvkm_device *, int, struct nvkm_pci **);
 int gf100_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
+int gf100_pci_new_g84_init(struct nvkm_device *, int, struct nvkm_pci **);
 #endif
diff --git a/drm/nouveau/nvkm/engine/device/base.c 
b/drm/nouveau/nvkm/engine/device/base.c
index acc2fe9..9b19b52 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -929,7 +929,7 @@ nv84_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv50_pci_new,
+   .pci = nv50_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -961,7 +961,7 @@ nv86_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv50_pci_new,
+   .pci = nv50_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -993,7 +993,7 @@ nv92_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv50_pci_new,
+   .pci = nv50_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1025,7 +1025,7 @@ nv94_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv40_pci_new,
+   .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1057,7 +1057,7 @@ nv96_chipset = {
.mc = nv50_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv40_pci_new,
+   .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1089,7 +1089,7 @@ nv98_chipset = {
.mc = g98_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv40_pci_new,
+   .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1121,7 +1121,7 @@ nva0_chipset = {
.mc = g98_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv40_pci_new,
+   .pci = nv40_pci_new_g84_init,
.therm = g84_therm_new,
.timer = nv41_timer_new,
.volt = nv40_volt_new,
@@ -1153,7 +1153,7 @@ nva3_chipset = {
.mc = g98_mc_new,
.mmu = nv50_mmu_new,
.mxm = nv50_mxm_new,
-   .pci = nv40_pci_new,
+   .pci = nv40_pci_new_g84_init,
.pmu = gt215_pmu_new,
.therm = gt215_therm_new,
.timer = nv41_timer_new,
@@ -1187,7 +1187,7 @@ nva5_chipset = {
  

Re: [Nouveau] [PATCH v3] pci: Handle 5-bit and 8-bit tag field

[Pierre Moreau]

- Mail original -
> If the hardware supports extended tag field (8-bit ones), then
> enabled it. This
> is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
> In case extended tag field is not supported, 5-bit tag field is used
> which
> limits the possible values to 32. Apparently bits 7:0 of 0x8841c
> stores some
> number of outstanding requests, so cap it to 32 if extended tag is
> unsupported.
> 
> Fixes: fdo#86537
> 
> v2: Restrict changes to chipsets >= 0x84
> v3:
>   * Add nvkm_pci_mask to pci.h
>   * Mask bit 8 before setting it
> 
> Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>

Tested-by: Karol Herbst <freedesk...@karolherbst.de>

> ---
>  drm/nouveau/include/nvkm/subdev/pci.h |  1 +
>  drm/nouveau/nvkm/subdev/pci/base.c| 25 +
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drm/nouveau/include/nvkm/subdev/pci.h
> b/drm/nouveau/include/nvkm/subdev/pci.h
> index 5b3c054..774ca66 100644
> --- a/drm/nouveau/include/nvkm/subdev/pci.h
> +++ b/drm/nouveau/include/nvkm/subdev/pci.h
> @@ -24,6 +24,7 @@ struct nvkm_pci {
>  u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
>  void nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data);
>  void nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data);
> +u32 nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 add);
>  void nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
>  
>  int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
> diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
> b/drm/nouveau/nvkm/subdev/pci/base.c
> index d1c148e..cb2835b 100644
> --- a/drm/nouveau/nvkm/subdev/pci/base.c
> +++ b/drm/nouveau/nvkm/subdev/pci/base.c
> @@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32
> data)
>   pci->func->wr32(pci, addr, data);
>  }
>  
> +u32
> +nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
> +{
> + u32 data = pci->func->rd32(pci, addr);
> + pci->func->wr32(pci, addr, (data & ~mask) | add);
> + return data;
> +}
> +
>  void
>  nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
>  {
> @@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
>   if (ret)
>   return ret;
>  
> + if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
> + /* Tag field is 8-bit long, regardless of EXT_TAG.
> +  * However, if EXT_TAG is disabled, only the lower 5 bits of the
> tag
> +  * field should be used, limiting the number of request to 32.
> +  *
> +  * Apparently, 0x041c stores some limit on the number of 
> requests
> +  * possible, so if EXT_TAG is disabled, limit that requests 
> number
> to
> +  * 32
> +  *
> +  * Fixes fdo#86537
> +  */
> + if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
> + nvkm_pci_mask(pci, 0x0080, 0x0100, 0x0100);
> + else
> + nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
> + }
> +
>   pci->irq = pdev->irq;
>   return ret;
>  }
> --
> 2.5.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2] pci: Handle 5-bit and 8-bit tag field

[Pierre Moreau]

If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.

Fixes: fdo#86537

v2: Restrict changes to chipsets >= 0x84

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/nvkm/subdev/pci/base.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drm/nouveau/nvkm/subdev/pci/base.c 
b/drm/nouveau/nvkm/subdev/pci/base.c
index d1c148e..bbad29d 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
 }
 
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
+{
+   u32 data = pci->func->rd32(pci, addr);
+   pci->func->wr32(pci, addr, (data & ~mask) | add);
+   return data;
+}
+
 void
 nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
 {
@@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (ret)
return ret;
 
+   if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
+   /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of 
the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of 
requests
+* possible, so if EXT_TAG is disabled, limit that requests 
number to
+* 32
+*
+* Fixes fdo#86537
+*/
+   if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+   nvkm_pci_mask(pci, 0x0080, 0x, 0x0100);
+   else
+   nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+   }
+
pci->irq = pdev->irq;
return ret;
 }
-- 
2.5.2

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

[Nouveau] [PATCH v3] pci: Handle 5-bit and 8-bit tag field

[Pierre Moreau]

If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.

Fixes: fdo#86537

v2: Restrict changes to chipsets >= 0x84
v3:
  * Add nvkm_pci_mask to pci.h
  * Mask bit 8 before setting it

Signed-off-by: Pierre Moreau <pierre.mor...@free.fr>
---
 drm/nouveau/include/nvkm/subdev/pci.h |  1 +
 drm/nouveau/nvkm/subdev/pci/base.c| 25 +
 2 files changed, 26 insertions(+)

diff --git a/drm/nouveau/include/nvkm/subdev/pci.h 
b/drm/nouveau/include/nvkm/subdev/pci.h
index 5b3c054..774ca66 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -24,6 +24,7 @@ struct nvkm_pci {
 u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
 void nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data);
 void nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data);
+u32 nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 add);
 void nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
 
 int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
diff --git a/drm/nouveau/nvkm/subdev/pci/base.c 
b/drm/nouveau/nvkm/subdev/pci/base.c
index d1c148e..cb2835b 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
 }
 
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
+{
+   u32 data = pci->func->rd32(pci, addr);
+   pci->func->wr32(pci, addr, (data & ~mask) | add);
+   return data;
+}
+
 void
 nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
 {
@@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (ret)
return ret;
 
+   if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
+   /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of 
the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of 
requests
+* possible, so if EXT_TAG is disabled, limit that requests 
number to
+* 32
+*
+* Fixes fdo#86537
+*/
+   if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+   nvkm_pci_mask(pci, 0x0080, 0x0100, 0x0100);
+   else
+   nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+   }
+
pci->irq = pdev->irq;
return ret;
 }
-- 
2.5.2

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

[Nouveau] [PATCH] pci: Handle 5-bit and 8-bit tag field

[Pierre Moreau]

If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.

Fixes: fdo#86537
Signed-off-by: Pierre Moreau <d...@pmoreau.org>
---
 drm/nouveau/nvkm/subdev/pci/base.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drm/nouveau/nvkm/subdev/pci/base.c 
b/drm/nouveau/nvkm/subdev/pci/base.c
index d1c148e..70631b3 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
 }
 
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
+{
+   u32 data = pci->func->rd32(pci, addr);
+   pci->func->wr32(pci, addr, (data & ~mask) | add);
+   return data;
+}
+
 void
 nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
 {
@@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (ret)
return ret;
 
+   if (pci_is_pcie(pdev)) {
+   /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of 
the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of 
requests
+* possible, so if EXT_TAG is disabled, limit that requests 
number to
+* 32
+*
+* Fixes fdo#86537
+*/
+   if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+   nvkm_pci_mask(pci, 0x0080, 0x, 0x0100);
+   else
+   nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+   }
+
pci->irq = pdev->irq;
return ret;
 }
-- 
2.5.1

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

Re: [Nouveau] Will nouveau support for cuda?

[Pierre Moreau]

Hello,

Nouveau will support Cuda and OpenCL, someday. :)
As to say when, I don't know. I am starting to work on translating between 
different intermediate representation (from SPIR-V to NV50 IR), and will later 
work on finishing compute support for Tesla cards (I only have Tesla cards, 
apart from one Fermi). Compute support for Fermi and Kepler (your card) should 
be almost done. It looks like there are no compilers out yet doing Cuda - 
SPIR-V, but Cuda - LLVM IR - SPIR-V should be possible, with the LLVM IR - 
SPIR-V still being discussed/worked on on the LLVM mailing list. When 
everything will be sorted out, you should then be able to use Cuda with Nouveau.

Pierre


- Mail original -
 
 
 Hi everyone,
 I have a GTX780 graphics card and want to move to nouveau for some
 reason.
 I need cuda for heavy use.(Blender, etc.)
 Will nouveau support for cuda? If yes, when will it be realesed?
 
 ZZ
 
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau
 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 8/9] acpi: Add support for Apple Gmux _DMS

[Pierre Moreau]

Hi Lukas

- Mail original -
 Hi Pierre,
 
 On Thu, May 28, 2015 at 10:52:56AM +0200, Pierre Moreau wrote:
  How is it supposed to work, by simply echo'ing ON or OFF to
  vga_switcheroo/switch? Then I probably forgot some stuff as
  it doesn't want to work on my laptop.
 
 What exactly doesn't work and which version of the MacBook Pro did
 you try this on? The expected behaviour when switching GPUs on the
 MBP is that the GPU that was inactive on bootup will only show a
 black screen because it was unable to read the EDID (and DPCD on
 retina MBPs) on bootup. In other words, it's broken.

I'm trying on a mid-2009 MBP, which has a double NVidia setup with a 9400M as 
IGD and 9600M GT as DIS. Switching between both works (as long as do a 
PCI-reset of the G96, but that's another story and I should have a patch soon, 
hopefully).
It was also tested by another user on a retina MBP and we ran into the black 
screen issue. I pointed him to your patches, but I don't know yet if it helped 
or not.

 
 There have been attempts to solve this by multiple folks, the last
 one was submitted to dri-devel in April by yours truly:
 http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
 
 That initial version of my patch set turned out to only work on
 pre-retina MBPs, and only if the active GPU on bootup is the
 discrete one. I'm currently working on a v2 to solve all that.

Cool! Looking forward to it!

 
 We need to get switching working before we can enable runtime PM on
 MBPs, otherwise the user will be greeted by a black screen when the
 Nvidia GPU goes to sleep and hands over to the integrated GPU.
 So your patch is a bit premature I'm afraid. :-(

It's power management++: we even save energy on the screen by powering it off 
for better battery life! ;)

 
 
 As to the patch itself, you're checking for existence of the gmux
 but we can't make use of it unless its driver is loaded. Hence it
 may be easier to simply query for the existence of the driver,
 using something along the lines of find_module(apple-gmux).
 I imagine this is much less code than checking for the DMI IDs.

I didn't know there was such a function! Seems nice!

 
 Also, Dave Airlie and Matthew Garrett already wrote a patch set to
 enable runtime PM for nouveau on MBPs which is more generic: It works
 with any vga_switcheroo handler, not just gmux:
 
 http://lists.freedesktop.org/archives/dri-devel/2014-June/060927.html
 http://lists.freedesktop.org/archives/dri-devel/2014-June/060928.html
 http://lists.freedesktop.org/archives/dri-devel/2014-June/060942.html
 http://www.codon.org.uk/~mjg59/tmp/retina_patches/0027-nouveau-enable-runtime-pm-on-apple-gmux-machines.patch
 http://www.codon.org.uk/~mjg59/tmp/retina_patches/0028-nouveau-Enable-switcheroo-dynamic-PM-at-switcheroo-e.patch
 
 The fourth one in that list is by Dave Airlie and all the others are
 by Matthew Garrett. But, as I said, we can't apply these either until
 switching works. I'm working on it. ;-)

I had no idea these patches existed: I should have looked around before.
I'll drop the patches, apart probably from the *cleaning* ones, but I'll wait 
for the previously mentioned ones to first land.

 
 
 As to your questions:
 
  How is it supposed to work, by simply echo'ing ON or OFF to
  vga_switcheroo/switch?
 
 Echoing ON/OFF to the switch file will power the inactive device
 up or down. If the currently active gpu is the discrete one (which
 is the default when booting a MacBook Pro)

Not on the mid-2009 MBP! ;) Which is great!

 , this will power up/down
 the integrated gpu. You can use the tool gpu-switch to force the
 MBP to the integrated GPU on next bootup, then you can echo ON/OFFI'ddd
 to change the power state of the Nvidia GPU:
 https://github.com/0xbb/gpu-switch
 
  If I understand it correctly, if the laptop is an Optimus one or
  has a mux, we are not allowed to opt-out of DynPwr/DynOff by
  powering down the card?
 
 If we power the GPU down manually by echoing OFF to the switch
 file, the runtime PM code would probably get confused, I imagine
 that's the reason why ON/OFF is ignored if
 client-driver_power_control
 is set to true.

I would have guessed that runtime pm would then get disabled.

 
 Speaking of which, the external ports of the MBP are soldered to
 the discrete GPU and can't be switched. Only the panel can be
 switched. So if there are DP or HDMI connectors with status
 connected, we can't suspend. That's one of the MBP's numerous
 peculiarities that I haven't verified yet they're handled properly
 by the code.

I could check that on my MBP if you want.



Best regards,

Pierre


 
 Best regards,
 
 Lukas
 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH NEW 5/9] acpi: Use a single type of errors in evaluate functions

[Pierre Moreau]

I wasn't sure how to insert this one into the flow, if I should make it a patch 
4.5 or not. I went with patch 5, so all the following patches are incremented 
by 1 compared to the v1, sorry about that.
What should be the way to go?

Pierre



 On 28 May 2015, at 08:40, Pierre Moreau pierre.mor...@free.fr wrote:
 
 Signed-off-by: Pierre Moreau pierre.mor...@free.fr
 ---
 drm/nouveau/nouveau_acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
 index 01dbf1d..b837ab1 100644
 --- a/drm/nouveau/nouveau_acpi.c
 +++ b/drm/nouveau/nouveau_acpi.c
 @@ -92,7 +92,7 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
 int func, int arg, u
  func, argv4, ACPI_TYPE_BUFFER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
 -return AE_ERROR;
 +return -EINVAL;
} else {
if (result  obj-buffer.length == 4) {
*result  = obj-buffer.pointer[0];
 @@ -142,7 +142,7 @@ static int nouveau_evaluate_mux_dsm(acpi_handle handle, 
 int func, int arg)
  func, argv4, ACPI_TYPE_INTEGER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
 -return AE_ERROR;
 +return -EINVAL;
} else {
if (obj-integer.value == 0x8002)
ret = -ENODEV;
 -- 
 2.4.2
 
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2 8/9] acpi: Add support for Apple Gmux _DMS

[Pierre Moreau]

Changes since v1:
* Factorise testing of the 3 different _DSMs presence with a single function
* Check for gmux in nouveau_switcheroo_set_state
* Change some comments and messages that were referring explicitly to Optimus
  whereas they were also testing the mux and gmux _DSMs

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 57 --
 drm/nouveau/nouveau_acpi.h |  4 
 drm/nouveau/nouveau_drm.c  | 12 +-
 drm/nouveau/nouveau_vga.c  | 10 
 4 files changed, 70 insertions(+), 13 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index edc4b94..ee5fcfa 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -29,6 +29,10 @@
 
 #define NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN (NOUVEAU_DSM_OPTIMUS_POWERDOWN_PS3 | 
NOUVEAU_DSM_OPTIMUS_FLAGS_CHANGED)
 
+#define NOUVEAU_DSM_GMUX_V1_CAPS (3  6)
+
+#define NOUVEAU_DSM_GMUX_V2_CAPS (1  1)
+
 /* result of the optimus caps function */
 #define OPTIMUS_ENABLED (1  0)
 #define OPTIMUS_STATUS_MASK (3  3)
@@ -45,6 +49,7 @@
 static struct nouveau_dsm_priv {
bool mux_detected;
bool optimus_detected;
+   bool gmux_detected;
acpi_handle dhandle;
acpi_handle rom_handle;
 } nouveau_dsm_priv;
@@ -57,8 +62,17 @@ bool nouveau_has_mux(void) {
return nouveau_dsm_priv.mux_detected;
 }
 
+bool nouveau_has_gmux(void) {
+   return nouveau_dsm_priv.gmux_detected;
+}
+
+bool nouveau_has_dsm(void) {
+   return nouveau_is_optimus() || nouveau_has_mux() || nouveau_has_gmux();
+}
+
 #define NOUVEAU_DSM_HAS_MUX 0x1
 #define NOUVEAU_DSM_HAS_OPT 0x2
+#define NOUVEAU_DSM_HAS_GMUX 0x4
 
 #ifdef CONFIG_VGA_SWITCHEROO
 static const uint32_t nouveau_mux_dsm_rid = 0x0102;
@@ -73,6 +87,18 @@ static const char nouveau_op_dsm_muid[] = {
0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
 };
 
+static const uint32_t nouveau_gmux_v1_dsm_rid = 0x101;
+static const char nouveau_gmux_v1_dsm_muid[] = {
+   0xA6, 0x69, 0x86, 0x99, 0xE9, 0x8B, 0xFB, 0x49,
+   0xBD, 0xDB, 0x51, 0xA1, 0xEF, 0xE1, 0x9C, 0x3D,
+};
+
+static const uint32_t nouveau_gmux_v2_dsm_rid = 0x001;
+static const char nouveau_gmux_v2_dsm_muid[] = {
+   0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44,
+   0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B,
+};
+
 static int nouveau_evaluate_optimus_dsm(acpi_handle handle, int func, int arg, 
uint32_t *result)
 {
int i;
@@ -161,6 +187,17 @@ static int nouveau_evaluate_mux_dsm(acpi_handle handle, 
int func, int arg)
return ret;
 }
 
+static int nouveau_check_gmux_dsm(acpi_handle handle)
+{
+   bool has_v1 = acpi_check_dsm(handle, nouveau_gmux_v1_dsm_muid,
+nouveau_gmux_v1_dsm_rid,
+NOUVEAU_DSM_GMUX_V1_CAPS);
+   bool has_v2 = acpi_check_dsm(handle, nouveau_gmux_v2_dsm_muid,
+nouveau_gmux_v2_dsm_rid,
+NOUVEAU_DSM_GMUX_V2_CAPS);
+   return has_v1 || has_v2;
+}
+
 static int nouveau_dsm_switch_mux(acpi_handle handle, int mux_id)
 {
mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
@@ -238,6 +275,9 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev)
   1  NOUVEAU_DSM_MUX_POWER))
retval |= NOUVEAU_DSM_HAS_MUX;
 
+   if (nouveau_check_gmux_dsm(dhandle))
+   retval |= NOUVEAU_DSM_HAS_GMUX;
+
if (nouveau_check_optimus_dsm(dhandle))
retval |= NOUVEAU_DSM_HAS_OPT;
 
@@ -263,6 +303,7 @@ static bool nouveau_dsm_detect(void)
struct pci_dev *pdev = NULL;
int has_mux = 0;
int has_optimus = 0;
+   bool has_gmux = false;
int vga_count = 0;
bool guid_valid;
int retval;
@@ -283,6 +324,8 @@ static bool nouveau_dsm_detect(void)
has_mux |= 1;
if (retval  NOUVEAU_DSM_HAS_OPT)
has_optimus = 1;
+   if (retval  NOUVEAU_DSM_HAS_GMUX)
+   has_gmux = true;
}
 
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_3D  8, pdev)) != NULL) 
{
@@ -293,9 +336,11 @@ static bool nouveau_dsm_detect(void)
has_mux |= 1;
if (retval  NOUVEAU_DSM_HAS_OPT)
has_optimus = 1;
+   if (retval  NOUVEAU_DSM_HAS_GMUX)
+   has_gmux = true;
}
 
-   /* find the optimus DSM or the mux DSM */
+   /* find the optimus DSM, the mux DSM or the gmux DSM */
if (has_optimus == 1) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
buffer);
@@ -310,6 +355,13 @@ static bool nouveau_dsm_detect(void)
acpi_method_name);
nouveau_dsm_priv.mux_detected = true;
ret

[Nouveau] [PATCH v2 2/9] acpi: Add evaluate to name of functions evaluating _DSM

[Pierre Moreau]

This makes it clearer when reading the function name, as well as following the
names of related ACPI functions.

Changes since v1:
* Fix typo in commit message
* Slightly reformulate the commit message to be clearer

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index c90037f..e18fbeb 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -71,7 +71,7 @@ static const char nouveau_op_dsm_muid[] = {
0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
 };
 
-static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t 
*result)
+static int nouveau_evaluate_optimus_dsm(acpi_handle handle, int func, int arg, 
uint32_t *result)
 {
int i;
union acpi_object *obj;
@@ -118,7 +118,7 @@ static int nouveau_check_optimus_dsm(acpi_handle handle)
 * Function 0 returns a Buffer containing available functions.
 * The args parameter is ignored for function 0, so just put 0 in it
 */
-   if (nouveau_optimus_dsm(handle, 0, 0, result))
+   if (nouveau_evaluate_optimus_dsm(handle, 0, 0, result))
return 0;
 
/*
@@ -128,7 +128,7 @@ static int nouveau_check_optimus_dsm(acpi_handle handle)
return result  1  result  (1  NOUVEAU_DSM_OPTIMUS_CAPS);
 }
 
-static int nouveau_mux_dsm(acpi_handle handle, int func, int arg)
+static int nouveau_evaluate_mux_dsm(acpi_handle handle, int func, int arg)
 {
int ret = 0;
union acpi_object *obj;
@@ -155,7 +155,7 @@ static int nouveau_dsm_switch_mux(acpi_handle handle, int 
mux_id)
 {
mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
mxm_wmi_call_mxds(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
-   return nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_LED, mux_id);
+   return nouveau_evaluate_mux_dsm(handle, NOUVEAU_DSM_MUX_LED, mux_id);
 }
 
 static int nouveau_dsm_set_discrete_state(acpi_handle handle, enum 
vga_switcheroo_state state)
@@ -165,7 +165,7 @@ static int nouveau_dsm_set_discrete_state(acpi_handle 
handle, enum vga_switchero
arg = NOUVEAU_DSM_MUX_POWER_SPEED;
else
arg = NOUVEAU_DSM_MUX_POWER_STAMINA;
-   nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_POWER, arg);
+   nouveau_evaluate_mux_dsm(handle, NOUVEAU_DSM_MUX_POWER, arg);
return 0;
 }
 
@@ -233,8 +233,8 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev)
 
if (retval  NOUVEAU_DSM_HAS_OPT) {
uint32_t result;
-   nouveau_optimus_dsm(dhandle, NOUVEAU_DSM_OPTIMUS_CAPS, 0,
-   result);
+   nouveau_evaluate_optimus_dsm(dhandle, NOUVEAU_DSM_OPTIMUS_CAPS,
+0, result);
dev_info(pdev-dev, optimus capabilities: %s, status %s%s\n,
 (result  OPTIMUS_ENABLED) ? enabled : disabled,
 (result  OPTIMUS_DYNAMIC_PWR_CAP) ? dynamic power,  
: ,
@@ -324,11 +324,14 @@ void nouveau_switcheroo_optimus_dsm(void)
if (!nouveau_dsm_priv.optimus_detected)
return;
 
-   nouveau_optimus_dsm(nouveau_dsm_priv.dhandle, NOUVEAU_DSM_OPTIMUS_FLAGS,
-   0x3, result);
+   nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
+NOUVEAU_DSM_OPTIMUS_FLAGS,
+0x3, result);
 
-   nouveau_optimus_dsm(nouveau_dsm_priv.dhandle, NOUVEAU_DSM_OPTIMUS_CAPS,
-   NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN, result);
+   nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
+NOUVEAU_DSM_OPTIMUS_CAPS,
+NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN,
+result);
 
 }
 
-- 
2.4.2

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

[Nouveau] [PATCH v2 1/9] acpi: Rename v1 DSM to mux to avoid ambiguity

[Pierre Moreau]

This is especially true when variables or functions are just called dsm without
specifying the v1.

Changes since v1:
* Fix typo in commit explanation
* Change has_dsm to has_mux in nouveau_dsm_detect

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 72 +++---
 drm/nouveau/nouveau_acpi.h |  4 +--
 drm/nouveau/nouveau_drm.c  |  4 +--
 drm/nouveau/nouveau_vga.c  | 10 +++
 4 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 6224246..c90037f 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -9,16 +9,16 @@
 #include nouveau_drm.h
 #include nouveau_acpi.h
 
-#define NOUVEAU_DSM_LED 0x02
-#define NOUVEAU_DSM_LED_STATE 0x00
-#define NOUVEAU_DSM_LED_OFF 0x10
-#define NOUVEAU_DSM_LED_STAMINA 0x11
-#define NOUVEAU_DSM_LED_SPEED 0x12
+#define NOUVEAU_DSM_MUX_LED 0x02
+#define NOUVEAU_DSM_MUX_LED_STATE 0x00
+#define NOUVEAU_DSM_MUX_LED_OFF 0x10
+#define NOUVEAU_DSM_MUX_LED_STAMINA 0x11
+#define NOUVEAU_DSM_MUX_LED_SPEED 0x12
 
-#define NOUVEAU_DSM_POWER 0x03
-#define NOUVEAU_DSM_POWER_STATE 0x00
-#define NOUVEAU_DSM_POWER_SPEED 0x01
-#define NOUVEAU_DSM_POWER_STAMINA 0x02
+#define NOUVEAU_DSM_MUX_POWER 0x03
+#define NOUVEAU_DSM_MUX_POWER_STATE 0x00
+#define NOUVEAU_DSM_MUX_POWER_SPEED 0x01
+#define NOUVEAU_DSM_MUX_POWER_STAMINA 0x02
 
 #define NOUVEAU_DSM_OPTIMUS_CAPS 0x1A
 #define NOUVEAU_DSM_OPTIMUS_FLAGS 0x1B
@@ -43,7 +43,7 @@
 #define OPTIMUS_HDA_CODEC_MASK (2  27) /* hda bios control */
 
 static struct nouveau_dsm_priv {
-   bool dsm_detected;
+   bool mux_detected;
bool optimus_detected;
acpi_handle dhandle;
acpi_handle rom_handle;
@@ -53,15 +53,15 @@ bool nouveau_is_optimus(void) {
return nouveau_dsm_priv.optimus_detected;
 }
 
-bool nouveau_is_v1_dsm(void) {
-   return nouveau_dsm_priv.dsm_detected;
+bool nouveau_has_mux(void) {
+   return nouveau_dsm_priv.mux_detected;
 }
 
 #define NOUVEAU_DSM_HAS_MUX 0x1
 #define NOUVEAU_DSM_HAS_OPT 0x2
 
 #ifdef CONFIG_VGA_SWITCHEROO
-static const char nouveau_dsm_muid[] = {
+static const char nouveau_mux_dsm_muid[] = {
0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
 };
@@ -128,7 +128,7 @@ static int nouveau_check_optimus_dsm(acpi_handle handle)
return result  1  result  (1  NOUVEAU_DSM_OPTIMUS_CAPS);
 }
 
-static int nouveau_dsm(acpi_handle handle, int func, int arg)
+static int nouveau_mux_dsm(acpi_handle handle, int func, int arg)
 {
int ret = 0;
union acpi_object *obj;
@@ -137,7 +137,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
arg)
.integer.value = arg,
};
 
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_dsm_muid, 0x0102,
+   obj = acpi_evaluate_dsm_typed(handle, nouveau_mux_dsm_muid, 0x0102,
  func, argv4, ACPI_TYPE_INTEGER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
@@ -153,30 +153,30 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
arg)
 
 static int nouveau_dsm_switch_mux(acpi_handle handle, int mux_id)
 {
-   mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
-   mxm_wmi_call_mxds(mux_id == NOUVEAU_DSM_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
-   return nouveau_dsm(handle, NOUVEAU_DSM_LED, mux_id);
+   mxm_wmi_call_mxmx(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
+   mxm_wmi_call_mxds(mux_id == NOUVEAU_DSM_MUX_LED_STAMINA ? 
MXM_MXDS_ADAPTER_IGD : MXM_MXDS_ADAPTER_0);
+   return nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_LED, mux_id);
 }
 
 static int nouveau_dsm_set_discrete_state(acpi_handle handle, enum 
vga_switcheroo_state state)
 {
int arg;
if (state == VGA_SWITCHEROO_ON)
-   arg = NOUVEAU_DSM_POWER_SPEED;
+   arg = NOUVEAU_DSM_MUX_POWER_SPEED;
else
-   arg = NOUVEAU_DSM_POWER_STAMINA;
-   nouveau_dsm(handle, NOUVEAU_DSM_POWER, arg);
+   arg = NOUVEAU_DSM_MUX_POWER_STAMINA;
+   nouveau_mux_dsm(handle, NOUVEAU_DSM_MUX_POWER, arg);
return 0;
 }
 
 static int nouveau_dsm_switchto(enum vga_switcheroo_client_id id)
 {
-   if (!nouveau_dsm_priv.dsm_detected)
+   if (!nouveau_dsm_priv.mux_detected)
return 0;
if (id == VGA_SWITCHEROO_IGD)
-   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_LED_STAMINA);
+   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_MUX_LED_STAMINA);
else
-   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_LED_SPEED);
+   return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_MUX_LED_SPEED);
 }
 
 static

[Nouveau] [PATCH 3/9] acpi: Define static variables for revision ids

[Pierre Moreau]

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index e18fbeb..3f01067 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -61,11 +61,13 @@ bool nouveau_has_mux(void) {
 #define NOUVEAU_DSM_HAS_OPT 0x2
 
 #ifdef CONFIG_VGA_SWITCHEROO
+static const uint32_t nouveau_mux_dsm_rid = 0x0102;
 static const char nouveau_mux_dsm_muid[] = {
0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
 };
 
+static const uint32_t nouveau_op_dsm_rid = 0x0100;
 static const char nouveau_op_dsm_muid[] = {
0xF8, 0xD8, 0x86, 0xA4, 0xDA, 0x0B, 0x1B, 0x47,
0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
@@ -87,7 +89,7 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
args_buff[i] = (arg  i * 8)  0xFF;
 
*result = 0;
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 0x0100,
+   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
nouveau_op_dsm_rid,
  func, argv4, ACPI_TYPE_BUFFER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
@@ -137,7 +139,7 @@ static int nouveau_evaluate_mux_dsm(acpi_handle handle, int 
func, int arg)
.integer.value = arg,
};
 
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_mux_dsm_muid, 0x0102,
+   obj = acpi_evaluate_dsm_typed(handle, nouveau_mux_dsm_muid, 
nouveau_mux_dsm_rid,
  func, argv4, ACPI_TYPE_INTEGER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
@@ -224,7 +226,7 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev)
if (!acpi_has_method(dhandle, _DSM))
return false;
 
-   if (acpi_check_dsm(dhandle, nouveau_mux_dsm_muid, 0x0102,
+   if (acpi_check_dsm(dhandle, nouveau_mux_dsm_muid, nouveau_mux_dsm_rid,
   1  NOUVEAU_DSM_MUX_POWER))
retval |= NOUVEAU_DSM_HAS_MUX;
 
-- 
2.4.2

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

[Nouveau] [PATCH v2 9/9] acpi: Move detecting available _DSM outside of while loops

[Pierre Moreau]

Changes since v1:
* Re-write the whole patch to detect available _DSMs when we enable them rather
  than on each loop run

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index ee5fcfa..a970e41 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -301,12 +301,9 @@ static bool nouveau_dsm_detect(void)
char acpi_method_name[255] = { 0 };
struct acpi_buffer buffer = {sizeof(acpi_method_name), 
acpi_method_name};
struct pci_dev *pdev = NULL;
-   int has_mux = 0;
-   int has_optimus = 0;
-   bool has_gmux = false;
int vga_count = 0;
bool guid_valid;
-   int retval;
+   int retval = 0;
bool ret = false;
 
/* lookup the MXM GUID */
@@ -319,43 +316,31 @@ static bool nouveau_dsm_detect(void)
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA  8, pdev)) != 
NULL) {
vga_count++;
 
-   retval = nouveau_dsm_pci_probe(pdev);
-   if (retval  NOUVEAU_DSM_HAS_MUX)
-   has_mux |= 1;
-   if (retval  NOUVEAU_DSM_HAS_OPT)
-   has_optimus = 1;
-   if (retval  NOUVEAU_DSM_HAS_GMUX)
-   has_gmux = true;
+   retval |= nouveau_dsm_pci_probe(pdev);
}
 
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_3D  8, pdev)) != NULL) 
{
vga_count++;
 
-   retval = nouveau_dsm_pci_probe(pdev);
-   if (retval  NOUVEAU_DSM_HAS_MUX)
-   has_mux |= 1;
-   if (retval  NOUVEAU_DSM_HAS_OPT)
-   has_optimus = 1;
-   if (retval  NOUVEAU_DSM_HAS_GMUX)
-   has_gmux = true;
+   retval |= nouveau_dsm_pci_probe(pdev);
}
 
/* find the optimus DSM, the mux DSM or the gmux DSM */
-   if (has_optimus == 1) {
+   if (retval  NOUVEAU_DSM_HAS_OPT) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
buffer);
printk(KERN_INFO VGA switcheroo: detected Optimus DSM method 
%s handle\n,
acpi_method_name);
nouveau_dsm_priv.optimus_detected = true;
ret = true;
-   } else if (vga_count == 2  has_mux  guid_valid) {
+   } else if (vga_count == 2  (retval  NOUVEAU_DSM_HAS_MUX)  
guid_valid) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
buffer);
printk(KERN_INFO VGA switcheroo: detected mux DSM switching 
method %s handle\n,
acpi_method_name);
nouveau_dsm_priv.mux_detected = true;
ret = true;
-   } else if (has_gmux) {
+   } else if (retval  NOUVEAU_DSM_HAS_GMUX) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
buffer);
printk(KERN_INFO VGA switcheroo: detected gmux DSM switching 
method %s handle\n,
-- 
2.4.2

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

[Nouveau] [PATCH v2 4/9] acpi: Allow evaluate_optimus_dsm to take NULL results

[Pierre Moreau]

Changes since v1:
* Fix check for result being not NULL in nouveau_evaluate_optimus_dsm

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 3f01067..01dbf1d 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -88,15 +88,14 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
for (i = 0; i  4; i++)
args_buff[i] = (arg  i * 8)  0xFF;
 
-   *result = 0;
obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
nouveau_op_dsm_rid,
  func, argv4, ACPI_TYPE_BUFFER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
return AE_ERROR;
} else {
-   if (obj-buffer.length == 4) {
-   *result |= obj-buffer.pointer[0];
+   if (result  obj-buffer.length == 4) {
+   *result  = obj-buffer.pointer[0];
*result |= (obj-buffer.pointer[1]  8);
*result |= (obj-buffer.pointer[2]  16);
*result |= (obj-buffer.pointer[3]  24);
@@ -322,18 +321,17 @@ void nouveau_register_dsm_handler(void)
 /* Must be called for Optimus models before the card can be turned off */
 void nouveau_switcheroo_optimus_dsm(void)
 {
-   u32 result = 0;
if (!nouveau_dsm_priv.optimus_detected)
return;
 
nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
 NOUVEAU_DSM_OPTIMUS_FLAGS,
-0x3, result);
+0x3, NULL);
 
nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
 NOUVEAU_DSM_OPTIMUS_CAPS,
 NOUVEAU_DSM_OPTIMUS_SET_POWERDOWN,
-result);
+NULL);
 
 }
 
-- 
2.4.2

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

[Nouveau] [PATCH v2 6/9] acpi: Check returned object type by Optimus _DSM locally

[Pierre Moreau]

Most _DSM will return an integer value of 0x8002 when given an unknown
UUID, revision ID or function ID. Checking locally allows us to differentiate
that case from other ACPI errors, and to not report a failed to evaluate _DSM
if 0x8002 is returned which was confusing.

Changes since v1:
* Replace ACPI errors with standard kernel ones

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index b837ab1..44a7328 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -88,12 +88,12 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
for (i = 0; i  4; i++)
args_buff[i] = (arg  i * 8)  0xFF;
 
-   obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 
nouveau_op_dsm_rid,
- func, argv4, ACPI_TYPE_BUFFER);
+   obj = acpi_evaluate_dsm(handle, nouveau_op_dsm_muid, nouveau_op_dsm_rid,
+   func, argv4);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
return -EINVAL;
-   } else {
+   } else if (obj-type == ACPI_TYPE_BUFFER) {
if (result  obj-buffer.length == 4) {
*result  = obj-buffer.pointer[0];
*result |= (obj-buffer.pointer[1]  8);
@@ -101,6 +101,15 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle 
handle, int func, int arg, u
*result |= (obj-buffer.pointer[3]  24);
}
ACPI_FREE(obj);
+   } else if (obj-type == ACPI_TYPE_INTEGER 
+  obj-integer.value == 0x8002) {
+   acpi_handle_debug(handle, failed to query Optimus _DSM\n);
+   ACPI_FREE(obj);
+   return -ENODEV;
+   } else {
+   acpi_handle_err(handle, unexpected returned value by Optimus 
_DSM\n);
+   ACPI_FREE(obj);
+   return -EINVAL;
}
 
return 0;
-- 
2.4.2

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

[Nouveau] [PATCH NEW 5/9] acpi: Use a single type of errors in evaluate functions

[Pierre Moreau]

Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
 drm/nouveau/nouveau_acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 01dbf1d..b837ab1 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -92,7 +92,7 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle handle, 
int func, int arg, u
  func, argv4, ACPI_TYPE_BUFFER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
-   return AE_ERROR;
+   return -EINVAL;
} else {
if (result  obj-buffer.length == 4) {
*result  = obj-buffer.pointer[0];
@@ -142,7 +142,7 @@ static int nouveau_evaluate_mux_dsm(acpi_handle handle, int 
func, int arg)
  func, argv4, ACPI_TYPE_INTEGER);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
-   return AE_ERROR;
+   return -EINVAL;
} else {
if (obj-integer.value == 0x8002)
ret = -ENODEV;
-- 
2.4.2

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