On Thu, 22 Sep 2011 21:50:49 -0700
Keith Packard wrote:
> On Thu, 22 Sep 2011 17:11:52 -0700, Ben Widawsky
> wrote:
>
> > It requires an additional IOMMU patch.
>
> Can we collect those two patches into one sequence?
>
Yes. Although not sure who would do the pull request to Linus.
> > + i
On Fri, 23 Sep 2011 08:25:13 +0530, Jesse Barnes
wrote:
> Yeah that sounds good. (2) and (3) are ok cleanups, but it would be
> best if they were a separate patch just in case the subtle timing
> change breaks the panel power sequencing state machine.
Ok, I'll split things up into tiny patches
On Thu, 22 Sep 2011 17:11:52 -0700, Ben Widawsky wrote:
> It requires an additional IOMMU patch.
Can we collect those two patches into one sequence?
> + if ((gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB ||
> + gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG) &&
> + intel_
On Fri, 23 Sep 2011 08:13:15 +0530, Jesse Barnes
wrote:
> I think it depends on the platform. On some, enabling SSC may actually
> create more noise than not for some components (not that I've run the
> EMF calculations...).
So, why is the MBA EFI code enabling SSC while the VBT table says not
On Tue, 20 Sep 2011 21:51:33 -0700
Keith Packard wrote:
> Yes, making it cleaner would help a ton. There are some basic problems
> with the DRM API that make this hard though -- intel_dp_prepare may
> not ever be followed by a call to intel_dp_commit. That's why I had
> the VDD AUX stuff get turne
On Tue, 20 Sep 2011 21:45:54 -0700
Keith Packard wrote:
> On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
> wrote:
>
> > This one mixes up lots of cleanups plus the EDID read with the power
> > changes.
>
> I think the cleanups are;
>
> 1) edp checks inside vdd_on and vdd_off to make the ot
On Thu, 22 Sep 2011 12:55:22 -0700
Keith Packard wrote:
> On Thu, 22 Sep 2011 15:13:42 -0300, przan...@gmail.com wrote:
>
> > It seems to be missing from this commit:
> > "drm/i915: split out PCH refclk update code"
>
> Oh, this code is missing far more than that. It doesn't deal with the
> L
Under certain circumstances, an IOTLB flush never completes and the hardware
just locks up. The fix is meant to idle the GPU both before and after
any map or unmap occurs.
It requires an additional IOMMU patch.
Cc: Dave Airlie
Cc: David Woodhouse
Cc: Keith Packard
Signed-off-by: Ben Widawsky
From: Daniel Vetter
This adds a new mode to map gem objects in a non-blocking way.
The new kernel interface required to get the caching level/coherency
is not yet wired up. All the code to transparently choose between gtt
mappings or (if coherent) cpu mappings is already in place, though.
To ma
Cc: Daniel Vetter
Cc: "Kilarski, Bernard R"
Signed-off-by: Ben Widawsky
---
tests/Makefile.am |1 +
tests/gem_wo_map.c | 237
tests/test.sh | 16
3 files changed, 254 insertions(+), 0 deletions(-)
create mode 100644 tests/g
This makes the code a lot cleaner, and theoretically faster (not many
real world tests use this GL extension).
Cc: Eric Anholt
Cc: Daniel Vetter
Cc: Mesa Devs
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 48 ++--
1 files changed, 5 inse
From: Daniel Vetter
This adds a new mode to map gem objects in a non-blocking way.
The new kernel interface required to get the caching level/coherency
is not yet wired up. All the code to transparently choose between gtt
mappings or (if coherent) cpu mappings is already in place, though.
To ma
Querying a BO's cache level can help clients wishing to map the buffer.
For example, an Ironlake machine could query the buffer to determine it
should use GTT mappings, while a Sandybridge machine running the same
code would prefer to use regular CPU mapped buffers since the cache is
coherent.
Cc:
After going back and forth many times, I think Daniel and I have agreed
on the solution for non-blocking maps.
This new interface adds a new call to map buffers non-blocking if
possible. In actuality it may block, but it will track if the buffer
needs flushing or not and does the right thing for t
Hi Knut,
The issue has been a bug in libdrm. Can you please update that and retest?
Thanks, Daniel
On Sat, Sep 17, 2011 at 16:09, Knut Petersen wrote:
> Am 17.09.2011 14:31, schrieb Daniel Vetter:
>>
>> Yeah, the i915g drivers has probably a few memory corruption issues left.
>> Can you recompi
On Thu, 22 Sep 2011 15:13:42 -0300, przan...@gmail.com wrote:
> It seems to be missing from this commit:
> "drm/i915: split out PCH refclk update code"
Oh, this code is missing far more than that. It doesn't deal with the
LVDS case at all.
Here's a patch which turns on the right bits of SSC, i
On Thu, 2011-09-22 at 11:24 -0700, Keith Packard wrote:
> On Thu, 22 Sep 2011 10:00:14 -0400, Adam Jackson wrote:
>
> > This code is still present in Linus' tree, and still crap. Any
> > reviewers for this series?
>
> It all looks reasonable to me, and Chris reviewed or ack'd every patch
> but
On Thu, 22 Sep 2011 10:00:14 -0400, Adam Jackson wrote:
> This code is still present in Linus' tree, and still crap. Any
> reviewers for this series?
It all looks reasonable to me, and Chris reviewed or ack'd every patch
but #4, which looks reasonable on the surface to me.
Are you thinking thi
From: Paulo Zanoni
It seems to be missing from this commit:
"drm/i915: split out PCH refclk update code"
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drive
On Thu, 22 Sep 2011 15:36:51 +, Ben Widawsky wrote:
> On Thu, Sep 22, 2011 at 09:35:12AM +0200, Daniel Vetter wrote:
> > On Wed, Sep 21, 2011 at 06:47:10PM -0700, Ben Widawsky wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index a546a71
On Thu, Sep 22, 2011 at 09:35:12AM +0200, Daniel Vetter wrote:
> On Wed, Sep 21, 2011 at 06:47:10PM -0700, Ben Widawsky wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index a546a71..362da16 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++
On Thu, 22 Sep 2011 09:42:38 +0100
Chris Wilson wrote:
> On Thu, 22 Sep 2011 11:15:57 +0530, Jesse Barnes
> wrote:
> > These aren't actually needed for correct functionality and can
> > speed up boot and resume a bit.
>
> We've been paranoid for years here. Even after I removed them they've
> r
On Thu, 22 Sep 2011 09:41:01 +0100
Chris Wilson wrote:
> On Thu, 22 Sep 2011 11:15:58 +0530, Jesse Barnes
> wrote:
> > Read link status first, followed by the full DPCD receiver cap field
> > rather than just the first 8 bytes.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i
On Thu, 22 Sep 2011 10:36:12 +0200, Rainer Dorsch wrote:
> This kind of output I do not see in the syslog anymore during regular
> operation now (is that the 10-second polling?):
Yes. So, the patch is definitely included.
> > Let me know if it actually helps your suspend/resume issues.
>
> So
On Thu, 2011-06-16 at 16:36 -0400, Adam Jackson wrote:
> I have no evidence for this byte being used this way, and lots of
> counterexamples. Restore the struct to its empirical definition and
> patch up gmbus setup to match.
>
> Signed-off-by: Adam Jackson
This code is still present in Linus'
On Thu, 22 Sep 2011 11:15:57 +0530, Jesse Barnes
wrote:
> These aren't actually needed for correct functionality and can speed up
> boot and resume a bit.
We've been paranoid for years here. Even after I removed them they've
returned.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i9
On Thu, 22 Sep 2011 11:15:58 +0530, Jesse Barnes
wrote:
> Read link status first, followed by the full DPCD receiver cap field
> rather than just the first 8 bytes.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_irq.c |2 ++
> drivers/gpu/drm/i915/intel_dp.c |4 ++--
Am Wednesday, 21. September 2011 schrieb Keith Packard:
> On Wed, 21 Sep 2011 18:15:27 +0200, Rainer Dorsch wrote:
> > Since I can ssh into the machine, when the problem occurs, are there some
> > diagnosis scripts/tools I could run?
>
> Hrm. As far as I can tell, we're turning on the monitor suc
Somehow I screwed things up. Probably I miss something obvious, but what is it?
Xorg sources: the current git sources.
After failing I executed "make clean", "make realclean", "git reset --hard" and
rebuilt everything twice
using the following commands:
export PREFIX=/usr
export PKG_CONFIG_PAT
On Wed, Sep 21, 2011 at 06:47:11PM -0700, Ben Widawsky wrote:
> Daniel Vetter
> Signed-off-by: Ben Widawsky
> ---
> include/drm/i915_drm.h |7 +++
> intel/intel_bufmgr_gem.c | 36 ++--
> 2 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git
On Wed, Sep 21, 2011 at 06:47:10PM -0700, Ben Widawsky wrote:
>
> Cc: Daniel Vetter
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_dma.c |1 +
> drivers/gpu/drm/i915/i915_drv.h |2 ++
> drivers/gpu/drm/i915/i915_gem.c | 23 +++
> include/drm/i915_d
On Wed, Sep 21, 2011 at 06:47:09PM -0700, Ben Widawsky wrote:
> Overall, I like this series much better. Do we want to sneak in a set
> cache level with the same IOCTL while we're at it?
I think the set_cache_level can wait a tad bit, and this stuff here looks
(almost) ready. A few nitpicks remain
32 matches
Mail list logo
