[Intel-gfx] [PATCH] drm/i915: Fix DDC bus selection for multifunction SDVO

[Adam Jackson]

On Wed, 2010-04-28 at 10:15 +0800, Zhenyu Wang wrote:
> On 2010.04.23 16:16:12 -0400, Adam Jackson wrote:
> > Multifunction SDVO cards stopped working after 14571b4, and would report
> > something that looked remarkably like an ADD2 SPD ROM instead of EDID.
> > This appears to be because DDC bus selection was utterly horked by that
> > commit; controlled_output was no longer always a single bit, so
> > intel_sdvo_select_ddc_bus would pick bus 0, which is (unsurprisingly)
> > the SPD ROM bus, not a DDC bus.
> > 
> > So, instead of that, let's just use the DDC bus the child device table
> > tells us to use.  I'm guessing at the bitmask and shifting from VBIOS
> > dumps, but it can't possibly be worse.
> > 
> > cf. https://bugzilla.redhat.com/584229
> 
> I'm worried about anything depending on BIOS table info for everytime.
> Or if we have a fallback to spec method way to validate if BIOS info
> really makes sense? As intel_sdvo_select_ddc_bus follows spec to select
> ddc bus switch, which in most case should be followed by SDVO chip too.

Well, if the BIOS uses this data table, and if output detection of SDVO
devices works at BIOS time, then we can probably use it safely at
runtime too.  Read the BIOS and find out.

> We should fix the DDC bus selection issue by check attached_output now
> and after detection for getting back the real connected output type, instead
> of fixed in init.

The "priority order" thing in the current implementation of
intel_sdvo_select_ddc_bus is presented without justification.  I assume
it's derived from a design document given by Intel to BIOS vendors
and/or ADD2 device manufacturers.  If they're following _that_
recommendation, then they would probably also be following the
recommendations to put the DDC bus they choose in the child device
table.  (Otherwise, why would that field in the CDT even exist.)  So the
DDC bus listed in the CDT is correct, and we should use it.

If they're _not_ following that recommendation, but there's still a CDT
that looks like it describes real SDVO devices, then either:

a) they're using the BIOS' DDC routines, and they put the DDC bus
they're really using in the CDT,
b) they're not using the BIOS' DDC routines.

Option b implies non-compatibility with off-the-shelf ADD2 cards, which
would defeat the whole purpose of ADD2.  Option a means the DDC bus
listed in the BIOS is correct, and we should use it.

If there isn't a CDT that looks like it describes real SDVO devices,
then we're already unable to drive them sensibly.

Seriously.  Read the ADD2 design documentation (it must exist, and Intel
must have written it, because it's your spec).  Find out what it says to
do and implement it.  It _has_ to work that way because that's the whole
point of ADD2, to have a bunch of vendors selling peripherals that
interoperate with Intel's GPUs, and have them work even in DOS.  If the
cards didn't do what the spec says to do, no one would buy them.  If the
hosts didn't do what the spec says to do, they would have only limited
market.  Either way it's reducing the amount of money someone can make,
so the Invisible Hand says that's just not going to happen.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100428/364ed65c/attachment.sig>