kernel paging request at fff8
IP: [f7fac57f] i915_gem_evict_something+0xef/0x230 [i915]
...
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/char/agp/intel-agp.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp
At Mon, 23 Aug 2010 09:35:07 +0800,
Zhenyu Wang wrote:
On 2010.08.20 17:36:08 +0200, Takashi Iwai wrote:
Sandybridge requires 36bit dma mask, but the current code checks only
against i965, thus it gives Oops with i915 probing on 32bit machine:
nommu_map_sg: overflow 14a00+4096
At Mon, 23 Aug 2010 13:43:03 +0800,
Zhenyu Wang wrote:
On 2010.08.23 07:29:29 +0200, Takashi Iwai wrote:
Sandybridge can do 40-bit dma mask. This has been fixed upstream now.
Could you point where is the upstream GIT tree and the corresponding
commit id?
Linus's tree:
commit
At Mon, 23 Aug 2010 08:02:42 +0200,
I wrote:
At Mon, 23 Aug 2010 13:43:03 +0800,
Zhenyu Wang wrote:
On 2010.08.23 07:29:29 +0200, Takashi Iwai wrote:
Sandybridge can do 40-bit dma mask. This has been fixed upstream now.
Could you point where is the upstream GIT tree
At Mon, 23 Aug 2010 14:19:22 +0800,
Zhenyu Wang wrote:
On 2010.08.23 08:02:42 +0200, Takashi Iwai wrote:
Also, I don't understand the logic of 40bit addr calculation:
static unsigned long intel_gen6_mask_memory(struct agp_bridge_data
*bridge
Add a missing NULL check and fix the wrong address passed to kunmap()
in i830_cleanup().
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/char/agp/intel-gtt.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel
At Wed, 22 Dec 2010 16:59:06 +,
Chris Wilson wrote:
On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai ti...@suse.de wrote:
The commit 448f53a1ede54eb854d036abf54573281412d650
drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge machine here
://bugzilla.kernel.org/show_bug.cgi?id=26952
https://bugzilla.kernel.org/show_bug.cgi?id=27272
I quickly tried these patches. After adding the missing EXPORT_SYMBOL,
it seems working fine. Tested on a SNB laptop and a PineView laptop.
Put my tag to all patches:
Tested-by: Takashi Iwai ti...@suse.de
At Thu, 3 Feb 2011 07:42:05 -0800,
Linus Torvalds wrote:
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra crmaf...@gmail.com wrote:
On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
If you know of any other unresolved post-2.6.36 regressions, please let us
know
either and
At Thu, 3 Feb 2011 17:11:14 -0800,
Linus Torvalds wrote:
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard kei...@keithp.com wrote:
The goal is to make it so that when you *do* set a mode, DPMS gets set
to ON (as the monitor will actually be on at that point). Here's a
patch which does the
At Thu, 10 Mar 2011 08:49:37 +0100,
Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
Alex, can you confirm that the revert of 951f3512dba5 plus the
one-liner patch from Takashi
At Thu, 10 Mar 2011 09:45:18 +0100 (CET),
Indan Zupancic wrote:
On Thu, March 10, 2011 08:49, Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
Alex, can you confirm that the revert
At Thu, 10 Mar 2011 11:06:28 +0100 (CET),
Indan Zupancic wrote:
On Thu, March 10, 2011 09:25, Takashi Iwai wrote:
At Thu, 10 Mar 2011 08:49:37 +0100,
Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47
-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/i915/i915_reg.h| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 36
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
good to me. A nice clean-up.
Reviewed-by: Takashi Iwai ti...@suse.de
thanks,
Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
At Sun, 17 Apr 2011 18:26:54 +0200,
Florian Mickler wrote:
On Wed, 22 Dec 2010 12:53:07 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 22 Dec 2010 12:42:32 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
From: Takashi Iwai ti...@suse.de
This patch adds a new
At Fri, 29 Apr 2011 19:41:53 +0200,
Melchior FRANZ wrote:
* Takashi Iwai -- Friday 29 April 2011:
Melchior FRANZ wrote:
The bug was introduced with commit
ba3820ade317ee36e496b9b40d2ec3987dd4aef0
[...] when using KMS my notebook's[2] screen remains dark, because the
backlight
At Fri, 29 Apr 2011 22:09:54 +0200,
Melchior FRANZ wrote:
* Takashi Iwai -- Friday 29 April 2011:
[https://bugzilla.kernel.org/show_bug.cgi?id=31522]
Looking at bugzilla, the problem seems like the case lbpc=0.
What about the patch below instead?
- val *= lbpc
At Sat, 30 Apr 2011 10:32:04 +0200,
Melchior FRANZ wrote:
* Takashi Iwai -- Saturday 30 April 2011:
I remember vaguely that the value zero could be interpreted as the max.
Also, with the patch, does the backlight level can be adjusted
correctly to different values? I wonder whether
At Sat, 30 Apr 2011 13:34:51 +0200,
Melchior FRANZ wrote:
Dropping Linus from the CC.
* Takashi Iwai -- Saturday 30 April 2011:
* * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote:
Yes, backlight adjustment generally works on this notebook, but only
with acpi_osi=Linux
At Sat, 7 May 2011 22:22:40 +0200,
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 06 May 2011:
last patch prevents the backlight from being turned off, but it also
breaks the brightness adjustment keys at runtime with acpi_osi=Linux.
It has turned out that acpi key events seem to be
At Mon, 09 May 2011 02:50:50 -0600,
Joey Lee wrote:
Add Cc. Michael Chang for he is our i915 expert.
Hi Melchior,
於 日，2011-05-08 於 16:05 +0200，Melchior FRANZ 提到：
Does it work to you direct control brightness by access
by /sys/class/backlight/acer-wmi/brightness ?
No. A
At Tue, 10 May 2011 13:08:23 +0200,
Melchior FRANZ wrote:
* Michael Chang -- Tuesday 10 May 2011:
Could you please try this patch and get the log ? We wonder why
is_backlight_combination_mode () returns false.
This information was already buried in the bugzilla thread:
At Wed, 29 Jun 2011 14:20:13 +0800,
Wu Fengguang wrote:
This patch is tested OK on G45/HDMI and IbexPeak/HDMI. DisplayPort is
tested on several IbexPeak and Sandybridge boxes, however not working,
possibly due to hardware/monitor problems.
We've got some reports that DP audio doesn't work
.
In this way, the bogus value for disabling backlight can be skipped.
Signed-off-by: Takashi Iwai ti...@suse.de
---
Feel free to add Cc to stable kernel, as this is a regression fix.
I've tested only a few machines here so more tests would be
appreciated, because the backlight issue is SOOO sensitive
At Thu, 13 Oct 2011 09:40:29 -0700,
Keith Packard wrote:
On Thu, 13 Oct 2011 10:57:35 +0200, Takashi Iwai ti...@suse.de wrote:
This patch fixes the bug by recording the backlight level always
when changed but only when dev_priv-backlight_enabled is set.
In this way, the bogus value
At Thu, 13 Oct 2011 12:28:07 -0700,
Keith Packard wrote:
On Thu, 13 Oct 2011 20:05:49 +0200, Takashi Iwai ti...@suse.de wrote:
Yes, this looks more understandable, indeed.
Would you patch it by yourself or should I refresh the patch?
In either way, I'll test tomorrow, as I'm already
At Tue, 8 Nov 2011 12:23:30 -0800,
Linus Torvalds wrote:
Hmm, I don't know what caused this to trigger, but I'm adding both the
i915 people and the HDA people to the cc, and they can fight to the
death about this in the HDMI Thunderdome.
It must be the new addition of ELD-passing code.
At Thu, 10 Nov 2011 16:11:29 +0100,
Daniel Mack wrote:
On 11/08/2011 01:57 AM, Daniel Mack wrote:
Didn't get any response yet, hence copying LKML for a broader audience.
Nobody, really?
This is a rather annoying regression, as touching the brightness keys
appearantly switches off the
[Added Chris to Cc]
At Sun, 13 Nov 2011 17:24:09 +0100,
Daniel Mack wrote:
Hi Takashi,
On 11/10/2011 04:39 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 16:11:29 +0100,
Daniel Mack wrote:
On 11/08/2011 01:57 AM, Daniel Mack wrote:
Didn't get any response yet, hence copying LKML
At Mon, 14 Nov 2011 13:03:46 +0100,
Daniel Mack wrote:
On 11/14/2011 11:39 AM, Takashi Iwai wrote:
[Added Chris to Cc]
At Sun, 13 Nov 2011 17:24:09 +0100,
Daniel Mack wrote:
Hi Takashi,
On 11/10/2011 04:39 PM, Takashi Iwai wrote:
At Thu, 10 Nov 2011 16:11:29 +0100,
Daniel
At Wed, 16 Nov 2011 13:58:57 +0100,
Daniel Mack wrote:
On 11/14/2011 11:39 AM, Takashi Iwai wrote:
OK, then perhaps a better fix is to change the check to be equivalent
with pineview, as you mentioned in the original post. The handling of
bit 0 for old chips was lost during
At Mon, 21 Nov 2011 09:58:09 +0800,
Wu Fengguang wrote:
On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote:
On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com
wrote:
However when in X, -mode_set won't be called at all. Only
-get_modes and -detect
At Wed, 11 Apr 2012 21:59:28 -0300,
Rodrigo Vivi wrote:
There are many bugs open on fd.o regarding missing modes that are supported
on Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor
allows it trough range limited flag...
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
CVT monitors _must_ accept GTF as well, EDID says so. So functionally
there's nothing wrong with the existing code.
Actually the current code just check for gtf flag... so if a monitor
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
I don't think we need to support all wild modes, too. But the _very_
common modes like 1366x768 and 1600x900 should be really supported as
default.
You guys still haven't answered the basic question, what HW is this broken?
The
At Fri, 13 Apr 2012 10:55:16 -0400,
Adam Jackson wrote:
On 4/13/12 10:29 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
Yeah, that's a bug. That's why I said it should be renamed
drm_dmt_modes_for_range and run unconditionally if we find a range
At Fri, 13 Apr 2012 11:30:01 -0400,
Alex Deucher wrote:
On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai ti...@suse.de wrote:
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
I don't think we need to support all wild modes, too. But the _very_
common modes like 1366x768
At Fri, 13 Apr 2012 12:31:25 -0400,
Adam Jackson wrote:
On 4/13/12 11:41 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
One thing to be careful of is that some monitors (especially LCD
panels) don't like modes that are not in their EDIDs. As such when
At Fri, 13 Apr 2012 16:33:37 -0400,
Adam Jackson wrote:
Signed-off-by: Adam Jackson a...@redhat.com
---
include/drm/drm_edid.h | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index
At Tue, 17 Apr 2012 17:33:17 +0200,
Takashi Iwai wrote:
At Fri, 13 Apr 2012 16:33:28 -0400,
Adam Jackson wrote:
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any
Hi,
I noticed that one machine here gives only the blank output with
3.4-rc's. The bisection lead me to affecting commit:
commit e00e8b5e760cbbe9067daeae5454d67c44c8d035
Author: Alex Deucher alexander.deuc...@amd.com
Date: Fri Mar 16 12:22:09 2012 -0400
drm/radeon/kms: fix
At Wed, 18 Apr 2012 14:39:54 +0200,
Takashi Iwai wrote:
Hi,
I noticed that one machine here gives only the blank output with
3.4-rc's. The bisection lead me to affecting commit:
commit e00e8b5e760cbbe9067daeae5454d67c44c8d035
Author: Alex Deucher alexander.deuc...@amd.com
...@vger.kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/radeon/radeon_connectors.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index bd05156..aa8268d 100644
--- a/drivers
At Tue, 17 Apr 2012 17:26:26 +0200,
Takashi Iwai wrote:
At Fri, 13 Apr 2012 16:56:26 -0400,
Adam Jackson wrote:
On 4/13/12 4:33 PM, Adam Jackson wrote:
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced
At Thu, 19 Apr 2012 14:03:58 +0200,
Takashi Iwai wrote:
At Tue, 17 Apr 2012 17:26:26 +0200,
Takashi Iwai wrote:
At Fri, 13 Apr 2012 16:56:26 -0400,
Adam Jackson wrote:
On 4/13/12 4:33 PM, Adam Jackson wrote:
Incorporates some feedback from Rodrigo and Takashi. Major themes
At Fri, 20 Apr 2012 13:04:42 +0100,
Dave Airlie wrote:
On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai ti...@suse.de wrote:
At Tue, 17 Apr 2012 17:26:26 +0200,
Takashi Iwai wrote:
At Fri, 13 Apr 2012 16:56:26 -0400,
Adam Jackson wrote:
On 4/13/12 4:33 PM, Adam Jackson wrote
At Fri, 20 Apr 2012 13:05:48 +0100,
Dave Airlie wrote:
On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai ti...@suse.de wrote:
At Thu, 19 Apr 2012 14:03:58 +0200,
Takashi Iwai wrote:
At Tue, 17 Apr 2012 17:26:26 +0200,
Takashi Iwai wrote:
At Fri, 13 Apr 2012 16:56:26 -0400,
Adam
Hi Dave,
in kernel bug 43155, we found out that the HDMI audio controller on
AMD graphics is also disabled when the graphics chip is disabled via
vga-switcher:
https://bugzilla.kernel.org/show_bug.cgi?id=43155
This screws up the sound driver, takes too long time for boot.
Since the audio
Dave,
this is a small patch series to add the support for audio clients
to VGA switcheroo. The background problem is that the HD-audio HDMI
controller of the discrete GPU is also disabled when the graphics core
is disabled by vga-switcheroo. This leads to a long stall of the
audio driver, or at
Refactor the code base a bit for the further work to adapt more clients.
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/vga/vga_switcheroo.c | 209 --
1 file changed, 110 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c
-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/vga/vga_switcheroo.c | 84 ++
include/linux/vga_switcheroo.h | 10 +
2 files changed, 78 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
At Thu, 10 May 2012 09:08:38 +0200,
Takashi Iwai wrote:
Dave,
this is a small patch series to add the support for audio clients
to VGA switcheroo. The background problem is that the HD-audio HDMI
controller of the discrete GPU is also disabled when the graphics core
is disabled by vga
At Thu, 10 May 2012 11:40:50 +0100,
Dave Airlie wrote:
On Thu, May 10, 2012 at 8:10 AM, Takashi Iwai ti...@suse.de wrote:
Add the support for audio clients to VGA-switcheroo for handling the
HDMI audio controller together with VGA switching. The id of the
audio controller should be given
At Thu, 10 May 2012 13:42:09 +0200,
Takashi Iwai wrote:
At Thu, 10 May 2012 12:20:05 +0100,
Alan Cox wrote:
On Thu, 10 May 2012 09:10:16 +0200
Takashi Iwai ti...@suse.de wrote:
Add the support for audio clients to VGA-switcheroo for handling the
HDMI audio controller together
At Thu, 10 May 2012 20:05:25 +0100,
Dave Airlie wrote:
On Thu, May 10, 2012 at 7:42 PM, Takashi Iwai ti...@suse.de wrote:
At Thu, 10 May 2012 13:42:09 +0200,
Takashi Iwai wrote:
At Thu, 10 May 2012 12:20:05 +0100,
Alan Cox wrote:
On Thu, 10 May 2012 09:10:16 +0200
Takashi
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to
This changes the API as a clean-up. Instead of passing multiple
function pointers at each time, introduce a new struct holding the
whole callback functions and pass it to the registration.
The same struct will be used for the upcoming audio client
registration, too.
Signed-off-by: Takashi Iwai
-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/vga/vga_switcheroo.c | 74 ++
include/linux/vga_switcheroo.h |6
2 files changed, 66 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
Refactor the code base a bit for the further work to adapt more clients.
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/vga/vga_switcheroo.c | 209 --
1 file changed, 110 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c
-specific problem, but it's
anyway safer to avoid such almost unrealistic setups.
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/drm_edid.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index eb92fe2..61e4cf1 100644
Hi,
this is a series of patches to fix the regressions of HD-audio HDMI
on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.
The first patch adds a new helper function to vga-switcheroo and the
second just uses that instead of an open code.
Dave, if the first patch is OK,
Add vga_switcheroo_get_client_state() to get the current state of the
client. This is necessary to determine the proper initial state of
audio clients in HD-audio driver.
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/vga/vga_switcheroo.c | 13 +
include/linux
audio
client state more correctly.
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/hda_intel.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 2b6392b..5f0375f 100644
--- a/sound/pci/hda/hda_intel.c
At Fri, 8 Jun 2012 09:42:58 +0100,
Dave Airlie wrote:
On Thu, Jun 7, 2012 at 11:15 AM, Takashi Iwai ti...@suse.de wrote:
Add vga_switcheroo_get_client_state() to get the current state of the
client. This is necessary to determine the proper initial state of
audio clients in HD-audio
At Fri, 08 Jun 2012 13:26:57 +0200,
Jörg-Volker Peetz wrote:
Takashi Iwai wrote, on 06/07/12 12:15:
Hi,
this is a series of patches to fix the regressions of HD-audio HDMI
on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.
The first patch adds a new helper
At Fri, 08 Jun 2012 17:45:17 +0200,
Jörg-Volker Peetz wrote:
Hello Takashi,
Takashi Iwai wrote, on 06/08/12 15:03:
At Fri, 08 Jun 2012 13:26:57 +0200,
Jörg-Volker Peetz wrote:
Takashi Iwai wrote, on 06/07/12 12:15:
Hi,
this is a series of patches to fix the regressions of HD
At Sat, 9 Jun 2012 08:57:20 +0100,
Dave Airlie wrote:
Good to hear.
Dave, is it OK to apply the patch below through sound tree?
ack below,
thanks,
Takashi
---
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right
on the DMT list without regard to a specific timing
formula.
Signed-off-by: Adam Jackson a...@redhat.com
Tested-by: Takashi Iwai ti...@suse.de
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Dave Airlie airl...@redhat.com
diff --git a/drivers/gpu/drm
At Mon, 25 Jun 2012 17:53:12 +0200,
Takashi Iwai wrote:
And, does the patch below help?
BTW, the patch below contains the possible generic fix.
It seems that EDID_QUIRK_FIRST_DETAILED_PREFERRED handling is missing
from the beginning. So I wrote it just from what I can imagine from
the comment
At Mon, 25 Jun 2012 19:40:48 +0200,
Sven Joachim wrote:
Am 25.06.2012 um 17:53 schrieb Takashi Iwai:
Looking at the EDID data, the problem is likely that your monitor
doesn't give the proper preferred mode.
What does xrandr output show?
,
| Screen 0: minimum 320 x 200, current
At Mon, 25 Jun 2012 21:38:56 +0200,
Sven Joachim wrote:
Am 25.06.2012 um 21:24 schrieb Takashi Iwai:
And, does the patch below help?
Somewhat: at least I get 1280x1024 again, but at 60 rather than 75 Hz.
I guess it worked casually because 1280x1024@75 was the highest
resolution
At Sat, 30 Jun 2012 13:46:54 -0500,
Calvin Owens wrote:
On 06/26/2012 02:21 AM, Takashi Iwai wrote:
At Mon, 25 Jun 2012 21:38:56 +0200,
Sven Joachim wrote:
Am 25.06.2012 um 21:24 schrieb Takashi Iwai:
And, does the patch below help?
Somewhat: at least I get 1280x1024 again
At Mon, 02 Jul 2012 15:46:29 -0400,
Adam Jackson wrote:
On 6/26/12 3:21 AM, Takashi Iwai wrote:
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] drm: edid: Don't add inferred modes with higher resolution
When a monitor EDID doesn't give the preferred bit, driver assumes
a...@redhat.com
Signed-off-by: Takashi Iwai ti...@suse.de
---
Dave, could you apply this as a regression fix for 3.5 kernel?
drivers/gpu/drm/drm_edid.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
On 08/21/2012 07:39 AM, Clark, Rob wrote:
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
Hello!
I have been working on prototypes for the
At Thu, 23 Aug 2012 20:44:32 -0500,
Ricardo Neri wrote:
Hi Takashi,
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
On 08/21/2012 07:39 AM, Clark, Rob wrote:
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei
At Mon, 10 Sep 2012 15:04:02 +1000,
Dave Airlie wrote:
On Mon, Sep 10, 2012 at 2:31 PM, Dave Airlie airl...@gmail.com wrote:
For optimus and powerxpress setups where we can explicitly power off
the GPU I'd like to do this under control of the driver. Now that I've
added X server support
At Mon, 10 Sep 2012 18:50:04 +1000,
Dave Airlie wrote:
On Mon, Sep 10, 2012 at 6:47 PM, Takashi Iwai ti...@suse.de wrote:
At Mon, 10 Sep 2012 15:04:02 +1000,
Dave Airlie wrote:
On Mon, Sep 10, 2012 at 2:31 PM, Dave Airlie airl...@gmail.com wrote:
For optimus and powerxpress setups
At Mon, 19 Nov 2012 15:23:06 -0500,
Egbert Eich e...@novell.com wrote:
EEDID v1.3 mandates map blocks if more than one EDID extension block
is used while in v1.4 they are optional.
If the extension count has been changed (because some extension
blocks were not readable) those map blocks
At Mon, 19 Nov 2012 15:23:09 -0500,
Egbert Eich e...@novell.com wrote:
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/drm_edid.c | 77
---
drivers/gpu/drm/drm_edid_load.c | 54 ++-
include/drm/drm_edid.h
At Mon, 19 Nov 2012 15:23:08 -0500,
Egbert Eich e...@novell.com wrote:
EDIDs are an integral concept of connectors, connectors are a concept
of drm core also drm_edid.o is already part of this drm core.
Overridden, 'firmware-supplied' EDIDs should be treated exactly the
same as device
At Mon, 19 Nov 2012 15:23:11 -0500,
Egbert Eich e...@novell.com wrote:
According the the VESA specs there can be up to 254 EEDID extension blocks.
Since we may read the EDID (including extensions) in 10 second intervals to
probe for display hotplugging (at least in cases where no hardware
At Mon, 19 Nov 2012 15:23:14 -0500,
Egbert Eich e...@novell.com wrote:
So far it was only possible to load an EDID for a single connector (unless
no connector was specified at all in which case the same EDID file was used
for all).
This patch extends the EDID loader so that EDID files can
At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
From: Alan Cox a...@lxorguk.ukuu.org.uk
Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.
This s partly a band aid, the fb layer is terminally confused
When the mode is set with 16bpp on QEMU, the output gets totally
broken. The culprit is the bogus register values set for 16bpp,
which was likely copied from from a wrong place.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=799216
Cc: sta...@vger.kernel.org
Signed-off-by: Takashi Iwai
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_mode.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 6c6b4c8
Hi Dave,
any chance to take a look at this problem?
thanks,
Takashi
At Fri, 25 Jan 2013 17:21:54 +0100,
Takashi Iwai wrote:
When the mode is set with 16bpp on QEMU, the output gets totally
broken. The culprit is the bogus register values set for 16bpp,
which was likely copied from from
Add a new option, bpp, to specify the default bpp value.
Signed-off-by: Takashi Iwai ti...@suse.de
---
This patch is applied on the top of previous two patches.
I couldn't find an easy way to specify the default bpp, so I cooked
the driver quickly. If there is any other convenient way
At Tue, 29 Jan 2013 10:53:50 +0100,
Daniel Vetter wrote:
On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
Add a new option, bpp, to specify the default bpp value.
Signed-off-by: Takashi Iwai ti...@suse.de
---
This patch is applied on the top of previous two patches
At Tue, 12 Mar 2013 16:05:26 +1000,
Dave Airlie wrote:
Hey guys,
I've been writing dynamic power management code for the secondary
GPUs, however a lot of these GPUs have audio codecs as a subfunction
PCI device.
So we get 01:00.0 as the GPU and 01:00.1 as the HDMI audio device.
Now
At Mon, 29 Jul 2013 16:06:59 +1000,
Dave Airlie wrote:
Add support for HDMI audio device on VGA cards that powerdown
to D3cold using non-standard ACPI/PCI infrastructure (optimus).
This does a couple of things to make it work:
a) add a set of power ops for the hdmi domain, and enables
At Mon, 5 Aug 2013 12:56:04 +1000,
Dave Airlie wrote:
Add support for HDMI audio device on VGA cards that powerdown
to D3cold using non-standard ACPI/PCI infrastructure (optimus).
This does a couple of things to make it work:
a) add a set of power ops for the hdmi domain, and enables
Hi Dave,
At Wed, 28 Aug 2013 16:51:55 +1000,
Dave Airlie wrote:
Hi Takashi,
I've put two branches in my repo,
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down-snd-merge
At Wed, 28 Aug 2013 18:25:47 +0200,
Takashi Iwai wrote:
Hi Dave,
At Wed, 28 Aug 2013 16:51:55 +1000,
Dave Airlie wrote:
Hi Takashi,
I've put two branches in my repo,
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down
http://cgit.freedesktop.org
Acked-by: Takashi Iwai ti...@suse.de
thanks,
Takashi
---
sound/ppc/keywest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
index 01aecc2..0d1c27e 100644
--- a/sound/ppc/keywest.c
+++ b/sound/ppc/keywest.c
@@ -65,7
This is just a cleanup, no functional change.
The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is
basically a copy of the existing code in drm_edid.c. Make the latter
code public so that it can be called from the former function.
Signed-off-by: Takashi Iwai <ti...@suse
On Fri, 21 Oct 2016 14:52:07 +0200,
Ville Syrjälä wrote:
>
> On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wrote:
> > Since 4.7 kernel, we've seen the error messages like
> >
> > kernel: [TTM] Buffer eviction failed
> > kernel: qxl :00:02.0: obje
On Tue, 25 Oct 2016 10:09:30 +0200,
Daniel Vetter wrote:
>
> On Tue, Oct 25, 2016 at 08:46:28AM +0200, Takashi Iwai wrote:
> > On Fri, 21 Oct 2016 14:52:07 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wr
On Thu, 27 Oct 2016 11:02:30 +0200,
Michel D4nzer wrote:
>
> On 26/09/16 09:09 PM, Takashi Iwai wrote:
> > On Mon, 26 Sep 2016 11:42:16 +0200, Takashi Iwai wrote:
> >> On Mon, 26 Sep 2016 10:57:50 +0200, Michel D4nzer wrote:
> >>> On 23/0
1 - 100 of 612 matches
Mail list logo
