Re: [Intel-gfx] Intel 2010Q2 release
В сообщении от 27 июня 2010 15:31:28 автор Chris Wilson написал: > On Sun, 27 Jun 2010 14:30:24 +0300, Vasily Khoruzhick wrote: > > Ok, I'll file bug once I reproduce it once again (can't reproduce it > > since posted first mail :(). > > Thankyou, the information will be appreciated. Here it is: https://bugs.freedesktop.org/show_bug.cgi?id=28785 signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: fix ironlake edp panel setup (v2)
This also didn't fix the Dell E6410. I'll also note this in the bug.
I'm trying to work with some contacts at Dell to get this routed to
the right person as well...but am having limited luck with that, so
far.
On Mon, Jun 28, 2010 at 2:28 AM, Dave Airlie wrote:
> On Mon, Jun 28, 2010 at 4:04 PM, Zhenyu Wang wrote:
>> On 2010.06.28 09:45:14 +1000, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> So the previous fix didn't work for everyone, I read the eDP spec and
>>> claims a 20% overhead for encoding, so make sure we take this into account
>>> when working out the bandwidth requirements.
>>>
>>> This makes my eDP panel happy also, please test on others.
>>>
>>> Signed-off-by: Dave Airlie
>>> ---
>>> drivers/gpu/drm/i915/intel_dp.c | 10 --
>>> 1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 6094e42..9830243 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -139,6 +139,12 @@ intel_dp_link_required(struct drm_device *dev,
>>> }
>>>
>>> static int
>>> +intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>>> +{
>>> + return (max_link_clock * max_lanes * 8) / 10;
>>> +}
>>> +
>>> +static int
>>> intel_dp_mode_valid(struct drm_connector *connector,
>>> struct drm_display_mode *mode)
>>> {
>>> @@ -148,7 +154,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
>>> int max_lanes = intel_dp_max_lane_count(intel_encoder);
>>>
>>> if (intel_dp_link_required(connector->dev, intel_encoder, mode->clock)
>>> - > max_link_clock * max_lanes)
>>> + > intel_dp_max_data_rate(max_link_clock, max_lanes))
>>> return MODE_CLOCK_HIGH;
>>>
>>> if (mode->clock < 1)
>>> @@ -509,7 +515,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
>>> drm_display_mode *mode,
>>>
>>> for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
>>> for (clock = 0; clock <= max_clock; clock++) {
>>> - int link_avail = intel_dp_link_clock(bws[clock]) *
>>> lane_count;
>>> + int link_avail =
>>> intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
>>>
>>> if (intel_dp_link_required(encoder->dev,
>>> intel_encoder, mode->clock)
>>> <= link_avail) {
>>> --
>>
>> sorry, this is still broken on the 16x9 panel.
>>
>> 'intel_dp_link_required' is 107840*18/8 = 242640, 'intel_dp_max_data_rate' is
>> 27*1*8/10 = 216000. So it will fail in both check.
>
> So this panel is definitely out of spec, according to the eDP table 3.2 and
> 3.3
>
> Are you sure this is the mode it actually advertises over EDID vs some
> crazy mode stored in VBT?
>
> According to the eDP spec it needs 2 lanes and 1.62.
>
> A cvt rb 1600x900 mode would fit okay
> cvt -r 1600 900
> # 1600x900 59.82 Hz (CVT 1.44M9-R) hsync: 55.40 kHz; pclk: 97.50 MHz
> Modeline "1600x900R" 97.50 1600 1648 1680 1760 900 903 908 926 +hsync
> -vsync
>
> Dave.
> ___
> 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] i915: Fix CRT hotplug regression in 2.6.35-rc1
On Sat, Jun 12, 2010 at 7:21 PM, Andy Lutomirski wrote:
> Commit 7a772c492fcfffae812ffca78a628e76fa57fe58 has two bugs which
> made the hotplug problems on my laptop worse instead of better.
>
> First, it did not, in fact, disable the CRT plug interrupt -- it
> disabled all the other hotplug interrupts. It seems rather doubtful
> that that bit of the patch fixed anything, so let's just remove it.
> (If you want to add it back, you probably meant ~CRT_HOTPLUG_INT_EN.)
>
> Second, on at least my GM45, setting CRT_HOTPLUG_ACTIVATION_PERIOD_64
> and CRT_HOTPLUG_VOLTAGE_COMPARE_50 (when they were previously unset)
> causes a hotplug interrupt about three seconds later. The old code
> never restored PORT_HOTPLUG_EN so this could only happen once, but
> they new code restores those registers. So just set those bits when
> we set up the interrupt in the first place.
ping? Intel guys? ajax? anyone?
We are clearly broken on GM45 at the moment.
Dave.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> The regression was introduced by the Extra CRT hotplug paranoia patch,
> and it makes 2.6.35-rc2+ as well as 2.6.34 with that patch
> cherry-picked essentially unusable on my X200s / GM45 machine. Even
> with this fix, there are still hotplug storm issues, but at least
> they're now no worse than they used to be.
>
> Please apply this or something similar to 2.6.35/
>
> drivers/gpu/drm/i915/i915_irq.c | 12 +++-
> drivers/gpu/drm/i915/i915_reg.h | 1 -
> drivers/gpu/drm/i915/intel_crt.c | 6 --
> 3 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 864acaa..2199c58 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1413,8 +1413,18 @@ int i915_driver_irq_postinstall(struct drm_device *dev)
> hotplug_en |= SDVOC_HOTPLUG_INT_EN;
> if (dev_priv->hotplug_supported_mask &
> SDVOB_HOTPLUG_INT_STATUS)
> hotplug_en |= SDVOB_HOTPLUG_INT_EN;
> - if (dev_priv->hotplug_supported_mask & CRT_HOTPLUG_INT_STATUS)
> + if (dev_priv->hotplug_supported_mask &
> CRT_HOTPLUG_INT_STATUS) {
> hotplug_en |= CRT_HOTPLUG_INT_EN;
> +
> + /* Programming the CRT detection parameters tends
> + to generate a spurious hotplug event about three
> + seconds later. So just do it once.
> + */
> + if (IS_G4X(dev))
> + hotplug_en |=
> CRT_HOTPLUG_ACTIVATION_PERIOD_64;
> + hotplug_en |= CRT_HOTPLUG_VOLTAGE_COMPARE_50;
> + }
> +
> /* Ignore TV since it's buggy */
>
> I915_WRITE(PORT_HOTPLUG_EN, hotplug_en);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d31355b..ad0e255 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1054,7 +1054,6 @@
> #define CRT_HOTPLUG_DETECT_DELAY_2G (1 << 4)
> #define CRT_HOTPLUG_DETECT_VOLTAGE_325MV (0 << 2)
> #define CRT_HOTPLUG_DETECT_VOLTAGE_475MV (1 << 2)
> -#define CRT_HOTPLUG_MASK (0x3fc) /* Bits 9-2 */
>
> #define PORT_HOTPLUG_STAT 0x61114
> #define HDMIB_HOTPLUG_INT_STATUS (1 << 29)
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index e700ca1..cbe1413 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -217,14 +217,8 @@ static bool intel_crt_detect_hotplug(struct
> drm_connector *connector)
> else
> tries = 1;
> hotplug_en = orig = I915_READ(PORT_HOTPLUG_EN);
> - hotplug_en &= CRT_HOTPLUG_MASK;
> hotplug_en |= CRT_HOTPLUG_FORCE_DETECT;
>
> - if (IS_G4X(dev))
> - hotplug_en |= CRT_HOTPLUG_ACTIVATION_PERIOD_64;
> -
> - hotplug_en |= CRT_HOTPLUG_VOLTAGE_COMPARE_50;
> -
> for (i = 0; i < tries ; i++) {
> unsigned long timeout;
> /* turn on the FORCE_DETECT */
> --
> 1.7.0.1
>
> ___
> 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] implement 'wait' instruction
'Wait' instruction allows EU to stop and wait notification
register state clear to continue the execution. And we can
clear the notifications through MMIO, so we can track EU
execution step by step.
I use below patch for implement 'wait' in mesa, and attach
'intel_eu_cont.c' program to kick EU to continue. This is
useful in debugging sandybridge for me.
From 34d96de16228013802ca577bb1007c5877ac5279 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang
Date: Fri, 25 Jun 2010 16:05:24 +0800
Subject: [PATCH] i965: Add 'wait' instruction support
When EU executes 'wait' instruction, it stalls and sets notification
register state. Host can issue MMIO write to clear notification
register state to allow EU continue on executing again.
Signed-off-by: Zhenyu Wang
---
src/mesa/drivers/dri/i965/brw_eu.h | 16
src/mesa/drivers/dri/i965/brw_eu_emit.c | 14 ++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h
b/src/mesa/drivers/dri/i965/brw_eu.h
index a6fcd83..3a01000 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -520,6 +520,20 @@ static INLINE struct brw_reg brw_acc_reg( void )
0);
}
+static INLINE struct brw_reg brw_notification_1_reg(void)
+{
+
+ return brw_reg(BRW_ARCHITECTURE_REGISTER_FILE,
+ BRW_ARF_NOTIFICATION_COUNT,
+ 1,
+ BRW_REGISTER_TYPE_UD,
+ BRW_VERTICAL_STRIDE_0,
+ BRW_WIDTH_1,
+ BRW_HORIZONTAL_STRIDE_0,
+ BRW_SWIZZLE_,
+ WRITEMASK_X);
+}
+
static INLINE struct brw_reg brw_flag_reg( void )
{
@@ -919,6 +933,8 @@ void brw_land_fwd_jump(struct brw_compile *p,
void brw_NOP(struct brw_compile *p);
+void brw_WAIT(struct brw_compile *p);
+
/* Special case: there is never a destination, execution size will be
* taken from src0:
*/
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 34dfe10..10e9ebc 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -906,6 +906,20 @@ void brw_CMP(struct brw_compile *p,
}
}
+/* Issue 'wait' instruction for n1, host could program MMIO
+ to wake up thread. */
+void brw_WAIT (struct brw_compile *p)
+{
+ struct brw_instruction *insn = next_insn(p, BRW_OPCODE_WAIT);
+ struct brw_reg src = brw_notification_1_reg();
+
+ brw_set_dest(insn, src);
+ brw_set_src0(insn, src);
+ brw_set_src1(insn, brw_null_reg());
+ insn->header.execution_size = 0; /* must */
+ insn->header.predicate_control = 0;
+ insn->header.compression_control = 0;
+}
/***
--
1.7.0.4
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
/*
* Copyright © 2009 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*
* Authors:
*Zhenyu Wang
*
*/
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include "intel_gpu_tools.h"
static uint32_t devid;
#define EU_ATT_CLR 0x7830
#define EU_ATT_CLR_2 0x7834
int main(int argc, char **argv)
{
struct pci_device *pci_dev;
pci_dev = intel_get_pci_device();
devid = pci_dev->device_id; /* XXX not true when mapping! */
intel_get_mmio(pci_dev);
printf("Clear EU wait attention.\n");
OUTREG(EU_ATT_CLR, 0x);
OUTREG(EU_ATT_CLR_2, 0x);
OUTREG(EU_ATT_CLR, 0);
OUTREG(EU_ATT_CLR_2, 0);
return 0;
}
signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
