Re: [Intel-gfx] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
On 8/7/2015 1:37 PM, Daniel Vetter wrote:
On Thu, Aug 06, 2015 at 05:43:39PM +0100, Chris Wilson wrote:
We have for a long time been ultra-paranoid about the situation whereby
we hand back pages to the system that have been written to by the GPU
and potentially simultaneously by the user through a CPU mmapping. We
can relax this restriction when we know that the cache domain tracking
is true and there can be no stale cacheline invalidatations. This is
true if the object has never been CPU mmaped as all internal accesses
(i.e. kmap/iomap) are carefully flushed. For a CPU mmaping, one would
expect that the invalid cache lines are resolved on PTE/TLB shootdown
during munmap(), so the only situation we need to be paranoid about is
That seems a pretty strong assumption given that x86 cache are physically
indexed - I'd never expect flushing to happen on munmap.
x86 L1 caches are most probably virtually indexed/physically tagged and
generally this is the prevalent & most optimal Cache configuration.
For the virtually indexed/physically tagged caches, the cache flush is
not really required either on Context switch or on page table update
(munmap, PTE/TLB shootdown).
So there could be few cache lines, holding the stale data (due to a
prior CPU mmapping), for the object being purged/truncated.
when such a CPU mmaping exists at the time of put_pages. Given that we
need to treat put_pages carefully as we may return live data to the
system that we want to use again in the future (i.e. I915_MADV_WILLNEED
pages) we can simply treat a live CPU mmaping as a special case of
WILLNEED (which it is!). Any I915_MADV_DONTNEED pages and their
mmapings are shotdown immediately following put_pages.
Signed-off-by: Chris Wilson
Cc: "Goel, Akash"
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jesse Barnes
But it's still salvageable I think since we only care about coherency for
the gpu (where data might be stuck in cpu caches). From the cpu's pov (and
hence the entire system except the gpu) we should never see inconsistency
really - as soon as the gpu does a write to a cacheline it'll win, and
before that nothing in the system can assume anything about the contents
of these pages.
So imo a simple
/* For purgeable objects we don't care about object contents. */
would be enough.
Well except that there's gl extensions which expose purgeable objects, so
I guess we can't actually do this.
I presume though you only want to avoid clflush when actually purging an
object, so maybe we can keep this by purging the shmem backing node first
and checking here for __I915_MADV_PURGED instead?
An object marked as MADV_DONT_NEED, implies that it will be
purged/truncated right away after the call to put_pages_gtt function.
So doing the other way round by purging first and then checking for
__I915_MADV_PURGED, might be equivalent.
Best regards
Akash
Oh and some perf data would be good for this.
-Daniel
---
drivers/gpu/drm/i915/i915_gem.c | 49 ++---
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2dfe707f11d3..24deace364a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2047,22 +2047,45 @@ i915_gem_object_put_pages_gtt(struct
drm_i915_gem_object *obj)
BUG_ON(obj->madv == __I915_MADV_PURGED);
- ret = i915_gem_object_set_to_cpu_domain(obj, true);
- if (ret) {
- /* In the event of a disaster, abandon all caches and
-* hope for the best.
-*/
- WARN_ON(ret != -EIO);
- i915_gem_clflush_object(obj, true);
- obj->base.read_domains = obj->base.write_domain =
I915_GEM_DOMAIN_CPU;
- }
-
i915_gem_gtt_finish_object(obj);
- if (i915_gem_object_needs_bit17_swizzle(obj))
- i915_gem_object_save_bit_17_swizzle(obj);
+ /* If we need to access the data in the future, we need to
+* be sure that the contents of the object is coherent with
+* the CPU prior to releasing the pages back to the system.
+* Once we unpin them, the mm is free to move them to different
+* zones or even swap them out to disk - all without our
+* intervention. (Though we could track such operations with our
+* own gemfs, if we ever write one.) As such if we want to keep
+* the data, set it to the CPU domain now just in case someone
+* else touches it.
+*
+* For a long time we have been paranoid about handing back
+* pages to the system with stale cacheline invalidation. For
+* all internal use (kmap/iomap), we know that the domain tracking is
+* accurate. However, the userspace API is lax and the user can CPU
+* mmap the object and invalidate cachelines without our accurate
+* tracking. We have been paranoid to be sure that w
Re: [Intel-gfx] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
On Sun, Aug 09, 2015 at 04:23:01PM +0530, Goel, Akash wrote: > On 8/7/2015 1:37 PM, Daniel Vetter wrote: > >I presume though you only want to avoid clflush when actually purging an > >object, so maybe we can keep this by purging the shmem backing node first > >and checking here for __I915_MADV_PURGED instead? > > An object marked as MADV_DONT_NEED, implies that it will be > purged/truncated right away after the call to put_pages_gtt > function. > So doing the other way round by purging first and then checking for > __I915_MADV_PURGED, might be equivalent. But disregards a few nice sanity checks, which I would like to keep. -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] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
On 8/9/2015 4:25 PM, Chris Wilson wrote: On Sun, Aug 09, 2015 at 04:23:01PM +0530, Goel, Akash wrote: On 8/7/2015 1:37 PM, Daniel Vetter wrote: I presume though you only want to avoid clflush when actually purging an object, so maybe we can keep this by purging the shmem backing node first and checking here for __I915_MADV_PURGED instead? An object marked as MADV_DONT_NEED, implies that it will be purged/truncated right away after the call to put_pages_gtt function. So doing the other way round by purging first and then checking for __I915_MADV_PURGED, might be equivalent. But disregards a few nice sanity checks, which I would like to keep. -Chris Fine, just wanted to convey that doing the other way round may not be really beneficial. About the other point of virtually indexed/physically tagged cache, would it be safe just rely on the MADV_DONT_NEED state of the object (which indicates that there are no active CPU mmappings) ? Due to an earlier CPU mmappings, there could be cachelines holding the stale data ? Best regards Akash ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false
We follow the VBT as to whether a DDI port is used for eDP and if so, do
not attach a HDMI encoder to it. However there are machines for which
the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link.
Furthermore, on those machines the HDMI is connected to that DDI port
but we ignore it.
If we reorder our port initialisation to try the eDP setup first and
if that fails we can treat it as a normal DP port along with a HDMI
output. To accomplish this, we have to delay registering the DP
connector/encoder until after we establish its final type.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88331
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 27
drivers/gpu/drm/i915/intel_dp.c | 127 +--
drivers/gpu/drm/i915/intel_drv.h | 6 +-
3 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0bcd1b1aba4f..aab8dfd1f8a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
- bool dpd_is_edp = false;
intel_lvds_init(dev);
@@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct drm_device
*dev)
intel_ddi_init(dev, PORT_D);
} else if (HAS_PCH_SPLIT(dev)) {
int found;
- dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
if (has_edp_a(dev))
intel_dp_init(dev, DP_A, PORT_A);
+ found = 0;
+ /* PCH SDVOB multiplex with HDMIB */
if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
- /* PCH SDVOB multiplex with HDMIB */
found = intel_sdvo_init(dev, PCH_SDVOB, true);
if (!found)
intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
- if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
- intel_dp_init(dev, PCH_DP_B, PORT_B);
}
+ if (!found && I915_READ(PCH_DP_B) & DP_DETECTED)
+ intel_dp_init(dev, PCH_DP_B, PORT_B);
- if (I915_READ(PCH_HDMIC) & SDVO_DETECTED)
- intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
-
- if (!dpd_is_edp && I915_READ(PCH_HDMID) & SDVO_DETECTED)
- intel_hdmi_init(dev, PCH_HDMID, PORT_D);
-
+ found = 0;
if (I915_READ(PCH_DP_C) & DP_DETECTED)
- intel_dp_init(dev, PCH_DP_C, PORT_C);
+ found = intel_dp_init(dev, PCH_DP_C, PORT_C);
+ if (found != DRM_MODE_CONNECTOR_eDP &&
+ I915_READ(PCH_HDMIC) & SDVO_DETECTED)
+ intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
+ found = 0;
if (I915_READ(PCH_DP_D) & DP_DETECTED)
- intel_dp_init(dev, PCH_DP_D, PORT_D);
+ found = intel_dp_init(dev, PCH_DP_D, PORT_D);
+ if (found != DRM_MODE_CONNECTOR_eDP &&
+ I915_READ(PCH_HDMID) & SDVO_DETECTED)
+ intel_hdmi_init(dev, PCH_HDMID, PORT_D);
} else if (IS_VALLEYVIEW(dev)) {
/*
* The DP_DETECTED bit is the latched state of the DDC
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1e64a8c1e7cb..8adf500f3989 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1031,14 +1031,13 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return ret;
}
-static void
+static int
intel_dp_aux_init(struct intel_dp *intel_dp, struct intel_connector *connector)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
enum port port = intel_dig_port->port;
const char *name = NULL;
- int ret;
switch (port) {
case PORT_A:
@@ -1080,20 +1079,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct
intel_connector *connector)
DRM_DEBUG_KMS("registering %s bus for %s\n", name,
connector->base.kdev->kobj.name);
- ret = drm_dp_aux_register(&intel_dp->aux);
- if (ret < 0) {
- DRM_ERROR("drm_dp_aux_register() for %s failed (%d)\n",
- name, ret);
- return;
- }
-
- ret = sysfs_create_link(&connector->base.kdev->kobj,
- &intel_dp->aux.ddc.dev.kobj,
- intel_dp->aux.ddc.dev.kobj.name);
- if (ret < 0) {
- DRM_ERROR("sysfs_create_link
Re: [Intel-gfx] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
On Sun, Aug 09, 2015 at 05:11:52PM +0530, Goel, Akash wrote: > > > On 8/9/2015 4:25 PM, Chris Wilson wrote: > >On Sun, Aug 09, 2015 at 04:23:01PM +0530, Goel, Akash wrote: > >>On 8/7/2015 1:37 PM, Daniel Vetter wrote: > >>>I presume though you only want to avoid clflush when actually purging an > >>>object, so maybe we can keep this by purging the shmem backing node first > >>>and checking here for __I915_MADV_PURGED instead? > >> > >>An object marked as MADV_DONT_NEED, implies that it will be > >>purged/truncated right away after the call to put_pages_gtt > >>function. > >>So doing the other way round by purging first and then checking for > >>__I915_MADV_PURGED, might be equivalent. > > > >But disregards a few nice sanity checks, which I would like to keep. > >-Chris > Fine, just wanted to convey that doing the other way round may not > be really beneficial. > > About the other point of virtually indexed/physically tagged cache, > would it be safe just rely on the MADV_DONT_NEED state of the object > (which indicates that there are no active CPU mmappings) ? > Due to an earlier CPU mmappings, there could be cachelines holding > the stale data ? If the conflicts survive munmap(), I don't have a clever idea on how to avoid the clflush before we hand back the pages to the system. -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] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
On 8/9/2015 6:19 PM, Chris Wilson wrote: On Sun, Aug 09, 2015 at 05:11:52PM +0530, Goel, Akash wrote: On 8/9/2015 4:25 PM, Chris Wilson wrote: On Sun, Aug 09, 2015 at 04:23:01PM +0530, Goel, Akash wrote: On 8/7/2015 1:37 PM, Daniel Vetter wrote: I presume though you only want to avoid clflush when actually purging an object, so maybe we can keep this by purging the shmem backing node first and checking here for __I915_MADV_PURGED instead? An object marked as MADV_DONT_NEED, implies that it will be purged/truncated right away after the call to put_pages_gtt function. So doing the other way round by purging first and then checking for __I915_MADV_PURGED, might be equivalent. But disregards a few nice sanity checks, which I would like to keep. -Chris Fine, just wanted to convey that doing the other way round may not be really beneficial. About the other point of virtually indexed/physically tagged cache, would it be safe just rely on the MADV_DONT_NEED state of the object (which indicates that there are no active CPU mmappings) ? Due to an earlier CPU mmappings, there could be cachelines holding the stale data ? If the conflicts survive munmap(), I don't have a clever idea on how to avoid the clflush before we hand back the pages to the system. One case could be, as you suggested, check if ever there was a CPU mapping created for the object & so avoid the clflush for GPU (GPU + GTT) only objects. Best regards Akash -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false
Hi,
On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:
> We follow the VBT as to whether a DDI port is used for eDP and if so, do
> not attach a HDMI encoder to it. However there are machines for which
> the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link.
> Furthermore, on those machines the HDMI is connected to that DDI port
> but we ignore it.
>
> If we reorder our port initialisation to try the eDP setup first and
> if that fails we can treat it as a normal DP port along with a HDMI
> output. To accomplish this, we have to delay registering the DP
> connector/encoder until after we establish its final type.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88331
The existing code seems very carefully crafted, taking into account
the differences betweem various GPU generations etc, shuffling that
around might risk breakage. FWIW, I'm wondering if just adding a quirk
for this single Dell workstation might be justified?
Best regards,
Lukas
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 27
> drivers/gpu/drm/i915/intel_dp.c | 127
> +--
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> 3 files changed, 79 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0bcd1b1aba4f..aab8dfd1f8a5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_encoder *encoder;
> - bool dpd_is_edp = false;
>
> intel_lvds_init(dev);
>
> @@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> intel_ddi_init(dev, PORT_D);
> } else if (HAS_PCH_SPLIT(dev)) {
> int found;
> - dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
>
> if (has_edp_a(dev))
> intel_dp_init(dev, DP_A, PORT_A);
>
> + found = 0;
> + /* PCH SDVOB multiplex with HDMIB */
> if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
> - /* PCH SDVOB multiplex with HDMIB */
> found = intel_sdvo_init(dev, PCH_SDVOB, true);
> if (!found)
> intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
> - if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
> - intel_dp_init(dev, PCH_DP_B, PORT_B);
> }
> + if (!found && I915_READ(PCH_DP_B) & DP_DETECTED)
> + intel_dp_init(dev, PCH_DP_B, PORT_B);
>
> - if (I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> - intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
> -
> - if (!dpd_is_edp && I915_READ(PCH_HDMID) & SDVO_DETECTED)
> - intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> -
> + found = 0;
> if (I915_READ(PCH_DP_C) & DP_DETECTED)
> - intel_dp_init(dev, PCH_DP_C, PORT_C);
> + found = intel_dp_init(dev, PCH_DP_C, PORT_C);
> + if (found != DRM_MODE_CONNECTOR_eDP &&
> + I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> + intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
>
> + found = 0;
> if (I915_READ(PCH_DP_D) & DP_DETECTED)
> - intel_dp_init(dev, PCH_DP_D, PORT_D);
> + found = intel_dp_init(dev, PCH_DP_D, PORT_D);
> + if (found != DRM_MODE_CONNECTOR_eDP &&
> + I915_READ(PCH_HDMID) & SDVO_DETECTED)
> + intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> } else if (IS_VALLEYVIEW(dev)) {
> /*
>* The DP_DETECTED bit is the latched state of the DDC
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1e64a8c1e7cb..8adf500f3989 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1031,14 +1031,13 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> return ret;
> }
>
> -static void
> +static int
> intel_dp_aux_init(struct intel_dp *intel_dp, struct intel_connector
> *connector)
> {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> enum port port = intel_dig_port->port;
> const char *name = NULL;
> - int ret;
>
> switch (port) {
> case PORT_A:
> @@ -1080,20 +1079,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct
> intel_connector *connector)
> DRM_DEBUG_KMS("registering %s bus for %s\n", name,
> connector->base.kdev->kobj.name);
>
> -
[Intel-gfx] [QA 2015/07/31 ww32] Testing report for `drm-intel-testing`
Hello, We launched Intel GPU Tools on 6 platforms: Skylake-Y, Braswell-M, Broadwell-U, Baytrail M and T, Haswell-U to validate tag drm-intel-testing-2015-07-31 (kernel 4.2-rc4). Here are the results: New bugs reported: https://bugs.freedesktop.org/show_bug.cgi?id=91569 [BDW-U] System crashing with gem_mmap_gtt over huge-bo-tiledx huge-bo-tiledy and huge-copy-xy Test Environment: Kernel: tag drm-intel-testing-2015-07-31 (4.2-rc4) from git://anongit.freedesktop.org/drm-intel Mesa: mesa-10.6.3 from http://cgit.freedesktop.org/mesa/mesa/ Xf86_video_intel: 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ Libdrm: libdrm-2.4.62 from http://cgit.freedesktop.org/mesa/drm/ Cairo: 1.14.2 from http://cgit.freedesktop.org/cairo libva: libva-1.6.0 from http://cgit.freedesktop.org/libva/ intel-driver: 1.6.0. from http://cgit.freedesktop.org/vaapi/intel-driver xorg: 1.17.99 installed with script git_xorg.sh Xserver: xorg-server-1.17.2 from http://cgit.freedesktop.org/xorg/xserver Intel-gpu-tools: 1.11 from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ Results: Platform| Available | Blacklisted | Skipped | Executed | % Pass| % Exe -- SKL | 5763 | 4011 | 513 | 1232 | 38.56%| 29.40% BSW | 5763 | 3882 | 254 | 1458 | 91.73%| 85.16% BDW-U | 5763 | 4028 | 810 | 926 | 86.60%| 53.37% BYT-T | 5763 | 3848 | 986 | 919 | 24.28%| 48.24% BYT-M | 5763 | 3848 | 220 | 1685 | 57.74 % | 88.45 % HSW-U | 5763 | 3810 | 804 | 1149 | 87.03%| 58.83% -- Last week results: Platform| Total | Executed | Pass | % Executed| % Pass - SKL | 1744 | 742 | 333 | 42.55%| 44.88% BSW | 1886 | 1707 | 773 | 90.51%| 45.28% BDW-U | 1751 | 1352 | 924 | 77.21%| 68.34% BYT-T | 2890 | 2638 | 1643 | 91.28%| 62.28% BYT-M | 1916 | 1707 | 776 | 89.09%| 45.46% HSW-U | 1953 | 1170 | 990 | 59.91%| 84.62% - Known bugs: SKL https://bugs.freedesktop.org/show_bug.cgi?id=89959 [SKL]igt/gem_concurrent_blit subcase sporadically causes system hang and *ERROR* blitter: timed out waiting for forcewake ack to clear. https://bugs.freedesktop.org/show_bug.cgi?id=89728 [HSW/BDW/BSW/SKL bisected] igt/pm_rps/ subcases reset and blocking fail https://bugs.freedesktop.org/show_bug.cgi?id=89928 [SKL]igt/gem_evict_everything/forked-mempressure-interruptible takes more than 10 minutes https://bugs.freedesktop.org/show_bug.cgi?id=90546 [BDW/BSW/SKL bisected]igt/pm_rpm/drm-resources-equal fails https://bugs.freedesktop.org/show_bug.cgi?id=86763 [BSW/SKL]igt/kms_plane some subcases fail (Overlay/Sprite Support (same as Color Key & Blend Support)) https://bugs.freedesktop.org/show_bug.cgi?id=87730 [BDW/BSW/SKL]igt/gem_dummy_reloc_loop sporadically causes *ERROR* Hangcheck timer elapsed... blitter ring idle https://bugs.freedesktop.org/show_bug.cgi?id=88437 [BDW/SKL]igt/drv_missed_irq_hang fails https://bugs.freedesktop.org/show_bug.cgi?id=88981 [BSW/SKL]igt/gem_exec_lut_handle causes *ERROR* Hangcheck timer elapsed... render ring idle https://bugs.freedesktop.org/show_bug.cgi?id=88984 [BSW/SKL]igt/gem_multi_bsd_sync_loop sporadically causes *ERROR* Hangcheck timer elapsed... render ring idle https://bugs.freedesktop.org/show_bug.cgi?id=89123 [SKL]igt/pm_rps tests fail https://bugs.freedesktop.org/show_bug.cgi?id=89124 [SKL mobile] igt/kms_psr_sink_crc subcases fail if PSR enabled https://bugs.freedesktop.org/show_bug.cgi?id=89644 [BSW/SKL]igt/gem_cs_prefetch causes *ERROR* Hangcheck timer elapsed... render ring idle https://bugs.freedesktop.org/show_bug.cgi?id=89931 [SKL]igt/gem_pwrite_pread@display-pwrite-blt-gtt_mmap-performance sporadically causes *ERROR* Hangcheck timer elapsed... blitter ring idle https://bugs.freedesktop.org/show_bug.cgi?id=90045 [BDW/BSW/SKL]igt/gem_exec_big fails and causes [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck timer elapsed... render ring idle https://
Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Lukas Wunner
> Hi,
>
> On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:
> > We follow the VBT as to whether a DDI port is used for eDP and if so,
> > do not attach a HDMI encoder to it. However there are machines for
> > which the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP
> > link.
> > Furthermore, on those machines the HDMI is connected to that DDI port
> > but we ignore it.
> >
> > If we reorder our port initialisation to try the eDP setup first and
> > if that fails we can treat it as a normal DP port along with a HDMI
> > output. To accomplish this, we have to delay registering the DP
> > connector/encoder until after we establish its final type.
Sorry to jump in. Could this help another use case as below ?
We have some Bytrail machine (Bayley Bay), we applied HW rework to disable eDP
connectivity to DDI1 and enable DP on DDI 1.
But we found the i915 driver still take this DDI as eDP, not DP. we suspect
it's because VBT still takes it as DP and so i915 driver just follows.
If we don't want to revise VBT in BIOS after every rework, is there any other
way to let i915 detect this is a DP link?
Thanks
Mengdong
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88331
>
> The existing code seems very carefully crafted, taking into account the
> differences betweem various GPU generations etc, shuffling that around
> might risk breakage. FWIW, I'm wondering if just adding a quirk for this
> single
> Dell workstation might be justified?
>
> Best regards,
>
> Lukas
>
>
> > Signed-off-by: Chris Wilson
> > Cc: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 27
> > drivers/gpu/drm/i915/intel_dp.c | 127
> +--
> > drivers/gpu/drm/i915/intel_drv.h | 6 +-
> > 3 files changed, 79 insertions(+), 81 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 0bcd1b1aba4f..aab8dfd1f8a5 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct
> > drm_device *dev) {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_encoder *encoder;
> > - bool dpd_is_edp = false;
> >
> > intel_lvds_init(dev);
> >
> > @@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct
> drm_device *dev)
> > intel_ddi_init(dev, PORT_D);
> > } else if (HAS_PCH_SPLIT(dev)) {
> > int found;
> > - dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
> >
> > if (has_edp_a(dev))
> > intel_dp_init(dev, DP_A, PORT_A);
> >
> > + found = 0;
> > + /* PCH SDVOB multiplex with HDMIB */
> > if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
> > - /* PCH SDVOB multiplex with HDMIB */
> > found = intel_sdvo_init(dev, PCH_SDVOB, true);
> > if (!found)
> > intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
> > - if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
> > - intel_dp_init(dev, PCH_DP_B, PORT_B);
> > }
> > + if (!found && I915_READ(PCH_DP_B) & DP_DETECTED)
> > + intel_dp_init(dev, PCH_DP_B, PORT_B);
> >
> > - if (I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> > - intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
> > -
> > - if (!dpd_is_edp && I915_READ(PCH_HDMID) & SDVO_DETECTED)
> > - intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> > -
> > + found = 0;
> > if (I915_READ(PCH_DP_C) & DP_DETECTED)
> > - intel_dp_init(dev, PCH_DP_C, PORT_C);
> > + found = intel_dp_init(dev, PCH_DP_C, PORT_C);
> > + if (found != DRM_MODE_CONNECTOR_eDP &&
> > + I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> > + intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
> >
> > + found = 0;
> > if (I915_READ(PCH_DP_D) & DP_DETECTED)
> > - intel_dp_init(dev, PCH_DP_D, PORT_D);
> > + found = intel_dp_init(dev, PCH_DP_D, PORT_D);
> > + if (found != DRM_MODE_CONNECTOR_eDP &&
> > + I915_READ(PCH_HDMID) & SDVO_DETECTED)
> > + intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> > } else if (IS_VALLEYVIEW(dev)) {
> > /*
> > * The DP_DETECTED bit is the latched state of the DDC diff
> > --git
> > a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 1e64a8c1e7cb..8adf500f3989 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1031,14 +1031,13 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux,
Re: [Intel-gfx] [alsa-devel] [PATCH 3/4] ALSA: hda - display audio call ncts callback
Hi Raymond,
>
> > > }
> > >
> > > + if (is_haswell_plus(codec)) {
> > > + if (acomp && acomp->ops && acomp->ops->set_ncts)
> > > + acomp->ops->set_ncts(acomp->dev, per_pin-
> > >pin_nid - 4,
> >
> > Please describe more how "pin_nid - 4" is supposed to work. Also...
>
> OK, I see.
>
> >
> > > + 0, runtime->rate);
> >
> > ... this implies that no MST support included?
>
> We will support MST later. Currently I just add the
> interface to support MST, but not implementing it.
Refer to DCN HDA040-A
Multi-stream over Single Display Port
Can the driver use subdevices for those display port support multi streaming ?
[Libin] What do you mean subdevice here,
using a struct device to represent a dev_entry or an int type?
The specification allow up to 64 device entries
This mean the number of subdevices is equal to the device list length
More than one audio output /converters can be connected to the multi stream
displayport pin widget but different device entry while only one audio output
can be dynamically allocated to other HDMI pin widget
[Libin] Yes, Pin widget can have multiple device entry and connecting different
converters. The audio output will be based on device entry.
7.3.3.42 Device Select
For Digital Display Pin Widget that is multi stream capable, the Device Select
control determines which Device Entry is currently selected and accessible by
the Pin Widget verbs which are controlling the sink device operations. This
control verb is only required if it is a Digital Display Pin Widget and multi
stream capable.
The index is in relation to the Device List associated with the widget. The
index is a zero-based offset into the Device List. Once the Device Entry is
selected by the Set index, all subsequent Pin Widget verbs controlling the sink
device operations will be directed to the selected Device Entry, until the
Device Select verb get updated with a new value.
Device Entry: Indicate the index of Device Entry (0 63) which the UR bit of is
generated for a multi stream capable Digital Display Pin Widget. Not valid for
non Digital Display Pin Widget or Digital Display Pin Widget that is not multi
stream capable
Device List Length is a 0 based integer value indicating the number of sink
device that a multi stream capable Digital Display Pin Widget can support. If
Device List Length is value is 0, there is only one sink device connection
possible indicating the Pin Widget is not multi stream capable, and there is no
Device Select control (see Section 7.3.3.42). If the Device List Length value
is 1 – 63, it indicates the Pin Widget is multi stream capable, and 2 – 64
Device Entries are supported in the Pin Widget.
>
Regards,
Libin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 3/4] ALSA: hda - display audio call ncts callback
2015-8-10 上午11:15於 "Yang, Libin" 寫道：
>
> Hi Raymond,
>
> >
> > > > }
> > > >
> > > > + if (is_haswell_plus(codec)) {
> > > > + if (acomp && acomp->ops && acomp->ops->set_ncts)
> > > > + acomp->ops->set_ncts(acomp->dev, per_pin-
> > > >pin_nid - 4,
> > >
> > > Please describe more how "pin_nid - 4" is supposed to work. Also...
> >
> > OK, I see.
> >
> > >
> > > > + 0, runtime->rate);
> > >
> > > ... this implies that no MST support included?
> >
> > We will support MST later. Currently I just add the
> > interface to support MST, but not implementing it.
> Refer to DCN HDA040-A
> Multi-stream over Single Display Port
> Can the driver use subdevices for those display port support multi
streaming ?
>
> [Libin] What do you mean subdevice here,
> using a struct device to represent a dev_entry or an int type?
http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/tree/codecs/stac9227-intel-d946gzis-mobo?id=HEAD
When HDA codecs have three Audio Input widgets, the driver create three
subdevices for those desktop which have three or more input sources in the
past
ARECORD
List of CAPTURE Hardware Devices
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 3/3
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
With the auto generic parser , the driver create one subdevice for Analog
two subdevices for Alt Analog
List of CAPTURE Hardware Devices
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 2: STAC92xx Alt Analog [STAC92xx Alt
Analog]
Subdevices: 2/2
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
>
> The specification allow up to 64 device entries
> This mean the number of subdevices is equal to the device list length
> More than one audio output /converters can be connected to the multi
stream displayport pin widget but different device entry while only one
audio output can be dynamically allocated to other HDMI pin widget
>
> [Libin] Yes, Pin widget can have multiple device entry and connecting
different converters. The audio output will be based on device entry.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series
Hi Daniel, That patch was already merged: http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.html For SKL, the above patch helped in getting the correct ISR bits set. One option is to enable the HDMI optimization from VLV onwards. I don't have an ivb machine to try out the issue. Regards, Sonika -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Friday, August 7, 2015 6:54 PM To: Jindal, Sonika Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series On Tue, Jul 14, 2015 at 05:21:20PM +0530, Sonika Jindal wrote: > This series adds some optimization related to reading of edid only > when required and when live status says so. > The comments in the patches explain more. This series breaks my funky ivb machine with the broken hpd bits: When I unplug the screen the system never invalidates the edid and so never notices that it's gone. Now iirc you've discovered an issue in our hpd irq handler which can cause lost hpd bits, but that patch isn't in this series. And iirc I asked you to resend everything since that hw fix also wasn't in the last series. And I can't find it any more. Did I just dream about this other patch to fix hpd on big core? Thanks, Daniel > v2: >Some refactoring is with this series. > >Also, right now this is done for platforms gen7 and above because we >couldn't test with older platforms. For newer platforms it works >reliably. > >For HPD and live status to work on SKL, following patch is required: >"drm/i915: Handle HPD when it has actually occurred" > > Shashank Sharma (2): > drm/i915: add attached connector to hdmi container > drm/i915: Add HDMI probe function > > Sonika Jindal (1): > drm/i915: Check live status before reading edid > > drivers/gpu/drm/i915/intel_dp.c |4 +- > drivers/gpu/drm/i915/intel_drv.h |3 ++ > drivers/gpu/drm/i915/intel_hdmi.c | 93 > + > 3 files changed, 88 insertions(+), 12 deletions(-) > > -- > 1.7.10.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/bxt: Add HPD support for DDIA
Also remove redundant comments.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_irq.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 02b9e73..9b9533a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -90,6 +90,7 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
/* BXT hpd list */
static const u32 hpd_bxt[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
};
@@ -3018,30 +3019,25 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
u32 hotplug_port = 0;
u32 hotplug_ctrl;
- /* Now, enable HPD */
for_each_intel_encoder(dev, intel_encoder) {
if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
== HPD_ENABLED)
hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
}
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) & ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
- /* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
+ if (hotplug_port & BXT_DE_PORT_HP_DDIA)
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
if (hotplug_port & BXT_DE_PORT_HP_DDIB)
hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
if (hotplug_port & BXT_DE_PORT_HP_DDIC)
hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) & ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] Add BXT A0/A1 WA for HPD swap in generic way
This series adds BXT HPD pin swap WA for A0/A1 by setting right hpd_pin and irq_port for PORT_B. Sonika Jindal (3): drm/i915: Dont enable hpd for eDP drm/i915/bxt: Add HPD support for DDIA drm/i915/bxt: WA for swapped HPD pins in A stepping drivers/gpu/drm/i915/i915_irq.c | 10 +++--- drivers/gpu/drm/i915/intel_ddi.c | 10 +- drivers/gpu/drm/i915/intel_dp.c |4 +++- drivers/gpu/drm/i915/intel_hdmi.c |9 - 4 files changed, 23 insertions(+), 10 deletions(-) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP
With HPD support added for all ports including PORT_A, setting hpd_pin will
result in enabling of hpd to edp as well. There is no need to enable HPD on
PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will
be connected. it can be added back when required
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..5a614c9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5784,7 +5784,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
- intel_encoder->hpd_pin = HPD_PORT_A;
+ /* Not enabling edp interrupts */
break;
case PORT_B:
intel_encoder->hpd_pin = HPD_PORT_B;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/bxt: WA for swapped HPD pins in A stepping
WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling DDIA HPD pin in place of DDIB. v2: For DP, irq_port is used to determine the encoder instead of hpd_pin and removing the edp HPD logic because port A HPD is not present(Imre) v3: Rebased on top of Imre's patchset for enabling HPD on PORT A. Added hpd_pin swapping for intel_dp_init_connector, setting encoder for PORT_A as per the WA in irq_port (Imre) v4: Dont enable interrupt for edp, also reframe the description (Siva) v5: Don’t check for PORT_A in intel_ddi_init to update dig_port, instead avoid setting hpd_pin itself (Imre) Signed-off-by: Sonika Jindal --- drivers/gpu/drm/i915/intel_ddi.c | 10 +- drivers/gpu/drm/i915/intel_dp.c |2 ++ drivers/gpu/drm/i915/intel_hdmi.c |9 - 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index e2c6f73..777e3a3 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -3225,7 +3225,15 @@ void intel_ddi_init(struct drm_device *dev, enum port port) goto err; intel_dig_port->hpd_pulse = intel_dp_hpd_pulse; - dev_priv->hotplug.irq_port[port] = intel_dig_port; + /* +* On BXT A0/A1, sw needs to activate DDIA HPD logic and +* interrupts to check the external panel connection. +*/ + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0) +&& port == PORT_B) + dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port; + else + dev_priv->hotplug.irq_port[port] = intel_dig_port; } /* In theory we don't need the encoder->type check, but leave it just in diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 5a614c9..7fab3e5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5788,6 +5788,8 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, break; case PORT_B: intel_encoder->hpd_pin = HPD_PORT_B; + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) + intel_encoder->hpd_pin = HPD_PORT_A; break; case PORT_C: intel_encoder->hpd_pin = HPD_PORT_C; diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 70bad5b..94fa716 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT; else intel_hdmi->ddc_bus = GMBUS_PIN_DPB; - intel_encoder->hpd_pin = HPD_PORT_B; + /* +* On BXT A0/A1, sw needs to activate DDIA HPD logic and +* interrupts to check the external panel connection. +*/ + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) + intel_encoder->hpd_pin = HPD_PORT_A; + else + intel_encoder->hpd_pin = HPD_PORT_B; break; case PORT_C: if (IS_BROXTON(dev_priv)) -- 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 1/3] drm/i915: Dont enable hpd for eDP
Reviewed-by: Sivakumar Thulasimani
On 8/10/2015 10:35 AM, Sonika Jindal wrote:
With HPD support added for all ports including PORT_A, setting hpd_pin will
result in enabling of hpd to edp as well. There is no need to enable HPD on
PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will
be connected. it can be added back when required
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..5a614c9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5784,7 +5784,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
- intel_encoder->hpd_pin = HPD_PORT_A;
+ /* Not enabling edp interrupts */
break;
case PORT_B:
intel_encoder->hpd_pin = HPD_PORT_B;
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/bxt: Add HPD support for DDIA
Reviewed-by: Sivakumar Thulasimani
On 8/10/2015 10:35 AM, Sonika Jindal wrote:
Also remove redundant comments.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_irq.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 02b9e73..9b9533a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -90,6 +90,7 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
/* BXT hpd list */
static const u32 hpd_bxt[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
};
@@ -3018,30 +3019,25 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
u32 hotplug_port = 0;
u32 hotplug_ctrl;
- /* Now, enable HPD */
for_each_intel_encoder(dev, intel_encoder) {
if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
== HPD_ENABLED)
hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
}
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) & ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
- /* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
+ if (hotplug_port & BXT_DE_PORT_HP_DDIA)
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
if (hotplug_port & BXT_DE_PORT_HP_DDIB)
hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
if (hotplug_port & BXT_DE_PORT_HP_DDIC)
hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) & ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/bxt: WA for swapped HPD pins in A stepping
Reviewed-by: Sivakumar Thulasimani On 8/10/2015 10:35 AM, Sonika Jindal wrote: WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling DDIA HPD pin in place of DDIB. v2: For DP, irq_port is used to determine the encoder instead of hpd_pin and removing the edp HPD logic because port A HPD is not present(Imre) v3: Rebased on top of Imre's patchset for enabling HPD on PORT A. Added hpd_pin swapping for intel_dp_init_connector, setting encoder for PORT_A as per the WA in irq_port (Imre) v4: Dont enable interrupt for edp, also reframe the description (Siva) v5: Don’t check for PORT_A in intel_ddi_init to update dig_port, instead avoid setting hpd_pin itself (Imre) Signed-off-by: Sonika Jindal --- drivers/gpu/drm/i915/intel_ddi.c | 10 +- drivers/gpu/drm/i915/intel_dp.c |2 ++ drivers/gpu/drm/i915/intel_hdmi.c |9 - 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index e2c6f73..777e3a3 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -3225,7 +3225,15 @@ void intel_ddi_init(struct drm_device *dev, enum port port) goto err; intel_dig_port->hpd_pulse = intel_dp_hpd_pulse; - dev_priv->hotplug.irq_port[port] = intel_dig_port; + /* +* On BXT A0/A1, sw needs to activate DDIA HPD logic and +* interrupts to check the external panel connection. +*/ + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0) +&& port == PORT_B) + dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port; + else + dev_priv->hotplug.irq_port[port] = intel_dig_port; } /* In theory we don't need the encoder->type check, but leave it just in diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 5a614c9..7fab3e5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5788,6 +5788,8 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, break; case PORT_B: intel_encoder->hpd_pin = HPD_PORT_B; + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) + intel_encoder->hpd_pin = HPD_PORT_A; break; case PORT_C: intel_encoder->hpd_pin = HPD_PORT_C; diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 70bad5b..94fa716 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT; else intel_hdmi->ddc_bus = GMBUS_PIN_DPB; - intel_encoder->hpd_pin = HPD_PORT_B; + /* +* On BXT A0/A1, sw needs to activate DDIA HPD logic and +* interrupts to check the external panel connection. +*/ + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) + intel_encoder->hpd_pin = HPD_PORT_A; + else + intel_encoder->hpd_pin = HPD_PORT_B; break; case PORT_C: if (IS_BROXTON(dev_priv)) -- regards, Sivakumar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check live status before reading edid
On 7/14/2015 5:21 PM, Sonika Jindal wrote:
Adding this for SKL onwards.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 43 +
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
}
-static int g4x_digital_port_connected(struct drm_device *dev,
- struct intel_digital_port
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port)
{
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port);
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index c4b82ce..402be54 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,40 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)->detect_edid = NULL;
}
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port)
+{
+ u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+ /* TODO: Add bxt A0/A1 wa related to hpd pin swap */
+ switch (port->port) {
why not pass the encoder and use its hpd_pin ? that will avoid the need
to do
A0/A1 related checks ?
+ case PORT_B:
+ return temp & BXT_DE_PORT_HP_DDIB;
+
+ case PORT_C:
+ return temp & BXT_DE_PORT_HP_DDIC;
+
+ default:
+ return false;
+
+ }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (IS_VALLEYVIEW(dev))
+ return g4x_digital_port_connected(dev, intel_dig_port);
+ else if (IS_SKYLAKE(dev))
+ return ibx_digital_port_connected(dev_priv, intel_dig_port);
+ else if (IS_BROXTON(dev))
+ return bxt_port_connected(dev_priv, intel_dig_port);
+
+ return true;
+}
+
static bool
intel_hdmi_set_edid(struct drm_connector *connector)
{
@@ -1308,15 +1342,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_encoder *intel_encoder =
&hdmi_to_dig_port(intel_hdmi)->base;
enum intel_display_power_domain power_domain;
- struct edid *edid;
+ struct edid *edid = NULL;
bool connected = false;
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
- edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- intel_hdmi->ddc_bus));
+ if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+ edid = drm_get_edid(connector,
+ intel_gmbus_get_adapter(dev_priv,
+ intel_hdmi->ddc_bus));
intel_display_power_put(dev_priv, power_domain);
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false
hi Mengdong,
is there any reason why you cannot modify VBT ? unless it is
shipped version you
can just flash the modified VBT along with BIOS.
Chris,
i would be even more surprised if VBIOS/GOP can enable some display
when it is
configured incorrectly in VBT. Give me a day to check with someone if
this is even
possible in that level.
On 8/10/2015 8:00 AM, Lin, Mengdong wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Lukas Wunner
Hi,
On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:
We follow the VBT as to whether a DDI port is used for eDP and if so,
do not attach a HDMI encoder to it. However there are machines for
which the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link.
Furthermore, on those machines the HDMI is connected to that DDI port
but we ignore it.
If we reorder our port initialisation to try the eDP setup first and
if that fails we can treat it as a normal DP port along with a HDMI
output. To accomplish this, we have to delay registering the DP
connector/encoder until after we establish its final type.
Sorry to jump in. Could this help another use case as below ?
We have some Bytrail machine (Bayley Bay), we applied HW rework to disable eDP
connectivity to DDI1 and enable DP on DDI 1.
But we found the i915 driver still take this DDI as eDP, not DP. we suspect
it's because VBT still takes it as DP and so i915 driver just follows.
If we don't want to revise VBT in BIOS after every rework, is there any other
way to let i915 detect this is a DP link?
Thanks
Mengdong
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88331
The existing code seems very carefully crafted, taking into account the
differences betweem various GPU generations etc, shuffling that around
might risk breakage. FWIW, I'm wondering if just adding a quirk for this single
Dell workstation might be justified?
Best regards,
Lukas
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 27
drivers/gpu/drm/i915/intel_dp.c | 127
+--
drivers/gpu/drm/i915/intel_drv.h | 6 +-
3 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0bcd1b1aba4f..aab8dfd1f8a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct
drm_device *dev) {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
- bool dpd_is_edp = false;
intel_lvds_init(dev);
@@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct
drm_device *dev)
intel_ddi_init(dev, PORT_D);
} else if (HAS_PCH_SPLIT(dev)) {
int found;
- dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
if (has_edp_a(dev))
intel_dp_init(dev, DP_A, PORT_A);
+ found = 0;
+ /* PCH SDVOB multiplex with HDMIB */
if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
- /* PCH SDVOB multiplex with HDMIB */
found = intel_sdvo_init(dev, PCH_SDVOB, true);
if (!found)
intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
- if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
- intel_dp_init(dev, PCH_DP_B, PORT_B);
}
+ if (!found && I915_READ(PCH_DP_B) & DP_DETECTED)
+ intel_dp_init(dev, PCH_DP_B, PORT_B);
- if (I915_READ(PCH_HDMIC) & SDVO_DETECTED)
- intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
-
- if (!dpd_is_edp && I915_READ(PCH_HDMID) & SDVO_DETECTED)
- intel_hdmi_init(dev, PCH_HDMID, PORT_D);
-
+ found = 0;
if (I915_READ(PCH_DP_C) & DP_DETECTED)
- intel_dp_init(dev, PCH_DP_C, PORT_C);
+ found = intel_dp_init(dev, PCH_DP_C, PORT_C);
+ if (found != DRM_MODE_CONNECTOR_eDP &&
+ I915_READ(PCH_HDMIC) & SDVO_DETECTED)
+ intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
+ found = 0;
if (I915_READ(PCH_DP_D) & DP_DETECTED)
- intel_dp_init(dev, PCH_DP_D, PORT_D);
+ found = intel_dp_init(dev, PCH_DP_D, PORT_D);
+ if (found != DRM_MODE_CONNECTOR_eDP &&
+ I915_READ(PCH_HDMID) & SDVO_DETECTED)
+ intel_hdmi_init(dev, PCH_HDMID, PORT_D);
} else if (IS_VALLEYVIEW(dev)) {
/*
* The DP_DETECTED bit is the latched state of the DDC diff
--git
a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/d
[Intel-gfx] [PATCH 5/6 v2] drm/i915/skl: enable DDI-E hotplug
v2: fix one error found by checkpath.pl
Signed-off-by: Xiong Zhang
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 48 +---
drivers/gpu/drm/i915/i915_reg.h | 12 +
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 3 +++
drivers/gpu/drm/i915/intel_hotplug.c | 3 +++
6 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8d50d4f..6d93334 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -214,6 +214,7 @@ enum hpd_pin {
HPD_PORT_B,
HPD_PORT_C,
HPD_PORT_D,
+ HPD_PORT_E,
HPD_NUM_PINS
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1118c39..d94c92d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -61,6 +61,13 @@ static const u32 hpd_cpt[HPD_NUM_PINS] = {
[HPD_PORT_D] = SDE_PORTD_HOTPLUG_CPT
};
+static const u32 hpd_spt[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = SDE_PORTB_HOTPLUG_CPT,
+ [HPD_PORT_C] = SDE_PORTC_HOTPLUG_CPT,
+ [HPD_PORT_D] = SDE_PORTD_HOTPLUG_CPT,
+ [HPD_PORT_E] = SDE_PORTE_HOTPLUG_SPT
+};
+
static const u32 hpd_mask_i915[HPD_NUM_PINS] = {
[HPD_CRT] = CRT_HOTPLUG_INT_EN,
[HPD_SDVO_B] = SDVOB_HOTPLUG_INT_EN,
@@ -1252,6 +1259,8 @@ static bool pch_port_hotplug_long_detect(enum port port,
u32 val)
return val & PORTC_HOTPLUG_LONG_DETECT;
case PORT_D:
return val & PORTD_HOTPLUG_LONG_DETECT;
+ case PORT_E:
+ return val & PORTE_HOTPLUG_LONG_DETECT;
default:
return false;
}
@@ -1752,7 +1761,12 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe;
- u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
+ u32 hotplug_trigger;
+
+ if (HAS_PCH_SPT(dev))
+ hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT;
+ else
+ hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
if (hotplug_trigger) {
u32 dig_hotplug_reg, pin_mask, long_mask;
@@ -1760,9 +1774,23 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
- intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
- dig_hotplug_reg, hpd_cpt,
- pch_port_hotplug_long_detect);
+ if (HAS_PCH_SPT(dev)) {
+ intel_get_hpd_pins(&pin_mask, &long_mask,
+ hotplug_trigger,
+ dig_hotplug_reg, hpd_spt,
+ pch_port_hotplug_long_detect);
+
+ /* detect PORTE HP event */
+ dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG2);
+ if (pch_port_hotplug_long_detect(PORT_E,
+dig_hotplug_reg))
+ long_mask |= 1 << HPD_PORT_E;
+ } else
+ intel_get_hpd_pins(&pin_mask, &long_mask,
+ hotplug_trigger,
+ dig_hotplug_reg, hpd_cpt,
+ pch_port_hotplug_long_detect);
+
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -2984,6 +3012,11 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
for_each_intel_encoder(dev, intel_encoder)
if
(dev_priv->hotplug.stats[intel_encoder->hpd_pin].state == HPD_ENABLED)
enabled_irqs |= hpd_ibx[intel_encoder->hpd_pin];
+ } else if (HAS_PCH_SPT(dev)) {
+ hotplug_irqs = SDE_HOTPLUG_MASK_SPT;
+ for_each_intel_encoder(dev, intel_encoder)
+ if
(dev_priv->hotplug.stats[intel_encoder->hpd_pin].state == HPD_ENABLED)
+ enabled_irqs |= hpd_spt[intel_encoder->hpd_pin];
} else {
hotplug_irqs = SDE_HOTPLUG_MASK_CPT;
for_each_intel_encoder(dev, intel_encoder)
@@ -3005,6 +3038,13 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms;
hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms;
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+
+ /* enable SPT PORTE hot plug */
+ if (HAS_PCH_SPT(dev)) {
+ hotplug = I915_READ(PCH_PORT_HOTPLUG2);
+ hotplug |= PORTE_HOTPLUG_ENABLE;
+
[Intel-gfx] [PATCH 6/6 v2] drm/i915: Enable HDMI on DDI-E
DDI-E doesn't have the correspondent GMBUS pin.
We rely on VBT to tell us which one it being used instead.
The DVI/HDMI on shared port couldn't exist.
This patch isn't tested without hardware wchich has HDMI
on DDI-E.
v2: fix trailing whitespace
Signed-off-by: Xiong Zhang
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_bios.c | 25 +
drivers/gpu/drm/i915/intel_hdmi.c | 18 ++
3 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6d93334..5d8e7fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1414,6 +1414,10 @@ enum modeset_restore {
#define DP_AUX_C 0x20
#define DP_AUX_D 0x30
+#define DDC_PIN_B 0x05
+#define DDC_PIN_C 0x04
+#define DDC_PIN_D 0x06
+
struct ddi_vbt_port_info {
/*
* This is an index in the HDMI/DVI DDI buffer translation table.
@@ -1428,6 +1432,7 @@ struct ddi_vbt_port_info {
uint8_t supports_dp:1;
uint8_t alternate_aux_channel;
+ uint8_t alternate_ddc_pin;
};
enum psr_lines_to_wait {
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 16cdf17..8140531 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -894,7 +894,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
uint8_t hdmi_level_shift;
int i, j;
bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
- uint8_t aux_channel;
+ uint8_t aux_channel, ddc_pin;
/* Each DDI port can have more than one value on the "DVO Port" field,
* so look for all the possible values for each port and abort if more
* than one is found. */
@@ -928,6 +928,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
return;
aux_channel = child->raw[25];
+ ddc_pin = child->common.ddc_pin;
is_dvi = child->common.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
is_dp = child->common.device_type & DEVICE_TYPE_DISPLAYPORT_OUTPUT;
@@ -959,11 +960,27 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
if (is_dvi) {
- if (child->common.ddc_pin == 0x05 && port != PORT_B)
+ if (port == PORT_E) {
+ info->alternate_ddc_pin = ddc_pin;
+ /* if DDIE share ddc pin with other port, then
+* dvi/hdmi couldn't exist on the shared port.
+* Otherwise they share the same ddc bin and system
+* couldn't communicate with them seperately. */
+ if (ddc_pin == DDC_PIN_B) {
+
dev_priv->vbt.ddi_port_info[PORT_B].supports_dvi = 0;
+
dev_priv->vbt.ddi_port_info[PORT_B].supports_hdmi = 0;
+ } else if (ddc_pin == DDC_PIN_C) {
+
dev_priv->vbt.ddi_port_info[PORT_C].supports_dvi = 0;
+
dev_priv->vbt.ddi_port_info[PORT_C].supports_hdmi = 0;
+ } else if (ddc_pin == DDC_PIN_D) {
+
dev_priv->vbt.ddi_port_info[PORT_D].supports_dvi = 0;
+
dev_priv->vbt.ddi_port_info[PORT_D].supports_hdmi = 0;
+ }
+ } else if (ddc_pin == DDC_PIN_B && port != PORT_B)
DRM_DEBUG_KMS("Unexpected DDC pin for port B\n");
- if (child->common.ddc_pin == 0x04 && port != PORT_C)
+ else if (ddc_pin == DDC_PIN_C && port != PORT_C)
DRM_DEBUG_KMS("Unexpected DDC pin for port C\n");
- if (child->common.ddc_pin == 0x06 && port != PORT_D)
+ else if (ddc_pin == DDC_PIN_D && port != PORT_D)
DRM_DEBUG_KMS("Unexpected DDC pin for port D\n");
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..e1f6e81 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1991,6 +1991,24 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_hdmi->ddc_bus = GMBUS_PIN_DPD;
intel_encoder->hpd_pin = HPD_PORT_D;
break;
+ case PORT_E:
+ /* On SKL PORT E doesn't have seperate GMBUS pin
+* We rely on VBT to set a proper alternate GMBUS pin. */
+ switch (dev_priv->vbt.ddi_port_info[PORT_E].alternate_ddc_pin) {
+ case DDC_PIN_B:
+ intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
+ break;
+ case DDC_PIN_C:
+
