On Mon, Jan 16, 2012 at 21:28, Daniel Vetter wrote:
> On Sun, Jan 08, 2012 at 03:01:12AM +0100, Cyril Brulebois wrote:
>> Eugeni Dodonov (07/01/2012):
>> > This is also handled by i915_reg.h, so just reuse this trick to reduce
>> > universe enthropy.
>>
>> entropy.
>>
>> Besides that:
>>
>> Revie
On Mon, Jan 16, 2012 at 11:01:13PM +, Chris Wilson wrote:
> Staring at an error state such as:
>
> PGTBL_ER: 0x0400
> Display B: Invalid tiling
> fence[0] = 05001001
> valid, x-tiled, pitch: 512, start: 0x0500, size: 1048576
> Pinned [2]:
> 131072 0001 0001 000
On Mon, Jan 16, 2012 at 02:20:55PM -0800, Ben Widawsky wrote:
> On 01/16/2012 01:50 PM, Daniel Vetter wrote:
> > On Tue, Dec 13, 2011 at 10:36:15AM -0800, Ben Widawsky wrote:
> >> On 12/13/2011 09:22 AM, Eric Anholt wrote:
> >>> On Mon, 12 Dec 2011 19:52:08 -0800, Ben Widawsky
> >>> wrote:
>
On Tue, Jan 17, 2012 at 07:08:09AM +0800, Wu Fengguang wrote:
> On Mon, Jan 16, 2012 at 12:44:43PM -0800, Keith Packard wrote:
> > On Mon, 16 Jan 2012 21:26:18 +0100, Daniel Vetter wrote:
> >
> > > Keith, does this address your concern and this patch is r-b: Keith or do
> > > we want an
> > >
>
On Tue, Nov 15, 2011 at 07:47:58PM +0100, Takashi Iwai wrote:
> At Fri, 11 Nov 2011 14:12:58 -0800,
> Simon Que wrote:
> >
> > If the firmware did not initialize the backlight PWM registers, set up a
> > default PWM frequency of 200 Hz. This is determined using the following
> > formula:
> >
> >
On Thu, Nov 10, 2011 at 05:50:26PM -0800, Simon Que wrote:
> There is an error in i915_read_blc_pwm_ctl, where the register values
> are not being copied correctly. BLC_PWM_CTL and BLC_PWM_CTL2 are
> getting mixed up. This patch fixes that so that saveBLC_PWM_CTL2 and
> not saveBLC_PWM_CTL is cop
On Wed, Nov 09, 2011 at 12:17:06PM -0800, Eric Anholt wrote:
> On Wed, 09 Nov 2011 19:15:06 +, Chris Wilson
> wrote:
> > On Wed, 09 Nov 2011 10:57:00 -0800, Eric Anholt wrote:
> > > On Wed, 9 Nov 2011 17:32:26 +, Chris Wilson
> > > wrote:
> > > > We are advised that in order to workar
On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote:
> Enabling FBC is causing the BLT ring to run between 10-100x slower than
> normal and frequently lockup. The interim solution is disable FBC once
> more until we know why.
>
> Signed-off-by: Chris Wilson
Iirc fbc isn't really worth i
On Tue, Jan 17, 2012 at 10:45 AM, Keith Whitwell wrote:
>
> On Mon, 2012-01-16 at 21:56 +0100, Daniel Vetter wrote:
>> On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote:
>> > Some decent history digging indicates that this was to be used for the
>> > GLX_MESA_allocate_memory extension
On Tue, Nov 08, 2011 at 11:13:12PM +, Chris Wilson wrote:
> Rather than relying on the hardware to do this correctly, we can
> trivially do it ourselves.
>
> This fixes a very reliable crash on d-i-n with all bits enabled during a
> cairo-trace replay. The symptoms of the crash is that we cont
On Fri, Nov 04, 2011 at 05:03:54PM -0700, Ben Widawsky wrote:
> The GTFIFODBG register gives us 3 error types when the fifo is accessed
> and full. Whenever we do a forcewake_put we can check this register to
> see if any of the CPU related errors occurred.
>
> Of more interest is perhaps the bit
On Tue, 17 Jan 2012 11:59:27 +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2011 at 11:13:12PM +, Chris Wilson wrote:
> > Rather than relying on the hardware to do this correctly, we can
> > trivially do it ourselves.
> >
> > This fixes a very reliable crash on d-i-n with all bits enabled duri
On Thu, Nov 03, 2011 at 03:23:39PM -0700, Ben Widawsky wrote:
> On Thu, 3 Nov 2011 20:19:23 +
> Dave Airlie wrote:
>
> > >> >
> > >> > The solution here is to add a new flag to the call chain which gives
> > >> > the
> > >> > routines the information they need to possibly defer actions which
On Tue, 17 Jan 2012 11:57:05 +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote:
> > Enabling FBC is causing the BLT ring to run between 10-100x slower than
> > normal and frequently lockup. The interim solution is disable FBC once
> > more until we know why
On Thu, Oct 20, 2011 at 03:15:09PM -0200, Eugeni Dodonov wrote:
> This is mostly similar to Ironlake, with some register changes and
> additional tricks.
>
> Jesse mentioned that it would make more sense to move those bits into
> ivb-specific functions instead of making this work within ironlake o
On Tue, 17 Jan 2012 12:08:57 +0100, Daniel Vetter wrote:
> On Fri, Nov 04, 2011 at 05:03:54PM -0700, Ben Widawsky wrote:
> > The GTFIFODBG register gives us 3 error types when the fifo is accessed
> > and full. Whenever we do a forcewake_put we can check this register to
> > see if any of the CPU
Some decent history digging indicates that this was to be used for the
GLX_MESA_allocate_memory extension but never actually implemented for
any released i915 userspace code.
So just rip it out.
v2: Fixup the Makefile.
Acked-by: Dave Airlie
Cc: Keith Whitwell
Signed-Off-by: Daniel Vetter
---
On Fri, Oct 07, 2011 at 02:38:41PM -0400, Adam Jackson wrote:
> Just a few things spotted in a readthrough. The DPLL disable one might
> actually be a bugfix, who knows.
I've queued patches 1,2&5 for -next. 3 is already fixed and 4 won't be
true in the near future due to something I'm not yet all
On Tue, 17 Jan 2012 11:49:53 +0100, Daniel Vetter wrote:
> What's the status of this patch? If you resend can you clarify the
> bugzilla reference and also include a Bspec/PRM/whatever citation for
> this workaround?
We don't know what it works around, nor do we have any idea if it
affects any bu
On Tue, Jan 17, 2012 at 08:57, Daniel Vetter wrote:
> On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote:
> > Enabling FBC is causing the BLT ring to run between 10-100x slower than
> > normal and frequently lockup. The interim solution is disable FBC once
> > more until we know why.
>
On Tue, Jan 17, 2012 at 08:58, Dave Airlie wrote:
> On Tue, Jan 17, 2012 at 10:45 AM, Keith Whitwell
> wrote:
> >
> > On Mon, 2012-01-16 at 21:56 +0100, Daniel Vetter wrote:
> >> On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote:
> >> > Some decent history digging indicates that this
On Tue, Jan 17, 2012 at 12:16, Chris Wilson wrote:
> On Tue, 17 Jan 2012 11:57:05 +0100, Daniel Vetter wrote:
>> On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote:
>> > Enabling FBC is causing the BLT ring to run between 10-100x slower than
>> > normal and frequently lockup. The interi
On Tue, 26 Jul 2011 15:39:44 -0400
Adam Jackson wrote:
> Matches the advice in the Sandybridge documentation.
>
> Signed-off-by: Adam Jackson
> ---
> drivers/gpu/drm/i915/intel_dp.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
On Tue, 26 Jul 2011 15:39:44 -0400
Adam Jackson wrote:
> Matches the advice in the Sandybridge documentation.
>
> Signed-off-by: Adam Jackson
> ---
> drivers/gpu/drm/i915/intel_dp.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
On Tue, Jan 17, 2012 at 07:19:35AM -0800, Jesse Barnes wrote:
> On Tue, 26 Jul 2011 15:39:44 -0400
> Adam Jackson wrote:
>
> > Matches the advice in the Sandybridge documentation.
> >
> > Signed-off-by: Adam Jackson
> > ---
> > drivers/gpu/drm/i915/intel_dp.c |2 +-
> > 1 files changed, 1
On Tue, Jul 12, 2011 at 03:42:11PM -0700, Keith Packard wrote:
> On Tue, 12 Jul 2011 17:37:59 -0400, Adam Jackson wrote:
> > Signed-off-by: Adam Jackson
>
> > +# define DP_DWN_STRM_PORT_TYPE_TMDS(2 << 1)
>
> This could be labeled TYPE_DVI_OR_HDMI according to the DP 1.1a spec.
>
>
On Fri, Jul 08, 2011 at 08:43:47PM +0100, Chris Wilson wrote:
> Oh dear, it was all looking too good. Works fine with just one output.
> Runs into a nasty race if you add a second and start unplugging things...
>
> The issue is that when unplugging an output, userspace sees this and
> appropriatel
LLC is not SNB/IVB-specific, so we should check for it in a more generic
way.
Reviewed-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_debugfs.c |1 +
drivers/gpu/drm/i915/i915_dma.c |3 +++
drivers/gpu/drm/i915/i915_drv.c
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
Signed-off-by: Eugeni Dodonov
---
include/drm/i915_drm.h |1 +
intel/intel_bufmgr_gem.c | 12
2 files changed, 13 inserti
On Tue, 17 Jan 2012 17:18:17 +0100, Daniel Vetter wrote:
> I've just noticed that we seem to miss this plug to fix fbc issues. Care
> to resend a proper patch in case we still need this?
>
> Also, I we could try to also disable fbc when we detect frontbuffer
> rendering (and generally abolish set
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
Signed-off-by: Eugeni Dodonov
---
include/drm/i915_drm.h |1 +
intel/intel_bufmgr_gem.c | 12
2 files changed, 13 inserti
On Tue, Jan 17, 2012 at 14:44, Eugeni Dodonov wrote:
> This adds support for querying the kernel about the LLC support in the
> hardware.
>
> In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
>
> Signed-off-by: Eugeni Dodonov
>
Please ignore this and consider the next one
On Tue, 17 Jan 2012 12:22:44 +0100
Daniel Vetter wrote:
> On Thu, Oct 20, 2011 at 03:15:09PM -0200, Eugeni Dodonov wrote:
> > This is mostly similar to Ironlake, with some register changes and
> > additional tricks.
> >
> > Jesse mentioned that it would make more sense to move those bits into
>
Otherwise, we are left with pretty bogus message saying that the pixel
format is not supported while leaving the details to the telepatic powers.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/driv
On Tue, Jan 17, 2012 at 03:11:11PM -0200, Eugeni Dodonov wrote:
> Otherwise, we are left with pretty bogus message saying that the pixel
> format is not supported while leaving the details to the telepatic powers.
>
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/i915/intel_display.c |
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
v2: fix the return code checking
Signed-off-by: Eugeni Dodonov
---
include/drm/i915_drm.h |1 +
intel/intel_bufmgr_gem.c | 12 +++
Otherwise, we are left with pretty bogus message saying that the pixel
format is not supported while leaving the details to the telepatic powers.
v2: use DRM_DEBUG_KMS instead of DRM_ERROR
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 files changed, 2 inse
On Tue, 17 Jan 2012 14:58:21 -0200, Eugeni Dodonov
wrote:
> This adds support for querying the kernel about the LLC support in the
> hardware.
>
> In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
This patch should probably come along with a consumer of the flag.
pgpzbrb
On Tue, 17 Jan 2012 14:43:53 -0200, Eugeni Dodonov
wrote:
> LLC is not SNB/IVB-specific, so we should check for it in a more generic
> way.
>
> Reviewed-by: Chris Wilson
> Reviewed-by: Daniel Vetter
> Signed-off-by: Eugeni Dodonov
Reviewed-by: Eric Anholt
pgpRyk23Qn3FJ.pgp
Description: PG
On Tue, 17 Jan 2012 12:50:12 +0100, Daniel Vetter
wrote:
> Some decent history digging indicates that this was to be used for the
> GLX_MESA_allocate_memory extension but never actually implemented for
> any released i915 userspace code.
>
> So just rip it out.
>
> v2: Fixup the Makefile.
Revi
On Tue, 17 Jan 2012 11:15:31 +0100, Daniel Vetter wrote:
> On Mon, Jan 16, 2012 at 02:20:55PM -0800, Ben Widawsky wrote:
> > On 01/16/2012 01:50 PM, Daniel Vetter wrote:
> > > On Tue, Dec 13, 2011 at 10:36:15AM -0800, Ben Widawsky wrote:
> > >> On 12/13/2011 09:22 AM, Eric Anholt wrote:
> > >>> On
On Tue, Jan 17, 2012 at 09:35:48AM -0800, Eric Anholt wrote:
> On Tue, 17 Jan 2012 12:50:12 +0100, Daniel Vetter
> wrote:
> > Some decent history digging indicates that this was to be used for the
> > GLX_MESA_allocate_memory extension but never actually implemented for
> > any released i915 user
Instead of checking for CPU generation, use the libdrm-provided
I915_PARAM_HAS_LLC instead.
Signed-off-by: Eugeni Dodonov
---
src/sna/kgem.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 970e462..96c5ddd 100644
--- a/src/sna/kge
This is requried for I915_PARAM_HAS_LLC support.
Signed-off-by: Eugeni Dodonov
---
configure.ac |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 63beb64..604ea6d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,6 +132,7 @@ required_pi
On 01/17/2012 08:43 AM, Eugeni Dodonov wrote:
LLC is not SNB/IVB-specific, so we should check for it in a more generic
way.
Reviewed-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Eugeni Dodonov
Reviewed-by: Kenneth Graunke
___
Intel-gf
Instead of checking for CPU generation, use the libdrm-provided
I915_PARAM_HAS_LLC instead.
v2: use a define check to verify if we have I915_PARAM_HAS_LLC.
Signed-off-by: Eugeni Dodonov
---
src/sna/kgem.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/s
On Tue, Jan 17, 2012 at 04:16:37PM -0200, Eugeni Dodonov wrote:
> Instead of checking for CPU generation, use the libdrm-provided
> I915_PARAM_HAS_LLC instead.
>
> v2: use a define check to verify if we have I915_PARAM_HAS_LLC.
>
> Signed-off-by: Eugeni Dodonov
> ---
> src/sna/kgem.c | 12 +++
Hi Paulo,
sorry for not getting back you sooner... your email was here on my "to do list"
Could you please report this issue on bugs.freedesktop.org attaching
this xrandr verbose info and also dmesg xorg log and confs?
Also, Is it possible to test it without the AV receiver? I think you
wont see
On Tue, 17 Jan 2012 16:16:37 -0200, Eugeni Dodonov
wrote:
> Instead of checking for CPU generation, use the libdrm-provided
> I915_PARAM_HAS_LLC instead.
>
> v2: use a define check to verify if we have I915_PARAM_HAS_LLC.
>
> Signed-off-by: Eugeni Dodonov
I attacked it slightly so that gem_pa
On Tue, Jan 17, 2012 at 02:43:53PM -0200, Eugeni Dodonov wrote:
> LLC is not SNB/IVB-specific, so we should check for it in a more generic
> way.
>
> Reviewed-by: Chris Wilson
> Reviewed-by: Daniel Vetter
> Signed-off-by: Eugeni Dodonov
Queued for -next, thanks for the patch.
-Daniel
--
Daniel
On Tue, Jan 17, 2012 at 18:14, Alfonso Fiore wrote:
>
> Hi Angela,
>
> I have a very similar problem!
>
> I have Sandy Bridge (i3 2130) and a Philips 32pf9731d (coincidence?). With
> my previous i3 550 I didn't have any problem.
>
> I tried all possible resolutions over HDMI and all the time the s
On Tue, Jan 17, 2012 at 9:25 PM, Eugeni Dodonov wrote:
> On Tue, Jan 17, 2012 at 18:14, Alfonso Fiore wrote:
>
>>
>> Hi Angela,
>>
>> I have a very similar problem!
>>
>> I have Sandy Bridge (i3 2130) and a Philips 32pf9731d (coincidence?).
>> With my previous i3 550 I didn't have any problem.
>>
On Tue, Jan 17, 2012 at 09:59:18PM +0100, Alfonso Fiore wrote:
> Hi,
>
> here is mine. Let me know if you need any other log.
Ok, your TV only reports 1080i as a mode (at least that's the only thing
your kernel can decode). The i915 driver then rejects it because it's
interlaced (we unfortunately
On Tue, Jan 17, 2012 at 10:32:33PM +0100, Angela Schmid wrote:
> Hello
>
> Thanks for helping. I added the dmesg with drm.debug=0x0e below.
> I tried last month with get-edid in DOS, with the same unhappy result, see
> below for actual linux.
>
> >Could you try with the following two patches whi
> Ok, your TV only reports 1080i as a mode (at least that's the only
thing your kernel can decode).
true, it's non a Full HD TV.
> we unfortunately do not yet support interlaced everywhere we could
when do you think the support will be added? weeks? months?
> can you add a short list of the
Hello
Over HDMI works:
"1280x720@50hz" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
1280x720@50hz (0xb4) 74.2MHz +HSync +VSync *current
h: width 1280 start 1720 end 1760 total 1980 skew0 clock 37.5KHz
v: height 720 start 725 end 730 total 750
On Tue, Jan 17, 2012 at 11:53:47PM +0100, Angela Schmid wrote:
> Over HDMI works:
>
> "1280x720@50hz" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
>
> 1280x720@50hz (0xb4) 74.2MHz +HSync +VSync *current
>
> h: width 1280 start 1720 end 1760 total 1980 skew0 clock
On Wed, Jan 18, 2012 at 01:16:02AM +0100, CC wrote:
> On Mon, Jan 16, 2012 at 5:36 PM, Daniel Vetter wrote:
>
> > On Mon, Jan 16, 2012 at 05:18:17PM +0100, CC wrote:
> > > Hi,
> > >
> > > I've heard that you need users having the RC6 bug.
> > >
> > > I have the following setup:
> > > CPU: Intel C
On Thu, Jan 05, 2012 at 11:11:53PM +0100, Daniel Vetter wrote:
> With the new ducttape of much finer quality, this seems to be no
> longer necessary.
>
> Tested on my ivb and snb machine with the usual suspects of testcases.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq
Does what it says on the box.
Signed-off-by: Daniel Stone
---
configure.ac | 14 ++
src/legacy/i810/Makefile.am |6 +-
src/legacy/i810/i810.h|4
src/legacy/i810/i810_dga.c|2 ++
src/legacy/i810/i810_driver.c | 10 +-
src
Hello Daniel
>Your TV likely sends a CEA block with some HDMI default modes set. Since
>linux-3.3-rc1 (to be released in a few days) we should be able to decode that.
>Can you grab the latest -linus kernel git and try that?
I wanted to remind, that the interlaced modes work with the noveau drive
61 matches
Mail list logo
