mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
	Zhao Yakui <yakui.zhao@intel.com>, Eric Anholt <eric@anholt.net>
Subject: [20/29] drm/i915: Read the response after issuing DDC bus switch command
Date: Fri, 22 Jan 2010 16:10:04 -0800	[thread overview]
Message-ID: <20100123001112.769683534@mini.kroah.org> (raw)
In-Reply-To: <20100123001145.GA7391@kroah.com>

2.6.32-stable review patch.  If anyone has any objections, please let us know.

------------------

From: Zhao Yakui <yakui.zhao@intel.com>

commit 6a304caf0bf9c429fc261f260b86cabf5bde2cbb upstream.

For some SDVO cards based on conexant chip, we can't read the EDID if
we don't read the response after issuing SDVO DDC bus switch
command.

>From the SDVO spec once when another I2C transaction is finished after
completing the I2C transaction of issuing the bus switch command, it
will be switched back to the SDVO internal state again. So we can't
initiate a new I2C transaction to read the response after issuing the
DDC bus switch command. Instead we should issue DDC bus switch command
and read the response in the same I2C transaction.

https://bugs.freedesktop.org/show_bug.cgi?id=23842
https://bugs.freedesktop.org/show_bug.cgi?id=24458
https://bugs.freedesktop.org/show_bug.cgi?id=24522
https://bugs.freedesktop.org/show_bug.cgi?id=24282

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/gpu/drm/i915/intel_sdvo.c |   57 +++++++++++++++++++++++++++++++++++---
 1 file changed, 53 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -472,14 +472,63 @@ static int intel_sdvo_get_pixel_multipli
 }
 
 /**
- * Don't check status code from this as it switches the bus back to the
- * SDVO chips which defeats the purpose of doing a bus switch in the first
- * place.
+ * Try to read the response after issuie the DDC switch command. But it
+ * is noted that we must do the action of reading response and issuing DDC
+ * switch command in one I2C transaction. Otherwise when we try to start
+ * another I2C transaction after issuing the DDC bus switch, it will be
+ * switched to the internal SDVO register.
  */
 static void intel_sdvo_set_control_bus_switch(struct intel_output *intel_output,
 					      u8 target)
 {
-	intel_sdvo_write_cmd(intel_output, SDVO_CMD_SET_CONTROL_BUS_SWITCH, &target, 1);
+	struct intel_sdvo_priv *sdvo_priv = intel_output->dev_priv;
+	u8 out_buf[2], cmd_buf[2], ret_value[2], ret;
+	struct i2c_msg msgs[] = {
+		{
+			.addr = sdvo_priv->slave_addr >> 1,
+			.flags = 0,
+			.len = 2,
+			.buf = out_buf,
+		},
+		/* the following two are to read the response */
+		{
+			.addr = sdvo_priv->slave_addr >> 1,
+			.flags = 0,
+			.len = 1,
+			.buf = cmd_buf,
+		},
+		{
+			.addr = sdvo_priv->slave_addr >> 1,
+			.flags = I2C_M_RD,
+			.len = 1,
+			.buf = ret_value,
+		},
+	};
+
+	intel_sdvo_debug_write(intel_output, SDVO_CMD_SET_CONTROL_BUS_SWITCH,
+					&target, 1);
+	/* write the DDC switch command argument */
+	intel_sdvo_write_byte(intel_output, SDVO_I2C_ARG_0, target);
+
+	out_buf[0] = SDVO_I2C_OPCODE;
+	out_buf[1] = SDVO_CMD_SET_CONTROL_BUS_SWITCH;
+	cmd_buf[0] = SDVO_I2C_CMD_STATUS;
+	cmd_buf[1] = 0;
+	ret_value[0] = 0;
+	ret_value[1] = 0;
+
+	ret = i2c_transfer(intel_output->i2c_bus, msgs, 3);
+	if (ret != 3) {
+		/* failure in I2C transfer */
+		DRM_DEBUG_KMS("I2c transfer returned %d\n", ret);
+		return;
+	}
+	if (ret_value[0] != SDVO_CMD_STATUS_SUCCESS) {
+		DRM_DEBUG_KMS("DDC switch command returns response %d\n",
+					ret_value[0]);
+		return;
+	}
+	return;
 }
 
 static bool intel_sdvo_set_target_input(struct intel_output *intel_output, bool target_0, bool target_1)



  parent reply	other threads:[~2010-01-23  0:21 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-23  0:11 [00/29] 2.6.32.6 stable review Greg KH
2010-01-23  0:09 ` [01/29] x86, msr/cpuid: Register enough minors for the MSR and CPUID drivers Greg KH
2010-01-23  0:09 ` [02/29] V4L/DVB (13900): gspca - sunplus: Fix bridge exchanges Greg KH
2010-01-23  0:09 ` [03/29] Staging: asus_oled: fix oops in 2.6.32.2 Greg KH
2010-01-23  0:09 ` [04/29] Staging: hv: fix smp problems in the hyperv core code Greg KH
2010-01-23  0:09 ` [05/29] tty: fix race in tty_fasync Greg KH
2010-01-23  0:09 ` [06/29] ecryptfs: use after free Greg KH
2010-01-23  0:09 ` [07/29] ecryptfs: initialize private persistent file before dereferencing pointer Greg KH
2010-01-23  0:09 ` [08/29] nozomi: quick fix for the close/close bug Greg KH
2010-01-23  0:09 ` [09/29] serial: 8250_pnp: use wildcard for serial Wacom tablets Greg KH
2010-01-23  0:09 ` [10/29] usb: serial: fix memory leak in generic driver Greg KH
2010-01-23  0:09 ` [11/29] USB: fix bitmask merge error Greg KH
2010-01-23  0:09 ` [12/29] USB: Dont use GFP_KERNEL while we cannot reset a storage device Greg KH
2010-01-23  0:09 ` [13/29] USB: EHCI: fix handling of unusual interrupt intervals Greg KH
2010-01-23  0:09 ` [14/29] USB: EHCI & UHCI: fix race between root-hub suspend and port resume Greg KH
2010-01-23  0:09 ` [15/29] USB: add missing delay during remote wakeup Greg KH
2010-01-23  0:10 ` [16/29] USB: add speed values for USB 3.0 and wireless controllers Greg KH
2010-01-23  0:10 ` [17/29] ACPI: EC: Accelerate query execution Greg KH
2010-01-23  0:10 ` [18/29] ACPI: EC: Add wait for irq storm Greg KH
2010-01-23  0:10 ` [19/29] SCSI: enclosure: fix oops while iterating enclosure_status array Greg KH
2010-01-23  0:10 ` Greg KH [this message]
2010-01-23  0:10 ` [21/29] drm/i915: try another possible DDC bus for the SDVO device with multiple outputs Greg KH
2010-01-23  0:10 ` [22/29] block: bdev_stack_limits wrapper Greg KH
2010-01-23  0:10 ` [23/29] DM: Fix device mapper topology stacking Greg KH
2010-01-23  0:10 ` [24/29] x86/PCI/PAT: return EINVAL for pci mmap WC request for !pat_enabled Greg KH
2010-01-23  0:10 ` [25/29] USB: fix usbstorage for 2770:915d delivers no FAT Greg KH
2010-01-23  2:43   ` [Stable-review] " Ben Hutchings
2010-01-23  6:05     ` Greg KH
2010-01-23  0:10 ` [26/29] vmalloc: remove BUG_ON due to racy counting of VM_LAZY_FREE Greg KH
2010-01-23  0:10 ` [27/29] perf timechart: Use tid not pid for COMM change Greg KH
2010-01-23  0:10 ` [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events Greg KH
2010-01-23 11:38   ` [Stable-review] " Stefan Bader
2010-01-23 15:33     ` Greg KH
2010-01-25 18:04     ` Greg KH
2010-01-23  0:10 ` [29/29] perf: Honour event state for aux stream data Greg KH
2010-01-24  7:21 ` [stable] [00/29] 2.6.32.6 stable review Andrew Morton
2010-01-24 16:29   ` Thomas Gleixner
2010-01-25  8:40     ` Ozan Çağlayan
2010-01-25 17:16       ` Greg KH
2010-01-25 17:39         ` Ozan Çağlayan
2010-01-25 17:46           ` Greg KH
2010-01-25 19:09             ` Greg KH
2010-01-25 18:22         ` Thomas Gleixner
2010-01-25 17:15     ` Greg KH

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=20100123001112.769683534@mini.kroah.org \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=eric@anholt.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=yakui.zhao@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®