On Wed, 16 Jan 2013 21:09:32 -0200
Rodrigo Vivi wrote:
> On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> > And, move it to where the rest of the logic is.
> >
> > Cc: Dave Airlie
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/char/agp/intel-gtt.c| 27 --
Hi,
I am currently working with a team that is porting the Intel Linux open source
stack to Integrity OS (a real-time OS by Green Hills) for embedded systems. The
current architecture we're using is the Sandybridge architecture (device ID:
0x0116). After a good amount of work, we have finally m
Reviewed-by: Rodrigo Vivi
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> We already had a mapping in both (minus the phys_addr in AGP).
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/char/agp/intel-gtt.c| 9 +
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/g
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> And, move it to where the rest of the logic is.
>
> Cc: Dave Airlie
> Signed-off-by: Ben Widawsky
> ---
> drivers/char/agp/intel-gtt.c| 27 ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/
Reviewed-by: Rodrigo Vivi
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
> drivers/char/agp/intel-gtt.c | 35 +--
> include/drm/intel-gtt.h | 11 +--
> 2 files changed, 22 insertions(+), 24 deletions(-)
>
>
Reviewed-by: Rodrigo Vivi
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> drivers/gpu/drm/i915/i915_gem_gtt.c| 7 ---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 8
> 3 files changed, 10
why not put gtt_mtrr to new gtt struct?
anyways, feel free to use Reviewed-by: Rodrigo Vivi
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> The purpose of the gtt structure is to help isolate our gtt specific
> properties from the rest of the code (in doing so it help us finish the
> iso
for the patch itself feel free to use
Reviewed-by: Rodrigo Vivi
but at this point I just got a bit confused why not having an standard
like always using total or always using end-start...
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> With the assertion from the previous patch in plac
Reviewed-by: Rodrigo Vivi
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> Both DRI1 and DRI2 can never specify a mappable size which goes past the
> GTT size. Don't pretend otherwise.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +++-
> 1 file changed
Reviewed-by: Rodrigo Vivi
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> It's duplicated in the more useful gtt_total.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +--
> 2 files changed, 1 insertion(+), 3
On Wed, Jan 16, 2013 at 10:11:30AM -0800, Jesse Barnes wrote:
> On Wed, 16 Jan 2013 19:59:03 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Fix up some copypaste errors in the PIPESTAT register for VLV.
> >
> > SPRITE0_FLIP_DONE_INT_EN_VLV is bit 22, not bit 26.
Nothing is shared anymore between AGP and drm/i915 driver. Pre-GEN6
still uses AGP, but all necessary info is encapsulated per driver.
v2: Conflict resolution from earlier rebase
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c| 7 ---
drivers/gpu/drm/i915/i915_gem_gtt.
The reasoning behind our code taking two paths depending upon whether or
not we may have been configured for IOMMU isn't clear to me. It should
always be safe to use the pci mapping functions as they are designed to
abstract the decision we were handling in i915.
Aside from simpler code, removing
Similar to gtt_mappable_entries we don't usually want the entries,
it's easy enough to calculate it when you need.
v2: Move relevant fields above pre-gen6 init
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 33
Mappable_end, ie. size is almost always what you want as opposed to the
number of entries. Since we already have that information, we can scrap
the number of entries and only calculate it when needed.
If gtt_start is !0, this will have slightly different behavior. This
difference can only occur in
We have enough info to not use the intel_gtt bridge stuff.
v2: Move setup of mappable_base above the legacy init stuff because we
still need that on older platforms. (Daniel)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 3 +--
drivers/gpu/drm/i915/i915_gem_gtt.c
On Wed, 16 Jan 2013 19:59:03 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Fix up some copypaste errors in the PIPESTAT register for VLV.
>
> SPRITE0_FLIP_DONE_INT_EN_VLV is bit 22, not bit 26.
>
> SPRITE0_FLIPDONE_INT_STATUS_VLV is bit 14, not bit 15.
>
> Signed-off-by
From: Ville Syrjälä
Fix up some copypaste errors in the PIPESTAT register for VLV.
SPRITE0_FLIP_DONE_INT_EN_VLV is bit 22, not bit 26.
SPRITE0_FLIPDONE_INT_STATUS_VLV is bit 14, not bit 15.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h |4 ++--
1 files changed, 2 inser
From: Ville Syrjälä
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise ful
Second attempt at handling the RGB quantization range for HDMI and DP.
The only change to the first set is that I dropped the
has_hdmi_monitor bool. has_hdmi_sink is used instead.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.fr
From: Ville Syrjälä
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
From: Ville Syrjälä
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 33 +
From: Ville Syrjälä
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
On Tue, Jan 08, 2013 at 10:53:19AM +, Chris Wilson wrote:
> Certain workarounds and workloads require objects at specific or at
> least known offsets. Privileged users could pin an object into the GTT,
> but that has obvious limitations for the general case. Instead, the user
> can construct a
On Tue, Jan 08, 2013 at 10:53:18AM +, Chris Wilson wrote:
> As we only maintain the list underneath the struct_mutex, we can hold a
> 'borrowed' reference to the objects safe in the knowledge that they will
> not disappear.
>
> Signed-off-by: Chris Wilson
Ok, after our irc discussion I've ch
On Tue, Jan 08, 2013 at 10:53:17AM +, Chris Wilson wrote:
> Using copywinwin10 as an example that is dependent upon emitting a lot
> of relocations (2 per operation), we see improvements of:
>
> c2d/gm45: 618000.0/sec to 623000.0/sec.
> i3-330m: 748000.0/sec to 789000.0/sec.
>
> (measured rel
On Tue, Jan 08, 2013 at 10:53:14AM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
Tiny bikeshed to sneak into follow-up patches, maybe ;-)
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 86
> +++-
> 1 file changed, 46 insertions(+), 40 deletions(-)
>
On Tue, Jan 08, 2013 at 10:53:13AM +, Chris Wilson wrote:
> The difference is that the kernel will then know that this memory will
> be reclaimable in the near future.
>
> Signed-off-by: Chris Wilson
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Co
On Tue, Jan 08, 2013 at 10:53:11AM +, Chris Wilson wrote:
> Clients like i915 needs to segregate cache domains within the GTT which
> can lead to small amounts of fragmentation. By allocating the uncached
> buffers from the bottom and the cacheable buffers from the top, we can
> reduce the amou
On Tue, Jan 08, 2013 at 10:53:09AM +, Chris Wilson wrote:
> Move the existing checking inside bind_to_gtt() to the more appropriate
> layer in order to prevent recreation of the pages after they have been
> explicitly truncated.
>
> Signed-off-by: Chris Wilson
Queued for -next, thanks for the
On Tue, Jan 08, 2013 at 10:53:10AM +, Chris Wilson wrote:
> If the object lies outside of the mappable GTT aperture, do not force it
> through the CPU domain for relocations, but simply flush the writes as
> we perform them and then queue a chipset flush.
>
> Signed-off-by: Chris Wilson
A fe
On Wed, Jan 16, 2013 at 04:42:35PM +0100, Daniel Vetter wrote:
> On Wed, Dec 05, 2012 at 02:02:21PM +, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
> > ---
> > tests/Makefile.am |1 +
> > tests/gem_lut_handle.c | 109
> >
> >
On Wed, Dec 05, 2012 at 02:02:21PM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> tests/Makefile.am |1 +
> tests/gem_lut_handle.c | 109
>
> 2 files changed, 110 insertions(+)
> create mode 100644 tests/gem_lut_handle
A bunch of miscellaneous fixes for assertion failures and various
performance regressions when mixing new methods for offloads, along with
a couple of improvements for rendering with gen4.
* Remove use of packed unnormalized texture coordinates on gen4/5 as
these GPUs do not support unnormaliz
On Tue, 2013-01-08 at 10:53 +, Chris Wilson wrote:
> Certain workarounds and workloads require objects at specific or at
> least known offsets. Privileged users could pin an object into the GTT,
> but that has obvious limitations for the general case. Instead, the user
> can construct a batch a
On Tue, Jan 15, 2013 at 12:39:35PM +, Chris Wilson wrote:
> As a means to investigate some bad system behaviour related to the
> purging of the active, inactive and unbound lists, it is useful to be
> able to manually control when those lists should be cleared.
>
> v2: use _safe list iterators
On Tue, Jan 15, 2013 at 04:17:54PM +, Chris Wilson wrote:
> In the slow path, we are forced to copy the relocations prior to
> acquiring the struct mutex in order to handle pagefaults. We forgo
> copying the new offsets back into the relocation entries in order to
> prevent a recursive locking
On Wed, Jan 16, 2013 at 10:53:40AM +0200, Jani Nikula wrote:
> Some machines detect an eDP port even if it's not really there, and eDP
> initialization has a fail path for this. Typically such machines have an
> LVDS display instead. A regression introduced in
>
> commit 82ed61fa1a4e08d5f9e86fb1b7
Some machines detect an eDP port even if it's not really there, and eDP
initialization has a fail path for this. Typically such machines have an
LVDS display instead. A regression introduced in
commit 82ed61fa1a4e08d5f9e86fb1b715b50ed678b6ac
Author: Daniel Vetter
Date: Sat Oct 20 20:57:41 2012
39 matches
Mail list logo
