linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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=/

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