lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 27 Dec 2011 10:32:28 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jingoo Han <jg1.han@...sung.com>
Cc:	'Florian Tobias Schandinat' <FlorianSchandinat@....de>,
	linux-kernel@...r.kernel.org, linux-fbdev@...r.kernel.org
Subject: Re: [PATCH] video: s3c-fb: Make runtime PM functional again

On Tue, Dec 27, 2011 at 01:40:47PM +0900, Jingoo Han wrote:

> > While this does make things simpler (the main motivation for the
> > original change) it will not only cause us to use more power in the
> > framebuffer controller but will also prevent us entering lower power
> > domain and SoC wide states as we can never power down the domain
> > containing the device.  Since neither of these things is desirable
> > revert the change.

> The main difference is as follows:
> If no fb windows are opened.
> 	- Your patch: LCD block power is off
> 	- My patch: LCD block power is on still.

By holding the LCD block power on your patch will also prevent the SoC
using lower power modes like STOP and DEEP-STOP on the S3C6410.

> However, after booting, probing, open is called from platform system, soon.
> And, the default window is always opened. This means that at least one window

This only happens if you enable CONFIG_FRAMEBUFFER_CONSOLE as that
causes the console code to become a framebuffer client.

> is opened after booting. So, I don't think that "video: s3c-fb: modify runtime
> pm functions" (commit: 35784b) cause us to use more power in the framebuffer
> controller.

If the console isn't using the framebuffer then whenever userspace
releases we'll be able to runtime suspend the framebuffer.  This isn't
ideal as what userspace expects is that it can hold the device open and
use blanking to save power - I'm working on patches to do this - but
it's a start.

> My intention is that runtime pm is used only for LCD block power off when
> suspend and resume are called.

This isn't runtime PM at all, it's system PM which for some reason calls
runtime PM functions.  At best the runtime PM calls won't do anything as
they're inhibited during system PM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ