On Mon, May 25, 2015 at 7:32 AM, Jani Nikula
wrote:
>> I'm not sure what is the approved way of fixing this. Perhaps
>> disabling CONFIG_DRM_I915_WERROR when CONFIG_COMPILE_TEST=y.
>
> Maybe the answer right now is to just drop that config. Daniel?
Agreed, that little experiment doesn't seem to
This reverts commit 118182e9d7d5afa0c7c10f568afb46ab78b462e9.
It's causing too much trouble when compile-testing for non-i915 folks.
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Andrew Morton
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Kconfig | 8
drivers/gpu/drm/i915/Kconf
Thanks for sending this.. I realized that I had a patch for this which I never
sent :)
Reviewed-by: Sonika Jindal
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Friday, May 22, 2015 3:31 PM
To: Intel-gfx@lists.freedesktop.org
Cc: Ursulin, Tvrtko;
From: Paulo Zanoni
This commit is the "sink CRC" version of:
commit 8c740dcea254a1472df2c0ac5ac585412a2507ec
Author: Paulo Zanoni
Date: Fri Oct 17 18:42:03 2014 -0300
drm/i915: disable IPS while getting the pipe CRCs.
For some unknown reason, when IPS gets enabled, the sink CRC changes.
From: Paulo Zanoni
This is a new test that should exercise the frontbuffer tracking
feature of the Kernel in a number of different ways. We use different
drawing methods, we use the primary, cursor and sprite planes, we can
test both on single and dual pipes, also on buffers not associated
with a
Since the advent of mmap(wc), where we reused the same cache domain for
WC and GTT paths (oh, how I regret that double-edged advice), we need to
be extra cautious when using GTT iomap_wc internally. Since userspace maybe
modifying through the mmap(wc) and we then modify modifying through an
aliased
On Mon, 25 May 2015, Jani Nikula wrote:
> On Fri, 22 May 2015, Uma Shankar wrote:
>> From: Sunil Kamath
>>
>> Latest VBT mentions which set of registers will be used for BLC,
>> as controller number field. Making use of this field in BXT
>> BLC implementation. Also, the registers are used in cas
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> BXT's DSI PLL is different from that of VLV. So this patch
> adds a new function to get the current DSI pixel clock based
> on the PLL divider ratio and lane count.
>
> This function is required for intel_dsi_get_config() functio
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> BXT DSI clocks are different than previous platforms. So adding a
> new function to program following clocks and dividers:
> 1. Program variable divider to generate input to Tx clock divider
>(Output value must be < 39.5Mhz)
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> This patch contains changes to support DSI disble sequence in BXT.
> The changes are:
> 1. BXT specific changes in clear_device_ready function.
> 2. BXT specific changes in DSI disable and post-disable functions.
> 3. Add a new f
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> This patch contains following changes:
> 1. MIPI device ready changes to support dsi_pre_enable. Changes
>are specific to BXT device ready sequence. Added check for
>ULPS mode(No effects on VLV).
> 2. Changes in dsi_enabl
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> This patch modifies dsi_prepare() function to support the same
> modeset prepare sequence for BXT also. Main changes are:
> 1. BXT port control register is different than VLV.
> 2. BXT modeset sequence needs vdisplay and hdisplay
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> This patch adds two new functions:
> - disable_dsi_pll.
> BXT DSI disable sequence and registers are
> different from previous platforms.
> - intel_disable_dsi_pll
> wrapper function to re-use the same code for
> multiple
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> This patch adds new functions for BXT clock and PLL programming.
> They are:
> 1. configure_dsi_pll for BXT.
>This function does the basic math and generates the divider ratio
>based on requested pixclock, and program clo
Why don’t we do this wm update as part of the fb unpin what is the need for wq
here. May add some latency
Please clarify
Thanks,
Pallavi
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Matt Roper
Sent: Thursday, May 21, 2015 7:42 AM
To: i
Since the advent of mmap(wc), where we reused the same cache domain for
WC and GTT paths (oh, how I regret that double-edged advice), we need to
be extra cautious when using GTT iomap_wc internally. Since userspace maybe
modifying through the mmap(wc) and we then modify modifying through an
aliased
On Mon, May 25, 2015 at 04:09:57PM +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2015-05-25 at 15:44 +0300, Ville Syrjälä wrote:
> > On Mon, May 25, 2015 at 03:32:52PM +0300, Ander Conselvan De Oliveira wrote:
> > > On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
> > >
On Mon, 2015-05-25 at 15:44 +0300, Ville Syrjälä wrote:
> On Mon, May 25, 2015 at 03:32:52PM +0300, Ander Conselvan De Oliveira wrote:
> > On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > GCP infoframes are required to inform the HDMI s
On Mon, May 25, 2015 at 03:32:52PM +0300, Ander Conselvan De Oliveira wrote:
> On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > GCP infoframes are required to inform the HDMI sink about the color
> > depth.
> >
> > Send the GCP infoframe whe
On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> GCP infoframes are required to inform the HDMI sink about the color
> depth.
>
> Send the GCP infoframe whenever the sink supports any deep color modes
> since such sinks must anyway be capable of r
On Mon, 25 May 2015, Chris Wilson wrote:
> On Mon, May 25, 2015 at 12:26:38PM +0300, Jani Nikula wrote:
>> On Mon, 25 May 2015, Chris Wilson wrote:
>> > On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote:
>> >> With allyesconfig/allmodconfig, kbuild enables all the options it can,
>>
On Mon, May 25, 2015 at 12:26:38PM +0300, Jani Nikula wrote:
> On Mon, 25 May 2015, Chris Wilson wrote:
> > On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote:
> >> With allyesconfig/allmodconfig, kbuild enables all the options it can,
> >> including DRM_I915_WERROR. That's not really
Reviewed-by: Ander Conselvan de Oliveira
On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> CPT/PPT require a specific procedure for enabling 12bpc HDMI. Implement
> it, and to keep things neat pull the code into a function.
>
> v2: Rebased due to
Please disregard this one, sent prematurely. Sorry.
On Mon, 25 May 2015, Jani Nikula wrote:
> On Fri, 22 May 2015, Uma Shankar wrote:
>> From: Shashank Sharma
>>
>> SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
>> functions are re-used for modeset sequence. But DDI inter
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
> functions are re-used for modeset sequence. But DDI interface doesn't
> include support for DSI.
> This patch adds:
> 1. cases for DSI encoder, in those modes
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Shashank Sharma
>
> SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
> functions are re-used for modeset sequence. But DDI interface doesn't
> include support for DSI.
> This patch adds:
> 1. cases for DSI encoder, in those modes
On Fri, 22 May 2015, Uma Shankar wrote:
> From: Sunil Kamath
>
> Latest VBT mentions which set of registers will be used for BLC,
> as controller number field. Making use of this field in BXT
> BLC implementation. Also, the registers are used in case control
> pin indicates display DDI. Adding a
On Sat, 23 May 2015, Paul Menzel wrote:
> Dear Intel folks,
>
>
> accessing the resources at 01.org over HTTPS, some have mixed content
> loading issues. For example [1] loads an image from Gravatar – for
> whatever reason – over HTTP.
>
> Google Chromium reports for example the following.
>
>
On Mon, 25 May 2015, Chris Wilson wrote:
> On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote:
>> With allyesconfig/allmodconfig, kbuild enables all the options it can,
>> including DRM_I915_WERROR. That's not really what we want with -Werror,
>> and this was breaking the build for And
On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote:
> With allyesconfig/allmodconfig, kbuild enables all the options it can,
> including DRM_I915_WERROR. That's not really what we want with -Werror,
> and this was breaking the build for Andrew.
>
> Andrew suggested to use COMPILE_TEST
30 matches
Mail list logo
