[Bug 88921] System reboots upon suspending when Radeon 5770 card is used
https://bugzilla.kernel.org/show_bug.cgi?id=88921 --- Comment #4 from Eduard Bloch --- Created attachment 162051 --> https://bugzilla.kernel.org/attachment.cgi?id=162051=edit dmesg covering X server lockup This becomes more and more weird. Sometimes I can boot the system and I can suspend it five times per day with no issues. Sometimes it reboots as described in the original description. And sometimes it seems to hang for about 10 seconds before the fans are turned off (this feels like with pre-3.13rcX kernels). When I resume it, the X picture is frozen. But I still can switch to the FB console and kill X from there. However, when X is restarted, it feels slightly sluggish, like having no accelleration in some applications. I haven't tested movie playback or other things in that mode yet, and Firefox freezes at 100% CPU time when I visit some sites like *sic* kernel bugzilla. All that obvservations with the same kernel 3.18.1. I added the dmesg look again, it contains something about r600 exception which looked related. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #29 from Markus Gaugusch --- Hi, I've also verified that commit 32167016076f714f0e35e287fbead7de0f1fb179 breaks my system: 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4250] (prog-if 00 [VGA controller]) The attached patch works fine for me. Without the patch, I can no longer use the DVI connector of my (onboard) graphics card, only VGA works. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 87278] Packet0 not allowed and GPU fault detected errors with Serious Engine games
https://bugs.freedesktop.org/show_bug.cgi?id=87278 --- Comment #13 from Alexandre Demers --- Created attachment 111430 --> https://bugs.freedesktop.org/attachment.cgi?id=111430=edit VM faults and Packet0 error when quitting the current game on R9 270X with today's latest mesa, drm, ddx from git repositories and kernel 3.19-rc1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141228/78e71b92/attachment.html>
[Bug 87278] Packet0 not allowed and GPU fault detected errors with Serious Engine games
https://bugs.freedesktop.org/show_bug.cgi?id=87278 --- Comment #12 from Alexandre Demers --- Sorry, it has been a couple of weeks, but I confirm I have the same problem with my R9 270X. I'm using latest mesa, drm, ddx from git repositories on a 3.19-rc1 kernel. I'll be attaching my log. I'll also test the patch. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141228/d73d351f/attachment.html>
[PATCH] nouveau: fix ambiguous backlight controls
Hi,
On 28-12-14 15:30, Jeremiah Mahler wrote:
> Hans,
>
> On Sat, Dec 27, 2014 at 02:39:42PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 27-12-14 00:51, Jeremiah Mahler wrote:
>>> Ilia,
>>>
>>> On Fri, Dec 26, 2014 at 04:39:08PM -0500, Ilia Mirkin wrote:
On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler
wrote:
> If a display supports backlight control using the nouveau driver, and
> also supports standard ACPI backlight control, there will be two sets of
> controls.
>
> /sys/class/backlight/acpi_video0
> /sys/class/backlight/nv_backlight
>
> This creates ambiguity because these controls can be out of sync with
> each other. One could be at 100% while the other is at 0% and the
> actual display brightness depends on which one was used last. This also
> creates anomalies in Powertop which will show two values for brightness
> with potentially different values.
>
> Fix this ambiguity by having the nouveau driver only enable its
> backlight controls if the standard ACPI controls are not present.
>
> Signed-off-by: Jeremiah Mahler
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index e566c5b..3a52bd4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
> struct nvif_device *device = >device;
> struct drm_connector *connector;
>
> + if (acpi_video_backlight_support()) {
None of the other drivers have this. Is nouveau somehow different
than, say, radeon in this respect?
Unfortunately the backlight situation is pretty fubar'd... sometimes
the acpi controls don't work, sometimes the card controls don't work,
sometimes they both work but in different ways (and then everyone's
favourite -- neither works, and there's some third platform thing).
I'm pretty sure this code existed before, but got removed. See commit
bee564430feec1175ee64bcfd4913cacc519f817 and the previous commit
5bead799d3f8 before that. The ping-pong is probably not the right way
to go.
>>>
>>> I was not aware of that change. But you are right, it took out what I
>>> was trying to put back in.
>>>
>>> Thanks for the helpful information. I will have to rethink this fix.
>>
>> So first of all NAK to the original fix, but I think that much was
>> already clear.
>>
>> Let me explain how this currently works, most laptops have up to 3
>> backlight control interfaces (all talking to the same single backlight):
>>
>> acpi_video: a standardized acpi interface for backlight control, broken on
>> most
>> win8 ready laptops.
>>
>> vendor: e.g. asus_wmi, dell_laptop, etc. typically not much better on
>> win8 ready laptops.
>>
>> native: e.g. intel_backlight, nv_backlight, usually your best bet on win8
>> laptops, but not so much on older models.
>>
>> Before windows8 only 2 of these 3 get registered / exported to userspace,
>> either you've:
>>
>> acpi_video + native:
>>
>> or:
>>
>> vendor + native:
>>
>> Since most vendor drivers contain:
>>
>> if (acpi_video_backlight_support())
>> return 0;
>>
>> And userspace backlight control code knows the prefer the firmware interfaces
>> over the native one and to simply ignore the native interface, unless there
>> is no firmware interface, so having 2 interfaces present in sysfs is not
>> really a problem as userspace knows how to deal with this.
>>
>> So along came Windows 8, breaking most acpi_video implementations. This got
>> fixed by a new module parameter to the acpi_video driver called
>> use_native_backlight,
>> which now a days defaults to 1. When this parameter is true *and* the BIOS is
>> a win8 ready bios, then acpi_video will not register a backlight interface
>> itself,
>> and acpi_video_backlight_support() will still return 1, causing the vendor
>> interfaces
>> to not register. Leaving only the native interface.
>>
> So acpi_video_backlight_support() will return true for win8 even when ACPI
> isn't actually supported.
Well it is supported (the bios has an acpi_video backlight interface), but
drivers/acpi/video.c choses not to register the interface. Note that
video-detect.c
knows nothing about that. As said this is not pretty.
> Could this have been fixed by updating
> acpi_video_backlight_support() function?
In retrospect it would probably have been best to do something akin to adding
a acpi_video_get_backlight_type function when the video.use_native_backlight
kernel option was first introduced.
>
>> Your proposed patch will break things on win8 laptops using nv_backlight,
>> since in the
>> use_native_backlight case it will cause nv_backlight to not register
>> resulting in
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Eric Anholt writes: > Reviewed-by: Eric Anholt Merged. 09230a2..d723928 master -> master -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 810 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141228/e2c71ebe/attachment.sig>
[Bug 87796] radeonsi 120Hz graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=87796 Bug ID: 87796 Summary: radeonsi 120Hz graphic glitches Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: magolobel at yahoo.com.br Created attachment 111427 --> https://bugs.freedesktop.org/attachment.cgi?id=111427=edit video screenshot of the glitch When I enable 120Hz refresh rate in the Radeon R9 290 card, with my Benq XL2420T monitor, I get horizontal glitches in the image. That happens in KDE, Unity, XFCE (all with or without compositing), and games. Without compositing, the windows decorations in KDE show artifacts in 60 and 120Hz. 60Hz refresh rate works okay. Fglx proprietary driver works okay with 120Hz. I also have a Radeon HD 6970 with the radeon OSS driver and it also works okay in 120Hz in my system. Currently I am using Kubuntu 14.10, kernel 3.19RC1 and Mesa git from this PPA: https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa The card is a Sapphire Radeon R9 290 4GB Tri-X. This bug is happening since I got this card, in September. I cant get a direct screenshot nor taking photos (with a smartphone) of the glitch happening, so I take a video of it with a phone and then take a screenshot. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141228/056e7aeb/attachment.html>
[PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd
On 12/26/2014 11:19 AM, Laurent Pinchart wrote: > Hi Thierry, > > On Thursday 25 December 2014 14:20:59 Thierry Reding wrote: >> On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote: >>> This small patch-set, was created to solve the bug described at >>> https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when >>> trying use amdkfd driver on Kaveri). It replaces the previous patch-set >>> called [PATCH 0/3] Use workqueue for device init in amdkfd >>> (http://lists.freedesktop.org/archives/dri-devel/2014-December/074401.html >>> ) >>> >>> That bug appears only when radeon, amdkfd and amd_iommu_v2 are compiled >>> inside the kernel (not as modules). In that case, the correct loading >>> order, as determined by the exported symbol used by each driver, is >>> not enforced anymore and the kernel loads them based on who was linked >>> first. That makes radeon load first, amdkfd second and amd_iommu_v2 >>> third. >>> >>> Because the initialization of a device in amdkfd is initiated by radeon, >>> and can only be completed if amdkfd and amd_iommu_v2 were loaded and >>> initialized, then in the case mentioned above, this initalization fails >>> and there is a kernel panic as some pointers are not initialized but >>> used nontheless. >>> >>> To solve this bug, this patch-set moves iommu/ before gpu/ in >>> drivers/Makefile and also moves amdkfd/ before radeon/ in >>> drivers/gpu/drm/Makefile. >>> >>> The rationale is that in general, AMD GPU devices are dependent on AMD >>> IOMMU controller functionality to allow the GPU to access a process's >>> virtual memory address space, without the need for pinning the memory. >>> That's why it makes sense to initialize the iommu/ subsystem ahead of the >>> gpu/ subsystem. >> >> I strongly object to this patch set. This makes assumptions about how >> the build system influences probe order. That's bad because seemingly >> unrelated changes could easily break this in the future. >> >> We already have ways to solve this kind of dependency (driver probe >> deferral), and I think you should be using it to solve this particular >> problem rather than some linking order hack. > > While I agree with you that probe deferral is the way to go, I believe linkage > ordering can still be used as an optimization to avoid deferring probe in the > most common cases. I'm thus not opposed to moving iommu/ earlier in link order > (provided we can properly test for side effects, as the jump is pretty large), > but not as a replacement for probe deferral. My thoughts exactly. If this was some extreme use case, than it would be justified to solve it with probe deferral. But I think that for most common cases, GPU are dependent on IOMMU and *not* vice-versa. BTW, my first try at solving this was to use probe deferral (using workqueue), but the feedback I got from Christian and Dave was that moving iommu/ linkage before gpu/ was a much more simpler solution. In addition, Linus said he doesn't object to this "band-aid". See: https://lkml.org/lkml/2014/12/25/152 Oded > >> Coincidentally there's a separate thread currently going on that deals >> with IOMMUs and probe order. The solution being worked on is currently >> somewhat ARM-specific, so adding a couple of folks for visibility. It >> looks like we're going to need something more generic since this is a >> problem that even the "big" architectures need to solve. >
[PATCH] amdkfd: actually allocate longs for the pasid bitmask
Commit "amdkfd: use sizeof(long) granularity for the pasid bitmask" calculated
the number of longs it will need, but ended up allocating that number of
bytes rather than longs.
Fix that silly error and allocate the amount of data really required.
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_pasid.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
b/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
index 71699ad..4c25ef5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
@@ -32,7 +32,7 @@ int kfd_pasid_init(void)
{
pasid_limit = max_num_of_processes;
- pasid_bitmap = kzalloc(BITS_TO_LONGS(pasid_limit), GFP_KERNEL);
+ pasid_bitmap = kcalloc(BITS_TO_LONGS(pasid_limit), sizeof(long),
GFP_KERNEL);
if (!pasid_bitmap)
return -ENOMEM;
--
1.7.10.4
[LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel
On 12/25/2014 02:31 PM, Christian König wrote:
> Am 22.12.2014 um 20:18 schrieb Oded Gabbay:
>>
>> On 12/22/2014 09:00 PM, Andi Kleen wrote:
>>> On Mon, Dec 22, 2014 at 10:49:40AM -0800, Andi Kleen wrote:
On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote:
> On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay
> wrote:
>> amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is
>> no
>> point in trying to initialize amdkfd in 32-bit kernel.
>>
>> In addition, in case of specific configuration of 32-bit kernel, no
>> modules and
>> random kernel base, the symbol_request function doesn't work as expected
>> - It
>> doesn't return NULL if the symbol doesn't exists. That makes the kernel
>> panic.
>> Therefore, the as amdkfd doesn't compile in 32-bit kernel, the best way
>> is
>> just
>> to return false immediately.
>>
>> Signed-off-by: Oded Gabbay
> Reviewed-by: Alex Deucher
Sorry but the patch is just bogus. X-bit only code is usually
a very bad sign for the code. This is not windows programing after all.
>> Hi Andi,
>>
>> Strange, I have never programmed for Windows in my life (except maybe in a
>> few courses during my degree) :)
Even if you wanted to do a 64bit only driver -- which
you probably don't -- the standard way would be to exclude
it in Kconfig.
>> So amdkfd actually *only* supports 64bit user processes, because AMD's HSA
>> stack on Linux supports *only* 64bit user processes. So, yes, I definitely
>> want to do a 64bit only driver.
>> If you look at kfd_open(), it fails the open of /dev/kfd if the process is
>> 32bit.
>> In addition, in Kconfig of amdkfd, it is written:
>> "depends on DRM_RADEON && AMD_IOMMU_V2 && X86_64"
>>
>> The problem here is that there is code in radeon, which is a driver that can
>> compile in 32bit, which tries to load amdkfd. I didn't see a point in trying
>> to load a driver which can't be compiled in 32bit.
>
> Well in this case couldn't we make the code in radeon depend on whether or not
> the KFD driver is compiled in or not instead of checking the system
> architecture?
>
> Regards,
> Christian.
>
If we are going down that path, we need something like:
bool radeon_kfd_init(void)
{
#if defined(CONFIG_HSA_AMD_MODULE)
current code (symbol request and call to symbol)
#elif defined(CONFIG_HSA_AMD)
direct call to kgd2kfd_init
#else
return false;
#endif
}
Now, the original concept of the symbol_request call was to prevent writing
something like the above pseudo-code, but because symbol_request is not
currently working in all cases, I think that this is a good band-aid as any.
Oded
>>
Please root-cause why symbol_request doesn't work on 32bit
and fix it properly.
>> I didn't say it doesn't always work.
>> The actual thing that doesn't work is the define symbol_get and only in a
>> specific case of 32bit kernel AND CONFIG_MODULES is unset AND
>> CONFIG_RANDOMIZE_BASE is set.
>> The define in that case is:
>> #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); })
>>
>> Why it doesn't work (doesn't return NULL when symbol doesn't exists) ?
>> I don't know, probably because of some elf/makefile/c language magic. I'm
>> not that big of an expert on those issues, and I wanted to provide a fix for
>> this problem during the -rc stages. If someone can help me solving the root
>> cause, I would be more than happy.
>>
>> Oded
+rusty.
>>> And also with correct email.
>>>
>>> -Andi
>>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 67790] error message on suspend and hibernate: *ERROR* Could not force DPM to low
https://bugs.freedesktop.org/show_bug.cgi?id=67790 xorgx3 at gmail.com changed: What|Removed |Added Priority|medium |high --- Comment #3 from xorgx3 at gmail.com --- Bug still persist in 3.18.1 kernel. And it's very annoying, because in my laptop(Radeon HD5400) I cannot return from suspend/hibernate because of this bug, and I need to restart computer... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141228/b4f18f59/attachment.html>
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #28 from kb at spatium.org --- I think your patch has a typo on line 1002 should be ref_div_max not fb_div_max. Anyway I played with the numbers and I found a config that works for me. See below for all the different combos. Right now I'm running with ref_div_max capped to 2 and going to test it in prolonged use. Any further ideas about this? fb/ref => outcome 4000/13 => mode not supported (message on TV screen) 2000/13 => MNS 1000/13 => MNS 500/13 => MNS 4000/1023 => MNS 2000/1023 => MNS 1000/1023 => MNS 20470/1023 => (nominal value without any capping) flicker 1/1023 => flicker 8000/1023 => different type of flicker, then blank screen 6000/1023 => MNS 20470/13 => flicker 20470/11 => flicker 20470/10 => flicker 20470/9 => very seldom flicker 20470/7 => stable! 20470/2 => stable! -- You are receiving this mail because: You are watching the assignee of the bug.
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Keith Packard writes:
> Eric Anholt writes:
>
>>> --- a/glamor/glamor_xv.c
>>> +++ b/glamor/glamor_xv.c
>>> @@ -435,7 +435,7 @@ glamor_xv_put_image(glamor_port_private *port_priv,
>>> }
>>>
>>> top = (src_y) & ~1;
>>> -nlines = (src_y + height) - top;
>>> +nlines = (src_y + src_h) - top;
>>>
>>> switch (id) {
>>> case FOURCC_YV12:
>>
>> If the point is to upload only from the src_[xywh] recctangle, shouldn't
>> the glamor_upload_sub_pixmap_to_texture() calls be using src_w instead
>> of width, too?
>
> It doesn't need to, but it could as an optimization. Skipping lines at
> the top and bottom is also just an optimization as the source rectangle
> defines a subset of the provided buffer, after all. I just fixed that
> optimization.
FWIW, even as is:
Reviewed-by: Eric Anholt
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141228/727a5dab/attachment.sig>
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Keith Packard writes:
> Eric Anholt writes:
>
>>> --- a/glamor/glamor_xv.c
>>> +++ b/glamor/glamor_xv.c
>>> @@ -435,7 +435,7 @@ glamor_xv_put_image(glamor_port_private *port_priv,
>>> }
>>>
>>> top = (src_y) & ~1;
>>> -nlines = (src_y + height) - top;
>>> +nlines = (src_y + src_h) - top;
>>>
>>> switch (id) {
>>> case FOURCC_YV12:
>>
>> If the point is to upload only from the src_[xywh] recctangle, shouldn't
>> the glamor_upload_sub_pixmap_to_texture() calls be using src_w instead
>> of width, too?
>
> It doesn't need to, but it could as an optimization. Skipping lines at
> the top and bottom is also just an optimization as the source rectangle
> defines a subset of the provided buffer, after all. I just fixed that
> optimization.
glamor_xv_render is trying to scale from dst coords to src coords using
multiplication by src_w / dst_w, though, so if the src pixmap was width
wide instead of src_w wide, I think you'd be rendering wrong.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141228/7f364b5e/attachment-0001.sig>
[PATCH] nouveau: fix ambiguous backlight controls
Hans,
On Sat, Dec 27, 2014 at 02:39:42PM +0100, Hans de Goede wrote:
> Hi,
>
> On 27-12-14 00:51, Jeremiah Mahler wrote:
> >Ilia,
> >
> >On Fri, Dec 26, 2014 at 04:39:08PM -0500, Ilia Mirkin wrote:
> >>On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler
> >>wrote:
> >>>If a display supports backlight control using the nouveau driver, and
> >>>also supports standard ACPI backlight control, there will be two sets of
> >>>controls.
> >>>
> >>>/sys/class/backlight/acpi_video0
> >>>/sys/class/backlight/nv_backlight
> >>>
> >>>This creates ambiguity because these controls can be out of sync with
> >>>each other. One could be at 100% while the other is at 0% and the
> >>>actual display brightness depends on which one was used last. This also
> >>>creates anomalies in Powertop which will show two values for brightness
> >>>with potentially different values.
> >>>
> >>>Fix this ambiguity by having the nouveau driver only enable its
> >>>backlight controls if the standard ACPI controls are not present.
> >>>
> >>>Signed-off-by: Jeremiah Mahler
> >>>---
> >>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
> >>> 1 file changed, 5 insertions(+)
> >>>
> >>>diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> >>>b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> >>>index e566c5b..3a52bd4 100644
> >>>--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> >>>+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> >>>@@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
> >>> struct nvif_device *device = >device;
> >>> struct drm_connector *connector;
> >>>
> >>>+ if (acpi_video_backlight_support()) {
> >>
> >>None of the other drivers have this. Is nouveau somehow different
> >>than, say, radeon in this respect?
> >>
> >>Unfortunately the backlight situation is pretty fubar'd... sometimes
> >>the acpi controls don't work, sometimes the card controls don't work,
> >>sometimes they both work but in different ways (and then everyone's
> >>favourite -- neither works, and there's some third platform thing).
> >>I'm pretty sure this code existed before, but got removed. See commit
> >>bee564430feec1175ee64bcfd4913cacc519f817 and the previous commit
> >>5bead799d3f8 before that. The ping-pong is probably not the right way
> >>to go.
> >>
> >
> >I was not aware of that change. But you are right, it took out what I
> >was trying to put back in.
> >
> >Thanks for the helpful information. I will have to rethink this fix.
>
> So first of all NAK to the original fix, but I think that much was
> already clear.
>
> Let me explain how this currently works, most laptops have up to 3
> backlight control interfaces (all talking to the same single backlight):
>
> acpi_video: a standardized acpi interface for backlight control, broken on
> most
> win8 ready laptops.
>
> vendor: e.g. asus_wmi, dell_laptop, etc. typically not much better on
> win8 ready laptops.
>
> native: e.g. intel_backlight, nv_backlight, usually your best bet on win8
> laptops, but not so much on older models.
>
> Before windows8 only 2 of these 3 get registered / exported to userspace,
> either you've:
>
> acpi_video + native:
>
> or:
>
> vendor + native:
>
> Since most vendor drivers contain:
>
> if (acpi_video_backlight_support())
> return 0;
>
> And userspace backlight control code knows the prefer the firmware interfaces
> over the native one and to simply ignore the native interface, unless there
> is no firmware interface, so having 2 interfaces present in sysfs is not
> really a problem as userspace knows how to deal with this.
>
> So along came Windows 8, breaking most acpi_video implementations. This got
> fixed by a new module parameter to the acpi_video driver called
> use_native_backlight,
> which now a days defaults to 1. When this parameter is true *and* the BIOS is
> a win8 ready bios, then acpi_video will not register a backlight interface
> itself,
> and acpi_video_backlight_support() will still return 1, causing the vendor
> interfaces
> to not register. Leaving only the native interface.
>
So acpi_video_backlight_support() will return true for win8 even when ACPI
isn't actually supported. Could this have been fixed by updating
acpi_video_backlight_support() function?
> Your proposed patch will break things on win8 laptops using nv_backlight,
> since in the
> use_native_backlight case it will cause nv_backlight to not register
> resulting in
> not having any backlight interface at all.
>
> I will happily admit that the combination of acpi_backlight=[video|vendor]
> + video.use_native_backlight=[0|1] which has evolved over time is not the
> prettiest
> solution. IMHO if you want to clean things up, and ensure only one interface
> gets
> registered at a time, the solution would be to change acpi_backlight to also
> take
> a native option, so that on the kernel commandline we end up with only:
> acpi_backlight=[video|vendor|native] and move the use_native_backlight
> handling
>
[PATCH 1/1 linux-next] drm/gma500: replace 0 by NULL for pointer
On Sat, Dec 27, 2014 at 4:37 PM, Fabian Frederick wrote: > Fix sparse warning: > drivers/gpu/drm/gma500/psb_drv.c: > 328:56: warning: Using plain integer as NULL pointer > > Signed-off-by: Fabian Frederick Reviewed-by: Patrik Jakobsson > --- > drivers/gpu/drm/gma500/psb_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/gma500/psb_drv.c > b/drivers/gpu/drm/gma500/psb_drv.c > index 92e7e57..9b49c155 100644 > --- a/drivers/gpu/drm/gma500/psb_drv.c > +++ b/drivers/gpu/drm/gma500/psb_drv.c > @@ -325,7 +325,7 @@ static int psb_driver_load(struct drm_device *dev, > unsigned long flags) > if (ret) > goto out_err; > > - dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0); > + dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, NULL); > if (!dev_priv->mmu) > goto out_err; > > -- > 2.1.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
