Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: Sascha Hauer <s.hauer@pengutronix.de>, adaplas@pol.net
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/2]Freescale i.MX framebuffer driver
Date: Fri, 18 Mar 2005 22:14:30 +0800	[thread overview]
Message-ID: <200503182214.30492.adaplas@hotpop.com> (raw)
In-Reply-To: <20050318113912.GA18354@metis.extern.pengutronix.de>

On Friday 18 March 2005 19:39, Sascha Hauer wrote:

[snip]

> +static int
> +imxfb_setpalettereg(u_int regno, u_int red, u_int green, u_int blue,
> +		       u_int trans, struct fb_info *info)
> +{
> +	struct imxfb_info *fbi = (struct imxfb_info *)info;

Use struct imxfb_info *fbi = info->par;

[snip]

> +
> +	pr_debug("var->bits_per_pixel=%d\n", var->bits_per_pixel);
> +	switch (var->bits_per_pixel) {
> +	case 16:
> +		rgbidx = RGB_16;
> +		break;
> +	case 8:
> +		rgbidx = RGB_8;
> +		break;
> +	default:
> +		return -EINVAL;

Don't trust users.  Might as well round off var->bits_per_pixel to
8 or 16 instead of failing.

[snip]

> +/*
> + * imxfb_blank():
> + *	Blank the display by setting all palette values to zero.  Note, the
> + * 	12 and 16 bpp modes don't really use the palette, so this will not
> + *      blank the display in all modes.
> + */
> +static int imxfb_blank(int blank, struct fb_info *info)
> +{
> +	struct imxfb_info *fbi = info->par;
> +	int i;
> +
> +	pr_debug("imxfb_blank: blank=%d\n", blank);
> +
> +	switch (blank) {
> +	case VESA_POWERDOWN:
> +	case VESA_VSYNC_SUSPEND:
> +	case VESA_HSYNC_SUSPEND:
> +		if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> +		    info->fix.visual == FB_VISUAL_STATIC_PSEUDOCOLOR)
> +			for (i = 0; i < fbi->palette_size; i++)
> +				imxfb_setpalettereg(i, 0, 0, 0, 0, info);
> +		imxfb_disable_controller(fbi);
> +		break;
> +
> +	case VESA_NO_BLANKING:
> +		if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> +		    info->fix.visual == FB_VISUAL_STATIC_PSEUDOCOLOR)
> +			fb_set_cmap(&info->cmap, info);
> +		imxfb_enable_controller(fbi);
> +	}

Use FB_BLANK_* constants instead of VESA_*.  They are interpreted
differently by fbcon.

[snip]

> +
> +	strcpy(info->fix.id, IMX_NAME);

strncpy may be safer, just in case you decide to use a longer string.
fix->id is only 16 bytes long.

I don't care which one you want.

[snip]

> +	if(!inf) {
> +		dev_err(dev,"No platform_data available\n");
> +		return -ENOMEM;
> +	}
> +
> +	info = framebuffer_alloc(sizeof(struct imxfb_info), dev);

Check if framebuffer_alloc is successful.

> +	info->device = dev;

No need to set info->device, framebuffer_alloc() will do it for you.

[snip]

> +
> +failed:
> +	dev_set_drvdata(dev, NULL);
> +	if (info)
> +		framebuffer_release(info);
> +	release_resource(res);
> +	return ret;

Fix the failure path.  kfree all kmallocs, dealloc_cmap(), etc.

> +}
> +
> +static int imxfb_remove(struct device *dev)
> +{
> +	struct fb_info *info = dev_get_drvdata(dev);
> +
> +	/* disable LCD controller */
> +	LCDC_RMCR &= ~RMCR_LCDC_EN;
> +
> +	unregister_framebuffer(info);
> +
> +	kfree(info->pseudo_palette);
> +	framebuffer_release(info);
> +

include dealloc_cmap here, at least.

> +	dev_set_drvdata(dev, NULL);
> +
> +	return 0;
> +}
> +
> +void  imxfb_shutdown(struct device * dev)
> +{
> +	/* disable LCD Controller */
> +	LCDC_RMCR &= ~RMCR_LCDC_EN;
> +}
> +
> +static struct device_driver imxfb_driver = {
> +	.name		= "imx-fb",
> +	.bus		= &platform_bus_type,
> +	.probe		= imxfb_probe,
> +	.suspend	= imxfb_suspend,
> +	.resume		= imxfb_resume,
> +	.remove		= imxfb_remove,
> +	.shutdown	= imxfb_shutdown,
> +};
> +
> +int __init imxfb_init(void)
> +{

It's ugliness, but you might want to include

if (fb_get_options("imxfb", NULL))
	return -ENODEV 

here so your driver can listen to generic video options, ie
video=imxfb:off.

[snip]

> +#define RGB_16	(0)
> +#define RGB_8	(1)
> +#define NR_RGB	2
> +
> +struct imxfb_info {
> +	struct fb_info		*fb;

If done properly, you don't need struct fb_info inside
struct imxfb_info.

Tony




-------------------------------------------------------
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

  reply	other threads:[~2005-03-18 14:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-17 17:36 [PATCH 1/2]Freescale i.MX framebuffer driver Sascha Hauer
2005-03-17 19:44 ` Antonino A. Daplas
2005-03-18 11:39   ` Sascha Hauer
2005-03-18 14:14     ` Antonino A. Daplas [this message]
2005-03-18 17:54       ` Sascha Hauer
2005-03-18 18:48         ` Geert Uytterhoeven
2005-03-18 20:47         ` Antonino A. Daplas
2005-03-22  9:31           ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200503182214.30492.adaplas@hotpop.com \
    --to=adaplas@hotpop.com \
    --cc=adaplas@pol.net \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox