headers
Dave Airlie | 1 Dec 2009 05:21
Picon
Gravatar

[PATCH] drm/radeon/kms: ignore unposted GPUs with no BIOS.

From: Dave Airlie <airlied <at> redhat.com>

If we find a GPU but we can't find its BIOS and it isn't posted,
then ignore it.

Signed-off-by: Dave Airlie <airlied <at> redhat.com>
---
 drivers/gpu/drm/radeon/r100.c          |    6 ++----
 drivers/gpu/drm/radeon/r300.c          |    6 ++----
 drivers/gpu/drm/radeon/r420.c          |   11 +++--------
 drivers/gpu/drm/radeon/r520.c          |    3 +++
 drivers/gpu/drm/radeon/r600.c          |    6 +++++-
 drivers/gpu/drm/radeon/radeon.h        |    1 +
 drivers/gpu/drm/radeon/radeon_device.c |   18 ++++++++++++++++++
 drivers/gpu/drm/radeon/rs400.c         |    7 +++----
 drivers/gpu/drm/radeon/rs600.c         |    7 +++----
 drivers/gpu/drm/radeon/rs690.c         |    7 +++----
 drivers/gpu/drm/radeon/rv515.c         |    6 ++----
 drivers/gpu/drm/radeon/rv770.c         |    6 +++++-
 12 files changed, 50 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 677fd72..79206e9 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
 <at>  <at>  -3243,10 +3243,8  <at>  <at>  int r100_init(struct radeon_device *rdev)
 			RREG32(R_0007C0_CP_STAT));
 	}
 	/* check if cards are posted or not */
-	if (!radeon_card_posted(rdev) && rdev->bios) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 Dec 2009 06:24
Picon
Favicon

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips


> This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
> are implemented via a ring buffer.  The GPU adds interrupts vectors to
> the ring and the host reads them off in the interrupt handler.  The
> interrupt controller requires firmware like the CP.  This firmware
> must be installed and accessible to the firmware loader for interrupts
> to function.

It might be nice to fail to non-interrupt operation if the firmware can't 
be found.

though I suppose distros can ship it  with the DDX if they aren't shipping 
-firmware

Dave.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 Dec 2009 06:42
Picon
Favicon

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips


> This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
> are implemented via a ring buffer.  The GPU adds interrupts vectors to
> the ring and the host reads them off in the interrupt handler.  The
> interrupt controller requires firmware like the CP.  This firmware
> must be installed and accessible to the firmware loader for interrupts
> to function.

If the fw isn't installed and you load the driver, it leafves the irq 
handler installed by the looks of it, adding the fw thenloading the driver 
really confuses things then.

Dave.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
Permalink | Reply | 1 comment |
headers
Dave Airlie | 1 Dec 2009 06:49
Picon
Favicon

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

> 
> > This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
> > are implemented via a ring buffer.  The GPU adds interrupts vectors to
> > the ring and the host reads them off in the interrupt handler.  The
> > interrupt controller requires firmware like the CP.  This firmware
> > must be installed and accessible to the firmware loader for interrupts
> > to function.
> 
> If the fw isn't installed and you load the driver, it leafves the irq 
> handler installed by the looks of it, adding the fw thenloading the driver 
> really confuses things then.

Another unload issue

BUG: sleeping function called from invalid context at 
/home/airlied/git/drm-2.6/mm/vmalloc.c:1349
in_atomic(): 1, irqs_disabled(): 1, pid: 6885, name: rmmod
Pid: 6885, comm: rmmod Not tainted 2.6.31-rc9 #80
Call Trace:
 [<ffffffff8102cd56>] __might_sleep+0xfe/0x100
 [<ffffffff810b5ffc>] vunmap+0x38/0x47
 [<ffffffffa004d313>] ttm_bo_kunmap+0x41/0x5a [ttm]
 [<ffffffffa007b6b1>] radeon_object_kunmap+0x55/0x5a [radeon]
 [<ffffffffa009bff1>] r600_ih_ring_fini+0x34/0x7a [radeon]
 [<ffffffffa009c0c1>] r600_irq_fini+0x8a/0x8e [radeon]
 [<ffffffffa009f5fb>] rv770_fini+0x21/0x9a [radeon]
 [<ffffffffa006ec89>] radeon_device_fini+0x2e/0x49 [radeon]
 [<ffffffffa006f795>] radeon_driver_unload_kms+0x26/0x41 [radeon]
 [<ffffffffa0017c90>] drm_put_dev+0xda/0x1a7 [drm]
 [<ffffffffa00590cc>] radeon_pci_remove+0x10/0x14 [radeon]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafał Miłecki | 1 Dec 2009 08:03
Picon

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

2009/12/1 Alex Deucher <alexdeucher <at> gmail.com>:
> On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <alexdeucher <at> gmail.com> wrote:
>> This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
>> are implemented via a ring buffer.  The GPU adds interrupts vectors to
>> the ring and the host reads them off in the interrupt handler.  The
>> interrupt controller requires firmware like the CP.  This firmware
>> must be installed and accessible to the firmware loader for interrupts
>> to function.
>
> Updated patch.  fixes some minor issues in the previous one.

Same issue with updated one. modprobed radeon, not a one VBLANK.
Started X and KDE, got first VBLANK on 48sec and received them cyclic
until 87sec. Then it just stopped.

--

-- 
Rafał

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Permalink | Reply | 7 comments |
headers
Michel Dänzer | 1 Dec 2009 08:33

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: 
> 2009/12/1 Alex Deucher <alexdeucher <at> gmail.com>:
> > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <alexdeucher <at> gmail.com> wrote:
> >> This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
> >> are implemented via a ring buffer.  The GPU adds interrupts vectors to
> >> the ring and the host reads them off in the interrupt handler.  The
> >> interrupt controller requires firmware like the CP.  This firmware
> >> must be installed and accessible to the firmware loader for interrupts
> >> to function.
> >
> > Updated patch.  fixes some minor issues in the previous one.
> 
> Same issue with updated one. modprobed radeon, not a one VBLANK.
> Started X and KDE, got first VBLANK on 48sec and received them cyclic
> until 87sec. Then it just stopped.

Note that vblank interrupts are only supposed to be occur while
userspace is waiting for vblank events.

--

-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
_______________________________________________
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rafał Miłecki | 1 Dec 2009 09:43
Picon

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

W dniu 1 grudnia 2009 08:33 użytkownik Michel Dänzer
<michel <at> daenzer.net> napisał:
> On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote:
>> 2009/12/1 Alex Deucher <alexdeucher <at> gmail.com>:
>> > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <alexdeucher <at> gmail.com> wrote:
>> >> This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
>> >> are implemented via a ring buffer.  The GPU adds interrupts vectors to
>> >> the ring and the host reads them off in the interrupt handler.  The
>> >> interrupt controller requires firmware like the CP.  This firmware
>> >> must be installed and accessible to the firmware loader for interrupts
>> >> to function.
>> >
>> > Updated patch.  fixes some minor issues in the previous one.
>>
>> Same issue with updated one. modprobed radeon, not a one VBLANK.
>> Started X and KDE, got first VBLANK on 48sec and received them cyclic
>> until 87sec. Then it just stopped.
>
> Note that vblank interrupts are only supposed to be occur while
> userspace is waiting for vblank events.

Could you tell me how can I wait for vblank from kernel space, please?
I see there is drm_wait_vblank but this is not yet exported. I tried
export this and use this with _DRM_VBLANK_ABSOLUTE so I hit
> DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
but that was busy waiting I think, as my desktop was almost not usable.

Also Alex believe I should *not* use drm_* for syncing my kernel
module code with vblank.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Michel Dänzer | 1 Dec 2009 09:59

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

On Tue, 2009-12-01 at 09:43 +0100, Rafał Miłecki wrote: 
> W dniu 1 grudnia 2009 08:33 użytkownik Michel Dänzer
> <michel <at> daenzer.net> napisał:
> > On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote:
> >> 2009/12/1 Alex Deucher <alexdeucher <at> gmail.com>:
> >> > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <alexdeucher <at> gmail.com> wrote:
> >> >> This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
> >> >> are implemented via a ring buffer.  The GPU adds interrupts vectors to
> >> >> the ring and the host reads them off in the interrupt handler.  The
> >> >> interrupt controller requires firmware like the CP.  This firmware
> >> >> must be installed and accessible to the firmware loader for interrupts
> >> >> to function.
> >> >
> >> > Updated patch.  fixes some minor issues in the previous one.
> >>
> >> Same issue with updated one. modprobed radeon, not a one VBLANK.
> >> Started X and KDE, got first VBLANK on 48sec and received them cyclic
> >> until 87sec. Then it just stopped.
> >
> > Note that vblank interrupts are only supposed to be occur while
> > userspace is waiting for vblank events.
> 
> Could you tell me how can I wait for vblank from kernel space, please?
> I see there is drm_wait_vblank but this is not yet exported. I tried
> export this and use this with _DRM_VBLANK_ABSOLUTE so I hit
> > DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
> but that was busy waiting I think, as my desktop was almost not usable.
> 
> Also Alex believe I should *not* use drm_* for syncing my kernel
> module code with vblank.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rafał Miłecki | 1 Dec 2009 10:01
Picon

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer
<michel <at> daenzer.net> napisał:
>> Could you tell me how can I wait for vblank from kernel space, please?
>> I see there is drm_wait_vblank but this is not yet exported. I tried
>> export this and use this with _DRM_VBLANK_ABSOLUTE so I hit
>> > DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
>> but that was busy waiting I think, as my desktop was almost not usable.
>>
>> Also Alex believe I should *not* use drm_* for syncing my kernel
>> module code with vblank.
>
> E.g. you could just call drm_vblank_get() before you need vblank
> interrupts to occur, drm_vblank_put() after you don't need them anymore
> and handle the rest from the IRQ handler.

Thanks you! I'll try that today later.

Could you just explain what is drm_wait_vblank for? I expected it to
sleep my process and wake it up interruptible on IRQ. But I'm not sure
that anymore. Also it expected drm_file parameter which AFAIK is never
passed from gpu driver, but from drm to gpu driver.

--

-- 
Rafał

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michel Dänzer | 1 Dec 2009 10:08

Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

On Tue, 2009-12-01 at 10:01 +0100, Rafał Miłecki wrote: 
> W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer
> <michel <at> daenzer.net> napisał:
> >> Could you tell me how can I wait for vblank from kernel space, please?
> >> I see there is drm_wait_vblank but this is not yet exported. I tried
> >> export this and use this with _DRM_VBLANK_ABSOLUTE so I hit
> >> > DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
> >> but that was busy waiting I think, as my desktop was almost not usable.
> >>
> >> Also Alex believe I should *not* use drm_* for syncing my kernel
> >> module code with vblank.
> >
> > E.g. you could just call drm_vblank_get() before you need vblank
> > interrupts to occur, drm_vblank_put() after you don't need them anymore
> > and handle the rest from the IRQ handler.
> 
> Thanks you! I'll try that today later.
> 
> Could you just explain what is drm_wait_vblank for? I expected it to
> sleep my process and wake it up interruptible on IRQ.

That much is correct.

> But I'm not sure that anymore. Also it expected drm_file parameter
> which AFAIK is never passed from gpu driver, but from drm to gpu
> driver.

As it is, it's intended for handling ioctl calls from userspace and as
such may make assumptions which weren't satisfied in the context you
tried using it from. It might be possible to factor out the core
(Continue reading)

Permalink | Reply | 1 comment |

Gmane