Re: [PATCH] matroxfb: New framebuffer_alloc API and class_d

Re: [PATCH] matroxfb: New framebuffer_alloc API and class_d

[Petr Vandrovec]

On 15 Sep 03 at 22:16, Kronos wrote:

> Hi,
> this patch converts driver/video/matrox to framebuffer_alloc. Now
> fb_info (and minfo) are dynamically allocated. This also voids the need 
> of a global matrox_fb_info if CONFIG_FB_MATROX_MULTIHEAD:
                             ^^^ if not defined

Whole point of CONFIG_FB_MATROX_MULTIHEAD is to use static structure
when MULTIHEAD is not set. It generates much faster driver for ia32 due
to smaller register pressure, as driver data can be addressed with fixed
address instructions. So if you are going to always allocate fbcon
dynamically, please also remove CONFIG_FB_MATROX_MULTIHEAD completely,
making it always enabled.

Besides that, what's the point of this change? Making driver slower, 
scattering its data over random memory places (so no cache locality...), 
or is there some benefit it brings in and which I missed?
                                        Thanks,
                                                Petr Vandrovec
                                                



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] matroxfb: New framebuffer_alloc API and class_dev

[Kronos]

Il Mon, Sep 15, 2003 at 10:24:29PM +0200, Petr Vandrovec ha scritto: 
> Besides that, what's the point of this change? Making driver slower, 
> scattering its data over random memory places (so no cache locality...), 
> or is there some benefit it brings in and which I missed?

There is  a class_dev  embedded in struct  fb_info, framebuffer_register
registers  it with  the driver  model. In  this way  drivers can  export
whatever  they  want using  sysfs. A  dynamically  allocated fb_info  is
needed  because the  release function  calls kfree  on the  container of
class_dev  and  can't  tell  weather  a  struct  fb_info  is  statically
allocated or not.

I  see your  point  though. Note that  framebuffer_alloc  uses a  single
kmalloc call for  fb_info and fb_info->par and they are  both aligned to
sizeof(long)... I'm  not  really  scattering data  "over  random  memory
places".

Of course I didn't want to screw your driver :)

Luca
-- 
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
La somma dell'intelligenza sulla terra e` una costante.
La popolazione e` in aumento.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf