From: Sascha Hauer <s.hauer@pengutronix.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv13][ 2/4] video: imxfb: Also add pwmr for the device tree.
Date: Fri, 06 Dec 2013 09:30:17 +0000 [thread overview]
Message-ID: <20131206093017.GB24559@pengutronix.de> (raw)
In-Reply-To: <1386318910.581671226@f322.i.mail.ru>
On Fri, Dec 06, 2013 at 12:35:10PM +0400, Alexander Shiyan wrote:
> > On Fri, Dec 06, 2013 at 12:03:54PM +0400, Alexander Shiyan wrote:
> ...
> > > > > - fsl,dmacr: DMA Control Register value. This is optional. By default, the
> > > > > register is not modified as recommended by the datasheet.
> > > > > +- fsl,pwmr: LCDC PWM Contrast Control Register value. That property is
> > > > > + optional, but defining it is necessary to get the backlight working. If that
> > > > > + property is ommited, the register is zeroed.
> > > >
> > > > Why isn't this implemented as a backlight driver? Static devicetree
> > > > provided values is very limiting.
> > >
> > > Let's understand the terminology.
> > > This register should be renamed according to the datasheet, i.e. LPCCR.
> > > As I pointed out earlier, it is NOT control the backlight, this is a contrast control.
> > > Yes, it works as PWM, but nothing do with the backlight subsystem.
> > > Yes, we can make a driver for this PWM, but how are we going to control it?
> > > I misunderstood something?
> >
> > I stumbled upon 'get the backlight working' which implied for me that it
> > should be a backlight driver. But you're right and now I remember we
> > talked about this already.
>
> Hallelujah.
>
> > I still think this should be something adjustable, not static data.
> > Maybe we could change the wording to something like "This property
> > provides the default value for the contrast control register" since even
> > if we add driver support for controlling the contrast we still want
> > to have a sane default.
>
> Sounds good.
>
> > BTW the contrast could be controlled with a lcd_device (see
> > lcd_device_register) which seems to be very easy to implement.
>
> Address of register is placed within LCD area, so we cannot use this
> memory region, I think is no so easy as you say....
We do not need a separate driver for this. Look for example at
drivers/video/bf537-lq035.c, it just calls lcd_device_register()
in its probe function.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2013-12-06 9:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-05 15:43 [PATCHv13][ 1/4] video: imxfb: Introduce regulator support Denis Carikli
2013-12-05 15:43 ` [PATCHv13][ 2/4] video: imxfb: Also add pwmr for the device tree Denis Carikli
2013-12-05 15:53 ` [PATCHv13][ 2/4] video: imxfb: Also add p =?UTF-8?B?d21yIGZvciB0aGUgZ Alexander Shiyan
2013-12-06 7:05 ` [PATCHv13][ 2/4] video: imxfb: Also add pwmr for the device tree Sascha Hauer
2013-12-06 8:03 ` [PATCHv13][ 2/4] video: imxfb: Also add p =?UTF-8?B?d21yIGZvciB0aGUgZ Alexander Shiyan
2013-12-06 8:16 ` [PATCHv13][ 2/4] video: imxfb: Also add pwmr for the device tree Sascha Hauer
2013-12-06 8:35 ` [PATCHv13][ 2/4] video: imxfb: Also add p =?UTF-8?B?d21yIGZvciB0aGUgZ Alexander Shiyan
2013-12-06 9:30 ` Sascha Hauer [this message]
2013-12-06 9:40 ` Alexander Shiyan
2013-12-05 15:43 ` [PATCHv13][ 3/4] video: Kconfig: Allow more broad selection of the imxfb framebuffer driver Denis Carikli
2013-12-06 7:06 ` Sascha Hauer
2013-12-05 15:43 ` [PATCHv13][ 4/4] ARM: dts: imx25: mbimxsd25: Add displays support Denis Carikli
2013-12-06 7:12 ` [PATCHv13][ 1/4] video: imxfb: Introduce regulator support Sascha Hauer
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=20131206093017.GB24559@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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).