On Sun, 28 Oct 2012 09:48:35 +
Chris Wilson wrote:
> On Fri, 26 Oct 2012 14:58:45 -0700, Ben Widawsky wrote:
> > On Fri, 19 Oct 2012 18:03:09 +0100
> > Chris Wilson wrote:
> >
> > > A few of the earlier registers where enlarged and so the Base Data of
> > > Stolen Memory Register (BDSM) wa
On Fri, 19 Oct 2012 18:03:08 +0100
Chris Wilson wrote:
> It was not until the G33 refresh, that a PCI config register was
> introduced that explicitly said where the stolen memory was. Prior to
> 865G there was not even a register that said where the end of usable
> low memory was and where the s
From: Paulo Zanoni
This covers the "Disable FDI" section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 26 ++
drivers/gpu/drm/i915/intel_display.c | 3 +--
dri
From: Paulo Zanoni
This commit makes hsw_fdi_link_train responsible for implementing
everything described in the "Enable and train FDI" section from the
Hawell CRT mode set sequence documentation. We completely rewrite
hsw_fdi_link_train to match the documentation and we also call it in
the right
Am Donnerstag, den 01.11.2012, 16:42 + schrieb Damien Lespiau:
> From: Damien Lespiau
The content of the cover letter would have been very useful for this
commit message body. ;-)
> Signed-off-by: Damien Lespiau
[…]
Thanks,
Paul
signature.asc
Description: This is a digitally signed me
This is wrong Ignore it. I messed up rebasing it against the new patches.
2012/11/1 Paulo Zanoni :
> From: Paulo Zanoni
>
> This commit makes hsw_fdi_link_train responsible for implementing
> everything described in the "Enable and train FDI" section from the
> Hawell CRT mode set sequence do
On Thu, Nov 01, 2012 at 02:35:13PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/10/31 Daniel Vetter :
> > Now that we no longer pretend to have flexibility in matching any
> > north display block with any pch, we can ditch this.
> >
> > v2: Fix the embarassing rebase fail that Paulo Zanoni spotted.
>
On Wed, Oct 31, 2012 at 04:05:33PM -0400, Adam Jackson wrote:
> On 10/27/12 9:52 AM, Daniel Vetter wrote:
> >This essentially reverts
> >
> >commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> >Author: Adam Jackson
> >Date: Fri Jul 16 14:46:29 2010 -0400
> >
> > drm/i915: Initialize LVDS and e
On Wed, Oct 31, 2012 at 06:12:55PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> On Haswell/LPT we must disable the PCH transcoder before we disable
> the FDI, so don't check for disabled FDI there.
>
> Signed-off-by: Paulo Zanoni
Ok, I've slurped in the last few patches here, safe for p
From: Paulo Zanoni
... instead of PIPECONF_INTERLACE_MASK.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 276a1c4..9b29
From: Paulo Zanoni
This covers the "Disable FDI" section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 26 ++
drivers/gpu/drm/i915/intel_display.c | 3 +--
dri
From: Paulo Zanoni
This commit makes hsw_fdi_link_train responsible for implementing
everything described in the "Enable and train FDI" section from the
Hawell CRT mode set sequence documentation. We completely rewrite
hsw_fdi_link_train to match the documentation and we also call it in
the right
From: Paulo Zanoni
We had 2 places using X2 and one place using X1.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 67bd6ba..a7a55
On Thu, Nov 01, 2012 at 07:26:45PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
Queued for -next, thanks for the patch. And don't ask me why it didn't
work last time around ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporat
On Thu, Nov 01, 2012 at 02:53:40PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/11/1 Daniel Vetter :
> > On Wed, Oct 31, 2012 at 06:12:48PM -0200, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> ... instead of PIPECONF_INTERLACE_MASK.
> >>
> >> Signed-off-by: Paulo Zanoni
> >
> > My Bspec here
From: Ville Syrjälä
intel_pipe_set_base() never actually waited for any pending page flips
on the CRTC. It looks like it tried to, by calling intel_finish_fb() on
the current front buffer. But the pending flips were actually tracked
in the BO of the previous front buffer, so the call to intel_fin
From: Ville Syrjälä
As per Chris Wilson's suggestion make
i915_gem_execbuffer_wait_for_flips() go away.
This was used to stall the GPU ring while there are pending
page flips involving the relevant BO. Ie. while the BO is still
being scanned out by the display controller.
The recommended altern
From: Ville Syrjälä
i915_gem_execbuffer_wait_for_flips() only works on some old hardware,
and it's not required by sane user space code. So assume that any
insane user space is limited to <= gen5, and just skip
i915_gem_execbuffer_wait_for_flips() for anything more recent.
Also eliminate the ext
From: Ville Syrjälä
Anyone stuck waiting for pending flips should get woken up when the GPU
hangs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i9
Another attempt at getting rid of i915_gem_execbuffer_wait_for_flips().
There's two versions of the patch:
3a just skips the function on SNB+
3b kills it completely
I'll let someone else make the decision which way to go.
Just dropping it looks reasonably safe to me. xf86-video-intel never see
On Thu, Nov 1, 2012 at 4:56 PM, Eric Anholt wrote:
> Damien Lespiau writes:
>
>> The goal here is to make dmesg output with the full verbosity a bit easier to
>> parse by a human. The script will transform:
>
> Couldn't a little bit of preprocessor in the kernel ioctl definitions
> give us decent
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
v2: Rebased on top of drm-intel-next-queued
drivers/gpu/drm/i915/i915_reg.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d4520d5..fc3bf
It's pretty much all consolidated now that we've killed AGP. We can move
the one outlier, and defines too.
(Kill some unused defines in the process)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 62 --
drivers/gpu/drm/i915/i915_gem_gtt.c | 76
This allows us to map the PTEs WC. I've not done thorough testing or
performance measurements with this patch, but it should be decent.
This is based on a patch from Jesse with the original commit message
> I've only lightly tested this so far, but the corruption seems to be
> gone if I write the
Signed-off-by: Ben Widawsky
Reviewed-by: Jesse Barnes
---
drivers/char/agp/intel-agp.h | 91 -
drivers/char/agp/intel-gtt.c | 307 +--
include/drm/intel-gtt.h | 4 -
3 files changed, 3 insertions(+), 399 deletions(-)
diff --git a/drive
This bug existed in the old code, but was easier to fix here in the
rework. Unfortunately gen7 doesn't have a nice way to figure out the
size and we must use a lookup table.
As Jesse pointed out, there is some confusion in the docs about these
definitions. We're picking the one which seems more ac
As a quick hack we make the old intel_gtt structure mutable so we can
fool a bunch of the existing code which depends on elements in that data
structure. We can/should try to remove this in a subsequent patch.
This should preserve the old gtt init behavior which upon writing these
patches seems in
On Thu, 01 Nov 2012 16:52:05 +
Tvrtko Ursulin wrote:
> On Thursday 01 November 2012 16:20:03 Chris Wilson wrote:
> > On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes
> wrote:
> > > On Thu, 01 Nov 2012 15:52:23 +
> > >
> > > Chris Wilson wrote:
> > > > Actually I've justified the blocki
Damien Lespiau writes:
> The goal here is to make dmesg output with the full verbosity a bit easier to
> parse by a human. The script will transform:
Couldn't a little bit of preprocessor in the kernel ioctl definitions
give us decent names right in the dmesg?
pgpKO3MXBo1nr.pgp
Description: PG
Hi
2012/11/1 Daniel Vetter :
> On Wed, Oct 31, 2012 at 06:12:48PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> ... instead of PIPECONF_INTERLACE_MASK.
>>
>> Signed-off-by: Paulo Zanoni
>
> My Bspec here still has bits 23:21 for the interlaced bits on the lpt pch,
> but everything with
Hi
2012/11/1 Daniel Vetter :
> On Wed, Oct 31, 2012 at 06:12:26PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using
>> "pipe" here is wrong.
>>
>> While at it, also reuse the rx_ctl_val variable created in the
>> previous c
From: Damien Lespiau
Signed-off-by: Damien Lespiau
---
scripts/Makefile.am | 2 +-
scripts/dmesg_filter | 195 +++
2 files changed, 196 insertions(+), 1 deletion(-)
create mode 100755 scripts/dmesg_filter
diff --git a/scripts/Makefile.am b/sc
The goal here is to make dmesg output with the full verbosity a bit easier to
parse by a human. The script will transform:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010646
Hi
2012/10/31 Daniel Vetter :
> Now that we no longer pretend to have flexibility in matching any
> north display block with any pch, we can ditch this.
>
> v2: Fix the embarassing rebase fail that Paulo Zanoni spotted.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Paulo Zanoni
> ---
> driver
On Thu, Nov 1, 2012 at 4:52 PM, Paulo Zanoni wrote:
> The only problem is: we're not doing anything here for the
> HAS_PCH_SPLIT platforms. Shouldn't we be doing something? We do have
> eDP code to set the PCH_PP registers, but not LVDS code for this.
> Also, each encoder probably needs different
On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes
wrote:
> On Thu, 01 Nov 2012 15:52:23 +
> Chris Wilson wrote:
>
> > Actually I've justified the blocking here to myself, and prefer it to
> > simply running the crtc->unpin_work. If userspace is swamping the system
> > so badly that we can run
On Wed, Oct 31, 2012 at 06:12:50PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> That function is made for IBX. Running it on LPT will trigger tons of
> "unclaimed register" errors. The only port remaining on LPT is
> PCH_ADPA.
>
> Signed-off-by: Paulo Zanoni
Actually I've had to stay aro
Hi
2012/10/31 Daniel Vetter :
> Found in Bspec vol4h South Display Engine Registers [CPT, PPT],
> section "5.3.1 TRANS_CHICKEN_1—Transcoder Chicken Bits 1"
>
> v2: Make it compile.
>
> Reviewed-by: Paulo Zanoni (v1)
R-B still applies... When I'm reviewing your patches I usually assume
they comp
On Wed, Oct 31, 2012 at 06:12:48PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> ... instead of PIPECONF_INTERLACE_MASK.
>
> Signed-off-by: Paulo Zanoni
My Bspec here still has bits 23:21 for the interlaced bits on the lpt pch,
but everything with bit 23 set is a reserved value. Sinc we
Hi
2012/11/1 Daniel Vetter :
> We need to set the timing override chicken bit after fdi link training
> has completed and before we enable the dp transcoder. We also have to
> clear that bit again after disabling the pch dp transcoder.
>
> See "Graphics BSpec: vol4g North Display Engine Registers
On Wed, Oct 31, 2012 at 06:12:46PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> These asserts are specific to IBX/CPT/PPT. Inside the assert_pch_pll
> function we even "return" in case we detect LPT, but I prefer to just
> not call it. In the future we might rename to something like
> ibx_
On Thu, 01 Nov 2012 15:52:23 +
Chris Wilson wrote:
> On Thu, 1 Nov 2012 08:34:47 -0700, Jesse Barnes
> wrote:
> > On Thu, 1 Nov 2012 16:29:35 +0100
> > Daniel Vetter wrote:
> >
> > > On Thu, Nov 01, 2012 at 03:18:46PM +, Chris Wilson wrote:
> > > > On Thu, 1 Nov 2012 08:07:59 -0700, J
Hi
2012/10/31 Daniel Vetter :
> We don't really support fancy north display/pch combinations, so
> put a big yelling WARN_ON in there. It /should/ be impossible, but
> alas, the rumours don't stop (mostly due to really early silicon
> sometimes using older PCHs).
>
> v2: Fixup the logic fumble not
On Thu, 1 Nov 2012 08:34:47 -0700, Jesse Barnes
wrote:
> On Thu, 1 Nov 2012 16:29:35 +0100
> Daniel Vetter wrote:
>
> > On Thu, Nov 01, 2012 at 03:18:46PM +, Chris Wilson wrote:
> > > On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes
> > > wrote:
> > > > On Thu, 1 Nov 2012 09:26:26 +
>
Hi
2012/10/31 Damien Lespiau :
> From: Damien Lespiau
>
> ILK+ have this register on the PCH. This check was triggering unclaimed
> writes.
>
> Signed-off-by: Damien Lespiau
The patch looks correct, so:
Reviewed-by: Paulo Zanoni
The only problem is: we're not doing anything here for the
HAS_P
On Wed, Oct 31, 2012 at 06:12:38PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because this function is only for the older PCHs, not the newer ones.
>
> Signed-off-by: Paulo Zanoni
Ok, I've merged patches 1-6 plus this one here for now. gtg, will resume
reviewing afterwards.
Thanks a
On Thu, 1 Nov 2012 16:33:45 +0100
Daniel Vetter wrote:
> On Thu, Nov 01, 2012 at 07:37:36AM -0700, Jesse Barnes wrote:
> > > v3: Paulo Zanoni pointed out that this workaround is also required on
> > > the LPT PCH. And Arthur Ranyan confirmed that this workaround is
> > > requierd for all ports on
On Thu, 1 Nov 2012 16:29:35 +0100
Daniel Vetter wrote:
> On Thu, Nov 01, 2012 at 03:18:46PM +, Chris Wilson wrote:
> > On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes
> > wrote:
> > > On Thu, 1 Nov 2012 09:26:26 +
> > > Chris Wilson wrote:
> > >
> > > > If we accumulate unpin tasks b
On Thu, Nov 01, 2012 at 07:37:36AM -0700, Jesse Barnes wrote:
> > v3: Paulo Zanoni pointed out that this workaround is also required on
> > the LPT PCH. And Arthur Ranyan confirmed that this workaround is
> > requierd for all ports on the pch, not just DP: The important part
> > is that the bit is
On Thu, Nov 01, 2012 at 03:18:46PM +, Chris Wilson wrote:
> On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes
> wrote:
> > On Thu, 1 Nov 2012 09:26:26 +
> > Chris Wilson wrote:
> >
> > > If we accumulate unpin tasks because we are pageflipping faster than the
> > > system can schedule it
On Wed, Oct 31, 2012 at 06:12:37PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This is done way earlier on HSW/LPT and is just wrong here.
>
> Signed-off-by: Paulo Zanoni
Ok, I'll probably regret it right away, but I think splitting the fdi link
training code up into that many patches
On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes
wrote:
> On Thu, 1 Nov 2012 09:26:26 +
> Chris Wilson wrote:
>
> > If we accumulate unpin tasks because we are pageflipping faster than the
> > system can schedule its workers, we can effectively create a
> > pin-leak. The solution taken here
On Wed, Oct 31, 2012 at 06:12:35PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> From the mode set sequence document: "Each setting should be tried at
> least twice before failing mode set".
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
> 1 file chang
On Wed, Oct 31, 2012 at 06:12:30PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> That's what our mode set sequence documentation says we need to do.
>
> Signed-off-by: Paulo Zanoni
As already bikeshedded on irc, I think the comment is a bit useless.
Instead of "program foo" I think "set
On Wed, Oct 31, 2012 at 06:12:29PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> According to the mode set sequence documentation, this is the right
> place. According to the FDI_RX_TUSIZE register description, this is
> the value we should set.
>
> Signed-off-by: Paulo Zanoni
> ---
> dr
On Wed, Oct 31, 2012 at 06:12:26PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using
> "pipe" here is wrong.
>
> While at it, also reuse the rx_ctl_val variable created in the
> previous commit.
>
> Signed-off-by: Paulo Zano
On Thu, 1 Nov 2012 09:26:26 +
Chris Wilson wrote:
> If we accumulate unpin tasks because we are pageflipping faster than the
> system can schedule its workers, we can effectively create a
> pin-leak. The solution taken here is to limit the number of unpin tasks
> we have per-crtc and to flus
On Wed, Oct 31, 2012 at 06:12:25PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Haswell FDI link training is very different from the previous
> generations.
>
> After this commit, hsw_fdi_link_train is responsible for implementing
> all the steps described as "Enable and train FDI" from t
On 11/01/12 16:50, Jesse Barnes wrote:
> No, it's in the gunit spec. I'm still working on getting that one
> opened up.
In that case, for the whole lot:
Reviewed-by: Antti Koskipää
--
- Antti
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop
On Thu, 01 Nov 2012 16:48:17 +0200
Antti Koskipää wrote:
> Hi,
>
> On 10/25/12 22:15, Jesse Barnes wrote:
> > This allows us to get the right vblank interrupt frequency.
> >
> > v2: pull in register definition
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i915_reg.h |
Hi,
On 10/25/12 22:15, Jesse Barnes wrote:
> This allows us to get the right vblank interrupt frequency.
>
> v2: pull in register definition
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_reg.h |2 ++
> drivers/gpu/drm/i915/intel_pm.c |7 +++
> 2 files changed, 9
On Thu, Nov 01, 2012 at 03:18:04PM +0100, Daniel Vetter wrote:
> On Thu, Nov 1, 2012 at 3:09 PM, Ville Syrjälä
> wrote:
> >> Userspace doesn't use this today at all even in the panning case?
> >
> > If it does, then the user is going to be upset when nothing happens.
> > Only the x/y offsets are e
On Thu, 1 Nov 2012 15:18:04 +0100
Daniel Vetter wrote:
> On Thu, Nov 1, 2012 at 3:09 PM, Ville Syrjälä
> wrote:
> >> Userspace doesn't use this today at all even in the panning case?
> >
> > If it does, then the user is going to be upset when nothing happens.
> > Only the x/y offsets are effecti
On Thu, 1 Nov 2012 09:15:30 +0100
Daniel Vetter wrote:
> We need to set the timing override chicken bit after fdi link training
> has completed and before we enable the dp transcoder. We also have to
> clear that bit again after disabling the pch dp transcoder.
>
> See "Graphics BSpec: vol4g No
On Thu, Nov 01, 2012 at 03:19:34PM +0100, Daniel Vetter wrote:
> On Thu, Nov 1, 2012 at 3:16 PM, Ville Syrjälä
> wrote:
> > On Wed, Oct 31, 2012 at 11:57:00PM +0100, Daniel Vetter wrote:
> >> On Wed, Oct 31, 2012 at 01:23:05PM -0700, Jesse Barnes wrote:
> >> > On Wed, 31 Oct 2012 17:50:15 +0200
>
On Thu, Nov 1, 2012 at 3:16 PM, Ville Syrjälä
wrote:
> On Wed, Oct 31, 2012 at 11:57:00PM +0100, Daniel Vetter wrote:
>> On Wed, Oct 31, 2012 at 01:23:05PM -0700, Jesse Barnes wrote:
>> > On Wed, 31 Oct 2012 17:50:15 +0200
>> > ville.syrj...@linux.intel.com wrote:
>> >
>> > > From: Ville Syrjälä
On Thu, Nov 1, 2012 at 3:09 PM, Ville Syrjälä
wrote:
>> Userspace doesn't use this today at all even in the panning case?
>
> If it does, then the user is going to be upset when nothing happens.
> Only the x/y offsets are effective with the current code.
>
>> I
>> know it worked at one point at le
On Wed, Oct 31, 2012 at 11:57:00PM +0100, Daniel Vetter wrote:
> On Wed, Oct 31, 2012 at 01:23:05PM -0700, Jesse Barnes wrote:
> > On Wed, 31 Oct 2012 17:50:15 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Signed-off-by: Ville Syrjälä
>
> Fails to app
On Wed, Oct 31, 2012 at 01:26:12PM -0700, Jesse Barnes wrote:
> On Wed, 31 Oct 2012 17:50:19 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > The current code can't deal with framebuffers with an offset. Return an
> > error when trying to create such a framebuffer u
On Thu, 1 Nov 2012 16:03:13 +0200, Ville Syrjälä
wrote:
> On Wed, Oct 31, 2012 at 01:20:23PM -0700, Jesse Barnes wrote:
> > On Wed, 31 Oct 2012 17:50:14 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Fix support for all RGB/BGR pixel formats (excep
On Wed, Oct 31, 2012 at 01:25:11PM -0700, Jesse Barnes wrote:
> On Wed, 31 Oct 2012 17:50:18 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Make sure the the framebuffer stride is smaller than 32k. That
> > seems to be the limit on recent hardware. Not quite sure
On Wed, Oct 31, 2012 at 01:20:23PM -0700, Jesse Barnes wrote:
> On Wed, 31 Oct 2012 17:50:14 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float
> > format).
> >
> > Fix intel_init_framebuffer() t
Summary
We finished a new round of kernel testing. Generally, in this circle, 1 new bug
is filed, 11 bugs are still opened,3 bugs are closed.
Test Environment
Kernel: (drm-intel-testing)b9960e75b5a348759c6e8c9ffb3f45e40ad702a5
Some additional commit info:
Merge: 8e740cd 1623392
Author: Dan
Hi Daniel,
Thanks for the patch.
On Wednesday 31 October 2012 10:11:50 Daniel Vetter wrote:
> I didn't bother with documenting the really trivial new "extract
> something from dpcd" helpers, but the i2c over aux ch is now
> documented a bit.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentati
Hi Daniel,
Thanks for the patch.
On Wednesday 31 October 2012 10:11:49 Daniel Vetter wrote:
> Again only minimal changes to make kerneldoc no longer shout. Plus a
> little introduction in the form of a inline DOC: section to quickly
> explain what this is all about.
>
> Signed-off-by: Daniel Vet
Hi Daniel,
Thanks for the patch.
(text reflowed for review purpose to fit the e-mail line length limit)
On Wednesday 31 October 2012 10:11:48 Daniel Vetter wrote:
> - Add the missing doc for drm_helper_move_panel_connectors_to_head.
> - Fixup any outdated stuff in existing sections. I've only lo
Hi Daniel,
Thanks for the patch.
On Wednesday 31 October 2012 10:11:47 Daniel Vetter wrote:
> I'm devoting all my wrath to that fight, so don't misname it ;-)
Right, my bad :-)
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Wed, 2012-10-31 at 23:46 +0100, Daniel Vetter wrote:
> On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote:
> > drm_vblank_off() requires callers to hold the event_lock.
> >
> > Signed-off-by: Imre Deak
>
> Hm, do we put this code through its paces already in flip_test by
> scheduling a
If we accumulate unpin tasks because we are pageflipping faster than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should
On Thu, 2012-11-01 at 00:03 +0200, Imre Deak wrote:
> drm_vblank_off() requires callers to hold the event_lock, while itself
> locking vbl_time and vblank_time_lock. This defines a dependency chain
> that conflicts with the one in drm_handle_vblank() where we first lock
> vblank_time_lock and then
Hi Dave,
Nothing big at all for -fixes, just small stuff:
- Two patches to fix bugs on i830M
- ums regression fixer due to kicking firmeware fbs (Chris)
- tune down a too loud warning (Jani)
- be more careful with sdvo infoframes, which fixes a long-standing
sdvo-hdmi regression
Cheers, Daniel
On Wed, 31 Oct 2012 17:18:47 -0700, Eric Anholt wrote:
> ville.syrj...@linux.intel.com writes:
>
> > From: Ville Syrjälä
> >
> > As per Chris Wilson's suggestion make
> > i915_gem_execbuffer_wait_for_flips() go away.
> >
> > This was used to stall the GPU ring while there are pending
> > page
We need to set the timing override chicken bit after fdi link training
has completed and before we enable the dp transcoder. We also have to
clear that bit again after disabling the pch dp transcoder.
See "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" and "
On Wed, Oct 31, 2012 at 10:46:36PM +, Chris Wilson wrote:
> On Wed, 31 Oct 2012 19:26:13 +0100, Daniel Vetter
> wrote:
> > Makes more sense to group the entire mode_set stage into one function.
> > Noticed while discussiing the rather confusing set of function names
> > with Paulo Zanoni. Unf
84 matches
Mail list logo
