[PATCH] Resource management for fbdev.

[PATCH] Resource management for fbdev.

[James Simmons]

I have a new resource management for testing. Its is a clenaup of the 
handling the drawing plane and the cursor. I have tested it on 

New NVIDIA fbdev driver.
NeoMagic
ATY Mach64
Radeon
Vesa

Please try it out. The patch is over 40K so grab it from the below link

http://www.infradead.org/~jsimmons/resource.diff

Thank you.



-------------------------------------------------------
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: [PATCH] Resource management for fbdev.

[Benjamin Herrenschmidt]

On Sat, 2005-03-26 at 00:34 +0000, James Simmons wrote:
> I have a new resource management for testing. Its is a clenaup of the 
> handling the drawing plane and the cursor. I have tested it on 
> 
> New NVIDIA fbdev driver.
> NeoMagic
> ATY Mach64
> Radeon
> Vesa
> 
> Please try it out. The patch is over 40K so grab it from the below link
> 
> http://www.infradead.org/~jsimmons/resource.diff

I had a quick look, and I'm fairly confused. That patch introduces a lot
of changes all over the place without any comment or explanation, in
code that has proven in the past to be fragile and prone to side
effects. Also, I see no explanation of the rationale for the resource
manager and it's API. At a minimum, the patch should be split into

 - implementation of the resource manager with appropriate explanations
and documentation
 - driver updates

Have you worked at all with the DRM folks ? We have a bad need to merge
DRM and fbdev as soon as possible and we need while doing so to impement
some kind of efficient memory manager for the card video RAM. I'm not
sure your proposal fits into this picture.

Also, we need to properly deal with the fact that real soon now, not all
of the video memory will be accessible from the CPU (not only from the
kernel, but from the CPU in general). There are already cards whose PCI
aperture is too small to enclose the entire video memory, and some funky
issues with aperture control on radeons might make me also limit the
amount of video memory accessible.

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: [PATCH] Resource management for fbdev.

[Miles Lane]

Is this video memory issue related to the problem I reported with
nvidiafb requiring too much (128M) memory at boot time?  I have had to
set vmalloc=256M to get my machine to boot using nvidiafb.  I am
testing on a AMD Athlon machine.

Randy Dunlap wrote:
>I started looking at vmalloc() and what it calls (which is
> __get_vm_area).  _get_vm_area() always allocates one extra
> page (called a "guard page") between all vmalloc allocations,
> so even though 128 MB is the default amount and the amount
> that nvidiafb wants to use, the kernel wants to allocate
> 128 MB + PAGE_SIZE (4 KB on x86; are you on x86?), so even
> if nvidiafb is the only caller, the vmalloc() call will fail.

Booting with vmalloc=256M works, but Andrew Morton thinks that
nvidiafb should not be requiring 128M in the first place.

Thanks,
           Miles

On Apr 7, 2005 6:52 PM, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sat, 2005-03-26 at 00:34 +0000, James Simmons wrote:
> > I have a new resource management for testing. Its is a clenaup of the
> > handling the drawing plane and the cursor. I have tested it on
> >
> > New NVIDIA fbdev driver.
> > NeoMagic
> > ATY Mach64
> > Radeon
> > Vesa
> >
> > Please try it out. The patch is over 40K so grab it from the below link
> >
> > http://www.infradead.org/~jsimmons/resource.diff
> 
> I had a quick look, and I'm fairly confused. That patch introduces a lot
> of changes all over the place without any comment or explanation, in
> code that has proven in the past to be fragile and prone to side
> effects. Also, I see no explanation of the rationale for the resource
> manager and it's API. At a minimum, the patch should be split into
> 
>  - implementation of the resource manager with appropriate explanations
> and documentation
>  - driver updates
> 
> Have you worked at all with the DRM folks ? We have a bad need to merge
> DRM and fbdev as soon as possible and we need while doing so to impement
> some kind of efficient memory manager for the card video RAM. I'm not
> sure your proposal fits into this picture.
> 
> Also, we need to properly deal with the fact that real soon now, not all
> of the video memory will be accessible from the CPU (not only from the
> kernel, but from the CPU in general). There are already cards whose PCI
> aperture is too small to enclose the entire video memory, and some funky
> issues with aperture control on radeons might make me also limit the
> amount of video memory accessible.
> 
> 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-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: [PATCH] Resource management for fbdev.

[Geert Uytterhoeven]

On Fri, 8 Apr 2005, Benjamin Herrenschmidt wrote:
> Also, we need to properly deal with the fact that real soon now, not all
                                                    ^^^^^^^^^^^^^
> of the video memory will be accessible from the CPU (not only from the
> kernel, but from the CPU in general). There are already cards whose PCI
> aperture is too small to enclose the entire video memory, and some funky
> issues with aperture control on radeons might make me also limit the
> amount of video memory accessible.

Ah, finally the PC world is catching up? :-)

This has existed since ages, cfr. TMS34010 and '020 graphics on Amiga (e.g.
A2410 and DMI Resolver) and Tektronix X-terminals, and many SGI machines.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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: [PATCH] Resource management for fbdev.

[James Simmons]

> I had a quick look, and I'm fairly confused. That patch introduces a lot
> of changes all over the place without any comment or explanation, in
> code that has proven in the past to be fragile and prone to side
> effects. Also, I see no explanation of the rationale for the resource
> manager and it's API. At a minimum, the patch should be split into
> 
>  - implementation of the resource manager with appropriate explanations
> and documentation
>  - driver updates

I have no problem splitting the patch up into several parts. It was 
addressing several problems. Plus I was doing some cleanups. Currently 
we have sprite and pixmap for drawing images and the cursor. We also need
one for merging the font images for framebuffer console. I really didn't 
want to add another fb_pixmap to struct fb_info. I will send some stuff 
later. 

 
> Have you worked at all with the DRM folks ? We have a bad need to merge
> DRM and fbdev as soon as possible and we need while doing so to impement
> some kind of efficient memory manager for the card video RAM. I'm not
> sure your proposal fits into this picture.

No. I haven't heard anything on this mailing list. Also I'm preparing for 
a plug fest for work. So I will be gone for May 16-18. We have been 
working like mad getting ready for it.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20