> > In 3.4, radeon worked with a glitch - window titles were see-throug (not
> > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> > acceleration on this system at all. Full dmesg below.
>
> Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?
That was a
s every time, and bisecting leads to 03bd6efa
> ("drm/nv50/fifo: use hardware channel kickoff functionality").
Hi Ben,
I'm still seeing this bug with the latest from Linus
(v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
lspci output:
01:00.0 VGA compatible controller: nVidia Corporat
On Thu, Jul 05, 2012 at 09:51:39AM -0500, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
> > +
> > +There are different ways of describing a display mode. The devicetree
> > representation
> > +corresponds to the one used by the Linux Framebuffer framework described
> > here in
On Thu, Jul 05, 2012 at 04:08:07PM +0200, Laurent Pinchart wrote:
> Hi Sascha,
>
> Thanks for the patch.
>
> > +++ b/Documentation/devicetree/bindings/video/displaymode
> > @@ -0,0 +1,40 @@
> > +videomode bindings
> > +==
> > +
> > +Required properties:
> > + - xres, yres:
On Thu, Jul 05, 2012 at 08:31:13AM +0200, Henrik Rydberg wrote:
> Hi Ben, Dave,
Hey Henrik,
>
> Since 3.5-rc0, I have been experiencing occasional screen corruption
> on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver
> version is xf86-video-nouvea-1.0.1-1 (arch).
>
> I do not
https://bugzilla.kernel.org/show_bug.cgi?id=15486
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment
Hi Sascha,
Thanks for the patch.
On Wednesday 04 July 2012 09:56:35 Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the
> devicetree. The videomode can be either converted to a struct
> drm_display_mode or a struct fb_videomode.
>
> Signed-off-by: Sascha
https://bugzilla.kernel.org/show_bug.cgi?id=15486
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
> > On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote:
> > > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > > > On Thu, 24 May 2012
On Thu, Jul 05, 2012 at 01:27:47PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > Make sure the the framebuffer stride is smaller than the maximum
> > accepted by any plane.
> >
> > Also when
Here's a new proposal that should address all issues collected during
the discussion of the previous one:
On Thu, May 24, 2012 at 09:08:59PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> MI display flips can't handle some changes in the framebuffer
> format or layout. Return an error in such cases.
>
> Signed-off-by: Ville Syrj?l?
Queued for -next, thanks for the patch.
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote:
> > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > > On Thu, 24 May 2012 21:08:58 +0300
> > > ville.syrjala at linux.intel.com wrote:
> > >
> > > >
On Thu, May 24, 2012 at 09:08:56PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Zero initialize the mode_cmd structure when creating the kernel
> framebuffer. Avoids having uninitialized data in offsets[0] for
> instance.
>
> Signed-off-by: Ville Syrj?l?
Queued for
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Make sure the the framebuffer stride is smaller than the maximum
> accepted by any plane.
>
> Also when using a tiled memory make sure the object stride matches
> the framebuffer stride.
On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote:
> > Thanks for tracking down the source of this corruption. I don't have
> > any such hardware, so until someone can figure it out, I think we
> > should apply this patch.
>
> In that case, I would have to massage the patch a bit
In 2.6.32, radeon worked fine.
In 3.4, radeon worked with a glitch - window titles were see-throug (not
drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
acceleration on this system at all. Full dmesg below.
Fujitsu Lifebook P series, 256M RAM, 239 usable.
[0.00]
On 07/04/2012 02:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
>
> Signed-off-by: Sascha Hauer
> ---
>
> changes since v1:
> - use
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel
wrote:
> Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher:
>> On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel wrote:
>> > Am Samstag, den 30.06.2012, 21:00 +0200 schrieb Paul Menzel:
>> >> Am Dienstag, den 26.06.2012, 07:42 +0200 schrieb
> Thanks for tracking down the source of this corruption. I don't have
> any such hardware, so until someone can figure it out, I think we
> should apply this patch.
In that case, I would have to massage the patch a bit first; it
creates a problem with suspend/resume. Might be something with
Hi Ben, Dave,
Since 3.5-rc0, I have been experiencing occasional screen corruption
on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver
version is xf86-video-nouvea-1.0.1-1 (arch).
I do not know what the root problem is, but I have been able to
isolate the symptoms to the usage
On Thu, Jul 5, 2012 at 8:00 AM, Meelis Roos wrote:
> In 2.6.32, radeon worked fine.
>
> In 3.4, radeon worked with a glitch - window titles were see-throug (not
> drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> acceleration on this system at all. Full dmesg below.
Does
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #13 from Jean Delvare 2012-07-05 07:30:03
---
Reproducibility information:
* I cannot reproduce the GPU lockup on a Radeon HD 4350 card.
* On the Radeon HD 6450, I can reproduce the GPU lockup with applications other
than
Hi Ben, Dave,
Since 3.5-rc0, I have been experiencing occasional screen corruption
on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver
version is xf86-video-nouvea-1.0.1-1 (arch).
I do not know what the root problem is, but I have been able to
isolate the symptoms to the usage
On Wed, Jul 04, 2012 at 10:47:06AM +1000, Dave Chinner wrote:
SNIP
[c999a223: xfs: introduce an allocation workqueue]
Which indicates that there is workqueue scheduling issues, I think.
The same amount of work is being done, but half of it is being
pushed off into a workqueue
On Thu, Jul 05, 2012 at 08:31:13AM +0200, Henrik Rydberg wrote:
Hi Ben, Dave,
Hey Henrik,
Since 3.5-rc0, I have been experiencing occasional screen corruption
on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver
version is xf86-video-nouvea-1.0.1-1 (arch).
I do not know
On Thu, Jul 5, 2012 at 8:00 AM, Meelis Roos mr...@linux.ee wrote:
In 2.6.32, radeon worked fine.
In 3.4, radeon worked with a glitch - window titles were see-throug (not
drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
acceleration on this system at all. Full dmesg
Thanks for tracking down the source of this corruption. I don't have
any such hardware, so until someone can figure it out, I think we
should apply this patch.
In that case, I would have to massage the patch a bit first; it
creates a problem with suspend/resume. Might be something with
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #13 from Jean Delvare kh...@linux-fr.org 2012-07-05 07:30:03 ---
Reproducibility information:
* I cannot reproduce the GPU lockup on a Radeon HD 4350 card.
* On the Radeon HD 6450, I can reproduce the GPU lockup with
In 2.6.32, radeon worked fine.
In 3.4, radeon worked with a glitch - window titles were see-throug (not
drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
acceleration on this system at all. Full dmesg below.
Fujitsu Lifebook P series, 256M RAM, 239 usable.
[0.00]
On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote:
Thanks for tracking down the source of this corruption. I don't have
any such hardware, so until someone can figure it out, I think we
should apply this patch.
In that case, I would have to massage the patch a bit first; it
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the the framebuffer stride is smaller than the maximum
accepted by any plane.
Also when using a tiled memory make sure the object stride matches
the
On Thu, May 24, 2012 at 09:08:56PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Zero initialize the mode_cmd structure when creating the kernel
framebuffer. Avoids having uninitialized data in offsets[0] for
instance.
Signed-off-by: Ville
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
On Thu, 24 May 2012 21:08:58 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
On Thu, May 24, 2012 at 09:08:59PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
MI display flips can't handle some changes in the framebuffer
format or layout. Return an error in such cases.
Signed-off-by: Ville Syrjälä
On Thu, Jul 05, 2012 at 01:27:47PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the the framebuffer stride is smaller than the maximum
accepted by any plane.
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
On Thu, 24 May 2012 21:08:58 +0300
Here's a new proposal that should address all issues collected during
the discussion of the previous one:
From tegra20.dtsi:
host1x {
compatible = nvidia,tegra20-host1x, simple-bus;
reg = 0x5000 0x00024000;
interrupts = 0 65 0x04 /*
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher:
On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel wrote:
Am Samstag, den 30.06.2012, 21:00 +0200 schrieb Paul Menzel:
Am Dienstag, den 26.06.2012,
Hi Sascha,
Thanks for the patch.
On Wednesday 04 July 2012 09:56:35 Sascha Hauer wrote:
This patch adds a helper function for parsing videomodes from the
devicetree. The videomode can be either converted to a struct
drm_display_mode or a struct fb_videomode.
Signed-off-by: Sascha Hauer
https://bugzilla.kernel.org/show_bug.cgi?id=15486
Alan a...@lxorguk.ukuu.org.uk changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=15486
Alex Deucher alexdeuc...@gmail.com changed:
What|Removed |Added
CC|
On Thu, Jul 05, 2012 at 04:08:07PM +0200, Laurent Pinchart wrote:
Hi Sascha,
Thanks for the patch.
+++ b/Documentation/devicetree/bindings/video/displaymode
@@ -0,0 +1,40 @@
+videomode bindings
+==
+
+Required properties:
+ - xres, yres: Display resolution
+ -
On Thu, Jul 05, 2012 at 09:51:39AM -0500, Rob Herring wrote:
On 07/04/2012 02:56 AM, Sascha Hauer wrote:
+
+There are different ways of describing a display mode. The devicetree
representation
+corresponds to the one used by the Linux Framebuffer framework described
here in
On 07/04/2012 02:56 AM, Sascha Hauer wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
changes since v1:
In 3.4, radeon worked with a glitch - window titles were see-throug (not
drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
acceleration on this system at all. Full dmesg below.
Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?
That was a good
From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra-
ow...@vger.kernel.org] On Behalf Of Thierry Reding
Sent: Thursday, July 05, 2012 8:15 PM
To: linux-te...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org; dri-devel@lists.freedesktop.org
Subject: Re: Tegra DRM device tree
47 matches
Mail list logo
