[Intel-gfx] ironlake wierdness bisection result
Okay I spent today bisecting this and although I'm not 100% sure I got it right the whole way down, I think where I landed seems sane, so I said I'd share This seems to cause the blank rendering zones people have been reporting. Dave. commit c07496fa61f4c5cb2addd1c57f6b22fcaeea2eeb Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Apr 13 15:51:51 2012 +0200 drm/i915: don't pwrite tiled objects through the gtt ... we will botch up the bit17 swizzling. Furthermore tiled pwrite is a (now) unused slowpath, so no one really cares. This fixes the last swizzling issues I have with i-g-t on my bit17 swizzling i915G. No regression, it's been broken since the dawn of gem, but it's nice for regression tracking when really _all_ i-g-t tests work. Actually this is not true, Chris Wilson noticed while reviewing this patch that the commit commit d9e86c0ee60f323e890484628f351bf50fa9a15d Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Nov 10 16:40:20 2010 + drm/i915: Pipelined fencing [infrastructure] contained a functional change that broke things. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ironlake wierdness bisection result
On Tue, Sep 18, 2012 at 4:43 PM, Dave Airlie airl...@gmail.com wrote: Okay I spent today bisecting this and although I'm not 100% sure I got it right the whole way down, I think where I landed seems sane, so I said I'd share This seems to cause the blank rendering zones people have been reporting. Though I'm of course having trouble reproducing the pain now, so it might all be lies, but hey its a better starting point than none, any way it could make sense to be this commit? I'll do another round of bisecton tomorrow and see if I can find a better test. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] [RESEND] console: implement lockdep support for console_lock
On Tue, 18 Sep 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map console_lock_dep_map = {
+ .name = console_lock
+};
+#endif
static?
BR,
Jani.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
On Mon, 17 Sep 2012, Adam Jackson a...@redhat.com wrote:
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ace757a..92939bd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -39,6 +39,7 @@
#include drm_dp_helper.h
#define DP_RECEIVER_CAP_SIZE 0xf
+#define DP_MAX_DOWNSTREAM_PORTS 0xf
#define DP_LINK_STATUS_SIZE 6
#define DP_LINK_CHECK_TIMEOUT(10 * 1000)
@@ -56,6 +57,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+ uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
bool is_pch_edp;
@@ -1968,12 +1970,25 @@ static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp-dpcd,
-sizeof(intel_dp-dpcd))
- (intel_dp-dpcd[DP_DPCD_REV] != 0)) {
- return true;
- }
+sizeof(intel_dp-dpcd) == 0))
Misplaced brace, isn't it? You're passing sizeof(intel_dp-dpcd) == 0
as length.
BR,
Jani.
+ return false; /* aux transfer failed */
- return false;
+ if (intel_dp-dpcd[DP_DPCD_REV] == 0)
+ return false; /* DPCD not present */
+
+ if (!(intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT]
+ DP_DWN_STRM_PORT_PRESENT))
+ return true; /* native DP sink */
+
+ if (intel_dp-dpcd[DP_DPCD_REV] == 0x10)
+ return true; /* no per-port downstream info */
+
+ if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
+intel_dp-downstream_ports,
+DP_MAX_DOWNSTREAM_PORTS) == 0)
+ return false; /* downstream port status fetch failed */
+
+ return true;
}
static void
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Assert that the exec object lookup table is a power-of-two
As we make the simplification of using a power-of-two size for the
execbuffer handle-to-object TLB, we should validate that this is actually
true and so clarify that premise.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8186f63..6a2f3e5 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -44,6 +44,7 @@ eb_create(int size)
{
struct eb_objects *eb;
int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
+ BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));
while (count size)
count = 1;
eb = kzalloc(count*sizeof(struct hlist_head) +
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: ioremap the right range for the registers on gen2
Fixes regression from commit 1ca673954355eb4105ef7fccdd770e69d4d3d1ef Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Sep 14 11:57:46 2012 +0100 drm/i915: Limit the ioremap of the PCI bar to the registers which only mapped 64k of the register BAR when the full 512k was required. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- drivers/gpu/drm/i915/i915_dma.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index f0cad84..5779e8f 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1524,13 +1524,15 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) if (IS_BROADWATER(dev) || IS_CRESTLINE(dev)) dma_set_coherent_mask(dev-pdev-dev, DMA_BIT_MASK(32)); - /* Restrict iomap to avoid clobbering the GTT which we want WC mapped. -* Do not attempt to map the whole BAR! -*/ mmio_bar = IS_GEN2(dev) ? 1 : 0; - if (info-gen 3) - mmio_size = 64*1024; - else if (info-gen 5) + /* Before gen4, the registers and the GTT are behind different BARs. +* However, from gen4 onwards, the registers and the GTT are shared +* in the same BAR, so we want to restrict this ioremap from +* clobbering the GTT which we want ioremap_wc instead. Fortunately, +* the register BAR remains the same size for all the earlier +* generations up to Ironlake. +*/ + if (info-gen 5) mmio_size = 512*1024; else mmio_size = 2*1024*1024; -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix OOPS in lid_notify
On Mon, 17 Sep 2012 14:38:14 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 17 Sep 2012 22:27:21 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: This goes back to commit c1c7af60892070e4b82ad63bbfb95ae745056de0 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Sep 10 15:28:03 2009 -0700 drm/i915: force mode set at lid open time It was used to fix an issue on a i915GM based Thinkpad X41, which somehow clobbered the modeset state at lid close time. Since then massive amounts of things changed: Tons of fixes to the modeset sequence, OpRegion support, better integration with the acpi code. Especially OpRegion /should/ allow us to control the display hw cooperatively with the firmware, without the firmware clobbering the hw state behind our backs. So it's dubious whether we still need this. The second issue is that it's unclear who's responsibility it actually is to restore the mode - Chris Wilson suggests to just emit a hotplug event and let userspace figure things out. The real reason I've stumbled over this is that the new modeset code breaks drm_helper_resume_force_mode - it OOPSes derefing a NULL vfunc pointer. The reason this wasn't caught in testing earlier is that in commit c9354c85c1c7bac788ce57d3c17f2016c1c45b1d Author: Linus Torvalds torva...@linux-foundation.org Date: Mon Nov 2 09:29:55 2009 -0800 i915: fix intel graphics suspend breakage due to resume/lid event confusion logic was added to _not_ restore the modeset state after a resume. And since most machines are configured to auto-suspend on lid-close, this neatly papered over the issue. Summarizing, this shouldn't be required on any platform supporting OpRegion. And none of the really old machines I have here seem to require it either. Hence I'm inclined to just rip it out. But in case that there are really firmwares out there that clobber the hw state, replace it with a call to intel_modset_check_state. This will ensure that we catch any issues as soon as they happen. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_lvds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index b1b36de..4e22d46 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -581,7 +581,7 @@ static int intel_lid_notify(struct notifier_block *nb, unsigned long val, dev_priv-modeset_on_lid = 0; mutex_lock(dev-mode_config.mutex); - drm_helper_resume_force_mode(dev); + intel_modeset_check_state(dev); mutex_unlock(dev-mode_config.mutex); return NOTIFY_OK; Yeah, I *hope* we don't need this anymore. Needs some good tested-by activity on old machines especially (some of them definitely do mess with display regs across lid events). Not even a squeak on my 855gm. On a positive note modeset-rework is able to light the LVDS even when that machine is booted with its lid close, which is a first! It complains vehemently in the process though. Acked-by: Jesse Barnes jbar...@virtuousgeek.org Tested-by: Chris Wilson ch...@chris-wilson.co.uk # 855gm with an evil BIOS -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Valid DP connection without EDID?
At Mon, 17 Sep 2012 12:24:36 -0400, Adam Jackson wrote: On Mon, 2012-09-17 at 11:32 +0200, Takashi Iwai wrote: At Mon, 17 Sep 2012 19:11:34 +1000, Dave Airlie wrote: On Mon, Sep 17, 2012 at 6:28 PM, Takashi Iwai ti...@suse.de wrote: At Mon, 17 Sep 2012 18:21:47 +1000, Dave Airlie wrote: On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai ti...@suse.de wrote: At Fri, 14 Sep 2012 11:25:03 -0400, Adam Jackson wrote: Can you be more specific here? What DPCD does it return? It shows DPCD: 110a820100030181 So dpcd[0x5] is 0x03, and drm_dp_helper.h says: #define DP_DOWNSTREAMPORT_PRESENT 0x005 # define DP_DWN_STRM_PORT_PRESENT (1 0) # define DP_DWN_STRM_PORT_TYPE_MASK 0x06 /* 00b = DisplayPort */ /* 01b = Analog */ /* 10b = TMDS or HDMI */ /* 11b = Other */ # define DP_FORMAT_CONVERSION (1 3) So there we go, it's a branch device with VGA downstream of it. We need to figure out the connectivity of the downstream port. Right. It's indeed a VGA. Checking DPCD bits might work, but I have no exact spec of DPCD, so no idea whether the above is really wrong or not. Is there a VGA port on the docking station, it might have a DP-VGA in it, or dual-link DVI port. Ah, right, that's the missing piece! It's a DP-VGA conversion indeed. Plugging to a VGA connector appears as DP2. Oh well, I didn't think of this possibility at all. But then this makes me wonder how to solve the problem at best. It's obviously a bogus connection status returned from the driver. DP2 advertises itself as if connected. I wouldn't quite say it's bogus, more that we're describing the connection status of the nearest DP device as if it were the connection status of the whole wire. True. However, from the end user's perspective, it's not easily understandable why it's DP2 although we know it's a VGA and why it's constantly stated as connected. Or, just think from the user-space POV. The only information it gets so far is it's DP-2, and it's always connected without EDID. It's a bit too little information to make apps judging the situation correctly. Something should be corrected, or the driver needs to expose more information. I started a patch series for this a bit ago, I'll send it on momentarily. Thanks! I evaluated it now (with a typo fix suggested by Jani). Unfortunately, it doesn't improve the situation. The fetch of downstream ports succeeds, and it gets 0x09. So, this indicates again it's a VGA downstream port. But that's all, so far. The 0x09 is reported no matter whether the VGA cable is plugged or not, so this can't be used as the detection of the downstream port plug state. Any alternative way to detect the downstream VGA plug state? thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Valid DP connection without EDID?
On Tue, 2012-09-18 at 13:01 +0200, Takashi Iwai wrote:
I started a patch series for this a bit ago, I'll send it on
momentarily.
Thanks! I evaluated it now (with a typo fix suggested by Jani).
Unfortunately, it doesn't improve the situation.
The fetch of downstream ports succeeds, and it gets 0x09. So, this
indicates again it's a VGA downstream port. But that's all, so far.
The 0x09 is reported no matter whether the VGA cable is plugged or
not, so this can't be used as the detection of the downstream port
plug state.
Sorry, there's a bug in the patch. link_configuration[0] is not
DP_SINK_COUNT, I have no idea why I thought it was. Try this on top of
the series:
===
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9809c53..b6b9a18 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2098,15 +2098,22 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
-
+
/* if there's no downstream port, we're done */
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
/* If we're HPD-aware, SINK_COUNT changes dynamically */
hpd = !!(intel_dp-downstream_ports[0] DP_DS_PORT_HPD);
- if (hpd (intel_dp-link_configuration[0] DP_SINK_COUNT_MASK))
- return connector_status_connected;
+ if (hpd) {
+ uint8_t sink_count;
+ if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
+ sink_count, 1))
+ return connector_status_unknown;
+ sink_count = DP_SINK_COUNT_MASK;
+ return sink_count ? connector_status_connected
+ : connector_status_disconnected;
+ }
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(intel_dp-adapter))
===
If that doesn't work then the HPD-capable bit is useless - or if we're
lucky just needs quirking by branch OUI - and we should just fall
through to the drm_probe_ddc() path. What is the branch OUI, anyway?
There's a third possibility, which is that HPD does work but that we're
not doing enough to enable it. The DP 1.1a spec has a non-normative
appendix describing one way a device could go about doing that as an
optional feature, but the method described does not match how we're
currently handling sink-specific IRQs. I have no idea what the 1.2 spec
says on this point though.
- ajax
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] Valid DP connection without EDID?
At Tue, 18 Sep 2012 10:04:33 -0400,
Adam Jackson wrote:
On Tue, 2012-09-18 at 13:01 +0200, Takashi Iwai wrote:
I started a patch series for this a bit ago, I'll send it on
momentarily.
Thanks! I evaluated it now (with a typo fix suggested by Jani).
Unfortunately, it doesn't improve the situation.
The fetch of downstream ports succeeds, and it gets 0x09. So, this
indicates again it's a VGA downstream port. But that's all, so far.
The 0x09 is reported no matter whether the VGA cable is plugged or
not, so this can't be used as the detection of the downstream port
plug state.
Sorry, there's a bug in the patch. link_configuration[0] is not
DP_SINK_COUNT, I have no idea why I thought it was. Try this on top of
the series:
===
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9809c53..b6b9a18 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2098,15 +2098,22 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
-
+
/* if there's no downstream port, we're done */
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
/* If we're HPD-aware, SINK_COUNT changes dynamically */
hpd = !!(intel_dp-downstream_ports[0] DP_DS_PORT_HPD);
- if (hpd (intel_dp-link_configuration[0] DP_SINK_COUNT_MASK))
- return connector_status_connected;
+ if (hpd) {
+ uint8_t sink_count;
+ if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
+ sink_count, 1))
+ return connector_status_unknown;
+ sink_count = DP_SINK_COUNT_MASK;
+ return sink_count ? connector_status_connected
+ : connector_status_disconnected;
+ }
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(intel_dp-adapter))
===
Woohoo, the patch works!
This also avoids the driver spewing tons of error messages
[drm:intel_dp_i2c_aux_ch] *ERROR* too many retries, giving up
and
[drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
I guess it's because now the driver detects the disconnection
properly. The hotplug / -unplug also seems working.
Could you brush up and resend the patches for merging to 3.7 kernel?
Or, would you like to fix the multiple branch devices first?
When you resubmit patches, feel free to add:
Tested-by: Takashi Iwai ti...@suse.de
Thanks!
Takashi
If that doesn't work then the HPD-capable bit is useless - or if we're
lucky just needs quirking by branch OUI - and we should just fall
through to the drm_probe_ddc() path. What is the branch OUI, anyway?
There's a third possibility, which is that HPD does work but that we're
not doing enough to enable it. The DP 1.1a spec has a non-normative
appendix describing one way a device could go about doing that as an
optional feature, but the method described does not match how we're
currently handling sink-specific IRQs. I have no idea what the 1.2 spec
says on this point though.
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Valid DP connection without EDID?
On Tue, 2012-09-18 at 16:32 +0200, Takashi Iwai wrote: Woohoo, the patch works! \o/ Could you brush up and resend the patches for merging to 3.7 kernel? Or, would you like to fix the multiple branch devices first? I'm not too worried about branch devices with multiple downstreams just yet. I don't know of any you can buy anyway. Even if you could there's some open questions about how we'd present them to the user, and the whole concept will need rethinking once we get multiple-stream support. The only case I can think of where this might not work sanely is an active DP-HDMI adaptor with sinks for both audio and video? But again, I don't think those exist. If they do you'd expect both the A and V sinks to plug simultaneously, so sink count should always be either zero or non-zero, so it should work anyway. When you resubmit patches, feel free to add: Tested-by: Takashi Iwai ti...@suse.de Will do, thanks for testing! - ajax 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
[Intel-gfx] [PATCH 1/4] drm: Export drm_probe_ddc()
Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..a1895ba 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -376,13 +376,14 @@ out:
* \param adapter : i2c device adaptor
* \return 1 on success
*/
-static bool
+bool
drm_probe_ddc(struct i2c_adapter *adapter)
{
unsigned char out;
return (drm_do_probe_ddc_edid(adapter, out, 0, 1) == 0);
}
+EXPORT_SYMBOL(drm_probe_ddc);
/**
* drm_get_edid - get EDID data, if available
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..f5d434b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -862,6 +862,7 @@ extern char *drm_get_tv_subconnector_name(int val);
extern char *drm_get_tv_select_name(int val);
extern void drm_fb_release(struct drm_file *file_priv);
extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct
drm_mode_group *group);
+extern bool drm_probe_ddc(struct i2c_adapter *adapter);
extern struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
extern int drm_add_edid_modes(struct drm_connector *connector, struct edid
*edid);
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/dp: Update DPCD defines
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP 1.2 for the MST bits. Tested-by: Takashi Iwai ti...@suse.de Signed-off-by: Adam Jackson a...@redhat.com --- include/drm/drm_dp_helper.h | 60 --- 1 files changed, 56 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1744b18c..f9888c3 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -69,16 +69,30 @@ /* 10b = TMDS or HDMI */ /* 11b = Other */ # define DP_FORMAT_CONVERSION (1 3) +# define DP_DETAILED_CAP_INFO_AVAILABLE(1 4) #define DP_MAIN_LINK_CHANNEL_CODING 0x006 #define DP_DOWN_STREAM_PORT_COUNT 0x007 -#define DP_PORT_COUNT_MASK0x0f -#define DP_OUI_SUPPORT(1 7) +# define DP_PORT_COUNT_MASK0x0f +# define DP_MSA_TIMING_PAR_IGNORED (1 6) +# define DP_OUI_SUPPORT(1 7) + +#define DP_I2C_SPEED_CAP 0x00c +# define DP_I2C_SPEED_1K 0x01 +# define DP_I2C_SPEED_5K 0x02 +# define DP_I2C_SPEED_10K 0x04 +# define DP_I2C_SPEED_100K 0x08 +# define DP_I2C_SPEED_400K 0x10 +# define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d #define DP_TRAINING_AUX_RD_INTERVAL 0x00e +/* Multiple stream transport */ +#define DP_MSTM_CAP0x021 +# define DP_MST_CAP(1 0) + #define DP_PSR_SUPPORT 0x070 # define DP_PSR_IS_SUPPORTED1 #define DP_PSR_CAPS 0x071 @@ -93,6 +107,31 @@ # define DP_PSR_SETUP_TIME_MASK (7 1) # define DP_PSR_SETUP_TIME_SHIFT1 +/* + * 0x80-0x8f describe downstream port capabilities, but there are two layouts + * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, + * each port's descriptor is one byte wide. If it was set, each port's is + * four bytes wide, starting with the one byte from the base info. As of + * DP interop v1.1a only VGA defines additional detail. + */ + +/* offset 0 */ +#define DP_DOWNSTREAM_PORT_0 0x80 +# define DP_DS_PORT_TYPE_MASK (7 0) +# define DP_DS_PORT_TYPE_DP0 +# define DP_DS_PORT_TYPE_VGA 1 +# define DP_DS_PORT_TYPE_DVI 2 +# define DP_DS_PORT_TYPE_HDMI 3 +# define DP_DS_PORT_TYPE_NON_EDID 4 +# define DP_DS_PORT_HPD(1 3) +/* offset 1 for VGA is maximum megapixels per second / 8 */ +/* offset 2 */ +# define DP_DS_VGA_MAX_BPC_MASK(3 0) +# define DP_DS_VGA_8BPC0 +# define DP_DS_VGA_10BPC 1 +# define DP_DS_VGA_12BPC 2 +# define DP_DS_VGA_16BPC 3 + /* link configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_BW_1_62 0x06 @@ -148,24 +187,37 @@ #define DP_DOWNSPREAD_CTRL 0x107 # define DP_SPREAD_AMP_0_5 (1 4) +# define DP_MSA_TIMING_PAR_IGNORE_EN (1 7) #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108 # define DP_SET_ANSI_8B10B (1 0) +#define DP_I2C_SPEED_CONTROL_STATUS0x109 +/* bitmask as for DP_I2C_SPEED_CAP */ + +#define DP_EDP_CONFIGURATION_SET0x10a + +#define DP_MSTM_CTRL 0x111 +# define DP_MST_EN (1 0) +# define DP_UP_REQ_EN (1 1) +# define DP_UPSTREAM_IS_SRC(1 2) + #define DP_PSR_EN_CFG 0x170 # define DP_PSR_ENABLE (1 0) # define DP_PSR_MAIN_LINK_ACTIVE (1 1) # define DP_PSR_CRC_VERIFICATION (1 2) # define DP_PSR_FRAME_CAPTURE (1 3) +#define DP_SINK_COUNT 0x200 +# define DP_SINK_COUNT_MASK(31 0) +# define DP_SINK_CP_READY (1 6) + #define DP_DEVICE_SERVICE_IRQ_VECTOR 0x201 # define DP_REMOTE_CONTROL_COMMAND_PENDING (1 0) # define DP_AUTOMATED_TEST_REQUEST (1 1) # define DP_CP_IRQ (1 2) # define DP_SINK_SPECIFIC_IRQ (1 6) -#define DP_EDP_CONFIGURATION_SET0x10a - #define DP_LANE0_1_STATUS 0x202 #define DP_LANE2_3_STATUS 0x203 # define DP_LANE_CR_DONE (1 0) -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
v2: Fix parenthesis mismatch, spotted by Jani Nikula
Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ace757a..098119e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -39,6 +39,7 @@
#include drm_dp_helper.h
#define DP_RECEIVER_CAP_SIZE 0xf
+#define DP_MAX_DOWNSTREAM_PORTS 0xf
#define DP_LINK_STATUS_SIZE6
#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
@@ -56,6 +57,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+ uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
bool is_pch_edp;
@@ -1968,12 +1970,25 @@ static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp-dpcd,
- sizeof(intel_dp-dpcd))
- (intel_dp-dpcd[DP_DPCD_REV] != 0)) {
- return true;
- }
+ sizeof(intel_dp-dpcd)) == 0)
+ return false; /* aux transfer failed */
- return false;
+ if (intel_dp-dpcd[DP_DPCD_REV] == 0)
+ return false; /* DPCD not present */
+
+ if (!(intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT]
+ DP_DWN_STRM_PORT_PRESENT))
+ return true; /* native DP sink */
+
+ if (intel_dp-dpcd[DP_DPCD_REV] == 0x10)
+ return true; /* no per-port downstream info */
+
+ if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
+ intel_dp-downstream_ports,
+ DP_MAX_DOWNSTREAM_PORTS) == 0)
+ return false; /* downstream port status fetch failed */
+
+ return true;
}
static void
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
If there's no downstream device, DPCD success is good enough. If
there's a hotplug-capable downstream device, count the number of
connected sinks in DP_SINK_STATUS and return success if it's non-zero.
Otherwise, probe DDC and report appropriately.
v2: Check DP_SINK_STATUS instead of something unrelated to sink status.
Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 35 ++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 098119e..813b771 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2088,11 +2088,44 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
}
}
+/* XXX this is probably wrong for multiple downstream ports */
static enum drm_connector_status
intel_dp_detect_dpcd(struct intel_dp *intel_dp)
{
- if (intel_dp_get_dpcd(intel_dp))
+ uint8_t *dpcd = intel_dp-dpcd;
+ bool hpd;
+ uint8_t type;
+
+ if (!intel_dp_get_dpcd(intel_dp))
+ return connector_status_disconnected;
+
+ /* if there's no downstream port, we're done */
+ if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] DP_DWN_STRM_PORT_PRESENT))
+ return connector_status_connected;
+
+ /* If we're HPD-aware, SINK_COUNT changes dynamically */
+ hpd = !!(intel_dp-downstream_ports[0] DP_DS_PORT_HPD);
+ if (hpd) {
+ uint8_t sink_count;
+ if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
+ sink_count, 1))
+ return connector_status_unknown;
+ sink_count = DP_SINK_COUNT_MASK;
+ return sink_count ? connector_status_connected
+ : connector_status_disconnected;
+ }
+
+ /* If no HPD, poke DDC gently */
+ if (drm_probe_ddc(intel_dp-adapter))
return connector_status_connected;
+
+ /* Well we tried, say unknown for unreliable port types */
+ type = intel_dp-downstream_ports[0] DP_DS_PORT_TYPE_MASK;
+ if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_NON_EDID)
+ return connector_status_unknown;
+
+ /* Anything else is out of spec, warn and ignore */
+ DRM_DEBUG_KMS(Broken DP branch device, ignoring\n);
return connector_status_disconnected;
}
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Valid DP connection without EDID?
At Tue, 18 Sep 2012 10:48:11 -0400, Adam Jackson wrote: On Tue, 2012-09-18 at 16:32 +0200, Takashi Iwai wrote: Woohoo, the patch works! \o/ Could you brush up and resend the patches for merging to 3.7 kernel? Or, would you like to fix the multiple branch devices first? I'm not too worried about branch devices with multiple downstreams just yet. I don't know of any you can buy anyway. Even if you could there's some open questions about how we'd present them to the user, and the whole concept will need rethinking once we get multiple-stream support. The only case I can think of where this might not work sanely is an active DP-HDMI adaptor with sinks for both audio and video? But again, I don't think those exist. If they do you'd expect both the A and V sinks to plug simultaneously, so sink count should always be either zero or non-zero, so it should work anyway. FWIW, I tried an active DP-DVI adapter, and it seems working, too. But the sink count is 1, so it doesn't look like A+V sinks. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
On Tue, 2012-09-18 at 10:58 -0400, Adam Jackson wrote: If there's no downstream device, DPCD success is good enough. If there's a hotplug-capable downstream device, count the number of connected sinks in DP_SINK_STATUS and return success if it's non-zero. Otherwise, probe DDC and report appropriately. v2: Check DP_SINK_STATUS instead of something unrelated to sink status. Ugh, s/STATUS/COUNT/g in the summary, sorry. - ajax 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 7/8] drm/i915: extract pch_pll_set from ironlake_crtc_mode_set
Hi
2012/9/12 Daniel Vetter dan...@ffwll.ch:
On Wed, Sep 12, 2012 at 10:06:35AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
[ ... ]
+ if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
Since the plan is to move all the hsw_crtc_stuff out into it's own
function I'd prefer a !HAS_PCH_LPT check here.
I don't agree with the LPT check. Let me give some more details about
my plan so you can understand why I did this.
My plan was to add even more (HAS_PCH_IBX || HAS_PCH_CPT) checks to
other places of this function and copy them all to the
haswell_crtc_mode_set version since I'm still not sure we'll never
ever have HSW with something older than LPT. After forking the Haswell
version, the plan was to add a WARN(!(HAS_PCH_IBX || HAS_PCH_CPT)) to
ironlake_crtc_mode_set and then remove the checks form it (leaving the
checks on haswell_crtc_mode_set untouched and prepared for the 42 new
PCHs they plan to ship after LPT). This code under the check was made
specifically for IBX/CPT (and PPT) and only tested on it, so I guess
the correct check is check for IBX/CPT.
So, may I keep the IBX/CPT check? Should I change the plan instead?
- intel_crtc-lowfreq_avail = false;
- if (intel_crtc-pch_pll) {
- if (is_lvds has_reduced_clock i915_powersave) {
- I915_WRITE(intel_crtc-pch_pll-fp1_reg, fp2);
- intel_crtc-lowfreq_avail = true;
- } else {
- I915_WRITE(intel_crtc-pch_pll-fp1_reg, fp);
- }
- }
-
Again, you're moving registers around - see the comment about that the
lvds pin pairs need to be enabled _before_ we fire up the pll.
Oh, thanks! Let's hope that after the rework it's harder to make such
mistakes :)
Yeah, this
is a mess and I think we should move the actual pll enabling to the
crtc_enable stage (and the also move the lvds pin pair/port enabling in
there). So
- the actuall pll enabling needs to stay here.
- maybe call the function update_pch_pll instead of set_pch_pll. This is
more in line with Jesse's similar refactoring of i9xx_crtc_mode_set,
where he called the split-out pll functions update_pll, too.
Ok, will do.
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Valleyview doesn't have rc6+ or rc6++
Feel free to use:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Sep 17, 2012 at 9:10 PM, Ben Widawsky b...@bwidawsk.net wrote:
I do not currently have a VLV to test this on, but hopefully it only
removes information from debugfs, sysfs, and prevents enabling an
unsupported mode.
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +
drivers/gpu/drm/i915/i915_sysfs.c | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7a4b3f3..4e74a6a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1144,11 +1144,16 @@ static int gen6_drpc_info(struct seq_file *m)
I915_READ(GEN6_GT_GFX_RC6_LOCKED));
seq_printf(m, RC6 residency since boot: %u\n,
I915_READ(GEN6_GT_GFX_RC6));
+
+ if (IS_VALLEYVIEW(dev))
+ goto out;
+
seq_printf(m, RC6+ residency since boot: %u\n,
I915_READ(GEN6_GT_GFX_RC6p));
seq_printf(m, RC6++ residency since boot: %u\n,
I915_READ(GEN6_GT_GFX_RC6pp));
+out:
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index a253515..4717a42 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -41,6 +41,9 @@ static u32 calc_residency(struct drm_device *dev, const u32
reg)
if (!intel_enable_rc6(dev))
return 0;
+ if (IS_VALLEYVIEW(dev) reg != GEN6_GT_GFX_RC6)
+ return 0;
+
raw_time = I915_READ(reg) * 128ULL;
return DIV_ROUND_UP_ULL(raw_time, 10);
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 82ca172..ccd50d7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2389,8 +2389,8 @@ int intel_enable_rc6(const struct drm_device *dev)
}
/* snb/ivb have more than one rc6 state. */
- if (INTEL_INFO(dev)-gen == 6) {
- DRM_DEBUG_DRIVER(Sandybridge: deep RC6 disabled\n);
+ if (INTEL_INFO(dev)-gen == 6 || IS_VALLEYVIEW(dev)) {
+ DRM_DEBUG_DRIVER(HW doesn't support deep RC6 (disabling)\n);
return INTEL_RC6_ENABLE;
}
--
1.7.12
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
