From: Zhenyu Wang <zhenyuw@linux.intel.com>
To: James Simmons <jsimmons@infradead.org>
Cc: airlied@redhat.com, dri-devel@lists.sourceforge.net
Subject: Re: [PATCH] drm: fix regression in fb blank handling
Date: Wed, 20 Jan 2010 10:54:49 +0800 [thread overview]
Message-ID: <20100120025449.GA11678@zhen-devel.sh.intel.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1001191609540.29861@casper.infradead.org>
[-- Attachment #1.1: Type: text/plain, Size: 1784 bytes --]
On 2010.01.19 16:17:56 +0000, James Simmons wrote:
> Sorry I meant the backlight power management state seperate from the
> encoder state.
>
> > drm_fb_helper_off() will find fb's crtc and attached encoders, then
> > call encoder_funcs->dpms() and turn off crtc, so for your DRM_MODE_DPMS_ON
> > change, it will actually turn encoder on, but what we need for
> > FB_BLANK_NORMAL is to turn off the display. No?
>
> FB_BLANK_NORMAL is not a full power down. Only CRTC is powerdown in this
> mode.
So how the encoder could tell the meaning of you passed DRM_MODE_DPMS_ON in
this case? which is really turning on everything, or keep port on but turn
off panel power?
> FB_BLANK_POWERDOWN turns off everything. You are wondering why this
> is the case. If the console blanks and you go to use it again it comes
> back very fast. In FB_BLANK_POWERDOWN mode it takes awhile to come back
> for certain types of displays. I have a old Sony CRT at home. Once powered
> down it takes about 5 to 10 seconds to come back up.
Isn't this monitor specific issue instead of display device problem? ;)
I don't think any LCD monitor nowadays could have this issue.
>
> Besides this the real issue is backlight != part of encoder.
>
> A patch will be coming shortly.
Panel power sequencing for Intel LVDS is controlled by encoder, and closely
related to port state, although we haven't really taken LVDS port enable/disable
step before Ironlake, I think this is normal case for encoders having backlight.
Could we just restore back to origin behavior for fixing this in 2.6.33?
Otherwise I don't know if your patch would be too intrusive...
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 420 bytes --]
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
next prev parent reply other threads:[~2010-01-20 2:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-18 8:47 [PATCH] drm: fix regression in fb blank handling Zhenyu Wang
2010-01-18 13:30 ` James Simmons
2010-01-19 1:01 ` Zhenyu Wang
2010-01-19 16:17 ` James Simmons
2010-01-20 2:54 ` Zhenyu Wang [this message]
2010-01-20 13:14 ` James Simmons
2010-01-21 1:09 ` Zhenyu Wang
2010-01-25 6:29 ` Dave Airlie
2010-01-25 18:12 ` James Simmons
2010-01-26 1:09 ` Zhenyu Wang
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=20100120025449.GA11678@zhen-devel.sh.intel.com \
--to=zhenyuw@linux.intel.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=jsimmons@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.