All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present
@ 2010-08-22 17:23 Chris Wilson
  2010-08-22 18:06 ` Chris Wilson
  0 siblings, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2010-08-22 17:23 UTC (permalink / raw)
  To: intel-gfx

My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
addin-offset. With the check in place, the panel was declared absent.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhao Yakui <yakui.zhao@intel.com>
---
 drivers/gpu/drm/i915/intel_lvds.c |   34 +++++++++++++++-------------------
 1 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index 218875a..12fd5fe 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -748,38 +748,34 @@ static void intel_find_lvds_downclock(struct drm_device *dev,
  * If it is present, return 1.
  * If it is not present, return false.
  * If no child dev is parsed from VBT, it assumes that the LVDS is present.
- * Note: The addin_offset should also be checked for LVDS panel.
- * Only when it is non-zero, it is assumed that it is present.
  */
-static int lvds_is_present_in_vbt(struct drm_device *dev)
+static bool lvds_is_present_in_vbt(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
-	struct child_device_config *p_child;
-	int i, ret;
+	int i;
 
 	if (!dev_priv->child_dev_num)
-		return 1;
+		return true;
 
-	ret = 0;
 	for (i = 0; i < dev_priv->child_dev_num; i++) {
-		p_child = dev_priv->child_dev + i;
+		struct child_device_config *child = dev_priv->child_dev + i;
+
 		/*
 		 * If the device type is not LFP, continue.
 		 * If the device type is 0x22, it is also regarded as LFP.
 		 */
-		if (p_child->device_type != DEVICE_TYPE_INT_LFP &&
-			p_child->device_type != DEVICE_TYPE_LFP)
-			continue;
-
-		/* The addin_offset should be checked. Only when it is
-		 * non-zero, it is regarded as present.
+		if (p_child->device_type == DEVICE_TYPE_INT_LFP ||
+		    p_child->device_type == DEVICE_TYPE_LFP)
+			return true;
+
+		/* Note that we used to check for a non-zero addin offset
+		 * before declaring the panel present. However, we have found
+		 * panels with zero offset in the wild and so must assume
+		 * that the VBT is correct.
 		 */
-		if (p_child->addin_offset) {
-			ret = 1;
-			break;
-		}
 	}
-	return ret;
+
+	return false;
 }
 
 /**
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present
  2010-08-22 17:23 [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present Chris Wilson
@ 2010-08-22 18:06 ` Chris Wilson
  2010-08-23 14:46   ` Adam Jackson
  0 siblings, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2010-08-22 18:06 UTC (permalink / raw)
  To: intel-gfx

On Sun, 22 Aug 2010 18:23:21 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
> addin-offset. With the check in place, the panel was declared absent.

Reviewing the history, the addin-offset was added to defend against
incorrect LVDS entries in some VBIOSes. Can we rely on the no-lvds quirk
table instead?

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present
  2010-08-22 18:06 ` Chris Wilson
@ 2010-08-23 14:46   ` Adam Jackson
  2010-08-23 15:23     ` Chris Wilson
  0 siblings, 1 reply; 6+ messages in thread
From: Adam Jackson @ 2010-08-23 14:46 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 874 bytes --]

On Sun, 2010-08-22 at 19:06 +0100, Chris Wilson wrote:
> On Sun, 22 Aug 2010 18:23:21 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
> > addin-offset. With the check in place, the panel was declared absent.
> 
> Reviewing the history, the addin-offset was added to defend against
> incorrect LVDS entries in some VBIOSes. Can we rely on the no-lvds quirk
> table instead?

If you don't mind that the quirk table is wildly incomplete, sure.

AIM seems to be structured such that you have to have an addin to make
LVDS work.  I think the opregion change you posted is sufficient to find
the real VBT; having done that, the addin offset check is still valid.
If the platform would give us some actually reliable method of doing
LVDS detection then we could skip all this, but.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present
  2010-08-23 14:46   ` Adam Jackson
@ 2010-08-23 15:23     ` Chris Wilson
  2010-08-23 18:22       ` Adam Jackson
  0 siblings, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2010-08-23 15:23 UTC (permalink / raw)
  To: Adam Jackson; +Cc: intel-gfx

On Mon, 23 Aug 2010 10:46:33 -0400, Adam Jackson <ajax@redhat.com> wrote:
> AIM seems to be structured such that you have to have an addin to make
> LVDS work.  I think the opregion change you posted is sufficient to find
> the real VBT; having done that, the addin offset check is still valid.

Sadly, I discovered this after enabling the OpRegion->VBT. The Samsung
went from finding no VBT to declaring the LVDS absent. :(

I am on the scrounge for documentation on how this all meant to hang
together. Reality will be different, but it would be nice to know what the
fields are supposed to mean.

> If the platform would give us some actually reliable method of doing
> LVDS detection then we could skip all this, but.

Amen.
-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present
  2010-08-23 15:23     ` Chris Wilson
@ 2010-08-23 18:22       ` Adam Jackson
  2010-08-23 22:00         ` Chris Wilson
  0 siblings, 1 reply; 6+ messages in thread
From: Adam Jackson @ 2010-08-23 18:22 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 1454 bytes --]

On Mon, 2010-08-23 at 16:23 +0100, Chris Wilson wrote:
> On Mon, 23 Aug 2010 10:46:33 -0400, Adam Jackson <ajax@redhat.com> wrote:
> > AIM seems to be structured such that you have to have an addin to make
> > LVDS work.  I think the opregion change you posted is sufficient to find
> > the real VBT; having done that, the addin offset check is still valid.
> 
> Sadly, I discovered this after enabling the OpRegion->VBT. The Samsung
> went from finding no VBT to declaring the LVDS absent. :(
> 
> I am on the scrounge for documentation on how this all meant to hang
> together. Reality will be different, but it would be nice to know what the
> fields are supposed to mean.

addin_offset is (afaict) intended to be the offset to the setup ROM
embedded on SDVO devices once it's glued into the final image at boot
time, or the offset to the equivalent table for non-SDVO outputs.  Which
is why I considered it pretty reliable; if it points to the vtable for
output setup, then it's only going to exist if the output exists.

But I suppose some enterprising BIOS engineer could have looked at the
whole vtable thing and thought "that's too big, I can do it better".  In
which case, if we have to resort to opregion to find the VBT, then maybe
we should believe whatever it claims to have.

IWBNI we had the VBT in a sysfs or debugfs file, if we're not going to
be able to pull it out of the legacy ROM space reliably.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present
  2010-08-23 18:22       ` Adam Jackson
@ 2010-08-23 22:00         ` Chris Wilson
  0 siblings, 0 replies; 6+ messages in thread
From: Chris Wilson @ 2010-08-23 22:00 UTC (permalink / raw)
  To: Adam Jackson; +Cc: intel-gfx

On Mon, 23 Aug 2010 14:22:48 -0400, Adam Jackson <ajax@redhat.com> wrote:
> IWBNI we had the VBT in a sysfs or debugfs file, if we're not going to
> be able to pull it out of the legacy ROM space reliably.

I added it to debugfs, only to my surprise the header.size field which I
thought was in KB (according to the OpRegion spec and the first machine I
tried) appears to be in bytes on the Samsung. Wonders never cease.

I guess I could just hardcode it to 8KiB, it's not like it is going to
change anytime soon.

Thanks for the information about the rationale, I'll dig out the OpRegion
shortly...

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-08-23 22:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-22 17:23 [PATCH] drm/i915: Addin-offset is an unreliable indicator of LVDS present Chris Wilson
2010-08-22 18:06 ` Chris Wilson
2010-08-23 14:46   ` Adam Jackson
2010-08-23 15:23     ` Chris Wilson
2010-08-23 18:22       ` Adam Jackson
2010-08-23 22:00         ` Chris Wilson

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.