Re: [Intel-gfx] [PATCH 08/13] drm/i915: Refactor platform specifics out of intel_get_shared_dpll()

On Thu, 2016-03-03 at 15:08 +0100, Maarten Lankhorst wrote: > Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira: > > The function intel_get_shared_dpll() had a more or less generic > > implementation with some platform specific checks to handle smaller > > differences between platforms.

[Intel-gfx] [alsa-devel] [PATCH 1/2] ALSA: hda - hdmi add wmb barrier for audio component

From: Libin Yang To make sure audio_ptr is set before intel_audio_codec_enable() or intel_audio_codec_disable() calling pin_eld_notify(), this patch adds wmb barrier to prevent optimizing. Signed-off-by: Libin Yang ---

Re: [Intel-gfx] [PATCH 08/13] drm/i915: Refactor platform specifics out of intel_get_shared_dpll()

On Thu, 2016-03-03 at 15:08 +0100, Maarten Lankhorst wrote: > Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira: > > The function intel_get_shared_dpll() had a more or less generic > > implementation with some platform specific checks to handle smaller > > differences between platforms.

Re: [Intel-gfx] [PATCH] drm/i915: Treat cursor plane as another sprite plane for BSW

Agreed, it does look messy. As for the watermarks, we have verified that this patch works on Chrome OS with the kernel version 3.18. We have not seen any regressions yet. However, it requires the patch "drm/i915: Workaround CHV pipe C cursor fail" to be reverted. I will send out another

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

On Thu, Mar 03, 2016 at 03:50:23PM +, Lionel Landwerlin wrote: > Hi Matt, > > On 11/02/16 02:32, Matt Roper wrote: > >Gen9 platforms allow CRTC's to be programmed with a background/canvas > >color below the programmable planes. Let's expose this as a property to > >allow userspace to program

[Intel-gfx] [PATCH] drm/i915: Only write watermark registers if a pipe is active

If all pipes are off, then we may have entered runtime suspend and writing these registers will have no effect anyway. When a pipe is re-enabled, it's crtc_enable will take care of programming appropriate watermark values. Cc: arun.siluv...@linux.intel.com Cc: ville.syrj...@linux.intel.com

[Intel-gfx] [PATCH] drm/i915: Don't WARN() when sprite watermark > 0 for disabled LP2/LP3 levels

As of commit d81f04c5ef ("drm/i915: Allow preservation of watermarks, v2.") it's now possible to have non-zero values for watermark levels that are disabled (e.g., in the higher LP levels that can only be used when the sprite is disabled). Stop WARN()'ing when we see these non-zero sprite values

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move CSB MMIO reads out of the execlists lock (rev2)

On Thu, Mar 03, 2016 at 05:47:14PM +, Tvrtko Ursulin wrote: > > On 03/03/16 11:02, Patchwork wrote: > >== Series Details == > > > >Series: drm/i915: Move CSB MMIO reads out of the execlists lock (rev2) > >URL : https://patchwork.freedesktop.org/series/3973/ > >State : warning > > > >==

Re: [Intel-gfx] [PATCH i-g-t 1/4] lib/igt_bb_factory: Add igt_bb_factory library

On 02/03/16 18:08, Morton, Derek J wrote: The CMD parser blacklists the TIMESTAMP register on gen 7.5 so I will leave this as requiring gen8+ //Derek You might still be able to store its value (to memory or the PPHWSP?) using a PIPE_CONTROL or MI_FLUSH_DW instruction rather than accessing

Re: [Intel-gfx] [PATCH RESEND FOR CI] drm/i915: Fix races on fbdev

Hi Damien, Hi Daniel, I've submitted the patch below for the third time now in an attempt to get CI to test it, again to no avail. This time I didn't set the In-Reply-To header and only submitted it as a single patch instead of as a series because I expected this might confuse CI. Nevertheless

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Read out hrawclk from CCK on vlv/chv

On Wed, 2016-03-02 at 17:22 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently we assume that hrawclk is 200MHz on VLV/CHV. That should > be true always, but just to avoid such asumptions we can read out the > actual frequency from CCK.

Re: [Intel-gfx] [PATCH v1 00/12] PCI: Rework shadow ROM handling

On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote: > The purpose of this series is to: > [ .. ] The patches look ok to me and seem to make sense. Of course, let's see what they break. Hopefully nothing, but any time the PCI resource code changes I get a bit worried. PTSD,

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move CSB MMIO reads out of the execlists lock (rev2)

On 03/03/16 11:02, Patchwork wrote: == Series Details == Series: drm/i915: Move CSB MMIO reads out of the execlists lock (rev2) URL : https://patchwork.freedesktop.org/series/3973/ State : warning == Summary == Series 3973v2 drm/i915: Move CSB MMIO reads out of the execlists lock

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us

On 03/03/16 17:20, Chris Wilson wrote: On Thu, Mar 03, 2016 at 05:01:15PM +, Tvrtko Ursulin wrote: On 03/03/16 15:03, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Add wait_for_us URL : https://patchwork.freedesktop.org/series/4059/ State : failure

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Add wait_for_us (rev2)

== Series Details == Series: series starting with [1/5] drm/i915: Add wait_for_us (rev2) URL : https://patchwork.freedesktop.org/series/4059/ State : warning == Summary == Series 4059v2 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/2/mbox/ Test

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us

On Thu, Mar 03, 2016 at 05:01:15PM +, Tvrtko Ursulin wrote: > > On 03/03/16 15:03, Patchwork wrote: > >== Series Details == > > > >Series: series starting with [1/5] drm/i915: Add wait_for_us > >URL : https://patchwork.freedesktop.org/series/4059/ > >State : failure > > > >== Summary == > >

Re: [Intel-gfx] [PATCH v3] igt/gem_trtt: Exercise the TRTT hardware

On 3/3/2016 9:16 PM, Chris Wilson wrote: On Thu, Mar 03, 2016 at 09:08:25PM +0530, Goel, Akash wrote: Before we destroy the context (or exit), how about a query_trtt(). We should also query after create to ensure that the defaults are set. Just thinking that is better doing the query after

[Intel-gfx] [PATCH RESEND FOR CI] drm/i915: Fix races on fbdev

The ->lastclose callback invokes intel_fbdev_restore_mode() and has been witnessed to run before intel_fbdev_initial_config_async() has finished. We might likewise receive hotplug events or be suspended before we've had a chance to fully set up the fbdev. Fix by waiting for the asynchronous

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us

On 03/03/16 15:03, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Add wait_for_us URL : https://patchwork.freedesktop.org/series/4059/ State : failure == Summary == Series 4059v1 Series without cover letter

[Intel-gfx] [PATCH v1 12/12] PCI: Simplify sysfs ROM cleanup

The value of pdev->rom_attr is the definitive indicator of the fact that we're created a sysfs attribute. Check that rather than rom_size, which is only used incidentally when deciding whether to create a sysfs attribute. Signed-off-by: Bjorn Helgaas ---

[Intel-gfx] [PATCH v1 10/12] MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow ROM resource

Loongson 3 used the IORESOURCE_ROM_COPY flag for its ROM resource. There are two problems with this: - When IORESOURCE_ROM_COPY is set, pci_map_rom() assumes the resource contains virtual addresses, so it doesn't ioremap the resource. This implies loongson_sysconf.vgabios_addr is a

[Intel-gfx] [PATCH v1 09/12] MIPS: Loongson 3: Use temporary struct resource * to avoid repetition

Use a temporary struct resource pointer to avoid needless repetition of "pdev->resource[PCI_ROM_RESOURCE]". No functional change intended. Signed-off-by: Bjorn Helgaas --- arch/mips/pci/fixup-loongson3.c | 14 +++--- 1 file changed, 7 insertions(+), 7

[Intel-gfx] [PATCH v1 11/12] PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY

The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused. Remove them and code that depends on them. Signed-off-by: Bjorn Helgaas --- drivers/pci/remove.c |1 - drivers/pci/rom.c | 31 +-- include/linux/ioport.h |2 --

[Intel-gfx] [PATCH v1 07/12] ia64/PCI: Use ioremap() instead of open-coded equivalent

Depositing __IA64_UNCACHED_OFFSET in the upper address bits is essentially equivalent to ioremap(): it converts a CPU physical address to a virtual address using the ia64 uncacheable identity map. Call ioremap() instead of doing the phys-to-virt conversion manually with __IA64_UNCACHED_OFFSET.

[Intel-gfx] [PATCH v1 06/12] ia64/PCI: Use temporary struct resource * to avoid repetition

Use a temporary struct resource pointer to avoid needless repetition of "dev->resource[idx]". No functional change intended. Signed-off-by: Bjorn Helgaas --- arch/ia64/sn/kernel/io_acpi_init.c | 10 + arch/ia64/sn/kernel/io_init.c | 39

[Intel-gfx] [PATCH v1 08/12] ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM resource

A struct resource contains CPU physical addresses, not virtual addresses. But sn_acpi_slot_fixup() and sn_io_slot_fixup() stored the virtual address of a shadow ROM copy in the resource. To compensate, pci_map_rom() had a special case that returned the resource address directly rather than

[Intel-gfx] [PATCH v1 05/12] PCI: Clean up pci_map_rom() whitespace

Remove unnecessary indentation in pci_map_rom(). This is logically part of the previous patch; I split it out to make the critical changes in that patch more obvious. No functional change intended. Signed-off-by: Bjorn Helgaas --- drivers/pci/rom.c | 37

[Intel-gfx] [PATCH v1 04/12] PCI: Set ROM shadow location in arch code, not in PCI core

IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in RAM. The existence of such a copy and its location are arch-specific. Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the 0xC-0xD location was hard-coded into the PCI core. If we're using a shadow

[Intel-gfx] [PATCH v1 01/12] PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED

A shadow copy of an option ROM is placed by the BIOS as a fixed address. Set IORESOURCE_PCI_FIXED to indicate that we can't move the shadow copy. This prevents warnings like the following when we assign resources: BAR 6: [??? 0x flags 0x2] has bogus alignment This warning is emitted by

[Intel-gfx] [PATCH v1 03/12] PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy

If we're using a RAM shadow copy instead of the ROM BAR, we don't need to touch the ROM BAR enable bit. Signed-off-by: Bjorn Helgaas --- drivers/pci/rom.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/pci/rom.c

[Intel-gfx] [PATCH v1 02/12] PCI: Don't assign or reassign immutable resources

IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set, don't bother trying to assign or reassign the resource. Signed-off-by: Bjorn Helgaas --- drivers/pci/setup-res.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/setup-res.c

[Intel-gfx] [PATCH v1 00/12] PCI: Rework shadow ROM handling

The purpose of this series is to: - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment" messages reported by Linus [1], Andy [2], and others. - Move arch-specific shadow ROM location knowledge, e.g., 0xC-0xD, from PCI core to arch code. - Fix the ia64 and MIPS

[Intel-gfx] [maintainer-tools PATCH v2] dim: Check for required tags as part of dim_checkpatch

Check in dim_checkpatch if the committer's Signed-off-by line and a Reviewed-by line exists in the commit message. If no Reviewed-by line exists also accept two distinct Signed-off-by lines instead. v2: (Jani) - move the check from dim_push_branch to dim_checkpatch - remove the check for the

[Intel-gfx] [PATCH v5 4/5] drm/i915: Do not lie about atomic timeout granularity

From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a jiffie timeout granularity which is not nice towards callers requesting small micro-second timeouts. Re-implement it so micro-second timeout granularity is really supported and not just in the name

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity

On Thu, Mar 03, 2016 at 03:43:49PM +, Tvrtko Ursulin wrote: > > On 03/03/16 15:11, Chris Wilson wrote: > >On Thu, Mar 03, 2016 at 02:36:44PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Currently the wait_for_atomic_us only allows for a millisecond

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

On Mon, Feb 29, 2016 at 02:26:52PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW > URL : https://patchwork.freedesktop.org/series/3916/ > State : failure > > == Summary == > > Series 3916v1 drm/i915: Fix bogus

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

Hi Matt, On 11/02/16 02:32, Matt Roper wrote: Gen9 platforms allow CRTC's to be programmed with a background/canvas color below the programmable planes. Let's expose this as a property to allow userspace to program a desired value. This patch is based on earlier work by Chandra Konduru;

Re: [Intel-gfx] [PATCH v3] igt/gem_trtt: Exercise the TRTT hardware

On Thu, Mar 03, 2016 at 09:08:25PM +0530, Goel, Akash wrote: > >Before we destroy the context (or exit), how about a query_trtt(). > >We should also query after create to ensure that the defaults are set. > >Just thinking that is better doing the query after several steps (i.e. > >the execbuf)

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity

On 03/03/16 15:11, Chris Wilson wrote: On Thu, Mar 03, 2016 at 02:36:44PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small micro-second

Re: [Intel-gfx] [PATCH v3] igt/gem_trtt: Exercise the TRTT hardware

Thanks for the review. On 3/3/2016 3:34 PM, Chris Wilson wrote: On Thu, Mar 03, 2016 at 10:25:59AM +0530, akash.g...@intel.com wrote: +static bool uses_full_ppgtt(int fd, int min) gem_gtt_type() fine will change like this, gem_gtt_type(fd) > 2 +static bool

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us

== Series Details == Series: series starting with [1/5] drm/i915: Add wait_for_us URL : https://patchwork.freedesktop.org/series/4059/ State : failure == Summary == Series 4059v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/1/mbox/ Test gem_sync:

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity

On Thu, Mar 03, 2016 at 02:36:44PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Currently the wait_for_atomic_us only allows for a millisecond > granularity which is not nice towards callers requesting small > micro-second waits. Hmm, by granularity I think

Re: [Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

On Mon, 29 Feb 2016 15:39:53 +0100, Jani Nikula wrote: > > On Mon, 29 Feb 2016, Martin Kepplinger wrote: > > Am 2016-02-26 um 20:59 schrieb Takashi Iwai: > >> Sorry, Cc to Jani was missing mistakenly. > >> > >> Please check this. It's a regression in 4.5-rc. > >> > >> > >>

[Intel-gfx] [PATCH 1/5] drm/i915: Add wait_for_us

From: Tvrtko Ursulin This is for callers who want micro-second precision but are not waiting from the atomic context. v2: * Fix atomic waits. (Dave Gordon) * Use USEC_PER_SEC and USEC_PER_MSEC. (Chris Wilson) Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [PATCH 5/5] drm/i915: Do not wait atomically for display clocks

From: Tvrtko Ursulin Looks like this code does not need to wait atomically since it otherwise takes the mutex. Signed-off-by: Tvrtko Ursulin Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä

[Intel-gfx] [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity

From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small micro-second waits. Re-implement it so micro-second granularity is really supported and not just in the name of the macro.

[Intel-gfx] [PATCH 2/5] drm/i915/lrc: Do not wait atomically when stopping engines

From: Tvrtko Ursulin I do not see that this needs to be done atomically and up to one second is quite a long time to busy loop. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1

[Intel-gfx] [PATCH 3/5] drm/i915: Kconfig for extra driver debugging

From: Tvrtko Ursulin v2: Added a submenu based on an idea by Chris Wilson. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Jani Nikula --- drivers/gpu/drm/i915/Kconfig | 6 ++

Re: [Intel-gfx] [PATCH 08/13] drm/i915: Refactor platform specifics out of intel_get_shared_dpll()

Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira: > The function intel_get_shared_dpll() had a more or less generic > implementation with some platform specific checks to handle smaller > differences between platforms. However, the minimalist approach forces > bigger differences between

Re: [Intel-gfx] [PATCH v3 13/13] drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code

Op 03-03-16 om 14:40 schreef Ander Conselvan De Oliveira: > On Thu, 2016-03-03 at 14:33 +0100, Maarten Lankhorst wrote: >> Op 29-02-16 om 10:08 schreef Ander Conselvan de Oliveira: >>> Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept >>> enabled because of it driving CDCLK,

Re: [Intel-gfx] [PATCH v3 13/13] drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code

On Thu, 2016-03-03 at 14:33 +0100, Maarten Lankhorst wrote: > Op 29-02-16 om 10:08 schreef Ander Conselvan de Oliveira: > > Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept > > enabled because of it driving CDCLK, it is better to special case that > > inside the DPLL code

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Use a table to initilize shared dplls

Op 03-03-16 om 12:32 schreef Ander Conselvan De Oliveira: > Hi Maarten, > > Thanks for reviewing. Comments below. > > On Wed, 2016-03-02 at 16:30 +0100, Maarten Lankhorst wrote: >> Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira: >>> Use a table to store the per-platform shared dpll

Re: [Intel-gfx] [PATCH v3 13/13] drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code

Op 29-02-16 om 10:08 schreef Ander Conselvan de Oliveira: > Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept > enabled because of it driving CDCLK, it is better to special case that > inside the DPLL code than in the higher level. > > v2: Use INTEL_DPLL_ALWAYS_ON flag.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,1/6] drm/i915: Move shared dpll code to a new file

On Thu, 2016-03-03 at 12:02 +, Patchwork wrote: > == Series Details == > > Series: series starting with [RESEND,FOR,CI,1/6] drm/i915: Move shared dpll > code to a new file > URL : https://patchwork.freedesktop.org/series/4055/ > State : failure > > == Summary == > > Series 4055v1 Series

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep

== Series Details == Series: drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep URL : https://patchwork.freedesktop.org/series/4056/ State : failure == Summary == Series 4056v1 drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

On Fri, 26 Feb 2016, Ramalingam C wrote: > On Thursday 18 February 2016 02:00 AM, Jani Nikula wrote: >> On Mon, 15 Feb 2016, Deepak M wrote: >>> The MIPI clock calculations for the addtional clock >>> are revised from B0 stepping onwards, the bit

[Intel-gfx] [PATCH] drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep

The DRM core depends on mm->mmap_sem being the outer lock in order to setup/teardown and utilize fault handlers. If we taint the mm->mmap_sem as soon as we open the device for a process, we can define this proper ordering for lockdep and so it will report any violations early. Signed-off-by:

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

Hi Dave, a couple of Intel fixes for v4.5. BR, Jani. The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af: Linux 4.5-rc6 (2016-02-28 08:41:20 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-03-03 for

Re: [Intel-gfx] [PATCH 1/2] man: rewrite manual pages in reStructuredText

On Tue, 01 Mar 2016, Jani Nikula wrote: > intel_reg.rst was the first man page written in reStructuredText. Follow > suit with the rest of the man pages. Marius, Daniel, any comments before I go ahead and push? BR, Jani. -- Jani Nikula, Intel Open Source Technology

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,1/6] drm/i915: Move shared dpll code to a new file

== Series Details == Series: series starting with [RESEND,FOR,CI,1/6] drm/i915: Move shared dpll code to a new file URL : https://patchwork.freedesktop.org/series/4055/ State : failure == Summary == Series 4055v1 Series without cover letter

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Check for required tags before pushing a branch

On Thu, 03 Mar 2016, Imre Deak wrote: > On Thu, 2016-03-03 at 10:11 +0200, Jani Nikula wrote: >> On Wed, 02 Mar 2016, Imre Deak wrote: >> > Check if the committer's and author's Signed-off-by line and at >> > least >> > one Reviewed-by line exists in

[Intel-gfx] [PATCH RESEND FOR CI 4/6] drm/i915: Store a direct pointer to shared dpll in intel_crtc_state

Change the type of intel_crtc_state->shared_dpll to be a pointer to a shared dpll. With this there is no need to first convert the id stored in the crtc state to a pointer in order to use it. It does introduce a bit of hassle on doing the opposite. The long term objective is to hide details about

[Intel-gfx] [PATCH RESEND FOR CI 1/6] drm/i915: Move shared dpll code to a new file

Create the new file intel_dpll_mgr.c and move the shared dpll code to it. Follow up patches that reorganize pll handling will move more code there and tweak the interface. No functional changes. Signed-off-by: Ander Conselvan de Oliveira Reviewed-by:

[Intel-gfx] [PATCH RESEND FOR CI 6/6] drm/i915: Move shared dpll function prototypes to intel_dpll_mgr.h

Move shared dpll function prototype together with other shared dpll definitions. Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dpll_mgr.h | 30

[Intel-gfx] [PATCH RESEND FOR CI 5/6] drm/i915: Move shared dpll struct definitions to separate header file

Move the declarations related to shared dplls from i915_drv.h to their own header file. The code that became the shared dpll infrastructre was first introcude in commit ee7b9f93fd96 ("drm/i915: manage PCH PLLs separately from pipes"), hence the 2012-2016 copyright years in the new header file.

[Intel-gfx] [PATCH RESEND FOR CI 2/6] drm/i915: Move ddi shared dpll code to intel_dpll_mgr.c

No functional changes. Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_ddi.c | 472 -- drivers/gpu/drm/i915/intel_dpll_mgr.c

[Intel-gfx] [PATCH RESEND FOR CI 3/6] drm/i915: Split intel_get_shared_dpll() into smaller functions

Make the code neater by splitting the code for platforms with fixed PLL to their own functions and splitting the logic for finding a shareable or unused pll from the logic for setting it up. Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Maarten

Re: [Intel-gfx] [PATCH] drm/i915: add sanity check for partial view creation

On Thu, Mar 03, 2016 at 11:27:47AM +, Auld, Matthew wrote: > > Handle overflow? > > Okay, good idea. > > > Why do it here and not at creation? > > We could, given that we currently only exercise partial views in the gem > fault handler code, but as Joonas mentioned we are expecting further

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Use a table to initilize shared dplls

Hi Maarten, Thanks for reviewing. Comments below. On Wed, 2016-03-02 at 16:30 +0100, Maarten Lankhorst wrote: > Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira: > > Use a table to store the per-platform shared dpll information in one > > place. This way, there is no need for platform

Re: [Intel-gfx] [PATCH] drm/i915: add sanity check for partial view creation

> Handle overflow? Okay, good idea. > Why do it here and not at creation? We could, given that we currently only exercise partial views in the gem fault handler code, but as Joonas mentioned we are expecting further use of partial views, so it makes sense to have the check in only one place.

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move CSB MMIO reads out of the execlists lock (rev2)

== Series Details == Series: drm/i915: Move CSB MMIO reads out of the execlists lock (rev2) URL : https://patchwork.freedesktop.org/series/3973/ State : warning == Summary == Series 3973v2 drm/i915: Move CSB MMIO reads out of the execlists lock

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/hangcheck: Prevent long walks across full-ppgtt

Patchwork writes: > == Series Details == > > Series: drm/i915/hangcheck: Prevent long walks across full-ppgtt > URL : https://patchwork.freedesktop.org/series/4023/ > State : warning > > == Summary == > > Series 4023v1 drm/i915/hangcheck: Prevent long walks

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Read out hrawclk from CCK on vlv/chv

On Thu, Mar 03, 2016 at 10:51:23AM +0200, Jani Nikula wrote: > On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Currently we assume that hrawclk is 200MHz on VLV/CHV. That should > > be true always, but just to avoid such

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Store rawclk_freq in dev_priv

On Thu, Mar 03, 2016 at 10:47:38AM +0200, Jani Nikula wrote: > On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Generalize rawclk handling by storing it in dev_priv. > > > > Presumably our hrawclk readout works at least for

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Use DIV_ROUND_CLOSEST for PWM calculations

On Thu, Mar 03, 2016 at 10:25:06AM +0200, Jani Nikula wrote: > On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Supposedly we would want to get the PWM output as close as possible to > > the target, so let's round to closest.

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Generalise common GPU engine reset request/unrequest code

Arun Siluvery writes: > On 02/03/2016 15:56, Patchwork wrote: >> == Series Details == >> >> Series: drm/i915: Generalise common GPU engine reset request/unrequest code >> URL : https://patchwork.freedesktop.org/series/4021/ >> State : warning >> >> == Summary ==

[Intel-gfx] [PATCH v2] drm/i915: Move CSB MMIO reads out of the execlists lock

From: Tvrtko Ursulin By reading the CSB (slow MMIO accesses) into a temporary local buffer we can decrease the duration of holding the execlist lock. Main advantage is that during heavy batch buffer submission we reduce the execlist lock contention, which should

Re: [Intel-gfx] Fwd: [PATCH] drm/i915: Avoid vblank counter for gen9+

On Wed, Mar 02, 2016 at 07:13:07PM +0200, Imre Deak wrote: > On Fri, 2016-02-26 at 10:02 -0800, Rodrigo Vivi wrote: > > [...] > > Well, I have this tree: > > https://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=rpm-domains-psr-vblank-counter-full > > with mainly: > > 1 - vblank domain on

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Check for required tags before pushing a branch

On Thu, 2016-03-03 at 10:11 +0200, Jani Nikula wrote: > On Wed, 02 Mar 2016, Imre Deak wrote: > > Check if the committer's and author's Signed-off-by line and at > > least > > one Reviewed-by line exists in each commit to be pushed. > > > > Signed-off-by: Imre Deak

Re: [Intel-gfx] [PATCH v3] igt/gem_trtt: Exercise the TRTT hardware

On Thu, Mar 03, 2016 at 10:25:59AM +0530, akash.g...@intel.com wrote: > +static bool uses_full_ppgtt(int fd, int min) gem_gtt_type() > +static bool has_softpin_support(int fd) gem_has_softpin() > +static int emit_store_dword(int fd, uint32_t *cmd_buf, uint32_t dw_offset, > +

[Intel-gfx] Ask for comments of getting guest framebuffer in igvt-g

Dear i915 developers, Here I have one topic hoping to get your comments and suggestions. Basically it is about graphics virtualization(igvt-g), for the purpose of host system to get virtual machine's framebuffer. We would like to hear your opinions about some design opens. Below is the patch and

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/atomic: Fix encoder stealing, v3.

== Series Details == Series: drm/atomic: Fix encoder stealing, v3. URL : https://patchwork.freedesktop.org/series/4045/ State : failure == Summary == Series 4045v1 drm/atomic: Fix encoder stealing, v3. http://patchwork.freedesktop.org/api/1.0/series/4045/revisions/1/mbox/ Test kms_flip:

Re: [Intel-gfx] [PATCH v3 6/7] drm/atomic: Clean up steal_encoder, v2.

Hi Maarten, [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20160303] [cannot apply to v4.5-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Maarten-Lankhorst

Re: [Intel-gfx] [PATCH] drm/i915: Adaptive backoff delay on link training

(Cc'ing Sivakumar, as he might have some ideas on this) On Fri, 2016-02-26 at 12:54 +0200, Mika Kuoppala wrote: > If the panel don't give us the information how long to wait > before starting a new link training phase, it is not productive > to poke it at 100us or 400us intervals and then give up

[Intel-gfx] [PATCH v3 4/7] drm/atomic: Handle encoder stealing from set_config better.

Instead of failing with -EINVAL when conflicting encoders are found, the legacy set_config will disable other connectors when encoders conflict. With the previous commit this becomes a lot easier to implement. set_config only adds connectors to the state that are modified, and because of the

[Intel-gfx] [PATCH v3 3/7] drm/atomic: Always call steal_encoder, v2.

There's no need to have a separate function to get the crtc which is stolen, this can already be found when actually stealing the encoder. drm_for_each_connector already checks for connection_mutex, so use that macro now. Changes since v1: - Do not check for NULL crtc in connector_state, this

[Intel-gfx] [PATCH v3 1/7] drm/atomic: Clean up update_output_state.

With the addition of crtc_state->connector_mask other connectors from different crtc's aren't needed any more, so only call add_affected_connectors on the target crtc. This allows a cleanup to first remove all current connectors, then add all set->connectors to the target crtc. Signed-off-by:

[Intel-gfx] [PATCH v3 6/7] drm/atomic: Clean up steal_encoder, v2.

Now that only encoders can be stolen that are part of the state steal_encoder no longer needs to inspect all connectors, just those that are part of the atomic state. Changes since v1: - Change return value to void, can no longer fail. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH v3 5/7] drm/atomic: Handle encoder assignment conflicts in a separate check, v3.

The current check doesn't handle the case where we don't steal an encoder, but keep it on the current connector. If we repurpose disable_conflicting_encoders to do the checking, we just have to reject the ones that conflict. Changes since v1: - Return early with empty encoder_mask,

[Intel-gfx] [PATCH v3 2/7] drm/atomic: Pass connector and state to update_connector_routing.

Minor cleanup, connector and connector_state are always non-NULL here. Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 15 +-- 1 file changed, 5 insertions(+), 10

[Intel-gfx] [PATCH v3 7/7] drm/atomic: Clean up update_connector_routing.

connector_state->crtc can no longer be unset by accident, so that check can be removed. The other code open-codes drm_atomic_get_existing_crtc_state, so use that. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 17 -

[Intel-gfx] [PATCH v3 0/7] drm/atomic: Fix encoder stealing, v3.

This is a resend of "drm/atomic: Fix encoder stealing" with updated patches. Maarten Lankhorst (7): drm/atomic: Clean up update_output_state. drm/atomic: Pass connector and state to update_connector_routing. drm/atomic: Always call steal_encoder, v2. drm/atomic: Handle encoder stealing

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Read out hrawclk from CCK on vlv/chv

On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently we assume that hrawclk is 200MHz on VLV/CHV. That should > be true always, but just to avoid such asumptions we can read out the > actual frequency from CCK. Okay, so I

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Store rawclk_freq in dev_priv

On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Generalize rawclk handling by storing it in dev_priv. > > Presumably our hrawclk readout works at least for CTG and ELK > since we've been using it for DP AUX on those platforms.

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Use DIV_ROUND_CLOSEST for PWM calculations

On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Supposedly we would want to get the PWM output as close as possible to > the target, so let's round to closest. > > Cc: Jani Nikula > Suggested-by: Jani

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only recalculate wm's for planes part of the state, v2.

Op 02-03-16 om 22:08 schreef Zanoni, Paulo R: > Em Ter, 2016-03-01 às 14:28 -0800, Matt Roper escreveu: >> On Tue, Mar 01, 2016 at 11:07:22AM +0100, Maarten Lankhorst wrote: >>> Only planes that are part of the state should be used for >>> recalculating >>> watermarks. For planes not part of the

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Check for required tags before pushing a branch

On Wed, 02 Mar 2016, Imre Deak wrote: > Check if the committer's and author's Signed-off-by line and at least > one Reviewed-by line exists in each commit to be pushed. > > Signed-off-by: Imre Deak > --- > dim | 32 > 1