From: Ben Dooks <ben-linux@fluff.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fbdev-devel@lists.sourceforge.net,
linux-arm-kernel@lists.arm.linux.org.uk,
Ben Dooks <ben-linux@fluff.org>
Subject: Re: [patch 3/5] FB: Add support for the ILI9320 video display controller.
Date: Tue, 24 Jun 2008 14:37:28 +0100 [thread overview]
Message-ID: <20080624133728.GB22222@fluff.org.uk> (raw)
In-Reply-To: <20080624000725.3622c57f.akpm@linux-foundation.org>
On Tue, Jun 24, 2008 at 12:07:25AM -0700, Andrew Morton wrote:
> 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? :(
This seems to be some confusion on my part about what was being freed
and where. There is a cleanup method on the device release and what
was meant to be freed was the ili.
> Does this function leaks *ili on errors?
I've fixed that.
> > +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?
Yes, but the naming confusion means that it looks like it
was freeing the lcd. I've renamed the argument to ili and
ensured we kfree() what we intended to kfree().
> > +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.
I've had no end of problems with getting suspend/resume working
with msleep in. I'll try and see if this can be changed, but I've
got lots of other patches in flight atm.
Would you like a new patch for the other issues, or a fixup patch for
the driver?
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
-------------------------------------------------------------------------
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 13:37 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
2008-06-24 13:37 ` Ben Dooks [this message]
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=20080624133728.GB22222@fluff.org.uk \
--to=ben-linux@fluff.org \
--cc=akpm@linux-foundation.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).