From: Andrew Morton <akpm@linux-foundation.org>
To: Dmitry <dbaryshkov@gmail.com>
Cc: Ian Molton <spyro@f2s.com>, Samuel Ortiz <sameo@openedhand.com>,
linux-fbdev-devel@lists.sourceforge.net,
Andrew W Woodward <akwoodward@juno.com>
Subject: Re: [RESEND][PATCH 1/2] fbdev: add new TMIO framebuffer driver
Date: Sat, 4 Oct 2008 14:58:13 -0700 [thread overview]
Message-ID: <20081004145813.da36dfdd.akpm@linux-foundation.org> (raw)
In-Reply-To: <bc64b4640810041441t4e434939k4ff9db2a9dedad06@mail.gmail.com>
On Sun, 5 Oct 2008 01:41:15 +0400 Dmitry <dbaryshkov@gmail.com> wrote:
> >
> >> + info->mode = data->modes;
> >> + }
> >> +
> >> +
> >> + tmio_iowrite16(0x0010, par->lcr + LCR_LCDCCRC);
> >> + mdelay(5);
> >> + tmio_iowrite16(0x0014, par->lcr + LCR_LCDCCRC); /* STOP_CKP */
> >> + mdelay(5);
> >> + tmio_iowrite16(0x0015, par->lcr + LCR_LCDCCRC); /* STOP_CKP | SOFT_RESET */
> >> + tmio_iowrite16(0xfffa, par->lcr + LCR_VCS);
> >
> > I trust that someone who is reasonably familiar with the hardware will
> > know why all these magical mdelay()s are here. But even if they are,
> > some comments explaining them would enhance maintainability.
>
> that's just for clocks/reset to happen.
I wasn't asking what it was doing - I was asking whether it should be
left uncommented.
It's the sort of thing which simply cannot be understood by reading the
C code alone.
> >> +#ifdef CONFIG_FB_TMIO_ACCELL
> >> +static int __must_check
> >> +tmiofb_acc_wait(struct fb_info *info, unsigned int ccs)
> >> +{
> >> + struct tmiofb_par *par = info->par;
> >> + if (in_atomic() || par->use_polling) {
> >
> > No, use of in_atomic() is almost always wrong. It returns "false"
> > inside a spinlocked section when CONFIG_PREEMPT=n.
> >
> > I cannot advise you further because (tada) there is no comment
> > explaining this code to me. But it will need to be rethought, please.
>
> The problem is that code may call fb functions with interrupts disabled.
> One of examples is suspend/resume path, when console seems to be
> resumed before interrupts are enabled (this is governed
> by par->use_polling). I'm not sure that there are no other uses of fb
> functions in atomic context.
The use of irqs_disabled() is OK (with a comment explaining what it's for!).
> >> + int i = 0;
> >> + while (tmio_ioread16(par->lcr + LCR_CCS) > ccs) {
> >> + udelay(1);
> >> + i++;
> >> + if (i > 10000) {
> >> + printk(KERN_ERR "tmiofb: timeout waiting for %d\n", ccs);
> >> + return -ETIMEDOUT;
> >> + }
> >> + tmiofb_irq(-1, info);
> >> + }
> >> + } else {
> >> + if (!wait_event_interruptible_timeout(par->wait_acc,
> >> + tmio_ioread16(par->lcr + LCR_CCS) <= ccs, 1000)) {
> >> + printk(KERN_ERR "tmiofb: timeout waiting for %d\n", ccs);
> >> + return -ETIMEDOUT;
> >> + }
> >> + }
> >> +
> >> + return 0;
> >> +}
>
> ...
>
> >> +static int __devinit tmiofb_probe(struct platform_device *dev)
> >> +{
> >> + struct mfd_cell *cell = dev->dev.platform_data;
> >> + struct tmio_fb_data *data = cell->driver_data;
> >> + struct resource *ccr = platform_get_resource(dev, IORESOURCE_MEM, 1);
> >> + struct resource *lcr = platform_get_resource(dev, IORESOURCE_MEM, 0);
> >> + struct resource *vram = platform_get_resource(dev, IORESOURCE_MEM, 2);
> >> + int irq = platform_get_irq(dev, 0);
> >> + struct fb_info *info;
> >> + struct tmiofb_par *par;
> >> + int retval;
> >> +
> >> + if (data == NULL) {
> >> + dev_err(&dev->dev, "NULL platform data!\n");
> >
> > Can this happen?
>
> Of course, if you pass incorrect data to your TMIO controller chip.
But would that be a programming error in the caller?
> This is better than kernel Oops.
Not really. A kernel oops gets us nice debugging information and
prompts people to send us bug reports. That way, bugs get fixed.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
next prev parent reply other threads:[~2008-10-04 22:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-30 8:38 [RESEND][PATCH 1/2] fbdev: add new TMIO framebuffer driver Dmitry Baryshkov
2008-09-30 8:38 ` [RESEND][PATCH 2/2] mfd: support tmiofb cell on tc6393xb Dmitry Baryshkov
2008-10-03 22:56 ` Samuel Ortiz
2008-09-30 9:17 ` [RESEND][PATCH 1/2] fbdev: add new TMIO framebuffer driver Geert Uytterhoeven
2008-09-30 14:37 ` Ian Molton
2008-09-30 22:04 ` Krzysztof Helt
2008-10-04 13:38 ` Dmitry
2008-10-03 9:23 ` Andrew Morton
2008-10-03 11:35 ` Ian Molton
2008-10-04 21:41 ` Dmitry
2008-10-04 21:58 ` Andrew Morton [this message]
2008-10-05 8:09 ` Dmitry
-- strict thread matches above, loose matches on Subject: below --
2008-09-30 9:11 krzysztof.h1
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=20081004145813.da36dfdd.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=akwoodward@juno.com \
--cc=dbaryshkov@gmail.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=sameo@openedhand.com \
--cc=spyro@f2s.com \
/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).