On Thu, Jul 09, 2015 at 07:29:01PM +0100, Dave Gordon wrote:
> This patch series enables command submission via the GuC. In this mode,
> instead of the host CPU driving the execlist port directly, it hands
> over work items to the GuC, using a doorbell mechanism to tell the GuC
> that new items hav
On Thu, Jul 09, 2015 at 07:29:06PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> The new node provides access to the status of the GuC-specific loader;
> also the scratch registers used for communication between the i915
> driver and the GuC firmware.
>
> v2:
> Changes to output formats per
On Thu, Jul 09, 2015 at 07:29:04PM +0100, Dave Gordon wrote:
> intel_guc_fwif.h contains the subset of the GuC interface that we
> will need for submission of commands through the GuC. These MUST
> be kept in sync with the definitions used by the GuC firmware, and
> updates to this file will (or sh
On Thu, Jul 09, 2015 at 07:29:03PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> Two new module parameters: "enable_guc_submission" which will turn
> on submission of batchbuffers via the GuC (when implemented), and
> "guc_log_level" which controls the level of debugging logged by the
> GuC and
On Thu, Jul 09, 2015 at 07:29:02PM +0100, Dave Gordon wrote:
> i915_gem_object_create_from_data() is a generic function to save data
> from a plain linear buffer in a new pageable gem object that can later
> be accessed by the CPU and/or GPU.
>
> We will need this for the microcontroller firmware
On Thu, Jul 09, 2015 at 07:29:05PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> This fetches the required firmware image from the filesystem,
> then loads it into the GuC's memory via a dedicated DMA engine.
>
> This patch is derived from GuC loading work originally done by
> Vinit Azad and Be
On Fri, 2015-07-17 at 13:47 +0530, Sonika Jindal wrote:
> As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
> and interrupts to check the external panel connection and DDIC HPD
> logic for edp panel.
>
> v2: For DP, irq_port is used to determine the encoder instead of
> hpd_pin and r
Hi all,
New -testing cycle with cool stuff:
- prelim hw support dropped for skl after Damien fixed an ABI issue around
planes
- legacy modesetting is done using atomic infrastructure now (Maarten)!
- more gen9 workarounds (Arun&Nick)
- MOCS programming (cache control for better performance) for
On Fri, Jul 17, 2015 at 07:13:32PM +0100, Arun Siluvery wrote:
> The Golden batch carries 3D state at the beginning so that HW starts with
> a known state. It is carried as a binary blob which is auto-generated from
> source. The idea was it would be easier to maintain and keep the complexity
> out
On 17/07/2015 19:13, Arun Siluvery wrote:
User space clients need to know when the pooled EU feature is present
and enabled on the hardware so that they can adapt work submissions.
Create a new device info flag for this purpose, and create a new GETPARAM
entry to allow user space to query its set
This mode allows to assign EUs to pools which can process work collectively.
The command to enable this mode should be issued as part of context
initialization.
The pooled mode is global, once enabled it has to stay the same across all
contexts until HW reset hence this is sent in auxiliary golde
On Fri, Jul 17, 2015 at 07:13:34PM +0100, Arun Siluvery wrote:
> This mode allows to assign EUs to pools which can process work collectively.
> The command to enable this mode should be issued as part of context
> initialization.
>
> The pooled mode is global, once enabled it has to stay the same
v1: http://lists.freedesktop.org/archives/intel-gfx/2015-July/071951.html
v2: auxiliary batch size must be a multiple of 8, use feature flag while
enabling support and add comments to clarify various things.
Resending all patches as the order is changed.
Arun Siluvery (3):
drm/i915: Add provis
User space clients need to know when the pooled EU feature is present
and enabled on the hardware so that they can adapt work submissions.
Create a new device info flag for this purpose, and create a new GETPARAM
entry to allow user space to query its setting.
Set has_pooled_eu to true in the Brox
The Golden batch carries 3D state at the beginning so that HW starts with
a known state. It is carried as a binary blob which is auto-generated from
source. The idea was it would be easier to maintain and keep the complexity
out of the kernel which makes sense as we don't really touch it. However i
From: Mika Kuoppala
Kunmap the renderstate page on error path.
Reviewed-by: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
This mode allows to assign EUs to pools which can process work collectively.
The command to enable this mode should be issued as part of context
initialization.
The pooled mode is global, once enabled it has to stay the same across all
contexts until HW reset hence this is sent in auxiliary golde
On Fri, Jul 17, 2015 at 05:54:20PM +0100, Siluvery, Arun wrote:
> On 17/07/2015 17:27, Chris Wilson wrote:
> >On Fri, Jul 17, 2015 at 05:08:53PM +0100, Arun Siluvery wrote:
> >>This mode allows to assign EUs to pools.
> >>The command to enable this mode is sent in auxiliary golden context batch
> >
On 17/07/2015 17:27, Chris Wilson wrote:
On Fri, Jul 17, 2015 at 05:08:53PM +0100, Arun Siluvery wrote:
This mode allows to assign EUs to pools.
The command to enable this mode is sent in auxiliary golden context batch
as this is only issued once with each context initialization. Thanks to
Mika
Chris Wilson writes:
> On Fri, Jul 17, 2015 at 05:08:53PM +0100, Arun Siluvery wrote:
>> This mode allows to assign EUs to pools.
>> The command to enable this mode is sent in auxiliary golden context batch
>> as this is only issued once with each context initialization. Thanks to
>> Mika for the
On Fri, Jul 17, 2015 at 07:37:45PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Fri, Jul 17, 2015 at 05:08:52PM +0100, Arun Siluvery wrote:
> >> The Golden batch carries 3D state at the beginning so that HW starts with
> >> a known state. It is carried as a binary blob which is aut
Chris Wilson writes:
> On Fri, Jul 17, 2015 at 05:08:52PM +0100, Arun Siluvery wrote:
>> The Golden batch carries 3D state at the beginning so that HW starts with
>> a known state. It is carried as a binary blob which is auto-generated from
>> source. The idea was it would be easier to maintain a
On Fri, Jul 17, 2015 at 05:08:53PM +0100, Arun Siluvery wrote:
> This mode allows to assign EUs to pools.
> The command to enable this mode is sent in auxiliary golden context batch
> as this is only issued once with each context initialization. Thanks to
> Mika for the preliminary review.
A quick
On Fri, Jul 17, 2015 at 05:08:52PM +0100, Arun Siluvery wrote:
> The Golden batch carries 3D state at the beginning so that HW starts with
> a known state. It is carried as a binary blob which is auto-generated from
> source. The idea was it would be easier to maintain and keep the complexity
> out
User space clients need to know when the pooled EU feature is present
and enabled on the hardware so that they can adapt work submissions.
Create a new device info flag for this purpose, and create a new GETPARAM
entry to allow user space to query its setting.
Set has_pooled_eu to true in the Brox
From: Mika Kuoppala
Kunmap the renderstate page on error path.
Reviewed-by: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
This patches adds support to enable Pooled EU feature in BXT.
This series has a dependency with Patch1 from Mika hence sending it
as part of the series (already reviewed).
Patch2 - adds a framework to extend the golden context batch through
which we can add Gen based commands to enable specific f
This mode allows to assign EUs to pools.
The command to enable this mode is sent in auxiliary golden context batch
as this is only issued once with each context initialization. Thanks to
Mika for the preliminary review.
Cc: Mika Kuoppala
Cc: Chris Wilson
Cc: Armin Reese
Signed-off-by: Arun Silu
The Golden batch carries 3D state at the beginning so that HW starts with
a known state. It is carried as a binary blob which is auto-generated from
source. The idea was it would be easier to maintain and keep the complexity
out of the kernel which makes sense as we don't really touch it. However i
>
>
>-Original Message-
>From: Thomas Wood [mailto:thomas.w...@intel.com]
>Sent: Friday, July 17, 2015 3:18 PM
>To: Morton, Derek J
>Cc: Intel Graphics Development
>Subject: Re: [PATCH i-g-t v3] Android.mk: Disable tools that do not build for
>android
>
>On 17 July 2015 at 10:15, Derek Mo
On Thu, Jul 16, 2015 at 12:37:56PM +0100, Chris Wilson wrote:
> Since the hardware sometimes mysteriously totally flummoxes the 64bit
> read of a 64bit register when read using a single instruction, split the
> read into two instructions. Since the read here is of automatically
> incrementing times
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: Tvrtko Ursulin
Debug output assumes all sync points are built on top of Android sync points
and when we start creating them from dma-fences will NULL ptr deref unless
taught about this.
This is Maarten's code, just the patch had
From: Maarten Lankhorst
This allows users of dma fences to create a android fence.
v2: Added kerneldoc. (Tvrtko Ursulin).
Signed-off-by: Maarten Lankhorst
Signed-off-by: Tvrtko Ursulin
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jesse Barnes
Cc: de...@driverdev.osuosl.org
Cc: Riley Andrews
From: Tvrtko Ursulin
Debug output assumes all sync points are built on top of Android sync points
and when we start creating them from dma-fences will NULL ptr deref unless
taught about this.
Signed-off-by: Tvrtko Ursulin
Cc: Maarten Lankhorst
Cc: de...@driverdev.osuosl.org
Cc: Riley Andrews
From: John Harrison
The change to the implementation of i915_gem_request_completed() means that the
lazy coherency flag is no longer used. This can now be removed to simplify the
interface.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu
From: John Harrison
There are various parameters within the scheduler which can be tuned to improve
performance, reduce memory footprint, etc. This change adds support for altering
these via debugfs.
Change-Id: I6c26765269ae7173ff4d3a5c20921eaaca7c36ed
For: VIZ-1587
Signed-off-by: John Harrison
From: John Harrison
The scheduler has always tracked batch buffer dependencies based on
DRM object usage. This means that it will not submit a batch on one
ring that has outstanding dependencies still executing on other rings.
This is exactly the same synchronisation performed by
i915_gem_object_
From: John Harrison
Updated the execbuffer() code to pass the packaged up batch buffer information
to the scheduler rather than calling execbuffer_final() directly. The scheduler
queue() code is currently a stub which simply chains on to _final() immediately.
Change-Id: I2a19062a9e66845f2e886332
From: John Harrison
It is useful for know what the scheduler is doing for both debugging and
performance analysis purposes. This change adds a bunch of counters and such
that keep track of various scheduler operations (batches submitted, completed,
flush requests, etc.). The data can then be read
From: John Harrison
It is useful to be able to see what seqnos have actually popped out of the
hardware when viewing the scheduler status.
Change-Id: Ie93e51c64328be2606b8b43440f6344d5f225426
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 10 ++
From: John Harrison
Now that all the scheduler patches have been applied, it is safe to enable.
Change-Id: I128042e85a30fca765ce1eb46c837c62dee66089
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
From: John Harrison
One of the major purposes of the GPU scheduler is to avoid stalling the CPU when
the GPU is busy and unable to accept more work. This change adds support to the
ring submission code to allow a ring space check to be performed before
attempting to submit a batch buffer to the h
From: John Harrison
Change-Id: I720463f01c4edd3579ce52e315a85e4d7874d7e5
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 31 +++
drivers/gpu/drm/i915/i915_scheduler.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/drive
From: John Harrison
To aid with debugging issues related to the scheduler, it can be useful to
ensure that all batch buffers are submitted immediately rather than queued until
later. This change adds an override flag via the module parameter to force
instant submission.
Change-Id: I7652df53e2d3c
From: John Harrison
Hardware sempahores require seqno values to be continuously incrementing.
However, the scheduler's reordering of batch buffers means that the seqno values
going through the hardware could be out of order. Thus semaphores can not be
used.
On the other hand, the scheduler super
From: John Harrison
There is a sync framework to allow work for multiple independent
systems to be synchronised with each other but without stalling
the CPU whether in the application or the driver. This patch adds
support for this framework to the GPU scheduler.
Batch buffers can now have sync
From: John Harrison
When debugging batch buffer submission issues, it is useful to be able to see
what the current state of the scheduler is. This change adds functions for
decoding the internal scheduler state and reporting it.
Change-Id: I0634168e3f3465ff023f5a673165c90b07e535b6
For: VIZ-1587
From: John Harrison
When the seqno wraps around zero, the entire GPU is forced to be idle
for some reason (possibly only to work around issues with hardware
semaphores but no-one seems too sure!). This causes a problem if the
force idle occurs at an inopportune moment such as in the middle of
sub
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver from their
subsequent submission to the hardware. This means that an application which is
continuously submitting buffers as fast as it can could potentialy flood the
driver. To prevent this, the driver now
From: John Harrison
Added trace points to the scheduler to track all the various events, node state
transitions and other interesting things that occur.
Change-Id: I9886390cfc7897bc1faf50a104bc651d8baed8a5
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.
From: John Harrison
When there are lots and lots and even more lots of contexts (e.g. when running
with execlists) it is useful to be able to immediately see what the total
context count is.
Change-Id: If9726d4df86567100ecf53867b43f4753f08bf84
For: VIZ-1587
Signed-off-by: John Harrison
---
dri
From: John Harrison
If a high priority task was to continuously submit batch buffers to the driver,
it could starve out any lower priority task from getting any GPU time at all. To
prevent this, the priority of a queued batch buffer is bumped each time it does
not get submitted to the hardware.
From: John Harrison
A major point of the GPU scheduler is that it re-orders batch buffers after they
have been submitted to the driver. This leads to requests completing out of
order. In turn, this means that the retire processing can no longer assume that
all completed entries are at the front o
From: John Harrison
It can be useful to be able to disable certain features (e.g. the entire
scheduler) via a module parameter for debugging purposes. A parameter has the
advantage of not being a compile time switch but without implying that it can be
changed dynamically at runtime.
Change-Id: I
From: John Harrison
The scheduler can cause batch buffers, and hence requests, to be submitted to
the ring out of order and asynchronously to their submission to the driver. Thus
at the point of waiting for the completion of a given request, it is not even
guaranteed that the request has actually
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver with their
submission to the hardware. This basically means splitting the execbuffer()
function in half. This change rearranges some code ready for the split to occur.
Change-Id: Icc9c8afaac18821f3eb8a151a4
From: John Harrison
The scheduler now supports sync framework fences being associated with
batch buffers. The execbuff IOCTL allows such fences to be passed in
from user land. This patch wires the two together so that the IOCTL no
longer needs to stall on the fence immediately. Instead the stall
From: John Harrison
When the watchdog resets the GPU, the scheduler needs to know so that it can
clean up it's view of the world. All in flight nodes must be marked as dead so
that the scheduler does not wait forever for them to complete. Also, all queued
nodes must be marked as dead so that the
From: John Harrison
Change-Id: Ice071af6d88306b0d1c53bdb651a1a3e20bdc1af
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
From: Dave Gordon
Added various definitions that will be useful for the scheduler in general and
pre-emptive context switching in particular.
Change-Id: Ica805b94160426def51f5d520f5ce51c60864a98
For: VIZ-1587
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 30 +
From: John Harrison
When requesting that all GPU work is completed, it is now necessary to get the
scheduler involved in order to flush out work that queued and not yet submitted.
Change-Id: I95dcc2a2ee5c1a844748621c333994ddd6cf6a66
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/dr
From: John Harrison
The scheduler needs to track interdependencies between batch buffers. These are
calculated by analysing the object lists of the buffers and looking for
commonality. The scheduler also needs to keep those buffers locked long after
the initial IOCTL call has returned to user lan
From: John Harrison
The GPU scheduler can cause requests to complete out of order. For example,
because one request pre-empted others that had already been submitted. This
means the simple seqno comparison is not necessarily valid. Instead, a check
against what the scheduler is currently doing mu
From: John Harrison
The seqno value is now only used for the final test for completion of a request.
It is no longer used to track the request through the software stack. Thus it is
no longer necessary to allocate the seqno immediately with the request. Instead,
it can be done lazily and left unt
From: John Harrison
The scheduler needs to be informed of each batch buffer completion. This is done
via the user interrupt mechanism. The epilogue of each batch buffer submission
updates a sequence number value (seqno) and triggers a user interrupt.
This change hooks the scheduler in to the pro
From: John Harrison
The scheduler keeps its own lock on various DRM objects in order to guarantee
safe access long after the original execbuff IOCTL has completed. This is
especially important when pre-emption is enabled as the batch buffer might need
to be submitted to the hardware multiple time
From: John Harrison
Initial creation of scheduler source files. Note that this patch implements most
of the scheduler functionality but does not hook it in to the driver yet. It
also leaves the scheduler code in 'pass through' mode so that even when it is
hooked in, it will not actually do very m
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver with
submission of batch buffers to the hardware. Thus it is possible for an
application to submit work, then close the DRM handle and free up all the
resources that piece of work wishes to use before the wo
From: John Harrison
GPU page faults can now require scheduler operation in order to complete. For
example, in order to free up sufficient memory to handle the fault the handler
must wait for a batch buffer to complete that has not even been sent to the
hardware yet. Thus EAGAIN no longer means a
From: John Harrison
A later patch in this series re-organises the batch buffer submission
code. Part of that is to reduce the scope of a pm_get/put pair.
Specifically, they previously wrapped the entire submission path from
the very start to the very end, now they only wrap the actual hardware
su
From: John Harrison
Split the execbuffer() function in half. The first half collects and validates
all the information requried to process the batch buffer. It also does all the
object pinning, relocations, active list management, etc - basically anything
that must be done upfront before the IOCT
From: John Harrison
Ring space is reserved when constructing a request to ensure that the
subsequent 'add_request()' call cannot fail due to waiting for space
on a busy or broken GPU. However, the scheduler jumps in to the middle
of the execbuffer process between request creation and request
subm
From: John Harrison
Implemented a batch buffer submission scheduler for the i915 DRM driver.
The general theory of operation is that when batch buffers are submitted to the
driver, the execbuffer() code assigns a unique seqno value and then packages up
all the information required to execute the
From: John Harrison
The seqno value cannot always be used when debugging issues via trace
points. This is because it can be reset back to start, especially
during TDR type tests. Also, when the scheduler arrives the seqno is
only valid while a given request is executing on the hardware. While
the
From: John Harrison
The scheduler needs to do interrupt triggered work that is too complex to do in
the interrupt handler. Thus it requires a deferred work handler to process this
work asynchronously.
Change-Id: I0f7cc2b6f034a50bf8f7e368b60ad8bafd00f993
For: VIZ-1587
Signed-off-by: John Harrison
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware. I.e. it solves the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to address. The
request structure does quite a lot more
From: John Harrison
Various projects desire a mechanism for managing dependencies between
work items asynchronously. This can also include work items across
complete different and independent systems. For example, an
application wants to retreive a frame from a video in device,
using it for rende
From: John Harrison
Added the '_complete' trace event which occurs when a fence/request is signaled
as complete. Also moved the notify event from the IRQ handler code to inside the
notify function itself.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
From: John Harrison
The fence object used inside the request structure requires a sequence number.
Although this is not used by the i915 driver itself, it could potentially be
used by non-i915 code if the fence is passed outside of the driver. This is the
intention as it allows external kernel dr
From: John Harrison
The intended usage model for struct fence is that the signalled status should be
set on demand rather than polled. That is, there should not be a need for a
'signaled' function to be called everytime the status is queried. Instead,
'something' should be done to enable a signal
From: John Harrison
The request structure is reference counted. When the count reached
zero, the request was immediately freed and all associated objects
were unrefereced/unallocated. This meant that the driver mutex lock
must be held at the point where the count reaches zero. This was fine
while
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware. I.e. it solves the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to address. The
request structure does quite a lot more
On 17 July 2015 at 10:15, Derek Morton wrote:
> Disable the tools / demo code that do not currently build
> for android until they can be fixed.
>
> Affected tools / demos
> intel_display_crc
> intel_sprite_on
>
> v2: intel_display_crc compiled conditionally on ANDROID_HAS_CAIRO
> flag.
> v3: remo
GEN >= 9 supports YUV format for all planes, but it's not exported in
Capability list of primary plane. Add YUV formats in skl_primary_formats
list.
Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not
filling bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide
On 17 July 2015 at 09:34, Nabendu Maiti wrote:
> 1) Added more overlay plane support for BXT.
> 2) Added and enhanced scaler test cases for additional planes.
Please split the various separate changes in different patches.
The i-g-t tag should also appear in the subject prefix rather than the
su
This patches rearrange gpgpu fill library functions and add support for BDW and
SKL.
Dominik Zeromski (3):
lib: Move gpgpu_fill code to separate file
lib/gpgpu_fill: Add BDW support
lib/gpgpu_fill: Add SKL support
lib/Makefile.sources | 4 +-
lib/gpgpu_fill.c | 808 +
BDW changed structure of surface state and interface descriptors.
Commands like state base address, gpgpu walker were extended.
Cc: Thomas Wood
Signed-off-by: Dominik Zeromski
---
lib/gpgpu_fill.c| 296 +++-
lib/gpgpu_fill.h| 7 ++
l
SKL changed state base address command.
Cc: Thomas Wood
Signed-off-by: Dominik Zeromski
---
lib/gpgpu_fill.c| 102
lib/gpgpu_fill.h| 7
lib/intel_batchbuffer.c | 2 +
3 files changed, 111 insertions(+)
diff --git a/lib/g
The gpgpu fill utility functions are used in separate test so it's
logical to keep them in separate file. This is similar to what media
spin test did in the past.
Functionally only gpgpu kernel changed. Send instruction payload size
was reduced. Since offset is incremented by 0x10 bytes there is n
Disable the tools / demo code that do not currently build
for android until they can be fixed.
Affected tools / demos
intel_display_crc
intel_sprite_on
v2: intel_display_crc compiled conditionally on ANDROID_HAS_CAIRO
flag.
v3: removed intel_reg from the skip list as Thomas has prepared
a patch t
>
>
>-Original Message-
>From: Morton, Derek J
>Sent: Friday, July 17, 2015 9:44 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Wood, Thomas; Morton, Derek J
>Subject: [PATCH i-g-t v3] Android.mk: Disable tools that do not build for
>android
>
>Disable the tools / demo code that do not curr
Disable the tools / demo code that do not currently build
for android until they can be fixed.
Affected tools / demos
intel_display_crc
intel_sprite_on
v2: intel_display_crc compiled conditionally on ANDROID_HAS_CAIRO
flag.
v3: removed intel_reg from the skip list as Thomas has prepared
a patch t
On 07/16/2015 05:18 PM, Michel Thierry wrote:
Commit c44ef60e4370 ("drm/i915/gtt: Allow >= 4GB sizes for vm.") took care
of most of this changes, but i915_gem_obj_offset still returned an unsigned
long, which in only 4-bytes long in 32-bit kernels.
Change return type (and other related offset v
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.
v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
S
1) Added more overlay plane support for BXT.
2) Added and enhanced scaler test cases for additional planes.
Signed-off-by: Nabendu Maiti
---
lib/igt_fb.c | 40
lib/igt_fb.h | 1 +
lib/igt_kms.c | 1 +
lib/igt_kms.h | 3
On Thu, Jul 16, 2015 at 01:43:15PM -0300, Paulo Zanoni wrote:
> 2015-07-16 13:36 GMT-03:00 Mika Kuoppala :
> > Fix divide by zero if we end up updating the watermarks
> > with zero dotclock.
> >
> > This is a stop gap measure to allow module load in cases
> > where our state keeping fails.
> >
> >
On Thu, Jul 16, 2015 at 05:08:09PM +0100, Damien Lespiau wrote:
> Time to light a candle and remove the preliminary_hw_support flag.
>
> Signed-off-by: Damien Lespiau
Both applied to dinq, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> dif
97 matches
Mail list logo
