From: ykzhao <yakui.zhao@intel.com>
To: Adam Jackson <ajax@redhat.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
Stable Team <stable@kernel.org>
Subject: Re: [PATCH 1/4] drm/i915: Configure the TV sense state correctly on GM45 to make TV detection reliable
Date: Thu, 22 Apr 2010 09:13:36 +0800 [thread overview]
Message-ID: <1271898816.3558.19.camel@localhost.localdomain> (raw)
In-Reply-To: <1271862548.32382.17242.camel@atropine.boston.devel.redhat.com>
On Wed, 2010-04-21 at 23:09 +0800, Adam Jackson wrote:
> On Wed, 2010-04-21 at 16:46 +0800, ykzhao wrote:
> > On Sat, 2010-04-10 at 05:14 +0800, Eric Anholt wrote:
> > > As far as I can tell from reading the specs, this patch just completely
> > > breaks TV detect on GM45. And the logic of "set all the bits for the
> > > register setting we're going to do and then if it's gm45 skip a few of
> > > them" is unintuitive and backwards, even if it was correct.\\
> >
> > This is from bios code. And the bios team also helps to confirm that TV
> > DAC sense state bits should be cleared to zero on cantiga platform.
>
> Uh. The patch does this:
>
> > + if (IS_GM45(dev))
> > + tv_dac &= ~(TVDAC_STATE_CHG_EN | TVDAC_A_SENSE_CTL |
> > + TVDAC_B_SENSE_CTL | TVDAC_C_SENSE_CTL);
> > +
>
> TVDAC_STATE_CHG_EN is documented as:
>
> > TVDAC_STATE_CHG_EN : Enables DAC state change detection logic
> > 0 = disabled
> > 1 = enabled
>
> You mean to tell me that, on Cantiga, _disabling_ the state change
> detection logic, enables state change detection?
On the cantiga the TV sense state bits[27:24] are required to be zero,
which is inconsistent with the description on the document.
After consulting with the BIOS team, they confirm that we had better
follow up the BIOS code on cantiga.
>
> > How about the following commit log?
> >
> > The TV detection logic is not reliable on the cantiga platform. Sometimes the
> > TV will be misdetected as the following two cases:
> > a. TV is misdetected on some laptops. e.g. There is no TV connector
> > port or no TV is attaced. But the TV is shown as connected.
> > b. TV connector type is misdetected. E.g. the component TV is
> > attached, but the TV is shown as S-video type.
> >
> > It is confirmed that in bios code the TV DAC sense bits should be cleared
> > to zero on GM45 in course of TV detection, which is different with other
> > platforms. It uses the following conditional definition:
> > IF CTG
> > TVDAC_SENSE_CTL EQU 0 ; Cantiga to Low level
> > ELSE
> > TVDAC_SENSE_CTL EQU BIT27 + BIT26 + BIT25 + BIT24
> > ENDIF ; CTG
>
> If the BIOS clears all those bits in TV_DAC, _then_ enables bit 27, then
> this seems like a reasonable thing to do. That would mean that the
> detection logic is basically one shot, and needs to be completely reset
> between uses.
>
> But I really don't see how, short of a really really bad hardware bug,
> turning a subsystem _off_ would make that subsystem work.
> - ajax
next prev parent reply other threads:[~2010-04-22 1:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1270631482-30282-1-git-send-email-zhenyuw@linux.intel.com>
[not found] ` <1270631482-30282-2-git-send-email-zhenyuw@linux.intel.com>
[not found] ` <87hbnkqqey.fsf@pollan.anholt.net>
2010-04-21 8:46 ` [PATCH 1/4] drm/i915: Configure the TV sense state correctly on GM45 to make TV detection reliable ykzhao
2010-04-21 15:09 ` Adam Jackson
2010-04-21 19:59 ` Peter Clifton
2010-04-22 1:13 ` ykzhao [this message]
[not found] ` <1270631482-30282-5-git-send-email-zhenyuw@linux.intel.com>
[not found] ` <87eiioqq20.fsf@pollan.anholt.net>
2010-04-26 6:11 ` [PATCH 4/4] drm/i915: Ignore LVDS EDID when it is unavailabe or invalid ykzhao
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=1271898816.3558.19.camel@localhost.localdomain \
--to=yakui.zhao@intel.com \
--cc=ajax@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@kernel.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.