lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 14 Feb 2007 00:46:49 +0000 From: Ben Dooks <ben@...ff.org.uk> To: linux-fbdev-devel@...ts.sourceforge.net Cc: vince@....linux.org.uk, linux-kernel@...r.kernel.org, ben-linux@...ff.org Subject: Re: [Linux-fbdev-devel] [PATCH] fb: SM501 framebuffer driver On Tue, Feb 13, 2007 at 09:01:25PM +0000, James Simmons wrote: > > > Framebuffer support for the Silicon Motion SM501 > > multi-function chip. > > > > This driver provides a pair of framebuffer interfaces > > for the CRT and LCD panel interfaces, and some basic > > acceleration for the cursor. > > > > The patch has been updated slightly from the previous > > version to including being able to pass an initial > > video mode through via the platform data. > > > > Signed-off-by: Ben Dooks <ben-linux@...ff.org> > > Signed-off-by: Vincent Sanders <vince@....linux.org.uk> > > > + * > > + * Converts a period in picoseconds to Hz. > > + * > > + * Note, we try to keep this in Hz to minimise rounding with > > + * the limited PLL settings on the SM501. > > +*/ > > + > > +static unsigned long sm501fb_ps_to_hz(unsigned long psvalue) > > +{ > > + unsigned long long numerator=1000000000000ULL; > > + > > + /* 10^12 / picosecond period gives frequency in Hz */ > > + do_div(numerator, psvalue); > > + return (unsigned long)numerator; > > +} > > + > > +/* sm501fb_hz_to_ps is identical to the oposite transform */ > > + > > +#define sm501fb_hz_to_ps(x) sm501fb_ps_to_hz(x) > > You really need it down to the Hz? My feeling is that we lose enough with the rather fixed nature of the frequency selection that we should keep the calculations as accurate as possible. It isn't a big loss to have 64bit calcs as we don't change mode that often. > > +/* sm501fb_validate_pan > > + * > > + * check panning on a var > > +*/ > > + > > +static inline int sm501fb_validate_pan(struct fb_var_screeninfo *var) > > +{ > > + if (var->xoffset < 0 || var->yoffset < 0) > > + return 0; > > + > > + if (var->xoffset > (var->xres_virtual - var->xres) || > > + var->yoffset > (var->yres_virtual - var->yres)) > > + return 0; > > + > > + return 1; > > +} > > Not needed. fb_pan_display in fbmem.c does this check for you :-) Ok, will look at removing > > +/* framebuffer ops */ > > + > > +static struct fb_ops sm501fb_ops_crt = { > > + .owner = THIS_MODULE, > > + .fb_check_var = sm501fb_check_var_crt, > > + .fb_set_par = sm501fb_set_par_crt, > > + .fb_blank = sm501fb_blank_crt, > > + .fb_setcolreg = sm501fb_setcolreg, > > + .fb_pan_display = sm501fb_pan_crt, > > + .fb_cursor = sm501fb_cursor, > > + .fb_fillrect = cfb_fillrect, > > + .fb_copyarea = cfb_copyarea, > > + .fb_imageblit = cfb_imageblit, > > +}; > > + > > +static struct fb_ops sm501fb_ops_pnl = { > > + .owner = THIS_MODULE, > > + .fb_check_var = sm501fb_check_var_pnl, > > + .fb_set_par = sm501fb_set_par_pnl, > > + .fb_pan_display = sm501fb_pan_pnl, > > + .fb_blank = sm501fb_blank_pnl, > > + .fb_setcolreg = sm501fb_setcolreg, > > + .fb_cursor = sm501fb_cursor, > > + .fb_fillrect = cfb_fillrect, > > + .fb_copyarea = cfb_copyarea, > > + .fb_imageblit = cfb_imageblit, > > +}; > > Many cards require a fb_sync function after/before they do a drawing > operation. I notice you don't have one. Is sm501fb_sync_regs equivalent to > that? That, iirc, is only needed for acceleration functions that may change the fb data before any of the non-accelerated ops happen. Basically, it is for the card to hold off any non-accelerated drawing until the acceleration unit has finished. > Other than that the driver looks great. Thank you. I really hope we can get this merged this kernel release. -- Ben (ben@...ff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists