On Tue, 15 Apr 2014, Daniel Vetter wrote:
> On Fri, Apr 11, 2014 at 08:26:25PM +0300, Imre Deak wrote:
>> On Fri, 2014-04-11 at 19:07 +0200, Egbert Eich wrote:
>> > When linking the i2c sysfs file into the connector's directory
>> > pass directory and link target in the right order.
>> > This code
On Tue, 06 May 2014, Daniel Vetter wrote:
> On Tue, May 06, 2014 at 10:04:17PM +0200, Knut Petersen wrote:
>> On 06.05.2014 20:59, Daniel Vetter wrote:
>> >On Tue, May 06, 2014 at 04:30:45PM +0300, Jani Nikula wrote:
>> >>On Tue, 06 May 2014, Knut Petersen wrote:
>> >>>On 28.04.2014 15:26, Daniel
On Mon, 2014-05-05 at 16:07 +0200, Daniel Vetter wrote:
> On Mon, May 05, 2014 at 05:13:18PM +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
> >
> > There is a use case, when user space (display compositor) tries
> > to directly flip a fb (without any prior rendering) on primary
> > plane
The DRM node allocation code was already a bit of an ugly bit of code
within a complex function. Removing it serves the purpose of cleaning
the function up. More importantly, it provides a way to have a
preallocated (address space) VMA to easily skip this code. Something
we're very likely to need.
The two users were already really similar. By adding the flags (I hope
you like a lot of arguments in your functions), we can satisfy both
callers quite well.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 16
drivers/gpu/drm/i915/i915_gem.c | 34 +
The driver currently lets callers pin global, and then tries to do
things correctly inside the function. Doing so has two downsides:
1. It's not possible to exclusively pin to a global, or an aliasing
address space.
2. It's difficult to read, and understand.
The eventual goal when realized should
AFAICT, it's impossible to actually infinitely retry the allocation in
our current code. However, a small oversight on my part, slight bug, or
future bug, could easily change that.
To avoid a potential breakage, a simple retry variable of 16 bits will
help us prevent infinitely running.
Retry is
We only actually want to retry if the failure mode was not enough space,
and so we'll evict. This will help us realize quickly in case we missed
a change in the common drm code.
NOTE: A similar check is already in place for the GEN7 PPGTT code.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i9
There is a good debate to be had about how best to fit the aliasing
PPGTT into the code. However, as it stands right now, getting aliasing
PPGTT bindings is a hack, and done through implicit arguments. To make
this absolutely clear, WARN and return an error if a driver writer tries
to do something
This patch finishes off actually separating the aliasing and global
finds. Prior to this, all global binds would be aliased. Now if aliasing
binds are required, they must be explicitly asked for. So far, we have
no users of this outside of execbuf - but Mika has already submitted a
patch requiring
This will be useful for some upcoming patches which do more platform
specific work. Having it in one central place just makes things a bit
cleaner and easier.
There is a small functional change here. There are more calls to the
tracepoints.
NOTE: I didn't actually end up using this patch for the
It was always the intention to do the topdown allocation for context
objects (Chris' idea originally). Unfortunately, I never managed to land
the patch, but someone else did, so now we can use it.
As a reminder, hardware contexts never need to be in the precious GTT
aperture space - which is what
From: Ben Widawsky
Daniel requested in the bug that I use a 3GB fallback size. Since this
is not in the spec as a valid size, I decided against it. We could
potentially add a patch to bump it to 3GB on top of this one.
This probably should be CC: stable - but I'll let the powers that be
decide t
"So can you not tracepoints to give EI results for up/down signals and
filter out the noise? ", Do you mean I don't need the debugfs at all?
For developer, he/she is able to trace anything including the point of
Turbo algorithm adjustment(+n/-n).
But as a black box, validation will not see the c
On Wed, May 07, 2014 at 12:40:13AM +0200, Daniel Vetter wrote:
> On Wed, May 07, 2014 at 12:40:53AM +0300, Abdiel Janulgue wrote:
> > Add test that makes sure RS bit only gets executed on BDW and
> > on the render ring.
> >
> > Signed-off-by: Abdiel Janulgue
> > ---
> > tests/gem_exec_params.c |
On Wed, May 07, 2014 at 12:40:53AM +0300, Abdiel Janulgue wrote:
> Add test that makes sure RS bit only gets executed on BDW and
> on the render ring.
>
> Signed-off-by: Abdiel Janulgue
> ---
> tests/gem_exec_params.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/tests
On Wednesday, May 07, 2014 12:38:04 AM Ville Syrjälä wrote:
> On Tue, May 06, 2014 at 10:48:02PM +0300, Abdiel Janulgue wrote:
> > Use on-chip hw-binding table generator to generate binding
> > tables when the test emits SURFACE_STATES packets. The hw generates
> > these binding table packets inter
Add test that makes sure RS bit only gets executed on BDW and
on the render ring.
Signed-off-by: Abdiel Janulgue
---
tests/gem_exec_params.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/gem_exec_params.c b/tests/gem_exec_params.c
index 769969d..a3f765b 100644
--- a/te
On Tue, May 06, 2014 at 10:48:02PM +0300, Abdiel Janulgue wrote:
> Use on-chip hw-binding table generator to generate binding
> tables when the test emits SURFACE_STATES packets. The hw generates
> these binding table packets internally so we don't have to
> allocate space on the batchbuffer.
>
>
On Tue, May 06, 2014 at 10:25:06PM +0300, Abdiel Janulgue wrote:
> Ensures that the batch buffer is executed by the resource streamer
>
> Signed-off-by: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c |8
> include/uapi/drm/i915_drm.h|7 ++-
On Tue, May 06, 2014 at 10:48:01PM +0300, Abdiel Janulgue wrote:
> This patchseries tests a resource streamer feature called hw-generated
> binding tables,
> which can be enabled from userspace. It is essentially a newer format that
> uses the hw to
> generate and submit binding tables to the GPU
On Tue, May 06, 2014 at 10:04:17PM +0200, Knut Petersen wrote:
> On 06.05.2014 20:59, Daniel Vetter wrote:
> >On Tue, May 06, 2014 at 04:30:45PM +0300, Jani Nikula wrote:
> >>On Tue, 06 May 2014, Knut Petersen wrote:
> >>>On 28.04.2014 15:26, Daniel Vetter wrote:
> >>>The patch below is a clear ca
On Tue, 2014-05-06 at 21:27 +0200, Daniel Vetter wrote:
> On Tue, May 06, 2014 at 05:46:01PM +0300, Imre Deak wrote:
> > On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote:
> > > On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
> > > > On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wr
On 06.05.2014 20:59, Daniel Vetter wrote:
On Tue, May 06, 2014 at 04:30:45PM +0300, Jani Nikula wrote:
On Tue, 06 May 2014, Knut Petersen wrote:
On 28.04.2014 15:26, Daniel Vetter wrote:
The patch below is a clear candidate for 3.15 as it fixes a regression
introduced after 3.14
Egbert Eich
Use on-chip hw-binding table generator to generate binding
tables when the test emits SURFACE_STATES packets. The hw generates
these binding table packets internally so we don't have to
allocate space on the batchbuffer.
Signed-off-by: Abdiel Janulgue
---
lib/gen8_render.h | 13 +++
Add option in basic test for the render_copy to test and toggle
hw-generated binding tables feature.
Signed-off-by: Abdiel Janulgue
---
tests/gem_render_copy.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/gem_render_copy.c b/tests/gem_render_copy.c
index 33
This patchseries tests a resource streamer feature called hw-generated binding
tables,
which can be enabled from userspace. It is essentially a newer format that uses
the hw to
generate and submit binding tables to the GPU. It uses the basic rendercopy
test to toggle
the feature on and off and t
On Mon, Apr 14, 2014 at 08:41:30PM +0300, Imre Deak wrote:
> Signed-off-by: Imre Deak
Ok, pulled it all in. Thanks for patches&review.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> [ I managed to leave out this last one, so sending
On Fri, Apr 25, 2014 at 07:14:42PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 25, 2014 at 05:28:00PM +0300, Imre Deak wrote:
> > In recent dmesg logs reported for unrelated issues I noticed some power
> > domain WARNs caused by the following.
> >
> > The workaround
> >
> > commit ce352550327b394f3
On Tue, May 06, 2014 at 05:46:01PM +0300, Imre Deak wrote:
> On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote:
> > On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
> > > On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
> > > > On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak
From: Abdiel Janulgue
This is a re-spin of my resource streamer patchset from October
adapted to enable the feature on Broadwell instead.
The resource streamer is a hw-feature that helps in reducing commands
being submitted by the CPU. Haswell initially has this feature.
Unfortunately, HSW seems
Ensures that the batch buffer is executed by the resource streamer
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |8
include/uapi/drm/i915_drm.h|7 ++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/
Adds support for executing the resource streamer on BDW
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff
On Fri, May 02, 2014 at 11:35:51AM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Due to Pipe C DPINVGTT has more bits on CHV.
>
> v2: Fix comment to say VLV/CHV (Rafael)
>
> Reviewed-by: Rafael Barbalho
> Signed-off-by: Ville Syrjälä
Merged up to this one to dinq.
-Da
On Wed, Apr 09, 2014 at 01:28:02PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Rafael Barbalho
>
> Page table updates were getting stuck in the CPU cache on chv causing
> spurious page faults and strange behaviour.
>
> Signed-off-by: Rafael Barbalho
> [vsyrjala: Add !HAS_LLC checks]
> S
On Tue, May 06, 2014 at 04:30:45PM +0300, Jani Nikula wrote:
> On Tue, 06 May 2014, Knut Petersen wrote:
> > On 28.04.2014 15:26, Daniel Vetter wrote:
> > The patch below is a clear candidate for 3.15 as it fixes a regression
> > introduced after 3.14
> >> Egbert Eich (1):
> >>drm/i915/SD
On 05/06/2014 08:26:15 AM, Yang, Rong R wrote:
> Hi,
>
> I am developing the HSW’s OCL driver in the linux. I encounter a LRI
> problem on HSW.
>
>
> Some gpgpu's applications, which use the shared local memory, must load
> the L3CTRLREG2 and L3CTRLREG3 registers to allocate the SLM in the L3
>
sourab.gu...@intel.com writes:
> From: Sourab Gupta
>
> This patch is in continuation of and is dependent on earlier patch
> series to 'reduce the time for which device mutex is kept locked'.
> (http://lists.freedesktop.org/archives/intel-gfx/2014-May/044596.html)
One of userspace's assumptions
On Tue, 06 May 2014, Damien Lespiau wrote:
> On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
>> From: Paulo Zanoni
>>
>> Even if the panel claims it can support 4 lanes, there's the
>> possibility that the HW can't, so consider this while selecting the
>> max lane count.
>>
>> Sign
On Tue, May 06, 2014 at 07:04:21PM +0300, Jani Nikula wrote:
> On Tue, 06 May 2014, Damien Lespiau wrote:
> > On Tue, May 06, 2014 at 02:27:23PM +0300, Jani Nikula wrote:
> >> All the somewhat recent VBT specs and the kernel have different format
> >> for the eDP block than what the tool decodes.
On Tue, 06 May 2014, Damien Lespiau wrote:
> On Tue, May 06, 2014 at 02:27:23PM +0300, Jani Nikula wrote:
>> All the somewhat recent VBT specs and the kernel have different format
>> for the eDP block than what the tool decodes. What the tool does *may*
>> be correct for really old VBT, but I have
On Tue, May 06, 2014 at 02:27:23PM +0300, Jani Nikula wrote:
> All the somewhat recent VBT specs and the kernel have different format
> for the eDP block than what the tool decodes. What the tool does *may*
> be correct for really old VBT, but I have no specs or other reference to
> suppor this. Ju
Chris Wilson writes:
> Why does this work? It is neither the most minimal batch, nor the
> maximal. Which state is truly required? It looks like cargo-culted
> Chinese.
These are just stripped down version of rendercopy for each gen.
What I would guess would be the key to understanding the issu
On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote:
> On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
> > On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
> > > On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
> > > > Currently user space can access GEM buffers mapped
Chris Wilson writes:
> On Tue, May 06, 2014 at 04:26:05PM +0300, Mika Kuoppala wrote:
>> HW guys say that it is not a cool idea to let device
>> go into rc6 without proper 3d pipeline state.
>
> * shrug
>
> What's improper 3d state and what prevents userspace from triggering
> badness later?
I w
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with empty states.
v2: - No need to vmap (Chris Wilson)
-
On Tue, May 06, 2014 at 02:56:52PM +0300, Jani Nikula wrote:
> Most likely the minimums for both should be enough for enabling the
> native resolution on the eDP, and we'll end up using the predetermined
> optimal link config for the panel.
>
> v2: Add debug prints.
>
> Bugzilla: https://bugs.fre
Why does this work? It is neither the most minimal batch, nor the
maximal. Which state is truly required? It looks like cargo-culted
Chinese.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesk
On Tue, May 06, 2014 at 04:26:05PM +0300, Mika Kuoppala wrote:
> HW guys say that it is not a cool idea to let device
> go into rc6 without proper 3d pipeline state.
* shrug
What's improper 3d state and what prevents userspace from triggering
badness later?
The only problem I see in the patch is
On Tue, May 06, 2014 at 02:56:51PM +0300, Jani Nikula wrote:
> Use defines, do not set anything if VBT has values unknown to us.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesk
On Tue, May 06, 2014 at 02:34:41PM +0100, Damien Lespiau wrote:
> On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
> > From: Paulo Zanoni
> >
> > Even if the panel claims it can support 4 lanes, there's the
> > possibility that the HW can't, so consider this while selecting the
> > ma
On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
> From: Paulo Zanoni
>
> Even if the panel claims it can support 4 lanes, there's the
> possibility that the HW can't, so consider this while selecting the
> max lane count.
>
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Jani Nikula
Ben Widawsky writes:
> On Tue, Apr 22, 2014 at 08:19:43PM +0300, Mika Kuoppala wrote:
>> HW guys say that it is not a cool idea to let device
>> go into rc6 without proper 3d pipeline state.
>>
>> For each new uninitialized context, generate a
>> valid null render state to be run on context
>> c
On Tue, 06 May 2014, Knut Petersen wrote:
> On 28.04.2014 15:26, Daniel Vetter wrote:
> The patch below is a clear candidate for 3.15 as it fixes a regression
> introduced after 3.14
>> Egbert Eich (1):
>>drm/i915/SDVO: For sysfs link put directory and target in correct
>> order
>
Danie
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with empty states.
v2: - No need to vmap (Chris Wilson)
-
These are generated with intel-gpu-tools/tools/null_state_gen
v2: Don't use header file for states (Daniel Vetter)
Tested-by: Kristen Carlson Accardi (v1)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_renderstate_gen6.c | 281 ++-
drivers/gpu/drm/i915/intel_rendersta
Hi,
V2 series of the render state initialization patches.
I decided not to pursue the copying of the context object as the ctx
is quite big, atleast on bdw. As discussed in irc, the copying
could be done with blitter, on context creation time. But even then we would
need to wait for it to comple
On Tue, May 06, 2014 at 12:59:37PM +, Gupta, Sourab wrote:
> On Tue, 2014-05-06 at 11:34 +, Chris Wilson wrote:
> > On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gu...@intel.com wrote:
> > > From: Sourab Gupta
> > >
> > > This patch is in continuation of and is dependent on earlier pat
On 28.04.2014 15:26, Daniel Vetter wrote:
Hi Dave,
drm-intel-next-2014-04-16:
- vlv infoframe fixes from Jesse
- dsi/mipi fixes from Shobhit
- gen8 pageflip fixes for LRI/SRM from Damien
- cmd parser fixes from Brad Volkin
- some prep patches for CHV, DRRS, ...
- and tons of little things all ov
On Tue, 2014-05-06 at 11:34 +, Chris Wilson wrote:
> On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > This patch is in continuation of and is dependent on earlier patch
> > series to 'reduce the time for which device mutex is kept locked'.
On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
> From: Paulo Zanoni
>
> Even if the panel claims it can support 4 lanes, there's the
> possibility that the HW can't, so consider this while selecting the
> max lane count.
>
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Jani Nikula
On Tue, May 06, 2014 at 09:57:01AM +0300, Jani Nikula wrote:
>
> Greg, ping? Can we go with this?
I still have over 700 emails pending for the stable releases, I'm
working my way through the patches that were sent to me the "simple" way
(i.e. through the cc: tag on them), before I get to the rest
On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
> On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
> > On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
> > > Currently user space can access GEM buffers mapped to GTT through
> > > existing mappings concurrently while the p
Most likely the minimums for both should be enough for enabling the
native resolution on the eDP, and we'll end up using the predetermined
optimal link config for the panel.
v2: Add debug prints.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73539
Tested-by: Markus Blank-Burian
Signed-o
Use defines, do not set anything if VBT has values unknown to us.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 52 ---
1 file changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i9
From: Paulo Zanoni
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while selecting the
max lane count.
Signed-off-by: Paulo Zanoni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 file chan
On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
> On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
> > Currently user space can access GEM buffers mapped to GTT through
> > existing mappings concurrently while the platform specific suspend
> > handlers are running. Since these han
On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
> Currently user space can access GEM buffers mapped to GTT through
> existing mappings concurrently while the platform specific suspend
> handlers are running. Since these handlers may change the HW state in a
> way that would break such
On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gu...@intel.com wrote:
> From: Sourab Gupta
>
> This patch is in continuation of and is dependent on earlier patch
> series to 'reduce the time for which device mutex is kept locked'.
> (http://lists.freedesktop.org/archives/intel-gfx/2014-May/0445
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers.
Suggest
All the somewhat recent VBT specs and the kernel have different format
for the eDP block than what the tool decodes. What the tool does *may*
be correct for really old VBT, but I have no specs or other reference to
suppor this. Just do what the kernel does, that's what we're interested
in anyway.
From: Sourab Gupta
This patch is in continuation of and is dependent on earlier patch
series to 'reduce the time for which device mutex is kept locked'.
(http://lists.freedesktop.org/archives/intel-gfx/2014-May/044596.html)
This patch aims to reduce the allocation time of pages from shmem
by usi
Hi Dave -
Some more i915 fixes. There's still some DP issues we are looking into,
but wanted to get these moving.
BR,
Jani.
The following changes since commit 78f2975eec9faff353a6194e854d3d39907bab68:
drm/i915: Move all ring resets before setting the HWS page (2014-04-25
16:01:14 +0300)
Hi all,
New -testing cycle with cool stuff:
- ring init improvements (Chris)
- vebox2 support (Zhao Yakui)
- more prep work for runtime pm on Baytrail (Imre)
- eDram support for BDW (Ben)
- prep work for userptr support (Chris)
- first parts of the encoder->mode_set callback removal (Daniel)
- 64b
Hi,
I am developing the HSW's OCL driver in the linux. I encounter a LRI problem on
HSW.
Some gpgpu's applications, which use the shared local memory, must load the
L3CTRLREG2 and L3CTRLREG3 registers to allocate the SLM in the L3 cache.
So I add L3CTRLREG2 and L3CTRLREG3 to the gen7_render_reg
On Tue, May 6, 2014 at 8:03 AM, Jani Nikula wrote:
>> Ubuntu kernel version bisect revealed:
>>
>> First bad Ubuntu kernel: 3.11.0-0.2
>>
>> last good Ubuntu kernel: 3.10.0-6.17
>
> A bisect result on upstream kernel pointing at the regression might be
> useful... although we've changed the code c
76 matches
Mail list logo
