Re: [Intel-gfx] [PATCH] drm/i915: reorder setup sequence to have irqs for output setup
On Sun, Sep 9, 2012 at 3:59 AM, Ben Widawsky b...@bwidawsk.net wrote:
On 2012-09-06 06:43, Daniel Vetter wrote:
Otherwise the newshiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 15 +--
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 2cba7b4..58320e0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1325,9 +1325,8 @@ static int i915_load_modeset_init(struct
drm_device *dev)
if (ret)
goto cleanup_gem_stolen;
- intel_modeset_gem_init(dev);
-
- ret = drm_irq_install(dev);
+ /* Note: This also enables irqs. */
+ ret = intel_modeset_gem_init(dev);
if (ret)
goto cleanup_gem;
I'd much rather you just drm_irq_install() before intel_modeset_gem_init(),
unless there is some reason that won't work?
I've simple been paranoid and wanted to enable the irq as late as
possible. After rechecking the code I think just moving the irq
enabling up a bit should be safe, too. I'll do that.
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 9fce782..5c8d5e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1536,7 +1536,7 @@ static inline void
intel_unregister_dsm_handler(void) { return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern void intel_modeset_init(struct drm_device *dev);
-extern void intel_modeset_gem_init(struct drm_device *dev);
+extern int intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
extern int intel_modeset_vga_set_state(struct drm_device *dev, bool
state);
extern void intel_modeset_setup_hw_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6658367..01289eb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7948,7 +7948,6 @@ void intel_modeset_init(struct drm_device *dev)
/* Just disable it once at startup */
i915_disable_vga(dev);
- intel_setup_outputs(dev);
}
static void
@@ -8206,13 +8205,25 @@ void intel_modeset_setup_hw_state(struct
drm_device *dev)
drm_mode_config_reset(dev);
}
-void intel_modeset_gem_init(struct drm_device *dev)
+int intel_modeset_gem_init(struct drm_device *dev)
{
+ int ret;
+
intel_modeset_init_hw(dev);
intel_setup_overlay(dev);
+ ret = drm_irq_install(dev);
+ if (ret)
+ return ret;
+
+ /* Importanat: Output setup needs working interrupts to use
+* interrupt-driven gmbus and dp aux. */
+ intel_setup_outputs(dev);
+
intel_modeset_setup_hw_state(dev);
+
+ return 0;
}
void intel_modeset_cleanup(struct drm_device *dev)
--
Ben Widawsky, Intel Open Source Technology Center
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: reorder setup sequence to have irqs for output setup
Otherwise the newshiny irq-driven gmbus and dp aux code won't work that well. Noticed since the dp aux code doesn't have an automatic fallback with a timeout (since the hw provides for that already). v2: Simple move drm_irq_install before intel_modeset_gem_init, as suggested by Ben Widawsky. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_dma.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 2c09900..068b49b 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1325,12 +1325,14 @@ static int i915_load_modeset_init(struct drm_device *dev) if (ret) goto cleanup_gem_stolen; - intel_modeset_gem_init(dev); - ret = drm_irq_install(dev); if (ret) goto cleanup_gem; + /* Important: The output setup functions called by modeset_gem_init need +* working irqs for e.g. gmbus transfers. */ + intel_modeset_gem_init(dev); + /* Always safe in the mode setting case. */ /* FIXME: do pre/post-mode set stuff in core KMS code */ dev-vblank_disable_allowed = 1; -- 1.7.11.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: extract gmbus_wait_hw_status
The gmbus interrupt generation is rather fiddly: We can only ever
enable one interrupt source (but we always want to check for NAK
in addition to the real bit). And the bits in the gmbus status
register don't map at all to the bis in the irq register.
To prepare for this mess, start by extracting the hw status wait
loop into it's own function, consolidate the NAK error handling a
bit. To keep things flexible, pass in the status bit we care about
(in addition to any NAK signalling).
v2: I've failed to notice that the sens of GMBUS_ACTIVE is inverted,
Chris Wilson gladly pointed that out for me. To keep things simple,
ignore that case for now (we only need to idle the gmbus controller
at the end of an entire i2c transaction, not after every message).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_i2c.c | 46 ++--
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b9755f6..57decac 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -204,6 +204,24 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
}
static int
+gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
+u32 gmbus2_status)
+{
+ int ret;
+ int reg_offset = dev_priv-gpio_mmio_base;
+ u32 gmbus2;
+
+ ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
+ (GMBUS_SATOER | gmbus2_status),
+ 50);
+
+ if (gmbus2 GMBUS_SATOER)
+ return -ENXIO;
+
+ return ret;
+}
+
+static int
gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
u32 gmbus1_index)
{
@@ -220,15 +238,10 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
while (len) {
int ret;
u32 val, loop = 0;
- u32 gmbus2;
- ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
- (GMBUS_SATOER | GMBUS_HW_RDY),
- 50);
+ ret = gmbus_wait_hw_status(dev_priv, GMBUS_HW_RDY);
if (ret)
- return -ETIMEDOUT;
- if (gmbus2 GMBUS_SATOER)
- return -ENXIO;
+ return ret;
val = I915_READ(GMBUS3 + reg_offset);
do {
@@ -262,7 +275,6 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct
i2c_msg *msg)
GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
while (len) {
int ret;
- u32 gmbus2;
val = loop = 0;
do {
@@ -271,13 +283,9 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct
i2c_msg *msg)
I915_WRITE(GMBUS3 + reg_offset, val);
- ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
- (GMBUS_SATOER | GMBUS_HW_RDY),
- 50);
+ ret = gmbus_wait_hw_status(dev_priv, GMBUS_HW_RDY);
if (ret)
- return -ETIMEDOUT;
- if (gmbus2 GMBUS_SATOER)
- return -ENXIO;
+ return ret;
}
return 0;
}
@@ -346,8 +354,6 @@ gmbus_xfer(struct i2c_adapter *adapter,
I915_WRITE(GMBUS0 + reg_offset, bus-reg0);
for (i = 0; i num; i++) {
- u32 gmbus2;
-
if (gmbus_is_index_read(msgs, i, num)) {
ret = gmbus_xfer_index_read(dev_priv, msgs[i]);
i += 1; /* set i to the index of the read xfer */
@@ -362,13 +368,11 @@ gmbus_xfer(struct i2c_adapter *adapter,
if (ret == -ENXIO)
goto clear_err;
- ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
- (GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
- 50);
+ ret = gmbus_wait_hw_status(dev_priv, GMBUS_HW_WAIT_PHASE);
+ if (ret == -ENXIO)
+ goto clear_err;
if (ret)
goto timeout;
- if (gmbus2 GMBUS_SATOER)
- goto clear_err;
}
/* Generate a STOP condition on the bus. Note that gmbus can't generata
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915: wire up gmbus irq handler
Only enables the interrupt and puts a irq handler into place, doesn't
do anything yet.
Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
pnv, but there the irq is marked as Test mode).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d601013..86f1690 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -596,6 +596,11 @@ out:
return ret;
}
+static void gmbus_irq_handler(struct drm_device *dev)
+{
+ DRM_DEBUG_DRIVER(GMBUS interrupt\n);
+}
+
static void ibx_irq_handler(struct drm_device *dev, u32 pch_iir)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
@@ -607,7 +612,7 @@ static void ibx_irq_handler(struct drm_device *dev, u32
pch_iir)
SDE_AUDIO_POWER_SHIFT);
if (pch_iir SDE_GMBUS)
- DRM_DEBUG_DRIVER(PCH GMBUS interrupt\n);
+ gmbus_irq_handler(dev);
if (pch_iir SDE_AUDIO_HDCP_MASK)
DRM_DEBUG_DRIVER(PCH HDCP audio interrupt\n);
@@ -650,7 +655,7 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
DRM_DEBUG_DRIVER(AUX channel interrupt\n);
if (pch_iir SDE_GMBUS_CPT)
- DRM_DEBUG_DRIVER(PCH GMBUS interrupt\n);
+ gmbus_irq_handler(dev);
if (pch_iir SDE_AUDIO_CP_REQ_CPT)
DRM_DEBUG_DRIVER(Audio CP request interrupt\n);
@@ -1864,12 +1869,14 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
hotplug_mask = (SDE_CRT_HOTPLUG_CPT |
SDE_PORTB_HOTPLUG_CPT |
SDE_PORTC_HOTPLUG_CPT |
- SDE_PORTD_HOTPLUG_CPT);
+ SDE_PORTD_HOTPLUG_CPT |
+ SDE_GMBUS_CPT);
} else {
hotplug_mask = (SDE_CRT_HOTPLUG |
SDE_PORTB_HOTPLUG |
SDE_PORTC_HOTPLUG |
SDE_PORTD_HOTPLUG |
+ SDE_GMBUS |
SDE_AUX_MASK);
}
@@ -1929,7 +1936,8 @@ static int ivybridge_irq_postinstall(struct drm_device
*dev)
hotplug_mask = (SDE_CRT_HOTPLUG_CPT |
SDE_PORTB_HOTPLUG_CPT |
SDE_PORTC_HOTPLUG_CPT |
- SDE_PORTD_HOTPLUG_CPT);
+ SDE_PORTD_HOTPLUG_CPT |
+ SDE_GMBUS_CPT);
dev_priv-pch_irq_mask = ~hotplug_mask;
I915_WRITE(SDEIIR, I915_READ(SDEIIR));
@@ -1982,6 +1990,7 @@ static int valleyview_irq_postinstall(struct drm_device
*dev)
POSTING_READ(VLV_IER);
i915_enable_pipestat(dev_priv, 0, pipestat_enable);
+ i915_enable_pipestat(dev_priv, 0, PIPE_GMBUS_INTERRUPT_STATUS);
i915_enable_pipestat(dev_priv, 1, pipestat_enable);
I915_WRITE(VLV_IIR, 0x);
@@ -2477,6 +2486,7 @@ static int i965_irq_postinstall(struct drm_device *dev)
dev_priv-pipestat[0] = 0;
dev_priv-pipestat[1] = 0;
+ i915_enable_pipestat(dev_priv, 0, PIPE_GMBUS_INTERRUPT_STATUS);
/*
* Enable some error detection, note the instruction error mask
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915: use the gmbus irq for waits
We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
hand-roll the wait_event_timeout code so that we wake up every
jiffie and can check for NAKs. This way we also subsume gmbus
support for platforms without interrupts (or where those are not
yet enabled).
The important bit really is to only enable one gmbus interrupt source
at the same time - with that piece of lore figured out, this seems to
work flawlessly.
Ben Widawsky rightfully complained the lack of measurements for the
claimed benefits (especially since the first version was actually
broken and fell back to bit-banging). Previously reading the 256 byte
hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms.
Given that transfering the 256 bytes over i2c at wire speed takes
20.5ms alone, the reduction in additional overhead is rather nice.
v2: Chris Wilson wondered whether GMBUS4 might contain some set bits
when booting up an hence result in some spurious interrupts. Since we
clear GMBUS4 after every wait and we do gmbus transfer really early in
the setup sequence to detect displays the window is small, but still
be paranoid and clear it properly.
v3: Clarify the comment that gmbus irq generation can only support one
kind of event, why it bothers us and how we work around that limit.
Cc: Daniel Kurtz djku...@chromium.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/intel_i2c.c | 45 ++--
3 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26c6959..13b9e6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -419,6 +419,8 @@ typedef struct drm_i915_private {
*/
uint32_t gpio_mmio_base;
+ wait_queue_head_t gmbus_wait_queue;
+
struct pci_dev *bridge_dev;
struct intel_ring_buffer ring[I915_NUM_RINGS];
uint32_t next_seqno;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 86f1690..1741f2e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -598,7 +598,11 @@ out:
static void gmbus_irq_handler(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = (drm_i915_private_t *)
dev-dev_private;
+
DRM_DEBUG_DRIVER(GMBUS interrupt\n);
+
+ wake_up_all(dev_priv-gmbus_wait_queue);
}
static void ibx_irq_handler(struct drm_device *dev, u32 pch_iir)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 57decac..7413595 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -64,6 +64,7 @@ intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
+ I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
}
static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool enable)
@@ -205,20 +206,38 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
-u32 gmbus2_status)
+u32 gmbus2_status,
+u32 gmbus4_irq_en)
{
- int ret;
+ int i;
int reg_offset = dev_priv-gpio_mmio_base;
- u32 gmbus2;
+ u32 gmbus2 = 0;
+ DEFINE_WAIT(wait);
+
+ /* Important: The hw handles only the first bit, so set only one! Since
+* we also need to check for NAKs besides the hw ready/idle signal, we
+* need to wake up periodically and check that ourselves. */
+ I915_WRITE(GMBUS4 + reg_offset, gmbus4_irq_en);
- ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
- (GMBUS_SATOER | gmbus2_status),
- 50);
+ for (i = 0; i msecs_to_jiffies(50) + 1; i++) {
+ prepare_to_wait(dev_priv-gmbus_wait_queue, wait,
+ TASK_UNINTERRUPTIBLE);
+
+ gmbus2 = I915_READ(GMBUS2 + reg_offset);
+ if (gmbus2 (GMBUS_SATOER | gmbus2_status))
+ break;
+
+ schedule_timeout(1);
+ }
+ finish_wait(dev_priv-gmbus_wait_queue, wait);
+
+ I915_WRITE(GMBUS4 + reg_offset, 0);
if (gmbus2 GMBUS_SATOER)
return -ENXIO;
-
- return ret;
+ if (gmbus2 gmbus2_status)
+ return 0;
+ return -ETIMEDOUT;
}
static int
@@ -239,7 +258,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
u32 val, loop = 0;
- ret = gmbus_wait_hw_status(dev_priv, GMBUS_HW_RDY);
[Intel-gfx] [PATCH 6/8] drm/i915: only read SDE_IIR when required on ilk/snb
The same optimization has already been applied to the ivb irq handler in
commit 0e43406bcc1868a316eea6012a0a09d992c53521
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed May 9 21:45:44 2012 +0100
drm/i915: Simplify interrupt processing for IvyBridge
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1741f2e..f836e89 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -754,7 +754,7 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
struct drm_device *dev = (struct drm_device *) arg;
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
int ret = IRQ_NONE;
- u32 de_iir, gt_iir, de_ier, pch_iir, pm_iir;
+ u32 de_iir, gt_iir, de_ier, pm_iir;
u32 hotplug_mask;
atomic_inc(dev_priv-irq_received);
@@ -766,11 +766,9 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
de_iir = I915_READ(DEIIR);
gt_iir = I915_READ(GTIIR);
- pch_iir = I915_READ(SDEIIR);
pm_iir = I915_READ(GEN6_PMIIR);
- if (de_iir == 0 gt_iir == 0 pch_iir == 0
- (!IS_GEN6(dev) || pm_iir == 0))
+ if (de_iir == 0 gt_iir == 0 (!IS_GEN6(dev) || pm_iir == 0))
goto done;
if (HAS_PCH_CPT(dev))
@@ -806,12 +804,17 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
/* check event from PCH */
if (de_iir DE_PCH_EVENT) {
+ u32 pch_iir = I915_READ(SDEIIR);
+
if (pch_iir hotplug_mask)
queue_work(dev_priv-wq, dev_priv-hotplug_work);
if (HAS_PCH_CPT(dev))
cpt_irq_handler(dev, pch_iir);
else
ibx_irq_handler(dev, pch_iir);
+
+ /* should clear PCH hotplug event before clear CPU irq */
+ I915_WRITE(SDEIIR, pch_iir);
}
if (IS_GEN5(dev) de_iir DE_PCU_EVENT)
@@ -820,8 +823,6 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
if (IS_GEN6(dev) pm_iir GEN6_PM_DEFERRED_EVENTS)
gen6_queue_rps_work(dev_priv, pm_iir);
- /* should clear PCH hotplug event before clear CPU irq */
- I915_WRITE(SDEIIR, pch_iir);
I915_WRITE(GTIIR, gt_iir);
I915_WRITE(DEIIR, de_iir);
I915_WRITE(GEN6_PMIIR, pm_iir);
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915: irq-drive the dp aux communication
At least on the platforms that have a dp aux irq and also have it
enabled - vlv/hsw should have one, too. But I don't have a machine to
test this on, and the current code doesn't support dp yet anyway on
those platforms. Judging from docs there's no dp aux interrupt for gm45.
Also, I only have an ivb cpu edp machine, so the dp aux A code for
snb/ilk is untested.
For dpcd probing when nothing is connected it slashes about 5ms of cpu
time (cpu time is now negligible), which agrees with 3 * 5 400 usec
timeouts.
A previous version of this patch increases the time required to go
through the dp_detect cycle (which includes reading the edid) from
around 33 ms to around 40 ms. Experiments indicated that this is
purely due to the irq latency - the hw doesn't allow us to queue up
dp aux transactions and hence irq latency directly affects throughput.
gmbus is much better, there we have a 8 byte buffer, and we get the
irq once another 4 bytes can be queued up.
But by using the pm_qos interface to request the lowest possible cpu
wake-up latency this slowdown completely disappeared.
Since all our output detection logic is single-threaded with the
mode_config mutex right now anyway, I've decide not ot play fancy and
to just reuse the gmbus wait queue. But this would definitely prep the
way to run dp detection on different ports in parallel
v2: Add a timeout for dp aux transfers when using interrupts - the hw
_does_ prevent this with the hw-based 400 usec timeout, but if the
irq somehow doesn't arrive we're screwed. Lesson learned while
developing this ;-)
v3: While at it also convert the busy-loop to wait_for_atomic, so that
we don't run the risk of an infinite loop any more.
v4: Ensure we have the smallest possible irq latency by using the
pm_qos interface.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 4 +++
drivers/gpu/drm/i915/i915_irq.c | 6 +
drivers/gpu/drm/i915/intel_dp.c | 55 +++--
4 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 068b49b..568913b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1761,6 +1761,7 @@ int i915_driver_unload(struct drm_device *dev)
intel_teardown_mchbar(dev);
destroy_workqueue(dev_priv-wq);
+ pm_qos_remove_request(dev_priv-pm_qos);
pci_dev_put(dev_priv-bridge_dev);
kfree(dev-dev_private);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 13b9e6a..50c6edf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -40,6 +40,7 @@
#include linux/backlight.h
#include linux/intel-iommu.h
#include linux/kref.h
+#include linux/pm_qos.h
/* General customization:
*/
@@ -437,6 +438,9 @@ typedef struct drm_i915_private {
/* protects the irq masks */
spinlock_t irq_lock;
+ /* To control wakeup latency, e.g. for irq-driven dp aux transfers. */
+ struct pm_qos_request pm_qos;
+
/* DPIO indirect register protection */
spinlock_t dpio_lock;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c483531..bcb2624 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -607,7 +607,11 @@ static void gmbus_irq_handler(struct drm_device *dev)
static void dp_aux_irq_handler(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = (drm_i915_private_t *)
dev-dev_private;
+
DRM_DEBUG_DRIVER(AUX channel interrupt\n);
+
+ wake_up_all(dev_priv-gmbus_wait_queue);
}
static void ibx_irq_handler(struct drm_device *dev, u32 pch_iir)
@@ -2718,6 +2722,8 @@ void intel_irq_init(struct drm_device *dev)
INIT_WORK(dev_priv-rps.work, gen6_pm_rps_work);
INIT_WORK(dev_priv-parity_error_work, ivybridge_parity_work);
+ pm_qos_add_request(dev_priv-pm_qos, PM_QOS_CPU_DMA_LATENCY, 0);
+
dev-driver-get_vblank_counter = i915_get_vblank_counter;
dev-max_vblank_count = 0xff; /* only 24 bits of frame count */
if (IS_G4X(dev) || INTEL_INFO(dev)-gen = 5) {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f28353d..5d98a53 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -340,6 +340,28 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
}
}
+static uint32_t
+intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
+{
+ struct drm_device *dev = intel_dp-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t ch_ctl = intel_dp-output_reg + 0x10;
+ uint32_t status;
+ bool done;
+
+#define C (((status = I915_READ(ch_ctl)) DP_AUX_CH_CTL_SEND_BUSY) == 0)
+ if (has_aux_irq)
+ done =
[Intel-gfx] Updated -testing
Hi All, New -testing cycle. Highlights from this -next: - New modeset code framework. - Tiny fix in the fb helper to go through the official dpms interface instead of calling the crtc helper code. - forcewake code frobbery from Ben, code should be more in-line with what Windows does now. - fixes for the render ring flush on hsw (Paulo) - gpu frequency tracepoint - vlv forcewake changes to better align it with our understanding of the forcewake magic. - a few smaller cleanups Happy testing! Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: irq-drive the dp aux communication
At least on the platforms that have a dp aux irq and also have it
enabled - vlv/hsw should have one, too. But I don't have a machine to
test this on, and the current code doesn't support dp yet anyway on
those platforms. Judging from docs there's no dp aux interrupt for gm45.
Also, I only have an ivb cpu edp machine, so the dp aux A code for
snb/ilk is untested.
For dpcd probing when nothing is connected it slashes about 5ms of cpu
time (cpu time is now negligible), which agrees with 3 * 5 400 usec
timeouts.
A previous version of this patch increases the time required to go
through the dp_detect cycle (which includes reading the edid) from
around 33 ms to around 40 ms. Experiments indicated that this is
purely due to the irq latency - the hw doesn't allow us to queue up
dp aux transactions and hence irq latency directly affects throughput.
gmbus is much better, there we have a 8 byte buffer, and we get the
irq once another 4 bytes can be queued up.
But by using the pm_qos interface to request the lowest possible cpu
wake-up latency this slowdown completely disappeared.
Since all our output detection logic is single-threaded with the
mode_config mutex right now anyway, I've decide not ot play fancy and
to just reuse the gmbus wait queue. But this would definitely prep the
way to run dp detection on different ports in parallel
v2: Add a timeout for dp aux transfers when using interrupts - the hw
_does_ prevent this with the hw-based 400 usec timeout, but if the
irq somehow doesn't arrive we're screwed. Lesson learned while
developing this ;-)
v3: While at it also convert the busy-loop to wait_for_atomic, so that
we don't run the risk of an infinite loop any more.
v4: Ensure we have the smallest possible irq latency by using the
pm_qos interface.
v5: Add a comment to the code to explain why we frob pm_qos. Suggested
by Chris Wilson.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 4 +++
drivers/gpu/drm/i915/i915_irq.c | 6 +
drivers/gpu/drm/i915/intel_dp.c | 59 -
4 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 068b49b..568913b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1761,6 +1761,7 @@ int i915_driver_unload(struct drm_device *dev)
intel_teardown_mchbar(dev);
destroy_workqueue(dev_priv-wq);
+ pm_qos_remove_request(dev_priv-pm_qos);
pci_dev_put(dev_priv-bridge_dev);
kfree(dev-dev_private);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 13b9e6a..50c6edf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -40,6 +40,7 @@
#include linux/backlight.h
#include linux/intel-iommu.h
#include linux/kref.h
+#include linux/pm_qos.h
/* General customization:
*/
@@ -437,6 +438,9 @@ typedef struct drm_i915_private {
/* protects the irq masks */
spinlock_t irq_lock;
+ /* To control wakeup latency, e.g. for irq-driven dp aux transfers. */
+ struct pm_qos_request pm_qos;
+
/* DPIO indirect register protection */
spinlock_t dpio_lock;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c483531..bcb2624 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -607,7 +607,11 @@ static void gmbus_irq_handler(struct drm_device *dev)
static void dp_aux_irq_handler(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = (drm_i915_private_t *)
dev-dev_private;
+
DRM_DEBUG_DRIVER(AUX channel interrupt\n);
+
+ wake_up_all(dev_priv-gmbus_wait_queue);
}
static void ibx_irq_handler(struct drm_device *dev, u32 pch_iir)
@@ -2718,6 +2722,8 @@ void intel_irq_init(struct drm_device *dev)
INIT_WORK(dev_priv-rps.work, gen6_pm_rps_work);
INIT_WORK(dev_priv-parity_error_work, ivybridge_parity_work);
+ pm_qos_add_request(dev_priv-pm_qos, PM_QOS_CPU_DMA_LATENCY, 0);
+
dev-driver-get_vblank_counter = i915_get_vblank_counter;
dev-max_vblank_count = 0xff; /* only 24 bits of frame count */
if (IS_G4X(dev) || INTEL_INFO(dev)-gen = 5) {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f28353d..0ddc9be 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -340,6 +340,28 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
}
}
+static uint32_t
+intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
+{
+ struct drm_device *dev = intel_dp-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t ch_ctl = intel_dp-output_reg + 0x10;
+ uint32_t status;
+ bool done;
+
+#define C (((status = I915_READ(ch_ctl)) DP_AUX_CH_CTL_SEND_BUSY) == 0)
[Intel-gfx] [PATCH] drm/i915: set the right gen3 flip_done mode also at resume
Currently we've only frobbed this bit at irq_init time, but did
not restore it at resume time. Move it to the gen3 clock gating
function to fix this.
Notice while reading through code.
Cc: sta...@vger.kernel.org (for 3.5 only)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 3 ---
drivers/gpu/drm/i915/intel_pm.c | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bcb2624..71688fc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2774,9 +2774,6 @@ void intel_irq_init(struct drm_device *dev)
dev-driver-irq_handler = i8xx_irq_handler;
dev-driver-irq_uninstall = i8xx_irq_uninstall;
} else if (INTEL_INFO(dev)-gen == 3) {
- /* IIR flip pending means done if this bit is set */
- I915_WRITE(ECOSKPD, _MASKED_BIT_DISABLE(ECO_FLIP_DONE));
-
dev-driver-irq_preinstall = i915_irq_preinstall;
dev-driver-irq_postinstall = i915_irq_postinstall;
dev-driver-irq_uninstall = i915_irq_uninstall;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 36c6409..99ef6d2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3723,6 +3723,9 @@ static void gen3_init_clock_gating(struct drm_device *dev)
if (IS_PINEVIEW(dev))
I915_WRITE(ECOSKPD, _MASKED_BIT_ENABLE(ECO_GATING_CX_ONLY));
+
+ /* IIR flip pending means done if this bit is set */
+ I915_WRITE(ECOSKPD, _MASKED_BIT_DISABLE(ECO_FLIP_DONE));
}
static void i85x_init_clock_gating(struct drm_device *dev)
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: set the right gen3 flip_done mode also at resume
On Sun, 9 Sep 2012 11:54:16 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Currently we've only frobbed this bit at irq_init time, but did not restore it at resume time. Move it to the gen3 clock gating function to fix this. Notice while reading through code. Cc: sta...@vger.kernel.org (for 3.5 only) Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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: irq-drive the dp aux communication
On Sun, 9 Sep 2012 11:29:24 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: At least on the platforms that have a dp aux irq and also have it enabled - vlv/hsw should have one, too. But I don't have a machine to test this on, and the current code doesn't support dp yet anyway on those platforms. Judging from docs there's no dp aux interrupt for gm45. Also, I only have an ivb cpu edp machine, so the dp aux A code for snb/ilk is untested. Typing this on a ilk pch dp, it seems to be holding up fine. -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
[Intel-gfx] [PATCH] drm/i915: use _NOTRACE for gmbus/dp aux wait loops
Less clutter in the traces. And in both cases we yell rather loud into the logs if we time out. Patch suggested by Chris Wilson. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_dp.c | 2 +- drivers/gpu/drm/i915/intel_i2c.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 0ddc9be..1aae1a1 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -349,7 +349,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq) uint32_t status; bool done; -#define C (((status = I915_READ(ch_ctl)) DP_AUX_CH_CTL_SEND_BUSY) == 0) +#define C (((status = I915_READ_NOTRACE(ch_ctl)) DP_AUX_CH_CTL_SEND_BUSY) == 0) if (has_aux_irq) done = wait_event_timeout(dev_priv-gmbus_wait_queue, C, 10); else diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 4a38a30..31b1a65 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -224,7 +224,7 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv, prepare_to_wait(dev_priv-gmbus_wait_queue, wait, TASK_UNINTERRUPTIBLE); - gmbus2 = I915_READ(GMBUS2 + reg_offset); + gmbus2 = I915_READ_NOTRACE(GMBUS2 + reg_offset); if (gmbus2 (GMBUS_SATOER | gmbus2_status)) break; @@ -247,7 +247,7 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv) int ret; int reg_offset = dev_priv-gpio_mmio_base; -#define C ((I915_READ(GMBUS2 + reg_offset) GMBUS_ACTIVE) == 0) +#define C ((I915_READ_NOTRACE(GMBUS2 + reg_offset) GMBUS_ACTIVE) == 0) if (!HAS_GMBUS_IRQ(dev_priv-dev)) return wait_for(C, 10); -- 1.7.11.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fighting tearing
Hello I run Arch Linux, with it's latest x.org and kernel, and I have compiled libdrm and the intel driver from git, and I update it today. Buit this is issue exists even with the releases. WIth UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy Option TripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Thanks in advance for any help. Regards, Roberth Sjonøy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fighting tearing
Dear Roberth, Am Sonntag, den 09.09.2012, 17:48 +0200 schrieb Roberth Sjonøy: I run Arch Linux, with it's latest x.org and kernel, that is xorg-server 1.12.4-1 [1] and linux 3.5.3-1 [2]. and I have compiled libdrm and the intel driver from git, and I update it today. Please provide the Git commit hashes with the commit summaries to make life for readers of your message easier. But this is issue exists even with the releases. Since when do you experience these issues? With UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Maybe your monitor causes the tearing? Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy OptionTripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Is the tearing fixed though? What happens when you test different Window managers or some live distribution with other versions? You can even test those by saving the ISO file on your drive and directly boot those using GRUB 2 [3]. Thanks in advance for any help. I am sorry for not being more helpful. Maybe the developers have more ideas. Thanks, Paul [1] http://www.archlinux.org/packages/extra/i686/xorg-server/ [2] http://www.archlinux.org/packages/core/i686/linux/ [3] https://bugs.freedesktop.org/show_bug.cgi?id=26294#c13 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] Fwd: Fighting tearing
-- Forwarded message -- From: Roberth Sjonøy roberth.sjo...@gmail.com Date: Sun, Sep 9, 2012 at 6:48 PM Subject: Re: [Intel-gfx] Fighting tearing To: Paul Menzel paulepan...@users.sourceforge.net On Sun, Sep 9, 2012 at 6:42 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Roberth, Am Sonntag, den 09.09.2012, 17:48 +0200 schrieb Roberth Sjonøy: I run Arch Linux, with it's latest x.org and kernel, that is xorg-server 1.12.4-1 [1] and linux 3.5.3-1 [2]. Yes. and I have compiled libdrm and the intel driver from git, and I update it today. Please provide the Git commit hashes with the commit summaries to make life for readers of your message easier. Ehm, how I do that? What I simply did was a PKGBUILD and built the packages from git with archs packagemanagementsystem. But this is issue exists even with the releases. Since when do you experience these issues? With UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Maybe your monitor causes the tearing? Thats what I am trying to figure out. Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy OptionTripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Is the tearing fixed though? I will have to come back on that later need to test, to be sure. What happens when you test different Window managers or some live distribution with other versions? You can even test those by saving the ISO file on your drive and directly boot those using GRUB 2 [3]. Tried different WMs but I wanna stick with XFCE. Thanks in advance for any help. I am sorry for not being more helpful. Maybe the developers have more ideas. No problem. Thanks, Paul [1] http://www.archlinux.org/packages/extra/i686/xorg-server/ [2] http://www.archlinux.org/packages/core/i686/linux/ [3] https://bugs.freedesktop.org/show_bug.cgi?id=26294#c13 ___ 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] Fwd: Fighting tearing
-- Forwarded message -- From: Roberth Sjonøy roberth.sjo...@gmail.com Date: Sun, Sep 9, 2012 at 6:52 PM Subject: Re: [Intel-gfx] Fighting tearing To: Paul Menzel paulepan...@users.sourceforge.net Tested with SNA. tearing is gone, but the performance of rendering windows in totally unacceptable. Regards, Roberth Sjonøy On Sun, Sep 9, 2012 at 6:48 PM, Roberth Sjonøy roberth.sjo...@gmail.com wrote: On Sun, Sep 9, 2012 at 6:42 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Roberth, Am Sonntag, den 09.09.2012, 17:48 +0200 schrieb Roberth Sjonøy: I run Arch Linux, with it's latest x.org and kernel, that is xorg-server 1.12.4-1 [1] and linux 3.5.3-1 [2]. Yes. and I have compiled libdrm and the intel driver from git, and I update it today. Please provide the Git commit hashes with the commit summaries to make life for readers of your message easier. Ehm, how I do that? What I simply did was a PKGBUILD and built the packages from git with archs packagemanagementsystem. But this is issue exists even with the releases. Since when do you experience these issues? With UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Maybe your monitor causes the tearing? Thats what I am trying to figure out. Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy OptionTripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Is the tearing fixed though? I will have to come back on that later need to test, to be sure. What happens when you test different Window managers or some live distribution with other versions? You can even test those by saving the ISO file on your drive and directly boot those using GRUB 2 [3]. Tried different WMs but I wanna stick with XFCE. Thanks in advance for any help. I am sorry for not being more helpful. Maybe the developers have more ideas. No problem. Thanks, Paul [1] http://www.archlinux.org/packages/extra/i686/xorg-server/ [2] http://www.archlinux.org/packages/core/i686/linux/ [3] https://bugs.freedesktop.org/show_bug.cgi?id=26294#c13 ___ 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
Re: [Intel-gfx] [PATCH] drm/i915: reorder setup sequence to have irqs for output setup
On 2012-09-09 02:50, Daniel Vetter wrote:
On Sun, Sep 9, 2012 at 3:59 AM, Ben Widawsky b...@bwidawsk.net
wrote:
On 2012-09-06 06:43, Daniel Vetter wrote:
Otherwise the newshiny irq-driven gmbus and dp aux code won't work
that
well. Noticed since the dp aux code doesn't have an automatic
fallback
with a timeout (since the hw provides for that already).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 15 +--
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 2cba7b4..58320e0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1325,9 +1325,8 @@ static int i915_load_modeset_init(struct
drm_device *dev)
if (ret)
goto cleanup_gem_stolen;
- intel_modeset_gem_init(dev);
-
- ret = drm_irq_install(dev);
+ /* Note: This also enables irqs. */
+ ret = intel_modeset_gem_init(dev);
if (ret)
goto cleanup_gem;
I'd much rather you just drm_irq_install() before
intel_modeset_gem_init(),
unless there is some reason that won't work?
I've simple been paranoid and wanted to enable the irq as late as
possible. After rechecking the code I think just moving the irq
enabling up a bit should be safe, too. I'll do that.
Thanks, Daniel
mm.interruptible = false; //paranoia
drm_irq_install()
intel_modeset_gem_init()
^^ seemed okay to me
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 9fce782..5c8d5e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1536,7 +1536,7 @@ static inline void
intel_unregister_dsm_handler(void) { return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern void intel_modeset_init(struct drm_device *dev);
-extern void intel_modeset_gem_init(struct drm_device *dev);
+extern int intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
extern int intel_modeset_vga_set_state(struct drm_device *dev,
bool
state);
extern void intel_modeset_setup_hw_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6658367..01289eb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7948,7 +7948,6 @@ void intel_modeset_init(struct drm_device
*dev)
/* Just disable it once at startup */
i915_disable_vga(dev);
- intel_setup_outputs(dev);
}
static void
@@ -8206,13 +8205,25 @@ void intel_modeset_setup_hw_state(struct
drm_device *dev)
drm_mode_config_reset(dev);
}
-void intel_modeset_gem_init(struct drm_device *dev)
+int intel_modeset_gem_init(struct drm_device *dev)
{
+ int ret;
+
intel_modeset_init_hw(dev);
intel_setup_overlay(dev);
+ ret = drm_irq_install(dev);
+ if (ret)
+ return ret;
+
+ /* Importanat: Output setup needs working interrupts to use
+* interrupt-driven gmbus and dp aux. */
+ intel_setup_outputs(dev);
+
intel_modeset_setup_hw_state(dev);
+
+ return 0;
}
void intel_modeset_cleanup(struct drm_device *dev)
--
Ben Widawsky, Intel Open Source Technology Center
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fighting tearing
On 2012-09-09 08:48, Roberth Sjonøy wrote: Hello I run Arch Linux, with it's latest x.org and kernel, and I have compiled libdrm and the intel driver from git, and I update it today. Buit this is issue exists even with the releases. WIth UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy Option TripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Thanks in advance for any help. Regards, Roberth Sjonøy0 Unfortunately it's often the case that tearing is pretty much unavoidable without a compositor. AFAIK you'd just be getting lucky with SNA, as opposed to UXA. However, for the SNA slowness, you should file a bug and include the following information: lspci -n -s 2.0 /var/log/Xorg.0.log dmesg with drm.debug=0xe sometime after experiencing the slowness feel free to mention UXA is much faster -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fighting tearing
On Sun, 09 Sep 2012 10:55:46 -0700, Ben Widawsky b...@bwidawsk.net wrote: On 2012-09-09 08:48, Roberth Sjonøy wrote: Hello I run Arch Linux, with it's latest x.org and kernel, and I have compiled libdrm and the intel driver from git, and I update it today. Buit this is issue exists even with the releases. WIth UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy Option TripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Thanks in advance for any help. Regards, Roberth Sjonøy0 Unfortunately it's often the case that tearing is pretty much unavoidable without a compositor. AFAIK you'd just be getting lucky with SNA, as opposed to UXA. Not so. He is explicitly asking for slow tear-free rendering with Option TearFree true. On my machines that takes about a 50% performance hit which suggests pebkac which is reinforced by the lack of information. -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
[Intel-gfx] Sandy Bridge: Return of the running fan issue
Dear list, I've previously had an issue with my Dell Laptop (Latitude E5520) which has a i915 graphics card on a Sandy Bridge (2011-12-13 Fan running with Intel Graphics). The fan was running because apparently the GPU was not going into powersave mode. Now, by sheer stupidity on my part, I've lost my kernel configuration and the (working) kernel image. So I embarked on the journey to retrieve the latest git and see how it goes. Sadly, the running fan is back: I've checked out drm-intel-testing, rev. c3c3d4e9. My kernel command line looks like this: pcie_aspm=force i915.i915_enable_rc6=3 i915.lvds_downclock=1 i915.i915_enable_fbc=1 nomodeset Previously, I've always done echo 400 /sys/kernel/debug/dri/0/i915_max_freq but with this kernel revision, /sys/kernel/debug/dri/ is empty and there's no i915_max_freq node anywhere to be found within /sys. Should I update to a different branch? Should I change the kernel command line? Or are there other options? Any advice is greatly appreciated, All the best, Joe ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Error checks in gen6_set_rps
On Fri, 7 Sep 2012 19:43:42 -0700, Ben Widawsky b...@bwidawsk.net wrote: With the new standardized sysfs interfaces we need to be a bit more careful about setting the RPS values. Because the sysfs code and the rps workqueue can run at the same time, if the sysfs setter wins the race to the mutex, the workqueue can come in and set a value which is out of range (ie. we're no longer protecting by RPINTLIM). I was not able to actually make this error occur in testing. Signed-off-by: Ben Widawsky b...@bwidawsk.net Good catch, care to squeeze the comment into a single line ;-) Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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
[Intel-gfx] [PATCH] drm/i915: rip out edp special case from dp_link_down
This has been tons of fun to figure out with git blame. The first
notion of this code block goes back to the original cpu edp enabling
for ilk in
commit 32f9d658aee5be09ebdd28fc730630e61d0b46db
Author: Zhenyu Wang zhen...@linux.intel.com
Date: Fri Jul 24 01:00:32 2009 +0800
drm/i915: Add eDP support on IGDNG mobile chip
Two things are notable in this commit wrt to the this edp special
case:
- The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports.
- The cpu edp port is disabled at the top of the dp_link_down function.
My theory is that these hacks was added to work around the completely
different modeset sequence for cpu edp ports compared to pch edp
ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up,
this shouldn't be required any more.
The really interesting question is how this special cases survived
this long in the code. The first step is declaring the pch port D as
eDP if it's used for an internal panel:
commit b329530ca7cdf6bf014f2124efd983e01265d623
Author: Adam Jackson a...@redhat.com
Date: Fri Jul 16 14:46:28 2010 -0400
drm/i915/dp: Correctly report eDP in the core connector type
This commit unfortunately failed to notice that not all edp ports are
created equal. Then follow a flurry of refactorings, culminating in a
patch from Keith Packard which resulted in the current logic (by
making it correct for all platforms that have edp):
commit 417e822deee1d2bcd8a8a60660c40a0903713f2b
Author: Keith Packard kei...@keithp.com
Date: Tue Nov 1 19:54:11 2011 -0700
drm/i915: Treat PCH eDP like DP in most places
None of these cleanups or refactorings supply any reason why we need
this code, they've simply carried it on as-is.
Hence presume it might be harmful with the current code and rip it
out. We do rewrite the link training bits completely anyway when
re-training the link.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f28353d..8adad5e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1934,13 +1934,6 @@ intel_dp_link_down(struct intel_dp *intel_dp)
msleep(17);
- if (is_edp(intel_dp)) {
- if (HAS_PCH_CPT(dev) (IS_GEN7(dev) || !is_cpu_edp(intel_dp)))
- DP |= DP_LINK_TRAIN_OFF_CPT;
- else
- DP |= DP_LINK_TRAIN_OFF;
- }
-
if (HAS_PCH_IBX(dev)
I915_READ(intel_dp-output_reg) DP_PIPEB_SELECT) {
struct drm_crtc *crtc = intel_dp-base.base.crtc;
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] Unified DRM GPU frequency knobs
On the Intel driver we've developed and reviewed some patches which enable GPU frequency settings in sysfs. Similar interfaces have existed for some time in our debugfs, but now we're getting interest from users like PowerTOP and have decided to formalize it. Most likely other DRM drivers have similar features; and perhaps similar proposals have gone out in the past. Boiling down what we've exposed in our patches: read current GPU frequency read/write min frequency read/write max frequency read HW support lowest frequency (we call this RPn) read HW supported highest frequency (we call this RP0) read HW recommended low frequnecy (we call this RP1) If no interest is perceived we will move forward with these as Intel only sysfs interfaces. The Intel specific patches which are ready to go are here: http://lists.freedesktop.org/archives/intel-gfx/2012-September/020342.html Thanks. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Unified DRM GPU frequency knobs
On Sun, 9 Sep 2012 12:42:55 -0700 Ben Widawsky b...@bwidawsk.net wrote: On the Intel driver we've developed and reviewed some patches which enable GPU frequency settings in sysfs. Similar interfaces have existed for some time in our debugfs, but now we're getting interest from users like PowerTOP and have decided to formalize it. Most likely other DRM drivers have similar features; and perhaps similar proposals have gone out in the past. Boiling down what we've exposed in our patches: read current GPU frequency read/write min frequency read/write max frequency read HW support lowest frequency (we call this RPn) read HW supported highest frequency (we call this RP0) read HW recommended low frequnecy (we call this RP1) If no interest is perceived we will move forward with these as Intel only sysfs interfaces. The Intel specific patches which are ready to go are here: http://lists.freedesktop.org/archives/intel-gfx/2012-September/020342.html Thanks. I was called out for not being clear. I'm asking if there is interest in making unified knobs in DRM as opposed to driver specific knobs. Is that even a good idea, and/or make sense to do? -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fighting tearing
Hello What can I do then? Wait for SNA to mature more? Other settings with UXA or SNA? Regards Roberth Sjonøy On Sun, Sep 9, 2012 at 8:00 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, 09 Sep 2012 10:55:46 -0700, Ben Widawsky b...@bwidawsk.net wrote: On 2012-09-09 08:48, Roberth Sjonøy wrote: Hello I run Arch Linux, with it's latest x.org and kernel, and I have compiled libdrm and the intel driver from git, and I update it today. Buit this is issue exists even with the releases. WIth UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy Option TripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Thanks in advance for any help. Regards, Roberth Sjonøy0 Unfortunately it's often the case that tearing is pretty much unavoidable without a compositor. AFAIK you'd just be getting lucky with SNA, as opposed to UXA. Not so. He is explicitly asking for slow tear-free rendering with Option TearFree true. On my machines that takes about a 50% performance hit which suggests pebkac which is reinforced by the lack of information. -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] Fighting tearing
I also experience tearing when viewing web sites with chromium and scrolling downwards webnewspapers etc. Hope this adds more relevant info. On Sun, Sep 9, 2012 at 8:00 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, 09 Sep 2012 10:55:46 -0700, Ben Widawsky b...@bwidawsk.net wrote: On 2012-09-09 08:48, Roberth Sjonøy wrote: Hello I run Arch Linux, with it's latest x.org and kernel, and I have compiled libdrm and the intel driver from git, and I update it today. Buit this is issue exists even with the releases. WIth UXA, rendering of the windows in my XFCE4-desktop goes just fines, good performance, windows (exspecially GTK+) doesn't hang after if I drag them over the screen, but there is lot of small tearing. And I want this to go away, I do not use any kind of composition, and I am using XFCEs window manager. Here is my xorg.conf Section ServerFlags Option AutoAddDevices Off EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout no EndSection Section Device Identifier Card0 Driver intel Option AccelMethod UXA Option TearFree true Option MigrationHeuristic greedy Option TripleBuffer true EndSection With SNA, the performance of the applications is muc much worse. If I just replace UXA with SNA. Thanks in advance for any help. Regards, Roberth Sjonøy0 Unfortunately it's often the case that tearing is pretty much unavoidable without a compositor. AFAIK you'd just be getting lucky with SNA, as opposed to UXA. Not so. He is explicitly asking for slow tear-free rendering with Option TearFree true. On my machines that takes about a 50% performance hit which suggests pebkac which is reinforced by the lack of information. -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 4/8] drm/i915: use the gmbus irq for waits
On Sun, Sep 9, 2012 at 5:00 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
hand-roll the wait_event_timeout code so that we wake up every
jiffie and can check for NAKs. This way we also subsume gmbus
support for platforms without interrupts (or where those are not
yet enabled).
Hi Daniel V,
The important bit really is to only enable one gmbus interrupt source
at the same time - with that piece of lore figured out, this seems to
work flawlessly.
Great find!
Overall, this looks and sounds great.
See some comments inline...
Ben Widawsky rightfully complained the lack of measurements for the
claimed benefits (especially since the first version was actually
broken and fell back to bit-banging). Previously reading the 256 byte
hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms.
Given that transfering the 256 bytes over i2c at wire speed takes
20.5ms alone, the reduction in additional overhead is rather nice.
v2: Chris Wilson wondered whether GMBUS4 might contain some set bits
when booting up an hence result in some spurious interrupts. Since we
clear GMBUS4 after every wait and we do gmbus transfer really early in
the setup sequence to detect displays the window is small, but still
be paranoid and clear it properly.
v3: Clarify the comment that gmbus irq generation can only support one
kind of event, why it bothers us and how we work around that limit.
Cc: Daniel Kurtz djku...@chromium.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/intel_i2c.c | 45
++--
3 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26c6959..13b9e6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -419,6 +419,8 @@ typedef struct drm_i915_private {
*/
uint32_t gpio_mmio_base;
+ wait_queue_head_t gmbus_wait_queue;
+
struct pci_dev *bridge_dev;
struct intel_ring_buffer ring[I915_NUM_RINGS];
uint32_t next_seqno;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 86f1690..1741f2e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -598,7 +598,11 @@ out:
static void gmbus_irq_handler(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = (drm_i915_private_t *)
dev-dev_private;
+
DRM_DEBUG_DRIVER(GMBUS interrupt\n);
+
+ wake_up_all(dev_priv-gmbus_wait_queue);
}
static void ibx_irq_handler(struct drm_device *dev, u32 pch_iir)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c
b/drivers/gpu/drm/i915/intel_i2c.c
index 57decac..7413595 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -64,6 +64,7 @@ intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
+ I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
}
static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool
enable)
@@ -205,20 +206,38 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
-u32 gmbus2_status)
+u32 gmbus2_status,
+u32 gmbus4_irq_en)
{
- int ret;
+ int i;
int reg_offset = dev_priv-gpio_mmio_base;
- u32 gmbus2;
+ u32 gmbus2 = 0;
Technically, initializing gmbus2 here isn't necessary, since you
always assign it first before reading.
+ DEFINE_WAIT(wait);
+
+ /* Important: The hw handles only the first bit, so set only one!
Since
+* we also need to check for NAKs besides the hw ready/idle signal, we
+* need to wake up periodically and check that ourselves. */
-- It is unfortunate that we can't enable both HW_WAIT/HW_RDY NAK irqs.
When I tried it before, it seemed to work... but something was always
unstable, and I never figured out what.
+ I915_WRITE(GMBUS4 + reg_offset, gmbus4_irq_en);
- ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
- (GMBUS_SATOER | gmbus2_status),
- 50);
+ for (i = 0; i msecs_to_jiffies(50) + 1; i++) {
Should there be an initial check of our condition before entering the wait?
+ prepare_to_wait(dev_priv-gmbus_wait_queue, wait,
+ TASK_UNINTERRUPTIBLE);
Should this wait be interruptible?
+
+ gmbus2 =
