From: Alex Deucher
- Properly set up the RBs
- Properly set up the SPI
- Properly set up gb_addr_config
This should fix rendering issues on certain cards.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |5 +-
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
drivers/gpu/
Hi Linus,
A bunch of fixes:
vmware memory corruption, ttm spinlock balance,
cirrus/mgag200, work in the presence of efifb
and finally Alex and Jerome managed to track down a magic set of bits that
on certain rv740 and evergreen cards allow the correct use of the
complete set of render backends
On Tue, May 29, 2012 at 5:19 PM, Bjorn Helgaas wrote:
> On Mon, May 21, 2012 at 11:27 AM, Steven Newbury
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 18/05/12 10:08, Yinghai Lu wrote:
>>> On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu
>>> wrote:
On Thu, May 17, 2012
On Fri, Jun 01, 2012 at 02:21:25PM +0800, Dave Young wrote:
> Today I got a lot i915 warnings on a thinkpad t400, here is the something
> copied from syslog:
> [Known issue?]
The gpu refuses to clear the write fifo. Which means it pretty much
disappeared into nirvana. The kernel _should_ detect t
https://bugs.freedesktop.org/show_bug.cgi?id=50594
Bug #: 50594
Summary: VDPAU checks version of wrong DRM driver
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: Linux (All)
Status:
From: Alex Deucher
- Properly set up the RBs
- Properly set up the SPI
- Properly set up gb_addr_config
This should fix rendering issues on certain cards.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |5 +-
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
drivers/gpu/
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Cc: stable at vger.kernel.org
---
Adding reviewed-by Jakob.
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
b/drivers/gpu/drm/vmwgfx/
This imbalance may cause hangs when TTM is trying to swap out a buffer
that is already on the delayed delete list.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletion
A typo may cause a write past the allocated area on 32-bit systems and
a resulting kernel oops. Triggers for example with the catia-03
Specviewperf test.
Signed-off-by: Thomas Hellstrom
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +-
1 files changed, 1 insertions
On Thu, May 31, 2012 at 03:54:03PM -0400, Alex Deucher wrote:
> On Thu, May 31, 2012 at 3:44 PM, Singh, Satyeshwar
> wrote:
> > Does this by extension mean that stride changes should also not be allowed
> > while page flipping?
>
> Everything beyond a crtc base address change should require a fu
Today I got a lot i915 warnings on a thinkpad t400, here is the something
copied from syslog:
[Known issue?]
Jun 1 13:31:13 localhost kernel: [15935.915986] [ cut here
]
Jun 1 13:31:13 localhost kernel: [15935.916009] WARNING: at
drivers/gpu/drm/i915/i915_drv.c:440 __g
On Fri, 2012-06-01 at 09:27 +0200, Paul Menzel wrote:
> Am Donnerstag, den 31.05.2012, 19:00 -0400 schrieb alexdeucher at gmail.com:
> > From: Alex Deucher
> >
> > Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and
> > simplify render backend map. This now properly sets up th
From: Christian Koenig
The shader preemption on cayman doesn't work
correctly with multiple rings. So to be able to
still make use of the compute rings we use a
semaphore to make sure that only one IB can execute
at the same time.
This isn't as effective as shader preemption, but
also isn't as b
Try to remove or replace the cs_mutex with a
vm_mutex where it is still needed.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c |7 ++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
From: Christian Koenig
So we can skip the looking. Also renames sw_int to
ring_int, cause that better matches its purpose.
Signed-off-by: Christian Koenig
---
drivers/gpu/drm/radeon/evergreen.c | 32 -
drivers/gpu/drm/radeon/r100.c | 10 +++---
drivers/gpu/dr
From: Christian Koenig
1. It is really dangerous to have more than one
spinlock protecting the same information.
2. radeon_irq_set sometimes wasn't called with lock
protection, so it can happen that more than one
CPU would tamper with the irq regs at the same
time.
3. The pm.gui_idl
From: Christian Koenig
The spinlock was actually there to protect the
rptr, but rptr was read outside of the locked area.
Also we don't really need a spinlock here, an
atomic should to quite fine since we only need to
prevent it from being reentrant.
v2: Keep the spinlock
v3: Back to an ato
From: Christian Koenig
Signed-off-by: Christian Koenig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index af57d1f..e68db99 100644
--- a/drivers/gpu/drm/ra
It is a rw_semaphore now and only write locked
while changing the clock. Also the lock is renamed
to better reflect what it is protecting.
v2: Keep the ttm_vm_ops on IGPs
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|3 ++-
drivers/gp
Move inter ring syncing with semaphores into the
existing ring allocations, with that we need to
lock the ring mutex only once.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |3 +-
drivers/gpu/drm/radeon/r600.c |5
v2: BUG_ON not matching rings.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 25 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 73 +
2 files changed, 87 insertions(+), 11 deletions(-)
diff --git a
It is completely unnecessary to create fences
before they are emitted, so remove it and a bunch
of checks if fences are emitted or not.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c|2 +-
drivers/gpu/drm/radeon/ni.c |
> -Original Message-
> From: Paul Menzel [mailto:paulepanter at users.sourceforge.net]
> Sent: Friday, June 01, 2012 3:37 AM
> To: alexdeucher at gmail.com
> Cc: airlied at gmail.com; dri-devel at lists.freedesktop.org; Deucher,
> Alexander;
> stable at vger.kernel.org
> Subject: Re: [PA
On Fre, 2012-06-01 at 12:44 +0200, Christian K?nig wrote:
> On 01.06.2012 08:30, Michel D?nzer wrote:
> > On Fre, 2012-06-01 at 08:19 +0200, Michel D?nzer wrote:
> >> I think this might introduce a race condition:
> >>
> >> Thread 0 Thread 1
> >>
> >> atomic_inc_return() returns
On 01.06.2012 08:30, Michel D?nzer wrote:
> On Fre, 2012-06-01 at 08:19 +0200, Michel D?nzer wrote:
>> I think this might introduce a race condition:
>>
>> Thread 0 Thread 1
>>
>> atomic_inc_return() returns 1
>> spin_lock_irqsave()
>> atomic_dec_and_test()
>> radeon_irq_set()
>>
On 01.06.2012 12:08, Steven Newbury wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I have two DRM devices, i965 onboard, and a Radeon in a docking station.
>
> Both devices are enabled in my Xorg server layout Screen0 is the i965,
> and Screen1, the Radeon.
>
> When I run vdpauinfo or
emlock?
>
> If you look further down you'll see the RV740 being programmed
> separately in the rv770.c file.
Alright. Thanks. My point was more that Hemlock is missing in the commit
summary.
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120601/2bea02b1/attachment.pgp>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have two DRM devices, i965 onboard, and a Radeon in a docking station.
Both devices are enabled in my Xorg server layout Screen0 is the i965,
and Screen1, the Radeon.
When I run vdpauinfo or try using mplayer -vo vdpau on the Radeon, I
get the erro
https://bugs.freedesktop.org/show_bug.cgi?id=50389
--- Comment #1 from Michel Dänzer 2012-06-01 10:07:21 UTC
---
The radeonsi driver still defines a few of the same symbols as r600g, so they
can't be both built into egl_gallium.so at this time. radeonsi isn't really
usable yet anyway, so you pro
https://bugs.freedesktop.org/show_bug.cgi?id=50389
--- Comment #1 from Michel D?nzer 2012-06-01 10:07:21
UTC ---
The radeonsi driver still defines a few of the same symbols as r600g, so they
can't be both built into egl_gallium.so at this time. radeonsi isn't really
usable yet anyway, so you pro
MC_VM_MD_L1_TLB3_CNTL, tmp);
> }
[?]
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120601/db19a551/attachment.pgp>
xt part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120601/a5456832/attachment.pgp>
;
> WREG32(GRBM_GFX_INDEX, grbm_gfx_index);
> WREG32(RLC_GFX_INDEX, grbm_gfx_index);
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
https://bugs.freedesktop.org/show_bug.cgi?id=50594
Bug #: 50594
Summary: VDPAU checks version of wrong DRM driver
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: Linux (All)
Status:
Hi Linus,
A bunch of fixes:
vmware memory corruption, ttm spinlock balance,
cirrus/mgag200, work in the presence of efifb
and finally Alex and Jerome managed to track down a magic set of bits that
on certain rv740 and evergreen cards allow the correct use of the
complete set of render backends
https://bugs.freedesktop.org/show_bug.cgi?id=50450
--- Comment #10 from Michel D?nzer 2012-06-01 02:09:16
PDT ---
Does passing radeon.agpmode=-1 on the kernel command line help?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail becau
On Fri, Jun 1, 2012 at 8:37 AM, Paul Menzel
wrote:
> Am Donnerstag, den 31.05.2012, 18:54 -0400 schrieb alexdeucher at gmail.com:
>> From: Alex Deucher
>>
>> Need to program an additional VM register. ?This doesn't not currently
>> cause any problems, but allows us to program the proper backend
>
On Fre, 2012-06-01 at 08:19 +0200, Michel D?nzer wrote:
>
> I think this might introduce a race condition:
>
> Thread 0 Thread 1
>
> atomic_inc_return() returns 1
> spin_lock_irqsave()
> atomic_dec_and_test()
> radeon_irq_set()
>
> => the interrupt won't be enabled.
Hrmm, I m
On Don, 2012-05-31 at 22:16 +0200, Christian K?nig wrote:
>
> So we can skip the looking.
'locking'
> diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> index 73cd0fd..52f85ba 100644
> --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> +++ b/driver
On Fri, Jun 01, 2012 at 02:21:25PM +0800, Dave Young wrote:
> Today I got a lot i915 warnings on a thinkpad t400, here is the something
> copied from syslog:
> [Known issue?]
The gpu refuses to clear the write fifo. Which means it pretty much
disappeared into nirvana. The kernel _should_ detect t
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Cc: sta...@vger.kernel.org
---
Adding reviewed-by Jakob.
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
b/drivers/gpu/drm/vmwgfx/vmw
This imbalance may cause hangs when TTM is trying to swap out a buffer
that is already on the delayed delete list.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-
A typo may cause a write past the allocated area on 32-bit systems and
a resulting kernel oops. Triggers for example with the catia-03
Specviewperf test.
Signed-off-by: Thomas Hellstrom
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +-
1 files changed, 1 insertions(+)
> -Original Message-
> From: Paul Menzel [mailto:paulepan...@users.sourceforge.net]
> Sent: Friday, June 01, 2012 3:37 AM
> To: alexdeuc...@gmail.com
> Cc: airl...@gmail.com; dri-devel@lists.freedesktop.org; Deucher, Alexander;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/radeon: p
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #81 from t...@math.tu-berlin.de 2012-06-01 06:10:32 UTC ---
Well, I've got a bit futher:
1) One can get i2c access mostly reliable when the drm.debug option is set
high. Thus, whether or not the i2c interface works is likely a matter
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #81 from thor at math.tu-berlin.de 2012-06-01 06:10:32 UTC ---
Well, I've got a bit futher:
1) One can get i2c access mostly reliable when the drm.debug option is set
high. Thus, whether or not the i2c interface works is likely a matt
On Thu, May 31, 2012 at 03:54:03PM -0400, Alex Deucher wrote:
> On Thu, May 31, 2012 at 3:44 PM, Singh, Satyeshwar
> wrote:
> > Does this by extension mean that stride changes should also not be allowed
> > while page flipping?
>
> Everything beyond a crtc base address change should require a fu
From: Christian Koenig
The shader preemption on cayman doesn't work
correctly with multiple rings. So to be able to
still make use of the compute rings we use a
semaphore to make sure that only one IB can execute
at the same time.
This isn't as effective as shader preemption, but
also isn't as b
From: Christian Koenig
So we can skip the looking. Also renames sw_int to
ring_int, cause that better matches its purpose.
Signed-off-by: Christian Koenig
---
drivers/gpu/drm/radeon/evergreen.c | 32 -
drivers/gpu/drm/radeon/r100.c | 10 +++---
drivers/gpu/dr
From: Christian Koenig
1. It is really dangerous to have more than one
spinlock protecting the same information.
2. radeon_irq_set sometimes wasn't called with lock
protection, so it can happen that more than one
CPU would tamper with the irq regs at the same
time.
3. The pm.gui_idl
From: Christian Koenig
The spinlock was actually there to protect the
rptr, but rptr was read outside of the locked area.
Also we don't really need a spinlock here, an
atomic should to quite fine since we only need to
prevent it from being reentrant.
v2: Keep the spinlock
v3: Back to an ato
Try to remove or replace the cs_mutex with a
vm_mutex where it is still needed.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c |7 ++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
From: Christian Koenig
Signed-off-by: Christian Koenig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index af57d1f..e68db99 100644
--- a/drivers/gpu/drm/ra
It is a rw_semaphore now and only write locked
while changing the clock. Also the lock is renamed
to better reflect what it is protecting.
v2: Keep the ttm_vm_ops on IGPs
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|3 ++-
drivers/gp
Move inter ring syncing with semaphores into the
existing ring allocations, with that we need to
lock the ring mutex only once.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |3 +-
drivers/gpu/drm/radeon/r600.c |5
It is completely unnecessary to create fences
before they are emitted, so remove it and a bunch
of checks if fences are emitted or not.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c|2 +-
drivers/gpu/drm/radeon/ni.c |
v2: BUG_ON not matching rings.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 25 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 73 +
2 files changed, 87 insertions(+), 11 deletions(-)
diff --git a
On Fre, 2012-06-01 at 12:44 +0200, Christian König wrote:
> On 01.06.2012 08:30, Michel Dänzer wrote:
> > On Fre, 2012-06-01 at 08:19 +0200, Michel Dänzer wrote:
> >> I think this might introduce a race condition:
> >>
> >> Thread 0 Thread 1
> >>
> >> atomic_inc_return() returns
On 01.06.2012 08:30, Michel Dänzer wrote:
On Fre, 2012-06-01 at 08:19 +0200, Michel Dänzer wrote:
I think this might introduce a race condition:
Thread 0 Thread 1
atomic_inc_return() returns 1
spin_lock_irqsave()
atomic_dec_and_test()
radeon_irq_set()
=> the interrupt won't
On 01.06.2012 12:08, Steven Newbury wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have two DRM devices, i965 onboard, and a Radeon in a docking station.
Both devices are enabled in my Xorg server layout Screen0 is the i965,
and Screen1, the Radeon.
When I run vdpauinfo or try using mp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have two DRM devices, i965 onboard, and a Radeon in a docking station.
Both devices are enabled in my Xorg server layout Screen0 is the i965,
and Screen1, the Radeon.
When I run vdpauinfo or try using mplayer -vo vdpau on the Radeon, I
get the erro
On Fri, 2012-06-01 at 09:27 +0200, Paul Menzel wrote:
> Am Donnerstag, den 31.05.2012, 19:00 -0400 schrieb alexdeuc...@gmail.com:
> > From: Alex Deucher
> >
> > Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and
> > simplify render backend map. This now properly sets up the b
Today I got a lot i915 warnings on a thinkpad t400, here is the something
copied from syslog:
[Known issue?]
Jun 1 13:31:13 localhost kernel: [15935.915986] [ cut here
]
Jun 1 13:31:13 localhost kernel: [15935.916009] WARNING: at
drivers/gpu/drm/i915/i915_drv.c:440 __g
Am Freitag, den 01.06.2012, 08:46 +0100 schrieb Dave Airlie:
> On Fri, Jun 1, 2012 at 8:37 AM, Paul Menzel wrote:
> > Am Donnerstag, den 31.05.2012, 18:54 -0400 schrieb alexdeuc...@gmail.com:
> >> From: Alex Deucher
> >>
> >> Need to program an additional VM register. This doesn't not currently
>
https://bugs.freedesktop.org/show_bug.cgi?id=50450
--- Comment #10 from Michel Dänzer 2012-06-01 02:09:16 PDT
---
Does passing radeon.agpmode=-1 on the kernel command line help?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=50422
Michel Dänzer changed:
What|Removed |Added
AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=50422
Michel D?nzer changed:
What|Removed |Added
AssignedTo|mesa-dev at lists.freedesktop. |dri-devel at
lists.freedesktop
On Fri, Jun 1, 2012 at 8:37 AM, Paul Menzel
wrote:
> Am Donnerstag, den 31.05.2012, 18:54 -0400 schrieb alexdeuc...@gmail.com:
>> From: Alex Deucher
>>
>> Need to program an additional VM register. This doesn't not currently
>> cause any problems, but allows us to program the proper backend
>> m
Am Donnerstag, den 31.05.2012, 18:54 -0400 schrieb alexdeuc...@gmail.com:
> From: Alex Deucher
>
> Need to program an additional VM register. This doesn't not currently
> cause any problems, but allows us to program the proper backend
> map in a subsequent patch which should improve performance
Hi Sascha,
it's good try to avoid demand paging way by page fault handler.
actually, we don't need demand paging way on non-iommu system. I
looked into your previous patch and I realized that patch was based on
old exynos driver. now patch looks almostly good to me and below is my
comments minor.
Am Donnerstag, den 31.05.2012, 19:00 -0400 schrieb alexdeuc...@gmail.com:
> From: Alex Deucher
>
> Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and
> simplify render backend map. This now properly sets up the backend map
> on r6xx-9xx which should improve 3D performance.
I
Am Donnerstag, den 31.05.2012, 19:00 -0400 schrieb alexdeuc...@gmail.com:
> From: Jerome Glisse
A description of the problem and the fix is missing.
> Bugs that should be fixed by this patch :
> https://bugs.freedesktop.org/show_bug.cgi?id=49792
> https://bugzilla.kernel.org/show_bug.cgi?id=4320
72 matches
Mail list logo
