From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>,
linux-media@vger.kernel.org
Subject: Re: [PATCH v2 2/2] as3645a: Add driver for LED flash controller
Date: Tue, 15 Nov 2011 18:55:55 +0200 [thread overview]
Message-ID: <1321376155.30587.23.camel@smile> (raw)
In-Reply-To: <201111151412.39333.laurent.pinchart@ideasonboard.com>
On Tue, 2011-11-15 at 14:12 +0100, Laurent Pinchart wrote:
> > > +struct as3645a {
> > > + struct v4l2_subdev subdev;
> > > + struct as3645a_platform_data *platform_data;
> > > +
> > > + struct mutex power_lock;
> > > + int power_count;
> > > +
> > > + /* Static parameters */
> > > + u8 vref;
> > > + u8 peak;
> > > +
> > > + /* Controls */
> > > + struct v4l2_ctrl_handler ctrls;
> > > +
> > > + enum v4l2_flash_led_mode led_mode;
> > > + unsigned int timeout;
> > > + u8 flash_current;
> > > + u8 assist_current;
> > > + u8 indicator_current;
> > > + enum v4l2_flash_strobe_source strobe_source;
> >
> > Do you think we should store this information in the controls instead,
> > or not?
>
> I've been thinking about that as well. The reason why the control values were
> copied to the as3645a structure is that they were accessed in timer context,
> where taking the control lock wasn't possible.
>
> I could switch to accessing the information in controls directly now, but that
> would require storing pointers to the controls in the as3645a structure, which
> might not be that better :-) And the code will need to change back to storing
> values when overheat protection will be implemented anyway. If you still think
> it's better, I can change it.
We don't need to solve the issue which is absent. We have in-kernel
adp1653 driver w/o overheat protection. It requires to be updated
anyway. I prefer to update drivers in common way when we will have
overheat protection framework in place.
> > > + switch (man) {
> > > + case 1:
> > > + factory = "AMS, Austria Micro Systems";
> > > + break;
> > > + case 2:
> > > + factory = "ADI, Analog Devices Inc.";
> > > + break;
> > > + case 3:
> > > + factory = "NSC, National Semiconductor";
> > > + break;
> > > + case 4:
> > > + factory = "NXP";
> > > + break;
> > > + case 5:
> > > + factory = "TI, Texas Instrument";
> > > + break;
> > > + default:
> > > + factory = "Unknown";
> > > + }
> > > +
> > > + dev_dbg(&client->dev, "Factory: %s(%d) Version: %d\n", factory, man,
> > > + version);
> >
> > Is that really a factor or is it the chip vendor --- which might
> > contract another factory to actually manufacture the chips?
>
> I don't know :-)
I guess the vendor is proper word here. For example, lm3555 (NSC) is
slightly different from as3645a.
And why dev_dbg? I think dev_info here might be suitable.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2011-11-15 16:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 0:19 [PATCH v2 0/2] as3645a flash driver Laurent Pinchart
2011-11-14 0:19 ` [PATCH v2 1/2] v4l: Add over-current and indicator flash fault bits Laurent Pinchart
2011-11-14 0:19 ` [PATCH v2 2/2] as3645a: Add driver for LED flash controller Laurent Pinchart
2011-11-14 9:34 ` Sakari Ailus
2011-11-15 12:01 ` Andy Shevchenko
2011-11-15 13:12 ` Laurent Pinchart
2011-11-15 15:28 ` Sakari Ailus
2011-11-15 15:53 ` Laurent Pinchart
2011-11-15 15:59 ` Sakari Ailus
2011-11-15 16:55 ` Andy Shevchenko [this message]
2011-11-16 0:37 ` Laurent Pinchart
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=1321376155.30587.23.camel@smile \
--to=andriy.shevchenko@linux.intel.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@maxwell.research.nokia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.