ry 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 Cor
> > 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 go
> 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 tr
ry 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 Cor
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: Display
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 Hauer
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 21:08:58
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 usin
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:
> > >
> > > > Fro
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.
> > 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 go
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 hyphens
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 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 fir
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 hyphens
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
https://bugzilla.kernel.org/show_bug.cgi?id=15486
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
https://bugzilla.kernel.org/show_bug.cgi?id=15486
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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 Michel
> 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
nva3
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 of
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 i
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 Firef
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
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 Michel
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 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
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ä
> >
> > Make sure the the framebuffer stride is smaller than the maximum
> > accepted by any plane.
> >
> > Also when using a ti
On Thu, May 24, 2012 at 09:08:59PM +0300, ville.syrj...@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. I've
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:
On Thu, May 24, 2012 at 09:08:56PM +0300, ville.syrj...@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 -nex
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@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 fir
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]
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 Firefo
> 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
nva3
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 i
45 matches
Mail list logo
