On Thu, 13 Aug 2015, Xiong Zhang wrote:
> Signed-off-by: Xiong Zhang
Even for a small patch like this, your commit message is inadequate.
First, it's obvious from the code that you're adding a break for one
case. Instead, you should explain what bug you fix. If someone hits this
bug and is look
On 8/14/2015 12:29 PM, Jani Nikula wrote:
On Wed, 12 Aug 2015, Daniel Vetter wrote:
On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote:
On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote:
On 8/12/2015 5:02 PM, Ville Syrjälä wrote:
On Fri, Jul 31, 2015 at 11:3
On Fri, Aug 14, 2015 at 12:13:04PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This is validating from the wrong index.
>
> testing with KASAN found it.
>
> Reported-by: Dave Jones
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
> 1 file changed, 1 i
There is currently conflicting documentation on which steppings the
workaround is needed, up to C vs. forever. However there is post-C
stepping hardware that doesn't report port presence on DDI A, leading to
black screen on eDP. Assume the strap isn't connected, and try to enable
DDI A on these mac
On 13.08.2015 16:14, David Weinehall wrote:
> On Wed, Aug 12, 2015 at 05:19:35PM +0300, Jani Nikula wrote:
>> On Wed, 12 Aug 2015, David Weinehall wrote:
>>> Some more fixup is needed; the bits from Antti's patch
>>> that actually expanded the struct to fully fit the newer
>>> versions of the chil
On Fri, Aug 14, 2015 at 08:40:47AM +0100, Chris Wilson wrote:
> On Fri, Aug 14, 2015 at 12:13:04PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This is validating from the wrong index.
> >
> > testing with KASAN found it.
> >
> > Reported-by: Dave Jones
> > Signed-off-by: Dave Airli
On Thu, Aug 13, 2015 at 01:31:41PM -0700, Jesse Barnes wrote:
git clean fixes this all, at least over here git status is clean.
-Daniel
> ---
> .gitignore | 3 +++
> tests/.gitignore | 13 +
> tools/.gitignore | 8
> 3 files changed, 24 insertions(+)
>
> diff --git
On Thu, Aug 13, 2015 at 04:51:37PM -0700, Bob Paauwe wrote:
> When reducing a xy reflection to a 180 degree rotation, make sure
> only one rotation bit is set. Also by rotating the bit left, we
> can support cases where xy reflection happens with 90/270 degree
> rotation.
>
> Signed-off-by: Bob P
On Wed, Aug 12, 2015 at 07:04:22PM +0300, Ville Syrjälä wrote:
> On Mon, Jul 06, 2015 at 03:09:59PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > While working on CHV DPIO powergating I relized DP .compute_config() was
> > clobbering lane_count etc. stored in intel_d
Hi,
On 13-08-15 16:33, Hans de Goede wrote:
Hi,
On 12-08-15 21:26, Ville Syrjälä wrote:
On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek wrote:
Hi,
this my first build of a 4.2-rc
Looks good to me.
Reviewed-by: Sonika Jindal
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Sivakumar Thulasimani
Sent: Friday, August 7, 2015 3:15 PM
To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i
On Wed, Aug 12, 2015 at 09:34:54PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 31, 2015 at 03:13:52PM +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 on
On Wed, Aug 12, 2015 at 09:24:01PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 31, 2015 at 03:13:57PM +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 on
On Wed, Aug 12, 2015 at 09:49:12PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 31, 2015 at 03:13:58PM +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 on
On Thu, 13 Aug 2015, David Weinehall wrote:
> On Wed, Aug 12, 2015 at 05:19:35PM +0300, Jani Nikula wrote:
>> On Wed, 12 Aug 2015, David Weinehall wrote:
>> > Some more fixup is needed; the bits from Antti's patch
>> > that actually expanded the struct to fully fit the newer
>> > versions of the
On Thu, Aug 13, 2015 at 02:57:38AM +, Zhang, Xiong Y wrote:
> > On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
> > > DDI-E doesn't have the correspondent GMBUS pin.
> > >
> > > We rely on VBT to tell us which one it being used instead.
> > >
> > > The DVI/HDMI on shared port could
On Wed, Aug 12, 2015 at 04:40:03PM +0100, Dave Gordon wrote:
> On 11/08/15 15:44, Arun Siluvery wrote:
> >From: Mika Kuoppala
> >
> >Prevent leaking the if scoping by containing the WA_REG
> >macro inside its own scope.
> >
> >Reported-by: Arun Siluvery
> >Signed-off-by: Mika Kuoppala
> >---
> >
On Wed, Aug 12, 2015 at 04:41:13PM +0100, Dave Gordon wrote:
> On 11/08/15 15:44, Arun Siluvery wrote:
> > From Gen9, Push constant instruction parsing behaviour varies according to
> >whether set shader is enabled or not. If we want legacy behaviour then it
> >can be achieved by disabling set shad
On Thu, Aug 13, 2015 at 03:49:35PM -0700, Ben Widawsky wrote:
> On Thu, Aug 13, 2015 at 10:33:00AM +0300, Joonas Lahtinen wrote:
> > Hi,
> >
> > On ke, 2015-08-12 at 18:35 -0700, Ben Widawsky wrote:
> > > On Wed, Aug 12, 2015 at 03:10:18PM +0300, Joonas Lahtinen wrote:
> > > > On ke, 2015-08-12 at
On Wed, Aug 12, 2015 at 03:43:36PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> This fetches the required firmware image from the filesystem,
> then loads it into the GuC's memory via a dedicated DMA engine.
>
> This patch is derived from GuC loading work originally done by
> Vinit Azad and Be
On Wed, Aug 12, 2015 at 07:35:10PM -0700, O'Rourke, Tom wrote:
> On Wed, Aug 12, 2015 at 07:57:37AM -0700, Gordon, David S wrote:
> > On 12/08/15 15:43, Dave Gordon wrote:
> > > This patch series enables command submission via the GuC. In this mode,
> > > instead of the host CPU driving the execlis
On Thursday, August 13, 2015 10:39:08 PM Sedat Dilek wrote:
>
> --f46d04447e7fc2306e051d3753a5
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Aug 13, 2015 at 6:53 PM, Hans de Goede wrote:
> > Before this commit, the following would happen:
> >
> > a) acpi_video_get_backlight_type() gets c
On Fri, Aug 14, 2015 at 08:27:45AM +, Jindal, Sonika wrote:
> Looks good to me.
> Reviewed-by: Sonika Jindal
Queued for -next, thanks for the patch.
-Daniel
>
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Sivakumar Thulasiman
On Wed, Aug 12, 2015 at 06:44:17PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> As with ILK/SNB wire up the port A HPD on IVB/HSW.
>
> This might be more important on HSW with PSR. BSpec tells us that if the
> automagic link training performed by the hardware fails for s
On Wed, Aug 12, 2015 at 06:33:55PM -0300, Paulo Zanoni wrote:
> We need to test those pixel formats on the FBC code, so let's make
> sure the drawing library works on them first.
>
> Signed-off-by: Paulo Zanoni
gtkdoc update seems to be missing for the igt_draw_rect change. Even more
so that the
On Thu, Aug 13, 2015 at 01:37:49PM +0300, Timo Aaltonen wrote:
> On 13.08.2015 13:36, Timo Aaltonen wrote:
> > On 13.08.2015 13:00, Xiong Zhang wrote:
> >> Signed-off-by: Xiong Zhang
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git
On 08/13/2015 01:29 AM, Tiago Vignatti wrote:
> Hi,
>
> The idea is to create a GEM bo in one process and pass the prime handle of the
> it to another process, which in turn uses the handle only to map and write.
> This could be useful for Chrome OS architecture, where the Web content
> ("unprivile
On Fri, Aug 14, 2015 at 10:53:17AM +0300, Jani Nikula wrote:
> There is currently conflicting documentation on which steppings the
> workaround is needed, up to C vs. forever. However there is post-C
> stepping hardware that doesn't report port presence on DDI A, leading to
> black screen on eDP. A
On Fri, Aug 14, 2015 at 10:24 AM, Hans de Goede wrote:
> Hi,
>
>
> On 13-08-15 16:33, Hans de Goede wrote:
>>
>> Hi,
>>
>> On 12-08-15 21:26, Ville Syrjälä wrote:
>>>
>>> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek
wrote:
On Fri, Aug 14, 2015 at 11:39 AM, Rafael J. Wysocki wrote:
> On Thursday, August 13, 2015 10:39:08 PM Sedat Dilek wrote:
>>
>> --f46d04447e7fc2306e051d3753a5
>> Content-Type: text/plain; charset=UTF-8
>>
>> On Thu, Aug 13, 2015 at 6:53 PM, Hans de Goede wrote:
>> > Before this commit, the followi
On Fri, 14 Aug 2015, Jani Nikula wrote:
> On Thu, 13 Aug 2015, David Weinehall wrote:
>> On Wed, Aug 12, 2015 at 05:19:35PM +0300, Jani Nikula wrote:
>>> On Wed, 12 Aug 2015, David Weinehall
>>> wrote:
>>> > Some more fixup is needed; the bits from Antti's patch
>>> > that actually expanded the
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7140
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Friday, August 14, 2015 11:36:41 AM Sedat Dilek wrote:
> On Fri, Aug 14, 2015 at 11:39 AM, Rafael J. Wysocki
> wrote:
> > On Thursday, August 13, 2015 10:39:08 PM Sedat Dilek wrote:
> >>
> >> --f46d04447e7fc2306e051d3753a5
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >> On Thu, Aug 13,
On Fri, Aug 14, 2015 at 12:16 PM, Rafael J. Wysocki wrote:
> On Friday, August 14, 2015 11:36:41 AM Sedat Dilek wrote:
>> On Fri, Aug 14, 2015 at 11:39 AM, Rafael J. Wysocki
>> wrote:
>> > On Thursday, August 13, 2015 10:39:08 PM Sedat Dilek wrote:
>> >>
>> >> --f46d04447e7fc2306e051d3753a5
>> >
Hi Dave, here's a DP MST fix from Maarten.
BR,
Jani.
The following changes since commit 5677d67ae3949f09f57357241b88222d49b8c782:
drm: Stop resetting connector state to unknown (2015-07-22 14:52:26 +0200)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags
Hi Dave, some i915 display fixes. A couple of backports by Maarten from
our -next to v4.2, and a dithering fix from Daniel.
BR,
Jani.
The following changes since commit f7644cbfcdf03528f0f450f3940c4985b2291f49:
Linux 4.2-rc6 (2015-08-09 15:54:30 -0400)
are available in the git repository at:
Store max dotclock into dev_priv structure so we are able
to filter out the modes that are not supported by our
platforms.
V2:
- limit the max dot clock frequency to max CD clock frequency
for the gen9 and above
- limit the max dot clock frequency to 90% of the max CD clock
frequency for the o
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort.
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DSI.
V2:
-
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to LVDS.
V2:
-
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to HDMI.
V2:
-
From EDID we can read and request higher pixel clock than
our HW can support. This set of patches add checks if
requested pixel clock is lower than the one supported by the HW.
The requested mode is discarded if we cannot support the requested
pixel clock. For example for Cherryview
'cvt 2560 1600
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to CRT.
V2:
-
Information on maximum supported DOT clock frequency to
i915_frequency_info.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 86734be..3df7492
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to SDVO.
V2:
-
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to TV.
V2:
- r
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DVO.
V2:
-
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 by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort
From: Thierry Reding
The gtt.stolen_size field is of type size_t, and so should be printed
using %zu to avoid build warnings on either 32-bit and 64-bit builds.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
> On Thu, Aug 13, 2015 at 02:57:38AM +, Zhang, Xiong Y wrote:
> > > On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
> > > > DDI-E doesn't have the correspondent GMBUS pin.
> > > >
> > > > We rely on VBT to tell us which one it being used instead.
> > > >
> > > > The DVI/HDMI on sha
> On Thu, Aug 13, 2015 at 01:37:49PM +0300, Timo Aaltonen wrote:
> > On 13.08.2015 13:36, Timo Aaltonen wrote:
> > > On 13.08.2015 13:00, Xiong Zhang wrote:
> > >> Signed-off-by: Xiong Zhang
> > >> ---
> > >> drivers/gpu/drm/i915/intel_display.c | 1 +
> > >> 1 file changed, 1 insertion(+)
> > >>
On Fri, Aug 14, 2015 at 12:35:23PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The gtt.stolen_size field is of type size_t, and so should be printed
> using %zu to avoid build warnings on either 32-bit and 64-bit builds.
Or better would be to convert stolen.size to u32 so that we kno
Everytime we use the logical context with execlists it becomes dirty (as
the hardware will write the new register values afterwards, as well as
the GPU state that will be used). We need to then flag the context as
dirty everytime since after a swap-out/swap-in cycle the dirty flag will
be cleared,
On Fri, Aug 14, 2015 at 12:59:19PM +0100, Chris Wilson wrote:
> Everytime we use the logical context with execlists it becomes dirty (as
> the hardware will write the new register values afterwards, as well as
> the GPU state that will be used). We need to then flag the context as
> dirty everytime
On Thu, Aug 13, 2015 at 01:31:24PM -0700, Jesse Barnes wrote:
> There was a lot of duplication going on... Mark as basic while we're at
> it as these should never fail.
>
> Signed-off-by: Jesse Barnes
> ---
> tests/Makefile.sources | 1 +
> tests/gem_storedw_loop.c | 181
>
On Thu, Aug 13, 2015 at 01:31:25PM -0700, Jesse Barnes wrote:
> Signed-off-by: Jesse Barnes
Absolutely-Acked-by: Daniel Vetter
btw this will cause lots of hilarity because of lockdep and vt and shit
like that. We probably need to grill gregkh a bit more with patches he's
not merging ...
-Daniel
On Thu, Aug 13, 2015 at 01:31:26PM -0700, Jesse Barnes wrote:
> Reduces runtime a lot...
>
> Signed-off-by: Jesse Barnes
> ---
> tests/drv_module_reload_basic | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
>
On Thu, Aug 13, 2015 at 01:31:27PM -0700, Jesse Barnes wrote:
> They're testing basic functionality and don't involve stress or race
> induction.
>
> Signed-off-by: Jesse Barnes
These are more stress-tests in nature I think. For basic testscases of
prime I'd recommend instead
prime_self_import:
On Thu, Aug 13, 2015 at 01:31:28PM -0700, Jesse Barnes wrote:
> Fundamental and simple functionality.
>
> Signed-off-by: Jesse Barnes
Mark entire testcase as basic instead to catch future extensions?
getparams should always complete super-fast I think.
-Daniel
> ---
> tests/drv_getparams.c | 4
On Thu, Aug 13, 2015 at 01:31:29PM -0700, Jesse Barnes wrote:
> debugfs may not be mounted, but sysfs should always be restored after
> suspend or hibernate.
>
> Signed-off-by: Jesse Barnes
We already have a suspend/resume testcase in kms_pipc_crc_basic. Do we
have enough budget for this one?
>
On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote:
> Need some LRC tests in the 'basic' subset, and this is a good simple
> one.
>
> Signed-off-by: Jesse Barnes
This is just a testcase for a very specific lrc corner case. We do already
exercise lrc with all the other execbuf testcases
On Thu, Aug 13, 2015 at 01:31:31PM -0700, Jesse Barnes wrote:
> We should be able to create small and moderate sized objects quickly and
> without errors.
>
> Signed-off-by: Jesse Barnes
They're all super-fast basic testcases for api cornercases. I'd vote to
rename the entire testcase to gem_mma
On Thu, Aug 13, 2015 at 01:31:32PM -0700, Jesse Barnes wrote:
> These ones should always pass and are fairly quick.
>
> Signed-off-by: Jesse Barnes
> ---
> tests/gem_mmap_gtt.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap
On Thu, Aug 13, 2015 at 01:31:33PM -0700, Jesse Barnes wrote:
> These should always pass.
>
> Signed-off-by: Jesse Barnes
If they're fast enough ... Acked-by: Daniel Vetter
> ---
> tests/gem_pread.c | 2 +-
> tests/gem_pwrite.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> d
On Fri, Aug 14, 2015 at 02:33:25PM +0200, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:31PM -0700, Jesse Barnes wrote:
> > We should be able to create small and moderate sized objects quickly and
> > without errors.
> >
> > Signed-off-by: Jesse Barnes
>
> They're all super-fast basic tes
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 41615b7ab6113248748c5734981009f1a0ee499b
commit: 9a9cb6512e140a84b589a6e99f4e71b0397b6685 [543/545] drm/i915: Debugfs
interface for GuC submission statistics
reproduce:
# apt-get install sparse
git checkout 9a9cb6512
By running igt/store_dword_loop_render on BXT we can hit a coherency
problem where the seqno written at GPU command completion time is not
seen by the CPU. This results in __i915_wait_request seeing the stale
seqno and not completing the request (not considering the lost
interrupt/GPU reset mechani
Due to a coherency issue on BXT A steppings we can't guarantee a
coherent view of cached GPU mappings, so fall back to uncached mappings.
Note that this still won't fix cases where userspace expects a coherent
view without synchronizing (via a set domain call). It still makes sense
to limit the ker
This is a v2 of [1]. Since v1 the HW team confirmed that there is an
HW issue in A steppings with the GPU/CPU snoop logic, which explains why
we need this workaround.
In v2 I fixed a typo and limited the workaround to A steppings, since
in later steppings this problem is fixed.
[1]
http://lists.f
On Thu, Aug 13, 2015 at 01:31:34PM -0700, Jesse Barnes wrote:
> These simple tests should always pass.
>
> Signed-off-by: Jesse Barnes
Imo shouldn't be part of the basic set, they thrash the machine quite
badly. Especially gem_tiled_pread_pwrite thrashes all of memory, so nack
on that one from m
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 41615b7ab6113248748c5734981009f1a0ee499b
commit: a08d99201d3133c4a59f9f04554fe03dc039631d [542/545] drm/i915: Integrate
GuC-based command submission
reproduce: make htmldocs
All error/warnings (new ones prefixed by >>):
On Thu, Aug 13, 2015 at 01:31:35PM -0700, Jesse Barnes wrote:
> We should always be able to create simple and tiled objects.
>
> Signed-off-by: Jesse Barnes
There's are all super-fast abi tests which don't even do a modeset. Imo
add them all by renaming the testcase to kms_addfb_basic. The real
On Thu, Aug 13, 2015 at 01:31:36PM -0700, Jesse Barnes wrote:
> Need some simple vblank coverage in the BAT list.
>
> Signed-off-by: Jesse Barnes
This testcase relies upon fbcon to have enabled pipe 0, which means it
spuriously skips (when fbcon is disabled or when it's blanked the screen)
until
On Fri, Aug 14, 2015 at 02:44:14PM +0200, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:36PM -0700, Jesse Barnes wrote:
> > Need some simple vblank coverage in the BAT list.
> >
> > Signed-off-by: Jesse Barnes
>
> This testcase relies upon fbcon to have enabled pipe 0, which means it
> sp
On Thu, Aug 13, 2015 at 01:31:37PM -0700, Jesse Barnes wrote:
> We should be able to adjust the backlight and observe changes in sysfs.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Daniel Vetter
> ---
> tests/pm_backlight.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --g
On Thu, Aug 13, 2015 at 01:31:38PM -0700, Jesse Barnes wrote:
> These always need to pass for basic PM functionality.
>
> Signed-off-by: Jesse Barnes
> ---
> tests/pm_rpm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index d509f
On Fri, Aug 14, 2015 at 03:38:55PM +0300, Imre Deak wrote:
> This is a v2 of [1]. Since v1 the HW team confirmed that there is an
> HW issue in A steppings with the GPU/CPU snoop logic, which explains why
> we need this workaround.
I've been testing this extensively, and I do believe we can use cl
On Fri, Aug 14, 2015 at 03:35:32PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> drivers/gpu/drm/exynos/exynos_drm_drv.c:290:2: warning: initialization from
> incompatible pointer typ
On Fri, Aug 14, 2015 at 01:37:46PM +0100, Chris Wilson wrote:
> On Fri, Aug 14, 2015 at 02:33:25PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 13, 2015 at 01:31:31PM -0700, Jesse Barnes wrote:
> > > We should be able to create small and moderate sized objects quickly and
> > > without errors.
> > >
On Fri, Aug 14, 2015 at 01:03:21PM +0300, Mika Kahola wrote:
> Store max dotclock into dev_priv structure so we are able
> to filter out the modes that are not supported by our
> platforms.
>
> V2:
> - limit the max dot clock frequency to max CD clock frequency
> for the gen9 and above
> - limit
On Thu, Aug 13, 2015 at 01:31:39PM -0700, Jesse Barnes wrote:
> Simple variants that don't do multiple output or interruptible testing.
>
> Signed-off-by: Jesse Barnes
> ---
> tests/kms_flip.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/tests/kms_flip.c
There's so much scaler debugging messages that it makes other debugging
hard. Remove them.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_atomic.c | 3 ---
drivers/gpu/drm/i915/intel_display.c | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
On Fri, Aug 14, 2015 at 01:03:26PM +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 by the HW. The requested mode is discarded
> if we cannot
On Thu, Aug 13, 2015 at 01:31:40PM -0700, Jesse Barnes wrote:
> Should cover simple, single CRTC mode sets.
>
> Signed-off-by: Jesse Barnes
> ---
> tests/kms_setmode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> index 8276
On Fri, 2015-08-14 at 15:55 +0300, Ville Syrjälä wrote:
> On Fri, Aug 14, 2015 at 01:03:21PM +0300, Mika Kahola wrote:
> > Store max dotclock into dev_priv structure so we are able
> > to filter out the modes that are not supported by our
> > platforms.
> >
> > V2:
> > - limit the max dot clock fr
On Fri, Aug 14, 2015 at 10:30:26AM +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 09:34:54PM +0300, Ville Syrjälä wrote:
> > On Fri, Jul 31, 2015 at 03:13:52PM +0300, Mika Kahola wrote:
> > > It is possible the we request to have a mode that has
> > > higher pixel clock than our HW can suppo
On Fri, Aug 14, 2015 at 01:03:24PM +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 by the HW. The requested mode is discarded
> if we cannot
2015-08-14 9:50 GMT-03:00 Daniel Vetter :
> On Thu, Aug 13, 2015 at 01:31:38PM -0700, Jesse Barnes wrote:
>> These always need to pass for basic PM functionality.
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> tests/pm_rpm.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --g
On Fri, Aug 14, 2015 at 01:03:30PM +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 by the HW. The requested mode is discarded
> if we cannot
On Fri, Aug 14, 2015 at 03:38:57PM +0300, Imre Deak wrote:
> Due to a coherency issue on BXT A steppings we can't guarantee a
> coherent view of cached GPU mappings, so fall back to uncached mappings.
> Note that this still won't fix cases where userspace expects a coherent
> view without synchroni
On Fri, Aug 14, 2015 at 04:03:55PM +0300, Ville Syrjälä wrote:
> On Fri, Aug 14, 2015 at 10:30:26AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 12, 2015 at 09:34:54PM +0300, Ville Syrjälä wrote:
> > > On Fri, Jul 31, 2015 at 03:13:52PM +0300, Mika Kahola wrote:
> > > > It is possible the we request
On Fri, Aug 14, 2015 at 03:38:56PM +0300, Imre Deak wrote:
> By running igt/store_dword_loop_render on BXT we can hit a coherency
> problem where the seqno written at GPU command completion time is not
> seen by the CPU. This results in __i915_wait_request seeing the stale
> seqno and not completin
On Fri, Aug 14, 2015 at 01:03:20PM +0300, Mika Kahola wrote:
> From EDID we can read and request higher pixel clock than
> our HW can support. This set of patches add checks if
> requested pixel clock is lower than the one supported by the HW.
> The requested mode is discarded if we cannot support
On Fri, Aug 14, 2015 at 03:59:53PM +0300, Jani Nikula wrote:
> There's so much scaler debugging messages that it makes other debugging
> hard. Remove them.
>
> Signed-off-by: Jani Nikula
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 3 ---
> dri
On Fri, 2015-08-14 at 16:09 +0300, Ville Syrjälä wrote:
> On Fri, Aug 14, 2015 at 01:03:24PM +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
> > s
On pe, 2015-08-14 at 13:49 +0100, Chris Wilson wrote:
> On Fri, Aug 14, 2015 at 03:38:55PM +0300, Imre Deak wrote:
> > This is a v2 of [1]. Since v1 the HW team confirmed that there is an
> > HW issue in A steppings with the GPU/CPU snoop logic, which explains why
> > we need this workaround.
>
>
On pe, 2015-08-14 at 14:11 +0100, Chris Wilson wrote:
> On Fri, Aug 14, 2015 at 03:38:57PM +0300, Imre Deak wrote:
> > Due to a coherency issue on BXT A steppings we can't guarantee a
> > coherent view of cached GPU mappings, so fall back to uncached mappings.
> > Note that this still won't fix cas
On pe, 2015-08-14 at 14:12 +0100, Chris Wilson wrote:
> On Fri, Aug 14, 2015 at 03:38:56PM +0300, Imre Deak wrote:
> > By running igt/store_dword_loop_render on BXT we can hit a coherency
> > problem where the seqno written at GPU command completion time is not
> > seen by the CPU. This results in
On Fri, Aug 14, 2015 at 04:26:29PM +0300, Imre Deak wrote:
> On pe, 2015-08-14 at 13:49 +0100, Chris Wilson wrote:
> > On Fri, Aug 14, 2015 at 03:38:55PM +0300, Imre Deak wrote:
> > > This is a v2 of [1]. Since v1 the HW team confirmed that there is an
> > > HW issue in A steppings with the GPU/CPU
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7141
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
1 - 100 of 164 matches
Mail list logo
