From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] video: fbdev: imxfb: enable lcd regulator in .probe
Date: Fri, 11 Mar 2016 11:22:40 +0000 [thread overview]
Message-ID: <56E2AA80.4050908@ti.com> (raw)
In-Reply-To: <1457380425-20244-3-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1818 bytes --]
On 07/03/16 21:53, Uwe Kleine-König wrote:
> This asserts that the display is on after the driver is initialized.
> Otherwise, depending on how the boot loader handled the display, it is
> either disabled as the regulator doesn't seem in use, or it stays off.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/video/fbdev/imxfb.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
> index c5fcedde2a60..3dd2824e6773 100644
> --- a/drivers/video/fbdev/imxfb.c
> +++ b/drivers/video/fbdev/imxfb.c
> @@ -979,8 +979,17 @@ static int imxfb_probe(struct platform_device *pdev)
> imxfb_enable_controller(fbi);
> fbi->pdev = pdev;
>
> + if (!IS_ERR(fbi->lcd_pwr)) {
> + ret = regulator_enable(fbi->lcd_pwr);
> + if (ret)
> + goto failed_regulator;
> + }
> +
> return 0;
>
> +failed_regulator:
> + imxfb_disable_controller(fbi);
> +
> failed_lcd:
> unregister_framebuffer(info);
So I didn't go through the code in detail, but this doesn't look correct
to me.
Where is the regulator disabled which now gets enabled in probe?
imxfb_lcd_set_power() handles the regulator enable/disable, so doesn't
this mean the regulator would always be enabled? You first enable it in
probe, then imxfb_lcd_set_power() enables it at some point (?), so the
enable-count is two then.
To be honest, I've never used 'struct lcd_ops', but I think the enabling
of the regulator should happen somehow via that. If the regulator needs
to be enabled at probe time, then the probe should somehow cause
lcd_ops->set_power to get called.
Why does the regulator need to be enabled at probe? Or are you saying
imxfb_lcd_set_power() is never called in your case?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] video: fbdev: imxfb: enable lcd regulator in .probe
Date: Fri, 11 Mar 2016 13:22:40 +0200 [thread overview]
Message-ID: <56E2AA80.4050908@ti.com> (raw)
In-Reply-To: <1457380425-20244-3-git-send-email-u.kleine-koenig@pengutronix.de>
On 07/03/16 21:53, Uwe Kleine-K?nig wrote:
> This asserts that the display is on after the driver is initialized.
> Otherwise, depending on how the boot loader handled the display, it is
> either disabled as the regulator doesn't seem in use, or it stays off.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> drivers/video/fbdev/imxfb.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
> index c5fcedde2a60..3dd2824e6773 100644
> --- a/drivers/video/fbdev/imxfb.c
> +++ b/drivers/video/fbdev/imxfb.c
> @@ -979,8 +979,17 @@ static int imxfb_probe(struct platform_device *pdev)
> imxfb_enable_controller(fbi);
> fbi->pdev = pdev;
>
> + if (!IS_ERR(fbi->lcd_pwr)) {
> + ret = regulator_enable(fbi->lcd_pwr);
> + if (ret)
> + goto failed_regulator;
> + }
> +
> return 0;
>
> +failed_regulator:
> + imxfb_disable_controller(fbi);
> +
> failed_lcd:
> unregister_framebuffer(info);
So I didn't go through the code in detail, but this doesn't look correct
to me.
Where is the regulator disabled which now gets enabled in probe?
imxfb_lcd_set_power() handles the regulator enable/disable, so doesn't
this mean the regulator would always be enabled? You first enable it in
probe, then imxfb_lcd_set_power() enables it at some point (?), so the
enable-count is two then.
To be honest, I've never used 'struct lcd_ops', but I think the enabling
of the regulator should happen somehow via that. If the regulator needs
to be enabled at probe time, then the probe should somehow cause
lcd_ops->set_power to get called.
Why does the regulator need to be enabled at probe? Or are you saying
imxfb_lcd_set_power() is never called in your case?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160311/bb4f6137/attachment.sig>
next prev parent reply other threads:[~2016-03-11 11:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 19:53 [PATCH 0/3] video: fbdev: imxfb: make it work again Uwe Kleine-König
2016-03-07 19:53 ` Uwe Kleine-König
2016-03-07 19:53 ` [PATCH 1/3] video: fbdev: imxfb: fix semantic of .get_power and .set_power Uwe Kleine-König
2016-03-07 19:53 ` Uwe Kleine-König
2016-03-08 7:55 ` Philipp Zabel
2016-03-08 7:55 ` Philipp Zabel
2016-03-08 8:30 ` Uwe Kleine-König
2016-03-08 8:30 ` Uwe Kleine-König
2016-03-07 19:53 ` [PATCH 2/3] video: fbdev: imxfb: enable lcd regulator in .probe Uwe Kleine-König
2016-03-07 19:53 ` Uwe Kleine-König
2016-03-11 11:22 ` Tomi Valkeinen [this message]
2016-03-11 11:22 ` Tomi Valkeinen
2016-04-20 19:17 ` Uwe Kleine-König
2016-04-20 19:17 ` Uwe Kleine-König
2016-07-05 10:09 ` Uwe Kleine-König
2016-07-05 10:09 ` Uwe Kleine-König
2016-07-05 12:08 ` Lothar Waßmann
2016-07-05 12:08 ` Lothar Waßmann
2016-07-05 12:22 ` Uwe Kleine-König
2016-07-05 12:22 ` Uwe Kleine-König
2016-07-27 19:57 ` Uwe Kleine-König
2016-07-27 19:57 ` Uwe Kleine-König
2016-08-10 10:29 ` Tomi Valkeinen
2016-08-10 10:29 ` Tomi Valkeinen
2016-03-07 19:53 ` [PATCH 3/3] video: fbdev: imxfb: add some error handling Uwe Kleine-König
2016-03-07 19:53 ` Uwe Kleine-König
2016-03-08 8:00 ` Philipp Zabel
2016-03-08 8:00 ` Philipp Zabel
2016-03-11 11:26 ` Tomi Valkeinen
2016-03-11 11:26 ` Tomi Valkeinen
2016-03-07 20:03 ` [PATCH 0/3] video: fbdev: imxfb: make it work again Fabio Estevam
2016-03-07 20:03 ` Fabio Estevam
2016-03-07 20:10 ` Uwe Kleine-König
2016-03-07 20:10 ` Uwe Kleine-König
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=56E2AA80.4050908@ti.com \
--to=tomi.valkeinen@ti.com \
--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 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.