Re: [Nouveau] [PATCH REBASED 2/2] nouveau/bl: Do not register interface if Apple GMUX detected
Hi,
On Sun, Apr 17, 2016 at 09:57:42PM +0200, Pierre Moreau wrote:
> The Apple GMUX is the one managing the backlight, so there is no need for
> Nouveau to register its own backlight interface.
>
> Signed-off-by: Pierre Moreau
> ---
> drm/nouveau/nouveau_backlight.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
> index 41330e4..94ac3cb 100644
> --- a/drm/nouveau/nouveau_backlight.c
> +++ b/drm/nouveau/nouveau_backlight.c
> @@ -30,6 +30,7 @@
> * Register locations derived from NVClock by Roderick Colenbrander
> */
>
> +#include
> #include
> #include
>
> @@ -257,6 +258,12 @@ nouveau_backlight_init(struct drm_device *dev)
> struct nvif_device *device = &drm->device;
> struct drm_connector *connector;
>
> + if (apple_gmux_present()) {
> + NV_INFO(drm, "Apple GMUX detected: not registering Nouveau"
> + " backlight interface");
Small nit -- Documentation/CodingStyle, chapter 2 says:
"However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them."
Thanks,
Lukas
> + return 0;
> + }
> +
> INIT_LIST_HEAD(&drm->bl_connectors);
>
> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> --
> 2.8.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 1/2] nouveau/bl: Assign different names to interfaces
Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539
v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_backlight.c | 64 ++---
drm/nouveau/nouveau_display.h | 10 +++
drm/nouveau/nouveau_drm.c | 2 ++
drm/nouveau/nouveau_drm.h | 1 +
4 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 89eb460..41330e4 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -31,11 +31,31 @@
*/
#include
+#include
#include "nouveau_drm.h"
#include "nouveau_reg.h"
#include "nouveau_encoder.h"
+static struct ida bl_ida;
+
+struct backlight_connector {
+ struct list_head head;
+ int id;
+};
+
+static void
+nouveau_get_backlight_name(char backlight_name[15], struct backlight_connector
+ *connector)
+{
+ const int nb = ida_simple_get(&bl_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 = &drm->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(&props, 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, &bl_connector);
+ bd = backlight_device_register(backlight_name , connector->kdev, drm,
&nv40_bl_ops, &props);
- if (IS_ERR(bd))
+
+ if (IS_ERR(bd)) {
+ if (bl_connector.id > 0)
+ ida_simple_remove(&bl_ida, bl_connector.id);
return PTR_ERR(bd);
+ }
+ list_add(&bl_connector.head, &drm->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(&props, 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, &bl_connector);
+ bd = backlight_device_register(backlight_name , connector->kdev,
nv_encoder, ops, &props);
- if (IS_ERR(bd))
+
+ if (IS_ERR(bd)) {
+ if (bl_connector.id > 0)
+ ida_simple_remove(&bl_ida, bl_connector.id);
return PTR_ERR(bd);
+ }
+ list_add(&bl_connector.head, &drm->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 = &drm->device;
struct drm_connector *connector;
+ INIT_LIST_HEAD(&drm->bl_connectors);
+
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
@@ -246,9 +284,27 @@
[Nouveau] [PATCH REBASED 2/2] nouveau/bl: Do not register interface if Apple GMUX detected
The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 41330e4..94ac3cb 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -30,6 +30,7 @@
* Register locations derived from NVClock by Roderick Colenbrander
*/
+#include
#include
#include
@@ -257,6 +258,12 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = &drm->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(&drm->bl_connectors);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
--
2.8.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91523] [NVE7] driver cannot initialize gpu(failed to parse ramcfg data)
https://bugs.freedesktop.org/show_bug.cgi?id=91523 --- Comment #3 from Ilia Bozhinov --- It seems that the code that triggers this bug is in drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.cpp around line 1583. It seems that the assumption in the comment is not true, on my card this condition obviously doesn't mean that the card should be ignored completely. This maybe has some other meaning, does anybody know how I can help debugging the problem? I'm posting the comment in the code: /* parse bios data for all rammap table entries up-front, and * build information on whether certain fields differ between * any of the entries. * * the binary driver appears to completely ignore some fields * when all entries contain the same value. at first, it was * hoped that these were mere optimisations and the bios init * tables had configured as per the values here, but there is * evidence now to suggest that this isn't the case and we do * need to treat this condition as a "don't touch" indicator. */ -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0
https://bugs.freedesktop.org/show_bug.cgi?id=93458 Ilia Mirkin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Ilia Mirkin --- This should be now upstream with commit 78a121d82da8aff3aca2a6a1c40f5061081760f0 Author: Ilia Mirkin Date: Sun Mar 6 16:06:06 2016 -0500 drm/nouveau/core: use vzalloc for allocating ramht Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a fairly sizeable chunk of memory to be allocated, which may not be available with kzalloc. Since this is done fairly rarely (once per channel), use vzalloc instead. Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Zlatko - I didn't realize (or perhaps totally forgot) you had provided the same patch, didn't mean to steal credit or anything like that. Just ran into the same issue myself and sent a patch. In the future, feel free to send patches to the mailing list. This issue should be resolved in v4.6-rc1+. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94342] Nvidia G96GLM 3840x2160@30 not functional with nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=94342 --- Comment #4 from Elmar Stellnberger --- 4.6.0-rc2-ARCH-4-g603539d: As soon as I boot with a hdmimhz=297 I get a blackscreen though the graphics card is known to work with 3840x2160@30 under Windows; i.e. that should work. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93887] [NV96] Amilo Xi 3650: G96M [GeForce 9600M GT]: HDMI monitor stays black after s2ram
https://bugs.freedesktop.org/show_bug.cgi?id=93887 --- Comment #17 from Elmar Stellnberger --- Created attachment 123007 --> https://bugs.freedesktop.org/attachment.cgi?id=123007&action=edit journal: delayed wakeup with Celsius on 4.6.0-rc2 Now I have also tried it with the Celsius; s2ram has significantly improved since my last test as the machine never crashed. At first bootup 3 s2rams worked ok and at the second bootup the same problem as before seemed to appear: the original screen content flashed up then the monitor turning black again thereafter immediately. However this time Num Lock was still working and I could make the machine come up again by pressing Ctrl-Alt-Entf on the integrated keyboard (which I did for both s2ram tests on the second bootup after a minute or so). External monitor staying black after s2ram; also here with the Celsius and kernel 4.6.0-rc2. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0
https://bugs.freedesktop.org/show_bug.cgi?id=93458 --- Comment #7 from Matt Whitlock --- FYI: Ilia Mirkin submitted the patch from Comment 4 to the Nouveau listserv on 6 Mar 2016. I think I'll apply this patch to my 4.4.7 kernel. http://permalink.gmane.org/gmane.comp.freedesktop.xorg.nouveau/24081 -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces
[…] > > > + const int nb = atomic_inc_return(&bl_interfaces_nb) - 1; > > This kinda sucks if you reload nouveau a bunch. How about using an > "ida". Have a look in drivers/gpu/drm/drm_crtc.c for how I use that > one. I had a quick look at drm_crtc.c. This seems to be exactly what I need, except that I do not see how I can enforce to have one of the active ones being named `nv_backlight`, to not break (possibly) existing userspace applications. (I’m guessing that I would be doing the same as in drm_crtc.c: looping over all connectors and assigning them an ida, regardless of them being active or not, as they might become active later on.) There is another issue that I failed to address with this patch, and just realised about it. Each time `nvXX_backlight_init(connector)` is called on a connector, a new backlight device is created, and is stored in `drm->backlight`, which is unique at a device level, not connector level, meaning the old one just gets overriden (and leaked). Having a list `drm->backlights` should solve this issue. Would that be fine with you Ben? Pierre > > > + if (nb > 0 && nb < 100) > > + sprintf(backlight_name, "nv_backlight%d", nb); > > + else > > + sprintf(backlight_name, "nv_backlight"); > > + return backlight_name; > > +} > > -- > > 2.8.0 > > > > ___ > > Nouveau mailing list > > Nouveau@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/nouveau signature.asc Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0
https://bugs.freedesktop.org/show_bug.cgi?id=93458 --- Comment #6 from Matt Whitlock --- (In reply to Matt Whitlock from comment #5) > I would venture a guess that the memory allocated for a GPU FIFO buffer > needs to be physically continuous, as it will be used for DMA I take it back. Looking into the source code, the allocation is happening in nvkm_ramht_new(â¦), which is allocating a struct nvkm_ramht containing a variably-sized array of struct nvkm_ramht_data elements. As these elements, in turn, contain pointers, it seems very unlikely that they'd be DMA'd, so presumably the struct nvkm_ramht doesn't need to be physically contiguous and could safely be allocated by vzalloc(â¦). -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
