Re: [PATCH] i915: Skip wrong TV outputs on HP laptop
On Wed, 2010-04-21 at 01:58 +0800, Takashi Iwai wrote: At Tue, 20 Apr 2010 10:13:20 -0700, Eric Anholt wrote: On Tue, 20 Apr 2010 14:50:54 +0200, Takashi Iwai ti...@suse.de wrote: A new HP laptop with GM45 seems detecting wrongly TV outputs occasionally. Most of time it detects the TV output as disconnected, but spontaneously it detects NTSC 480i although the laptop has no TV output at all. A simple (but ad hoc) fix is to add a DMI check as below. Signed-off-by: Takashi Iwai ti...@suse.de Does this laptop have no TV connector on the laptop or the dock for it? No, it has neither TV connector nor docking-station. If any patch that can fix the wrong detection is available, I'll happily test it. Oh. This laptop is also based on gm45. Maybe it has the similar issue wit the laptop on https://bugzilla.kernel.org/show_bug.cgi?id=14792. Will you please try the patch in hhttps://bugzilla.kernel.org/show_bug.cgi?id=14792#C24 and see whether the issue can be fixed? Thanks. Yakui thanks, Takashi -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Add a generic function to change connector type/id of connector dynamically
On Thu, 2010-01-28 at 01:24 +0800, Jesse Barnes wrote: On Wed, 27 Jan 2010 19:25:04 +1000 Dave Airlie airl...@redhat.com wrote: On Wed, 2010-01-27 at 15:16 +0800, yakui.z...@intel.com wrote: From: Zhao Yakui yakui.z...@intel.com Sometimes one connector can support more than one connector type. And it will switch the connector type/id dynamically according to the external connected device. Connectors cannot change they physical plugs that users plug stuff into. Yakui, I think what we really want here is to split the SDVO code (at the very least) into an encoder/connector scheme like radeon uses. Most of the Intel outputs have paired encoder/connectors (e.g. LVDS, TV, VGA) but SDVO doesn't, so we should split it out. The fact that it's still treated as a single blob is historical, dating back from the big rework Dave did to properly split encoders from connectors. Thanks for pointing out the issue. And we will try in this direction. Best regards. Yakui. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Add a generic function to change connector type/id of connector dynamically
On Wed, 2010-01-27 at 17:07 +0800, Maarten Maathuis wrote:
On Wed, Jan 27, 2010 at 8:16 AM, yakui.z...@intel.com wrote:
From: Zhao Yakui yakui.z...@intel.com
Sometimes one connector can support more than one connector type. And it
will switch the connector type/id dynamically according to the external
connected device.
I very much doubt it's the connector that is physically changing. It's
a plug, a piece of metal with connection points/wires. What you want
is multiple connectors with the same encoder, to accurately reflect
what is happening.
Only one plug is used for this encoder. But it can be detected as
different type when the different adaptor is used. For one
multi-function SDVO card, it can be detected as LVDS, VGA,
SDVO-TV(composite/S-video). Before the external device is connected, we
can't know the exact connector type.
What I want is to report the correct type according to the external
connected device. When the user changes the external connected device,
we can reflect their changes.
Thanks.
Yakui
Add a generic function to change connector type/id of the connector
dynamically.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
One multi-function SDVO card device can support SDVO-VGA/SDVO-TV(S-Video/
Composite). We should give them the correct connector type according
to the external connected device. For example: VGA/TV. The connector id
should be re-initialized when connector type is changed. Otherwise we will
get one conflict connector id.
One list is added to save the connector type/id that is already used by the
connector. If the target type is already in the list, we can change the
connector type/ide directly by using the saved result.
If the new connector type is not in the list, we will dynamically
allocate the connector id for it and then save the connector type/id to the
list.
drivers/gpu/drm/drm_crtc.c | 81
include/drm/drm_crtc.h |5 +++
2 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5124401..a64e389 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -39,6 +39,11 @@ struct drm_prop_enum_list {
char *name;
};
+struct connector_type_id {
+ struct list_head head;
+ int connector_type;
+ int connector_id;
+};
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
char *fnname(int val) \
@@ -443,6 +448,13 @@ void drm_connector_init(struct drm_device *dev,
const struct drm_connector_funcs *funcs,
int connector_type)
{
+ struct connector_type_id *p_type_id = NULL;
+
+ p_type_id = kzalloc(sizeof(*p_type_id), GFP_KERNEL);
+
+ if (!p_type_id)
+ DRM_DEBUG_KMS(Can't allocate the memory\n);
+
mutex_lock(dev-mode_config.mutex);
connector-dev = dev;
@@ -465,11 +477,73 @@ void drm_connector_init(struct drm_device *dev,
drm_connector_attach_property(connector,
dev-mode_config.dpms_property, 0);
+ INIT_LIST_HEAD(connector-connector_type_list);
+ if (p_type_id) {
+ p_type_id-connector_type = connector_type;
+ p_type_id-connector_id = connector-connector_type_id;
+ list_add_tail(p_type_id-head,
+ connector-connector_type_list);
+ }
mutex_unlock(dev-mode_config.mutex);
}
EXPORT_SYMBOL(drm_connector_init);
/**
+ * drm_rename_connector_type - Rename the connector type for one connector
+ * @connector: the connector to be named
+ * @target_type: the renamed target connector type
+ *
+ * Rename the connector type for one connector. Sometimes we will
+ * need get a new connector type id.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+
+int drm_rename_connector_type(struct drm_connector *connector,
+int target_type)
+{
+ struct connector_type_id *type_id, *temp;
+ int connector_id, found = 0;
+ struct drm_device *dev = connector-dev;
+
+ if (connector-connector_type == target_type)
+ return 0;
+
+ list_for_each_entry_safe(type_id, temp,
+ connector-connector_type_list, head) {
+ if (type_id-connector_type == target_type) {
+ connector_id = type_id-connector_id;
+ found = 1;
+ break;
+ }
+ }
+ if (found) {
+ connector-connector_type = target_type;
+ connector-connector_type_id = connector_id;
+ return 0;
+ }
+
Re: [PATCH] drm/i915: Add HP nx9020/Samsung SX20S to ACPI LID quirk list
On Tue, 2010-01-12 at 06:47 +0800, Len Brown wrote:
From: Zhao Yakui yakui.z...@intel.com
Hi, Len
Thanks for caring this issue.
Now this patch is already picked up by Eric. And it is Eric's
drm-intel-next tree.
Thanks.
Yakui.
The HP comaq nx9020/Samsung SX20S laptop always report that the LID status is
closed and we can't use it reliabily for LVDS detection. So add the two boxes
into the quirk list.
http://bugzilla.kernel.org/show_bug.cgi?id=14957
http://bugzilla.kernel.org/show_bug.cgi?id=14554
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Tested-by: Philipp Kohlbecherx...@gmx.de
Signed-off-by: Len Brown len.br...@intel.com
---
Dave,
As this is an ACPI BIOS workaround bug that touches DRM code,
if you ack this I'll be happy to send this upstream w/ your ack.
thanks,
-Len
drivers/gpu/drm/i915/intel_lvds.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index f4b4aa2..160283a 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -602,6 +602,20 @@ static void intel_lvds_mode_set(struct drm_encoder
*encoder,
/* Some lid devices report incorrect lid status, assume they're connected */
static const struct dmi_system_id bad_lid_status[] = {
{
+ .ident = Compaq nx9020,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Hewlett-Packard),
+ DMI_MATCH(DMI_BOARD_NAME, 3084),
+ },
+ },
+ {
+ .ident = Samsung SX20S,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Samsung Electronics),
+ DMI_MATCH(DMI_BOARD_NAME, SX20S),
+ },
+ },
+ {
.ident = Aspire One,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, Acer),
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable 36bit physical address for hardware status page
On Tue, 2010-01-05 at 11:25 +0800, Zhenyu Wang wrote:
This enables possible 36bit address mask on 965G that use physical
address for hw status page.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/char/agp/intel-agp.c|6 +-
drivers/gpu/drm/i915/i915_dma.c |4
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 30c36ac..3999a5f 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -2460,10 +2460,14 @@ static int __devinit agp_intel_probe(struct pci_dev
*pdev,
bridge-mode);
}
- if (bridge-driver-mask_memory == intel_i965_mask_memory)
+ if (bridge-driver-mask_memory == intel_i965_mask_memory) {
if (pci_set_dma_mask(intel_private.pcidev, DMA_BIT_MASK(36)))
dev_err(intel_private.pcidev-dev,
set gfx device dma mask 36bit failed!\n);
+ else
+ pci_set_consistent_dma_mask(intel_private.pcidev,
+ DMA_BIT_MASK(36));
+ }
It seems that both pci_set_dma_mask/set_consistent_dma_mask will be
called when the DMA mask is set correctly.
Can we use the following format so that it is easy to understand?
if (!pci_set_dma_mask() !pci_set_consistent_dma_mask()) {
success;
} else
failure;
Do we need to add the explicit DMA mask for using 32bit DMA mask?
pci_set_drvdata(pdev, bridge);
return agp_add_bridge(bridge);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 02607ed..750f6c8 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -134,6 +134,10 @@ static int i915_init_phys_hws(struct drm_device *dev)
memset(dev_priv-hw_status_page, 0, PAGE_SIZE);
+ if (IS_I965G(dev))
+ dev_priv-dma_status_page |= (dev_priv-dma_status_page 28)
+ 0xf0;
+
I915_WRITE(HWS_PGA, dev_priv-dma_status_page);
DRM_DEBUG_DRIVER(Enabled hardware status page\n);
return 0;
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: lvds downclocking breaks on G45/thinkpad T500
On Sun, 2009-12-27 at 01:41 +0800, Andres Freund wrote: On Saturday 26 December 2009 17:49:29 Andres Freund wrote: On 2.6.33-rc1 I noticed that the display of my T500 with a G45 reacts very slowly (you can see the text appearing) and colors take a time to solidify. I.e. making a white terminal black takes some seconds. ... Anything I can do to help analyzing the issue? Thats with recent git checkouts of xorg btw, if thats relevant (which I doubt a bit). The missing config is attached now as well. It will be great if you can open a new bug on bugs.freedesktop.org(Product=xorg, component = driver/intel) and attach the following info: 1. add the boot option of drm.debug=0x06 and attach the output of dmesg. 2. attach the output of xrandr -q --verbose 3. attach the vbios.dump, which can be obtained by using the following command: echo 1 /sys/devices/pci:00/:00:02.0/rom cat /sys/devices/pci:00/:00:02.0/rom 4. attach the output of Xorg.0.log Thanks. Yakui. Andres -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: lvds downclocking breaks on G45/thinkpad T500
On Sun, 2009-12-27 at 22:18 +0800, Andres Freund wrote: On Sunday 27 December 2009 14:10:55 ykzhao wrote: On Sun, 2009-12-27 at 01:41 +0800, Andres Freund wrote: On Saturday 26 December 2009 17:49:29 Andres Freund wrote: On 2.6.33-rc1 I noticed that the display of my T500 with a G45 reacts very slowly (you can see the text appearing) and colors take a time to solidify. I.e. making a white terminal black takes some seconds. ... Anything I can do to help analyzing the issue? Thats with recent git checkouts of xorg btw, if thats relevant (which I doubt a bit). The missing config is attached now as well. It will be great if you can open a new bug on bugs.freedesktop.org(Product=xorg, component = driver/intel) and attach the following info: 1. add the boot option of drm.debug=0x06 and attach the output of dmesg. 2. attach the output of xrandr -q --verbose 3. attach the vbios.dump, which can be obtained by using the following command: echo 1 /sys/devices/pci:00/:00:02.0/rom cat /sys/devices/pci:00/:00:02.0/rom 4. attach the output of Xorg.0.log Is it relevant whether I boot a kernel with the patch really enabled? I don't know whether it is relevant with my patch. In fact my patch only checks whether the LVDS downclock is found and then set the corresponding flag. Anyway, please open a new bug and I will investigate it. thanks. Yakui Andres -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Disable all the possibles output/crtcs before entering KMS mode
On Sat, 2009-12-05 at 06:22 +0800, Rafał Miłecki wrote: 2009/12/4 Dave Airlie airl...@redhat.com: On Fri, 2009-12-04 at 20:05 +0800, yakui.z...@intel.com wrote: From: Zhao Yakui yakui.z...@intel.com Disable all the possible outputs/crtcs before entering KMS mode. We need a bit more info than this for such a large change? At one point we wanted to do smooth startup for LVDS panels, so that we read back the mode and avoided reconfiguring them this sort of change would totally go against it. Also I thought Arjan wanted to avoid slowdowns on startup, which I would expect this to add to. We have something like drm_disable_unused_functions. Isn't that supposed to make what you introduce there? At least at KMS booting when we don't have encoders/crtcs/outputs configured it should work for that. Am I wrong? Yes. Your are right. The main purpose of this function is to put all the outputs/crtcs into the known state. In fact this function can also be called in course of suspend/resume. Before we have the encoder/crts/output configuration, the drm_helper_disable_unused_functions can also put all the outputs/crtcs into the known state. But after we build the connection between encoder/crtcs/output, the function of drm_helper_disable_unused_functions can only disable the unused crtc/output. Thanks. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 1/4] DRM: Add the default mode table
On Thu, 2009-09-03 at 09:33 +0800, Zhao, Yakui wrote:
From: Zhao Yakui yakui.z...@intel.com
When we add a standard timing mode in UMS, we will first check whether it can
be found in default mode table. If it can't be found, then we will use cvt/gtf
to add the standard timing mode.
Add the default mode table so that we can check whether the given mode
can be found in the default mode table as what we have done in UMS mode.
If the status of one output device is connected but there is no EDID, it will
have no correct mode. In such case we can add some default modes for it. Of
course we only add the modes in the default modes list that visible part is
not
greater than 1024x768.
The default mode is autogenerated from the DMT spec. And it is copied from
xserver/hw/xfree86/modes/xf86EdidModes.c. But the mode with reduced blank
feature is removed.
Hi, Dave
Can you please review this patch set and see whether it can be
picked up?
Thanks.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/drm_edid.c | 237
+
1 file changed, 237 insertions(+)
Index: linux-2.6/drivers/gpu/drm/drm_edid.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_edid.c 2009-09-03 08:56:50.0
+0800
+++ linux-2.6/drivers/gpu/drm/drm_edid.c 2009-09-03 08:57:18.0
+0800
@@ -243,6 +243,243 @@
preferred_mode-type |= DRM_MODE_TYPE_PREFERRED;
}
+/*
+ * Add the Autogenerated from the DMT spec.
+ * This table is copied from xfree86/modes/xf86EdidModes.c.
+ * But the mode with Reduced blank feature is deleted.
+ */
+static struct drm_display_mode drm_dmt_modes[] = {
+ /* 640x...@85hz */
+ { DRM_MODE(640x350, DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
+736, 832, 0, 350, 382, 385, 445, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 640x...@85hz */
+ { DRM_MODE(640x400, DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
+736, 832, 0, 400, 401, 404, 445, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 720x...@85hz */
+ { DRM_MODE(720x400, DRM_MODE_TYPE_DRIVER, 35500, 720, 756,
+828, 936, 0, 400, 401, 404, 446, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 640x...@60hz */
+ { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
+752, 800, 0, 480, 489, 492, 525, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 640x...@72hz */
+ { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
+704, 832, 0, 480, 489, 492, 520, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 640x...@75hz */
+ { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 31500, 640, 656,
+720, 840, 0, 480, 481, 484, 500, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 640x...@85hz */
+ { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 36000, 640, 696,
+752, 832, 0, 480, 481, 484, 509, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 800x...@56hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 36000, 800, 824,
+896, 1024, 0, 600, 601, 603, 625, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 800x...@60hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 4, 800, 840,
+968, 1056, 0, 600, 601, 605, 628, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 800x...@72hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 5, 800, 856,
+976, 1040, 0, 600, 637, 643, 666, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 800x...@75hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 49500, 800, 816,
+896, 1056, 0, 600, 601, 604, 625, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 800x...@85hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 56250, 800, 832,
+896, 1048, 0, 600, 601, 604, 631, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 848x...@60hz */
+ { DRM_MODE(848x480, DRM_MODE_TYPE_DRIVER, 33750, 848, 864,
+976, 1088, 0, 480, 486, 494, 517, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 1024x...@43hz, interlace */
+ { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 44900, 1024, 1032,
+1208, 1264, 0, 768, 768, 772, 817, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+ DRM_MODE_FLAG_INTERLACE) },
+ /* 1024x...@60hz */
+ { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 65000, 1024, 1048,
+1184, 1344, 0, 768, 771, 777, 806, 0,
+DRM_MODE_FLAG_NHSYNC |
Re: [Patch 4/4] DRM/I915: Add the default mode for CRT output without EDID
On Thu, 2009-09-03 at 09:39 +0800, Dave Airlie wrote:
On Thu, 2009-09-03 at 09:33 +0800, yakui.z...@intel.com wrote:
From: Zhao Yakui yakui.z...@intel.com
Add the default mode for the CRT output without EDID. But we only add the
mode
which visible part is equal to or less than 1024x768.
Use 800x600 as the default mode for consistency with X sake, this case
should be handled by the main drm code when it finds no modes anyways,
it possibly should be done in a helper
Your propose seems better. When one output device is connected but there
is no mode, we can add some default modes for it. How about the
following patch?
If so, we will add the default mode for every output device when there
is no mode for it.
---
drivers/gpu/drm/drm_crtc_helper.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/gpu/drm/drm_crtc_helper.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_crtc_helper.c2009-09-03
14:25:16.0 +0800
+++ linux-2.6/drivers/gpu/drm/drm_crtc_helper.c 2009-09-03
14:27:51.0 +0800
@@ -109,8 +109,11 @@
}
count = (*connector_funcs-get_modes)(connector);
- if (!count)
- return 0;
+ if (!count) {
+ count = drm_add_modes_noedid(connector, 800, 600);
+ if (!count)
+ return 0;
+ }
drm_mode_connector_list_update(connector);
Dave.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/intel_crt.c |8
1 file changed, 8 insertions(+)
Index: linux-2.6/drivers/gpu/drm/i915/intel_crt.c
===
--- linux-2.6.orig/drivers/gpu/drm/i915/intel_crt.c 2009-09-03
08:56:50.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/intel_crt.c 2009-09-03
09:28:35.0 +0800
@@ -458,6 +458,14 @@
intel_i2c_destroy(ddcbus);
end:
+ if (!ret) {
+ /*
+* when there is no EDID, add some default modes.
+* But the hdisplay should not be greater than 1024.
+* the vdisplay should not be greater than 768
+*/
+ ret = drm_add_modes_noedid(connector, 1024, 768);
+ }
return ret;
}
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux 2.6.31-rc7
On Wed, 2009-08-26 at 11:58 +0800, Zhenyu Wang wrote: Hi From the config file it seems that the CONFIG_FRAMEBUFFER_CONSOLE is set as m. Will you please set it to y and see whether the black screen happens? Thanks. Yakui On 2009.08.25 20:33:32 -0700, Linus Torvalds wrote: On Wed, 26 Aug 2009, Zhenyu Wang wrote: In my experience, the BIOS setup doesn't reflect what outputs should be used at runtime, and certainly not the correct configuration of the enabled outputs. For example, if we went to this, the giant monitor attached to my laptop that I actually look at would go unused. yeah, normally VBIOS startup just needs or only can driver one pipe, so we don't have any pre knowledge except detect everything. Umm. What's your guys point, exactly? We can't depend on any BIOS display config as you noted before our driver. And our driver does more flexible config than VBIOS does. The fact is, as-is, YOU DETECT THE WRONG OUTPUTS! If you actually detected things _right_, none of this would be an issue. But you don't. And you seem to have a really hard time even admitting that. You try to re-detect things, and you SCREW UP. We know we have problem on Mac mini, this issue has been known for a while. And Keith also posted patch at http://lists.freedesktop.org/archives/intel-gfx/2009-June/002843.html but I don't know the status of this now. we already have some mac relate bugs open, but please report on it so we do have people with hardware to try and response. We have recently got a MacBook, yakui is looking after the modesetting issue on it. Quite frankly, I've reported these things several times. I've been open to try patches. Nothing has ever come out of it. I have a Mac Mini that I reported as broken over a month ago. I have a Westemere I've reported as not doing any DDC probing - and that I have to disable the LVDS probing on entirely in order to not make KMS set up the display to go to a non-existent LVDS port. You claim that you detect everything, but quite frankly, you don't. The KMS code seems to assume that if it's a mobile chipset, it should have an LVDS output - and whether anything is connected to that or not is totally immaterial. There's clearly _zero_ detection going on. We've tried many ways to detect LVDS, but none is stable or actually work for every chip. But now we have DMI quirks for some known no LVDS machine (including Mac mini), and we detect through ACPI LID object for LVDS exist. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH resend] drm/i915: Add support for dual-channel LVDS on 8xx.
On Thu, 2009-08-20 at 04:28 +0800, Bruno Prémont wrote:
drm/i915: Check if BIOS enabled dual-channel LVDS on 8xx, not only on 9xx
Commit 0c2e39525b3b53a97a0202c5f35058147e53977e is not sufficient to
get fd.o bug #20115 fixed.
In addition intel_find_best_PLL() must not only rely on BIOS settings
for i9xx chips but also for i8xx, so drop the IS_I9XX() check.
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
Agree. We should also check whether the dual-channel is enabled on the
8xx platform.
Acked-by: Zhao Yakui yakui.z...@intel.com
--
Hi Eric, Ma Ling,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0c2e39525b3b53a97a0202c5f35058147e53977e
(drm/i915: Add support for dual-channel LVDS on 8xx.) is not sufficient
for i8xx, below patch is needed too for LVDS to work on my Acer TM66x.
In case this is not appropriate for newer chips replacing IS_I9XX(dev)
with (IS_I9XX(dev) || IS_I85X(dev)) would be sufficient for me though
other i8xx variants would possibly need to be added too/later on.
Bruno
--
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d6fce21..486bdaf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -666,7 +666,7 @@ intel_find_best_PLL(const intel_limit_t *limit, struct
drm_crtc *crtc,
intel_clock_t clock;
int err = target;
- if (IS_I9XX(dev) intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)
(I915_READ(LVDS)) != 0) {
/*
* For LVDS, if the panel is on, just rely on its
current
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/4] DRM: Remove the unused prefix in DRM_DEBUG_KMS/DRIVER/MODE
On Thu, 2009-07-30 at 08:42 +0800, ykzhao wrote:
On Mon, 2009-07-20 at 13:48 +0800, Zhao, Yakui wrote:
Hi, Dave
How about this patch set?
Before it is shipped, we can't use the DRM_DEBUG_KMS/DRIVER to add
the debug info.
Hi, Dave
Any comments about this patch set?
Before it is shipped, we can't use the updated DRM_DEBUG_KMS/DRIVER
macro definition to add the debug info. In such case we can't get the
debug info related with KMS and it is difficult to debug the issue
related with KMS.
Thanks.
thanks.
From: Zhao Yakui yakui.z...@intel.com
We will have to add a prefix when using the macro defintion of DRM_DEBUG_KMS
/DRM_DEBUG_DRIVER/MODE. It is not convenient. We should use the DRM_NAME
as default prefix.
So remove the prefix in the macro definition of DRM_DEBUG_KMS/DRIVER/MODE.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Acked-by: Ian Romanick ian.d.roman...@intel.com
---
drivers/gpu/drm/drm_modes.c |8 +++-
drivers/gpu/drm/i915/i915_dma.c | 35
+++
drivers/gpu/drm/i915/intel_lvds.c | 10 +++---
drivers/gpu/drm/i915/intel_sdvo.c | 31 ++-
include/drm/drmP.h| 18 +-
5 files changed, 44 insertions(+), 58 deletions(-)
Index: linux-2.6/include/drm/drmP.h
===
--- linux-2.6.orig/include/drm/drmP.h 2009-07-16 13:53:24.0 +0800
+++ linux-2.6/include/drm/drmP.h2009-07-16 13:53:38.0 +0800
@@ -174,19 +174,19 @@
__func__, fmt, ##args); \
} while (0)
-#define DRM_DEBUG_DRIVER(prefix, fmt, args...) \
+#define DRM_DEBUG_DRIVER(fmt, args...) \
do {\
- drm_ut_debug_printk(DRM_UT_DRIVER, prefix, \
+ drm_ut_debug_printk(DRM_UT_DRIVER, DRM_NAME,\
__func__, fmt, ##args); \
} while (0)
-#define DRM_DEBUG_KMS(prefix, fmt, args...)\
+#define DRM_DEBUG_KMS(fmt, args...)\
do {\
- drm_ut_debug_printk(DRM_UT_KMS, prefix, \
+ drm_ut_debug_printk(DRM_UT_KMS, DRM_NAME, \
__func__, fmt, ##args);\
} while (0)
-#define DRM_DEBUG_MODE(prefix, fmt, args...) \
+#define DRM_DEBUG_MODE(fmt, args...) \
do {\
- drm_ut_debug_printk(DRM_UT_MODE, prefix,\
+ drm_ut_debug_printk(DRM_UT_MODE, DRM_NAME, \
__func__, fmt, ##args);\
} while (0)
#define DRM_LOG(fmt, args...) \
@@ -210,9 +210,9 @@
NULL, fmt, ##args); \
} while (0)
#else
-#define DRM_DEBUG_DRIVER(prefix, fmt, args...) do { } while (0)
-#define DRM_DEBUG_KMS(prefix, fmt, args...)do { } while (0)
-#define DRM_DEBUG_MODE(prefix, fmt, args...) do { } while (0)
+#define DRM_DEBUG_DRIVER(fmt, args...) do { } while (0)
+#define DRM_DEBUG_KMS(fmt, args...)do { } while (0)
+#define DRM_DEBUG_MODE(fmt, args...) do { } while (0)
#define DRM_DEBUG(fmt, arg...) do { } while (0)
#define DRM_LOG(fmt, arg...) do { } while (0)
#define DRM_LOG_KMS(fmt, args...) do { } while (0)
Index: linux-2.6/drivers/gpu/drm/drm_modes.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_modes.c 2009-07-16
13:53:24.0 +0800
+++ linux-2.6/drivers/gpu/drm/drm_modes.c 2009-07-16
13:53:38.0 +0800
@@ -38,7 +38,6 @@
#include drm.h
#include drm_crtc.h
-#define DRM_MODESET_DEBUG drm_mode
/**
* drm_mode_debug_printmodeline - debug print a mode
* @dev: DRM device
@@ -51,8 +50,8 @@
*/
void drm_mode_debug_printmodeline(struct drm_display_mode *mode)
{
- DRM_DEBUG_MODE(DRM_MODESET_DEBUG,
- Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d 0x%x
0x%x\n,
+ DRM_DEBUG_MODE(Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d
+ 0x%x 0x%x\n,
mode-base.id, mode-name, mode-vrefresh, mode-clock,
mode-hdisplay, mode-hsync_start,
mode-hsync_end, mode-htotal,
@@ -403,8 +402,7 @@
list_del(mode-head);
if (verbose
Re: [PATCH 1/4] DRM: Remove the unused prefix in DRM_DEBUG_KMS/DRIVER/MODE
On Mon, 2009-07-20 at 13:48 +0800, Zhao, Yakui wrote:
Hi, Dave
How about this patch set?
Before it is shipped, we can't use the DRM_DEBUG_KMS/DRIVER to add
the debug info.
thanks.
From: Zhao Yakui yakui.z...@intel.com
We will have to add a prefix when using the macro defintion of DRM_DEBUG_KMS
/DRM_DEBUG_DRIVER/MODE. It is not convenient. We should use the DRM_NAME
as default prefix.
So remove the prefix in the macro definition of DRM_DEBUG_KMS/DRIVER/MODE.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Acked-by: Ian Romanick ian.d.roman...@intel.com
---
drivers/gpu/drm/drm_modes.c |8 +++-
drivers/gpu/drm/i915/i915_dma.c | 35 +++
drivers/gpu/drm/i915/intel_lvds.c | 10 +++---
drivers/gpu/drm/i915/intel_sdvo.c | 31 ++-
include/drm/drmP.h| 18 +-
5 files changed, 44 insertions(+), 58 deletions(-)
Index: linux-2.6/include/drm/drmP.h
===
--- linux-2.6.orig/include/drm/drmP.h 2009-07-16 13:53:24.0 +0800
+++ linux-2.6/include/drm/drmP.h2009-07-16 13:53:38.0 +0800
@@ -174,19 +174,19 @@
__func__, fmt, ##args); \
} while (0)
-#define DRM_DEBUG_DRIVER(prefix, fmt, args...) \
+#define DRM_DEBUG_DRIVER(fmt, args...) \
do {\
- drm_ut_debug_printk(DRM_UT_DRIVER, prefix, \
+ drm_ut_debug_printk(DRM_UT_DRIVER, DRM_NAME,\
__func__, fmt, ##args); \
} while (0)
-#define DRM_DEBUG_KMS(prefix, fmt, args...)\
+#define DRM_DEBUG_KMS(fmt, args...)\
do {\
- drm_ut_debug_printk(DRM_UT_KMS, prefix, \
+ drm_ut_debug_printk(DRM_UT_KMS, DRM_NAME, \
__func__, fmt, ##args);\
} while (0)
-#define DRM_DEBUG_MODE(prefix, fmt, args...) \
+#define DRM_DEBUG_MODE(fmt, args...) \
do {\
- drm_ut_debug_printk(DRM_UT_MODE, prefix,\
+ drm_ut_debug_printk(DRM_UT_MODE, DRM_NAME, \
__func__, fmt, ##args);\
} while (0)
#define DRM_LOG(fmt, args...) \
@@ -210,9 +210,9 @@
NULL, fmt, ##args); \
} while (0)
#else
-#define DRM_DEBUG_DRIVER(prefix, fmt, args...) do { } while (0)
-#define DRM_DEBUG_KMS(prefix, fmt, args...)do { } while (0)
-#define DRM_DEBUG_MODE(prefix, fmt, args...) do { } while (0)
+#define DRM_DEBUG_DRIVER(fmt, args...) do { } while (0)
+#define DRM_DEBUG_KMS(fmt, args...)do { } while (0)
+#define DRM_DEBUG_MODE(fmt, args...) do { } while (0)
#define DRM_DEBUG(fmt, arg...) do { } while (0)
#define DRM_LOG(fmt, arg...) do { } while (0)
#define DRM_LOG_KMS(fmt, args...) do { } while (0)
Index: linux-2.6/drivers/gpu/drm/drm_modes.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_modes.c 2009-07-16 13:53:24.0
+0800
+++ linux-2.6/drivers/gpu/drm/drm_modes.c 2009-07-16 13:53:38.0
+0800
@@ -38,7 +38,6 @@
#include drm.h
#include drm_crtc.h
-#define DRM_MODESET_DEBUG drm_mode
/**
* drm_mode_debug_printmodeline - debug print a mode
* @dev: DRM device
@@ -51,8 +50,8 @@
*/
void drm_mode_debug_printmodeline(struct drm_display_mode *mode)
{
- DRM_DEBUG_MODE(DRM_MODESET_DEBUG,
- Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d 0x%x
0x%x\n,
+ DRM_DEBUG_MODE(Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d
+ 0x%x 0x%x\n,
mode-base.id, mode-name, mode-vrefresh, mode-clock,
mode-hdisplay, mode-hsync_start,
mode-hsync_end, mode-htotal,
@@ -403,8 +402,7 @@
list_del(mode-head);
if (verbose) {
drm_mode_debug_printmodeline(mode);
- DRM_DEBUG_MODE(DRM_MODESET_DEBUG,
- Not using %s mode %d\n,
+ DRM_DEBUG_MODE(Not using %s mode %d\n,
mode-name, mode-status);
}
drm_mode_destroy(dev, mode);
Index:
