On Mon, Jul 13, 2015 at 11:24:46AM +0200, Daniel Vetter wrote:
> On Fri, Jul 10, 2015 at 02:10:54PM +0300, Antti Koskipaa wrote:
> > VBT version 196 increased the size of common_child_dev_config. The parser
> > code assumed that the size of this structure would not change.
> >
> > So now, instead
On Tue, Jul 14, 2015 at 12:11:12PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/intel_display.c
>
> between commit:
>
> 8aa3053bf731 ("drm/i915: fix oops in primary_check_plane")
>
> from the drm-int
On Tue, Jul 14, 2015 at 10:30:56AM +0530, Archit Taneja wrote:
>
> Hi,
>
> On 07/14/2015 08:22 AM, Stephen Rothwell wrote:
> >Hi all,
> >
> >After merging the drm-misc tree, today's linux-next build (x86_64
> >allmodconfig) failed like this:
> >
> >drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In fun
Can you please attach your Xorg.log?
Thanks, Daniel
On Tue, Jul 14, 2015 at 6:51 AM, Harald Arnesen wrote:
> 4.2-rc2 gives me an unusable X11 screen (se attached picture).
> 4.2-rc1 is OK.
>
> Bisected to the following:
>
>
> 19ee835cdb0b5a8eb11a68f25a51b8039d564488 is the first bad commit
> com
On Mon, Jul 13, 2015 at 05:32:14PM +, Bish, Jim wrote:
> On Mon, 2015-07-13 at 11:05 +0200, Daniel Vetter wrote:
> > On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote:
> > > On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Jul 10, 2015 at 02:18:57PM +0
On Tue, Jul 14, 2015 at 10:16:17AM +0530, Jindal, Sonika wrote:
>
>
> On 7/13/2015 8:25 PM, Daniel Vetter wrote:
> >On Mon, Jul 13, 2015 at 04:35:00PM +0530, Sonika Jindal wrote:
> >>Adding this for SKL onwards.
> >>
> >>v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
> >
On Tue, Jul 14, 2015 at 03:48:36AM +, Sharma, Shashank wrote:
> Hi Daniel, Chris
>
> Gen7 and Gen8 platforms have a different live status register (0x61114) and
> we need not to rely on ISR on that.
> As Sonika mentioned, We have been using this register for our commercial
> releases, and
On Tue, Jul 14, 2015 at 10:11:37AM +0300, David Weinehall wrote:
> On Mon, Jul 13, 2015 at 11:24:46AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 10, 2015 at 02:10:54PM +0300, Antti Koskipaa wrote:
> > > VBT version 196 increased the size of common_child_dev_config. The parser
> > > code assumed th
Op 13-07-15 om 19:16 schreef Daniel Stone:
> Hi,
>
> On 13 July 2015 at 15:30, Maarten Lankhorst
> wrote:
>> @@ -13649,9 +13647,7 @@ static void intel_begin_crtc_commit(struct drm_crtc
>> *crtc)
>>
>> /* Perform vblank evasion around commit operation */
>> if (crtc->state->active)
On Mon, Jul 13, 2015 at 04:07:14PM +, Gore, Tim wrote:
>
>
> Tim Gore
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday,
On Tue, Jul 14, 2015 at 11:18:50AM +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.
>
> Signed-off-by: Sonika Jindal
Yeah I think this is much clearer. Will pu
Please apply this patch series along with the Interrupt handling fix patch
Sonika shared.
With these 4 patches applied, we should not see any problems with HPDs (Until
the HW is broken).
On a similar note, the corresponding chrome team applied the live status check
patch, along with others, a
On Mon, Jul 13, 2015 at 04:56:53PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Frame buffer modifiers extensions provided in;
>
> commit e3eb3250d84ef97b766312345774367b6a310db8
> Author: Rob Clark
> Date: Thu Feb 5 14:41:52 2015 +
>
> drm: add support for tiled/c
On 28.05.2015 18:03, Michel Dänzer wrote:
> On 28.05.2015 17:38, Daniel Vetter wrote:
>> On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
>>> On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
> On 27.05.2015 18:04, Daniel
On 07/13/15 16:07, Daniel Vetter wrote:
> On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote:
>> On 07/13/2015 11:54 AM, Daniel Vetter wrote:
>>> On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote:
On 07/13/2015 11:18 AM, Daniel Vetter wrote:
> On Mon, Jul 13, 2015 at 1
Op 13-07-15 om 18:30 schreef Daniel Stone:
> Hi,
>
> On 13 July 2015 at 15:30, Maarten Lankhorst
> wrote:
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 037a85f1b127..e4d8acc63823 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++
Op 13-07-15 om 18:21 schreef Daniel Stone:
> Hi,
>
> On 13 July 2015 at 15:30, Maarten Lankhorst
> wrote:
>> This might not have been set during boot, and when we preserve
>> the initial mode this can result in a black screen.
>>
>> Cc: Daniel Stone
>> Signed-off-by: Maarten Lankhorst
>> ---
>>
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, July 14, 2015 9:09 AM
> To: Gore, Tim
> Cc: Daniel Vetter; intel-gfx@lists.free
Totatlly forgotten that we have these when nuking all the UMS code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_ioc32.c | 125 --
1 file changed, 125 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_ioc32.c
b/drivers/gpu/drm/i915/i915_ioc32
I was confused shortly whether the compat was needed for the int,
until I noticed the pointer in the original.
Also remove typedef.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_ioc32.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Tue, Jul 14, 2015 at 08:09:21AM +, Sharma, Shashank wrote:
> Please apply this patch series along with the Interrupt handling fix patch
> Sonika shared.
> With these 4 patches applied, we should not see any problems with HPDs (Until
> the HW is broken).
Ok, that explains things. If you
On Tue, Jul 14, 2015 at 10:17:09AM +0200, Hans Verkuil wrote:
> On 07/13/15 16:07, Daniel Vetter wrote:
> > On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote:
> >> On 07/13/2015 11:54 AM, Daniel Vetter wrote:
> >>> On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote:
> On 0
On Tue, Jul 14, 2015 at 10:59:30AM +0200, Daniel Vetter wrote:
> Totatlly forgotten that we have these when nuking all the UMS code.
>
> Signed-off-by: Daniel Vetter
All deleted UMS stubs,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
On Mon, Jul 13, 2015 at 09:36:45AM -0700, jay.p.pa...@intel.com wrote:
> From: Jay Patel
>
> NOTE: This is an interim solution which is targeted towards
> Chrome OS/Android to be used until a long term solution is available.
>
> In this patch, request_firmware() is called in a worker thread
> wh
On Tue, Jul 14, 2015 at 10:59:31AM +0200, Daniel Vetter wrote:
> I was confused shortly whether the compat was needed for the int,
> until I noticed the pointer in the original.
>
> Also remove typedef.
>
> Signed-off-by: Daniel Vetter
Oh, why an int? But you should improve the uapi definition
On Mon, Jun 29, 2015 at 02:50:21PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> Ring frequency table programming is not required on BXT. Added separate
> checks to enable the programming only for SKL & skip for BXT.
>
> v2: Removed the BXT check from gen6_update_ring_freq function
>
On 13/07/15 14:16, Mika Kuoppala wrote:
Arun Siluvery writes:
In Indirect context w/a batch buffer,
+WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
Cc: Robert Beckett
Cc: Imre Deak
Sig
On 07/14/15 11:11, Daniel Vetter wrote:
> On Tue, Jul 14, 2015 at 10:17:09AM +0200, Hans Verkuil wrote:
>> On 07/13/15 16:07, Daniel Vetter wrote:
>>> On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote:
On 07/13/2015 11:54 AM, Daniel Vetter wrote:
> On Mon, Jul 13, 2015 at 11:43:
On Mon, Jul 13, 2015 at 04:30:22PM +0200, Maarten Lankhorst wrote:
> There is a small memory leak in intel_modeset_readout_hw_state,
> plug it.
This should be a separate patch I think since it seems unrelated to the
other changes. And I think less mystery in the commit message helps, e.g.
"We leak
On Mon, Jul 13, 2015 at 04:30:17PM +0200, Maarten Lankhorst wrote:
> Instead of doing ad-hoc checks we already have a way of checking
> if the state is compatible or not. Use this to force a modeset.
>
> Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
> we should check if a full mod
On Mon, Jul 13, 2015 at 04:30:21PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
Needs a summary (or just pasting relevant parts of our mail threads) about
double-modesets, ways to avoid them and why exactly we ended up opting for
this solution here. Especially please highlig
On Mon, Jul 13, 2015 at 04:30:20PM +0200, Maarten Lankhorst wrote:
> All non-primary planes get disabled during hw readout,
> this reduces complexity and means not having to do some plane
> visibility checks during the first commit.
>
> Signed-off-by: Maarten Lankhorst
I still think calling read
Hi Dave,
Dave Gordon writes:
> On 13/07/15 14:16, Mika Kuoppala wrote:
>> Arun Siluvery writes:
>>
>>> In Indirect context w/a batch buffer,
>>> +WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
>>>
>>> v2: SKL revision id was used for BXT, copy paste error found during
>>> internal revie
On Tue, Jul 14, 2015 at 10:50:21AM +0200, Maarten Lankhorst wrote:
> Op 13-07-15 om 18:21 schreef Daniel Stone:
> > Hi,
> >
> > On 13 July 2015 at 15:30, Maarten Lankhorst
> > wrote:
> >> This might not have been set during boot, and when we preserve
> >> the initial mode this can result in a blac
On Mon, Jul 13, 2015 at 04:30:28PM +0200, Maarten Lankhorst wrote:
> And get rid of things that are no longer true. This function is only
> used for forcing a modeset when encoder properties are changed.
>
> Because this is not yet done atomically, assume a full modeset is
> needed and reset the c
Op 14-07-15 om 11:55 schreef Daniel Vetter:
> On Tue, Jul 14, 2015 at 10:50:21AM +0200, Maarten Lankhorst wrote:
>> Op 13-07-15 om 18:21 schreef Daniel Stone:
>>> Hi,
>>>
>>> On 13 July 2015 at 15:30, Maarten Lankhorst
>>> wrote:
This might not have been set during boot, and when we preserve
From: Tvrtko Ursulin
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being
forwarded, but the drm.h header suggests (and reality confirms) ones
after (and including) DRM_COMMAND_END should be forwarded as well.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: sta...@vger.ker
From: Tvrtko Ursulin
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the structure packing/alignment problem w
On Tue, Jul 14, 2015 at 11:35:30AM +0200, Hans Verkuil wrote:
> On 07/14/15 11:11, Daniel Vetter wrote:
> > On Tue, Jul 14, 2015 at 10:17:09AM +0200, Hans Verkuil wrote:
> >> On 07/13/15 16:07, Daniel Vetter wrote:
> >>> On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote:
> On 07/13/
Instead of doing ad-hoc checks we already have a way of checking
if the state is compatible or not. Use this to force a modeset.
Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
we should check if a full modeset is really needed.
Fastboot will allow the adjust parameter to ignore so
On Sat, Jul 11, 2015 at 10:11:43PM +0100, Chris Wilson wrote:
> On Thu, Jul 09, 2015 at 11:32:33PM +0200, Daniel Vetter wrote:
> > Doesn't really add anything which can't be figured out through
> > proc files. And more clearly separates the new gem mmap handling
> > code from the old drm maps mmap
On Tue, Jul 14, 2015 at 11:13:08AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Frame buffer modifiers extensions provided in;
>
> commit e3eb3250d84ef97b766312345774367b6a310db8
> Author: Rob Clark
> Date: Thu Feb 5 14:41:52 2015 +
>
> drm: add support for tiled/c
This reverts commit 19ee835cdb0b5a8eb11a68f25a51b8039d564488.
It breaks existing old userspace which doesn't handle UNKNOWN
swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably
still is on some other platforms, but it still pretty clearly broke
the testers machine. If we want this
Op 14-07-15 om 11:53 schreef Daniel Vetter:
> On Mon, Jul 13, 2015 at 04:30:20PM +0200, Maarten Lankhorst wrote:
>> All non-primary planes get disabled during hw readout,
>> this reduces complexity and means not having to do some plane
>> visibility checks during the first commit.
>>
>> Signed-off-
Hey,
Op 14-07-15 om 11:50 schreef Daniel Vetter:
> On Mon, Jul 13, 2015 at 04:30:21PM +0200, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
> Needs a summary (or just pasting relevant parts of our mail threads) about
> double-modesets, ways to avoid them and why exactly we ended up
On Tue, Jul 14, 2015 at 12:30:38PM +0200, Maarten Lankhorst wrote:
> Op 14-07-15 om 11:53 schreef Daniel Vetter:
> > On Mon, Jul 13, 2015 at 04:30:20PM +0200, Maarten Lankhorst wrote:
> >> All non-primary planes get disabled during hw readout,
> >> this reduces complexity and means not having to do
commit 4efb477b56ca9ac6ab76136a2801aaee4d3f46c5
Author: Maarten Lankhorst
Date: Mon Jul 13 15:29:47 2015 +0200
drm/i915: Remove plane_config from struct intel_crtc, v2.
Nothing depends on this outside initial hw readout, so keep this
struct on the stack instead.
Change
Hi,
On 14 July 2015 at 10:50, Daniel Vetter wrote:
> On Mon, Jul 13, 2015 at 04:30:21PM +0200, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>
> Needs a summary (or just pasting relevant parts of our mail threads) about
> double-modesets, ways to avoid them and why exactly we ende
Hey,
On 14 July 2015 at 09:27, Maarten Lankhorst
wrote:
> Op 13-07-15 om 18:30 schreef Daniel Stone:
>> On 13 July 2015 at 15:30, Maarten Lankhorst
>> wrote:
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 037a85f1b127..e4d8acc63823 100
Sure, Daniel, Thanks.
Sonika will send the patches in some time.
Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, July 14, 2015 2:33 PM
To: Sharma, Shashank
Cc: Daniel Vetter; Jindal, Sonika; Chris Wilson; i
Op 14-07-15 om 13:21 schreef Daniel Stone:
> Hi,
>
> On 14 July 2015 at 10:50, Daniel Vetter wrote:
>> On Mon, Jul 13, 2015 at 04:30:21PM +0200, Maarten Lankhorst wrote:
>>> Signed-off-by: Maarten Lankhorst
>> Needs a summary (or just pasting relevant parts of our mail threads) about
>> double-mo
On (07/13/15 17:05), Daniel Vetter wrote:
> It goes boom somewhere from the cursor ioctl code, which means X is
> probably involved. Usual suspects are vt-switching, suspend/resume or
> cursor vs. DPMS. You can force a DPMS off from within X with
>
> $ xset dpms force off
>
that helped. seems to
Op 14-07-15 om 11:49 schreef Daniel Vetter:
> On Mon, Jul 13, 2015 at 04:30:22PM +0200, Maarten Lankhorst wrote:
>> There is a small memory leak in intel_modeset_readout_hw_state,
>> plug it.
> This should be a separate patch I think since it seems unrelated to the
> other changes. And I think less
Unreference the old mode_blob by calling the crtc_destroy_state
helper before zeroing the crtc_state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_d
There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic
property.
If the mode_blob still exists, but enable = false then all updates are rejected
with -EINVAL.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+)
On 14 July 2015 at 12:42, Maarten Lankhorst
wrote:
> Unreference the old mode_blob by calling the crtc_destroy_state
> helper before zeroing the crtc_state.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Stone
___
Intel-gfx mailing list
Inte
This is required to properly initialize vblanks on the active crtc.
Without it drm_calc_vbltimestamp_from_scanoutpos can fail with
crtc 0: Noop due to uninitialized mode.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
On 14 July 2015 at 12:45, Maarten Lankhorst
wrote:
> There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic
> property.
> If the mode_blob still exists, but enable = false then all updates are
> rejected with -EINVAL.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Dan
On 14 July 2015 at 12:46, Maarten Lankhorst
wrote:
> This is required to properly initialize vblanks on the active crtc.
> Without it drm_calc_vbltimestamp_from_scanoutpos can fail with
> crtc 0: Noop due to uninitialized mode.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Stone
On Tue, Jul 14, 2015 at 12:33:29PM +0200, Maarten Lankhorst wrote:
> commit 4efb477b56ca9ac6ab76136a2801aaee4d3f46c5
> Author: Maarten Lankhorst
> Date: Mon Jul 13 15:29:47 2015 +0200
>
> drm/i915: Remove plane_config from struct intel_crtc, v2.
>
> Nothing depends on this outside
This series adds some optimization related to reading of edid only when
required and when live status says so.
The comments in the patches explain more.
v2:
Some refactoring is with this series.
Also, right now this is done for platforms gen7 and above because we
couldn't test with older
From: Shashank Sharma
This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.
The current implementation of hdmi_detect()
function re-sets the cached HDMI edid (in connector->detect_edid) in
every d
Adding this for SKL onwards.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
drivers/gpu/drm/i915/int
From: Shashank Sharma
This patch adds the intel_connector initialized to intel_hdmi
display, during the init phase, just like the other encoders do.
This attachment is very useful when we need to extract the connector
pointer during the hotplug handler function
Signed-off-by: Shashank Sharma
--
Fill in driver type, hsync, vrefresh and name.
Those members are not read out but can be calculated from the mode.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 434b43054d60..fa1cdefa5662 100644
--- a/drivers/g
On 14 July 2015 at 13:12, Maarten Lankhorst
wrote:
> Fill in driver type, hsync, vrefresh and name.
> Those members are not read out but can be calculated from the mode.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Stone
Should be safe to merge independently.
Cheers,
Daniel
__
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 Tue, Jul 14, 2015 at 01:40:45PM +0200, Maarten Lankhorst wrote:
> Op 14-07-15 om 13:21 schreef Daniel Stone:
> > Hi,
> >
> > On 14 July 2015 at 10:50, Daniel Vetter wrote:
> >> On Mon, Jul 13, 2015 at 04:30:21PM +0200, Maarten Lankhorst wrote:
> >>> Signed-off-by: Maarten Lankhorst
> >> Needs
On Tue, Jul 14, 2015 at 08:39:50PM +0900, Sergey Senozhatsky wrote:
> On (07/13/15 17:05), Daniel Vetter wrote:
> > It goes boom somewhere from the cursor ioctl code, which means X is
> > probably involved. Usual suspects are vt-switching, suspend/resume or
> > cursor vs. DPMS. You can force a DPMS
On Tue, Jul 14, 2015 at 06:08:06PM +0530, Kumar, Mahesh wrote:
> 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 bit
On Tue, Jul 14, 2015 at 10:15:21AM +0100, Chris Wilson wrote:
> On Tue, Jul 14, 2015 at 10:59:30AM +0200, Daniel Vetter wrote:
> > Totatlly forgotten that we have these when nuking all the UMS code.
> >
> > Signed-off-by: Daniel Vetter
>
> All deleted UMS stubs,
> Reviewed-by: Chris Wilson
App
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 709b3c7..71e
On (07/14/15 14:44), Daniel Vetter wrote:
> > that helped. seems to be working only on -next.
>
> You mean you only get a backtrace on -next, right?
yeah, sure :-)
> Otherwise I'd be confused ;-)
>
> Next up. Please boot with drm.debug=0xe, repro the issue and attach
> complete dmesg (from boo
v2: Patch leakage fixed
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 059de0f..afa8972 100644
---
drm/i915: Readout initial hw mode, v2.
Atomic requires a mode blob when crtc_state->enable is true, or
you get a huge warn_on.
With a few tweaks the mode we read out from hardware could be used
as the real mode without a modeset, but this requires too much
testing, so for now force a mode
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt
v2: address static checker warning where unsigned value was checked for
less than zero which is never true (Dan Carpenter).
v3: The WA uses default value of GEN8_L3SQCREG4 during flush but that disables
some
First two patches received r-b tags.
All patches use updated macro, patch 3 and 4 updated as per review comments.
v2 review history is available at,
http://www.spinics.net/lists/intel-gfx/msg70952.html
Arun Siluvery (4):
drm/i915: Enable WA batch buffers for Gen9
drm/i915/gen9: Add WaDisableC
In Indirect context w/a batch buffer,
+WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
v3: explain why part of the WA is in Per ctx batch (Mika)
Cc: Mika Kuoppala
Cc: Imre Deak
Signed-off-b
This patch only enables support for Gen9, the actual WA will be
initialized in subsequent patches.
The WARN that we use to warn user if WA batch support is not available
for a particular Gen is replaced with DRM_ERROR as warning here doesn't
really add much value.
v2: include all infrastructure b
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
v3: use updated macro.
Reviewed-by: Mika Kuoppala
Cc: Robert Beckett
Cc: Mika Kuoppala
Cc: Imre Deak
Signed-off-by:
And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.
Because this is not yet done atomically, assume a full modeset is
needed and force a modeset on the crtc.
Changes since v1:
- s/reset/force modeset/
Signed-off-by:
On ti, 2015-07-14 at 11:18 +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.
>
> Signed-off-by: Sonika Jindal
> ---
> drivers/gpu/drm/i915/intel_dp.c | 18 +
On ti, 2015-07-14 at 17:21 +0530, Sonika Jindal wrote:
> Adding this for SKL onwards.
>
> v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
> to check digital port status. Adding a separate function to get bxt live
> status (Daniel)
>
> Signed-off-by: Sonika Jindal
> ---
>
On Fri, Jul 10, 2015 at 08:13:11PM +0300, Francisco Jerez wrote:
> From: Peter Antoine
>
> This change adds the programming of the MOCS registers to the gen 9+
> platforms. The set of MOCS configuration entries introduced by this
> patch is intended to be minimal but sufficient to cover the needs
Damien Lespiau writes:
> On Fri, Jul 10, 2015 at 08:13:11PM +0300, Francisco Jerez wrote:
>> From: Peter Antoine
>>
>> This change adds the programming of the MOCS registers to the gen 9+
>> platforms. The set of MOCS configuration entries introduced by this
>> patch is intended to be minimal b
On Tue, Jul 14, 2015 at 10:41:42PM +0900, Sergey Senozhatsky wrote:
> On (07/14/15 14:44), Daniel Vetter wrote:
> > > that helped. seems to be working only on -next.
> >
> > You mean you only get a backtrace on -next, right?
>
> yeah, sure :-)
>
> > Otherwise I'd be confused ;-)
> >
> > Next u
On Tue, Jul 14, 2015 at 05:47:37PM +0300, Francisco Jerez wrote:
> Damien Lespiau writes:
>
> > On Fri, Jul 10, 2015 at 08:13:11PM +0300, Francisco Jerez wrote:
> >> From: Peter Antoine
> >>
> >> This change adds the programming of the MOCS registers to the gen 9+
> >> platforms. The set of MOC
Arun Siluvery writes:
> In Indirect context w/a batch buffer,
> +WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
>
> v2: SKL revision id was used for BXT, copy paste error found during
> internal review (Bob Beckett).
>
> v3: explain why part of the WA is in Per ctx batch (Mika)
>
> Cc: Mik
I was confused shortly whether the compat was needed for the int,
until I noticed the pointer in the original.
Also remove typedef.
v2: Review from Chris.
- Add comments.
- Also change the int param in the original structure.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i
On Tue, Jul 14, 2015 at 06:07:30PM +0200, Daniel Vetter wrote:
> I was confused shortly whether the compat was needed for the int,
> until I noticed the pointer in the original.
>
> Also remove typedef.
>
> v2: Review from Chris.
> - Add comments.
> - Also change the int param in the original str
On Mon, Jul 13, 2015 at 04:30:29PM +0200, Maarten Lankhorst wrote:
> Calculate all state using a normal transition, but afterwards fudge
> crtc->state->active back to its old value. This should still allow
> state restore in setup_hw_state to work properly.
>
> Signed-off-by: Maarten Lankhorst
O
On Tue, Jul 14, 2015 at 12:31:21PM +0200, Daniel Vetter wrote:
> This reverts commit 19ee835cdb0b5a8eb11a68f25a51b8039d564488.
>
> It breaks existing old userspace which doesn't handle UNKNOWN
> swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably
> still is on some other platforms
2015-07-09 14:28 GMT-03:00 Paulo Zanoni :
> 2015-07-09 14:15 GMT-03:00 Daniel Vetter :
>> Plus igt testcases to make sure we check for this (since
>> right now it seems like we don't).
>
> It's on the TODO list but it's not a priority since the Kernel checks
> are very straightforward. One of the p
2015-07-09 14:39 GMT-03:00 Ville Syrjälä :
> On Thu, Jul 09, 2015 at 02:31:15PM -0300, Paulo Zanoni wrote:
>> 2015-07-09 14:22 GMT-03:00 Ville Syrjälä :
>> > On Thu, Jul 09, 2015 at 07:10:04PM +0200, Daniel Vetter wrote:
>> >> On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
>> >> > Fr
From: Paulo Zanoni
Hi
This series can be reviewed in parallel with the other FBC patches
currently under review. The goal here is to fix all the mmap-wc
subtests of kms_frontbuffer_tracking that don't require any patches
that are in the other series.
Thanks,
Paulo
Paulo Zanoni (4):
drm/i915:
From: Paulo Zanoni
Because intel_unpin_work_fn() already calls
intel_frontbuffer_flip_complete() which will call intel_fbc_flush()
which will call intel_fbc_update() when needed.
We couldn't fix this previously due to the fact that FBC was not
properly behaving as intended on frontbuffer flushes
From: Paulo Zanoni
Use the appropriate call.
I know there's a discussion about whether we need this call here at
all, but removing the call means we'll only update FBC after we get
the page flip IRQ. So the user may only see the new frame a little
after it should. Let's wait just a little bit mo
From: Paulo Zanoni
First, an introduction. We currently have two types of GTT mmaps: the
"normal" old mmap, and the WC mmap. For frontbuffer-related features
that have automatic hardware tracking, only the non-WC mmap writes are
detected by the hardware. Since inside the Kernel both are treated a
From: Paulo Zanoni
Due to the way busy_bits was handled, we were not doing any flushes if
we didn't previously get an invalidate. Since it's possible to get
flushes without an invalidate first, remove the busy_bits early
return.
So now that we don't have the busy_bits guard anymore we'll need th
From: Paulo Zanoni
We can't add this to igt_draw since igt_draw doesn't care whether it's
writing on a frontbuffer or not.
PS: the ENOSYS is for Kernels without the patch implementing the
IOCTL.
Signed-off-by: Paulo Zanoni
---
tests/kms_frontbuffer_tracking.c | 18 ++
1 file c
1 - 100 of 110 matches
Mail list logo
