Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
On Wed, 2014-12-10 at 08:55 -0700, Dave Gordon wrote:
> On 10/12/14 09:11, Daniel Vetter wrote:
> > On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
> >> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
> >>> On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
>
> [s
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
On 11/12/2014 01:33, Tian, Kevin wrote:
> My point is that KVMGT doesn't introduce new requirements as what's
> required in IGD passthrough case, because all the hacks you see now
> is to satisfy guest graphics driver's expectation. I haven't follow up the
> KVM IGD passthrough progress, but if i
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, December 11, 2014 12:59 AM
>
> On 09/12/2014 03:49, Tian, Kevin wrote:
> > - Now we have XenGT/KVMGT separately maintained, and KVMGT lags
> > behind XenGT regarding to features and qualities. Likely you'll continue
> > see stale
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 364/364 3
Adds a function to check the status of a Displayport connector. This function
simplifies the Displayport compliance testing interface in debugfs by providing
a single method for determining the status of a connector during Displayport
compliance testing. This function checks whether or not the conn
Adds provisions in intel_dp_compute_config() to accommodate compliance
testing. Mostly this invovles circumventing the automatic link configuration
parameters and allowing the compliance code to set those parameters as
required by the tests.
Signed-off-by: Todd Previte
---
drivers/gpu/drm/i915/i
Adds and implements the 'write' function for the debugfs i915_dp_test_ctrl file.
Also adds in the required parsing function to read in the data from the file
once the user app has written its data to it.
Signed-off-by: Todd Previte
---
drivers/gpu/drm/i915/i915_debugfs.c | 103 ++
Moves the non-MST case out of the if-statement and places it at the beginning
of the function to handle HPD events for SST mode. The reasoning behind this
is to accommodate link status checks for compliance testing. Some test devices
use long pulses to perform test requests so link status must be c
Updates displayport_config_ctl_write and displayport_config_ctl_show to
use the dp_connector_is_valid() function. This saves on code and improves
maintainability by unifying the code in a single, common path.
Signed-off-by: Todd Previte
---
drivers/gpu/drm/i915/i915_debugfs.c | 42 +-
Adds a new file for controlling Displayport compliance testing via the debugfs
interface. Adds two functions, 'open' and 'show', as well as the file operations
structure to support reading the file from userspace. The new file is called
'i915_dp_test_ctl' and contains 4 fields:
- Connector name
Updates the EDID compliance test function to perform the EDID read as
required by the tests. This read needs to take place in the kernel for
reasons of speed and efficiency. The results of the EDID read are handed
off to userspace so that the remainder of the test can be conducted there.
V2:
- Add
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure (no response /
invalid response) must have a minimum delay of 400us before the resend can
occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.
This patch was previously part of "[PATCH 07/10] drm/i915: Add structures for
Displayport compliance testing parameters". Adds a struct to maintain link
configuration data for Displayport compliance testing. The members added to
the intel_dp struct are for compliance testing purposes only and shoul
This patch was part of "[PATCH 05/10] drm/i915: Add debugfs interface for
Displayport debug and compliance testing". That patch has been split into
smaller patches for ease of review and integration.
This patch contains the definitions/declarations for some of the constants
and data structures add
This patch is a combination of sections out of the following two previous
patches:
[PATCH 05/10] drm/i915: Add debugfs interface for Displayport debug and
compliance testing
[PATCH 07/10] drm/i915: Add structures for Displayport compliance testing
parameters
This patch implements the debugfs funct
This patch was previously part of "[PATCH 05/10] drm/i915: Add debugfs interface
for Displayport debug and compliance testing". Adds two support functions for
handling Displayport configuration parameters that are used for compliance
testing.
Signed-off-by: Todd Previte
---
drivers/gpu/drm/i915
This patch was also part of "[PATCH 05/10] drm/i915: Add debugfs interface
for Displayport debug and compliance testing". Adds file operations structures
for Displayport configuration in debugfs for compliance testing. Also adds
the declarations for the open() and write() functions listed in the fi
This patch was previously part of "[PATCH 05/10] drm/i915: Add debugfs
interface for Displayport debug and compliance testing". This patch implements
the 'show' functions for the debugfs interface for Displayport compliance
testing.
Signed-off-by: Todd Previte
---
drivers/gpu/drm/i915/i915_debug
Move the DPCD read to the top and check for an interrupt from the sink to catch
Displayport automated testing requests necessary to support Displayport
compliance
testing. The checks for active connectors and link status are moved below the
check for the interrupt.
Adds a check at the top to veri
This patch was previously part of "[PATCH 05/10] drm/i915: Add debugfs
interface for Displayport debug and compliance testing". This patch adds two
functions to handle parsing of Displayport configuration information as it
formatted in the debugfs file. It is used to process incoming configuration
Add the skeleton framework for supporting automation for Displayport compliance
testing. This patch adds the necessary framework for the source device to
appropriately respond to test automation requests from a sink device.
V2:
- Addressed previous mailing list feedback
- Fixed compilation issue (
This is version 2 of the patch set for Displayport compliance testing support
in the i915 driver. This implementation of compliance testing conforms to the
VESA specification Displayport Link Compliance Testing Specification (Link CTS)
1.2 Core Rev1.1. The code has been partitioned into two segme
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 364/364 3
Should address a warning reported in #79824.
References: https://bugs.freedesktop.org/show_bug.cgi?id=79824
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
On Wed, 10 Dec 2014 22:35:37 +0200
Ville Syrjälä wrote:
> On Wed, Dec 10, 2014 at 12:16:05PM -0800, Jesse Barnes wrote:
> > Should probably just init this in the GMbus code all the time,
> > based on the cdclk and HPLL like we do on newer platforms. Ville
> > has code for that in a rework branch
From: Durgadoss R
This patch enables eDP DRRS for CHV by adding the
required IS_CHERRYVIEW() checks.
CHV uses the same register bit as VLV.
[Vandana]: Since CHV has 2 sets of M_N registers, it will follow the same code
path as gen < 8. Added CHV check in dp_set_m_n()
Signed-off-by: Durgadoss R
Add DRRS work function to trigger a switch to low refresh rate when activity
is detected on screen.
Signed-off-by: Vandana Kannan
---
drivers/gpu/drm/i915/intel_dp.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
On Wed, Dec 10, 2014 at 12:16:05PM -0800, Jesse Barnes wrote:
> Should probably just init this in the GMbus code all the time, based on
> the cdclk and HPLL like we do on newer platforms. Ville has code for
> that in a rework branch, but until then we can fix this bug fairly
> easily.
>
> Referen
Earlier, DRRS structures were specific to eDP (used only in intel_dp).
Since DRRS can be extended to other internal display types
(if the panel supports multiple RR), modifying structures
to be part of drm_i915_private and have a provision to add display related
structs like intel_dp.
Also, alignin
Adding i915 module parameter for setting drrs_interval. If this param is
set to 0, then drrs is disabled. If changed in runtime, then the new interval
value will be considered for scheduling the next drrs work.
drrs_interval is set to 0 by default, i.e. DRRS is disabled by default.
Signed-off-by:
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next fram
Definition of VLV RR switch bit and corresponding toggling in
set_drrs function.
Signed-off-by: Vandana Kannan
Signed-off-by: Uma Shankar
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 10 --
2 files changed, 9 insertions(+), 2 de
Calls have been added to invalidate/flush DRRS whenever invalidate/flush is
called as part of frontbuffer tracking.
Apart from calls as a result of GEM tracking to fb invalidate/flush, a
call has been added to invalidate fb obj from crtc_page_flip as well. This
is to track busyness through flip cal
Calling enable/disable DRRS when enable/disable DDI are called.
These functions are responsible for setup of drrs data (in enable) and
reset of drrs (in disable).
has_drrs is true when downclock_mode is found and SEAMLESS_DRRS is set in
the VBT. A check has been added for has_drrs in these function
This patch series inserts DRRS into frontbuffer tracking mechanism.
1. Previous submission for this feature was designed considering only eDP
DRRS. In this series, apart from following fb tracking, changes have been made
to make structures generic so that it can be of use to any other code
additio
Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms. Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.
References: https://bugs.freedesktop.org/show_bug.cgi?id=76301
Signed-off-by: Jes
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 364/364 3
Add a function to lock memory into RAM and use it in the
gem_tiled_swapping test to reduce the amount of allocated memory
required to force swapping. This also reduces the amount of time
required for the test to complete, since the data set is smaller.
The following durations were recorded on a ha
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
When querying the GTFIFOCTL register to check the FIFO space, the read value
must be masked. The operation is repeated explicitly in several places. This
change refactors the read-and-mask code into a function call.
v2: rebased on top of Mika's forcewake patch set, specifically:
[PATCH 8/8
On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
> irq_mask should include all IRQ bits that we want to mask, but atm we
> set it incorrectly to the inverse of this. If the mask is used
> subsequently to enable/disable some IRQ bits, we may unintentionally
> unmask unrelated IRQs. I can't
From: Tvrtko Ursulin
This series continues what was previously a single patch called "drm/i915:
Infrastructure for supporting different GGTT views per object".
v2:
* One less patch due early prep work getting merged.
* Main patch reworked to keep the pages pointer around for the lifetime of th
From: Tvrtko Ursulin
A short section describing background, implementation and intended usage.
v2:
* Align section name between template and DOC comment. (Michel Thierry)
For: VIZ-4544
Signed-off-by: Tvrtko Ursulin
---
Documentation/DocBook/drm.tmpl | 5
drivers/gpu/drm/i915/i9
From: Tvrtko Ursulin
Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.
Added a GGTT view concept and linked it with the VMA to distinguish between
multiple instances per address space.
New objects and GEM functi
v2: add an "application" filter for the default domain (used by
applications)
Signed-off-by: Thomas Wood
---
docs/reference/intel-gpu-tools/igt_test_programs.xml | 6 --
lib/igt_core.c | 17 +++--
2 files changed, 19 insertions(+), 4 del
Log domains can be used to identify the source of log messages, such as
the test being run or the helper library.
v2: Add separate domains for different parts of the helper library and
use an empty default domain for applications.
Expand the log output to include the process name and the l
On 10/12/14 10:42, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:08PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon
>>
>> There is a workaround for a hardware bug when reading the seqno from the
>> status
>> page. The bug does not exist on VLV however, the workaround was sti
On Wed, Dec 10, 2014 at 04:33:14PM +, Dave Gordon wrote:
> On 10/12/14 10:58, Daniel Vetter wrote:
> > On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
> >> From: John Harrison
> >>
> >> The scheduler decouples the submission of batch buffers to the driver with
> >>
On Thu, Dec 11, 2014 at 09:42:49PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> According to updated BSpec, Render/Common/media Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
>
> v2: Update media forcewake
On 12/10/2014 08:41 AM, Bloomfield, Jon wrote:
why do we take the batch_pool lock in i915_gem_batch_pool_info() ?
i915_gem_batch_pool_info() is a new debugfs entry while
print_batch_pool_stats() is just an internal fnc, called from the
debugfs entry i915_gem_object_info(). i915_gem_object_inf
On Wed, Dec 10, 2014 at 10:07:40PM +0530, Gaurav K Singh wrote:
> From now on for both DSI Ports A & C, the seq_port value has been
> set to 0. seq_port value is parsed from Sequence block#53 of VBT.
> So, for packets that needs to be read/write for DSI single link on
> Port A and Port C will now b
On 09/12/2014 03:49, Tian, Kevin wrote:
> - Now we have XenGT/KVMGT separately maintained, and KVMGT lags
> behind XenGT regarding to features and qualities. Likely you'll continue
> see stale code (like Xen inst decoder) for some time. In the future we
> plan to maintain a single kernel repo for
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, December 10, 2014 4:44 PM
> To: Intel Graphics Development
> Cc: Daniel Vetter; Daniel, Thomas; Vetter, Daniel
> Subject: [PATCH] drm/i915: Call the lrc irq handler correctly
>
> We consistently u
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
From now on for both DSI Ports A & C, the seq_port value has been
set to 0. seq_port value is parsed from Sequence block#53 of VBT.
So, for packets that needs to be read/write for DSI single link on
Port A and Port C will now be based on the DVO port from VBT block 2,
instead of seq_port.
Signed-o
> -Original Message-
> From: Nguyen, Michael H
> Sent: Wednesday, December 10, 2014 4:34 PM
> To: Bloomfield, Jon
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for
> batch buffer pools
>
> Hi Jon,
>
> On 12/1
We consistently use the _irq_handler postfix for functions called in
hardirq context. Especially when it's a non-static function hardirq is
a crazy enough calling context to warrant this level of ocd. So rename
it.
Cc: Thomas Daniel
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq
On 10/12/14 10:40, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:06PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon
>>
>> Added various definitions that will be useful for the scheduler in general
>> and
>> pre-emptive context switching in particular.
>>
>> Change-Id: Ica805
Hi Jon,
On 12/10/2014 03:06 AM, Bloomfield, Jon wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel Vetter
Sent: Tuesday, December 09, 2014 1:18 PM
To: Nguyen, Michael H
Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
Subject: R
On 10/12/14 10:58, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
>> 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 e
On 2014-12-04 03:24, Jike Song wrote:
> Hi all,
>
> We are pleased to announce the first release of KVMGT project. KVMGT is
> the implementation of Intel GVT-g technology, a full GPU virtualization
> solution. Under Intel GVT-g, a virtual GPU instance is maintained for
> each VM, with part of per
hey,
i have a dell xps 13 with an integrated intel adapter running on kubuntu
14.10, and a club3d csv5300 displayport hub with two attached dell displays.
i am currently using the 3.18 kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/
the problem is that the displays attache
On Wed, Nov 12, 2014 at 10:53:22AM +, Nick Hoath wrote:
> This patchset merges execlist queue items in to gem requests. It does this by
> using the reference count added by John Harrison's "Replace seqno values with
> request structures" patchset to ensure that the gem request is available for
On Wed, Nov 12, 2014 at 12:13:03PM +, Nick Hoath wrote:
> On 12/11/2014 11:24, Chris Wilson wrote:
> >On Wed, Nov 12, 2014 at 10:53:26AM +, Nick Hoath wrote:
> > seq_putc(m, '\n');
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index
On Wed, Dec 10, 2014 at 03:07:07PM +, Dave Gordon wrote:
> When adding instructions to a legacy or LRC ringbuffer, the sequence of
> emit() calls must be preceded by a call to intel(_logical)_ring_begin()
> to reserve the required amount of space, and followed by a matching call
> to intel(_log
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance(). Historically some (display) code
didn't use be
With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submis
From: Deepak S
According to updated BSpec, Render/Common/media Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.
v2: Update media forcewake range (Ville)
Signed-off-by: Deepak S
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm
On Wednesday 10 December 2014 08:01 PM, Ville Syrjälä wrote:
On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
According to updated BSpec, Render/Common Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
On 10/12/14 09:11, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
>> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
>>> On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
On Wed, Dec 10, 2014 at 03:07:08PM +, Dave Gordon wrote:
> @@ -401,11 +406,59 @@ static inline void intel_ring_emit(struct
> intel_engine_cs *ring,
> iowrite32(data, ringbuf->virtual_start + ringbuf->tail);
> ringbuf->tail += 4;
> }
> +
> +static inline void __intel_ringbuffer_beg
On Wed, 10 Dec 2014, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
> ---
> CONTRIBUTING | 9 +++--
> MAINTAINERS | 2 ++
> 2 files changed, 5 insertions(+), 6 deletions(-)
> create mode 100644 MAINTAINERS
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 0ad0c3a..a2ddf09 100644
> ---
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submis
With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance(). Historically some (display) code
didn't use be
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
On Wed, Dec 10, 2014 at 02:53:01PM +0100, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> > On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > > This added as a BUG_ON as it
Signed-off-by: Thomas Wood
---
NEWS | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 103c7cd..447ba77 100644
--- a/NEWS
+++ b/NEWS
@@ -1,18 +1,30 @@
Release 1.9 (-XX-XX)
-- As usual piles of new testcases and
Signed-off-by: Thomas Wood
---
CONTRIBUTING | 9 +++--
MAINTAINERS | 2 ++
2 files changed, 5 insertions(+), 6 deletions(-)
create mode 100644 MAINTAINERS
diff --git a/CONTRIBUTING b/CONTRIBUTING
index 0ad0c3a..a2ddf09 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -33,12 +33,9 @@ A short
Signed-off-by: Thomas Wood
---
tools/ddi_compute_wrpll.c | 23 +++
tools/intel_l3_udev_listener.c| 23 +++
tools/quick_dump/chipset_macro_wrap.c | 23 +++
tools/skl_ddb_allocation.c| 23 +++
Signed-off-by: Thomas Wood
---
README | 46 +-
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/README b/README
index 8bdaebd..f1aab58 100644
--- a/README
+++ b/README
@@ -1,17 +1,22 @@
-This is a collection of tools for development and t
On Wed, Dec 10, 2014 at 11:02:20AM +0100, Daniel Vetter wrote:
> Stupid userspace (there is no evil userspace in debugfs by assumption)
> might provoke a leak since we allocate the new array without holding
> any locks. Drop in an unconditional kfree to deal with this - kfree
> can handle NULL.
>
On Mon, 08 Dec 2014, Damien Lespiau wrote:
> We may be hidding bugs by doing that, so let remove it and have the
> actual mask value shine through, for better or worse.
>
> Signed-off-by: Damien Lespiau
Pushed these two to drm-intel-next-fixes, thanks for the patches.
BR,
Jani.
> ---
> driv
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> According to updated BSpec, Render/Common Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
>
> Signed-off-by: Deepak S
> ---
>
For CHT changes are required for calculating the correct m,n & p with
minimal error +/- for the required DSI clock, so that the correct dividor
& ctrl values are written in cck regs for DSI. This patch has been tested
on CHT RVP with 1200 x 1920 panel.
Signed-off-by: Gaurav K Singh
---
drivers/g
On Wed, Dec 10, 2014 at 12:03:20PM +, Damien Lespiau wrote:
> On Wed, Dec 10, 2014 at 11:42:13AM +0200, Jani Nikula wrote:
> > Pushed to drm-intel-next-fixes, replacing the old version. Thanks for
> > the patch.
> >
> > Now the question is, do we want [1] for 3.19 or 3.20?
> >
> > [1]
> > ht
On Wed, Dec 10, 2014 at 02:49:05PM +0100, Daniel Vetter wrote:
> Faster feedback to errors is always better. This is inspired by the
> addition to WARN_ONs to mask/enable helpers for registers to make sure
> callers have the arguments ordered correctly: Pretty much always the
> arguments are static
On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > This added as a BUG_ON as it considered that no one would ever request
> > > an unaligned object. Ho
On 12/08/2014 06:36 PM, Daniel Vetter wrote:
On Mon, Dec 08, 2014 at 05:21:07PM +0200, Ander Conselvan de Oliveira wrote:
There are no more users of that pointer since the new config is now
passed down the call chain during mode set. Also, when the switch to
atomic happens, the right config (sta
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915:
Cache ringbuf pointer in
Is anyone else having problems reading the PRTS logs?
It looks like I got a
1 - 100 of 138 matches
Mail list logo
