Re: [Intel-gfx] [PATCH 2/4] drm/i915: Adding Panel Filter function for DP
On Wednesday 19 August 2015 09:11:11 Zhang, Xiong Y wrote: On Fri, Aug 14, 2015 at 07:28:44PM +0300, Ville Syrjälä wrote: Another thing we could do with this approach is expose the pipe PF-ID mode when the fixed mode is interlaced and the user mode is progressive. And if both are interlaced, or there's just an interlaced used mode w/o a fixed mode, we'd keep using IF-ID like we do today. [Zhang, Xiong Y] I checked the B spec, there isn't PF-ID / IF-ID control bit in PIPE_CONF since BDW. I never see a monitor supporting interlaced mode. Does a monitor could support both Interlaced and progressive mode ? Most of the computer monitors I see support interlaced modes on HDMI; I usually see CEA-861 VIC 5 (1920x1080i60) and VIC 20 (1920x1080i50) supported on HDMI by computer monitors. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Pageflip failure on SNB devices running 3.13.3
Hello, I'm seeing pageflips give up on me on SNB hardware - Celeron 847, i5-2400S - where the CRTC becomes unexpectedly busy and never recovers. When I'm failed, I can see interrupts coming in (Interrupts received in /sys/kernel/debug/dri/0/i915_gem_interrupt increments), but the queued flip never happens: # cat /sys/kernel/debug/dri/0/i915_gem_pageflip Flip queued on pipe A (plane A) Stall check enabled, 1 prepares Old framebuffer gtt_offset 0x01354000 New framebuffer gtt_offset 0x0093c000 No flip due on pipe B (plane B) # cat /sys/kernel/debug/dri/0/i915_gem_interrupt North Display Interrupt enable: 8eb48585 North Display Interrupt identity: North Display Interrupt mask: 734bfa7a South Display Interrupt enable: South Display Interrupt identity: South Display Interrupt mask: f114 Graphics Interrupt enable: 00401001 Graphics Interrupt identity: Graphics Interrupt mask: Interrupts received: 1006958 Graphics Interrupt mask (render ring): Current sequence (render ring): 1472838 Graphics Interrupt mask (bsd ring): Current sequence (bsd ring): 1271460 Graphics Interrupt mask (blitter ring): Current sequence (blitter ring): 1472839 I'm running packages from Fedora 20: # rpm -q mesa-libGL kernel xorg-x11-server-Xorg xorg-x11-drv-intel libva- intel-driver libdrm mesa-libGL-9.2.5-1.20131220.fc20.x86_64 kernel-3.13.3-201.fc20.x86_64 xorg-x11-server-Xorg-1.14.4-90.fc20.x86_64 xorg-x11-drv-intel-2.21.15-5.fc20.x86_64 libva-intel-driver-1.2.1-1.fc20.x86_64 libdrm-2.4.50-1.fc20.x86_64 I've put a dmesg from a failed system at http://90.155.96.198/sfarnsworth/flip-fail.txt - it's 11.3MB, so can't be attached. I've spotted the MCH_SSKPD message, but I also get the failures on systems that don't output that message. Any ideas? Or should I file a bug? -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Pageflip failure on SNB devices running 3.13.3
On Tuesday 25 February 2014 16:52:59 Chris Wilson wrote: On Tue, Feb 25, 2014 at 02:52:00PM +, Simon Farnsworth wrote: I've put a dmesg from a failed system at http://90.155.96.198/sfarnsworth/flip-fail.txt - it's 11.3MB, so can't be attached. I've spotted the MCH_SSKPD message, but I also get the failures on systems that don't output that message. Any ideas? Or should I file a bug? Let's capture as much as possible in a bug. Can you try the stall detection w/a (if it is not already enabled)? -Chris Filed as https://bugs.freedesktop.org/show_bug.cgi?id=75502 I'm not sure what you mean by stall detection w/a; I've not deliberately disabled anything, so it should be in its default state. We can follow through on the bug if there's something I need to turn on, though. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm: Add a helper to forge HDMI vendor infoframes
More typo fallout:
On Wednesday 14 August 2013 00:17:27 Damien Lespiau wrote:
This can then be used by DRM drivers to setup their vendor infoframes.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 36
include/drm/drm_edid.h | 4
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9a07a33..83e1202 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3262,3 +3262,39 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
return 0;
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
+
+/**
+ * drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI infoframe
with
+ * data from a DRM display mode
+ * @frame: HDMI vendor infoframe
+ * @mode: DRM display mode
+ *
+ * Note that there's is a need to send HDMI vendor infoframes only when
using a
+ * 4k or stereoscopic 3D mode. So when giving any other mode as input this
+ * function will return -EINVAL, error that can be safely ignored.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_hdmi_infoframe
*frame,
+ const struct drm_display_mode *mode)
+{
+ int err;
+ u8 vic;
+
+ if (!frame || !mode)
+ return -EINVAL;
+
+ vic = drm_match_hmdi_mode(mode);
Should be hdmi again.
+ if (!vic)
+ return -EINVAL;
+
+ err = hdmi_hdmi_infoframe_init(frame);
+ if (err 0)
+ return err;
+
+ frame-vic = vic;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
snip
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HDMI 4k support v2
On Wednesday 14 August 2013 00:17:16 Damien Lespiau wrote:
Following up the first instance of this series:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html
Here is a v2 with Ville's review pass and a few additions:
- Alternate clock modes for 4k resolutions
- HDMI vendor specific infoframe support in drivers/video/hdmi.c
- Enabling of those vendor specific infoframes in the i915 driver
Along the way, a tegra patch was needed for a small consolidation of the code
packing vendor specific infoframes. This patch has only been compile-tested.
On Intel, it's possible to read back the programmed infoframe buffers with
intel-gpu-tools' intel_infoframe and this gives:
Vendor InfoFrame:
- frequency: every vsync
- raw:
f4050181 000c0347 0320
004c
- vendor Id: 0x000c03 (HDMI)
- video format: 0x001
- HDMI VIC: 3
after a $ xrandr --output HDMI1 --mode 3840x2160 -r 24
With the typos fixed, feel free to add:
Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel_infoframes: Add support for decoding HDMI VICs
Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
On Wednesday 14 August 2013 00:19:14 Damien Lespiau wrote:
The HDMI vendor infoframe can contain a HDMI VIC (as of HDMI 1.4, only
used for 4k formats).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
tools/intel_infoframes.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/tools/intel_infoframes.c b/tools/intel_infoframes.c
index 09fdcb9..b6d289f 100644
--- a/tools/intel_infoframes.c
+++ b/tools/intel_infoframes.c
@@ -184,8 +184,13 @@ typedef union {
uint8_t Rsvd0:5;
uint8_t video_format :3;
- uint8_t Rsvd1 :4;
- uint8_t s3d_structure :4;
+ union {
+ uint8_t vic;
+ struct {
+ uint8_t Rsvd1 :4;
+ uint8_t s3d_structure :4;
+ } s3d;
+ } pb5;
uint8_t Rsvd2:4;
uint8_t s3d_ext_data :4;
@@ -467,13 +472,26 @@ static const char *s3d_structure_to_string(int format)
static void dump_vendor_hdmi(DipInfoFrame *frame)
{
+ int vic_present = frame-vendor.video_format 0x1;
int s3d_present = frame-vendor.video_format 0x2;
printf(- video format: 0x%03x %s\n, frame-vendor.video_format,
s3d_present ? (3D) : );
- if (s3d_present)
+
+ if (vic_present s3d_present) {
+ printf(Error: HDMI VIC and S3D bits set. Only one of those
+ at a time is valid\n);
+ return;
+ }
+
+ if (vic_present)
+ printf(- HDMI VIC: %d\n, frame-vendor.pb5.vic);
+ else if (s3d_present) {
+ int s3d_structure = frame-vendor.pb5.s3d.s3d_structure;
+
printf(- 3D Format: %s\n,
-s3d_structure_to_string(frame-vendor.s3d_structure));
+s3d_structure_to_string(s3d_structure));
+ }
}
static void dump_vendor_info(Transcoder transcoder)
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/edid: Parse the HDMI CEA block and look for 4k modes
Minor typo - feel free to ignore:
On Wednesday 14 August 2013 00:17:19 Damien Lespiau wrote:
HDMI 1.4 adds 4 4k x 2k modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the 4096x2160 string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
relative to the end of the required fields of the HDMI VSDB
(Ville Syrjälä)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Tested-by: Cancan Feng cancan.f...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
---
drivers/gpu/drm/drm_edid.c | 124
+++--
1 file changed, 109 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e9b6ed..0faa08e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
snip
@@ -2465,6 +2495,68 @@ do_cea_modes(struct drm_connector *connector, const u8
*db, u8 len)
return modes;
}
+/*
+ * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
+ * @connector: connector corresponding to the HDMI sink
+ * @db: start of the CEA vendor specific block
+ * @len: length of the CEA block payload, ie. one can access up to db[len]
+ *
+ * Parses the HDMI VSDB looking for modes to add to @connector.
+ */
+static int
+do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
+{
+ struct drm_device *dev = connector-dev;
+ int modes = 0, offset = 0, i;
+ u8 vic_len;
+
+ if (len 8)
+ goto out;
+
+ /* no HDMI_Video_Present */
+ if (!(db[8] (1 5)))
+ goto out;
+
+ /* Latency_Fields_Present */
+ if (db[8] (1 7))
+ offset += 2;
+
+ /* I_Latency_Fields_Present */
+ if (db[8] (1 6))
+ offset += 2;
+
+ /* the declared length is not long enough for the 2 first bytes
+ * of additional video format capabilities */
+ offset += 2;
+ if (len (8 + offset))
+ goto out;
+
+ vic_len = db[8 + offset] 5;
+
+ for (i = 0; i vic_len len = (9 + offset + i); i++) {
+ struct drm_display_mode *newmode;
+ u8 vic;
+
+ vic = db[9 + offset + i];
+
+ vic--; /* VICs start at 1 */
+ if (vic = ARRAY_SIZE(edid_4k_modes)) {
+ DRM_ERROR(Unknow HDMI VIC: %d\n, vic);
^^
Missing n - should be Unknown
+ continue;
+ }
+
+ newmode = drm_mode_duplicate(dev, edid_4k_modes[vic]);
+ if (!newmode)
+ continue;
+
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+
+out:
+ return modes;
+}
+
static int
cea_db_payload_len(const u8 *db)
{
snip
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
On Thursday 1 November 2012 09:58:51 Jesse Barnes wrote: On Thu, 01 Nov 2012 16:52:05 + Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk wrote: On Thursday 01 November 2012 16:20:03 Chris Wilson wrote: On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 01 Nov 2012 15:52:23 + Chris Wilson ch...@chris-wilson.co.uk wrote: Actually I've justified the blocking here to myself, and prefer it to simply running the crtc-unpin_work. If userspace is swamping the system so badly that we can run the kthreads quick enough, it deserves a stall. Note that the unpin leak is still about the 3rd most common bug in fedora, so this stall will be forced on many machines. Hm funky, why does Fedora hit it so much? Does some of the GNOME shell stuff run unthrottled or something? I don't think so. I trust that in Tvrtko's use case, he is not so much as hogging the GPU as keeping the system as a whole relatively busy. So I suspect it is more to do with CPU starvation of the kthreads than anything else. Tvrtko, do you have any feeling for why your machine was easily suspectible to this leak? Are the stalls noticeable and do they affect your performance targets? We didn't bother looking for any stalls, but for a long time we were occasionally hitting this pin_count BUG i915_gem_object_pin. So it didn't in fact affect our performance targets as much it completely wrecked our system. If this patch causes an occasional stall instead, given that this bug triggers every 3-4 hours of uptime, we are fine with that. If a frame or so is missed every couple hours on low end hardware we don't care that much. More on the actual workload... Only recently we got lucky and found a platform and workload where it happens reliably. And this patch reliably fixes that. In this workload CPU is being loaded 50-60% decoding a movie and rendering it to a full screen window. Our proprietary compositor page flips at 60Hz only, not faster. Together with another small semi-transparent window being rendered on top of the full screen movie. Movie played is a 25fps one, which means the full screen window is damaged 25 out of 60 frames (give or take) which is when we render to our back buffer and page flip at the vsync rate (60Hz). According to intel_gpu_top tool, GPU load is roughly at 40%, apart from the Framebuffer Compression metric which is maxed out, if that is one is at all valid. This particular scenario triggers the bug only on two of our Atom based platform both with a NM10/Pineview G/i915 chipset. Ah ok on Atom you're probably CPU constrained a bit, but still at 50-60% utilization the kthreads should be running at least sometimes... But it sounds like a case of the kthreads not running instead of queueing too fast anyway (not that the latter is really possible without some hacking to the flip code). It may help you here to know that we run both our compositor and the X server at real-time priorities - both are SCHED_RR static priority 1 (the lowest realtime priority). IIRC, the kthreads run at SCHED_OTHER priority, so we are quite capable of starving them during a burst of activity. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] GPU RC6 breaks PCIe to PCI bridge connected to CPU PCIe slot on SandyBridge systems
On Friday 19 October 2012 16:26:08 Daniel Vetter wrote: On Fri, Oct 19, 2012 at 12:26 PM, Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: Hello, I've just been trying to work out why a PCIe to PCI bridge worked with kernel 3.3, but not with kernel 3.5 or Linus's git master. I bisected down to bad: [aa46419186992e6b8b8010319f0ca7f40a0d13f5] drm/i915: enable plain RC6 on Sandy Bridge by default. I then confirmed that on a failing kernel (3.5 or Linus git 8d2b6b3ae280dcf6f6c7a95623670a57cdf562ed from Tuesday 16th, Merge tag 'sh- for-linus' of git://github.com/pmundt/linux-sh), I can make the failure disappear by adding i915.i915_enable_rc6=0 to the kernel command line, and I can make it reappear by changing the value of i915_enable_rc6 to -1. I've attached lspci -vvx output from a failure case and from a working case as lspci.faulty and lspci.working; if you need anything more, just ask for it. My hardware is an Intel DH67CF motherboard, with an i3-2100 CPU; there is a Startech branded PCIe to PCI bridge in the PCIe x16 slot (which I believe is connected to the CPU PCIe lanes, not the PCH PCIe lanes). I have a Hauppauge HVR-1110 in the PCI slot provided by the bridge. I have two test cases; one is transferring MPEG-2 transport streams from the DVB-T tuner on the card (no graphics involved), the other is using the V4L2 interface to capture buffers via the mmap() mechanism, which are then uploaded to the XServer via the Xv extension, and composited using an OpenGL compositor that uses texture_from_pixmap. Ok, this is really freaky stuff. One thing to triage: Is it just sufficient to put the gpu into rc6 to corrupt the dma transfers, or is some light X/gpu load required? In either case, rc6 being able to corrupt random dma transfers (or at least prevent them from reaching their destination) would be a fitting explanation for the leftover rc6 issues on snb ... In an attempt to have this happen with the GPU as idle as possible, I did the following (note that I'm on a gigabit Ethernet segment, so I can burn network bandwidth while testing): 1. Start X.org with -noreset, and don't start any X clients. 2. Run xset dpms force off ; xrandr --output DP2 --off (DP2 is the connected output). 3. On the affected machine, run gst-launch v4l2src ! gdppay ! tcpclientsink host=f17simon port=65512 4. On my desktop, run gst-launch tcpserversrc host=0.0.0.0 port=65512 ! gdpdepay ! xvimagesink I see the corruption continue to happen, even though the GPU should be idle and in RC6 state most of the time (confirmed by reading /sys/class/drm/card0/power/rc6_residency_ms and seeing it increase between reads). When I run intel_forcewaked from intel_gpu_tools, the corruption goes away, and I can confirm by reading /sys/class/drm/card0/power/rc6_residency_ms that the GPU does not enter RC6. Killing intel_forcewaked makes the corruption reappear while streaming over the network (X11 idle). -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix sdvo hotplug support check and activation
(apologies to Daniel and Jani, who've seen this twice - I accidentally sent it from the wrong address originally). On Wednesday 29 August 2012 16:43:58 Jani Nikula wrote: The sdvo hotplug support check and activation has worked by coincidence for TMDS0. The boolean value returned by intel_sdvo_supports_hotplug() was masked with a bit shifted by device number, which also should have been one of SDVO_OUTPUT_* bits instead. Boolean true masked with 1 shifted by 0 just happened to match SDVO_OUTPUT_TMDS0... Get hotplug support as a bit mask, check the correct bits for support, and use the correct bits for activating hotplug support. Signed-off-by: Jani Nikula jani.nik...@intel.com Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.com The code you're fixing was written with the aid of ajax's educated guesses - it's nice to see an Intel employee fix it to match the spec. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv5] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Tuesday 20 September 2011, Keith Packard kei...@keithp.com wrote: On Tue, 20 Sep 2011 18:31:25 +0100, Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: + /* Set up hotplug command - note paranoia about contents of reply. +* We simply clear out the bits we understand, and hope that +* the rest are in good shape for the hardware. +*/ + intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT, +intel_sdvo-hotplug_active, 2); + intel_sdvo-hotplug_active[0] = 0x3; + This appears to unconditionally set the bits for devices 0 and 1, making the dvi-specific code that sets the device bit irrelevant. I think you just want to set hotplug_active to 0. I'm clearing the bits (= not |=). I could respin setting it to 0, but that takes me even further from the old (commented out) code, and I'd really want someone to check SDVO specs before doing that. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv5] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Wednesday 21 September 2011, Keith Packard kei...@keithp.com wrote: On Wed, 21 Sep 2011 10:08:13 +0100, Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: I'm clearing the bits (= not |=). I could respin setting it to 0, but that takes me even further from the old (commented out) code, and I'd really want someone to check SDVO specs before doing that. What I see the code doing is asking whether devices 0 and 1 *could* support hotplug and then unconditionally setting the devices for which we *want* hotplug to that. I think you should set the list of devices requesting hotplug to be the intersection of the set of devices which *could* do hotplug and the set of devices for which we *want* hotplug. That seems like it would be achieved by just clearing the set of devices that we will request hotplug for and then checking which ones are supported and incrementally adding those to the hotplug_active set. I think I see my mistake - but I'd like to check before I do a v6 of this patch. I'm ANDing the value returned by hardware with 3 - I should be ANDing it with an appropriate ~3. The rest of the code (setting those bits in intel_sdvo_dvi_init based on what functions I have) should be OK. Essentially, I'm fairly confident based on empirical evidence that bit 0 is HPD for device 0 (as my SDVO devices both return 0x01 in that byte). I don't know what the rest of the bits mean, but it seems like a reasonable guess that bit 1 is HPD for device 1, so I'm acting accordingly. I would still like someone with the spec to go over what I'm doing - this seems appropriate, but *all* I have to test against are two different motherboards with integrated DVI-D that turns out to be an SDVO device. I have no documentation for SDVO - all of this is based on the existing code with hints from ajax; it could be complete nonsense for anything other than the two devices I have. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Tuesday 20 September 2011, Keith Packard kei...@keithp.com wrote:
On Wed, 17 Aug 2011 10:52:21 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
static bool
intel_sdvo_multifunc_encoder(struct intel_sdvo *intel_sdvo)
@@ -2062,7 +2053,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
int device)
intel_connector = intel_sdvo_connector-base;
connector = intel_connector-base;
- connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT; +if
(intel_sdvo_supports_hotplug(intel_sdvo) (1 device))
+ connector-polled = DRM_CONNECTOR_POLL_HPD;
+ else
+ connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
encoder-encoder_type = DRM_MODE_ENCODER_TMDS;
connector-connector_type = DRM_MODE_CONNECTOR_DVID;
@@ -2587,6 +2581,11 @@ bool intel_sdvo_init(struct drm_device *dev, int
sdvo_reg)
intel_sdvo-pixel_clock_max))
goto err;
+if (intel_sdvo_supports_hotplug(intel_sdvo)) {
+ intel_encoder-hot_plug = intel_sdvo_do_hotplug;
+ intel_sdvo_set_hotplug(intel_sdvo);
+ }
+
This all looks quite reasonable, about the only thing I would suggest is
that you avoid calling intel_sdvo_supports_hotplug twice in
intel_sdvo_init and simply look at connector-polled to see if the HPD
bit is set.
V2 patch coming up - I'll check connector-polled in intel_sdvo_init, and rely
on the call to intel_sdvo_output_setup calling a connector-specific output
function (in my case, intel_sdvo_dvi_init) that sets it correctly.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of help from Adam Jackson a...@redhat.com on IRC.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Changes from first version:
* Don't call intel_sdvo_supports_hotplug twice - pick up the setting
in connector-polled instead (suggested by Keith Packard in review).
* Change subject prefix to drm/i915
drivers/gpu/drm/i915/intel_drv.h |3 --
drivers/gpu/drm/i915/intel_sdvo.c | 65 -
2 files changed, 28 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b330e7..94bb596 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -336,9 +336,6 @@ extern void intel_release_load_detect_pipe(struct
intel_encoder *intel_encoder,
struct drm_connector *connector,
struct intel_load_detect_pipe *old);
-extern struct drm_connector* intel_sdvo_find(struct drm_device *dev, int
sdvoB);
-extern int intel_sdvo_supports_hotplug(struct drm_connector *connector);
-extern void intel_sdvo_set_hotplug(struct drm_connector *connector, int
enable);
extern void intelfb_restore(void);
extern void intel_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno);
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 30fe554..ebce2a5 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1208,74 +1208,55 @@ static bool intel_sdvo_get_capabilities(struct
intel_sdvo *intel_sdvo, struct in
return true;
}
-/* No use! */
-#if 0
-struct drm_connector* intel_sdvo_find(struct drm_device *dev, int sdvoB)
+struct drm_connector* intel_sdvo_find_connector(struct intel_sdvo *sdvo)
{
struct drm_connector *connector = NULL;
struct intel_sdvo *iout = NULL;
- struct intel_sdvo *sdvo;
+ struct drm_device *dev;
+
+ dev = sdvo-base.base.dev;
/* find the sdvo connector */
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- iout = to_intel_sdvo(connector);
-
- if (iout-type != INTEL_OUTPUT_SDVO)
- continue;
-
- sdvo = iout-dev_priv;
-
- if (sdvo-sdvo_reg == SDVOB sdvoB)
- return connector;
+ iout = intel_attached_sdvo(connector);
- if (sdvo-sdvo_reg == SDVOC !sdvoB)
+ if (iout == sdvo)
return connector;
-
}
return NULL;
}
-int intel_sdvo_supports_hotplug(struct drm_connector *connector)
+static int intel_sdvo_supports_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
- u8 status;
- struct intel_sdvo *intel_sdvo;
- DRM_DEBUG_KMS(\n);
-
- if (!connector)
- return 0;
-
- intel_sdvo = to_intel_sdvo(connector);
return intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
response, 2) response[0];
}
-void intel_sdvo_set_hotplug(struct drm_connector *connector, int on)
+static void intel_sdvo_set_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
u8 status;
- struct intel_sdvo *intel_sdvo = to_intel_sdvo(connector);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL, 0);
- status = intel_sdvo_read_response(intel_sdvo, response, 2);
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT, NULL,
0);
+ status = intel_sdvo_read_response(intel_sdvo, response, 2);
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- } else {
- response[0] = 0;
- response[1] = 0;
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- }
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
}
-#endif
+
+void intel_sdvo_do_hotplug(struct intel_encoder *encoder)
+{
+ struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder-base);
+ intel_sdvo_set_hotplug(intel_sdvo);
+}
static bool
intel_sdvo_multifunc_encoder(struct intel_sdvo *intel_sdvo)
@@ -2062,7 +2043,10
Re: [Intel-gfx] [PATCH v2] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Tuesday 20 September 2011, Chris Wilson ch...@chris-wilson.co.uk wrote: Couldn't spot anything wrong with the logic, so just style nitpicking. I'll have to fix the Ubuntu snafu that's preventing my one machine with a hotpluggable SDVO device from booting before I can test. Also need to find someone with the SDVO specs to see if there are any known caveats. :| -Chris v3 patch on the way, with your style nitpicks fixed up. Just needs testing before I send it to the list. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv3] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of help from Adam Jackson a...@redhat.com on IRC.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Changes from v2:
* Stylistic cleanups requested by Chris Wilson in review:
* Make intel_sdvo_find_connector cleaner
* Rename intel_sdvo_set_hotplug to intel_sdvo_enable_hotplug
(reflects functionality better)
* Remove intel_sdvo_do_hotplug
Changes from first version:
* Don't call intel_sdvo_supports_hotplug twice - pick up the setting
in connector-polled instead (suggested by Keith Packard in review).
* Change subject prefix to drm/i915
drivers/gpu/drm/i915/intel_drv.h |3 --
drivers/gpu/drm/i915/intel_sdvo.c | 61 +---
2 files changed, 22 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 375690b..a72d31d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -337,9 +337,6 @@ extern void intel_release_load_detect_pipe(struct
intel_encoder *intel_encoder,
struct drm_connector *connector,
struct intel_load_detect_pipe *old);
-extern struct drm_connector* intel_sdvo_find(struct drm_device *dev, int
sdvoB);
-extern int intel_sdvo_supports_hotplug(struct drm_connector *connector);
-extern void intel_sdvo_set_hotplug(struct drm_connector *connector, int
enable);
extern void intelfb_restore(void);
extern void intel_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno);
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index aa94110..b4326ff 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1208,74 +1208,47 @@ static bool intel_sdvo_get_capabilities(struct
intel_sdvo *intel_sdvo, struct in
return true;
}
-/* No use! */
-#if 0
-struct drm_connector* intel_sdvo_find(struct drm_device *dev, int sdvoB)
+struct drm_connector* intel_sdvo_find_connector(struct intel_sdvo *sdvo)
{
struct drm_connector *connector = NULL;
- struct intel_sdvo *iout = NULL;
- struct intel_sdvo *sdvo;
+ struct drm_device *dev;
+
+ dev = sdvo-base.base.dev;
/* find the sdvo connector */
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- iout = to_intel_sdvo(connector);
-
- if (iout-type != INTEL_OUTPUT_SDVO)
- continue;
-
- sdvo = iout-dev_priv;
-
- if (sdvo-sdvo_reg == SDVOB sdvoB)
+ if (intel_attached_encoder(connector) == sdvo-base)
return connector;
-
- if (sdvo-sdvo_reg == SDVOC !sdvoB)
- return connector;
-
}
return NULL;
}
-int intel_sdvo_supports_hotplug(struct drm_connector *connector)
+static int intel_sdvo_supports_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
- u8 status;
- struct intel_sdvo *intel_sdvo;
- DRM_DEBUG_KMS(\n);
-
- if (!connector)
- return 0;
-
- intel_sdvo = to_intel_sdvo(connector);
return intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
response, 2) response[0];
}
-void intel_sdvo_set_hotplug(struct drm_connector *connector, int on)
+static void intel_sdvo_enable_hotplug(struct intel_encoder *encoder)
{
+ struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder-base);
u8 response[2];
u8 status;
- struct intel_sdvo *intel_sdvo = to_intel_sdvo(connector);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL, 0);
- status = intel_sdvo_read_response(intel_sdvo, response, 2);
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT, NULL,
0);
+ status = intel_sdvo_read_response(intel_sdvo, response, 2);
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- } else {
- response[0] = 0;
- response[1] = 0;
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- }
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo
Re: [Intel-gfx] [PATCHv3] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Tuesday 20 September 2011, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, 20 Sep 2011 13:52:59 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
+ connector = intel_sdvo_find_connector(intel_sdvo);
+ if (connector-polled == DRM_CONNECTOR_POLL_HPD) {
+ intel_encoder-hot_plug = intel_sdvo_enable_hotplug;
+ intel_sdvo_enable_hotplug(intel_encoder);
+ }
I should have spotted this the first time... This does not look right.
A multi-function SDVO card has multiple connectors. As we enable
hotplug for any functions with support on a global basis, we only need
the single hook. However, the first connector found might not be the one
marked as POLL_HPD. I think the answer is to move this this
initialisation into intel_sdvo_output_setup() where the individual
functions can report whether or not they want hotplug enabling.
I'll send v4 shortly - I think I've understood and addressed your comment.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of help from Adam Jackson a...@redhat.com on IRC.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Changes from v3:
* As per Chris Wilson's comment, move the hotplug enable from
intel_sdvo_init to intel_sdvo_dvi_init. Should correctly enable HPD
if only one of a multifunction SDVO pair supports HPD.
Changes from v2:
* Stylistic cleanups requested by Chris Wilson in review:
* Make intel_sdvo_find_connector cleaner
* Rename intel_sdvo_set_hotplug to intel_sdvo_enable_hotplug
(reflects functionality better)
* Remove intel_sdvo_do_hotplug
Changes from first version:
* Don't call intel_sdvo_supports_hotplug twice - pick up the setting
in connector-polled instead (suggested by Keith Packard in review).
* Change subject prefix to drm/i915
drivers/gpu/drm/i915/intel_drv.h |3 --
drivers/gpu/drm/i915/intel_sdvo.c | 64 -
2 files changed, 14 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 375690b..a72d31d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -337,9 +337,6 @@ extern void intel_release_load_detect_pipe(struct
intel_encoder *intel_encoder,
struct drm_connector *connector,
struct intel_load_detect_pipe *old);
-extern struct drm_connector* intel_sdvo_find(struct drm_device *dev, int
sdvoB);
-extern int intel_sdvo_supports_hotplug(struct drm_connector *connector);
-extern void intel_sdvo_set_hotplug(struct drm_connector *connector, int
enable);
extern void intelfb_restore(void);
extern void intel_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno);
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index aa94110..27a1ead 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1208,74 +1208,31 @@ static bool intel_sdvo_get_capabilities(struct
intel_sdvo *intel_sdvo, struct in
return true;
}
-/* No use! */
-#if 0
-struct drm_connector* intel_sdvo_find(struct drm_device *dev, int sdvoB)
-{
- struct drm_connector *connector = NULL;
- struct intel_sdvo *iout = NULL;
- struct intel_sdvo *sdvo;
-
- /* find the sdvo connector */
- list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- iout = to_intel_sdvo(connector);
-
- if (iout-type != INTEL_OUTPUT_SDVO)
- continue;
-
- sdvo = iout-dev_priv;
-
- if (sdvo-sdvo_reg == SDVOB sdvoB)
- return connector;
-
- if (sdvo-sdvo_reg == SDVOC !sdvoB)
- return connector;
-
- }
-
- return NULL;
-}
-
-int intel_sdvo_supports_hotplug(struct drm_connector *connector)
+static int intel_sdvo_supports_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
- u8 status;
- struct intel_sdvo *intel_sdvo;
- DRM_DEBUG_KMS(\n);
-
- if (!connector)
- return 0;
-
- intel_sdvo = to_intel_sdvo(connector);
return intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
response, 2) response[0];
}
-void intel_sdvo_set_hotplug(struct drm_connector *connector, int on)
+static void intel_sdvo_enable_hotplug(struct intel_encoder *encoder)
{
+ struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder-base);
u8 response[2];
u8 status;
- struct intel_sdvo *intel_sdvo = to_intel_sdvo(connector);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL, 0);
- status = intel_sdvo_read_response(intel_sdvo, response, 2);
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT, NULL,
0);
+ status = intel_sdvo_read_response(intel_sdvo, response, 2);
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- } else {
- response[0] = 0;
- response[1] = 0;
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- }
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo
Re: [Intel-gfx] [PATCH] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Tuesday 20 September 2011, Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: I was seeing a nasty 5 frame glitch every 10 seconds, caused by the poll for connection on DVI attached by SDVO. As my SDVO DVI supports hotplug detect interrupts, the fix is to enable them, and hook them in to the various bits of driver infrastructure so that they work reliably. With lots of help from Adam Jackson a...@redhat.com on IRC. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Changes from v3: * As per Chris Wilson's comment, move the hotplug enable from intel_sdvo_init to intel_sdvo_dvi_init. Should correctly enable HPD if only one of a multifunction SDVO pair supports HPD. Note that I forgot to update the subject line - this is patch v4. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Tuesday 20 September 2011, Keith Packard kei...@keithp.com wrote:
On Tue, 20 Sep 2011 15:17:38 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL,
0); - status = intel_sdvo_read_response(intel_sdvo,
response, 2);
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT, NULL,
0); + status = intel_sdvo_read_response(intel_sdvo, response, 2);
...
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
You are unconditionally enabling hotplug on all devices, I think you
want to take the desired device as an argument to this function and add
it to the set of active hotplug devices instead. You've just gotten the
active hotplug value above, so removing the call to GET_HOT_PLUG_SUPPORT
and doing:
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
response[0] |= (1 device);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response,
2);
should do what you want.
This interacts badly with the need I've found to call this function every time
a hotplug interrupt comes through (explained below) - I'm not sure how to
track back from the encoder (which gets the callback) to the SDVO device
number.
@@ -2062,7 +2020,13 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
int device)
intel_connector = intel_sdvo_connector-base;
connector = intel_connector-base;
- connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT; +if
(intel_sdvo_supports_hotplug(intel_sdvo) (1 device)) {
+ connector-polled = DRM_CONNECTOR_POLL_HPD;
+ intel_encoder-hot_plug = intel_sdvo_enable_hotplug;
The encoder-hot_plug function is what is called when the hotplug
interrupt is detected. The only current user is the DisplayPort driver
which uses this to signal link retraining. You definitely don't want or
need to call intel_sdvo_enable_hotplug at that point.
If I don't call intel_sdvo_enable_hotplug at this point, I only get the one
hotplug interrupt; it appears that the SDVO devices I have send their
interrupt, then expect you to re-enable HPD interrupts before they will send
another interrupt.
I'm not sure how best to handle this; my gut feeling is that there's no real
harm enabling HPD interrupts on all ports that support it, even though I'm
only processing HPD interrupts from DVI and HDMI ports. If you have better
ideas, I'm happy to try them.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
On Tuesday 20 September 2011, Keith Packard kei...@keithp.com wrote: On Tue, 20 Sep 2011 17:38:37 +0100, Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: This interacts badly with the need I've found to call this function every time a hotplug interrupt comes through (explained below) - I'm not sure how to track back from the encoder (which gets the callback) to the SDVO device number. You might store the desired hotplug bits in the intel_sdvo structure, and then use that in the enable function. The enable function should be able to just call SET_ACTIVE_HOT_PLUG with the desired value instead of making the four calls that it does now, right? Sounds perfectly reasonable to me. I'll whip up patch v5 before I head home tonight. If I don't call intel_sdvo_enable_hotplug at this point, I only get the one hotplug interrupt; it appears that the SDVO devices I have send their interrupt, then expect you to re-enable HPD interrupts before they will send another interrupt. ok, sounds good. I'll add a comment to the code so that future reviewers understand why I'm doing it. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv5] drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of help from Adam Jackson a...@redhat.com on IRC.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Changes from the unnumbered v4:
* At Keith Packard's request, store the required hotplug bits in
struct intel_sdvo and just call SET_ACTIVE_HOT_PLUG to enable
hotplug interrupts.
* Add some comments to explain why I'm doing things that reviewers
didn't think was obvious, so that the next person to examine this
area doesn't get confused.
Changes from v3:
* As per Chris Wilson's comment, move the hotplug enable from
intel_sdvo_init to intel_sdvo_dvi_init. Should correctly enable HPD
if only one of a multifunction SDVO pair supports HPD.
Changes from v2:
* Stylistic cleanups requested by Chris Wilson in review:
* Make intel_sdvo_find_connector cleaner
* Rename intel_sdvo_set_hotplug to intel_sdvo_enable_hotplug
(reflects functionality better)
* Remove intel_sdvo_do_hotplug
Changes from first version:
* Don't call intel_sdvo_supports_hotplug twice - pick up the setting
in connector-polled instead (suggested by Keith Packard in review).
* Change subject prefix to drm/i915
drivers/gpu/drm/i915/intel_drv.h |3 -
drivers/gpu/drm/i915/intel_sdvo.c | 88 -
2 files changed, 29 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 375690b..a72d31d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -337,9 +337,6 @@ extern void intel_release_load_detect_pipe(struct
intel_encoder *intel_encoder,
struct drm_connector *connector,
struct intel_load_detect_pipe *old);
-extern struct drm_connector* intel_sdvo_find(struct drm_device *dev, int
sdvoB);
-extern int intel_sdvo_supports_hotplug(struct drm_connector *connector);
-extern void intel_sdvo_set_hotplug(struct drm_connector *connector, int
enable);
extern void intelfb_restore(void);
extern void intel_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno);
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index aa94110..5813538 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -92,6 +92,11 @@ struct intel_sdvo {
*/
uint16_t attached_output;
+ /*
+* Hotplug activation bits for this device
+*/
+ uint8_t hotplug_active[2];
+
/**
* This is used to select the color range of RBG outputs in HDMI mode.
* It is only valid when using TMDS encoding and 8 bit per color mode.
@@ -1208,74 +1213,20 @@ static bool intel_sdvo_get_capabilities(struct
intel_sdvo *intel_sdvo, struct in
return true;
}
-/* No use! */
-#if 0
-struct drm_connector* intel_sdvo_find(struct drm_device *dev, int sdvoB)
-{
- struct drm_connector *connector = NULL;
- struct intel_sdvo *iout = NULL;
- struct intel_sdvo *sdvo;
-
- /* find the sdvo connector */
- list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- iout = to_intel_sdvo(connector);
-
- if (iout-type != INTEL_OUTPUT_SDVO)
- continue;
-
- sdvo = iout-dev_priv;
-
- if (sdvo-sdvo_reg == SDVOB sdvoB)
- return connector;
-
- if (sdvo-sdvo_reg == SDVOC !sdvoB)
- return connector;
-
- }
-
- return NULL;
-}
-
-int intel_sdvo_supports_hotplug(struct drm_connector *connector)
+static int intel_sdvo_supports_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
- u8 status;
- struct intel_sdvo *intel_sdvo;
- DRM_DEBUG_KMS(\n);
-
- if (!connector)
- return 0;
-
- intel_sdvo = to_intel_sdvo(connector);
return intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
response, 2) response[0];
}
-void intel_sdvo_set_hotplug(struct drm_connector *connector, int on)
+static void intel_sdvo_enable_hotplug(struct intel_encoder *encoder)
{
- u8 response[2];
- u8 status;
- struct intel_sdvo *intel_sdvo = to_intel_sdvo(connector);
-
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
- intel_sdvo_read_response(intel_sdvo, response, 2);
-
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL, 0);
- status = intel_sdvo_read_response(intel_sdvo, response
Re: [Intel-gfx] [PATCH] i915: Enable SDVO hotplug interrupts for HDMI and DVI
Hello Keith,
I've not seen any replies to this patch in the last month, nor can I find it in
your tree at http://cgit.freedesktop.org/~keithp/linux/ (I'd check kernel.org
as well, but it's still down).
Is there anything I need to do to make this patch acceptable? Or is it just a
case of waiting for you to catch up on post-XDC madness?
--
Simon
On Wednesday 17 August 2011, Simon Farnsworth simon.farnswo...@onelan.co.uk
wrote:
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of help from Adam Jackson a...@redhat.com on IRC.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
I'm not entirely confident that I'm treating the result of
SDVO_CMD_GET_HOT_PLUG_SUPPORT correctly for multifunction SDVO
devices. I've assumed it's a bitmask, but I have no documents to tell
me that that's right. Review from someone who understands SDVO would
be appreciated.
Note that I've only wired up hotplug fully for SDVO TMDS
outputs. While we will get hotplug interrupts for other SDVO types, we
won't do anything with them; if someone with another SDVO type wants
to wire it up and test it, look at how intel_sdvo_dvi_init sets
connector-polled.
However, this does work well for my hardware, which is all
single-function SDVO DVI-D ports, both on Atom N270 and 965GME.
drivers/gpu/drm/i915/intel_drv.h |3 --
drivers/gpu/drm/i915/intel_sdvo.c | 43
++--- 2 files changed, 21 insertions(+),
25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h index 7b330e7..94bb596 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -336,9 +336,6 @@ extern void intel_release_load_detect_pipe(struct
intel_encoder *intel_encoder, struct drm_connector *connector,
struct intel_load_detect_pipe *old);
-extern struct drm_connector* intel_sdvo_find(struct drm_device *dev, int
sdvoB); -extern int intel_sdvo_supports_hotplug(struct drm_connector
*connector); -extern void intel_sdvo_set_hotplug(struct drm_connector
*connector, int enable); extern void intelfb_restore(void);
extern void intel_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16
green, u16 blue, int regno);
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c index 30fe554..9404388 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1235,47 +1235,38 @@ struct drm_connector* intel_sdvo_find(struct
drm_device *dev, int sdvoB)
return NULL;
}
+#endif
-int intel_sdvo_supports_hotplug(struct drm_connector *connector)
+static int intel_sdvo_supports_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
- u8 status;
- struct intel_sdvo *intel_sdvo;
- DRM_DEBUG_KMS(\n);
-
- if (!connector)
- return 0;
-
- intel_sdvo = to_intel_sdvo(connector);
return intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
response, 2) response[0];
}
-void intel_sdvo_set_hotplug(struct drm_connector *connector, int on)
+static void intel_sdvo_set_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
u8 status;
- struct intel_sdvo *intel_sdvo = to_intel_sdvo(connector);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL,
0); - status = intel_sdvo_read_response(intel_sdvo, response, 2);
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT, NULL,
0);
+ status = intel_sdvo_read_response(intel_sdvo, response, 2);
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2); - } else {
- response[0] = 0;
- response[1] = 0;
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2); - }
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response,
2);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
}
-#endif
+
+void intel_sdvo_do_hotplug(struct intel_encoder *encoder)
+{
+ struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder-base);
+ intel_sdvo_set_hotplug(intel_sdvo);
+}
static bool
intel_sdvo_multifunc_encoder(struct intel_sdvo *intel_sdvo)
@@ -2062,7 +2053,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
int device)
intel_connector = intel_sdvo_connector-base
[Intel-gfx] [PATCH] i915: Enable SDVO hotplug interrupts for HDMI and DVI
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of help from Adam Jackson a...@redhat.com on IRC.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
I'm not entirely confident that I'm treating the result of
SDVO_CMD_GET_HOT_PLUG_SUPPORT correctly for multifunction SDVO
devices. I've assumed it's a bitmask, but I have no documents to tell
me that that's right. Review from someone who understands SDVO would
be appreciated.
Note that I've only wired up hotplug fully for SDVO TMDS
outputs. While we will get hotplug interrupts for other SDVO types, we
won't do anything with them; if someone with another SDVO type wants
to wire it up and test it, look at how intel_sdvo_dvi_init sets
connector-polled.
However, this does work well for my hardware, which is all
single-function SDVO DVI-D ports, both on Atom N270 and 965GME.
drivers/gpu/drm/i915/intel_drv.h |3 --
drivers/gpu/drm/i915/intel_sdvo.c | 43 ++---
2 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b330e7..94bb596 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -336,9 +336,6 @@ extern void intel_release_load_detect_pipe(struct
intel_encoder *intel_encoder,
struct drm_connector *connector,
struct intel_load_detect_pipe *old);
-extern struct drm_connector* intel_sdvo_find(struct drm_device *dev, int
sdvoB);
-extern int intel_sdvo_supports_hotplug(struct drm_connector *connector);
-extern void intel_sdvo_set_hotplug(struct drm_connector *connector, int
enable);
extern void intelfb_restore(void);
extern void intel_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno);
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 30fe554..9404388 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1235,47 +1235,38 @@ struct drm_connector* intel_sdvo_find(struct drm_device
*dev, int sdvoB)
return NULL;
}
+#endif
-int intel_sdvo_supports_hotplug(struct drm_connector *connector)
+static int intel_sdvo_supports_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
- u8 status;
- struct intel_sdvo *intel_sdvo;
- DRM_DEBUG_KMS(\n);
-
- if (!connector)
- return 0;
-
- intel_sdvo = to_intel_sdvo(connector);
return intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
response, 2) response[0];
}
-void intel_sdvo_set_hotplug(struct drm_connector *connector, int on)
+static void intel_sdvo_set_hotplug(struct intel_sdvo *intel_sdvo)
{
u8 response[2];
u8 status;
- struct intel_sdvo *intel_sdvo = to_intel_sdvo(connector);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL, 0);
- status = intel_sdvo_read_response(intel_sdvo, response, 2);
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT, NULL,
0);
+ status = intel_sdvo_read_response(intel_sdvo, response, 2);
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- } else {
- response[0] = 0;
- response[1] = 0;
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
- }
+ intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_SET_ACTIVE_HOT_PLUG,
response, 2);
intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_ACTIVE_HOT_PLUG, NULL, 0);
intel_sdvo_read_response(intel_sdvo, response, 2);
}
-#endif
+
+void intel_sdvo_do_hotplug(struct intel_encoder *encoder)
+{
+ struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder-base);
+ intel_sdvo_set_hotplug(intel_sdvo);
+}
static bool
intel_sdvo_multifunc_encoder(struct intel_sdvo *intel_sdvo)
@@ -2062,7 +2053,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int
device)
intel_connector = intel_sdvo_connector-base;
connector = intel_connector-base;
- connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
+ if (intel_sdvo_supports_hotplug(intel_sdvo) (1 device))
+ connector-polled = DRM_CONNECTOR_POLL_HPD;
+ else
+ connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
encoder
Re: [Intel-gfx] HDMI CEC support
On Thursday 30 June 2011, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 30 Jun 2011 18:19:20 +0100 Barry Scott barry.sc...@onelan.co.uk wrote: The HW needs to support the 1 wire bidirectional bus using AV.Link prootocol on pin 13. I bit of googling seems to confirm that Intel Integrated graphic on Windows can operate CEC. (I did not find chip level details). We may be asked to get this going here. If we have access to the necesssary docs to work on this we'll supply patches for your consideration. Great. Docs are available at http://www.intellinuxgraphics.org if you want to take a stab at this. It would be a nice feature to have. Of the available docs, which one should I look in? I can't find any references to pin 13 or CEC in any part of volume 3, and when I look at the search results for HDMI, I can't find anything that even hints that pin 13 is connected to a GPIO line or an AV.Link engine in the hardware. I can only find references to HDMI in part 3 of volume 3, but, again, nothing that indicates where I'd go hunting to find out how I get at the CEC pin. Am I looking in the wrong place? -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/sdvo: Only enable HDMI encodings only if the commandset is supported
On Monday 22 November 2010, Chris Wilson ch...@chris-wilson.co.uk wrote:
As we conflated intel_sdvo-is_hdmi with both having HDMI support on the
ADD along with having HDMI support on the monitor, we would attempt to
use HDMI encodings even if the interface did not support those commands.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
This fixes my problems with the image being in the middle third or so of the
screen. I've also read the patch and resulting state of code, and it looks
like the right thing to do, so take your pick of:
Tested-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
drivers/gpu/drm/i915/intel_sdvo.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c index de158b7..8431825 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -107,7 +107,8 @@ struct intel_sdvo {
* This is set if we treat the device as HDMI, instead of DVI.
*/
bool is_hdmi;
- bool has_audio;
+ bool has_hdmi_monitor;
+ bool has_hdmi_audio;
/**
* This is set if we detect output of sdvo device as LVDS and
@@ -1023,7 +1024,7 @@ static void intel_sdvo_mode_set(struct drm_encoder
*encoder, if (!intel_sdvo_set_target_input(intel_sdvo))
return;
- if (intel_sdvo-is_hdmi
+ if (intel_sdvo-has_hdmi_monitor
!intel_sdvo_set_avi_infoframe(intel_sdvo))
return;
@@ -1063,7 +1064,7 @@ static void intel_sdvo_mode_set(struct drm_encoder
*encoder, }
if (intel_crtc-pipe == 1)
sdvox |= SDVO_PIPE_B_SELECT;
- if (intel_sdvo-has_audio)
+ if (intel_sdvo-has_hdmi_audio)
sdvox |= SDVO_AUDIO_ENABLE;
if (INTEL_INFO(dev)-gen = 4) {
@@ -1388,8 +1389,10 @@ intel_sdvo_hdmi_sink_detect(struct drm_connector
*connector) /* DDC bus is shared, match EDID to connector type */
if (edid-input DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
- intel_sdvo-is_hdmi = drm_detect_hdmi_monitor(edid);
- intel_sdvo-has_audio = drm_detect_monitor_audio(edid);
+ if (intel_sdvo-is_hdmi) {
+ intel_sdvo-has_hdmi_monitor =
drm_detect_hdmi_monitor(edid);
+ intel_sdvo-has_hdmi_audio =
drm_detect_monitor_audio(edid);
+ }
}
connector-display_info.raw_edid = NULL;
kfree(edid);
@@ -1398,7 +1401,7 @@ intel_sdvo_hdmi_sink_detect(struct drm_connector
*connector) if (status == connector_status_connected) {
struct intel_sdvo_connector *intel_sdvo_connector =
to_intel_sdvo_connector(connector); if (intel_sdvo_connector-force_audio)
- intel_sdvo-has_audio =
intel_sdvo_connector-force_audio 0;
+ intel_sdvo-has_hdmi_audio =
intel_sdvo_connector-force_audio
0;
}
return status;
@@ -1713,12 +1716,12 @@ intel_sdvo_set_property(struct drm_connector
*connector,
intel_sdvo_connector-force_audio = val;
- if (val 0 intel_sdvo-has_audio)
+ if (val 0 intel_sdvo-has_hdmi_audio)
return 0;
- if (val 0 !intel_sdvo-has_audio)
+ if (val 0 !intel_sdvo-has_hdmi_audio)
return 0;
- intel_sdvo-has_audio = val 0;
+ intel_sdvo-has_hdmi_audio = val 0;
goto done;
}
@@ -2070,6 +2073,8 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
int device) intel_sdvo_set_colorimetry(intel_sdvo,
SDVO_COLORIMETRY_RGB256);
connector-connector_type = DRM_MODE_CONNECTOR_HDMIA;
+
+ intel_sdvo_add_hdmi_properties(intel_sdvo_connector);
intel_sdvo-is_hdmi = true;
}
intel_sdvo-base.clone_mask = ((1 INTEL_SDVO_NON_TV_CLONE_BIT) |
@@ -2077,8 +2082,6 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
int device)
intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo);
- intel_sdvo_add_hdmi_properties(intel_sdvo_connector);
-
return true;
}
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Modesetting bug on 945GSE (Atom N270) with Chris Wilson's drm-intel-next kernel
Hello, I'm seeing an interesting bug on 945GSE, and I have absolutely no idea where to start looking. I'm trying to deal with performance issues on this platform, so I'm updating to master of as many bits as possible, to see if they're better. drm-intel-next as of a17577c9 (not tried older versions yet) is consistently rendering to the middle third or so of the screen only; this is happening in X, as well as in inteldrmfb during boot. Has anyone seen anything similar? I'm going to try and see if I can find a working version, then bisect my way to a faulty commit, but if the symptom is familiar, a clue would be welcomed. -- Thanks, Simon Farnsworth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
On Thursday 16 September 2010, Vasily Khoruzhick anars...@gmail.com wrote: В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал: processor.max_cstate=2 Nope, it doesn't work with max_cstate=2 Perhaps intel_idle is being used? Any mention of it in dmesg? Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is smooth, with higher values (i.e. max_cstate=2) graphics is jerky. Btw, Jesse, any comments/solutions/workarounds except one with processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo bugzilla? This looks like a problem I've seen on some hardware. My workaround has been to use the pm_qos /dev/cpu_dma_latency interface to request a maximum latency of 1ms (value chosen as definitely small enough - a larger value may be better, but I don't care about power saving at runtime on my kit). If it's happening on other kit, perhaps the i915 driver should make a suitable pm_qos request itself. Jesse, can you comment? -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] Avoid pageflipping freeze when we apparently miss the flip prepare interrupt
When we miss the flip prepare interrupt, we never get into the
software state needed to restart userspace, resulting in a freeze of a
full-screen OpenGL application (such as a compositor).
Work around this by checking DSPxSURF/DSPxBASE to see if the page flip
has actually happened. If it has, do the work we would have done when
the flip prepare interrupt comes in.
Also, add debugfs information to tell us what's going on (based on the
patch from Chris Wilson attached to bugs.fdo bug #29798).
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
After sending the previous patch, I thought about the problem a lot
more. We have two interesting cases when a full-screen application
is running:
1) The GPU is able to complete rendering in the time between the page
flip being queued and the next vblank. This should result in a
pageflip prepared interrupt before the vblank interrupt, but if it
doesn't, the stall check will detect that the page flip has happened
and recover without a visual glitch.
2) The rendering is queued late, or is too hefty for the GPU to
complete before the next vblank. In this case, we pay a small CPU
penalty checking to see if the page flip has happened, while the GPU
hasn't got far enough through the ring to have seen that we want it to
flip.
My intution is that case 2 is rare - in the case of my application (an
OpenGL compositor for digital signage), I expect to be woken up as
soon as the page flip has occured, queue some rendering and follow it
with a page flip request. Further, except in cases of extreme
overload, I expect to be able to queue everything up to the page flip
and have the GPU process it well before the next vblank.
Hence the stall check handler aims to short-circuit as soon as I can
determine that we've not got a page flip queued (don't waste time), or
if we're in case 1, and have received the page flip prepared interrupt
before vblank.
It only reads a hardware register (hopefully not a painful cost, but
still more expensive than checking two CPU-side variables rather than
just one) if we've hit the problem (when we have to check the GPU
register to detect it), or if we're in case 2.
drivers/gpu/drm/i915/i915_debugfs.c | 50 +++
drivers/gpu/drm/i915/i915_irq.c | 54 -
drivers/gpu/drm/i915/intel_display.c | 14 ++--
drivers/gpu/drm/i915/intel_drv.h | 10 ++
4 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 92d5605..b05ed83 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -33,6 +33,7 @@
#include drm.h
#include i915_drm.h
#include i915_drv.h
+#include intel_drv.h
#define DRM_I915_RING_DEBUG 1
@@ -121,6 +122,54 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
return 0;
}
+static int i915_gem_pageflip_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ unsigned long flags;
+ struct intel_crtc *crtc;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+ const char *pipe = crtc-pipe ? B : A;
+ const char *plane = crtc-plane ? B : A;
+ struct intel_unpin_work *work;
+
+ spin_lock_irqsave(dev-event_lock, flags);
+ work = crtc-unpin_work;
+ if (work == NULL) {
+ seq_printf(m, No flip due on pipe %s (plane %s)\n,
+ pipe, plane);
+ } else {
+ if (!work-pending) {
+ seq_printf(m, Flip queued on pipe %s (plane
%s)\n,
+ pipe, plane);
+ } else {
+ seq_printf(m, Flip pending (waiting for vsync)
on pipe %s (plane %s)\n,
+ pipe, plane);
+ }
+ if (work-enable_stall_check)
+ seq_printf(m, Stall check enabled, );
+ else
+ seq_printf(m, Stall check waiting for page
flip ioctl, );
+ seq_printf(m, %d prepares\n, work-pending);
+
+ if (work-old_fb_obj) {
+ struct drm_i915_gem_object *obj_priv =
to_intel_bo(work-old_fb_obj);
+ if(obj_priv)
+ seq_printf(m, Old framebuffer
gtt_offset 0x%08x\n, obj_priv-gtt_offset );
+ }
+ if (work-pending_flip_obj) {
+ struct drm_i915_gem_object *obj_priv =
to_intel_bo(work-pending_flip_obj);
+ if(obj_priv
Re: [Intel-gfx] [PATCH] Attempt to detect and recover from pageflipping stalls
On Wednesday 1 September 2010, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
In an attempt to get to the bottom of bug #29798, Chris Wilson gave me
a patch that put some details in debugfs. With the clues gathered from
that patch, I was able to determine that the page flip is happening,
but that we're not seeing the IRQs we'd expect.
Work around this by only permitting a pageflip to be outstanding for 3
VBlank periods before we start examining the display registers to see
if the pageflip happened, but we weren't told about it. This converts
an apparent hang into a visual glitch.
And, as promised, it's buggy:
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c index 16861b8..893cd77 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -887,6 +887,54 @@ static void i915_handle_error(struct drm_device *dev,
bool wedged) queue_work(dev_priv-wq, dev_priv-error_work);
}
+static void i915_pageflip_stall_check(struct drm_device *dev, int pipe)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
+ int plane = intel_crtc-plane;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
These two lines got swapped when I was checking various possible null
pointers.
I can send a new version if required.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Attempt to detect and recover from pageflipping stalls
In an attempt to get to the bottom of bug #29798, Chris Wilson gave me
a patch that put some details in debugfs. With the clues gathered from
that patch, I was able to determine that the page flip is happening,
but that we're not seeing the IRQs we'd expect.
Work around this by only permitting a pageflip to be outstanding for 3
VBlank periods before we start examining the display registers to see
if the pageflip happened, but we weren't told about it. This converts
an apparent hang into a visual glitch.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 45 +++
drivers/gpu/drm/i915/i915_irq.c | 56 -
drivers/gpu/drm/i915/intel_display.c | 15 +++--
drivers/gpu/drm/i915/intel_drv.h | 10 ++
4 files changed, 114 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 92d5605..2879ab1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -33,6 +33,7 @@
#include drm.h
#include i915_drm.h
#include i915_drv.h
+#include intel_drv.h
#define DRM_I915_RING_DEBUG 1
@@ -121,6 +122,49 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
return 0;
}
+static int i915_gem_pageflip_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ unsigned long flags;
+ struct intel_crtc *crtc;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+ const char *pipe = crtc-pipe ? B : A;
+ const char *plane = crtc-plane ? B : A;
+ struct intel_unpin_work *work;
+
+ spin_lock_irqsave(dev-event_lock, flags);
+ work = crtc-unpin_work;
+ if (work == NULL) {
+ seq_printf(m, No flip due on pipe %s (plane %s)\n,
+ pipe, plane);
+ } else {
+ if (!work-pending) {
+ seq_printf(m, Flip queued on pipe %s (plane
%s)\n,
+ pipe, plane);
+ } else {
+ seq_printf(m, Flip pending (waiting for vsync)
on pipe %s (plane %s)\n,
+ pipe, plane);
+ }
+ seq_printf(m, %d vblanks before missed interrupt
check, %d prepares\n, work-stall_check_vblanks, work-pending);
+ if (work-old_fb_obj) {
+ struct drm_i915_gem_object *obj_priv =
to_intel_bo(work-old_fb_obj);
+ if(obj_priv)
+ seq_printf(m, Old framebuffer
gtt_offset 0x%08x\n, obj_priv-gtt_offset );
+ }
+ if (work-pending_flip_obj) {
+ struct drm_i915_gem_object *obj_priv =
to_intel_bo(work-pending_flip_obj);
+ if(obj_priv)
+ seq_printf(m, New framebuffer
gtt_offset 0x%08x\n, obj_priv-gtt_offset );
+ }
+ }
+ spin_unlock_irqrestore(dev-event_lock, flags);
+ }
+
+ return 0;
+}
+
static int i915_gem_request_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -777,6 +821,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_gem_active, i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
{i915_gem_flushing, i915_gem_object_list_info, 0, (void *)
FLUSHING_LIST},
{i915_gem_inactive, i915_gem_object_list_info, 0, (void *)
INACTIVE_LIST},
+ {i915_gem_pageflip, i915_gem_pageflip_info, 0},
{i915_gem_request, i915_gem_request_info, 0},
{i915_gem_seqno, i915_gem_seqno_info, 0},
{i915_gem_fence_regs, i915_gem_fence_regs_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 16861b8..893cd77 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -887,6 +887,54 @@ static void i915_handle_error(struct drm_device *dev, bool
wedged)
queue_work(dev_priv-wq, dev_priv-error_work);
}
+static void i915_pageflip_stall_check(struct drm_device *dev, int pipe)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
+ int plane = intel_crtc-plane;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long flags;
+ bool stall_detected = false;
+ struct drm_i915_gem_object *obj_priv;
+
+ /* Ignore early vblank irqs */
+ if (intel_crtc == NULL)
+ return
Re: [Intel-gfx] [PATCH] drm/agp/i915: trim stolen space to 32M
On Wednesday 7 July 2010, Jesse Barnes jbar...@virtuousgeek.org wrote:
Some BIOSes will claim a large chunk of stolen space. Unless we
reclaim it, our aperture for remapping buffer objects will be
constrained. So clamp the stolen space to 32M and ignore the rest.
I'm not sure that this changelog fits the patch - if I'm understanding the code
correctly, you're clamping to 16M, not 32M.
Apart from that, the code looks sensible.
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index f97122a..54ed0e1 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -25,6 +25,10 @@
#define USE_PCI_DMA_API 1
#endif
+/* Max amount of stolen space, anything above will be returned to Linux */
+int intel_max_stolen = 16 * 1024 * 1024;
This is 16M, not 32M
+EXPORT_SYMBOL(intel_max_stolen);
+
static const struct aper_size_info_fixed intel_i810_sizes[] =
{
{64, 16384, 4},
@@ -710,7 +714,12 @@ static void intel_i830_init_gtt_entries(void)
break;
}
}
- if (gtt_entries 0) {
+ if (!local gtt_entries intel_max_stolen) {
+ dev_info(agp_bridge-dev-dev,
+ detected %dK stolen memory, trimming to %dK\n,
+ gtt_entries / KB(1), intel_max_stolen / KB(1));
+ gtt_entries = intel_max_stolen / KB(4);
This appears to limit to intel_max_stolen bytes, not intel_max_stolen * 2
bytes.
+ } else if (gtt_entries 0) {
dev_info(agp_bridge-dev-dev, detected %dK %s memory\n,
gtt_entries / KB(1), local ? local : stolen);
gtt_entries /= KB(4);
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index e2dd903..69e25ab 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -40,6 +40,8 @@
#include linux/vga_switcheroo.h
#include linux/slab.h
+extern int intel_max_stolen; /* from AGP driver */
+
/**
* Sets up the hardware status page for devices that need a physical
address * in the register.
@@ -2105,6 +2107,12 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags) if (ret)
goto out_iomapfree;
+ if (prealloc_size intel_max_stolen) {
+ DRM_INFO(detected %dM stolen memory, trimming to %dM\n,
+ prealloc_size 20, intel_max_stolen 20);
+ prealloc_size = intel_max_stolen;
And again here, you appear to limit to intel_max_stolen, not to twice that.
+ }
+
dev_priv-wq = create_singlethread_workqueue(i915);
if (dev_priv-wq == NULL) {
DRM_ERROR(Failed to create our workqueue.\n);
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/agp/i915: trim stolen space to 32M
On Thursday 8 July 2010, Jesse Barnes jbar...@virtuousgeek.org wrote:
Some BIOSes will claim a large chunk of stolen space. Unless we
reclaim it, our aperture for remapping buffer objects will be
constrained. So clamp the stolen space to 32M and ignore the rest.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15469 among others.
Adding the ignored stolen memory back into the general pool using the
memory hotplug code is left as an exercise for the reader.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
FWIW, given how simple the code actually is:
Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.com
---
drivers/char/agp/intel-gtt.c| 11 ++-
drivers/gpu/drm/i915/i915_dma.c |8
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index f97122a..a61a87c 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -25,6 +25,10 @@
#define USE_PCI_DMA_API 1
#endif
+/* Max amount of stolen space, anything above will be returned to Linux */
+int intel_max_stolen = 32 * 1024 * 1024;
+EXPORT_SYMBOL(intel_max_stolen);
+
static const struct aper_size_info_fixed intel_i810_sizes[] =
{
{64, 16384, 4},
@@ -710,7 +714,12 @@ static void intel_i830_init_gtt_entries(void)
break;
}
}
- if (gtt_entries 0) {
+ if (!local gtt_entries intel_max_stolen) {
+ dev_info(agp_bridge-dev-dev,
+ detected %dK stolen memory, trimming to %dK\n,
+ gtt_entries / KB(1), intel_max_stolen / KB(1));
+ gtt_entries = intel_max_stolen / KB(4);
+ } else if (gtt_entries 0) {
dev_info(agp_bridge-dev-dev, detected %dK %s memory\n,
gtt_entries / KB(1), local ? local : stolen);
gtt_entries /= KB(4);
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index e2dd903..69e25ab 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -40,6 +40,8 @@
#include linux/vga_switcheroo.h
#include linux/slab.h
+extern int intel_max_stolen; /* from AGP driver */
+
/**
* Sets up the hardware status page for devices that need a physical
address * in the register.
@@ -2105,6 +2107,12 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags) if (ret)
goto out_iomapfree;
+ if (prealloc_size intel_max_stolen) {
+ DRM_INFO(detected %dM stolen memory, trimming to %dM\n,
+ prealloc_size 20, intel_max_stolen 20);
+ prealloc_size = intel_max_stolen;
+ }
+
dev_priv-wq = create_singlethread_workqueue(i915);
if (dev_priv-wq == NULL) {
DRM_ERROR(Failed to create our workqueue.\n);
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Regression in i965 Mesa driver caused by commit c7c64d97836c71eaf2ee3fc6d384877170b8c844
Hello Kristian, Your commit: commit c7c64d97836c71eaf2ee3fc6d384877170b8c844 Author: Kristian Høgsberg k...@bitplanet.net Date: Tue Jun 1 14:33:43 2010 -0400 intel: Fallback to meta if we're asked to CopyTexImage2D from RGB to RGBA The pixel transfer rules state that we must set alpha to 1.0 in this case which we can't easily do with the blitter. We can do to passes: one that sets the alpha to 0xff and one that copies the RGB bits or we can just use the 3D engine. Neither approach seems worth it for this case. has broken my use of Mesa to snapshot the display using an FBO. In my code, I do (where width and height are the size of the screen, snapshot_width and snapshot_height are the target size of my snapshot): glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, framebuffer_object ); glBindRenderbufferEXT( GL_RENDERBUFFER_EXT, renderbuffer ); glRenderbufferStorageEXT( GL_RENDERBUFFER_EXT, GL_RGB8, snapshot_width, snapshot_height ); glFramebufferRenderbufferEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_RENDERBUFFER_EXT, renderbuffer ); glBindFramebufferEXT( GL_READ_FRAMEBUFFER_EXT, 0 ); glBlitFramebufferEXT( 0, 0, width, height, 0, snapshot_height, snapshot_width, 0, GL_COLOR_BUFFER_BIT, GL_LINEAR ); glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 ); to get a snapshot of the current screen contents in my FBO. I then have a separate thread (using its own GL context) get the pixel contents of the FBO with glReadPixels() and turn it into a PNG file. With current Mesa master (eb7ef433bbbeabda963e74adf0ef61c47883f292), the glBlitFramebufferEXT() call causes my fullscreen application to get stuck - the front buffer and back buffer at the time of the glBlitFramebufferEXT() call swap back and forth as I call glXSwapBuffers(), but no further changes to screen contents occur. The FBO appears to have the correct contents the first time I do this, but not on future attempts to snapshot the screen. git bisect fingered this commit as the cause - reverting just this commit makes things work as they used to. Is there a better fix (either to my code or to Mesa) that I should work on; I can't glReadPixels() directly from the main framebuffer, as (not entirely surprisingly) this causes my rendering thread to stall for a short but visible period - and while I can stall the snapshotting thread indefinitely, I'm not permitted to stall the rendering thread. I've tried using both GL_RGBA8 and GL_RGB8 renderbuffers, which hasn't helped - but it looks from the code like it's the format of the source buffer (the system framebuffer) that matters, not the format of the destination buffer. -- Thanks in advance for any advice you can offer, Simon Farnsworth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
On Wednesday 19 May 2010, Zou, Nanhai nanhai@intel.com wrote: Currently we do not find any regression or slowness. We have been testing full HD video test along with regression tests for more than 1 month. The only slowness we find now is with playing 2 1080p H.264 video. That was caused by too much GPU memory usage which is not related to the interface. And are you utterly confident that if anyone finds a way to use your new ioctl to (e.g.) hang the GPU, stall rendering indefinitely waiting for media engine events that will never happen, or perhaps bypass system security, you can fix it without changing the ioctl interface to userspace? If not, you have a problem, and need to redesign the ioctl. Bear in mind that I don't have to use VAAPI to call your ioctl; I can write evil code that calls it directly. On the other hand, you can't remove the ioctl later - users will want to use older VAAPI versions with new kernels, so that they can upgrade without too much fear of regression. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
On Wednesday 19 May 2010, Eric Anholt eric.anh...@intel.com wrote: On Wed, 19 May 2010 10:00:10 +0100, Simon Farnsworth simon.farnswo...@onelan.com wrote: Bear in mind that I don't have to use VAAPI to call your ioctl; I can write evil code that calls it directly. On the other hand, you can't remove the ioctl later - users will want to use older VAAPI versions with new kernels, so that they can upgrade without too much fear of regression. OK, now you're going over the top. The GPU can't schedule[1], is turing complete, and you hand it programs. You can hang it with or without his interface. If you don't want to be able to do that, then don't let non-root use the DRI. Fair enough, and my apologies for going overboard - my intended point is that just because VAAPI is the only planned user of this ioctl doesn't mean that it's OK to get the userspace/kernel interface wrong. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
On Tuesday 18 May 2010, Zou, Nanhai nanhai@intel.com wrote: -Original Message- From: Daniel Vetter [mailto:dan...@ffwll.ch] Sent: 2010年5月18日 1:43 Well, that's exactly the problem. You simply can't optimize a kernel interface once it's in use. And if you try to, your users will get the pitchforks and scream bloody murder trying to get you ;) So we need to get these patches right (at least the semantics of the interface) beforehand. Hi, Since VAAPI will be the only client for this multi ring buffer for a period of time. We may not have so much pain to optimize both kernel and user space. This approach touches little user space interface, only 1 new flag is added to IOCTL. We have new kinds of ring buffer to come in SandyBridge and later chips. Since we are still enabling SandyBridge. I can not for cast how those rings would be synchronized to each other. We may use minimum API to work first. Be aware that you cannot expect users to bump both their userspace VAAPI library and their kernel at the same time; there are good reasons for this. If you do tie the VAAPI library version and the kernel version too tightly together, you get into a position where users get upset - if I bump my kernel from 2.6.32 to 2.6.36 to get support for a new WiFi chipset and a new TV capture card, I'm likely to get quite upset if I then have to also respin my userspace. There are also issues around bisection as a tool for isolating regressions - if I have to carefully bump userspace and kernel in lock-step, it's very difficult for me to bisect down until I find the changeset that broke things. As most of the bugs you'll get reported from users like me won't reproduce in your lab, making it harder for me to give you helpful information is not in your interests. In conclusion, as Daniel's been saying, you must get the kernel interface mostly right first time. If it's too slow, a new interface to improve performance isn't hard to add in parallel to the old interface; if the old interface is a DoS vector or worse, you're going to get stuck in a very bad place. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Unexpected behaviour of xrandr and the Intel driver on monitor hotplug
On Tuesday 18 May 2010, Adam Jackson a...@redhat.com wrote: On Mon, 2010-05-17 at 12:13 +0100, Simon Farnsworth wrote: The first bit of misbehaviour I'm seeing is caching of EDID across hotplug events. If I boot my system with no display attached, I correctly see no EDID property. When I connect a monitor via VGA, using cabling that supports DDC, I see EDID. When I unplug the monitor, I continue to see the old EDID. When I then plug in using a cable that doesn't support DDC, I see an extra mode appear in the mode list, but the EDID has not changed. Connecting using the original cable, or disconnecting cables completely removes this extra mode. commit 725398322d05486109375fbb85c3404108881e17 Author: Zhao Yakui yakui.z...@intel.com Date: Thu Mar 4 08:25:55 2010 + Adding that to my kernel build nearly fixed things for me. I still can't explain why the 848x480 mode appears when I connect a DDC-crippled cable to the GMA 945, but I can live with that, I suspect (it looks to be XServer side, anyway, and I'm about to have to generate patches there, as I don't want default modes). -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Unexpected behaviour of xrandr and the Intel driver on monitor hotplug
363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1280x1024 60.0 1024x768 60.0 800x60060.3 640x48060.0 DVI1 disconnected (normal left inverted right x axis y axis) The second misbehaviour I'm seeing is that the list of modes isn't predictable in the presence of hotplug. If I boot without EDID available, I get one list of modes; if I make EDID available by changing cables, I get a second list of modes. If I then change cables back to the no EDID cable, I get a third list of modes - I was expecting the first list again. In xrandr terms: Boot without cable (it'd be nice to know how to trim this modelist, for backwards compatibility reasons, but I can live with the full list): Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 disconnected 1360x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm NTB-vesa_cvt-1360x768 59.8*+ 1600x1200 60.0 1400x1050 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x60060.3 640x48060.0 59.9 DVI1 disconnected (normal left inverted right x axis y axis) Connect monitor with EDID: # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 connected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832 363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1920x1200 60.0 + 1600x1200 60.0 1280x1024 60.0 1024x768 60.0 800x60060.3 640x48060.0 DVI1 disconnected (normal left inverted right x axis y axis) Disconnect monitor (why've I lost lots of modes that I had before I connected the monitor? Why do I still have EDID?): # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 disconnected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832 363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1280x1024 60.0 1024x768 60.0 800x60060.3 640x48060.0 DVI1 disconnected (normal left inverted right x axis y axis) Connect a monitor without DDC support (why do I have EDID still? Where's 848x480 from?): # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 connected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832 363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1280x1024 60.0 1024x768 60.0 800x60060.3 848x48060.0 640x48060.0 59.9 DVI1 disconnected (normal left inverted right x axis y axis) Disconnect again (why's 848x480 no longer present?): # xrandr --prop Screen 0: minimum 320 x 200, current 1360 x 768, maximum 4096 x 4096 VGA1 disconnected 1360x768+0+0 (normal left inverted right x axis y axis) 519mm x 324mm EDID: 000010ac29a053315933 111201030e342078eab325ac5130b426 105054a54b008180a940714f01010101 010101010101283c80a070b023403020 36000744211a00ff00435832 363838344e335931530a00fc0044 454c4c20323430385746500a00fd 00384c1e5311000a202020202020005f NTB-vesa_cvt-1360x768 59.8*+ 1280x1024 60.0 1024x768 60.0 800x60060.3 640x48060.0 DVI1 disconnected (normal left inverted right x axis y axis) Should I file bugs for these, and start chasing down what's going on, or is this expected behaviour? If it's expected, can someone explain why I'm seeing what I'm seeing? -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com
Re: [Intel-gfx] Page flipping not working as expected for compositing - engineering resource available to help fix it
On Monday 10 May 2010, Jesse Barnes jbar...@virtuousgeek.org wrote: What about the indirect bug? Did that also go away when you fixed the perms issue? If not, that sounds like a serious issue, in indirect mode the swap interval should still be honored I think... In indirect mode, the swap interval was being honoured by the page flipping code, but SwapBuffers wasn't blocking; instead, I appeared to be able to continue to draw to the backbuffer after issuing SwapBuffers in my application. In direct mode, SwapBuffers behaved as I'd expect - I blocked as soon as I tried to draw, until the swap had completed. Guessing wildly, when I SwapBuffers in a direct context, I ask the kernel to stall me as soon as I draw to the back buffer (which is presumably still in use as the real front buffer). When I'm in an indirect context, it's the X server process that calls the kernel, which can't block, because that would stop it servicing other clients, and it's not blocking me until it discovers asynchronously that the kernel has pageflipped. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Page flipping not working as expected for compositing - engineering resource available to help fix it
On Monday 10 May 2010, Simon Farnsworth simon.farnswo...@onelan.com wrote: On Friday 7 May 2010, Simon Farnsworth simon.farnswo...@onelan.com wrote: I've attached my test program (it's based on our C++ OpenGL compositor, but cut down to just test OpenGL pageflipping) as performance.c, and my test X stack's Xorg.0.log after one run of performance -indirect (which ran for 573 frames). I'm using a 32-bit PAE kernel - I can add information as required, and I'm happy to run tests or experiments for people. 2) How should I go about fixing compositing? Should I fix indirect rendering to use pageflipping (and if so, where do I start looking for the code that's getting it wrong), or should I make TFP work when direct rendering (and again, where should I start looking)? Is this the expected behaviour when indirect rendering? If so, I'll dive back into the stack and see if I can work out why TFP and direct rendering don't interact nicely. If not, roughly where should I look to fix it? I've found why direct rendering and TFP don't interact nicely, and it's a client side error. Briefly, my compositor was being started as our signage user, who does not have access to /dev/dri/card0, so was falling back to swrast. When you're using swrast, TFP only appears to work for pixmaps you create, not for compositing pixmaps. Sorry for the noise, -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad render errors (Re: Page flipping not working as expected for compositing - engineering resource available to help fix it)
On Friday 7 May 2010, Andrew Lutomirski l...@mit.edu wrote: On Fri, May 7, 2010 at 9:07 AM, Simon Farnsworth simon.farnswo...@onelan.com wrote: Hello, I don't know exactly what this program is supposed to do, but here's what it does right now, on GM45 and F13 with -linus be1066bbcd443a65df312fdecea7e4959adedb45 (approx 2.6.34-rc6). If it's working perfectly (I run it as the only X client, no window manager or anything else running), you should see alternating frames of yellow and pink at the frame rate on the screen, with no tearing visible (tearing would be visible as a frame that's part pink, part yellow). Assuming your refresh rate is 60Hz, you should also have text output once a second, printing lines like Last 60 frames rate 59.99 fps. If it's failing to maintain 60 frames a second, you will see messages where the first line is either Frames too fast or Frames too slow, and the second line is an fps number. Simon (Note: I have an extra patch to turn off all digital outputs except LVDS -- I still need that to use my laptop reliably.) compiz, no -indirect: solid color. metacity, no -indirect: annoying flashing. metacity, -indirect: annoying flashing. compiz, -indirect: solid color. But last time I ran it, X blew up quite thoroughly - no caps lock, no VT switching, and no sysrq+r response. sysrq+k killed X, but after a couple rounds, X wouldn't respond without lagging after restarting it. dmesg had: [61997.737046] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61997.737057] render error detected, EIR: 0x [61997.737414] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415947 at 1415940) [61998.890100] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61998.890105] render error detected, EIR: 0x [61998.890129] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415949 at 1415940) [61999.741248] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61999.741260] render error detected, EIR: 0x [61999.741317] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415953 at 1415940) [61999.963257] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61999.963261] render error detected, EIR: 0x [62000.331262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62000.331272] render error detected, EIR: 0x [62000.950043] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62000.950048] render error detected, EIR: 0x [62000.950210] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415964 at 1415940) [62001.413288] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62001.413293] render error detected, EIR: 0x [62001.413306] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415969 at 1415940) [62001.509261] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62001.509270] render error detected, EIR: 0x [62001.631262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62001.631272] render error detected, EIR: 0x [62002.006281] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62002.006291] render error detected, EIR: 0x [62002.982266] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62002.982279] render error detected, EIR: 0x [62002.982327] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415975 at 1415940) [62003.079261] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.079271] render error detected, EIR: 0x [62003.201262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.201272] render error detected, EIR: 0x [62003.323012] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.323022] render error detected, EIR: 0x [62003.567013] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.567023] render error detected, EIR: 0x [62003.691262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.691272] render error detected, EIR: 0x [62004.425263] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62004.425273] render error detected, EIR: 0x [62004.915013] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62004.915023] render error detected, EIR: 0x [62005.660013] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62005.660023] render error detected, EIR: 0x [62006.404052] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
