Re: i915 freakout with latest 3.7 git
On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote: Ok, but in comment 11 in the same thread you mention that reverting this patch didn't fix the issue for you: Reverting that commit on top of 3.7-rc4 did not fix the hang issue. The bisected commit was from between rc2 and rc3: $ git describe 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 v3.6-rc2-88-g504c726 The fact that reverting that commit does not help implies that some commits thereafter also expose the bug. i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you probably hit another bug. I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE compositor. Now I'm trying to hit the bug again... Do you have a reliable reproduce method? As you can see in the linked bug it was caused by relatively low memory pressure combined with high I/O (caching? delays? Who knows). A shot in the dark: could it be that all the machines wich encounter this hang have nvidia's optimus? Mine has. Could that somehow be related? (I'm by no means a programmer or a kernel hacker..). It is unlikely that Optimus has anything to do with this. Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 freakout with latest 3.7 git
On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote: > Ok, but in comment 11 in the same thread you mention that reverting > this patch didn't fix the issue for you: > > "Reverting that commit on top of 3.7-rc4 did not fix the hang issue." The bisected commit was from between rc2 and rc3: $ git describe 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 v3.6-rc2-88-g504c726 The fact that reverting that commit does not help implies that some commits thereafter also expose the bug. > > i915.i915_enable_rc6=0 worked for me, if it does not work for you, then > > you probably hit another bug. > > I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE > compositor. Now I'm trying to hit the bug again... Do you have a reliable reproduce method? As you can see in the linked bug it was caused by relatively low memory pressure combined with high I/O (caching? delays? Who knows). > A shot in the dark: could it be that all the machines wich encounter > this hang have nvidia's optimus? Mine has. Could that somehow be > related? (I'm by no means a programmer or a kernel hacker..). It is unlikely that Optimus has anything to do with this. Peter
i915 freakout with latest 3.7 git
On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote: > Btw: which kernel is known to be the "last good one"? As mentioned in the linked bug [1], I bisected it to: commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 Author: Chris Wilson Date: Thu Aug 23 13:12:52 2012 +0100 drm/i915: Use cpu relocations if the object is in the GTT but not mappable > > (you need to disable rc6 on ilk to not hit another issue which seems much > > easier to hit) > > Ilk? If this stands for "Ironlake": I'm on Sandybridge. > > > ... > > Bisecting will be a pain without being able to reproduce > the hang reliably. > > > Atm we're trying to come up with ways to dump more debug > > information, >but with no clue whatsoever what's going on that's > > slow-going. > Is there anything at the moment I can do to help you to get a grip on > this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus > U45-JC). i5-420M is not SB, but ILK. i5-2xxx is SB. I have a i5-460M myself. i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you probably hit another bug. Peter [1]: https://bugs.freedesktop.org/show_bug.cgi?id=55984#c9
[bisected] drm i915 hangs on heavy io load
On Sunday 04 November 2012 16:08:47 Dave Airlie wrote: > On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining > wrote: > > On Di, 30 Okt 2012, Dave Airlie wrote: > >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 > >> final to 3.7-rc1 or maybe -rc2. > > > > Sorry for my ignorance ... I did on master branch > > > > $ git checkout v3.7-rc1 > > ... > > $ git bisect start drivers/gpu/drm/i915 > > $ git bisect bad > > $ git bisect good v3.6 > > Bisecting: 121 revisions left to test after this (roughly 7 steps) > > [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new > > set_mode code flow $ > > > > after that I am back somewhere around > > > > 3.6.0-rc2 > > > > ??? > > > > Am I doing something wrong? I thought I am bisecting between 3.6 and > > 3.7.-rc2? How can I go back to 3.6.0-rc2? > > Yeah thats fine, bisecting works by going to where commits were > originally committed, so drm-intel-next was 3.6.0-rc2 at some point > was only merged into Linus later. As I mentioned on https://bugs.freedesktop.org/show_bug.cgi?id=55984, I also hit this bug. The first time was on branch drm-intel-next-2012-09-20 on Daniel Vetters drm-intel git. I guess it has something to do with low memory. To reproduce the bug on my laptop with 8GB RAM and a i5-460M, I did: 1. Boot (I use KDE) 3. Start glxspheres (from http://virtualgl.org/, but glxgears might work too, not tested) 2. Copy a 1.2 GiB Linux source tree to /dev/shm and /tmp (both tmpfs), 5 times. This uses 6GiB of RAM. I used this bash script: #!/bin/bash for i in /tmp/hang-l1 /tmp/hang-l2 /tmp/hang-l3 \ /dev/shm/hang-l1 /dev/shm/hang-l2; do cp -ra ~/Linux-src/linux "$i" & done; wait 3. When the copy is almost done, watch the machine become sluggish and eventually print the "[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung" message to the kernel log. Until the machine is rebooted, all OpenGL applications will fail to load. On kernels where it was working fine, there is no lag when the copy is almost finished. 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 is the first bad commit commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 Author: Chris Wilson Date: Thu Aug 23 13:12:52 2012 +0100 drm/i915: Use cpu relocations if the object is in the GTT but not mappable This prevents the case of unbinding the object in order to process the relocations through the GTT and then rebinding it only to then proceed to use cpu relocations as the object is now in the CPU write domain. By choosing to use cpu relocations up front, we can therefore avoid the rebind penalty. Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter :04 04 090ed3d52b4f3210b988877f747b6ff86e123385 1d48be89ded4777a543b693db833de64877059c4 M drivers Regards, Peter
[bisected] drm i915 hangs on heavy io load
On Sunday 04 November 2012 16:08:47 Dave Airlie wrote: On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining prein...@logic.at wrote: On Di, 30 Okt 2012, Dave Airlie wrote: I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 final to 3.7-rc1 or maybe -rc2. Sorry for my ignorance ... I did on master branch $ git checkout v3.7-rc1 ... $ git bisect start drivers/gpu/drm/i915 $ git bisect bad $ git bisect good v3.6 Bisecting: 121 revisions left to test after this (roughly 7 steps) [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new set_mode code flow $ after that I am back somewhere around 3.6.0-rc2 ??? Am I doing something wrong? I thought I am bisecting between 3.6 and 3.7.-rc2? How can I go back to 3.6.0-rc2? Yeah thats fine, bisecting works by going to where commits were originally committed, so drm-intel-next was 3.6.0-rc2 at some point was only merged into Linus later. As I mentioned on https://bugs.freedesktop.org/show_bug.cgi?id=55984, I also hit this bug. The first time was on branch drm-intel-next-2012-09-20 on Daniel Vetters drm-intel git. I guess it has something to do with low memory. To reproduce the bug on my laptop with 8GB RAM and a i5-460M, I did: 1. Boot (I use KDE) 3. Start glxspheres (from http://virtualgl.org/, but glxgears might work too, not tested) 2. Copy a 1.2 GiB Linux source tree to /dev/shm and /tmp (both tmpfs), 5 times. This uses 6GiB of RAM. I used this bash script: #!/bin/bash for i in /tmp/hang-l1 /tmp/hang-l2 /tmp/hang-l3 \ /dev/shm/hang-l1 /dev/shm/hang-l2; do cp -ra ~/Linux-src/linux $i done; wait 3. When the copy is almost done, watch the machine become sluggish and eventually print the [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung message to the kernel log. Until the machine is rebooted, all OpenGL applications will fail to load. On kernels where it was working fine, there is no lag when the copy is almost finished. 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 is the first bad commit commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 23 13:12:52 2012 +0100 drm/i915: Use cpu relocations if the object is in the GTT but not mappable This prevents the case of unbinding the object in order to process the relocations through the GTT and then rebinding it only to then proceed to use cpu relocations as the object is now in the CPU write domain. By choosing to use cpu relocations up front, we can therefore avoid the rebind penalty. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :04 04 090ed3d52b4f3210b988877f747b6ff86e123385 1d48be89ded4777a543b693db833de64877059c4 M drivers Regards, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sunday 21 October 2012 16:49:08 Marcin Slusarz wrote:
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
This looks like ACPI bug...
I'm shocked to hear that firmware would be fragile.
Anyway, here's the #1 thing to keep in mind about firmware:
- firmware is always buggy.
I know. But this bug is not about broken firmware. It's about Linux kernel
ACPI implementation, which (I think) wrongly interprets ACPI script.
The ACPI implementation is fine, it is just the fw engineers that suck. I see I
have not cc'd the linux-vger ml when replying to a previous mail. I'll paste
it below:
Since commit 9a334cd drm/nouveau/bios: fix shadowing of ACPI ROMs larger than
64KiB chunks are not always read in multiples of 4KiB anymore (less is
possible). That is the only obvious thing I can think of atm (besides the
kmalloc(0) bug for which Martin submitted a patch in the previous mail).
Do you still still have an Asus laptop with the same BIOS as in
https://bugzilla.kernel.org/show_bug.cgi?id=19702? (if yes, then the acpidump
from that bug still applies).
This is the ACPI _ROM method that is being called:
Method (_ROM, 2, NotSerialized) // _ROM: Read-Only Memory
{
Add (Arg0, RBUF, Local0)
ShiftLeft (Arg1, 0x03, Local1) // times 8, bytes to bits?
Name (VBUF, Buffer (Arg1) {})
OperationRegion (VROM, SystemMemory, Local0, Local1)
Field (VROM, ByteAcc, NoLock, Preserve)
{
ROMI, 65536
}
Store (ROMI, VBUF)
Return (VBUF)
}
Arg0 is the offset (0 when first reading the size), Arg1 is the number of read
bytes (3). Note the use of Local1 in OperationRegion. The meaning there is
bytes, but a multiple of the requested bytes is passed. So if we request 4096
bytes, we end up with a VROM of size 32KiB. ROMI is 65536 bits (or 8192
bytes), hence reading 4096 does not give errors. But reading only 3 bytes will
fail. Martin, I saw your second patch (https://lkml.org/lkml/2012/10/20/150)
which takes care of the first case, but it skips the case where the ROM is of
an odd size (does that even happen, something like 64KiB+1 bytes? No idea.)
Addition: Conclusion: this means that the request must have a length must be
at least 1 KiB or it will fail with the ACPI error that you have seen before.
This AML snippet suck.
Regards,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sunday 21 October 2012 16:49:08 Marcin Slusarz wrote:
> On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> >
> > wrote:
> > > This looks like ACPI bug...
> >
> > I'm shocked to hear that firmware would be fragile.
> >
> > Anyway, here's the #1 thing to keep in mind about firmware:
> >
> > - firmware is always buggy.
>
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.
The ACPI implementation is fine, it is just the fw engineers that suck. I see I
have not cc'd the linux-vger ml when replying to a previous mail. I'll paste
it below:
Since commit 9a334cd "drm/nouveau/bios: fix shadowing of ACPI ROMs larger than
64KiB" chunks are not always read in multiples of 4KiB anymore (less is
possible). That is the only obvious thing I can think of atm (besides the
kmalloc(0) bug for which Martin submitted a patch in the previous mail).
Do you still still have an Asus laptop with the same BIOS as in
https://bugzilla.kernel.org/show_bug.cgi?id=19702? (if yes, then the acpidump
from that bug still applies).
This is the ACPI _ROM method that is being called:
Method (_ROM, 2, NotSerialized) // _ROM: Read-Only Memory
{
Add (Arg0, RBUF, Local0)
ShiftLeft (Arg1, 0x03, Local1) // times 8, bytes to bits?
Name (VBUF, Buffer (Arg1) {})
OperationRegion (VROM, SystemMemory, Local0, Local1)
Field (VROM, ByteAcc, NoLock, Preserve)
{
ROMI, 65536
}
Store (ROMI, VBUF)
Return (VBUF)
}
Arg0 is the offset (0 when first reading the size), Arg1 is the number of read
bytes (3). Note the use of Local1 in OperationRegion. The meaning there is
bytes, but a multiple of the requested bytes is passed. So if we request 4096
bytes, we end up with a VROM of size 32KiB. ROMI is 65536 bits (or 8192
bytes), hence reading 4096 does not give errors. But reading only 3 bytes will
fail. Martin, I saw your second patch (https://lkml.org/lkml/2012/10/20/150)
which takes care of the first case, but it skips the case where the ROM is of
an odd size (does that even happen, something like 64KiB+1 bytes? No idea.)
Addition: Conclusion: this means that the request must have a length must be
at least 1 KiB or it will fail with the ACPI error that you have seen before.
This AML snippet suck.
Regards,
Peter
Re: [PATCH 3/5] nouveau: Add interface to detect optimus support
Hi Dave,
+bool nouveau_is_optimus(void) {
+ return nouveau_dsm_priv.optimus_detected;
+}
This will only work for new Optimus laptops, not the older ones such as your
Lenovo T410s or on a Dell Vostro 3500 with a GT 310M. Is that intended? If
not, check for those models too:
return nouveau_dsm_priv.optimus_detected ||
nouveau_dsm_priv.dsm_detected;
Regards,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] nouveau: Add interface to detect optimus support
Hi Dave,
> +bool nouveau_is_optimus(void) {
> + return nouveau_dsm_priv.optimus_detected;
> +}
This will only work for new Optimus laptops, not the older ones such as your
Lenovo T410s or on a Dell Vostro 3500 with a GT 310M. Is that intended? If
not, check for those models too:
return nouveau_dsm_priv.optimus_detected ||
nouveau_dsm_priv.dsm_detected;
Regards,
Peter
[PATCH] i915: initialize CADL in opregion
On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote: > On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter wrote: > > - When loading the i915.ko with the CADL patch the screen went black > > (like at boot), but with some excessive vt-switching and X restarting > > I've managed to light it up. Although it is flickery as hell, > > especially the lower part of the screen. And if the screen is somewhat > > stable, I just get the upper part of the screen duplicated in the > > lower part. > > Just a small note: Reloading i915.ko without the CADL patch fixes > things. No idea how that could happen ... > -Daniel Does CADL gets reinitialised to zeroes on module load? (I think so, but could you verify that by checking the contents of that field after loading the module w/ and w/o the CADL patch?) Peter
[PATCH] i915: initialize CADL in opregion
On Wednesday 27 June 2012 18:27:37 Daniel Vetter wrote: > On Wed, Jun 27, 2012 at 05:09:02PM +0200, Lekensteyn wrote: > > On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote: > > > On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote: > > > > On Tue, Jun 26, 2012 at 02:04:00PM -0700, Jesse Barnes wrote: > > > > > On Tue, 26 Jun 2012 00:36:24 +0200 > > > > > > > > > > Lekensteyn wrote: > > > > > > This is rather a hack to fix brightness hotkeys on a Clevo laptop. > > > > > > CADL is not used anywhere in the driver code at the moment, but it > > > > > > could be used in BIOS as is the case with the Clevo laptop. > > > > > > > > > > > > The Clevo B7130 requires the CADL field to contain at least the ID > > > > > > of > > > > > > the LCD device. If this field is empty, the ACPI methods that are > > > > > > called > > > > > > on pressing brightness / display switching hotkeys will not > > > > > > trigger a > > > > > > notification. As a result, it appears as no hotkey has been > > > > > > pressed. > > > > > > > > > > Not ideal, but definitely better than nothing. > > > > > > > > > > Acked-by: Jesse Barnes > > > > > > > > Queued for -next, thanks for the patch. > > > > > > Unfortunately this results in a neat black screen on my ivb zenbook. > > > Until > > > I've figured out what exactly's going on, I have to drop this from -next > > > again. > > > -Daniel > > > > Can you share your acpidump on > > https://bugs.freedesktop.org/show_bug.cgi?id=45452 ? > > Attached. > -Daniel Thank you, I've now written a partial analysis which is available at https://github.com/Lekensteyn/acpi- stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is cut in two parts in this mail, concat them as needed). Question: can you try disabling the asus-laptop module and try booting again w/ and w/o the CADL patch applied? - Does it boot in both cases? - Do the brightness hotkeys work? - Can you change brightness via /sys/class/backlight? Can you SSH in it and check the logs? Any ACPI warnings/errors or messages from the asus-laptop module? (or whatever asus module(s) is/are loaded) Can you also generate dmidecode.txt? (peek in http://lekensteyn.nl/files/get- acpi-info.sh, you do not have to run all of the commands since I already have your acpidump) Thanks, Peter
Re: [PATCH] i915: initialize CADL in opregion
On Wednesday 27 June 2012 18:27:37 Daniel Vetter wrote: On Wed, Jun 27, 2012 at 05:09:02PM +0200, Lekensteyn wrote: On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote: On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote: On Tue, Jun 26, 2012 at 02:04:00PM -0700, Jesse Barnes wrote: On Tue, 26 Jun 2012 00:36:24 +0200 Lekensteyn lekenst...@gmail.com wrote: This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop. The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is empty, the ACPI methods that are called on pressing brightness / display switching hotkeys will not trigger a notification. As a result, it appears as no hotkey has been pressed. Not ideal, but definitely better than nothing. Acked-by: Jesse Barnes jbar...@virtuousgeek.org Queued for -next, thanks for the patch. Unfortunately this results in a neat black screen on my ivb zenbook. Until I've figured out what exactly's going on, I have to drop this from -next again. -Daniel Can you share your acpidump on https://bugs.freedesktop.org/show_bug.cgi?id=45452 ? Attached. -Daniel Thank you, I've now written a partial analysis which is available at https://github.com/Lekensteyn/acpi- stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is cut in two parts in this mail, concat them as needed). Question: can you try disabling the asus-laptop module and try booting again w/ and w/o the CADL patch applied? - Does it boot in both cases? - Do the brightness hotkeys work? - Can you change brightness via /sys/class/backlight? Can you SSH in it and check the logs? Any ACPI warnings/errors or messages from the asus-laptop module? (or whatever asus module(s) is/are loaded) Can you also generate dmidecode.txt? (peek in http://lekensteyn.nl/files/get- acpi-info.sh, you do not have to run all of the commands since I already have your acpidump) Thanks, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: initialize CADL in opregion
On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote: On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter dan...@ffwll.ch wrote: - When loading the i915.ko with the CADL patch the screen went black (like at boot), but with some excessive vt-switching and X restarting I've managed to light it up. Although it is flickery as hell, especially the lower part of the screen. And if the screen is somewhat stable, I just get the upper part of the screen duplicated in the lower part. Just a small note: Reloading i915.ko without the CADL patch fixes things. No idea how that could happen ... -Daniel Does CADL gets reinitialised to zeroes on module load? (I think so, but could you verify that by checking the contents of that field after loading the module w/ and w/o the CADL patch?) Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: initialize CADL in opregion
On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote: > On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote: > > On Tue, Jun 26, 2012 at 02:04:00PM -0700, Jesse Barnes wrote: > > > On Tue, 26 Jun 2012 00:36:24 +0200 > > > > > > Lekensteyn wrote: > > > > This is rather a hack to fix brightness hotkeys on a Clevo laptop. > > > > CADL is not used anywhere in the driver code at the moment, but it > > > > could be used in BIOS as is the case with the Clevo laptop. > > > > > > > > The Clevo B7130 requires the CADL field to contain at least the ID of > > > > the LCD device. If this field is empty, the ACPI methods that are > > > > called > > > > on pressing brightness / display switching hotkeys will not trigger a > > > > notification. As a result, it appears as no hotkey has been pressed. > > > > > > Not ideal, but definitely better than nothing. > > > > > > Acked-by: Jesse Barnes > > > > Queued for -next, thanks for the patch. > > Unfortunately this results in a neat black screen on my ivb zenbook. Until > I've figured out what exactly's going on, I have to drop this from -next > again. > -Daniel Can you share your acpidump on https://bugs.freedesktop.org/show_bug.cgi?id=45452 ? TIA Peter
Re: [PATCH] i915: initialize CADL in opregion
On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote: On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote: On Tue, Jun 26, 2012 at 02:04:00PM -0700, Jesse Barnes wrote: On Tue, 26 Jun 2012 00:36:24 +0200 Lekensteyn lekenst...@gmail.com wrote: This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop. The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is empty, the ACPI methods that are called on pressing brightness / display switching hotkeys will not trigger a notification. As a result, it appears as no hotkey has been pressed. Not ideal, but definitely better than nothing. Acked-by: Jesse Barnes jbar...@virtuousgeek.org Queued for -next, thanks for the patch. Unfortunately this results in a neat black screen on my ivb zenbook. Until I've figured out what exactly's going on, I have to drop this from -next again. -Daniel Can you share your acpidump on https://bugs.freedesktop.org/show_bug.cgi?id=45452 ? TIA Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: initialize CADL in opregion
This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not
used anywhere in the driver code at the moment, but it could be used in BIOS as
is the case with the Clevo laptop.
The Clevo B7130 requires the CADL field to contain at least the ID of
the LCD device. If this field is empty, the ACPI methods that are called
on pressing brightness / display switching hotkeys will not trigger a
notification. As a result, it appears as no hotkey has been pressed.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452
Tested-by: Peter Wu
Signed-off-by: Peter Wu
---
drivers/gpu/drm/i915/intel_opregion.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 18bd0af..adf6c79 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -427,6 +427,25 @@ blind_set:
goto end;
}
+static void intel_setup_cadls(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_opregion *opregion = _priv->opregion;
+ int i = 0;
+ u32 disp_id;
+
+ /* Initialize the CADL field by duplicating the DIDL values.
+* Technically, this is not always correct as display outputs may exist,
+* but not active. This initialization is necessary for some Clevo
+* laptops that check this field before processing the brightness and
+* display switching hotkeys. Just like DIDL, CADL is NULL-terminated if
+* there are less than eight devices. */
+ do {
+ disp_id = ioread32(>acpi->didl[i]);
+ iowrite32(disp_id, >acpi->cadl[i]);
+ } while (++i < 8 && disp_id != 0);
+}
+
void intel_opregion_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -436,8 +455,10 @@ void intel_opregion_init(struct drm_device *dev)
return;
if (opregion->acpi) {
- if (drm_core_check_feature(dev, DRIVER_MODESET))
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
intel_didl_outputs(dev);
+ intel_setup_cadls(dev);
+ }
/* Notify BIOS we are ready to handle ACPI video ext notifs.
* Right now, all the events are handled by the ACPI video
module.
--
1.7.11
[PATCH] i915: initialize CADL in opregion
This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not
used anywhere in the driver code at the moment, but it could be used in BIOS as
is the case with the Clevo laptop.
The Clevo B7130 requires the CADL field to contain at least the ID of
the LCD device. If this field is empty, the ACPI methods that are called
on pressing brightness / display switching hotkeys will not trigger a
notification. As a result, it appears as no hotkey has been pressed.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452
Tested-by: Peter Wu lekenst...@gmail.com
Signed-off-by: Peter Wu lekenst...@gmail.com
---
drivers/gpu/drm/i915/intel_opregion.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 18bd0af..adf6c79 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -427,6 +427,25 @@ blind_set:
goto end;
}
+static void intel_setup_cadls(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_opregion *opregion = dev_priv-opregion;
+ int i = 0;
+ u32 disp_id;
+
+ /* Initialize the CADL field by duplicating the DIDL values.
+* Technically, this is not always correct as display outputs may exist,
+* but not active. This initialization is necessary for some Clevo
+* laptops that check this field before processing the brightness and
+* display switching hotkeys. Just like DIDL, CADL is NULL-terminated if
+* there are less than eight devices. */
+ do {
+ disp_id = ioread32(opregion-acpi-didl[i]);
+ iowrite32(disp_id, opregion-acpi-cadl[i]);
+ } while (++i 8 disp_id != 0);
+}
+
void intel_opregion_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -436,8 +455,10 @@ void intel_opregion_init(struct drm_device *dev)
return;
if (opregion-acpi) {
- if (drm_core_check_feature(dev, DRIVER_MODESET))
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
intel_didl_outputs(dev);
+ intel_setup_cadls(dev);
+ }
/* Notify BIOS we are ready to handle ACPI video ext notifs.
* Right now, all the events are handled by the ACPI video
module.
--
1.7.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
