On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-03-12 15:37, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thanks for the patch.
> >
> > On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
> >> Structs videomode and display_timing have rather long field names
On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
> Property blob objects need to be destroyed when cleaning up to avoid
> memory leaks. Go through the list of all blobs in the
> drm_mode_config_cleanup() function and destroy them.
>
> The drm_mode_config_cleanup() function needs t
From: Dave Airlie
This aligns this code more carefully with what is in the upstream X.org MGA
driver.
The freq is a typo, and other changes ports from the same function in the
X.org driver.
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 ++
On Fri, Mar 15, 2013 at 08:47:39AM -0700, Greg KH wrote:
> On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Greg KH wrote:
> >
> > > > > I have the same problem on my Lenovo T500. I think the graphics card
> > > > > is
> > > > > involved.
> > > > >
> > > > >
On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote:
>
> Moin,
>
> [1.] One line summary of the problem:
>
>Both screens stay blank during boot with 3.8.3.
>
> [2.] Full description of the problem/report:
>
>When booting the screens go blank soon after showing the grub me
On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
>
> I have an Acer Aspire One netbook, and on it I get the following
> warning when closing and opening the lid. I think this warning first
> appeared in 3.7.
>
> Does this need fixing? If so, who can do it?
Another pesky BIOS whic
On Fri, 15 Mar 2013, Yinghai Lu wrote:
> > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > reveals that "nobody cared" for irq 16 happens long after last
> >
> > I915_WRITE(GMBUS4 + reg_offset, 0);
> >
> > has been performed in gmbus_wait_hw_status(). On the o
Hi Daniel,
On Monday 18 March 2013 09:06:21 Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
> > Property blob objects need to be destroyed when cleaning up to avoid
> > memory leaks. Go through the list of all blobs in the
> > drm_mode_config_cleanup() func
Hi Greg&all,
So a recent stable backport to fix rc6 on ilk (which is disabled by
default and with dubious power savings at best, unlike rc6 on snb and
later) totally blew up all over the place:
https://bugzilla.kernel.org/show_bug.cgi?id=55291
https://lkml.org/lkml/2013/3/14/540
There might be mo
https://bugs.freedesktop.org/show_bug.cgi?id=62466
Priority: medium
Bug ID: 62466
Assignee: dri-devel@lists.freedesktop.org
Summary: KSP 0.19 causes GPU lockups on r600g
Severity: normal
Classification: Unclassified
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #8 from Michel Dänzer ---
(In reply to comment #5)
> Possible patch
This seems less than ideal, as it makes libllvmradeon duplicate lots of stuff
from the driver *.so, and it grows from ~500K to ~10M for me.
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #9 from LoneVVolf ---
That appears to be correct,
in a git version build on march 11
libllvmradeon9.2.0.so is just 39 Kib .
Build with the patch it's size increases to 1.8 Mib !
--
You are receiving this mail because:
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=62466
--- Comment #1 from Alex Deucher ---
Does disabling hyperz help? Set env var:
R600_DEBUG=nohyperz
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #10 from Andreas Boll ---
(In reply to comment #8)
> (In reply to comment #5)
> > Possible patch
>
> This seems less than ideal, as it makes libllvmradeon duplicate lots of
> stuff from the driver *.so, and it grows from ~500K to ~10
https://bugs.freedesktop.org/show_bug.cgi?id=62466
--- Comment #2 from Knut Andre Tidemann ---
Disabling hyperz does indeed fix the issue. Tried a quick spin for ~15-20 mins
wit no issues now.
With hyperz enabled, I get lockups after a few minutes.
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=62466
Alex Deucher changed:
What|Removed |Added
Summary|KSP 0.19 causes GPU lockups |r600g hyperz lockups with
Just a bit of cleanup from me (resubmitted). The important patch comes
from Julia. Julia's patch conflicts with the following:
1363594270-22137-1-git-send-email-airl...@gmail.com
it fixes
https://bugzilla.kernel.org/show_bug.cgi?id=46591
Christopher Harvey (3):
drm/mgag200: Remove pointless cal
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index a274b99..6b5db83 100644
--- a/drivers/gpu/drm/mgag200/mgag
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 64297c7
While testing the mgag200 kms driver on the HP ProLiant Gen8, a
bug was seen. Once the bootloader would load the selected kernel,
the screen would go black. At first it was assumed that the
mgag200 kms driver was hanging. But after setting up the grub
serial output, it was seen that the driver w
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #11 from Maarten Lankhorst ---
The fix is correct, despite the size increase.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel
vesa is presumed to be the generic hardware agnostic fallback framebuffer
driver for standard VGA that conflicts with the real drivers. Those
drivers already check and remove vesafb if it is previously loaded, but
in the reverse case where vesafb is loaded afterwards, the VESA driver
will proceed t
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #12 from Maarten Lankhorst ---
Reverting the gallium fix would reopen bug #59238
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-de
On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/show_bug.
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits"
https://bugs.freedesktop.org/show_bug.cgi?id=60407
Benjamin Gaignard changed:
What|Removed |Added
Version|unspecified |XOrg CVS
--
You are receiving this
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually
> hardware root cause / workaround is found for GM45, we can have it merged
> later.
>
>
>
> From: Jiri Kosina
> Subject: [PATCH] drm/i915: stop using GMBUS
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #13 from Fabio Pedretti ---
Ubuntu is providing a shared libgallium, the patches are here:
http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=tree;f=debian/patches;hb=refs/heads/ubuntu%2B1
--
You are receiving this mail bec
Btw, what is the hw response to invalid input (ie. bottom>top, invalid
size, etc)?
Ie. if it will just ignore the blit or raise an error irq which can be
handled sanely, it could be ok to avoid the overhead of the cmdstream
checking in the kernel. The kernel part really just needs to ensure
that
On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>> > I915_WRITE(GMBUS4 + reg_offset, 0);
>>
My laptop is an Acer 1810T. I see this error message each boot.
Kind regards
Thomas
Jiri Kosina schrieb:
>On Fri, 15 Mar 2013, Jiri Kosina wrote:
>
>> > I have the same problem on my Lenovo T500. I think the graphics card is
>> > involved.
>> >
>> > This laptop has "hybrid graphics" - one Inte
On 2013-03-18 10:00, Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 2013-03-12 15:37, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> Thanks for the patch.
>>>
>>> On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
Structs videomode and
Sergio Callegari writes:
> This is just a short note to let you know that after installing 3.8.3,
> display port stopped working on my laptop. Going back to 3.8.2 brought
> it back to life.
> This has been tested with the ubuntu mainline kernels that should be
> vanilla stable kernels. Hope this
On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
> > > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > > reveals that "nobody cared" for irq 16 happens long after last
> > >
> > > I915_WRITE(GMBUS4 + reg_o
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually
> hardware root cause / workaround is found for GM45, we can have it merged
> later.
I'd prefer if we dig into this for a bit more. I've been traveling last
wee
On Mon, Mar 18, 2013 at 04:59:35PM +0100, Bjørn Mork wrote:
> Sergio Callegari writes:
>
> > This is just a short note to let you know that after installing 3.8.3,
> > display port stopped working on my laptop. Going back to 3.8.2 brought
> > it back to life.
> > This has been tested with the ubu
-lkml
On Sun, Mar 17, 2013 at 12:46 PM, Daniel Vetter wrote:
> On Fri, Mar 15, 2013 at 3:11 AM, Stéphane Marchesin
> wrote:
>>> drm/i915: read out the modeset hw state at load and resume time
>> This commit regresses modeset on the samsung series 5 chromebook (it
>> is basically a pineview
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #14 from LoneVVolf ---
Trying to summarize
I've looked a bit more at bug #59238, and if i understand correctly the problem
with building xa tracker was that symbols were exported that are not supposed
to be visible outside of the lib
On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Yinghai Lu wrote:
> >
> > > > Just a datapoint -- I have put a trivial debugging patch in place, and
> > > > it
> > > > reveals that "nobody cared
On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen wrote:
> Hi Dave,
>
> I'm writing this mail to get some ideas how we should manage OMAP's
> display drivers in the future.
>
> As a short intro, we have the following players around:
>
> omapdss - omapdss handles the DSS (display subsystem) hardware.
On Mon, Mar 18, 2013 at 11:05:26AM +0100, Daniel Vetter wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/s
On Mon, Mar 18, 2013 at 8:35 PM, Stéphane Marchesin
wrote:
>
>> For starters I guess we need:
>> - drm.debug=0xe dmesg from just before that commit
>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>
>> Latest upstream has a minor chance to work better I think since we've
>> im
On Mon, Mar 18, 2013 at 9:59 PM, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 8:35 PM, Stéphane Marchesin
> wrote:
>>
>>> For starters I guess we need:
>>> - drm.debug=0xe dmesg from just before that commit
>>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>>
>>> Latest ups
On Mon, 18 Mar 2013, Daniel Vetter wrote:
> Yep, there's a big comment in the irq handler for that chipset that we
> have a gaping race with when using MSI interrupts. Although the comment
> bodly claims that the race is small enough to avoid the dreaded "nobody
> cared" message. Looks like gmbus
On Mon, 18 Mar 2013, Yinghai Lu wrote:
> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
> > interrupts go away.
> >
> > My understanding from the other mail is that DAniel Vetter already has an
> > idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Yinghai Lu wrote:
>
>> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
>> > interrupts go away.
>> >
>> > My understanding from the other mail is that DAniel Vetter already has an
>> > idea what mig
On Mar 19, 2013 3:01 AM, "Rob Clark" wrote:
>
> Btw, what is the hw response to invalid input (ie. bottom>top, invalid
> size, etc)?
>
Unfortunately the IOMMU page fault is happened. So we need some codes for
protecting kernel.
Thank you~
Best regards YJ
> Ie. if it will just ignore the blit or
On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho wrote:
>
> On Mar 19, 2013 3:01 AM, "Rob Clark" wrote:
>>
>> Btw, what is the hw response to invalid input (ie. bottom>top, invalid
>> size, etc)?
>>
>
> Unfortunately the IOMMU page fault is happened. So we need some codes for
> protecting kernel.
h
On Mar 19, 2013 9:55 AM, "Rob Clark" wrote:
>
> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho
wrote:
> >
> > On Mar 19, 2013 3:01 AM, "Rob Clark" wrote:
> >>
> >> Btw, what is the hw response to invalid input (ie. bottom>top, invalid
> >> size, etc)?
> >>
> >
> > Unfortunately the IOMMU page fau
On Mon, Mar 18, 2013 at 9:32 PM, YoungJun Cho wrote:
>
> On Mar 19, 2013 9:55 AM, "Rob Clark" wrote:
>>
>> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho
>> wrote:
>> >
>> > On Mar 19, 2013 3:01 AM, "Rob Clark" wrote:
>> >>
>> >> Btw, what is the hw response to invalid input (ie. bottom>top, inv
> Just a bit of cleanup from me (resubmitted). The important patch comes
> from Julia. Julia's patch conflicts with the following:
> 1363594270-22137-1-git-send-email-airl...@gmail.com
>
Yeah I was going to leave the cleanups until -next opens, I'll push
the fix though and get it to stable.
Dave.
Hi Rob,
2013/3/19 Rob Clark :
> On Mon, Mar 18, 2013 at 9:32 PM, YoungJun Cho wrote:
>>
>> On Mar 19, 2013 9:55 AM, "Rob Clark" wrote:
>>>
>>> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho
>>> wrote:
>>> >
>>> > On Mar 19, 2013 3:01 AM, "Rob Clark" wrote:
>>> >>
>>> >> Btw, what is the hw res
On Tuesday 12 March 2013 08:23 PM, Tomi Valkeinen wrote:
On 2013-03-12 16:38, Archit Taneja wrote:
memcmp on two structs is often not a good idea. There could be padding
bytes there, with uninitialized data. I'm not sure if that's the case
here, though, but it could well change any time (perhap
On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson
wrote:
> On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
>> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson
>> wrote:
>> > If *userspace* doesn't request either IOC_IN | IOC_OUT in their ioctl
>> > command (which are seperate from the
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/20130318/85dbd506/attachment.html>
On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-03-12 15:37, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thanks for the patch.
> >
> > On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
> >> Structs videomode and display_timing have rather long field names
On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
> Property blob objects need to be destroyed when cleaning up to avoid
> memory leaks. Go through the list of all blobs in the
> drm_mode_config_cleanup() function and destroy them.
>
> The drm_mode_config_cleanup() function needs t
From: Dave Airlie
This aligns this code more carefully with what is in the upstream X.org MGA
driver.
The freq is a typo, and other changes ports from the same function in the
X.org driver.
Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6
On Fri, Mar 15, 2013 at 08:47:39AM -0700, Greg KH wrote:
> On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Greg KH wrote:
> >
> > > > > I have the same problem on my Lenovo T500. I think the graphics card
> > > > > is
> > > > > involved.
> > > > >
> > > > >
On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote:
>
> Moin,
>
> [1.] One line summary of the problem:
>
>Both screens stay blank during boot with 3.8.3.
>
> [2.] Full description of the problem/report:
>
>When booting the screens go blank soon after showing the grub me
On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
>
> I have an Acer Aspire One netbook, and on it I get the following
> warning when closing and opening the lid. I think this warning first
> appeared in 3.7.
>
> Does this need fixing? If so, who can do it?
Another pesky BIOS whic
On Fri, 15 Mar 2013, Yinghai Lu wrote:
> > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > reveals that "nobody cared" for irq 16 happens long after last
> >
> > I915_WRITE(GMBUS4 + reg_offset, 0);
> >
> > has been performed in gmbus_wait_hw_status(). On the o
Hi Daniel,
On Monday 18 March 2013 09:06:21 Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 03:31:11PM +0100, Laurent Pinchart wrote:
> > Property blob objects need to be destroyed when cleaning up to avoid
> > memory leaks. Go through the list of all blobs in the
> > drm_mode_config_cleanup() func
Hi Greg&all,
So a recent stable backport to fix rc6 on ilk (which is disabled by
default and with dubious power savings at best, unlike rc6 on snb and
later) totally blew up all over the place:
https://bugzilla.kernel.org/show_bug.cgi?id=55291
https://lkml.org/lkml/2013/3/14/540
There might be mo
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/061c4a44/attachment-0001.html>
ing 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/20130318/17ea303c/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/5cc44395/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/3923500c/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/41ae6b54/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/251ddbba/attachment.html>
|on r600g|KSP 0.19
--
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/20130318/6490febd/attachment.html>
Just a bit of cleanup from me (resubmitted). The important patch comes
from Julia. Julia's patch conflicts with the following:
1363594270-22137-1-git-send-email-airlied at gmail.com
it fixes
https://bugzilla.kernel.org/show_bug.cgi?id=46591
Christopher Harvey (3):
drm/mgag200: Remove pointless
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index a274b99..6b5db83 100644
--- a/drivers/gpu/drm/mgag200/mgag
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 64297c7
While testing the mgag200 kms driver on the HP ProLiant Gen8, a
bug was seen. Once the bootloader would load the selected kernel,
the screen would go black. At first it was assumed that the
mgag200 kms driver was hanging. But after setting up the grub
serial output, it was seen that the driver w
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/fb35ae05/attachment.html>
vesa is presumed to be the generic hardware agnostic fallback framebuffer
driver for standard VGA that conflicts with the real drivers. Those
drivers already check and remove vesafb if it is previously loaded, but
in the reverse case where vesafb is loaded afterwards, the VESA driver
will proceed t
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/409b7b61/attachment.html>
On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter
wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/show_bug
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits"
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/20130318/9d252e5d/attachment.html>
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually
> hardware root cause / workaround is found for GM45, we can have it merged
> later.
>
>
>
> From: Jiri Kosina
> Subject: [PATCH] drm/i915: stop using GMBUS
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/1b54a4a9/attachment.html>
Btw, what is the hw response to invalid input (ie. bottom>top, invalid
size, etc)?
Ie. if it will just ignore the blit or raise an error irq which can be
handled sanely, it could be ok to avoid the overhead of the cmdstream
checking in the kernel. The kernel part really just needs to ensure
that
On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>> > I915_WRITE(GMBUS4 + reg_offset, 0);
>>
On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
> > > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > > reveals that "nobody cared" for irq 16 happens long after last
> > >
> > > I915_WRITE(GMBUS4 + reg_o
My laptop is an Acer 1810T. I see this error message each boot.
Kind regards
Thomas
Jiri Kosina schrieb:
>On Fri, 15 Mar 2013, Jiri Kosina wrote:
>
>> > I have the same problem on my Lenovo T500. I think the graphics card is
>> > involved.
>> >
>> > This laptop has "hybrid graphics" - one Inte
s, and no positive comments, so I'm dropping the
last patch. The first four should be fine, though.
And yes, we should definitely try to use only this new videomode struct
in the future everywhere in the kernel. It sure would make me remember
the names better =).
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/b7c1a942/attachment.pgp>
Sergio Callegari writes:
> This is just a short note to let you know that after installing 3.8.3,
> display port stopped working on my laptop. Going back to 3.8.2 brought
> it back to life.
> This has been tested with the ubuntu mainline kernels that should be
> vanilla stable kernels. Hope this
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually
> hardware root cause / workaround is found for GM45, we can have it merged
> later.
I'd prefer if we dig into this for a bit more. I've been traveling last
wee
On Mon, Mar 18, 2013 at 04:59:35PM +0100, Bj?rn Mork wrote:
> Sergio Callegari writes:
>
> > This is just a short note to let you know that after installing 3.8.3,
> > display port stopped working on my laptop. Going back to 3.8.2 brought
> > it back to life.
> > This has been tested with the ubu
-lkml
On Sun, Mar 17, 2013 at 12:46 PM, Daniel Vetter wrote:
> On Fri, Mar 15, 2013 at 3:11 AM, St?phane Marchesin
> wrote:
>>> drm/i915: read out the modeset hw state at load and resume time
>> This commit regresses modeset on the samsung series 5 chromebook (it
>> is basically a pineview
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130318/64665c95/attachment.html>
On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Yinghai Lu wrote:
> >
> > > > Just a datapoint -- I have put a trivial debugging patch in place, and
> > > > it
> > > > reveals that "nobody cared
On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen wrote:
> Hi Dave,
>
> I'm writing this mail to get some ideas how we should manage OMAP's
> display drivers in the future.
>
> As a short intro, we have the following players around:
>
> omapdss - omapdss handles the DSS (display subsystem) hardware.
On Mon, Mar 18, 2013 at 11:05:26AM +0100, Daniel Vetter wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/s
On Mon, Mar 18, 2013 at 8:35 PM, St?phane Marchesin
wrote:
>
>> For starters I guess we need:
>> - drm.debug=0xe dmesg from just before that commit
>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>
>> Latest upstream has a minor chance to work better I think since we've
>> im
On Mon, Mar 18, 2013 at 9:59 PM, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 8:35 PM, St?phane Marchesin
> wrote:
>>
>>> For starters I guess we need:
>>> - drm.debug=0xe dmesg from just before that commit
>>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>>
>>> Latest ups
1 - 100 of 105 matches
Mail list logo
