With
commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
Author: Daniel Vetter
Date: Thu Jul 9 23:44:28 2015 +0200
drm: Check locking in drm_for_each_connector
we started checking the locking in drm_for_each_connector but somehow
I totally missed drm_mode_config_reset. There's no problem ther
With
commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
Author: Daniel Vetter
Date: Thu Jul 9 23:44:28 2015 +0200
drm: Check locking in drm_for_each_connector
we started checking the locking in drm_for_each_connector but somehow
I totally missed drm_mode_config_reset. There's no problem ther
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 als
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 chec
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 s
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 bet
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 DRM_NO
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 DRM_NO
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 th
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 li
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 s
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
Good. The place where you call hsw_disable_ips() changes, but as you
explained earlier, this is require
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 inside
those tags so readers can easily jump between methods directly.
This was discussed in 2014[1] and is implement
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:
- @device_for_each_child
We should use an array for that job, so we can guarantee that the order
of the regex execution on d
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,
underlin
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 p
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:
https://people.collabora.com/~danilo/intel/Documentation.
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
wo
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 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
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 g
Hi,
On Tue, 28 Jul 2015 10:14:51 +0200
Daniel Vetter 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 tables, (b
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* WAR
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 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
>>
>> GuC-based submission is mostly the same as execlist mode, up to
>> intel_logical_ring_advance_and_submit(), where the contex
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 th
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
Cc:: Alex Dai
Cc: D
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, Jul 28, 2015 at 11:55 AM, Daniel Vetter 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
>> wrote:
>> > Trying to do anything with kms drivers when oopsing has become a
>> > failing proposition. But since we can end up
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
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.
So
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
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 an
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
---
drivers/gpu/drm/i915/intel_dp.c | 74 -
1 file changed, 58 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/dr
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 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 for
On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
> On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter 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
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
> ---
> drivers/gpu/drm/i915/intel_crt.c | 2 -
> drivers/gpu/drm/i915/intel_display.c | 79
>
> dr
On Tue, 28 Jul 2015, Deepak M 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
> ---
> drivers/gpu/drm/i915/i915_drv.h|5 +-
> drivers/gpu/drm/i915/i91
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 07:2
On Tue, 28 Jul 2015, Deepak M wrote:
> From: vkorjani
>
> 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
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/intel_bios.c
On Tue, 28 Jul 2015, Deepak M 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 mailbox3 if
> VB
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
> > -Summ
On Tue, 28 Jul 2015, Deepak M 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
> accordingly.
>
> Signe
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 <
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter 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 handler isn't enoug
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
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 execlist queue;
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
>
Reviewed-by: Ander Conselvan de Oliveira
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 NULL then active s
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
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertio
Reviewed-by: Ander Conselvan de Oliveira
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
> ---
> drivers/gpu/drm/i915/intel_display.c | 19 +--
> 1 f
Add a new debug value to distinguish and filter upon debug messages
emanating from GEM support code.
Signed-off-by: Chris Wilson
---
include/drm/drmP.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f2d68d185274.
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
Cc:: Alex Dai
Cc: Dave Gordon
Cc: Tom O'Rourke
---
driver
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 enhanc
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 2 -
drivers/gpu/drm/i915/intel_display.c | 79
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_dvo
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 speci
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
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 --
> drivers/gpu/drm/i915/intel_dp_mst.c | 45
> +++-
> 2 files change
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 >>):
Warning(
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
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
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h
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] drm/fb_helper:
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 obje
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
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_
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 fu
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
---
drivers/gpu/drm/drm_fb_helper.c | 11 +--
1 file changed,
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 wa
The last user is gone, no need for trylocking any more in this legacy
helper.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_modeset_lock.c | 52 --
include/drm/drm_modeset_lock.h | 1 -
2 files changed, 11 insertions(+), 42 deletions(-)
diff --git
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
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 >>):
W
On Tuesday 28 July 2015 01:38 PM, Nagaraju, Vathsala wrote:
Signed-off-by: Vatsala Nagaraju
It's Vathsala Nagaraju
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
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 require
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
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 t
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
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 t
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
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
From: Gaurav K Singh
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
Signed-off-by: Shobhit Kumar
Signed-off-by: Deepak M
From: Uma Shankar
Added the BXT GPIO pin configuration and programming logic for
backlight and panel control.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel
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 t
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 wil
From: vkorjani
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: vkorjani
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
---
drivers/gpu/drm/i915/i915_drv.h|5 +-
drivers/gpu/drm/i915/i915_reg.h|5 +
drivers/gpu/drm/i915/int
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.
S
From: vkorjani
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
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c |6 +++
drivers/gpu/drm/i915/intel_bios.h
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
---
drivers/gpu/drm/i915/intel
From: Yogesh Mohan Marimuthu
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
---
drivers/gpu/drm/i915/i915_reg.h| 23 ++
drivers
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
---
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i91
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 dcd14dd957f02ef679c61325a2221a0574bdcab3
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
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
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
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 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: Maart
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 f
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 wrote:
> >
> > > The tables aren't sorted, that is worth fixing.
> >
> > Attached patch should do that and fix the l
Signed-off-by: Vatsala Nagaraju
It's Vathsala Nagaraju
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 due byte swap done in the
driver"
-Original
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
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
> Hm, shouldn't our fancy fastset logic be able to detect that we
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
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 refere
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 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? If so please a
1 - 100 of 101 matches
Mail list logo
