Hi,
I am using a CentOS 6.2 64-bit Operating system. I have DH67CL
Intel motherboard and i52500k 3.3Ghz Processor (Sandy Bridge).
I am new to the linux environment. I have download the driver from
your website which is xf86-video-intel-2.18.0.tar.gz and tried to install
it
On Fri, 23 Mar 2012 10:51:03 +0100
Daniel Vetter wrote:
> On Thu, Mar 22, 2012 at 08:29:30PM -0700, Ben Widawsky wrote:
> > On Thu, Mar 22, 2012 at 02:38:46PM -0700, Jesse Barnes wrote:
> > > Add support for ValleyView watermark handling. It's like Cantiga
> > > with a few small differences (big
Originally the code tried to allocate a large enough array to perform
the copy using vmalloc, performance wasn't great and throughput was
improved by processing each individual relocation entry separately.
This too is not as efficient as one would desire. A compromise is then
to allocate a single p
On Thu, Mar 22, 2012 at 02:38:52PM -0700, Jesse Barnes wrote:
> Just to make things clearer and reduce the size of this monstrosity.
>
> Signed-off-by: Jesse Barnes
In-depth review ftw. This time the code looks good, but the call the the
new funtion looks a bit misplaced. See below.
-Daniel
> -
On Fri, 23 Mar 2012 23:43:36 +0100, Daniel Vetter
wrote:
> Again, Valleyview modes these around, so make the mmio base more
> explicit to consolidate the base address computations to one
> HAS_PCH_SPLIT check.
>
> Signed-Off-by: Daniel Vetter
Consolidating the offset computation is nice. Every
On Thu, Mar 22, 2012 at 02:38:51PM -0700, Jesse Barnes wrote:
> Makes it more readable and maintainable. ValleyView will add its own
> PLL update function in a later patch.
>
> v2: split LVDS bits out of this patch (Daniel)
>
> Signed-off-by: Jesse Barnes
In-depth review ftw, i.e. two things b
On Fri, 23 Mar 2012 23:43:35 +0100, Daniel Vetter
wrote:
> With valleyview we'll have these at yet another address, so keeping
> track of this with an ever-growing list of registers will get ugly.
>
> This way intel_sdvo.c is fully independent of the base address of the
> output ports display re
On Thu, Mar 22, 2012 at 03:25:28PM -0700, Ben Widawsky wrote:
> On Thu, Mar 22, 2012 at 02:38:44PM -0700, Jesse Barnes wrote:
> > They were all over the place, order them by position and add a few.
> >
> > v2: add gen indications to the new bits (Ben)
> >
> > Signed-off-by: Jesse Barnes
> Review
On Thu, Mar 22, 2012 at 03:20:51PM -0700, Ben Widawsky wrote:
> On Thu, Mar 22, 2012 at 02:38:43PM -0700, Jesse Barnes wrote:
> > It's only used by the main read/write functions, so we can keep it with
> > them.
> >
> > Signed-off-by: Jesse Barnes
> Acked-by: Ben Widawsky
Queued for -next, thank
Again, Valleyview modes these around, so make the mmio base more
explicit to consolidate the base address computations to one
HAS_PCH_SPLIT check.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/intel_i2c.c | 15 ---
2 files chan
With valleyview we'll have these at yet another address, so keeping
track of this with an ever-growing list of registers will get ugly.
This way intel_sdvo.c is fully independent of the base address of the
output ports display register blocks.
While at it, do 2 closely related cleanups:
- use SDV
On Wed, 21 Mar 2012 10:48:18 +, Chris Wilson
wrote:
> One side-effect is that we ten have to double check that a fence was
s/ten/then/
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskt
On Fri, 23 Mar 2012 20:02:05 +, Chris Wilson
wrote:
> On Fri, 23 Mar 2012 20:18:37 +0100, Daniel Vetter wrote:
> > Mea culpa, but I agree that it's better to reap this instead of letting it
> > languish even longer as some dead code. For the patch itself, this does
> > way too much. Imo the
On Fri, 23 Mar 2012 20:18:37 +0100, Daniel Vetter wrote:
> On Thu, Mar 22, 2012 at 03:10:01PM +, Chris Wilson wrote:
> > I have failed to find a way to make this work without random GPU deaths,
> > so remove the ability to pipeline a fence update using the GPU. In the
> > process, we can refac
On Thu, Mar 22, 2012 at 03:10:01PM +, Chris Wilson wrote:
> I have failed to find a way to make this work without random GPU deaths,
> so remove the ability to pipeline a fence update using the GPU. In the
> process, we can refactor the code to improve the error handling and
> avoid unnecessary
On Thu, Mar 22, 2012 at 03:10:00PM +, Chris Wilson wrote:
> By simplifying the rules to calling get_fence when writing to the
> through the GTT in a tiled manner, and calling put_fence before writing
> to the object through the GTT in a linear manner, the code becomes
> clearer and there is les
On Wed, Mar 21, 2012 at 10:48:18AM +, Chris Wilson wrote:
> The BLT commands on gen2/3 utilize the fence registers and so we cannot
> modify any fences for the object whilst those commands are in flight.
> Currently we marked tiled commands as occupying a fence, but forgot to
> restrict the unt
On Fri, 23 Mar 2012 17:38:49 +
Chris Wilson wrote:
> Fixes a regression from 9e984bc1 (drm/i915: Don't do MTRR setup if PAT
> is enabled) where we left the MTRR as 0 and so tried to free a MTRR we
> did not own during unload.
>
> Reported-by: Ben Widawsky
> Cc: Ben Widawsky
> Cc: Adam Jack
On Fri, 23 Mar 2012 13:43:22 -0300
Eugeni Dodonov wrote:
> On Thu, Mar 22, 2012 at 22:42, Ben Widawsky wrote:
>
> > RC6 residency should be in intervals of 1.28us, and the counter
> > wraps. Here is an example using awk to get the RC6 and RC6+
> > residency in seconds, since boot.
> >
> > cat /
On 3/23/12 1:38 PM, Chris Wilson wrote:
Fixes a regression from 9e984bc1 (drm/i915: Don't do MTRR setup if PAT
is enabled) where we left the MTRR as 0 and so tried to free a MTRR we
did not own during unload.
Reported-by: Ben Widawsky
Cc: Ben Widawsky
Cc: Adam Jackson
Signed-off-by: Chris Wil
Fixes a regression from 9e984bc1 (drm/i915: Don't do MTRR setup if PAT
is enabled) where we left the MTRR as 0 and so tried to free a MTRR we
did not own during unload.
Reported-by: Ben Widawsky
Cc: Ben Widawsky
Cc: Adam Jackson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c
On Thu, Mar 22, 2012 at 18:38, Jesse Barnes wrote:
> ValleyView and similar hardware (like CedarView) put some display
> related registers like the PLL controls and dividers on a DPIO bus. Add
> simple indirect register access routines to get to those registers.
>
> v2: move new wait_for macro to
On Thu, Mar 22, 2012 at 18:39, Jesse Barnes wrote:
> ValleyView handles force wake differently than previous chipsets, so add
> a couple of new functions for it. But leave it disabled by default
> until we test it (need a chip with the Punit enabled first).
>
> Signed-off-by: Jesse Barnes
> ---
On Thu, Mar 22, 2012 at 18:39, Jesse Barnes wrote:
> Might be able to merge this back in at some point, but we're seeing bugs
> with ADPA based detection, so keep it separate for now with explicit
> hotplug trigger usage.
>
> v2: drop superfluous debug message
>
[...]
> +
> + DRM_DEBUG_KM
On Thu, Mar 22, 2012 at 18:39, Jesse Barnes wrote:
> We'll probably need new init functions and will need to test it.
>
> Signed-off-by: Jesse Barnes
>
This will be the same case for HSW I guess. And it is not the case of
adding a new feature check, like HAS_TURBO, because these platforms do hav
On Thu, Mar 22, 2012 at 22:42, Ben Widawsky wrote:
> RC6 residency should be in intervals of 1.28us, and the counter wraps.
> Here is an example using awk to get the RC6 and RC6+ residency in
> seconds, since boot.
>
> cat /sys/kernel/debug/dri/0/i915_drpc_info | grep residency | awk -F':'
> -F'
On Fri, Mar 23, 2012 at 11:57:17AM -0300, Eugeni Dodonov wrote:
> Hi,
>
> Daniel Vetter and Chris Wilson noticed that the latest rc6 patches went
> missing
> in the latest drm merge requests. So I updated them to the latest Linus' tree,
> and improved the description a bit.
Yeah, sorry again I'v
On Fri, 23 Mar 2012 11:57:19 -0300, Eugeni Dodonov
wrote:
> This is yet another chapter in the ongoing saga of bringing RC6 to Sandy
> Bridge machines by default.
>
> Now that we have discovered that RC6 issues are triggered by RC6+ state,
> let's try to disable it by default. Plain RC6 is the o
This is yet another chapter in the ongoing saga of bringing RC6 to Sandy
Bridge machines by default.
Now that we have discovered that RC6 issues are triggered by RC6+ state,
let's try to disable it by default. Plain RC6 is the one responsible for
most energy savings, and so far it haven't given an
This allows to select which rc6 modes are to be used via kernel parameter,
via a bitmask parameter. E.g.:
- to enable rc6, i915_enable_rc6=1
- to enable rc6 and deep rc6, i915_enable_rc6=3
- to enable rc6 and deepest rc6, use i915_enable_rc6=5
- to enable rc6, deep and deepest rc6, use i915_enable
Hi,
Daniel Vetter and Chris Wilson noticed that the latest rc6 patches went missing
in the latest drm merge requests. So I updated them to the latest Linus' tree,
and improved the description a bit.
Those settings have received a huge testing on Ubuntu (thanks a lot
Canonical!!), and so far it lo
On Fri, Feb 24, 2012 at 09:13:38PM +, Chris Wilson wrote:
> If we discard a buffer due to memory pressure, also release its alloted
> mmap address space. As it may be sometime before userspace wakes up
> and notices that it has buffers to purge from its cache, we may waste
> valuable address sp
Hi all,
I've pushed out an updated -next and -testing tree. Highlights:
- more decoupling of ppgtt and global gtt.
- shut up the compiler (Ben)
- a bunch of minor quirks and fixlets, accompanied with quite a few module
options to ease debuggin (and adding new entries to these for these new
qui
On Thu, Mar 22, 2012 at 08:29:30PM -0700, Ben Widawsky wrote:
> On Thu, Mar 22, 2012 at 02:38:46PM -0700, Jesse Barnes wrote:
> > Add support for ValleyView watermark handling. It's like Cantiga with a
> > few small differences (big FIFO mode and different WM limits).
> >
> > Signed-off-by: Jesse
34 matches
Mail list logo
