Re: [Intel-gfx] [PATCH 5/6] drm/i915: give G45 and GM45 their own platform enums

On ke, 2016-11-30 at 17:43 +0200, Jani Nikula wrote: > Distinguish them better. > > Signed-off-by: Jani Nikula Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] [PATCH 1/6] drm/i915: replace platform flags with a platform enum

On ke, 2016-11-30 at 17:43 +0200, Jani Nikula wrote: > The platform flags in device info are (mostly) mutually > exclusive. Replace the flags with an enum. Add the platform enum also > for platforms that previously didn't have a flag, and give them codename > logging in dmesg. > > Pineview

Re: [Intel-gfx] [PATCH] drm: Initialise drm_mm.head_node.allocated

On Wed, Nov 30, 2016 at 08:51:26PM +, Chris Wilson wrote: > commit 202b52b7fbf7 ("drm: Track drm_mm nodes with an interval tree") > introduced a requirement that the special drm_mm.head_node was > initialised and marked as not being allocated. It is a very special node > that has no side but

[Intel-gfx] ✗ Fi.CI.BAT: failure for Introduce drmfs pseudo filesystem for drm subsystem

== Series Details == Series: Introduce drmfs pseudo filesystem for drm subsystem URL : https://patchwork.freedesktop.org/series/16203/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/opregion.o CC [M] drivers/gpu/drm/i915/gvt/mmio.o LD

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Initialise drm_mm.head_node.allocated

> == Series Details == > > Series: drm: Initialise drm_mm.head_node.allocated > URL : https://patchwork.freedesktop.org/series/16183/ > State : warning > > == Summary == > > Series 16183v1 drm: Initialise drm_mm.head_node.allocated >

[Intel-gfx] [RFC 2/3] drm: Register drmfs filesystem from drm init

From: Swati Dhingra During drm module initialization, drm_core_init initializes the drmfs filesystem and register this with kernel. A driver specific directory is created inside drmfs root, and dentry of this directory is saved for subsequent use by the driver (e.g.

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/perf: Treat u64 in uabi as a normal integer

> == Series Details == > > Series: drm/i915/perf: Treat u64 in uabi as a normal integer > URL : https://patchwork.freedesktop.org/series/16171/ > State : warning > > == Summary == > > Series 16171v1 drm/i915/perf: Treat u64 in uabi as a normal integer >

[Intel-gfx] [RFC 3/3] drm/i915: Creating guc log file in drmfs instead of debugfs

From: Swati Dhingra In the current scenario, the relay API fit well only with debugfs, due to availability of parent dentry. Any other existing filesystem was not feasible for holding guc logs, due to incompatibility with relay. But this makes the guc_log file

[Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces

From: Swati Dhingra The patch introduces a new pseudo filesystem type, named 'drmfs' which is intended to house the files for the data generated by drm subsystem that cannot be accommodated by any of the existing filesystems. The filesystem is modelled on the lines of

[Intel-gfx] [RFC 0/3] Introduce drmfs pseudo filesystem for drm subsystem

From: Swati Dhingra Currently, for the purpose of providing output debug/loggging/crc and various other kinds of data from DRM layer to userspace, we don't have a standard filesystem, which would suffice for all the usecases. The filesystems used currently such as

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios

== Series Details == Series: series starting with [1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios URL : https://patchwork.freedesktop.org/series/16200/ State : success == Summary == Series 16200v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for HuC Loading Patches

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/16188/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/opregion.o CC [M] drivers/gpu/drm/i915/gvt/mmio.o CC [M] drivers/gpu/drm/i915/gvt/display.o CC [M]

[Intel-gfx] [PATCH 2/2] drm/i915/audio: extend audio sync rate support for DP MST

From: Libin Yang Remove the type judgement in i915_audio_component_sync_audio_rate(). Audio rate sync is necessary for all i915 digital audio now. Signed-off-by: Libin Yang --- drivers/gpu/drm/i915/intel_audio.c | 4 +--- 1 file changed, 1

[Intel-gfx] [PATCH 1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios

From: Libin Yang In initialization, audio driver will call functions get_eld() and etc. But at that time, audio driver may not know whether it is DP MST or not. In the original function get_saved_enc(), if it is DP MST, it requires to set the pipe to the correct

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Initialise drm_mm.head_node.allocated

== Series Details == Series: drm: Initialise drm_mm.head_node.allocated URL : https://patchwork.freedesktop.org/series/16183/ State : warning == Summary == Series 16183v1 drm: Initialise drm_mm.head_node.allocated https://patchwork.freedesktop.org/api/1.0/series/16183/revisions/1/mbox/ Test

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/perf: Treat u64 in uabi as a normal integer

== Series Details == Series: drm/i915/perf: Treat u64 in uabi as a normal integer URL : https://patchwork.freedesktop.org/series/16171/ State : warning == Summary == Series 16171v1 drm/i915/perf: Treat u64 in uabi as a normal integer

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: introduce platform enum

== Series Details == Series: drm/i915: introduce platform enum URL : https://patchwork.freedesktop.org/series/16170/ State : success == Summary == Series 16170v1 drm/i915: introduce platform enum https://patchwork.freedesktop.org/api/1.0/series/16170/revisions/1/mbox/ Test kms_busy:

[Intel-gfx] ✗ Fi.CI.BAT: failure for GEM object create and driver init dev_priv cleanups

== Series Details == Series: GEM object create and driver init dev_priv cleanups URL : https://patchwork.freedesktop.org/series/16162/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/sched_policy.o CC [M] drivers/gpu/drm/i915/gvt/render.o CC [M]

Re: [Intel-gfx] [PATCH 2/2] drm/i915/audio: Extend audio sync rate support for DP MST

>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Wednesday, November 30, 2016 11:52 PM >To: Yang, Libin ; intel-gfx@lists.freedesktop.org; >ville.syrj...@linux.intel.com; Vetter, Daniel ; >Pandiyan,

[Intel-gfx] [RFC i-g-t v3 3/5] igt_kms: Add helpers for watching for sysfs hotplug events

This adds some basic helpers for connecting to udev and watching for sysfs hotplug events. Signed-off-by: Lyude Changes since v1: - Remove unused arg from documentation --- lib/igt_kms.c | 108 ++ lib/igt_kms.h | 6

[Intel-gfx] [RFC i-g-t v3 2/5] igt_aux: Add igt_set_autoresume_delay()

The default autoresume delay is about 5 seconds. It's possible on a system that's not very fast this might not be a long enough time, since an asynchronous hotplug event we scheduled on the chamelium that was intended to happen during suspend could happen before we actually manage to suspend. So,

[Intel-gfx] [RFC i-g-t v3 0/5] Add support for the Chamelium

Latest version of my series for adding Chamelium Major changes: - Since I finally figured out why Video capturing wasn't working on my Chamelium, add the rest of the CRC functions and fix some of the existing ones - Doc fixes Lyude (5): igt_aux: Add igt_skip_without_suspend_support()

[Intel-gfx] [RFC i-g-t v3 1/5] igt_aux: Add igt_skip_without_suspend_support()

Since all of the chamelium calls are blocking, we need to be able to make suspend/resume tests with it multi-threaded. As such, it's not the best idea to rely on igt_system_suspend_autoresume() for skipping tests on systems without suspend/resume support since we could accidentally leave the

[Intel-gfx] [RFC i-g-t v3 4/5] igt_debugfs: Make igt_crc_to_string() work with other CRC types

Intel GPUs have CRC values with 5 n_words, but the Chamelium's definitely doesn't. So make igt_crc_to_string() a little smarter so it can handle this. Signed-off-by: Lyude --- lib/igt_debugfs.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [RFC i-g-t v3 5/5] Add support for hotplug testing with the Chamelium

For the purpose of testing things such as hotplugging and bad monitors, the ChromeOS team ended up designing a neat little device known as the Chamelium. More information on this can be found here: https://www.chromium.org/chromium-os/testing/chamelium This adds support for a couple of

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

From: Peter Antoine HuC firmware css header has almost exactly same definition as GuC firmware except for the sw_version. Also, add a new member fw_type into intel_uc_fw to indicate what kind of fw it is. So, the loader will pull right sw_version from header. v2:

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

From: Peter Antoine Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. v8: rebased. v9: rebased. v10: rebased. v11: rebased on top of drm-tip Tested-by: Xiang Haihao

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

This patch adds the HuC Loading for the BXT by using the updated file construction. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased on top of drm-tip Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa Reviewed-by: Jeff McGee

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

From: Peter Antoine This patch will allow for getparams to return the status of the HuC. As the HuC has to be validated by the GuC this patch uses the validated status to show when the HuC is loaded and ready for use. You cannot use the loaded status as with the GuC as

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

This patch adds the support to load HuC on KBL Version 2.0 v2: rebased. v3: rebased on top of drm-tip Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa Reviewed-by: Jeff McGee --- drivers/gpu/drm/i915/intel_huc_loader.c | 16

[Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

From: Peter Antoine The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

From: Peter Antoine Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2: rebased on-top of drm-intel-nightly. removed if(HAS_GUC()) before the guc call.

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

These patches add HuC loading support. The GuC is required to authenticate the HuC. The userspace patches that check for a fully loaded HuC firmware and use it can be found at: https://lists.freedesktop.org/archives/libva/2016-September/004554.html

Re: [Intel-gfx] linux-next: problems fetching the drm-intel, etc trees

Hi Rob, On Wed, 30 Nov 2016 17:49:24 -0500 Rob Clark wrote: > > yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh > git urls for folks who have push access work fine).. although it has > worked for me a couple times today, given enough time. > > (not

Re: [Intel-gfx] linux-next: problems fetching the drm-intel, etc trees

yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh git urls for folks who have push access work fine).. although it has worked for me a couple times today, given enough time. (not sure if we have github/etc mirrors somewhere? I do have a github clone of mesa which is up to

[Intel-gfx] linux-next: problems fetching the drm-intel, etc trees

Hi all, There is something seriaously wrong with anongit.freedesktop.org this morning. Fething trees from there takes an enormous amount of time - so long that I had to abort the fetches ... -- Cheers, Stephen Rothwell ___ Intel-gfx mailing list

[Intel-gfx] [PATCH] drm: Initialise drm_mm.head_node.allocated

commit 202b52b7fbf7 ("drm: Track drm_mm nodes with an interval tree") introduced a requirement that the special drm_mm.head_node was initialised and marked as not being allocated. It is a very special node that has no side but has a hole that represents the drm_mm address space, and holds the list

Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

On Tue, Nov 29, 2016 at 05:00:55PM +, Robert Bragg wrote: > This adds a 'Perf' section to i915.rst with the following sub sections: > - Overview > - Comparison with Core Perf > - i915 Driver Entry Points > - i915 Perf Stream > - i915 Perf Observation Architecture Stream > - All i915 Perf

Re: [Intel-gfx] [PATCH] drm/i915: Remove dummy i915_kick_out_firmware_fb

On Wed, Nov 30, 2016 at 11:49:23AM +, Chris Wilson wrote: > On Wed, Nov 30, 2016 at 12:01:31PM +0100, Daniel Vetter wrote: > > Since > > > > commit 44adece57e2604cec8527a499b48e4d584ab53b8 > > Author: Daniel Vetter > > Date: Wed Aug 10 18:52:34 2016 +0200 > > > >

Re: [Intel-gfx] [PULL] GVT-g device model fix

On Wed, Nov 30, 2016 at 04:23:02PM +0800, Zhenyu Wang wrote: > > Hi, > > Here's current left GVT-g device model bug fixes for pull. Since 4.10 feature freeze is already done, this needs to go into drm-intel-next-fixes. Jani, can you pls pull? Thanks, Daniel > > Thanks. > > --- > > The

[Intel-gfx] [PULL] drm-misc-fixes

Hi Dave, Just one patch from Michel I picked up for -fixes. Cheers, Daniel The following changes since commit e5517c2a5a49ed5e99047008629f1cd60246ea0e: Linux 4.9-rc7 (2016-11-27 13:08:04 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Remove dummy i915_kick_out_firmware_fb

== Series Details == Series: drm/i915: Remove dummy i915_kick_out_firmware_fb URL : https://patchwork.freedesktop.org/series/16158/ State : warning == Summary == Series 16158v1 drm/i915: Remove dummy i915_kick_out_firmware_fb

Re: [Intel-gfx] [Regression report] Weekly regression report WW48

Here is the link to the FDO Bugzilla to see this bug list, I'll attach it to weekly report

Re: [Intel-gfx] [PATCH 1/3] assembler: Fix assert when setting 3src sources

Hi, This series is Reviewed-by: Lionel Landwerlin Thanks! On 30/11/16 01:15, Kristian H. Kristensen wrote: We need to map the type to the 3src encoding before comparing to insn->bits1.da3src.src_reg_type, which is 3src encoded. Signed-off-by: Kristian H.

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Implement Link Rate fallback on Link training failure

On Wed, Nov 30, 2016 at 09:36:33AM +0100, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:30:33PM -0800, Manasi Navare wrote: > > If link training at a link rate optimal for a particular > > mode fails during modeset's atomic commit phase, then we > > let the modeset complete and then retry. We

Re: [Intel-gfx] [PATCH] drm/i915/perf: Treat u64 in uabi as a normal integer

On 30 November 2016 at 16:46, Chris Wilson wrote: > Forgo marking up the u64 integer representing a user pointer as this > just annoys sparse. The conversion from u64 to a user pointer is managed > by u64_to_user_ptr(). > > Fixes: eec688e1420d ("drm/i915: Add i915 perf

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Implement Link Rate fallback on Link training failure

On Wed, Nov 30, 2016 at 09:36:33AM +0100, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:30:33PM -0800, Manasi Navare wrote: > > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work) > > +{ > > + struct intel_connector *intel_connector; > > + struct drm_connector *connector;

[Intel-gfx] [PATCH] drm/i915/perf: Treat u64 in uabi as a normal integer

Forgo marking up the u64 integer representing a user pointer as this just annoys sparse. The conversion from u64 to a user pointer is managed by u64_to_user_ptr(). Fixes: eec688e1420d ("drm/i915: Add i915 perf infrastructure") Signed-off-by: Chris Wilson Cc: Robert

Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

On 29 November 2016 at 17:00, Robert Bragg wrote: > This adds a 'Perf' section to i915.rst with the following sub sections: > - Overview > - Comparison with Core Perf > - i915 Driver Entry Points > - i915 Perf Stream > - i915 Perf Observation Architecture Stream > - All i915

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Implement Link Rate fallback on Link training failure

On Wed, Nov 30, 2016 at 09:36:33AM +0100, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:30:33PM -0800, Manasi Navare wrote: > > If link training at a link rate optimal for a particular > > mode fails during modeset's atomic commit phase, then we > > let the modeset complete and then retry. We

Re: [Intel-gfx] [PATCH 30/37] drm/i915: Use drm_framebuffer_plane_{width, height}() where possible

On Fri, Nov 18, 2016 at 09:53:06PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace drm_format_plane_{width,height}() usage with > drm_framebuffer_plane_{width,height}() to avoid the lookup of the format > info. > > Cc:

Re: [Intel-gfx] [PATCH 21/37] drm/i915: Populate fb->format early for inherited fbs

On Wed, Nov 30, 2016 at 04:42:23PM +0100, Daniel Vetter wrote: > On Fri, Nov 18, 2016 at 09:52:57PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Make sure the framebuffer format info is available as early as possible > > for fbs we

Re: [Intel-gfx] [PATCH 28/37] drm/i915: Store a pointer to the pixel format info for fbc

On Fri, Nov 18, 2016 at 09:53:04PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rather than store the pixel format and look up the format info as > needed, let's just store a pointer to the format info directly > and speed up our lookups.

Re: [Intel-gfx] [PATCH 30/37] drm/i915: Use drm_framebuffer_plane_{width, height}() where possible

On Fri, Nov 18, 2016 at 09:53:06PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace drm_format_plane_{width,height}() usage with > drm_framebuffer_plane_{width,height}() to avoid the lookup of the format > info. > > Cc:

Re: [Intel-gfx] [PATCH 24/37] drm/i915: Eliminate the ugly 'fb?:' constructs from the ilk/skl wm code

On Wed, Nov 30, 2016 at 04:51:33PM +0100, Daniel Vetter wrote: > On Fri, Nov 18, 2016 at 09:53:00PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Don't access plane_state->fb until we know the plane to be visible. > > It it's visible,

Re: [Intel-gfx] [PATCH 21/37] drm/i915: Populate fb->format early for inherited fbs

On Wed, Nov 30, 2016 at 04:42:23PM +0100, Daniel Vetter wrote: > On Fri, Nov 18, 2016 at 09:52:57PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Make sure the framebuffer format info is available as early as possible > > for fbs we

Re: [Intel-gfx] [PATCH 2/2] drm/i915/audio: Extend audio sync rate support for DP MST

On Wed, 30 Nov 2016, "Yang, Libin" wrote: >>-Original Message- >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >>Sent: Wednesday, November 30, 2016 12:34 AM >>To: Yang, Libin ; intel-gfx@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH 24/37] drm/i915: Eliminate the ugly 'fb?:' constructs from the ilk/skl wm code

On Fri, Nov 18, 2016 at 09:53:00PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Don't access plane_state->fb until we know the plane to be visible. > It it's visible, it will have an fb, and thus we don't have to > consider the NULL fb

Re: [Intel-gfx] [PATCH 21/37] drm/i915: Populate fb->format early for inherited fbs

On Fri, Nov 18, 2016 at 09:52:57PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make sure the framebuffer format info is available as early as possible > for fbs we inherit from the BIOS. This will allow us to use the fb as > if it was

[Intel-gfx] [PATCH 5/6] drm/i915: give G45 and GM45 their own platform enums

Distinguish them better. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 8 +--- drivers/gpu/drm/i915/i915_pci.c | 4 ++-- drivers/gpu/drm/i915/intel_device_info.c | 3 ++- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git

[Intel-gfx] [PATCH 2/6] drm/i915: keep intel device info structs in gen based order

Move G33 and Pineview higher up in the list. Add a couple of blank lines for OCD while at it. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_pci.c | 32 ++-- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git

[Intel-gfx] [PATCH 6/6] drm/i915: use platform enum instead of duplicating PCI ID if possible

Duplicating the PCI ID for IS_FOO checks is redundant for a bunch of platforms. Simplify. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 3/6] drm/i915: rename BROADWATER and CRESTLINE to I965G and I965GM, respectively

Add more consistency to our naming. Pineview remains the outlier. Keep using code names for gen5+. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 8

[Intel-gfx] [PATCH 1/6] drm/i915: replace platform flags with a platform enum

The platform flags in device info are (mostly) mutually exclusive. Replace the flags with an enum. Add the platform enum also for platforms that previously didn't have a flag, and give them codename logging in dmesg. Pineview remains an exception, the platform being G33 for that. v2: Sort enum

[Intel-gfx] [PATCH 0/6] drm/i915: introduce platform enum

The platform enum patch + some sugar coating on top. BR, Jani. Jani Nikula (6): drm/i915: replace platform flags with a platform enum drm/i915: keep intel device info structs in gen based order drm/i915: rename BROADWATER and CRESTLINE to I965G and I965GM, respectively drm/i915: add

[Intel-gfx] [PATCH 4/6] drm/i915: add some more "i" in platform names for consistency

Consistency FTW. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +- drivers/gpu/drm/i915/i915_pci.c | 4 ++--

Re: [Intel-gfx] [PATCH 17/37] drm/i915: Set fb->dev early on for inherited fbs

On Fri, Nov 18, 2016 at 09:52:53PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We want the fbs inherited from the BIOS to be more or less fully working > prior to actually registering them. This will allow us to just pass the > fb to

Re: [Intel-gfx] [PATCH 01/37] drm/i915: Add local 'fb' variables

On Fri, Nov 18, 2016 at 09:52:37PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add a local 'fb' variable to a few places to get rid of the > 'crtc->primary->fb' stuff. Looks neater and helps me with my poor > coccinelle skills later. > >

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: Fix CRC based atomic correctness test

Op 29-11-16 om 14:57 schreef Mika Kahola: > Fixes issues on kms_plane_multiple i-g-t test found when running CI tests > > v1: > - don't use tiling for cursor plane (Ville) > - for y/yf tiling check that the platform is at least GEN9 (Ville) > > Cc: Ville Syrjala >

Re: [Intel-gfx] [PATCH v2] drm/i915: Create a common GEN9_LP_FEATURE.

On ma, 2016-11-14 at 16:19 +0200, Ander Conselvan de Oliveira wrote: > From: Rodrigo Vivi > > The following LP platform inherits a lot of this platform > So let's simplify here to re-use this later. > > v2: Keep ddb_size out of the new macro. > > Signed-off-by: Rodrigo

Re: [Intel-gfx] [PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer

On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote: > On 11/24/16 at 10:53am, Jani Nikula wrote: > > On Thu, 24 Nov 2016, Dave Young wrote: > > > I see a lot of below warning: > > > > No, we must not hide this under the carpet. There's a bug at fdo about > > this, and

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Make gmbus setup take dev_priv

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > Commit message. > Signed-off-by: Tvrtko Ursulin With that, Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen

Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization

On ti, 2016-11-29 at 23:00 +0200, Ville Syrjälä wrote: > [...] > > > > > There is a slight concern on g4x/vlv/chv that an AUX interrupts > > > > > would > > > > > trigger the hpd irq handler, which doesn't realize it's supposed > > > > > to > > > > > ignore the actual hpd bits in

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Make various init functions take dev_priv

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Like GEM init, GUC init, MOCS init and context creation. > > Enables them to lose dev_priv locals. > > Signed-off-by: Tvrtko Ursulin Keeps pdev \o/

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Make GEM object create and create from data take dev_priv

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Makes all GEM object constructors consistent. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Joonas Lahtinen Regards,

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Make GEM object alloc/free and stolen created take dev_priv

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Where it is more appropriate and also to be consistent with > the direction of the driver. > > Also inline object alloc/free since they are just wrappers > around kmem_cache_alloc/free.

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Make intel_pm_setup take dev_priv

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin With commit message; Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open

Re: [Intel-gfx] [PATCH 09/10] drm/i915: Make i915_save/restore_state and intel_i2c_reset take dev_priv

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > Empty commit message is strictly forbidden. At least repeat the title with a couple more word. > Signed-off-by: Tvrtko Ursulin Again, keep the 'pdev' and this

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Make i915_destroy_error_state take dev_priv

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Since it does not need dev at all. > > Also change the stored pointer in struct i915_error_state_file_priv > to i915. > > Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 04/10] drm/i915: More GEM init dev_priv cleanup

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center

Re: [Intel-gfx] [PATCH 00/10] GEM object create and driver init dev_priv cleanups

On Wed, Nov 30, 2016 at 11:35:30AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Autumn of churn continues. :) > > This series tidies GEM object construction to take dev_priv instead of dev > in all cases and also does a bit of random tidy in the driver

Re: [Intel-gfx] [PATCH 05/10] drm/i915: dev_priv cleanup in bridge/bar/mmio init code

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin > -static int i915_mmio_setup(struct drm_device *dev) > +static int i915_mmio_setup(struct drm_i915_private *dev_priv) >  { > -

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Unexport VGA switcheroo functions

On ke, 2016-11-30 at 11:35 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > They are only used in i915_drv.c so a forward declaration is enough. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915: Remove dummy i915_kick_out_firmware_fb

On Wed, Nov 30, 2016 at 12:01:31PM +0100, Daniel Vetter wrote: > Since > > commit 44adece57e2604cec8527a499b48e4d584ab53b8 > Author: Daniel Vetter > Date: Wed Aug 10 18:52:34 2016 +0200 > > drm/fb-helper: Add a dummy remove_conflicting_framebuffers > > the drm

[Intel-gfx] [PATCH 05/10] drm/i915: dev_priv cleanup in bridge/bar/mmio init code

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 52 +++-- 1 file changed, 19 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH 02/10] drm/i915: Make GEM object create and create from data take dev_priv

From: Tvrtko Ursulin Makes all GEM object constructors consistent. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h| 9 + drivers/gpu/drm/i915/i915_gem.c| 20 ++--

[Intel-gfx] [PATCH 04/10] drm/i915: More GEM init dev_priv cleanup

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 8 drivers/gpu/drm/i915/i915_drv.h | 8 drivers/gpu/drm/i915/i915_gem.c | 10 +++---

[Intel-gfx] [PATCH 09/10] drm/i915: Make i915_save/restore_state and intel_i2c_reset take dev_priv

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 6 +++--- drivers/gpu/drm/i915/i915_suspend.c | 22 +-

[Intel-gfx] [PATCH 07/10] drm/i915: Make gmbus setup take dev_priv

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_i2c.c | 8

[Intel-gfx] [PATCH 01/10] drm/i915: Make GEM object alloc/free and stolen created take dev_priv

From: Tvrtko Ursulin Where it is more appropriate and also to be consistent with the direction of the driver. Also inline object alloc/free since they are just wrappers around kmem_cache_alloc/free. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 03/10] drm/i915: Make various init functions take dev_priv

From: Tvrtko Ursulin Like GEM init, GUC init, MOCS init and context creation. Enables them to lose dev_priv locals. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c| 31 ++--

[Intel-gfx] [PATCH 06/10] drm/i915: Unexport VGA switcheroo functions

From: Tvrtko Ursulin They are only used in i915_drv.c so a forward declaration is enough. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 5 - drivers/gpu/drm/i915/i915_drv.h | 3 --- 2 files changed, 4 insertions(+),

[Intel-gfx] [PATCH 10/10] drm/i915: Make intel_pm_setup take dev_priv

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 4 +--- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git

[Intel-gfx] [PATCH 08/10] drm/i915: Make i915_destroy_error_state take dev_priv

From: Tvrtko Ursulin Since it does not need dev at all. Also change the stored pointer in struct i915_error_state_file_priv to i915. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 8

[Intel-gfx] [PATCH 00/10] GEM object create and driver init dev_priv cleanups

From: Tvrtko Ursulin Autumn of churn continues. :) This series tidies GEM object construction to take dev_priv instead of dev in all cases and also does a bit of random tidy in the driver load/init code. Basically functions which only need dev_priv are changed to take

[Intel-gfx] [PATCH] drm/i915: Remove dummy i915_kick_out_firmware_fb

Since commit 44adece57e2604cec8527a499b48e4d584ab53b8 Author: Daniel Vetter Date: Wed Aug 10 18:52:34 2016 +0200 drm/fb-helper: Add a dummy remove_conflicting_framebuffers the drm helpers take care of this for us. Cc: Chris Wilson

Re: [Intel-gfx] [dim PATCH 2/2] dim: fetch drm-tip before rebuilding

On Tue, Nov 29, 2016 at 06:17:16PM +0200, Jani Nikula wrote: > Without this, my non-git-worktree setup will fail to push (or it takes > forever) if the local drm-tip is not up to date. > > Signed-off-by: Jani Nikula Ack. No idea why git is dense at this ... -Daniel > ---

Re: [Intel-gfx] [dim PATCH 1/2] dim: fetch Linus' tree again on update-branches

On Tue, Nov 29, 2016 at 06:17:15PM +0200, Jani Nikula wrote: > Fixes: 6552af2d32c4 ("dim: fix update-branches to fetch all available nightly > repos") > Cc: Archit Taneja > Signed-off-by: Jani Nikula > --- > dim | 8 > 1 file changed, 8

Re: [Intel-gfx] [PATCH v3] Idleness DRRS test

On Tue, Nov 29, 2016 at 03:06:17PM +0530, Nautiyal, Ankit K wrote: > As per discussion with Chris, on IRC following were the suggestions : > > - Chris has suggested an event based approach to avoid using pthreads. > > - Avoid using kernel-specific info like transitional delays and instead use >

  1   2   >