I was getting a glicthy checkerboard mess at the cursor in some programs
(konsol+) with
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-2-amd64
root=UUID=4107d1db-62a3-427c-8515-c954a103ce25 ro text quiet
changed the command line in a blind attempt to:
$ cat /proc/cmdline
This patch creates a special group attributes for attrs like "*auto_point*".
We check if we have support for them, and if we do, we gather them all in
an attribute_group's structure which is the parameter regarding special groups
of hwmon_device_register_with_info
We also do the same for
This patch replaces the symbolic permissions with the numeric ones.
Signed-off-by: Oscar Salvador
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
This patch introduces the nouveau_hwmon_ops structure, sets up
.is_visible and .read_string operations and adds all the functions
for these operations.
This is also a preparation for the next patches, where most of the
work is being done.
This code doesn't interacture with the old one.
It's just
This patch removes old code related to the old api and transforms the
functions for the new api. It also adds the .write and .read operations.
Signed-off-by: Oscar Salvador
Reviewed-by: Martin Peres
---
This v6 fixes some comments pointed out by Martin Peres.
Versions:
v1 -> v2:
* Keep temp attrs as read only
v2 -> v3:
* Code fix-ups: struct and string as const and add return within switch
due to fallthrough
* Add Signed-off-by to all commits
v3 -> v4:
*
This is a preparation for the next patches. It just adds the sensors with
their possible configurable settings and then fills the struct
hwmon_channel_info
with all this information.
Signed-off-by: Oscar Salvador
Reviewed-by: Martin Peres
On Mon, May 8, 2017 at 7:50 AM, Vincent Vanackere
wrote:
> Alternatively if you know of a fanless graphic card model that would be able
> to drive 2 monitors at 2560x1440 with proper linux support, I'm interested ;-)
Anything made by AMD will likely work well on
The last goto looks spurious because it releases less resources than the
previous one.
Also free 'img->sig' if 'ls_ucode_img_build()' fails.
Fixes: 9d896f3e41a6 ("drm/nouveau/secboot: abstract LS firmware loading
functions")
Signed-off-by: Christophe JAILLET
---
On 07/05/2017 23:50, Ilia Mirkin wrote:
> You have two issues:
>
> (a) nouveau's GL driver messed something up, causing a read fault error
> (b) nouveau's kernel driver tried to recover. It failed.
>
> Solution to #1: None, really. You can try updating mesa, and hope it
> helps. Not sure what
Hi Christophe,
s/fix some error handling in 'ls_ucode_img_load_gr/plug memory leak in
ls_ucode_img_load_gr() error path/
On 8 May 2017 at 08:46, Christophe JAILLET
wrote:
> The last goto looks spurious because it releases less resources than the
> previous one.
>
On Mon, May 08, 2017 at 10:26:30AM +0200, Daniel Vetter wrote:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.
>
> Cc: Ben Skeggs
> Cc:
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Reviewed-by: Sean Paul
Reviewed-by:
The last goto looks spurious because it releases less resources than the
previous one.
Add a new label in order to free the memory allocated by the 'kmemdup'
call.
Fixes: 9d896f3e41a6 ("drm/nouveau/secboot: abstract LS firmware loading
functions")
Signed-off-by: Christophe JAILLET
14 matches
Mail list logo