On Mon, Jul 27, 2015 at 10:48:16AM +0200, Daniel Vetter wrote:
On Sun, Jul 26, 2015 at 12:30:25AM +0530, Animesh Manna wrote:
Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 1).
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6870
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
On 21/07/2015 08:05, Daniel Vetter wrote:
On Fri, Jul 17, 2015 at 03:31:17PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware.
On Tue, Jul 28, 2015 at 08:45:51AM +0100, Chris Wilson wrote:
On Mon, Jul 27, 2015 at 09:15:32PM -0700, Hanno Böck wrote:
On Mon, 27 Jul 2015 09:59:45 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
The tables aren't sorted, that is worth fixing.
Attached patch should do that
Currently the iomap for VBT works only if the size of the
VBT is less than 6KB, but if the size of the VBT exceeds
6KB than the physical address and the size of the VBT to
be iomapped is specified in the mailbox3 and is iomapped
accordingly.
Signed-off-by: Deepak M m.dee...@intel.com
---
From: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
The GPIO configuration and register offsets are different from
baytrail for cherrytrail. Port the gpio programming accordingly
for cherrytrail in this patch.
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
---
Op 27-07-15 om 16:04 schreef Daniel Vetter:
On Mon, Jul 27, 2015 at 02:35:30PM +0200, Maarten Lankhorst wrote:
Set active_changed to force a modeset if the panel fitter's force
enabled.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Hm, shouldn't our fancy fastset logic
On Tue, Jul 28, 2015 at 09:57:37AM +0200, Maarten Lankhorst wrote:
Op 27-07-15 om 16:04 schreef Daniel Vetter:
On Mon, Jul 27, 2015 at 02:35:30PM +0200, Maarten Lankhorst wrote:
Set active_changed to force a modeset if the panel fitter's force
enabled.
Signed-off-by: Maarten Lankhorst
Set connectors_changed to force a modeset if the panel fitter's force
enabled on eDP.
Changes since v1:
- Use connectors_changed instead of active_changed because it's a
routing update.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
diff --git
On Fri, 2015-07-03 at 15:57 +0300, Ville Syrjälä wrote:
On Fri, Jul 03, 2015 at 02:35:49PM +0300, Mika Kahola wrote:
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported
On Mon, Jul 27, 2015 at 06:37:28PM +, Vivi, Rodrigo wrote:
On Mon, 2015-07-27 at 10:36 +0200, Daniel Vetter wrote:
On Fri, Jul 24, 2015 at 04:42:27PM -0700, Rodrigo Vivi wrote:
Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6871
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Hi Dave,
More drm-misc, mostly fine-tuning of atomic helpers. They're mostly
driver-wide interface changes of the helpers and I need them for i915
work, so I plan to pull this tag into drm-intel-next too.
Cheers, Daniel
The following changes since commit
On Sun, Jul 26, 2015 at 12:30:26AM +0530, Animesh Manna wrote:
As skl is fully dependent on dmc to go to low power state (dc5/dc6)
which requires a trigger from rpm and to ensure the dmc firmware
is available for runtime pm support rpm-reference-count is used
by not releasing the rpm reference
From: vkorjani vikas.korj...@intel.com
The Block 53 of the VBT, which is the MIPI sequence block
has undergone a design change because of which the parsing
logic has to be changed.
The current code will handle the parsing of v3 and other
lower versions of the MIPI sequence block.
Signed-off-by:
The generic gpio is sequence is parsed from the VBT and the
GPIO table is updated with the North core, South core and
SUS core elements.
Signed-off-by: Deepak M m.dee...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|5 +-
drivers/gpu/drm/i915/i915_reg.h|5 +
Currently the field in bdb header which indicates the VBT size
is of 2 bytes, but there are some cases where VBT size exceeds
64KB in which case this field may not contain the correct VBT size.
So its better to get the VBT size from the mailbox3 if
VBT is not present in the mailbox4 of opregion.
Currently in our kernel we ioremap 8KB of memory for the
opregion and it holds a maximum of 6KB sized RAW vbt data.
As per the latest opregion spec when the VBT size exceeds
6KB it cant be placed in the mailbox4 of the opregion, so
the physical address of the buffer where the Raw VBT is
stored
From: vkorjani vikas.korj...@intel.com
New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.
Signed-off-by: vkorjani vikas.korj...@intel.com
Signed-off-by: Deepak M m.dee...@intel.com
---
From: Gaurav K Singh gaurav.k.si...@intel.com
New sequences are added in the mipi sequence block of the
VBT from version 3 onwards. The sequences are added to
make the code more generic as the panel related info
are placed in the VBT.
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
From: Uma Shankar uma.shan...@intel.com
Added the BXT GPIO pin configuration and programming logic for
backlight and panel control.
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 46
1 file changed, 46
Currently there are few pair of functions which
are called during the panel enable/disable sequence.
To improve the granularity, adding few more wrapper
functions so that the functions are more specific
on what they are doing and also in some cases
some specific operations have to be done between
On 22/07/2015 15:26, Tvrtko Ursulin wrote:
Hi,
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
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
On Sun, Jul 26, 2015 at 12:30:35AM +0530, Animesh Manna wrote:
As power well 1 is superset of power well 2 and always pw2
will be disabled first and then pw1. On the other hand dmc
is responsible to save restore back pw1 when display
engine goes and come back from low power state. Before
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6873
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On 22/07/2015 15:45, Tvrtko Ursulin wrote:
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
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
Signed-off-by: Vatsala Nagaraju vatsala.nagr...@intel.com
It's Vathsala Nagaraju vathsala.nagar...@intel.com
Commit message: Removed byte swapping for csr firmware.
Commit message does not convey as to why the change was made. This change is
needed as DMC firmware loading failed on skylake
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6874
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Tuesday 28 July 2015 01:38 PM, Nagaraju, Vathsala wrote:
Signed-off-by: Vatsala Nagaraju vatsala.nagr...@intel.com
It's Vathsala Nagaraju vathsala.nagar...@intel.com
Commit message: Removed byte swapping for csr firmware.
Commit message does not convey as to why the change was made. This
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f
commit: be38e2b849aaa8cb223d807a4582fd666aefbd73 [9/30] drm/fb_helper: Create
wrappers for blit, copyarea and fillrect funcs
reproduce: make htmldocs
All warnings (new ones prefixed by
On 27/07/15 16:33, O'Rourke, Tom wrote:
On Thu, Jul 09, 2015 at 07:29:11PM +0100, Dave Gordon wrote:
Turn on interrupt steering to route necessary interrupts to GuC.
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai yu@intel.com
Signed-off-by: Dave Gordon david.s.gor...@intel.com
On Tue, Jul 28, 2015 at 01:43:11AM -0700, shuang...@intel.com wrote:
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6873
-Summary-
Platform Delta
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
Connectors are updated atomically now, so the only interaction
with the encoder is through base.crtc.
If it's NULL the encoder's not part of any crtc, and if it's
not
On Mon, Jul 27, 2015 at 09:15:32PM -0700, Hanno Böck wrote:
On Mon, 27 Jul 2015 09:59:45 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
The tables aren't sorted, that is worth fixing.
Attached patch should do that and fix the loop. Now it boots without
errors.
Does that look okay?
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.
For an example I have changed a DRM_ERROR for being unable to set a
performance
On Wed, Jul 15, 2015 at 09:50:42AM +0100, Chris Wilson wrote:
Since we may conceivably encounter situations where the upper part of the
64bit register changes between reads, for example when a timestamp
counter overflows, change the WARN into a retry loop.
Signed-off-by: Chris Wilson
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_crt.c | 2 -
drivers/gpu/drm/i915/intel_display.c | 79
drivers/gpu/drm/i915/intel_drv.h | 1
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the erroneous values.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc:: Alex Dai yu@intel.com
Cc:
Add a new debug value to distinguish and filter upon debug messages
emanating from GEM support code.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
include/drm/drmP.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/drm/drmP.h
Unlike the other i915_gem_object create functions, _from_data() requires
the struct_mutex as it also allocates the backing storage and so
interacts with the common lists. Document this requirement.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1
On 27/07/15 16:57, O'Rourke, Tom wrote:
On Thu, Jul 09, 2015 at 07:29:12PM +0100, Dave Gordon wrote:
From: Alex Dai yu@intel.com
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
This is handled by the atomic core now, no need to check this for
ourself.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
On Tue, Jul 28, 2015 at 12:12:11PM +0100, Michel Thierry wrote:
On 7/27/2015 10:11 PM, Chris Wilson wrote:
On Thu, Jul 16, 2015 at 10:33:29AM +0100, Michel Thierry wrote:
+ if (!(entry-flags EXEC_OBJECT_SUPPORTS_48B_ADDRESS)
+ (vma-node.start + vma-node.size) = (1ULL 32))
+
Op 28-07-15 om 15:13 schreef Ander Conselvan De Oliveira:
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_crt.c | 2 -
drivers/gpu/drm/i915/intel_display.c | 79
On 28/07/15 14:14, Chris Wilson wrote:
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.
For an example I have changed a DRM_ERROR
On Tue, Jul 28, 2015 at 04:58:27PM +0100, Dave Gordon wrote:
On 28/07/15 14:14, Chris Wilson wrote:
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug
On Tue, 28 Jul 2015, Deepak M m.dee...@intel.com wrote:
The generic gpio is sequence is parsed from the VBT and the
GPIO table is updated with the North core, South core and
SUS core elements.
Signed-off-by: Deepak M m.dee...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|5
On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console
On Tue, Jul 28, 2015 at 11:55 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Trying to do anything with kms drivers when oopsing has become a
failing
On Tue, Jul 28, 2015 at 12:03:28PM -0400, Benjamin Tissoires wrote:
We check the polarity of the attached dp, so it is normal to fail.
Do not send errors to the users.
if (probe) DRM_DEBUG else DRM_ERROR is fairly offensive.
It strikes me that you could make each of these functions report the
On Tue, 28 Jul 2015, Deepak M m.dee...@intel.com wrote:
Currently the field in bdb header which indicates the VBT size
is of 2 bytes, but there are some cases where VBT size exceeds
64KB in which case this field may not contain the correct VBT size.
So its better to get the VBT size from the
On 28/07/15 00:12, O'Rourke, Tom wrote:
On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote:
On 07/24/2015 03:31 PM, O'Rourke, Tom wrote:
[TOR:] When I see phase 1 I also look for phase 2.
A subject that better describes the change in this patch
would help.
On Thu, Jul 09, 2015 at
On Tue, 28 Jul 2015, Deepak M m.dee...@intel.com wrote:
From: vkorjani vikas.korj...@intel.com
New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.
Signed-off-by: vkorjani vikas.korj...@intel.com
Signed-off-by:
Hi,
On ASUS EeePC 1015PE with kernel 3.18 - 4.1, there is a problem very
similar to the one fixed for Lenovo by the following commit in the
mainline kernel:
commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb
drm/i915: gen4: work around hang during hibernation
When I try to put the system
On Tue, 28 Jul 2015, Deepak M m.dee...@intel.com wrote:
Currently the iomap for VBT works only if the size of the
VBT is less than 6KB, but if the size of the VBT exceeds
6KB than the physical address and the size of the VBT to
be iomapped is specified in the mailbox3 and is iomapped
On Tue, Jul 28, 2015 at 12:29:37PM +0100, Chris Wilson wrote:
On Tue, Jul 28, 2015 at 01:43:11AM -0700, shuang...@intel.com wrote:
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6873
The DP outputs connected through a USB Type-C port can have inverted
lanes. To detect that case, we implement autodetection by training only
the first lane if it doesn't work, we assume that we need to invert
the lanes.
Tested on a Chromebook Pixel 2015 (samus) with a USB Type-C to HDMI
adapter
We check the polarity of the attached dp, so it is normal to fail.
Do not send errors to the users.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 74 -
1 file changed, 58 insertions(+), 16
In order to detect if the Display Port is reversed or not (when connected
to a USC type-C connector), we need to probe the training with one lane
to check if the polarity is correct.
Factor out the code that we need later on.
This commit has no functional change
Signed-off-by: Benjamin Tissoires
Hi,
plugging a USB Type-C to HDMI adapter on a Chromebook Pixel 2015 works
only if the HDMI port is in its normal (not reverted) state.
Theorically, the USB chip should provide the information whether or not
the lane are resversed, but I could not find anything in the Intel PRM
regarding this.
On 7/27/2015 10:11 PM, Chris Wilson wrote:
On Thu, Jul 16, 2015 at 10:33:29AM +0100, Michel Thierry wrote:
+ if (!(entry-flags EXEC_OBJECT_SUPPORTS_48B_ADDRESS)
+ (vma-node.start + vma-node.size) = (1ULL 32))
+ return true;
gcc completely screwed this up here
On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote:
As csr firmware is taking care of loading the firmware,
so no need for driver to load again.
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f
commit: 97db4bc61cd0f862e0fd2bc13e7f87d82a2529ef [10/30] drm/fb_helper: Create
a wrapper for fb_set_suspend
reproduce: make htmldocs
All warnings (new ones prefixed by ):
On Tuesday 28 July 2015 01:27 PM, Daniel Vetter wrote:
On Mon, Jul 27, 2015 at 10:48:16AM +0200, Daniel Vetter wrote:
On Sun, Jul 26, 2015 at 12:30:25AM +0530, Animesh Manna wrote:
Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f
commit: 9c4b750e97facd19749a44e0c8eeb9d2a78dd55f [8/30] drm/fb_helper: Create
wrappers for fb_sys_read/write funcs
reproduce: make htmldocs
All warnings (new ones prefixed by ):
On Mon, Jul 27, 2015 at 10:26:26AM +0100, Chris Wilson wrote:
When we shrink our working sets, we want to avoid stealing pages from
objects that likely to be reused in the near future. We first look at
inactive objects before processing active objects - but what about a
recently active object
On 07/28/2015 04:55 PM, Daniel Vetter wrote:
On Tue, Jul 28, 2015 at 07:10:30PM +0800, kbuild test robot wrote:
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f
commit: 9c4b750e97facd19749a44e0c8eeb9d2a78dd55f [8/30]
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f
commit: 3a28c82f569178f2cb96fae03841fc9d71416fa7 [11/30] drm/fb_helper: Create
a wrapper for remove_conflicting_framebuffers
reproduce: make htmldocs
All warnings (new ones prefixed by
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There
The last user is gone, no need for trylocking any more in this legacy
helper.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/drm_modeset_lock.c | 52 --
include/drm/drm_modeset_lock.h | 1 -
2 files changed, 11 insertions(+), 42
Since the panic handling is gone this is only used for force-restoring
the fbdev/fbcon from sysrq, and that's done with a work item. No need
any more to do trylocks, we can just do normal locking.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/drm_fb_helper.c | 11
On Tue, Jul 28, 2015 at 07:10:30PM +0800, kbuild test robot wrote:
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 109cd1d0fe187769f5e8ea414b9479b1c33b1d9f
commit: 9c4b750e97facd19749a44e0c8eeb9d2a78dd55f [8/30] drm/fb_helper: Create
wrappers for fb_sys_read/write funcs
On Thu, Jul 16, 2015 at 10:33:12AM +0100, Michel Thierry wrote:
This clean-up version delays the 48-bit work to later patches and includes
other review comments from Akash and Chris Wilson. The first 4 patches
prepare the dynamic page allocation code to handle independent pdps, but
no specific
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 --
drivers/gpu/drm/i915/intel_dp_mst.c | 45
On 28/07/15 17:34, Chris Wilson wrote:
On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
On 28/07/15 14:27, Chris Wilson wrote:
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes
On Tue, Jul 28, 2015 at 06:09:16PM +0100, Dave Gordon wrote:
On 28/07/15 17:34, Chris Wilson wrote:
On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
On 28/07/15 14:27, Chris Wilson wrote:
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is
On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
On 28/07/15 14:27, Chris Wilson wrote:
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the
On 07/28/2015 06:59 AM, Dave Gordon wrote:
On 27/07/15 16:57, O'Rourke, Tom wrote:
On Thu, Jul 09, 2015 at 07:29:12PM +0100, Dave Gordon wrote:
From: Alex Dai yu@intel.com
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where
On 28/07/15 14:27, Chris Wilson wrote:
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the erroneous values.
Signed-off-by: Chris Wilson
Hi,
On Tue, 28 Jul 2015 10:14:51 +0200
Daniel Vetter dan...@ffwll.ch wrote:
Indeed, nice catch. Could you please read
Documentation/SubmittingPatches and apply your Signed-off-by and
then we can accept this patch under your authorship.
Preferrably this is two patches, (a) fix the
Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.
Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.
This adds the capability of adding human-readle text highlight (bold,
The highlight code is very sensible to the order of the hash keys,
but the order of the keys cannot be predicted on Perl. It generates
faulty DocBook entries like:
- @functiondevice_for_each_child/function
We should use an array for that job, so we can guarantee that the order
of the
Functions, Structs and Parameters definitions on kernel documentation
are pure cosmetic, it only highlights the element.
To ease the navigation in the documentation we should use links inside
those tags so readers can easily jump between methods directly.
This was discussed in 2014[1] and is
DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.
* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore
* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
to look
On 07/25/2015 07:20 AM, Stephan Mueller wrote:
Am Donnerstag, 23. Juli 2015, 15:16:23 schrieb Danilo Cesar Lemes de Paula:
Hi Danilo,
This series add supports for hyperlink cross-references on Docbooks and
an optional markup syntax for in-source Documentation.
Can you please give an
On Tue, Jul 28, 2015 at 11:14:19AM -0700, Hanno Böck wrote:
Hi,
On Tue, 28 Jul 2015 10:14:51 +0200
Daniel Vetter dan...@ffwll.ch wrote:
Indeed, nice catch. Could you please read
Documentation/SubmittingPatches and apply your Signed-off-by and
then we can accept this patch under
This series add supports for hyperlink cross-references on
Docbooks and an optional markup syntax for in-source
Documentation.
eg:
https://people.collabora.com/~danilo/intel/Documentation.MarkDown/DocBook/drm/API-drm-dev-ref.html
old:
On 28/07/15 16:16, Dave Gordon wrote:
On 28/07/15 00:12, O'Rourke, Tom wrote:
On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote:
On 07/24/2015 03:31 PM, O'Rourke, Tom wrote:
[TOR:] When I see phase 1 I also look for phase 2.
A subject that better describes the change in this patch
would
On Thu, Jul 23, 2015 at 04:35:47PM -0700, Rodrigo Vivi wrote:
No functional change. Just a preparation patch to make clear
what operation we are performing.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Good. The place where you call hsw_disable_ips() changes, but as you
explained
Hi Daniel,
On Thursday 09 July 2015 23:44:28 Daniel Vetter wrote:
Because of DP MST connectors can now be hotplugged and we must hold
the right lock when walking the connector lists. Enforce this by
checking the locking in our shiny new list walking macros.
v2: Extract the locking check
On Tue, Jul 28, 2015 at 08:40:58PM +0100, Dave Gordon wrote:
On 28/07/15 16:16, Dave Gordon wrote:
On 28/07/15 00:12, O'Rourke, Tom wrote:
On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote:
On 07/24/2015 03:31 PM, O'Rourke, Tom wrote:
[TOR:] When I see phase 1 I also look for phase 2.
On Thu, Jul 23, 2015 at 04:35:48PM -0700, Rodrigo Vivi wrote:
By Vesa DP spec, test counter at DP_TEST_SINK_MISC just reset to 0
when unsetting DP_TEST_SINK_START, so let's force this stop here.
But let's minimize the aux transactions and just do it when we know
it hasn't been properly
On Thu, Jul 23, 2015 at 04:35:50PM -0700, Rodrigo Vivi wrote:
By Vesa DP 1.2 spec TEST_CRC_COUNT is a 4 bit wrap counter which
increments each time the TEST_CRC_x_x are updated.
However if we are trying to verify the screen hasn't changed we get
same (count, crc) pair twice. Without this
On 28/07/15 14:14, Chris Wilson wrote:
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.
Wouldn't it be better to opt for
On 28/07/15 14:14, Chris Wilson wrote:
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.
Wouldn't it be better to opt for
On Thu, Jul 23, 2015 at 04:35:49PM -0700, Rodrigo Vivi wrote:
By Vesa DP 1.2 Spec TEST_CRC_COUNT should be
reset to 0 when TEST_SINK bit 0 = 0.
However for some strange reason when PSR is enabled in
certain platforms this is not true. At least not immediatelly.
So we face cases like this:
On Tue, Jul 28, 2015 at 04:16:03PM +0100, Dave Gordon wrote:
On 28/07/15 00:12, O'Rourke, Tom wrote:
On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote:
On 07/24/2015 03:31 PM, O'Rourke, Tom wrote:
[TOR:] When I see phase 1 I also look for phase 2.
A subject that better describes the
On Tue, 2015-07-28 at 13:25 -0700, Rafael Antognolli wrote:
On Thu, Jul 23, 2015 at 04:35:50PM -0700, Rodrigo Vivi wrote:
By Vesa DP 1.2 spec TEST_CRC_COUNT is a 4 bit wrap counter which
increments each time the TEST_CRC_x_x are updated.
However if we are trying to verify the screen
99 matches
Mail list logo
