linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Ben Dooks <ben-linux@fluff.org>
Cc: linux-fbdev-devel@lists.sourceforge.net,
	linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: [patch 3/5] FB: Add support for the ILI9320 video display controller.
Date: Tue, 24 Jun 2008 00:07:25 -0700	[thread overview]
Message-ID: <20080624000725.3622c57f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080622210614.627586051@fluff.org.uk>

On Sun, 22 Jun 2008 22:04:42 +0100 Ben Dooks <ben-linux@fluff.org> wrote:

> Provide support for the ILI9320 display controller chip
> which is found in many LCD displays. Included with this
> is support for an example LCD using this chip, the
> VGG2432A4.
> 

Please pass this patch (and indeed all patches) through
scripts/checkpatch.pl.  It finds things which you wouldn't have sent
had you known they were there.

>
> ...
>
> +int __devinit ili9320_probe_spi(struct spi_device *spi,
> +				struct ili9320_client *client)
> +{
> +	struct ili9320_platdata *cfg = spi->dev.platform_data;
> +	struct device *dev = &spi->dev;
> +	struct ili9320 *ili;
> +	struct lcd_device *lcd;
> +	int ret = 0;
> +
> +	/* verify we where given some information */
> +
> +	if (cfg == NULL) {
> +		dev_err(dev, "no platform data supplied\n");
> +		return -EINVAL;
> +	}
> +
> +	if (cfg->hsize <= 0 || cfg->vsize <= 0 || cfg->reset == NULL) {
> +		dev_err(dev, "invalid platform data supplied\n");
> +		return -EINVAL;
> +	}
> +
> +	/* allocate and initialse our state */
> +
> +	ili = kzalloc(sizeof(struct ili9320), GFP_KERNEL);
> +	if (ili == NULL) {
> +		dev_err(dev, "no memory for device\n");
> +		return -ENOMEM;
> +	}
> +
> +	ili->access.spi.id = ILI9320_SPI_IDCODE | ILI9320_SPI_ID(1);
> +
> +	ili->dev = dev;
> +	ili->client = client;
> +	ili->power = FB_BLANK_POWERDOWN;
> +	ili->platdata = cfg;
> +
> +	dev_set_drvdata(&spi->dev, ili);
> +
> +	ili9320_setup_spi(ili, spi);
> +
> +	lcd = lcd_device_register("ili9320", dev, ili, &ili9320_ops);
> +	if (IS_ERR(lcd)) {
> +		dev_err(dev, "failed to register lcd device\n");
> +		ret = PTR_ERR(lcd);
> +		goto err_free;
> +	}
> +
> +	ili->lcd = lcd;
> +
> +	dev_info(dev, "initialising %s\n", client->name);
> +
> +	ret = ili9320_power(ili, FB_BLANK_UNBLANK);
> +	if (ret != 0) {
> +		dev_err(dev, "failed to set lcd power state\n");
> +		goto err_unregister;
> +	}
> +
> +	return 0;
> +
> + err_unregister:
> +	lcd_device_unregister(lcd);
> +
> + err_free:
> +	kfree(lcd);
> +	return ret;
> +}

urgh.  lcd_device_register() returns kmalloced memory which the caller
must kfree() after having run lcd_device_unregister()?  Who thought
that scheme up?  :(

Does this function leaks *ili on errors?

> +EXPORT_SYMBOL_GPL(ili9320_probe_spi);
> +
> +int __devexit ili9320_remove(struct ili9320 *lcd)
> +{
> +	ili9320_power(lcd, FB_BLANK_POWERDOWN);
> +
> +	lcd_device_unregister(lcd->lcd);
> +	kfree(lcd);
> +
> +	return 0;
> +}
> +
> +EXPORT_SYMBOL_GPL(ili9320_remove);

Did ili get freed in here?

>
> ...
>
> +/* Holder for register and value pairs. */
> +struct ili9320_reg {
> +	unsigned short		address;
> +	unsigned short		value;
> +};
> +
> +struct ili9320;
> +
> +struct ili9320_client {
> +	const char	*name;
> +	int	(*init)(struct ili9320 *ili, struct ili9320_platdata *cfg);
> +
> +};
> +/* Device attached via an SPI bus. */
> +struct  ili9320_spi {

s/  / /

> +	struct spi_device	*dev;
> +	struct spi_message	message;
> +	struct spi_transfer	xfer[2];
> +
> +	unsigned char		id;
> +	unsigned char		buffer_addr[4];
> +	unsigned char		buffer_data[4];
> +};
> +
>
> ...
>
> +static int vgg2432a4_lcd_init(struct ili9320 *lcd,
> +			      struct ili9320_platdata *cfg)
> +{
> +	unsigned int addr;
> +	int ret;
> +
> +	/* Set VCore before anything else (VGG243237-6UFLWA) */
> +	ret = ili9320_write(lcd, 0x00e5, 0x8000);
> +	if (ret)
> +		goto err_initial;
> +
> +	/* Start the oscillator up before we can do anything else. */
> +	ret = ili9320_write(lcd, ILI9320_OSCILATION, ILI9320_OSCILATION_OSC);
> +	if (ret)
> +		goto err_initial;
> +
> +	/* must wait at-lesat 10ms after starting */
> +	mdelay(15);

msleep()?  And everywhere else.  This function alone consumes maybe
half a second CPU time.

>
> ...
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

  reply	other threads:[~2008-06-24  7:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-22 21:04 [patch 0/5] fb driver patches for next kernel Ben Dooks
2008-06-22 21:04 ` [patch 1/5] SM501: Add inversion controls for VBIASEN and FPEN Ben Dooks
2008-06-22 21:04 ` [patch 2/5] SM501: Restructure init to allow only 1 fb on an SM501 Ben Dooks
2008-06-24  6:54   ` Andrew Morton
2008-06-24 11:54     ` Ben Dooks
2008-06-22 21:04 ` [patch 3/5] FB: Add support for the ILI9320 video display controller Ben Dooks
2008-06-24  7:07   ` Andrew Morton [this message]
2008-06-24 13:37     ` Ben Dooks
2008-06-24 17:51       ` Andrew Morton
2008-06-22 21:04 ` [patch 4/5] LCD: Add lcd_device to check_fb() entry in lcd_ops Ben Dooks
2008-06-22 21:04 ` [patch 5/5] LCD: Add platform_lcd driver Ben Dooks

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=20080624000725.3622c57f.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ben-linux@fluff.org \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).