Hi,
I've been finding that kmemleak reports that i915 is leaking gem
buffers (although it takes about 20 minutes before the supposed leaks
occur). The leaks normally occur in batches of 13 and seem to require
chrome to be running looking at a page like google.com while a
gnome-terminal is also pr
> > Hi!
> >
> > ? ? ? ?I been working on updating the VIA kernel driver to using KMS
> > and TTM. So this weekend I started to implement a couple of buffer
> > allocations internally to the driver from the video ram. So the first
> > buffer I allocated was not the front buffer from the video vram
On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
>> the front buffer. The problem was the buffer offset for the second
>> allocation was the same as the VQ buffer. I'm stump to what I'm doing
>> wrong, so does anyone have a idea?
>
> I gave up trying to understand TTM (they don't make happy pills t
> the front buffer. The problem was the buffer offset for the second
> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> wrong, so does anyone have a idea?
I gave up trying to understand TTM (they don't make happy pills that big)
and used GEM and a simple allocator. The pri
TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no
evict flags, then i guess it got evicted on first bo allocation which
is strange, maybe first bo has some lpfn constraint.
>> > =A0 =A0 =A0 =A0Second question I have is how are monochrome cursor ima=
ges
>> > handled with KMS. Yes
Hi!
I been working on updating the VIA kernel driver to using KMS
and TTM. So this weekend I started to implement a couple of buffer
allocations internally to the driver from the video ram. So the first
buffer I allocated was not the front buffer from the video vram but a
virtual queu
On 10/03/2011 06:46 PM, Konrad Rzeszutek Wilk wrote:
>
> It does now (I had a spinlock mishap).. which reminds me - how
> do I test these patches with your vmwgfx driver? I've an old version
> of VMWare Workstation 8, would that do?
>
VMware workstation 8 is OK (it's actually the latest versio
On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
>
>> Konrad,
>>
>> I'm really sorry for taking so long to review this.
>>
> That is OK. We all are busy - and it gave me some time to pretty
> up the code even more.
>
> Thats fine as long as you don't want to do acceleration or object
> migration between GTT
> and VRAM type memory. Now I expect when you give out this advice you
Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effectively in the GART with the 'stolen' pages pre
Hi, Konrad Rzeszutek Wilk.
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Tuesday, October 04, 2011 12:46 AM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> kyungmin.p...@samsung.com; sw0312@samsung.com;
jy0922.s...@
Hi, Dave.
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Monday, October 03, 2011 7:17 PM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> kyungmin.p...@samsung.com
> Subject: Re: [RESEND] An inquiry about DRM Driver for Samsung SoC Exy
On Mon, 3 Oct 2011 16:21:08 -0700, Jesse Barnes
wrote:
> Agreed; fortunately shutting everything off when no outputs are
> active should be simpler than trying flip the bits on & off every mode
> set. :)
We'd have to track when outputs are shut off; just tracking per clock
doesn't seem any hard
edesktop.org/archives/dri-devel/attachments/20111003/fcb63202/attachment-0001.pgp>
On Mon, Oct 3, 2011 at 3:37 PM, James Simmons wrote:
>
>> > Hi!
>> >
>> > ? ? ? ?I been working on updating the VIA kernel driver to using KMS
>> > and TTM. So this weekend I started to implement a couple of buffer
>> > allocations internally to the driver from the video ram. So the first
>> > buf
On Mon, 03 Oct 2011 16:18:48 -0700
Keith Packard wrote:
> On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
> wrote:
>
> > Now... is keeping the various refclks enabled costing us any power?
> > IOW, should we be trying to disable them when everything has been
> > DPMS'd off too?
>
> That's the
On Mon, 03 Oct 2011 16:18:48 -0700
Keith Packard wrote:
> On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
> wrote:
>
> > Now... is keeping the various refclks enabled costing us any power?
> > IOW, should we be trying to disable them when everything has been
> > DPMS'd off too?
>
> That's the
On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
wrote:
> Now... is keeping the various refclks enabled costing us any power?
> IOW, should we be trying to disable them when everything has been
> DPMS'd off too?
That's the same as tracking usage and enabling/disabling on the fly as
modes are set
pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111003/de04839d/attachment.pgp>
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> ? ? ? ?I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> ? ? ? ?I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
On Wed, 28 Sep 2011 15:22:48 -0300
Paulo Zanoni wrote:
> 2011/9/27 Keith Packard :
> > Here's a patch sequence which cleans up a bunch of PCH refclk related
> > bits.
>
> For the series: Tested-by: Paulo Zanoni
>
> Tested all the patches on Ironlake (LVDS + VGA). Fixes fd.o bug #38750 for me.
On Wed, 28 Sep 2011 15:22:48 -0300
Paulo Zanoni wrote:
> 2011/9/27 Keith Packard :
> > Here's a patch sequence which cleans up a bunch of PCH refclk related
> > bits.
>
> For the series: Tested-by: Paulo Zanoni
>
> Tested all the patches on Ironlake (LVDS + VGA). Fixes fd.o bug #38750 for me.
On Tue, 27 Sep 2011 11:11:57 -0700
Keith Packard wrote:
> On Tue, 27 Sep 2011 17:56:39 +0100, Chris Wilson
> wrote:
>
> > Ah, now I see why we moved from using the active configuration earlier. ;-)
>
> My evil plan is revealed!
>
> > Doesn't this prevent us from ever using SSC though, as vir
On Tue, 27 Sep 2011 11:11:57 -0700
Keith Packard wrote:
> On Tue, 27 Sep 2011 17:56:39 +0100, Chris Wilson chris-wilson.co.uk> wrote:
>
> > Ah, now I see why we moved from using the active configuration earlier. ;-)
>
> My evil plan is revealed!
>
> > Doesn't this prevent us from ever using S
On Fri, 30 Sep 2011 11:17:38 -0700
Keith Packard wrote:
> On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o wrote:
>
> > What kind of battery life do you get with these patches applied, out
> > of curiosity?
>
> 4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
> same as people
On Thu, 29 Sep 2011 18:09:42 -0700
Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
These VDD AUX changes look good, ack on all of them.
--
Jesse Barnes,
On Fri, 30 Sep 2011 11:17:38 -0700
Keith Packard wrote:
> On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o wrote:
>
> > What kind of battery life do you get with these patches applied, out
> > of curiosity?
>
> 4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
> same as people
On Thu, 29 Sep 2011 18:09:48 -0700
Keith Packard wrote:
> The return value was unused, so just stop doing that.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/inte
On Thu, 29 Sep 2011 18:09:48 -0700
Keith Packard wrote:
> The return value was unused, so just stop doing that.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/inte
On Thu, 29 Sep 2011 18:09:42 -0700
Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
These VDD AUX changes look good, ack on all of them.
--
Jesse Barnes,
On Thu, 29 Sep 2011 18:09:37 -0700
Keith Packard wrote:
> Verify that the eDP VDD is on, either with the panel being on or with
> the VDD force-on bit being set.
>
> This demonstrates that in many instances, VDD is not on when needed,
> which leads to failed EDID communications.
>
> Signed-off-
On Thu, 29 Sep 2011 18:09:37 -0700
Keith Packard wrote:
> Verify that the eDP VDD is on, either with the panel being on or with
> the VDD force-on bit being set.
>
> This demonstrates that in many instances, VDD is not on when needed,
> which leads to failed EDID communications.
>
> Signed-off-
On Fri, 30 Sep 2011 10:58:26 -0700
Keith Packard wrote:
> On Fri, 30 Sep 2011 18:32:35 +0200, Daniel Vetter wrote:
>
> > Ok, this is way over my head, just checked whether the patch does what it
> > claims to - nice exercise in reading dp modeset code ;-)
>
> Yeah, it's purely heuristic -- the
On Fri, 30 Sep 2011 10:58:26 -0700
Keith Packard wrote:
> On Fri, 30 Sep 2011 18:32:35 +0200, Daniel Vetter wrote:
>
> > Ok, this is way over my head, just checked whether the patch does what it
> > claims to - nice exercise in reading dp modeset code ;-)
>
> Yeah, it's purely heuristic -- the
On Mon, Oct 03, 2011 at 03:18:32AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:42 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> Signed-off-by: Jakob Bornecrantz
> >> Reviewed-by: Th
On Mon, Oct 03, 2011 at 03:12:17AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:50 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> More preparation for Screen Object support.
> >>
> >>
On Fri, 30 Sep 2011 18:17:32 +0200
Daniel Vetter wrote:
> On Thu, Sep 29, 2011 at 06:09:33PM -0700, Keith Packard wrote:
> > We were relying on the BIOS to set these bits, which doesn't always
> > happen.
> >
> > Signed-off-by: Keith Packard
>
> Ok, I'll try to increase our review-bandwidth fo
On Mon, Oct 3, 2011 at 3:37 PM, James Simmons wrote:
>
>> > Hi!
>> >
>> > I been working on updating the VIA kernel driver to using KMS
>> > and TTM. So this weekend I started to implement a couple of buffer
>> > allocations internally to the driver from the video ram. So the first
>> > buf
On Fri, 30 Sep 2011 18:17:32 +0200
Daniel Vetter wrote:
> On Thu, Sep 29, 2011 at 06:09:33PM -0700, Keith Packard wrote:
> > We were relying on the BIOS to set these bits, which doesn't always
> > happen.
> >
> > Signed-off-by: Keith Packard
>
> Ok, I'll try to increase our review-bandwidth fo
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
On Fri, Sep 30, 2011 at 06:43:16PM +0900, Inki Dae wrote:
> I am sorry for missed title.
Hey Dave,
I took a look at the driver with memory/DMA in mind and it looks
good to me.
>
>
>
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Friday, September 30, 2011 6:39 PM
> To: 'airlied at
On Mon, Oct 03, 2011 at 06:35:42PM +0200, Thomas Hellstrom wrote:
> On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> >>Konrad,
> >>
> >>I'm really sorry for taking so long to review this.
> >That is OK. We all are busy - and
> > Hi!
> >
> > I been working on updating the VIA kernel driver to using KMS
> > and TTM. So this weekend I started to implement a couple of buffer
> > allocations internally to the driver from the video ram. So the first
> > buffer I allocated was not the front buffer from the video vram
On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
>> the front buffer. The problem was the buffer offset for the second
>> allocation was the same as the VQ buffer. I'm stump to what I'm doing
>> wrong, so does anyone have a idea?
>
> I gave up trying to understand TTM (they don't make happy pills t
> the front buffer. The problem was the buffer offset for the second
> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> wrong, so does anyone have a idea?
I gave up trying to understand TTM (they don't make happy pills that big)
and used GEM and a simple allocator. The pri
On Mon, Oct 3, 2011 at 3:01 PM, James Simmons wrote:
>
> Hi!
>
> I been working on updating the VIA kernel driver to using KMS
> and TTM. So this weekend I started to implement a couple of buffer
> allocations internally to the driver from the video ram. So the first
> buffer I allocated wa
On Sat, Oct 1, 2011 at 21:01, Keith Packard wrote:
> On Sat, 1 Oct 2011 11:59:09 +0200, Daniel Vetter wrote:
>
>> So while you bang your head against this, can you add the backlight power
>> sequencing delays for lvds panels, too? The lvds panel power sequencing
>> should be imo safe - we just ms
Hi!
I been working on updating the VIA kernel driver to using KMS
and TTM. So this weekend I started to implement a couple of buffer
allocations internally to the driver from the video ram. So the first
buffer I allocated was not the front buffer from the video vram but a
virtual queu
> diff --git a/drivers/gpu/drm/samsung/Kconfig b/drivers/gpu/drm/samsung/Kconfig
> new file mode 100644
> index 000..34cedda
> --- /dev/null
> +++ b/drivers/gpu/drm/samsung/Kconfig
> @@ -0,0 +1,18 @@
> +config DRM_SAMSUNG
> + tristate "DRM Support for Samsung SoC EXYNOS Series"
> + depe
>
> We would look forward to your comments. thank you.
I think the only thing I can see wanting changing at this point is to
add padding to the
offset ioctl.
struct drm_samsung_gem_map_off {
unsigned int handle;
uint64_t offset;
};
just add an unsigned int pad; between the two me
On Mon, Oct 03, 2011 at 03:18:32AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:42 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> Signed-off-by: Jakob Bornecrantz
> >> Reviewed-by: Th
On Mon, Oct 03, 2011 at 03:12:17AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:50 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> More preparation for Screen Object support.
> >>
> >>
On 10/03/2011 06:46 PM, Konrad Rzeszutek Wilk wrote:
It does now (I had a spinlock mishap).. which reminds me - how
do I test these patches with your vmwgfx driver? I've an old version
of VMWare Workstation 8, would that do?
VMware workstation 8 is OK (it's actually the latest version of
On Fri, Sep 30, 2011 at 06:43:16PM +0900, Inki Dae wrote:
> I am sorry for missed title.
Hey Dave,
I took a look at the driver with memory/DMA in mind and it looks
good to me.
>
>
>
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Friday, September 30, 2011 6:39 PM
> To: 'airl...@linux
On Mon, Oct 03, 2011 at 06:35:42PM +0200, Thomas Hellstrom wrote:
> On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> >>Konrad,
> >>
> >>I'm really sorry for taking so long to review this.
> >That is OK. We all are busy - and
On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
Konrad,
I'm really sorry for taking so long to review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
I'd like to
2011/9/30 Michel D?nzer :
> While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image
> off-by-one error', I noticed at least one other bug (fixed by patch 2, and one
> potential bug fixed by patch 3) and opportunities for cleanup.
>
> Patch 1 is based on Nicholas' patch and can be d
https://bugs.freedesktop.org/show_bug.cgi?id=7271
Eugeni Dodonov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #25 from Alex Deucher 2011-10-03 09:18:30 PDT ---
(In reply to comment #24)
>
> R600_TILING=1 produces the rendering errors.
> Is it still worth a new bug report?
R600_TILING=1 enables 2D tiling of textures. It's off by default bec
https://bugs.freedesktop.org/show_bug.cgi?id=7271
Eugeni Dodonov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #25 from Alex Deucher 2011-10-03 09:18:30 PDT
---
(In reply to comment #24)
>
> R600_TILING=1 produces the rendering errors.
> Is it still worth a new bug report?
R600_TILING=1 enables 2D tiling of textures. It's off by default be
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #24 from chrisdh...@googlemail.com 2011-10-03 09:15:35 PDT ---
(In reply to comment #23)
> (In reply to comment #22)
> > I completely forgot that I had set the R600_TILING variable to 1. It
> > overrode
> > the xorg settings.
>
> The
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #24 from chrisdhaag at googlemail.com 2011-10-03 09:15:35 PDT ---
(In reply to comment #23)
> (In reply to comment #22)
> > I completely forgot that I had set the R600_TILING variable to 1. It
> > overrode
> > the xorg settings.
>
>
From: Alex Deucher
The previous code could potentially loop forever. Limit
the number of DP aux defer retries to 4 for native aux
transactions, same as i2c over aux transactions.
Noticed by: Brad Campbell
Signed-off-by: Alex Deucher
Cc: Brad Campbell
Cc: stable at kernel.org
---
drivers/gp
From: Alex Deucher
An incorrect ordering in the error checking code lead
to DP aux defer being skipped in the aux native write
path. Move the bytes transferred check (ret == 0)
below the defer check.
Tracked down by: Brad Campbell
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Sig
https://bugs.freedesktop.org/show_bug.cgi?id=41420
Michel Dänzer changed:
What|Removed |Added
Product|xorg|DRI
Component|Driver/Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=41420
Michel D?nzer changed:
What|Removed |Added
Product|xorg|DRI
Component|Driver/Radeon
> diff --git a/drivers/gpu/drm/samsung/Kconfig b/drivers/gpu/drm/samsung/Kconfig
> new file mode 100644
> index 000..34cedda
> --- /dev/null
> +++ b/drivers/gpu/drm/samsung/Kconfig
> @@ -0,0 +1,18 @@
> +config DRM_SAMSUNG
> + tristate "DRM Support for Samsung SoC EXYNOS Series"
> + depe
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #4 from Franz Brauße 2011-10-03 08:42:26
PDT ---
Created an attachment (id=51898)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51898)
complete dmesg for 3.1.0-rc8+
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #4 from Franz Brau?e 2011-10-03
08:42:26 PDT ---
Created an attachment (id=51898)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51898)
complete dmesg for 3.1.0-rc8+
--
Configure bugmail: https://bugs.freedesktop.org/userpref
From: Alex Deucher
Only disable the pipe if the monitor is physically
disconnected. The previous logic also disabled the
pipe if the link was trained.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41248
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/rad
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #3 from Franz Brauße 2011-10-03 08:36:17
PDT ---
The issue is also present in the latest git kernel from today, 3.1.0-rc8+,
commit 9b13776977d45505469edc6decc93e9e3799afe2
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #3 from Franz Brau?e 2011-10-03
08:36:17 PDT ---
The issue is also present in the latest git kernel from today, 3.1.0-rc8+,
commit 9b13776977d45505469edc6decc93e9e3799afe2
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #23 from Michel Dänzer 2011-10-03 07:48:43 PDT
---
(In reply to comment #22)
> I completely forgot that I had set the R600_TILING variable to 1. It overrode
> the xorg settings.
They're not directly related. Does the problem occur w
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #23 from Michel D?nzer 2011-10-03 07:48:43
PDT ---
(In reply to comment #22)
> I completely forgot that I had set the R600_TILING variable to 1. It overrode
> the xorg settings.
They're not directly related. Does the problem occur w
https://bugs.freedesktop.org/show_bug.cgi?id=41418
Franz Brauße changed:
What|Removed |Added
Attachment #51895|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #2 from Franz Brauße 2011-10-03 07:45:55
PDT ---
Created an attachment (id=51895)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51895)
dmesg output of a modetest run with 1400x1050 resolution and drm.debug=15
--
Configure bu
https://bugs.freedesktop.org/show_bug.cgi?id=41418
Franz Brau?e changed:
What|Removed |Added
Attachment #51895|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #2 from Franz Brau?e 2011-10-03
07:45:55 PDT ---
Created an attachment (id=51895)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51895)
dmesg output of a modetest run with 1400x1050 resolution and drm.debug=15
--
Configure bu
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #1 from Franz Brauße 2011-10-03 07:42:20
PDT ---
Created an attachment (id=51894)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51894)
Corrupted screen
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=ema
https://bugs.freedesktop.org/show_bug.cgi?id=41418
--- Comment #1 from Franz Brau?e 2011-10-03
07:42:20 PDT ---
Created an attachment (id=51894)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51894)
Corrupted screen
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=ema
https://bugs.freedesktop.org/show_bug.cgi?id=41418
Summary: [RV350] Screen corruption with certain resolutions on
LVDS (scaled)
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=41418
Summary: [RV350] Screen corruption with certain resolutions on
LVDS (scaled)
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=24475
--- Comment #4 from Marco Albanese 2011-10-03 07:08:00 PDT
---
(In reply to comment #3)
> (In reply to comment #2)
> > Yes it is still relevant, unfortunately. On my Thinkpad T41 at least (ATI
> > Technologies Inc Radeon Mobility M7 LW [Radeon M
https://bugs.freedesktop.org/show_bug.cgi?id=24475
--- Comment #4 from Marco Albanese 2011-10-03 07:08:00
PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Yes it is still relevant, unfortunately. On my Thinkpad T41 at least (ATI
> > Technologies Inc Radeon Mobility M7 LW [Radeon M
2011/9/30 Michel Dänzer :
> While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image
> off-by-one error', I noticed at least one other bug (fixed by patch 2, and one
> potential bug fixed by patch 3) and opportunities for cleanup.
>
> Patch 1 is based on Nicholas' patch and can be d
From: Alex Deucher
The previous code could potentially loop forever. Limit
the number of DP aux defer retries to 4 for native aux
transactions, same as i2c over aux transactions.
Noticed by: Brad Campbell
Signed-off-by: Alex Deucher
Cc: Brad Campbell
Cc: sta...@kernel.org
---
drivers/gpu/d
From: Alex Deucher
An incorrect ordering in the error checking code lead
to DP aux defer being skipped in the aux native write
path. Move the bytes transferred check (ret == 0)
below the defer check.
Tracked down by: Brad Campbell
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Sig
https://bugs.freedesktop.org/show_bug.cgi?id=41248
--- Comment #6 from Alex Deucher 2011-10-03 05:38:17 PDT ---
I've sent the patch upstream:
http://lists.freedesktop.org/archives/dri-devel/2011-October/014882.html
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
From: Alex Deucher
Only disable the pipe if the monitor is physically
disconnected. The previous logic also disabled the
pipe if the link was trained.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41248
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon
https://bugs.freedesktop.org/show_bug.cgi?id=41248
--- Comment #6 from Alex Deucher 2011-10-03 05:38:17 PDT
---
I've sent the patch upstream:
http://lists.freedesktop.org/archives/dri-devel/2011-October/014882.html
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
On Thu, Sep 29, 2011 at 11:42 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Sep 28, 2011 at 04:10:02PM +0200, Thomas Hellstrom wrote:
>> From: Jakob Bornecrantz
>>
>> Signed-off-by: Jakob Bornecrantz
>> Reviewed-by: Thomas Hellstrom
>> ---
>> ?drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | ? ?5 +
>
On Thu, Sep 29, 2011 at 11:42 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
>> From: Jakob Bornecrantz
>>
>> Signed-off-by: Jakob Bornecrantz
>> Reviewed-by: Thomas Hellstrom
>> ---
>> ?drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | ? ?5 -
>> ?1
>
> We would look forward to your comments. thank you.
I think the only thing I can see wanting changing at this point is to
add padding to the
offset ioctl.
struct drm_samsung_gem_map_off {
unsigned int handle;
uint64_t offset;
};
just add an unsigned int pad; between the two me
On Thu, Sep 29, 2011 at 11:50 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
>> From: Jakob Bornecrantz
>>
>> More preparation for Screen Object support.
>>
>> Signed-off-by: Jakob Bornecrantz
>> Signed-off-by: Thomas Hellstrom
>> ---
>> ?dr
On Sat, Oct 1, 2011 at 21:01, Keith Packard wrote:
> On Sat, 1 Oct 2011 11:59:09 +0200, Daniel Vetter wrote:
>
>> So while you bang your head against this, can you add the backlight power
>> sequencing delays for lvds panels, too? The lvds panel power sequencing
>> should be imo safe - we just ms
On Fri, Sep 30, 2011 at 12:05 AM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Sep 28, 2011 at 04:10:08PM +0200, Thomas Hellstrom wrote:
>> From: Jakob Bornecrantz
>>
>> Signed-off-by: Jakob Bornecrantz
>> Signed-off-by: Thomas Hellstrom
>> ---
>> ?drivers/gpu/drm/vmwgfx/Makefile ? ? ?| ? ?2 +-
>> ?d
97 matches
Mail list logo
