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
next prev parent 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).