Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
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ä [EMAIL PROTECTED] 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_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
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_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
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ä [EMAIL PROTECTED] 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_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
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ä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/
Re: waitforVBlank, how does this even work?
> > 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
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ä [EMAIL PROTECTED] 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_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
> > 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
> > 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
On Wed, 2005-03-02 at 17:29 +, 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
On Wed, 02 Mar 2005 21:19:14 +0100, Dag Bakke <[EMAIL PROTECTED]> wrote: > On Wed, 2 Mar 2005, Jon Smirl wrote: > > > On Wed, 2 Mar 2005 12:45:54 -0500 (EST), Vladimir Dergachev > > <[EMAIL PROTECTED]> wrote: > >> > >> > >> On Wed, 2 Mar 2005, Jon Smirl wrote: > >> > >>> On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev > >>> <[EMAIL PROTECTED]> 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 may possibly be way off here, but can the neomagic hack be a useful > (interim) model here? > > (from 'man neomagic') > >Option "OverlayMem" "integer" > Reserve the given amount of memory (in bytes) for the XVideo > overlay. On boards with limited memory, display of large XVideo > buffers might fail due to insufficient available memory. Using > this option solves the problem at the expense of reducing the > memory available for other operations. For full-resolution > DVDs, 829440 bytes (720x576x2) are necessary. > > Works for me. > > Dag B > > I believe this was more of a hack to get around the limitations of the old X memory manager. It only allowed you to use memory that was within the limits of the 2d engine. Alex --- 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
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005, Jon Smirl wrote: On Wed, 2 Mar 2005 12:45:54 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: On Wed, 2 Mar 2005, Jon Smirl wrote: On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> 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 may possibly be way off here, but can the neomagic hack be a useful (interim) model here? (from 'man neomagic') Option "OverlayMem" "integer" Reserve the given amount of memory (in bytes) for the XVideo overlay. On boards with limited memory, display of large XVideo buffers might fail due to insufficient available memory. Using this option solves the problem at the expense of reducing the memory available for other operations. For full-resolution DVDs, 829440 bytes (720x576x2) are necessary. Works for me. Dag B --- 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
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005, Jon Smirl wrote: On Wed, 2 Mar 2005 12:45:54 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: On Wed, 2 Mar 2005, Jon Smirl wrote: On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- 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
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005 13:08:23 -0500, Eric Sellers <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- 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
Re: waitforVBlank, how does this even work?
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 > > > > <[EMAIL PROTECTED]> 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005 12:45:54 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > > On Wed, 2 Mar 2005, Jon Smirl wrote: > > > On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev > > <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- 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
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005, Jon Smirl wrote: On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- 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
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
> 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005 12:15:18 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- 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
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005, Jon Smirl wrote: On Wed, 2 Mar 2005 11:32:44 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- 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
Re: waitforVBlank, how does this even work?
On Wed, 2 Mar 2005 11:32:44 -0500 (EST), Vladimir Dergachev <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --- 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
Re: waitforVBlank, how does this even work?
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 [EMAIL PROTECTED] --- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] waitforVBlank, how does this even work?
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_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
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 [EMAIL PROTECTED] --- 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
Re: [Linux-fbdev-devel] waitforVBlank, how does this even work?
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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] waitforVBlank, how does this even work?
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ä [EMAIL PROTECTED] 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_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
waitforVBlank, how does this even work?
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 [EMAIL PROTECTED] --- 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
