On Wed, Dec 14, 2016 at 05:55:39PM -0200, Paulo Zanoni wrote:
> Don't even tell the mm allocator to handle the first page of stolen on
> the affected platforms. This means that we won't inherit the FB in
> case the BIOS decides to put it at the start of stolen. But the BIOS
> should not be putting
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Exercise drm_mm_insert_node_in_range(), check that we only allocate from
> the specified range.
>
> Signed-off-by: Chris Wilson
With the stylistic changes I proposed to whole series;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joona
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> usleep_range() is intended for delays in the 10us to 10ms range that need
> good precision. a useleep_range(1, will effectively be no more than an
> imprecise udelay with some added cache disruption as it will fire more or
> less immediately - use ud
On Thu, 15 Dec 2016, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> usleep_range() is intended for delays in the 10us to 10ms range that need
>> good precision. a useleep_range(1, will effectively be no more than an
>> imprecise udelay with some added cache disruption as it
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we can request alignment to any power-of-two or prime using a
> plain drm_mm_node_insert(), and also handle a reasonable selection of
> primes.
>
> Signed-off-by: Chris Wilson
> +static int igt_align(void *ignored)
> +{
> +
From: Deepak M
v2: Addressed Jani's Review comments (renamed bit field macros)
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/
From: Deepak M
v2: Addressed Jani's Review comments(renamed bit field macros)
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 134 +++
1 file changed, 134 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ds
The patches in this list enable MIPI DSI video mode
support for GLK platform. Tesed locally.
v2: Renamed bitfields macros as per review comments(Jani)
Deepak M (7):
drm/i915/glk: Add new bit fields in MIPI CTRL register
drm/i915/glk: Program new MIPI DSI PHY registers for GLK
drm/i915/glk: A
From: Deepak M
Program the clk lane and tlpx time count registers
to configure DSI PHY.
v2: Addressed Jani's Review comments(renamed bit field macros)
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 18 ++
drivers/gpu/drm/i915/inte
From: Vincente Tsou
The upper bits of the vsync width, vsync offset and hsync width
were not parsed form the VBT. Parse these fields in this patch.
Signed-off-by: Madhav Chauhan
Signed-off-by: Vincente Tsou
---
drivers/gpu/drm/i915/intel_bios.c | 8 +---
drivers/gpu/drm/i915/intel_vbt
For GEMINILAKE, dphy param reg values are programmed in terms
of HS byte clock while for legacy platforms in terms of ddrclk
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 33 +++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --
From: Deepak M
PLL divider range for GLK is different than that of
BXT, hence adding the GLK range check in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_dsi_pll.c | 20 ++--
2 f
From: Deepak M
Register MIPI_CLOCK_CTRL is applicable only
for BXT platform. Future platform have other
registers to program the escape clock dividers.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 25 +++--
1 file changed
From: Deepak M
Dual link Z-inversion overlap field is present
in MIPI_CTRL register unlike the older platforms,
hence setting the same in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 17 +
1 file changed, 13 insertion
From: Deepak M
v2: Addressed Jani's Review comments(renamed bit field macros)
Txesc clock divider is calculated and programmed
for geminilake platform.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++
drivers/gpu/drm/i915/intel_dsi_pll.
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> Even on fast systems a 2 microsecond delay is most likely more efficient
> as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
> change this to a udelay(2).
Similar concerns as in [1]. We don't need the accuracy of udelay() here
On Thu, 15 Dec 2016, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 04:56:33PM +0200, Jani Nikula wrote:
>> On Wed, 14 Dec 2016, Daniel Vetter wrote:
>> > On Tue, Dec 13, 2016 at 10:23:05PM +0200, Ville Syrjälä wrote:
>> >> On Tue, Dec 13, 2016 at 08:54:14PM +0100, Daniel Vetter wrote:
>> >> > It
On Thu, Dec 15, 2016 at 10:59:10AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> > Check that we can request alignment to any power-of-two or prime using a
> > plain drm_mm_node_insert(), and also handle a reasonable selection of
> > primes.
> >
> > Signed
On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > Even on fast systems a 2 microsecond delay is most likely more efficient
> > as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
> > change this to a udelay(2).
>
On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote:
> On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > > Even on fast systems a 2 microsecond delay is most likely more efficient
> > > as a busy-wait loop. The overhead of
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we add arbitrary blocks to the eviction scanner in order to
> find the first minimal hole that matches our request.
>
> Signed-off-by: Chris Wilson
> + if ((int)tmp.start % n || tmp.size != nsize ||
> tmp.hole_foll
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 10:47:57AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > usleep_range() is intended for delays in the 10us to 10ms range that need
>> > good precision. a useleep_range(1, will effectively be
== Series Details ==
Series: GLK MIPI DSI VIDEO MODE PATCHES (rev2)
URL : https://patchwork.freedesktop.org/series/16542/
State : success
== Summary ==
Series 16542v2 GLK MIPI DSI VIDEO MODE PATCHES
https://patchwork.freedesktop.org/api/1.0/series/16542/revisions/2/mbox/
fi-bdw-5557u tot
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we add arbitrary blocks to a restrited eviction scanner in
> order to find the first minimal hole that matches our request.
>
> Signed-off-by: Chris Wilson
> +static int igt_evict_range(void *ignored)
> +{
> + drm_for_ea
The failed case is KBL hang. This patch shouldn't impact platforms that have
non-zero num_pipes.
So the KBL hang isn't a regression caused by this patch. According to below
kernel log before hang
(https://intel-gfx-ci.01.org/CI/Patchwork_3266/fi-kbl-7500u/dmesg-during.log),
It should be the same
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > Even on fast systems a 2 microsecond delay is most likely more efficient
>> > as a busy-wait loop. The overhead of a hrtimer does not
On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> >> > Even on fast systems a 2 microsecond delay is most likely more ef
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, December 14, 2016 5:21 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> louis.boss...@linux.intel.c
Reply to correct thread.
The failed case is KBL hang. This patch shouldn't impact platforms that have
non-zero num_pipes.
So the KBL hang isn't a regression caused by this patch. According to below
kernel log before hang
(https://intel-gfx-ci.01.org/CI/Patchwork_3266/fi-kbl-7500u/dmesg-during.lo
On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> >> > Even on fast sys
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, December 14, 2016 6:26 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ti...@suse.de; broo...@kernel.org; Ughreja, Rakes
Since wake count is released asynchronously, *drpc_info output indicates
blitter wake count to be 1. Print these wake counts before reading
registers in *drpc_info.
Acked-by: Chris Wilson
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 ++--
1 file changed, 6 in
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, December 14, 2016 6:16 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> louis.boss...@linux.intel.c
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that after applying the driver's color adjustment, fitting of the
> node and its alignment are still correct.
>
> Signed-off-by: Chris Wilson
> +static void no_color_touching(struct drm_mm_node *node,
> + u
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, December 14, 2016 6:26 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> louis.boss...@linux.intel.c
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, December 14, 2016 6:31 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> louis.boss...@linux.intel.c
On Thu, 15 Dec 2016 11:55:23 +0100,
Anand, Jerome wrote:
>
>
>
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Wednesday, December 14, 2016 6:16 PM
> > To: Anand, Jerome
> > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> > ville.syrj..
== Series Details ==
Series: series starting with [1/1] drm/i915: Print forcewake domain wake counts
before reading register
URL : https://patchwork.freedesktop.org/series/16839/
State : success
== Summary ==
Series 16839v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
On Thu, Dec 15, 2016 at 11:51 AM, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 10:27:59AM +0100, Daniel Vetter wrote:
>> On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote:
>> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> > > On Thu, 15 Dec 2016, Nicholas Mc Gu
On Thu, Dec 15, 2016 at 12:14:30PM +0100, Takashi Iwai wrote:
> The interaction between i915 and audio is simple, yes, it just exposes
> a few things, mmio ptr, irq, etc. But still I don't understand why
> multiple layers of indirect accesses are needed *inside* lpe audio
> driver itself. For ex
On Thu, Dec 15, 2016 at 10:18:13AM +, Anand, Jerome wrote:
>
>
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Wednesday, December 14, 2016 5:21 PM
> > To: Anand, Jerome
> > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> > ville.syr
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Ville Syrjälä wrote:
>> > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
>> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> >> > On Thu, Dec 15,
Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
crtc_state after commit. Move it to atomic_state->crtcs.
Also stop re-using new_crtc_state->enable, we can now simply set a
bitmask with crtc_crtc_mask.
Changes since v1:
- Keep last_vblank_count in __drm_crtc_state.
---
diff
On Thu, Dec 15, 2016 at 10:34:00AM +, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
> > On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> > > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
> > >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range effic
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Build the struct drm_mm selftests so that we can trivially run them
> within our CI.
>
> Signed-off-by: Chris Wilson
"Enable debug, become developer."
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technolog
On 2016-12-14 11:04 AM, Brian Starkey wrote:
Hi,
On Wed, Dec 14, 2016 at 04:05:03AM -0500, Robert Foss wrote:
Add support dor the IN_FENCE_FD property to enable setting in fences
for atomic
commits.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 20
lib/igt_kms.h | 5 ++
On ma, 2016-12-12 at 14:57 +0800, Wang Elaine wrote:
> From: Elaine Wang
>
> Some platforms don't have display. To avoid accessing the
> non-existent registers, check HAS_PCH_NOP before invoking
> display IRQ install or reset function.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by
On Thu, Dec 15, 2016 at 02:28:32PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> > @@ -799,7 +706,7 @@ bool drm_mm_scan_add_block(struct drm_mm_scan *scan,
> > if (adj_end <= adj_start || adj_end - adj_start < scan->size)
> > return false;
>
On Mon, Dec 12, 2016 at 02:57:44PM +0800, Wang Elaine wrote:
> From: Elaine Wang
>
> Some platforms don't have display. To avoid accessing the
> non-existent registers, check HAS_PCH_NOP before invoking
> display IRQ install or reset function.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signe
Don't even tell the mm allocator to handle the first page of stolen on
the affected platforms. This means that we won't inherit the FB in
case the BIOS decides to put it at the start of stolen. But the BIOS
should not be putting it at the start of stolen since it's going to
get corrupted. I suppose
On Thu, Dec 15, 2016 at 11:23:55AM -0200, Paulo Zanoni wrote:
> Don't even tell the mm allocator to handle the first page of stolen on
> the affected platforms. This means that we won't inherit the FB in
> case the BIOS decides to put it at the start of stolen. But the BIOS
> should not be putting
On 13/12/2016 17:23, Patchwork wrote:
== Series Details ==
Series: drm/i915: Optimise VMA lookup slightly (rev2)
URL : https://patchwork.freedesktop.org/series/16740/
State : warning
== Summary ==
Series 16740v2 drm/i915: Optimise VMA lookup slightly
https://patchwork.freedesktop.org/api/1.
On Thu, Dec 15, 2016 at 03:26:59PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 15, 2016 at 11:23:55AM -0200, Paulo Zanoni wrote:
> > Don't even tell the mm allocator to handle the first page of stolen on
> > the affected platforms. This means that we won't inherit the FB in
> > case the BIOS decides
On Wed, Dec 14, 2016 at 11:37:46PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 18, 2016 at 09:52:36PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Second installment of my effort to remove the duplicated
> > depth/bpp/pixel_format from drm_framebuffer and just use
> >
On Thu, Dec 15, 2016 at 01:40:15PM +, Chris Wilson wrote:
> On Thu, Dec 15, 2016 at 03:26:59PM +0200, Ville Syrjälä wrote:
> > On Thu, Dec 15, 2016 at 11:23:55AM -0200, Paulo Zanoni wrote:
> > > Don't even tell the mm allocator to handle the first page of stolen on
> > > the affected platforms.
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 067324d26ea0a913b18737a702eded1db4b255d0
commit: ca984a998ad3a3b6bf8bf0d89861a6537551aaf2 [902/918] drm/fb_cma_helper:
Replace drm_format_info() with fb->format
config: i386-randconfig-s1-201650 (attached as .config)
compiler: gcc-6
There were some issues in i915 preventing rmfb from working correctly.
A lot of them are related to hw readout, some others due to keeping
crtc active during driver unload:
https://intel-gfx-ci.01.org/CI/Trybot_394/
I fixed the POWER_DOMAIN_AUDIO issue because it was easy to do so,
but ignored th
If the crtc was brought up with audio before the driver loads,
then crtc_disable will remove a refcount to audio that doesn't exist
before.
Fortunately we already set power domains on readout, so we can just add
the power domain handling to get_crtc_power_domains, which will update
the power domai
We may keep the crtc's enabled when userspace unsets all framebuffers but
keeps the crtc active. This exposes a WARN in fbc_global disable, and
a lot of bugs in our hardware readout code. Solve this by disabling
all crtc's for now.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_d
drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
different from commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 60697482b94c..d1d25
From: Daniel Vetter
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied f
On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > Even on fast systems a 2 microsecond delay is most likely more efficient
> > as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
> > change this to a udelay(2).
>
On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> >> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> >> >>
On Thu, Dec 15, 2016 at 10:47:57AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > usleep_range() is intended for delays in the 10us to 10ms range that need
> > good precision. a useleep_range(1, will effectively be no more than an
> > imprecise udelay with some added
== Series Details ==
Series: series starting with [1/2] drm/i915: skip the first 4k of stolen memory
on everything >= gen8 (rev3)
URL : https://patchwork.freedesktop.org/series/16800/
State : warning
== Summary ==
Series 16800v3 Series without cover letter
https://patchwork.freedesktop.org/ap
usleep_range() is intended for delays in the 10us to 10ms range that need
good precision. a useleep_range(1, will effectively be no more than an
imprecise udelay with some added cache disruption as it will fire more or
less immediately - use udelay() here.
Fixes: commit be4fc046bed3 ("drm/i915: ad
Even on fast systems a 2 microsecond delay is most likely more efficient
as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
change this to a udelay(2).
Signed-off-by: Nicholas Mc Guire
---
Problem found by coccinelle:
Patch was compile tested with: x86_64_defconfig (implie
On Thu, Dec 15, 2016 at 10:27:59AM +0100, Daniel Vetter wrote:
> On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote:
> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> > > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > > > Even on fast systems a 2 microsecond delay is
On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> On Mon, Dec 12, 2016 at 02:57:44PM +0800, Wang Elaine wrote:
>> From: Elaine Wang
>>
>> Some platforms don't have display. To avoid accessing the
>> non-existent registers, check HAS_PCH_NOP before invoking
>> display IRQ install or reset function.
>>
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> In a lot of place we wish to know which planes on the crtc are actually
> visible, or how many of them there are. Let's start tracking that in a
> bitmask in the crtc state.
>
> We already track enabled planes (i
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Track the plane fifo sizes under intel_crtc instead of under each
> intel_plane. Avoids looping over the planes in a bunch of places,
> and later we'll move this tracking into the crtc state properly.
>
> Signed-
On Thu, Dec 15, 2016 at 03:56:03PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > In a lot of place we wish to know which planes on the crtc are actually
> > visible, or how many of them there are. Let's start tracking
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Add a test to try out all the different plane enable/disable
> order permutations.
>
> Signed-off-by: Ville Syrjälä
Didn't look through the test, but sounds like
kms_atomic_transitions.plane-*-transition-* ?
A
On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
> different from commit.
>
> Signed-off-by: Maarten Lankhorst
I think it'd be good to update the kerneldoc for the atomic_commit
callback to mention that driver
On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Add a test to try out all the different plane enable/disable
> > order permutations.
> >
> > Signed-off-by: Ville Syrjälä
> Didn't look
From: Ville Syrjälä
mount("/sys/kernel/debug") will return an error if something is already
mounted there. So let's check for that before calling mount(). This
allows many of the tools (eg. intel_reg) to work even when no drm
drivers are loaded since the earlier "/sys/kernel/debug/dri" & co.
path
From: Ville Syrjälä
CCK houses various important clock related registers. Let's
dump those as well.
Signed-off-by: Ville Syrjälä
---
tools/registers/cherryview | 1 +
tools/registers/valleyview | 1 +
tools/registers/vlv_cck.txt | 11 +++
3 files changed, 13 insertions(+)
create m
From: Ville Syrjälä
Knowing how were trasmitting the data is pretty important, so let's
dump out the video transfer mode and pixel overlap for DSI.
Signed-off-by: Ville Syrjälä
---
tools/intel_bios.h| 3 ++-
tools/intel_bios_reader.c | 8 ++--
2 files changed, 8 insertions(+), 3 de
From: Ville Syrjälä
We don't need the drm fd to find out the PCI device ID. So let's drop
the drm stuff, which allows the tool to work without i915 loaded.
Signed-off-by: Ville Syrjälä
---
tools/intel_display_poller.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/to
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Start computing the vlv/chv watermarks the atomic way, from the
> .compute_pipe_wm() hook. We'll recompute the actual watermarks
> for only planes that are part of the state, the other planes will
> keep their wa
Op 15-12-16 om 16:23 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote:
>> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> Add a test to try out all the different plane enable/disable
>>> order permutations.
>>>
>
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: f720625c665f237616e3320255a89cdf394d2451
commit: a3f913ca98925d7e5bae725e9b2b38408215a695 [891/920] drm: Pass 'dev' to
drm_helper_mode_fill_fb_struct()
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
make[3]: w
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
> lead to an underrun. This only happens when sprite0 FIFO size is zero
> prior to enabling it. Hence an effective workaround is to always
> a
On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 16:23 schreef Ville Syrjälä:
> > On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote:
> >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> >>> From: Ville Syrjälä
> >>>
> >>> Add a test
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Check whether anything relevant has actually change when we compute new
> watermarks for each plane in the state. If the watermarks for no
> primary/sprite planes changed we don't have to recompute the FIFO split
On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Start computing the vlv/chv watermarks the atomic way, from the
> > .compute_pipe_wm() hook. We'll recompute the actual watermarks
> > fo
Op 15-12-16 om 16:36 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote:
>> Op 15-12-16 om 16:23 schreef Ville Syrjälä:
>>> On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote:
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
>>>
Op 15-12-16 om 16:38 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote:
>> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> Start computing the vlv/chv watermarks the atomic way, from the
>>> .compute_pipe_wm() hoo
On Thu, Dec 15, 2016 at 04:34:58PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
> > lead to an underrun. This only happens when sprite0 FIFO size i
Let intel_guc_init() focus on determining and fetching the correct
firmware.
This patch introduces intel_sanitize_uc_params() that is called from
intel_uc_init().
Then, if we have GuC, we can call intel_guc_init() conditionally and we
do not have to do internal checks.
It can be easily extended
Currently guc_fw_path values can represent one of three possible states:
1) NULL - device without GuC
2) '\0' - device with GuC but no known firmware
3) else - device with GuC and known firmware
Second case is used only to WARN at the later stage.
We can WARN right away and merge cases 1 and
GuC historically has two "startup" functions called _init() and _setup()
Then HuC came with it's _init() and _load().
To make naming more consistent this commit renames intel_guc_setup() to
intel_guc_load() as it it seams more fitting (it's in intel_guc_loader.c
after all).
Cc: Anusha Srivatsa
Current version of intel_guc_load() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_load(), which now
cares about the above.
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
driver
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 64353e762935a7ad82867be0e4e80ff2f7bc97e4
commit: ca984a998ad3a3b6bf8bf0d89861a6537551aaf2 [902/919] drm/fb_cma_helper:
Replace drm_format_info() with fb->format
config: m68k-allyesconfig (attached as .config)
compiler: m68k-
General GuC cleanup simplifying logic, and moving chooks around either for
simplification or cleaner HuC accommodation.
A lot of logic were extracted from intel_guc_load() to other functions - it not
only did handle the actual loading but had WA implementations and submission
enabling code baked i
We will be able to bulk call all firmware _init() function from single
point and offset some general logic there.
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 5 +
drive
On Thu, Dec 15, 2016 at 12:51:42PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
> crtc_state after commit. Move it to atomic_state->crtcs.
>
> Also stop re-using new_crtc_state->enable, we can now simply set a
> bitmask with crtc_crtc_mas
On Thu, Dec 15, 2016 at 04:47:04PM +0100, Arkadiusz Hiler wrote:
> GuC historically has two "startup" functions called _init() and _setup()
>
> Then HuC came with it's _init() and _load().
>
> To make naming more consistent this commit renames intel_guc_setup() to
> intel_guc_load() as it it seam
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing
1 - 100 of 215 matches
Mail list logo
