On Thu, 19 Dec 2013, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because we already do the wait in software: see
> ironlake_wait_backlight_on and ironlake_edp_wait_backlight_off.
>
> For the "backlight on" delay, even BSpec says we need to program 0x1
> to PP_ON_DELAYS 12:0.
>
> For the "backlig
v2: Rebased upon cleaned up error state
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 9
drivers/gpu/drm/i915/i915_gpu_error.c | 39 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915
This helps make an upcoming patch a bit more reviewable
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 43 -
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 62 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 137 +-
2 files changed, 99 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i91
Chris:
Do we also want to capture?
GAC_ECO_BITS /* gen6,7 */
GAM_ECOCHK /* gen6,7 */
GAB_CTL /* gen6 */
GFX_MODE /* gen6 */
Requested-by: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/i915_gpu_error.c | 16
The code has become quite hairy. By relocating all the generic registers
it will become more obvious where future ones should go. There is still
admittedly a bit of confusion left for things like per ring registers.
A subsequent patch will clean this function up.
Signed-off-by: Ben Widawsky
---
Create logical sections in an attempt to clean up, and continue to keep
future additions clean.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gpu_error.c | 60 +--
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
There are cases where we want to know if there is a full, or aliased
PPGTT. Currently, in fact the only distinction we ever need to make is
when we're using full PPGTT.
This patch is simply to promote readability and clarify for the
confusing existing usage where "aliasing" meant aliasing and full
From: Chia-I Wu
The optimization helps IVB too. No piglit regression.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c535e5c..58aba3e 100644
--- a/driv
From: Chia-I Wu
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as GLBenchmark TRex test.
No piglit regression.
v2
- no need to save the register before suspend as init_clock_gating can
correctly program it after r
On Mon, Jan 27, 2014 at 9:07 PM, Ville Syrjälä
wrote:
> On Mon, Jan 27, 2014 at 04:18:36PM +0800, Chia-I Wu wrote:
>> From: Chia-I Wu
>>
>> The optimization is available on Ivy Bridge and later, and is disabled by
>> default. Enabling it helps certain workloads such as GLBenchmark TRex test.
>
>
From: Zhao Yakui
The Sampler/Constant cache is read-only. And it can't be used as
the target cache agent of WRITE message.
Signed-off-by: Zhao Yakui
---
assembler/gram.y | 4
1 file changed, 4 deletions(-)
diff --git a/assembler/gram.y b/assembler/gram.y
index ad4cb29..589a0fe 100644
---
On Mon, Jan 27, 2014 at 02:20:16PM -0800, Kenneth Graunke wrote:
> On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set
> must be preceded by a PIPE_CONTROL with the "CS Stall" bit set.
>
> Documented on the BSpec 3D workarounds page.
FWIW, I am not clear this is actually need
On Mon, Jan 27, 2014 at 02:20:18PM -0800, Kenneth Graunke wrote:
> These should only be necessary on pre-production hardware.
>
> Signed-off-by: Kenneth Graunke
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 12
> 2 files changed, 13 insertions(+
On Mon, Jan 27, 2014 at 02:20:14PM -0800, Kenneth Graunke wrote:
> According to the latest documentation, any PIPE_CONTROL with the
> "Command Streamer Stall" bit set must also have another bit set,
> with five different options. I chose "Stall at Pixel Scoreboard"
> since we've used it effectivel
On Mon, 13 Jan 2014 16:24:45 +0530
akash.g...@intel.com wrote:
> From: Akash Goel
>
> The 'offset' field of the 'scatterlist' structure was wrongly
> programmed with the offset value from the base of stolen area,
> whereas this field indicates the offset from where the interested
> data starts w
On Sun, 26 Jan 2014 12:24:33 + Chris Wilson
wrote:
> Note for maintainers, this is being proposed for use by i915.ko, so it
> may make the most sense to merge it via the drm/i915 tree in the next
> cycle.
Yes, please proceed that way.
___
Intel-gf
As the VM do not track activity of objects and instead use a large
hammer to forcibly idle and evict all of their associated objects when
one is released, it is possible for that to cause a recursion when we
need to wait for free space on a ring and call retire requests.
(intel_ring_begin -> intel_
On Mon, Jan 27, 2014 at 04:23:26PM -0600, Jeff McGee wrote:
> On Mon, Jan 27, 2014 at 05:50:04PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 27, 2014 at 10:24:53AM -0600, Jeff McGee wrote:
> > > On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
> > > > On Thu, Jan 23, 2014 at 03:54:50P
From: Chris Wilson
One side-effect of the introduction of ppgtt was that we needed to
rebind the object into the appropriate vm (and global gtt in some
peculiar cases). For simplicity this was done twice for every object on
every call to execbuffer. However, that adds a tremendous amount of CPU
o
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
Split out from Chris' vma-binding rework patch.
v2: Undo the behaviour change in object_pin that Chris spotted.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gp
These should only be necessary on pre-production hardware.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg
This should apply even for production hardware.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b958e85..4
We'll want to reuse this for a workaround.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 37 -
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ring
On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set
must be preceded by a PIPE_CONTROL with the "CS Stall" bit set.
Documented on the BSpec 3D workarounds page.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +
1 file changed, 9 inser
According to the latest documentation, any PIPE_CONTROL with the
"Command Streamer Stall" bit set must also have another bit set,
with five different options. I chose "Stall at Pixel Scoreboard"
since we've used it effectively in the past, but the choice is
fairly arbitrary.
Signed-off-by: Kennet
On Mon, Jan 27, 2014 at 05:50:04PM +0100, Daniel Vetter wrote:
> On Mon, Jan 27, 2014 at 10:24:53AM -0600, Jeff McGee wrote:
> > On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 23, 2014 at 03:54:50PM -0600, jeff.mc...@intel.com wrote:
> > > > From: Jeff McGee
> > >
On Mon, Jan 27, 2014 at 09:47:12PM +, Chris Wilson wrote:
> On Mon, Jan 27, 2014 at 07:10:51PM +0100, Daniel Vetter wrote:
> > Anything more than just one bool parameter is just a pain to read,
> > symbolic constants are much better.
>
> This patch introduces PIN_GLOBAL which is required for g
On Mon, Jan 27, 2014 at 09:31:04PM +, Chris Wilson wrote:
> On Mon, Jan 27, 2014 at 12:31:08PM -0800, Ben Widawsky wrote:
> > The other issue is the existing method doesn't rely as much on proper
> > request handling, ie. this could be more resilient to driver bugs. I
> > kind of want to keep b
On Mon, Jan 27, 2014 at 07:10:51PM +0100, Daniel Vetter wrote:
> Anything more than just one bool parameter is just a pain to read,
> symbolic constants are much better.
This patch introduces PIN_GLOBAL which is required for ggtt_pin to
remain correct with the flag changes in the later patches, bu
On Mon, Jan 27, 2014 at 10:26 PM, Chris Wilson wrote:
> On Mon, Jan 27, 2014 at 09:49:47PM +0100, Daniel Vetter wrote:
>> Userspace can currently provoke this when e.g. trying to use a pinned
>> scanout as a cursor or overlay target. Later on that might lead to
>> some fun fence pin count mayhem.
On Mon, Jan 27, 2014 at 12:31:08PM -0800, Ben Widawsky wrote:
> The other issue is the existing method doesn't rely as much on proper
> request handling, ie. this could be more resilient to driver bugs. I
> kind of want to keep both...
Actually I think it is. Part of the process of reading an erro
On Mon, Jan 27, 2014 at 09:49:47PM +0100, Daniel Vetter wrote:
> Userspace can currently provoke this when e.g. trying to use a pinned
> scanout as a cursor or overlay target. Later on that might lead to
> some fun fence pin count mayhem.
>
> Spurred by Ville's report that something goes wrong her
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence pin count mayhem.
Spurred by Ville's report that something goes wrong here and
originally I've thought that this might slip through the pwrite gtt
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-
On Mon, Jan 27, 2014 at 01:45:22PM +, Chris Wilson wrote:
> On Sun, Jan 26, 2014 at 01:47:29PM -0800, Ben Widawsky wrote:
> > On Sun, Jan 26, 2014 at 07:55:59PM +, Chris Wilson wrote:
> > > On Sun, Jan 26, 2014 at 11:05:40AM -0800, Ben Widawsky wrote:
> > > > On Sun, Jan 26, 2014 at 11:47:4
Only the hardware really access them, so no need to have cpu
gtt access available.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/i915_gem.c | 20
2 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i
This is prep work for reworking the object_pin logic. Atm
it still does a (now redundant) lookup of the vma. The next
patch will fix this.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 23 +++-
We access it through the cpu window. No functional difference expected
atm since we default to a bottom-up allocation scheme. But that might
eventually change so that we prefer the unmappable range for buffers
that don't need cpu gtt access.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
There's no need not to, really.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/d
On Mon, Jan 27, 2014 at 01:45:22PM +, Chris Wilson wrote:
> On Sun, Jan 26, 2014 at 01:47:29PM -0800, Ben Widawsky wrote:
> > On Sun, Jan 26, 2014 at 07:55:59PM +, Chris Wilson wrote:
> > > On Sun, Jan 26, 2014 at 11:05:40AM -0800, Ben Widawsky wrote:
> > > > On Sun, Jan 26, 2014 at 11:47:4
From: Chris Wilson
One side-effect of the introduction of ppgtt was that we needed to
rebind the object into the appropriate vm (and global gtt in some
peculiar cases). For simplicity this was done twice for every object on
every call to execbuffer. However, that adds a tremendous amount of CPU
o
Tighter code since legacy gem has only mappable anyway.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/int
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
Split out from Chris' vma-binding rework patch.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h| 15
drivers/gpu/drm/i
Apparently I've lost a game of chicken. For review I'd like to sign up Jani for
the overall series and Ben to upgrade his ack on the actual bugfix to a full
r-b.
Cheers, Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.free
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuff
On Mon, Jan 27, 2014 at 09:56:12AM -0800, Volkin, Bradley D wrote:
> > +static void
> > +i915_mmu_notifier_del(struct i915_mmu_notifier *mmu,
> > + struct i915_mmu_object *mn)
> > +{
> > + bool destroy;
> > +
> > + spin_lock(&mmu->lock);
> > + interval_tree_remove(&mn->it, &mm
Hi Chris,
A few questions/comments throughout. I may be off the mark on some. Please
bear with me as I try to get more familiar with the gem code.
Thanks,
Brad
[ snip ]
On Fri, Jan 24, 2014 at 01:00:19AM -0800, Chris Wilson wrote:
> +static void
> +__i915_mmu_notifier_destroy_worker(struct work
On Mon, 27 Jan 2014, Daniel Vetter wrote:
> On Mon, Jan 27, 2014 at 11:05:47AM -0500, Alan Stern wrote:
> > On Mon, 27 Jan 2014, Daniel Vetter wrote:
> >
> > > > By the way, I tried getting an up-to-date version of your
> > > > drm-intel-nightly branch, and ended up with the following:
> > > >
On Mon, Jan 27, 2014 at 09:35:06PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> When we enter RC6 and GFX Clocks are off, the voltage remains higher
> than Vmin. When we try to set the freq to RPn, it might fail since the
> Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX c
On Mon, Jan 27, 2014 at 10:24:53AM -0600, Jeff McGee wrote:
> On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 23, 2014 at 03:54:50PM -0600, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > The current frequency should reach the minimum frequency within
On Mon, Jan 27, 2014 at 09:35:06PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> When we enter RC6 and GFX Clocks are off, the voltage remains higher
> than Vmin. When we try to set the freq to RPn, it might fail since the
> Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX c
On Mon, Jan 27, 2014 at 11:05:47AM -0500, Alan Stern wrote:
> On Mon, 27 Jan 2014, Daniel Vetter wrote:
>
> > > By the way, I tried getting an up-to-date version of your
> > > drm-intel-nightly branch, and ended up with the following:
> > >
> > > $ git clone --depth 1 -b drm-intel-nightly
> > >
On Mon, Jan 27, 2014 at 03:26:38PM +0200, Jani Nikula wrote:
> Having to use i915.i915_foo is inconsistent and a bit on the verbose
> side. Drop the prefix per Daniel's request, who also says this is not
> ABI we need to maintain.
>
> Signed-off-by: Jani Nikula
Queued for -next, thanks for the p
On Mon, Jan 27, 2014 at 03:07:45PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 27, 2014 at 04:18:36PM +0800, Chia-I Wu wrote:
> > From: Chia-I Wu
> >
> > The optimization is available on Ivy Bridge and later, and is disabled by
> > default. Enabling it helps certain workloads such as GLBenchmark T
On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
> On Thu, Jan 23, 2014 at 03:54:50PM -0600, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > The current frequency should reach the minimum frequency within a
> > reasonable time during idle.
> >
> > v2: Not using forcewake f
On Mon, Jan 27, 2014 at 04:05:24PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 27, 2014 at 01:52:34PM +, Chris Wilson wrote:
> > Currently we report through our error state only the rings that have
> > been initialised (as detected by ring->obj). This check is done after
> > the GPU reset and rin
From: Deepak S
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPn then move GFx down.
v2: remove vlv_update_rps
On Mon, 27 Jan 2014, Daniel Vetter wrote:
> > By the way, I tried getting an up-to-date version of your
> > drm-intel-nightly branch, and ended up with the following:
> >
> > $ git clone --depth 1 -b drm-intel-nightly
> > http://cgit.freedesktop.org/~danvet/drm-intel/
> > Cloning into 'drm-inte
From: Deepak S
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for
From: Deepak S
Below patches addes WA to set Gfx freq while clock are down and enable/disable
the pm interrupts based on cur delay.
Deepak S (2):
drm/i915: Disable/Enable PM Intrrupts based on the current freq.
drm/i915/vlv: WA to fix Voltage not getting dropped to Vmin when Gfx
is powe
On Mon, Jan 27, 2014 at 01:06:33PM +0200, Ville Syrjälä wrote:
> On Sun, Jan 26, 2014 at 06:29:06PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 21, 2014 at 04:12:38PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a mechanism by which we can evade the le
On Mon, Jan 27, 2014 at 10:30:11AM -0500, Alan Stern wrote:
> On Mon, 27 Jan 2014, Daniel Vetter wrote:
>
> > On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern
> > wrote:
> > > Don't bother. I'll redo it using the drm-intel-nightly branch, but I
> > > won't have time for a few days.
> >
> > My apolo
On Mon, 27 Jan 2014, Daniel Vetter wrote:
> On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern wrote:
> > Don't bother. I'll redo it using the drm-intel-nightly branch, but I
> > won't have time for a few days.
>
> My apologies for the delay in getting around to this. Can you please
> test the patch i
On Mon, Jan 27, 2014 at 01:52:34PM +, Chris Wilson wrote:
> Currently we report through our error state only the rings that have
> been initialised (as detected by ring->obj). This check is done after
> the GPU reset and ring re-initialisation, which means that the software
> state may not be t
Currently we report through our error state only the rings that have
been initialised (as detected by ring->obj). This check is done after
the GPU reset and ring re-initialisation, which means that the software
state may not be the same as when we captured the hardware error and we
may not print ou
On Sun, Jan 26, 2014 at 01:47:29PM -0800, Ben Widawsky wrote:
> On Sun, Jan 26, 2014 at 07:55:59PM +, Chris Wilson wrote:
> > On Sun, Jan 26, 2014 at 11:05:40AM -0800, Ben Widawsky wrote:
> > > On Sun, Jan 26, 2014 at 11:47:40AM +, Chris Wilson wrote:
> > > > On Fri, Jan 24, 2014 at 06:17:4
On Mon, Jan 27, 2014 at 03:09:34PM +0200, Antti Koskipaa wrote:
> RFCv2: Reorganize array indexing so that full offsets can be used as
> is. It makes grepping for registers in i915_reg.h much easier. Also
> move offset arrays to intel_device_info.
>
> v1: Fixed offsets for VLV, proper eDP handling
Having to use i915.i915_foo is inconsistent and a bit on the verbose
side. Drop the prefix per Daniel's request, who also says this is not
ABI we need to maintain.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_params.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(
On Mon, Jan 27, 2014 at 04:18:36PM +0800, Chia-I Wu wrote:
> From: Chia-I Wu
>
> The optimization is available on Ivy Bridge and later, and is disabled by
> default. Enabling it helps certain workloads such as GLBenchmark TRex test.
Actually BSpec even goes as far as saying that this optimizati
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP pip
On Mon, Jan 27, 2014 at 02:51:53PM +0200, Antti Koskipää wrote:
> On 01/27/14 13:21, Chris Wilson wrote:
> > On Mon, Jan 27, 2014 at 01:17:25PM +0200, Antti Koskipaa wrote:
> >> RFCv2: Reorganize array indexing so that full offsets can be used as
> >> is. It makes grepping for registers in i915_reg
On 01/27/14 13:21, Chris Wilson wrote:
> On Mon, Jan 27, 2014 at 01:17:25PM +0200, Antti Koskipaa wrote:
>> RFCv2: Reorganize array indexing so that full offsets can be used as
>> is. It makes grepping for registers in i915_reg.h much easier. Also
>> move offset arrays to intel_device_info.
>>
>> P
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
PATCHv1: Fixed offsets for VLV
Upcoming hardware will not have the various display pipe register
ranges evenly spaced i
And subject is misleading, I don't call this a clean up.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Jan 27, 2014 at 01:17:25PM +0200, Antti Koskipaa wrote:
> RFCv2: Reorganize array indexing so that full offsets can be used as
> is. It makes grepping for registers in i915_reg.h much easier. Also
> move offset arrays to intel_device_info.
>
> PATCHv1: Fixed offsets for VLV
>
> Upcoming h
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP pip
Sorry, sent the wrong file. Ignore this one.
--
- Antti
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 01/24/14 14:52, Ville Syrjälä wrote:
> On Fri, Jan 24, 2014 at 02:13:14PM +0200, Antti Koskipaa wrote:
>> +#define PIPE_A_OFFSET 0x7
>> +#define PIPE_B_OFFSET 0x71000
>> +#define PIPE_C_OFFSET 0x72000
>
> I'd like a comment here to explain what PIPE_EDP_OFFSET
> actually m
On Sun, Jan 26, 2014 at 06:29:06PM +0100, Daniel Vetter wrote:
> On Tue, Jan 21, 2014 at 04:12:38PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add a mechanism by which we can evade the leading edge of vblank. This
> > guarantees that no two sprite register writes w
On Mon, Jan 27, 2014 at 09:57:11AM +, Chris Wilson wrote:
> On Mon, Jan 27, 2014 at 10:00:31AM +0100, Daniel Vetter wrote:
> > We seem to get confused when trying to reconstruct this from the pipe
> > get_config when reading out pfit state. In our code these two are
> > connected, but in the ha
On Mon, Jan 27, 2014 at 10:00:31AM +0100, Daniel Vetter wrote:
> We seem to get confused when trying to reconstruct this from the pipe
> get_config when reading out pfit state. In our code these two are
> connected, but in the hardware they're not.
Huh? I think the change is to only read out the b
On Sat, Jan 25, 2014 at 08:57:34PM +0100, Daniel Vetter wrote:
> On Thu, Jan 23, 2014 at 04:49:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
>
> Hm, running the fbc tests with a 16bpp fb would be neat ...
Indeed. I'll put it on th
On Sun, Jan 26, 2014 at 03:35:42PM +0100, Daniel Vetter wrote:
> On Sun, Jan 26, 2014 at 03:33:32PM +0100, Daniel Vetter wrote:
> > On Sat, Jan 25, 2014 at 08:59:49PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 23, 2014 at 07:47:59PM +, Chris Wilson wrote:
> > > > On Thu, Jan 23, 2014 at 04:4
On Sun, Jan 26, 2014 at 03:33:32PM +0100, Daniel Vetter wrote:
> On Sat, Jan 25, 2014 at 08:59:49PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 23, 2014 at 07:47:59PM +, Chris Wilson wrote:
> > > On Thu, Jan 23, 2014 at 04:49:07PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
On Mon, Jan 27, 2014 at 9:33 AM, Chia-I Wu wrote:
> [Additional comments, and copy Ian and Chad for real]
>
> On Mon, Jan 27, 2014 at 4:18 PM, Chia-I Wu wrote:
>> From: Chia-I Wu
>>
>> The optimization is available on Ivy Bridge and later, and is disabled by
>> default. Enabling it helps certai
On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern wrote:
> Don't bother. I'll redo it using the drm-intel-nightly branch, but I
> won't have time for a few days.
My apologies for the delay in getting around to this. Can you please
test the patch i've just posted?
http://patchwork.freedesktop.org/patc
We seem to get confused when trying to reconstruct this from the pipe
get_config when reading out pfit state. In our code these two are
connected, but in the hardware they're not.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Cc: Alan Stern
Cc: sta...@vger.kernel.org
Signed-off-by:
Apparently we really only need this when the pfit is enabled, at least
I couldn't dicern any difference here. Furthermore the hacks we have
to reconstruct this bit is a bit glaring, and probably only works
because we can't move the lvds port to any other pipe than pipe B on
gen2/3.
So let's just r
[Additional comments, and copy Ian and Chad for real]
On Mon, Jan 27, 2014 at 4:18 PM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> The optimization is available on Ivy Bridge and later, and is disabled by
> default. Enabling it helps certain workloads such as GLBenchmark TRex test.
With the patch ap
From: Chia-I Wu
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as GLBenchmark TRex test.
Signed-off-by: Chia-I Wu
Cc: Ian Romanick
Cc: Chad Versace
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i
92 matches
Mail list logo
