waitforVBlank, how does this even work?

waitforVBlank, how does this even work?

[Jon Smirl]

For the r128 driver both the fbdev and drm drivers have implemented
waitforVBlank and they both play with the interrupt registers. I can
only assume that no one has ever tried to use them at the same time.
In the radeon case the DRM driver has implemented waitforVBlank and
the fbdev driver has not.

This is a mess and it is yet another reason for merging DRM and fbdev
into a sane, combined driver.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Jon Smirl]

Ok I see now how it works. The fbdev support is only on the Rage not
the Rage128. But this is really confusing trying to track down who is
actually controlling the interrupts.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

On Wed, 2005-03-02 at 00:50 -0500, Jon Smirl wrote:
> For the r128 driver both the fbdev and drm drivers have implemented
> waitforVBlank and they both play with the interrupt registers. I can
> only assume that no one has ever tried to use them at the same time.
> In the radeon case the DRM driver has implemented waitforVBlank and
> the fbdev driver has not.
> 
> This is a mess and it is yet another reason for merging DRM and fbdev
> into a sane, combined driver.

I'd say nobody ever used both :)

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [Linux-fbdev-devel] waitforVBlank, how does this even work?

[Ville Syrjälä]

On Wed, Mar 02, 2005 at 06:10:14PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-02 at 00:50 -0500, Jon Smirl wrote:
> > For the r128 driver both the fbdev and drm drivers have implemented
> > waitforVBlank and they both play with the interrupt registers. I can
> > only assume that no one has ever tried to use them at the same time.
> > In the radeon case the DRM driver has implemented waitforVBlank and
> > the fbdev driver has not.
> > 
> > This is a mess and it is yet another reason for merging DRM and fbdev
> > into a sane, combined driver.
> 
> I'd say nobody ever used both :)

I (and others) have with mga. The easiest solution was to disable the irq 
code in the drm. That was for running OpenGL on DirectFB btw.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
--

Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

On Wed, 2005-03-02 at 09:30 +0200, Ville Syrjälä wrote:
> On Wed, Mar 02, 2005 at 06:10:14PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-03-02 at 00:50 -0500, Jon Smirl wrote:
> > > For the r128 driver both the fbdev and drm drivers have implemented
> > > waitforVBlank and they both play with the interrupt registers. I can
> > > only assume that no one has ever tried to use them at the same time.
> > > In the radeon case the DRM driver has implemented waitforVBlank and
> > > the fbdev driver has not.
> > > 
> > > This is a mess and it is yet another reason for merging DRM and fbdev
> > > into a sane, combined driver.
> > 
> > I'd say nobody ever used both :)
> 
> I (and others) have with mga. The easiest solution was to disable the irq 
> code in the drm. That was for running OpenGL on DirectFB btw.

I'd rather have disabled the IRQ code in the fbdev and added a
waitForVBlank in the DRM ...

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: waitforVBlank, how does this even work?

[Torgeir Veimo]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Wed, 2005-03-02 at 18:53 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-02 at 09:30 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 02, 2005 at 06:10:14PM +1100, Benjamin Herrenschmidt wrote:
> > > On Wed, 2005-03-02 at 00:50 -0500, Jon Smirl wrote:
> > > > For the r128 driver both the fbdev and drm drivers have implemented
> > > > waitforVBlank and they both play with the interrupt registers. I can
> > > > only assume that no one has ever tried to use them at the same time.
> > > > In the radeon case the DRM driver has implemented waitforVBlank and
> > > > the fbdev driver has not.
> > > > 
> > > > This is a mess and it is yet another reason for merging DRM and fbdev
> > > > into a sane, combined driver.
> > > 
> > > I'd say nobody ever used both :)
> > 
> > I (and others) have with mga. The easiest solution was to disable the irq 
> > code in the drm. That was for running OpenGL on DirectFB btw.
> 
> I'd rather have disabled the IRQ code in the fbdev and added a
> waitForVBlank in the DRM ...

That doesn't help when you need it for a DirectFB application..

I've been trying to implement wait-for-vsync irq support in the radeonfb
driver, using the patch for the mga and the code in the dri driver as a
base, but am having some basic problems actually getting request_irq to
succeed. My test setup is a radeon QD, and the bios assigns it an
interrupt. I dont have the dri driver loaded.

Maybe someone with a little more kernel experience can help me spot the
problem. Attached is a patch against kernel 2.6.11.


-- 
Torgeir Veimo <torgeir@pobox.com>

[-- Attachment #2: radeon-irq.patch --]
[-- Type: text/x-patch, Size: 6913 bytes --]

--- linux-2.6.11-orig/drivers/video/aty/radeon_base.c	2005-03-02 13:25:16.000000000 +0000
+++ linux-2.6.11/drivers/video/aty/radeon_base.c	2005-03-02 12:13:13.000000000 +0000
@@ -68,6 +68,9 @@
 #include <linux/ioport.h>
 #include <linux/init.h>
 #include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/wait.h>
 #include <linux/vmalloc.h>
 #include <linux/device.h>
 #include <linux/i2c.h>
@@ -863,6 +885,108 @@
 }
 
 
+static irqreturn_t radeon_irq(int irq, void *dev_id, struct pt_regs *fp)
+{
+	struct radeonfb_info *rinfo = dev_id;
+	int handled = 0;
+	u32 int_cntl;
+
+	spin_lock(&rinfo->int_lock);
+
+        int_cntl = INREG(GEN_INT_CNTL);
+
+	if (int_cntl & CRTC_VBLANK_MASK) {
+		/* clear interrupt */
+                OUTREG(GEN_INT_CNTL, (int_cntl & CRTC_VBLANK_STAT_ACK) | CRTC_VBLANK_STAT_ACK);
+		rinfo->vblank.count++;
+		wake_up_interruptible(&rinfo->vblank.wait);
+		handled = 1;
+	}
+
+	spin_unlock(&rinfo->int_lock);
+
+	return IRQ_RETVAL(handled);
+}
+
+static int radeon_enable_irq(struct radeonfb_info *rinfo, int reenable)
+{
+	u32 int_cntl;
+
+	if (!test_and_set_bit(0, &rinfo->irq_flags)) {
+		if (request_irq(rinfo->irq, radeon_irq, SA_SHIRQ, "radeonfb", rinfo)) {
+			printk("radeonfb: request_irq failed..\n");
+			clear_bit(0, &rinfo->irq_flags);
+			return -EINVAL;
+		}
+		spin_lock_irq(&rinfo->int_lock);
+                int_cntl = INREG(GEN_INT_CNTL) & CRTC_INT_EN_MASK;
+		/* clear interrupt */
+                OUTREG(GEN_INT_CNTL, int_cntl | CRTC_VBLANK_STAT_ACK);
+		/* enable interrupt */
+                OUTREG(GEN_INT_CNTL, int_cntl | CRTC_VBLANK_INT_EN);
+		spin_unlock_irq(&rinfo->int_lock);
+		printk("radeonfb: enabled IRQ\n");
+	} else if (reenable) {
+		spin_lock_irq(&rinfo->int_lock);
+                int_cntl = INREG(GEN_INT_CNTL) & CRTC_INT_EN_MASK;
+		if (!(int_cntl & CRTC_VBLANK_INT_EN)) {
+			printk("radeonfb: someone disabled IRQ [%08x]\n", int_cntl);
+			/* re-enable interrupt */
+                        OUTREG(GEN_INT_CNTL, int_cntl | CRTC_VBLANK_INT_EN);
+		}
+		spin_unlock_irq(&rinfo->int_lock);
+	}
+
+	return 0;
+}
+
+static int radeon_disable_irq(struct radeonfb_info *rinfo)
+{
+	u32 int_cntl;
+
+	if (test_and_clear_bit(0, &rinfo->irq_flags)) {
+		spin_lock_irq(&rinfo->int_lock);
+                                
+                int_cntl = INREG(GEN_INT_CNTL) & CRTC_INT_EN_MASK;
+		/* disable interrupt */
+                OUTREG(GEN_INT_CNTL, int_cntl & ~CRTC_VBLANK_INT_EN);
+		spin_unlock_irq(&rinfo->int_lock);
+		free_irq(rinfo->irq, rinfo);
+		printk("radeonfb: disabled IRQ\n");
+	}
+
+	return 0;
+}
+
+static int radeon_waitforvblank(struct radeonfb_info *rinfo)
+{
+	struct radeon_interrupt *vbl;
+	unsigned int count;
+	int ret;
+
+        vbl = &rinfo->vblank;
+
+	ret = radeon_enable_irq(rinfo, 0);
+	if (ret)
+		return ret;
+
+	count = vbl->count;
+	ret = wait_event_interruptible_timeout(vbl->wait, count != vbl->count, HZ/10);
+	if (ret < 0) {
+		return ret;
+	}
+	if (ret == 0) {
+		radeon_enable_irq(rinfo, 1);
+		return -ETIMEDOUT;
+	}
+
+	return 0;
+}
+
+#ifndef FBIO_WAITFORVSYNC
+#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
+#endif
+
 static int radeonfb_ioctl (struct inode *inode, struct file *file, unsigned int cmd,
                            unsigned long arg, struct fb_info *info)
 {
@@ -927,6 +1051,11 @@
 				value |= 0x02;
 
 			return put_user(value, (__u32 __user *)arg);
+		case FBIO_WAITFORVSYNC:
+			printk("radeonfb: waitforvblank..\n");
+			return radeon_waitforvblank(rinfo);
+			//return 0;
+                        
 		default:
 			return -EINVAL;
 	}
@@ -1464,6 +1593,30 @@
 	RTRACE("ppll_div_3 = 0x%x\n", regs->ppll_div_3);
 }
 
+static int radeonfb_open(struct fb_info *info, int user)
+{
+      struct radeonfb_info *rinfo = (struct radeonfb_info *) info->par;
+      if (user) {
+              rinfo->open++;
+      }
+      return (0);
+}
+
+static int radeonfb_release(struct fb_info *info, int user)
+{
+      struct radeonfb_info *rinfo = (struct radeonfb_info *) info->par;
+      if (user) {
+              rinfo->open--;
+              mdelay(1);
+              //wait_for_idle(rinfo);
+              if (!rinfo->open) {
+                      radeon_disable_irq(rinfo);
+              }
+      }
+      return (0);
+}
+
+
 static int radeonfb_set_par(struct fb_info *info)
 {
 	struct radeonfb_info *rinfo = info->par;
@@ -1788,6 +1941,8 @@
 
 static struct fb_ops radeonfb_ops = {
 	.owner			= THIS_MODULE,
+        .fb_open	        = radeonfb_open,
+	.fb_release	        = radeonfb_release,        
 	.fb_check_var		= radeonfb_check_var,
 	.fb_set_par		= radeonfb_set_par,
 	.fb_setcolreg		= radeonfb_setcolreg,
@@ -2338,6 +2494,8 @@
 	radeon_create_i2c_busses(rinfo);
 #endif
 
+	rinfo->irq_flags = 0;
+
 	/* set all the vital stuff */
 	radeon_set_fbinfo (rinfo);
 
--- linux-2.6.11-orig/drivers/video/aty/radeonfb.h	2005-03-02 13:25:16.000000000 +0000
+++ linux-2.6.11/drivers/video/aty/radeonfb.h	2005-02-26 23:17:18.000000000 +0000
@@ -269,6 +269,11 @@
 	radeon_pm_off	= 0x00000002,	/* Can resume from D3 cold */
 };
 
+struct radeon_interrupt {
+	wait_queue_head_t wait;
+	unsigned int count;
+};
+
 struct radeonfb_info {
 	struct fb_info		*info;
 
@@ -344,6 +349,12 @@
 	struct timer_list	lvds_timer;
 	u32			pending_lvds_gen_cntl;
 
+	int			open;
+	struct radeon_interrupt	vblank;
+	unsigned long		irq_flags;
+	unsigned int		irq;
+	spinlock_t		int_lock;
+
 #ifdef CONFIG_FB_RADEON_I2C
 	struct radeon_i2c_chan 	i2c[4];
 #endif
--- linux-2.6.11-orig/include/video/radeon.h	2005-03-02 07:38:33.000000000 +0000
+++ linux-2.6.11/include/video/radeon.h	2005-02-26 23:22:56.000000000 +0000
@@ -541,6 +541,34 @@
 #define CRTC_EN					   (1 << 25)
 #define CRTC_DISP_REQ_EN_B                         (1 << 26)
 
+#define GEN_INT_CNTL                           0x0040
+#define GEN_INT_STATUS                         0x0044
+
+/* GEN_INT_CNTL bit constants */
+#define CRTC_VBLANK_MASK          (1 << 0)
+#define CRTC_VBLANK_INT_EN        (1 << 0)
+#define FP_DETECT_ENABLE          (1 << 4)
+#define FP2_DETECT_ENABLE         (1 << 10)
+#define GUI_IDLE_INT_ENABLE       (1 << 19)
+#define SW_INT_ENABLE             (1 << 25)
+
+/* GEN_INT_STATUS bit constants */
+#define CRTC_VBLANK_STAT          (1 << 0)
+#define CRTC_VBLANK_STAT_ACK      (1 << 0)
+#define FP_DETECT_STAT            (1 << 4)
+#define FP_DETECT_ACK             (1 << 4)
+#define FP2_DETECT_STAT           (1 << 10)
+#define FP2_DETECT_ACK            (1 << 10)
+#define GUI_IDLE_INT_TEST_ACK     (1 << 19)
+#define SW_INT_TEST               (1 << 25)
+#define SW_INT_TEST_ACK           (1 << 25)
+
+#define CRTC_INT_EN_MASK       (CRTC_VBLANK_MASK |     \
+				FP_DETECT_ENABLE |     \
+				FP2_DETECT_ENABLE |    \
+				GUI_IDLE_INT_ENABLE |  \
+				SW_INT_ENABLE)
+
 /* CRTC_STATUS bit constants */
 #define CRTC_VBLANK                                0x00000001
 

Re: waitforVBlank, how does this even work?

[Vladimir Dergachev]

On Wed, 2 Mar 2005, Jon Smirl wrote:

> For the r128 driver both the fbdev and drm drivers have implemented
> waitforVBlank and they both play with the interrupt registers. I can
> only assume that no one has ever tried to use them at the same time.
> In the radeon case the DRM driver has implemented waitforVBlank and
> the fbdev driver has not.
>
> This is a mess and it is yet another reason for merging DRM and fbdev
> into a sane, combined driver.

Hi Jon,

    What about isolating interrupt-handling code into a small driver ?
Something simple to respond to interrupts and call all handlers with a 
certain mask.

    This would be useful not only for drm and fbdev but also for km 
(v4l capture module) and stereo-glasses code.

                         best

                           Vladimir Dergachev

>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Jon Smirl]

On Wed, 2 Mar 2005 11:32:44 -0500 (EST), Vladimir Dergachev
<volodya@mindspring.com> wrote:
>     What about isolating interrupt-handling code into a small driver ?
> Something simple to respond to interrupts and call all handlers with a
> certain mask.

My current plan is that fbdev is the base driver and I will modify the
other drivers to bind to it. It is possible to split about 50K out of
the fbdev driver into another module and make a smaller base driver
but I'm not working on size isssues. Right now all I want to do is get
a combined fbdev/DRM on the radeon with enough features to support
mesa-solo. XGL needs most of both DRM and fbdev features. After that I
have to spend a bunch of time getting it into Linus' tree.

I would find it useful if someone came up with a standard kernel space
V4L radeon driver instead of the Gatos stuff.


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Vladimir Dergachev]

On Wed, 2 Mar 2005, Jon Smirl wrote:

> On Wed, 2 Mar 2005 11:32:44 -0500 (EST), Vladimir Dergachev
> <volodya@mindspring.com> wrote:
>>     What about isolating interrupt-handling code into a small driver ?
>> Something simple to respond to interrupts and call all handlers with a
>> certain mask.
>
> My current plan is that fbdev is the base driver and I will modify the
> other drivers to bind to it. It is possible to split about 50K out of
> the fbdev driver into another module and make a smaller base driver
> but I'm not working on size isssues. Right now all I want to do is get
> a combined fbdev/DRM on the radeon with enough features to support
> mesa-solo. XGL needs most of both DRM and fbdev features. After that I
> have to spend a bunch of time getting it into Linus' tree.

I see..

>
> I would find it useful if someone came up with a standard kernel space
> V4L radeon driver instead of the Gatos stuff.

By "standard" you mean "self-contained", right ?

While there have been a number of attempts, I don't think a full-featured 
v4l module will appear before video memory allocation functions are 
accessible from kernel space.

                       best

                          Vladimir Dergachev

>
>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Jon Smirl]

On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> > I would find it useful if someone came up with a standard kernel space
> > V4L radeon driver instead of the Gatos stuff.
> 
> By "standard" you mean "self-contained", right ?

One that doesn't depend on X being there.

Can one be build now that just ignores the memory management hooks?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: waitforVBlank, how does this even work?

[Vladimir Dergachev]

On Wed, 2 Mar 2005, Jon Smirl wrote:

> On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev
> <volodya@mindspring.com> wrote:
>>> I would find it useful if someone came up with a standard kernel space
>>> V4L radeon driver instead of the Gatos stuff.
>>
>> By "standard" you mean "self-contained", right ?
>
> One that doesn't depend on X being there.
>
> Can one be build now that just ignores the memory management hooks?

Sure, but you would have to give up using X on that card.

In fact, Eric Sellers has already written such a module that provides V4L 
1 and 2 support (Eric, please correct me if I got anything wrong..)

                 best

                     Vladimir Dergachev

>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Jon Smirl]

On Wed, 2 Mar 2005 12:45:54 -0500 (EST), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> 
> 
> On Wed, 2 Mar 2005, Jon Smirl wrote:
> 
> > On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev
> > <volodya@mindspring.com> wrote:
> >>> I would find it useful if someone came up with a standard kernel space
> >>> V4L radeon driver instead of the Gatos stuff.
> >>
> >> By "standard" you mean "self-contained", right ?
> >
> > One that doesn't depend on X being there.
> >
> > Can one be build now that just ignores the memory management hooks?
> 
> Sure, but you would have to give up using X on that card.

Is memory management the only reason you need to give up on X?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Vladimir Dergachev]

On Wed, 2 Mar 2005, Jon Smirl wrote:

> On Wed, 2 Mar 2005 12:45:54 -0500 (EST), Vladimir Dergachev
> <volodya@mindspring.com> wrote:
>>
>>
>> On Wed, 2 Mar 2005, Jon Smirl wrote:
>>
>>> On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev
>>> <volodya@mindspring.com> wrote:
>>>>> I would find it useful if someone came up with a standard kernel space
>>>>> V4L radeon driver instead of the Gatos stuff.
>>>>
>>>> By "standard" you mean "self-contained", right ?
>>>
>>> One that doesn't depend on X being there.
>>>
>>> Can one be build now that just ignores the memory management hooks?
>>
>> Sure, but you would have to give up using X on that card.
>
> Is memory management the only reason you need to give up on X?

I think so..

                 best

                     Vladimir Dergachev

>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Eric Sellers]

On Wednesday 02 March 2005 12:45, Vladimir Dergachev wrote:
> On Wed, 2 Mar 2005, Jon Smirl wrote:
> > On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev
> >
> > <volodya@mindspring.com> wrote:
> >>> I would find it useful if someone came up with a standard kernel space
> >>> V4L radeon driver instead of the Gatos stuff.
> >>
> >> By "standard" you mean "self-contained", right ?
> >
> > One that doesn't depend on X being there.
> >
> > Can one be build now that just ignores the memory management hooks?
>
> Sure, but you would have to give up using X on that card.
>
> In fact, Eric Sellers has already written such a module that provides V4L
> 1 and 2 support (Eric, please correct me if I got anything wrong..)

You can use my module with or without X 
(right now it only supports the older mach64 cards)

The only problem is there is no way of telling X where 
the capture buffers are. So you might get some corruption on screen when X 
uses that memory and it gets overwritten by a frame and then copied back.

The more memory you have the less you will notice this.
(so if you have a 4 meg card, you might want to keep your resolution and bit 
depth down)

If there was a userspace program that could allocate the end of video memory 
there would be no problem.

Eric


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Jon Smirl]

On Wed, 2 Mar 2005 13:08:23 -0500, Eric Sellers <sellers-eric@rogers.com> wrote:
> You can use my module with or without X
> (right now it only supports the older mach64 cards)
> 
> The only problem is there is no way of telling X where
> the capture buffers are. So you might get some corruption on screen when X
> uses that memory and it gets overwritten by a frame and then copied back.
> 
> The more memory you have the less you will notice this.
> (so if you have a 4 meg card, you might want to keep your resolution and bit
> depth down)
> 
> If there was a userspace program that could allocate the end of video memory
> there would be no problem.

I'm working on the radeon fbdev and DRM drivers currently. I can fix
the memory management for V4L if there is a radeon driver available.


> 
> Eric
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: waitforVBlank, how does this even work?

[James Simmons]

> Hi Jon,
> 
>     What about isolating interrupt-handling code into a small driver ?
> Something simple to respond to interrupts and call all handlers with a 
> certain mask.
> 
>     This would be useful not only for drm and fbdev but also for km 
> (v4l capture module) and stereo-glasses code.

Ultimatly this is the goal. That is what the struct xxx_par is for in 
struct fb_info. It is the core driver private data that can be shared by 
everyone. Ben would you mind if I reworked your code to have this "core".
It will take me some time but I can have it working. I need to do some 
fixes for multiple monitor handling anyways.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

On Wed, 2005-03-02 at 17:29 +0000, James Simmons wrote:
> > Hi Jon,
> > 
> >     What about isolating interrupt-handling code into a small driver ?
> > Something simple to respond to interrupts and call all handlers with a 
> > certain mask.
> > 
> >     This would be useful not only for drm and fbdev but also for km 
> > (v4l capture module) and stereo-glasses code.
> 
> Ultimatly this is the goal. That is what the struct xxx_par is for in 
> struct fb_info. It is the core driver private data that can be shared by 
> everyone. Ben would you mind if I reworked your code to have this "core".
> It will take me some time but I can have it working. I need to do some 
> fixes for multiple monitor handling anyways.

Wait, wait ... there is already Jon working on the driver, and I plan to
include part of his recent work along with some initial dual head
support soon, let's avoid having too many people working at the same
time on it.

Also, with the merge DRM/fbdev, this will become a non-issue, wether the
ioctl comes from DRM or fbdev, we'll be able to do the right thing.

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: waitforVBlank, how does this even work?

[James Simmons]

> > Ultimatly this is the goal. That is what the struct xxx_par is for in 
> > struct fb_info. It is the core driver private data that can be shared by 
> > everyone. Ben would you mind if I reworked your code to have this "core".
> > It will take me some time but I can have it working. I need to do some 
> > fixes for multiple monitor handling anyways.
> 
> Wait, wait ... there is already Jon working on the driver, and I plan to
> include part of his recent work along with some initial dual head
> support soon, let's avoid having too many people working at the same
> time on it.

I have seen his patches. He post them:-) The way it is being done is not 
according to the fbev api spec. I like to see it done right. Alot of 
drivers never where ported properly to the new api. People ported as fast 
as they could instead of properly. 
 
> Also, with the merge DRM/fbdev, this will become a non-issue, wether the
> ioctl comes from DRM or fbdev, we'll be able to do the right thing.

Ture but that is down the road. The idea is to share the par between the 
two different systems. 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

> 
>     What about isolating interrupt-handling code into a small driver ?
> Something simple to respond to interrupts and call all handlers with a 
> certain mask.
> 
>     This would be useful not only for drm and fbdev but also for km 
> (v4l capture module) and stereo-glasses code.
> 

Nope, I don't agree.

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: waitforVBlank, how does this even work?

[Vladimir Dergachev]

On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote:

>
>>
>>     What about isolating interrupt-handling code into a small driver ?
>> Something simple to respond to interrupts and call all handlers with a
>> certain mask.
>>
>>     This would be useful not only for drm and fbdev but also for km
>> (v4l capture module) and stereo-glasses code.
>>
>
> Nope, I don't agree.

With which part ? ;)

                  Vladimir Dergachev

>
> Ben.
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

On Wed, 2005-03-02 at 20:03 -0500, Vladimir Dergachev wrote:
> 
> On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote:
> 
> >
> >>
> >>     What about isolating interrupt-handling code into a small driver ?
> >> Something simple to respond to interrupts and call all handlers with a
> >> certain mask.
> >>
> >>     This would be useful not only for drm and fbdev but also for km
> >> (v4l capture module) and stereo-glasses code.
> >>
> >
> > Nope, I don't agree.
> 
> With which part ? ;)

On having a small stub module that does just IRQs ... I think the base
module should be the fbdev (mode setting etc...)

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: waitforVBlank, how does this even work?

[Vladimir Dergachev]

On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote:

> On Wed, 2005-03-02 at 20:03 -0500, Vladimir Dergachev wrote:
>>
>> On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote:
>>
>>>
>>>>
>>>>     What about isolating interrupt-handling code into a small driver ?
>>>> Something simple to respond to interrupts and call all handlers with a
>>>> certain mask.
>>>>
>>>>     This would be useful not only for drm and fbdev but also for km
>>>> (v4l capture module) and stereo-glasses code.
>>>>
>>>
>>> Nope, I don't agree.
>>
>> With which part ? ;)
>
> On having a small stub module that does just IRQs ... I think the base
> module should be the fbdev (mode setting etc...)

Oh, but I was not suggesting that. I just meant that interrupt handling 
code is self-contained and can easily serve several consumers.

Which driver claims the pci id I don't care about..

                    best

                      Vladimir Dergachev

>
> Ben.
>
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Ville Syrjälä]

On Wed, Mar 02, 2005 at 10:01:00PM -0500, Vladimir Dergachev wrote:
> 
> 
> On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote:
> 
> >On Wed, 2005-03-02 at 20:03 -0500, Vladimir Dergachev wrote:
> >>
> >>On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote:
> >>
> >>>
> >>>>
> >>>>    What about isolating interrupt-handling code into a small driver ?
> >>>>Something simple to respond to interrupts and call all handlers with a
> >>>>certain mask.
> >>>>
> >>>>    This would be useful not only for drm and fbdev but also for km
> >>>>(v4l capture module) and stereo-glasses code.
> >>>>
> >>>
> >>>Nope, I don't agree.
> >>
> >>With which part ? ;)
> >
> >On having a small stub module that does just IRQs ... I think the base
> >module should be the fbdev (mode setting etc...)
> 
> Oh, but I was not suggesting that. I just meant that interrupt handling 
> code is self-contained and can easily serve several consumers.

I'm with you here. And the same should IMHO hold for DMA handling. And for 
memory management of course.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
--

Re: waitforVBlank, how does this even work?

[Vladimir Dergachev]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 659 bytes --]

>>>> With which part ? ;)
>>>
>>> On having a small stub module that does just IRQs ... I think the base
>>> module should be the fbdev (mode setting etc...)
>>
>> Oh, but I was not suggesting that. I just meant that interrupt handling
>> code is self-contained and can easily serve several consumers.
>
> I'm with you here. And the same should IMHO hold for DMA handling. And for
> memory management of course.

With one refinement - the DMA code would need to be a customer of IRQ 
code..

                      best

                        Vladimir Dergachev

>
> -- 
> Ville Syrjälä
> syrjala@sci.fi
> http://www.sci.fi/~syrjala/
>

Re: Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

On Thu, 2005-03-03 at 10:12 -0500, Vladimir Dergachev wrote:
> >>>> With which part ? ;)
> >>>
> >>> On having a small stub module that does just IRQs ... I think the base
> >>> module should be the fbdev (mode setting etc...)
> >>
> >> Oh, but I was not suggesting that. I just meant that interrupt handling
> >> code is self-contained and can easily serve several consumers.
> >
> > I'm with you here. And the same should IMHO hold for DMA handling. And for
> > memory management of course.
> 
> With one refinement - the DMA code would need to be a customer of IRQ 
> code..

No, again, DMA is what DRM is for, or you want to re-invent the whole
architecture ?

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

> > Oh, but I was not suggesting that. I just meant that interrupt handling 
> > code is self-contained and can easily serve several consumers.
> 
> I'm with you here. And the same should IMHO hold for DMA handling. And for 
> memory management of course.

DMA handling is the main piece of what the DRM does, memory management
is the missing part.

No, what we really need is just what we said: merging fbdev & DRM and
adding memory management.

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--

Re: waitforVBlank, how does this even work?

[Ville Syrjälä]

On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrote:
> 
> > > Oh, but I was not suggesting that. I just meant that interrupt handling 
> > > code is self-contained and can easily serve several consumers.
> > 
> > I'm with you here. And the same should IMHO hold for DMA handling. And for 
> > memory management of course.
> 
> DMA handling is the main piece of what the DRM does,

The actual bits that feed DMA buffers to the hardware are very small. And 
I just meant that like the IRQ code those need to be easily accessible 
from other components (fbdev, video capture module etc.)

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Re: waitforVBlank, how does this even work?

[Benjamin Herrenschmidt]

On Fri, 2005-03-04 at 15:18 +0200, Ville Syrjälä wrote:
> On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrote:
> > 
> > > > Oh, but I was not suggesting that. I just meant that interrupt handling 
> > > > code is self-contained and can easily serve several consumers.
> > > 
> > > I'm with you here. And the same should IMHO hold for DMA handling. And for 
> > > memory management of course.
> > 
> > DMA handling is the main piece of what the DRM does,
> 
> The actual bits that feed DMA buffers to the hardware are very small. And 
> I just meant that like the IRQ code those need to be easily accessible 
> from other components (fbdev, video capture module etc.)

"Feeding DMA buffers" in what sense ? The buffers are matches with
various functions. For AGP buffers, you have to get into the whole
allocation mecanism, pure PCI DMA isn't always possible on some hosts.

Also, those buffers are what ? Data for blits ? textures ? they always
belong to some sort of command, which we want to eventually validate in
a way by the kernel unless you want your client to be root...

No, honestly, I don't see the point in breaking up our current DRM/fbdev
thing.

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Re: waitforVBlank, how does this even work?

[Ville Syrjälä]

On Sat, Mar 05, 2005 at 09:35:00AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2005-03-04 at 15:18 +0200, Ville Syrjälä wrote:
> > On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrote:
> > > 
> > > > > Oh, but I was not suggesting that. I just meant that interrupt handling 
> > > > > code is self-contained and can easily serve several consumers.
> > > > 
> > > > I'm with you here. And the same should IMHO hold for DMA handling. And for 
> > > > memory management of course.
> > > 
> > > DMA handling is the main piece of what the DRM does,
> > 
> > The actual bits that feed DMA buffers to the hardware are very small. And 
> > I just meant that like the IRQ code those need to be easily accessible 
> > from other components (fbdev, video capture module etc.)
> 
> "Feeding DMA buffers" in what sense ? The buffers are matches with
> various functions. For AGP buffers, you have to get into the whole
> allocation mecanism, pure PCI DMA isn't always possible on some hosts.

Allocating buffers should IMO belong to the memory management part.

If DMA isn't possible then I suppose the comammands/data would have to fed 
via MMIO. But that is a detail only the DMA component would have to know.

> Also, those buffers are what ? Data for blits ? textures ? they always
> belong to some sort of command, which we want to eventually validate in
> a way by the kernel unless you want your client to be root...

Usually the buffers are series of commands. And they don't need to 
validated when they come from the kernel. Validating buffers from 
userspace is done by the DRM.

> No, honestly, I don't see the point in breaking up our current DRM/fbdev
> thing.

From the userspace perspective nothing should change.


For the memory management I have some rough ideas but I'm not an expert 
here so let me know if I'm talking out of my ass...

The GART (be it AGP, PCI or some other mechanism) should be only used by 
the memory management part to dynamically map required bits of system RAM 
for the graphics hardware to access. Clients of the memory management 
system should only have to ask thing like "give me a buffer of size x with 
priority y". Those buffers could then exist in system or video memory and 
the memory manager could actaully dynamically move them around without the 
clients even knowing about it. At one point the buffer could be in video 
memory and in system memory the next. If the hardware can render to system 
RAM then it could be totally transparent to the user. With hardware that 
can't render to system RAM I suppose the best idea would be to always move 
the buffers to system RAM when software access is required. That way the 
software could lock the buffer for any period of time without disturbing 
the memory managers work.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click