[Intel-gfx] [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops
From: Chris Wilson
This provides support for the Drivers or shmem file owners to register
a set of callbacks, which can be invoked from the address space operations
methods implemented by shmem.
This allow the file owners to hook into the shmem address space operations
to do some extra/custom operations in addition to the default ones.
The private_data field of address_space struct is used to store the pointer
to driver specific ops.
Currently only one ops field is defined, which is migratepage, but can be
extended on need basis.
The need for driver specific operations arises since some of the operations
(like migratepage) may not be handled completely within shmem, so as to be
effective, and would need some driver specific handling also.
Specifically, i915.ko would like to participate in migratepage().
i915.ko uses shmemfs to provide swappable backing storage for its user
objects, but when those objects are in use by the GPU it must pin the entire
object until the GPU is idle. As a result, large chunks of memory can be
arbitrarily withdrawn from page migration, resulting in premature
out-of-memory due to fragmentation. However, if i915.ko can receive the
migratepage() request, it can then flush the object from the GPU, remove
its pin and thus enable the migration.
Since Gfx allocations are one of the major consumer of system memory, its
imperative to have such a mechanism to effectively deal with fragmentation.
And therefore the need for such a provision for initiating driver specific
actions during address space operations.
Cc: Hugh Dickins
Cc: linux...@kvack.org
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
---
include/linux/shmem_fs.h | 17 +
mm/shmem.c | 17 -
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index 4d4780c..6cfa76a 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -34,11 +34,28 @@ struct shmem_sb_info {
struct mempolicy *mpol; /* default memory policy for mappings */
};
+struct shmem_dev_info {
+ void *dev_private_data;
+ int (*dev_migratepage)(struct address_space *mapping,
+ struct page *newpage, struct page *page,
+ enum migrate_mode mode, void *dev_priv_data);
+};
+
static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
{
return container_of(inode, struct shmem_inode_info, vfs_inode);
}
+static inline int shmem_set_device_ops(struct address_space *mapping,
+ struct shmem_dev_info *info)
+{
+ if (mapping->private_data != NULL)
+ return -EEXIST;
+
+ mapping->private_data = info;
+ return 0;
+}
+
/*
* Functions in mm/shmem.c called directly from elsewhere:
*/
diff --git a/mm/shmem.c b/mm/shmem.c
index 440e2a7..f8625c4 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -952,6 +952,21 @@ redirty:
return 0;
}
+#ifdef CONFIG_MIGRATION
+static int shmem_migratepage(struct address_space *mapping,
+struct page *newpage, struct page *page,
+enum migrate_mode mode)
+{
+ struct shmem_dev_info *dev_info = mapping->private_data;
+
+ if (dev_info && dev_info->dev_migratepage)
+ return dev_info->dev_migratepage(mapping, newpage, page,
+ mode, dev_info->dev_private_data);
+
+ return migrate_page(mapping, newpage, page, mode);
+}
+#endif
+
#ifdef CONFIG_NUMA
#ifdef CONFIG_TMPFS
static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
@@ -3168,7 +3183,7 @@ static const struct address_space_operations shmem_aops =
{
.write_end = shmem_write_end,
#endif
#ifdef CONFIG_MIGRATION
- .migratepage= migrate_page,
+ .migratepage= shmem_migratepage,
#endif
.error_remove_page = generic_error_remove_page,
};
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Make pages of GFX allocations movable
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get fragmented
severely, which considerably slows down the system. In such a scenario,
Shrinker is also unable to help as lack of memory is not the actual problem,
since it has been observed that there are enough free pages of 0 order.
To address the issue of external fragementation, kernel does a compaction
(which involves migration of pages) but it's efficacy depends upon how many
pages are marked as MOVABLE, as only those pages can be migrated.
Currently the backing pages for GFX buffers are allocated from shmemfs
with GFP_RECLAIMABLE flag, in units of 4KB pages.
In the case of limited Swap space, it may not be possible always to reclaim
or swap-out pages of all the inactive objects, to make way for free space
allowing formation of higher order groups of physically-contiguous pages
on compaction.
Just marking the GFX pages as MOVABLE will not suffice, as i915 Driver
has to pin the pages if they are in use by GPU, which will prevent their
migration. So the migratepage callback in shmem is also hooked up to get a
notification when kernel initiates the page migration. On the notification,
i915 Driver appropriately unpin the pages.
With this Driver can effectively mark the GFX pages as MOVABLE and hence
mitigate the fragmentation problem.
Cc: Hugh Dickins
Cc: linux...@kvack.org
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem.c | 128 +++-
2 files changed, 128 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f330a53..28e50c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include "intel_guc.h"
#include "intel_dpll_mgr.h"
@@ -1966,6 +1967,8 @@ struct drm_i915_private {
struct intel_encoder *dig_port_map[I915_MAX_PORTS];
+ struct shmem_dev_info migrate_info;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8588c83..a4af5b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -33,6 +33,7 @@
#include "i915_trace.h"
#include "intel_drv.h"
#include
+#include
#include
#include
#include
@@ -2204,6 +2205,7 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj)
if (obj->madv == I915_MADV_WILLNEED)
mark_page_accessed(page);
+ set_page_private(page, 0);
page_cache_release(page);
}
obj->dirty = 0;
@@ -2318,6 +2320,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
sg->length += PAGE_SIZE;
}
last_pfn = page_to_pfn(page);
+ set_page_private(page, (unsigned long)obj);
/* Check that the i965g/gm workaround works. */
WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL));
@@ -2343,8 +2346,11 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
err_pages:
sg_mark_end(sg);
- for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
- page_cache_release(sg_page_iter_page(&sg_iter));
+ for_each_sg_page(st->sgl, &sg_iter, st->nents, 0) {
+ page = sg_page_iter_page(&sg_iter);
+ set_page_private(page, 0);
+ page_cache_release(page);
+ }
sg_free_table(st);
kfree(st);
@@ -4465,9 +4471,116 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
};
+#ifdef CONFIG_MIGRATION
+static int i915_migratepage(struct address_space *mapping,
+ struct page *newpage, struct page *page,
+ enum migrate_mode mode, void *dev_priv_data)
+{
+ struct drm_i915_private *dev_priv = dev_priv_data;
+ struct drm_device *dev = dev_priv->dev;
+ struct drm_i915_gem_object *obj;
+ unsigned long timeout = msecs_to_jiffies(10) + 1;
+ int ret = 0;
+
+ WARN((page_count(newpage) != 1), "Unexpected ref count for newpage\n");
+
+ /*
+* Clear the private field of the new target page as it could have a
+* stale value in the private field. Otherwise later on if this page
+* itself gets migrated, without getting referred by the Driver
+* in between, the stale value would cause the i915_migratepage
+* function to go for a toss as object pointer is derived from it.
+* This should be safe since at the time of migration, private field
+* of the new page (which is actually an independent free 4KB page now)
+*
Re: [Intel-gfx] [PATCH] drm/i915: BXT DDI PHY sequence BUN
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Monday, March 21, 2016 7:34 PM
> To: Kannan, Vandana
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: BXT DDI PHY sequence BUN
>
> On Mon, Mar 21, 2016 at 12:12:40PM +0530, Vandana Kannan wrote:
> > According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register
> needs
> > to be checked to ensure that the register is in accessible state.
> > Also, based on a BSpec update, changing the timeout value to check
> > iphypwrgood, from 10ms to wait for up to 100us.
> >
> > Signed-off-by: Vandana Kannan
> > Reported-by: Philippe Lecluse
> > Cc: Deak, Imre
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_ddi.c | 11 +--
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 7dfc400..9a02bfc 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1318,6 +1318,7 @@ enum skl_disp_power_wells {
> > #define _PORT_CL1CM_DW0_A 0x162000
> > #define _PORT_CL1CM_DW0_BC 0x6C000
> > #define PHY_POWER_GOOD (1 << 16)
> > +#define PHY_RESERVED (1 << 7)
> > #define BXT_PORT_CL1CM_DW0(phy)_BXT_PHY((phy),
> _PORT_CL1CM_DW0_BC, \
> > _PORT_CL1CM_DW0_A)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 62de9f4..354f949 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2669,9 +2669,16 @@ static void broxton_phy_init(struct
> drm_i915_private *dev_priv,
> > val |= GT_DISPLAY_POWER_ON(phy);
> > I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
> >
> > - /* Considering 10ms timeout until BSpec is updated */
> > - if (wait_for(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> PHY_POWER_GOOD, 10))
> > + /*
> > +* HW team confirmed that the time to reach phypowergood status
> is
> > +* anywhere between 50 us and 100us.
> > +*/
> > + if (wait_for_atomic_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy))
> &
>
> Switching to atomic wait seems silly.
>
[Vandana] You think wait_for_us should suffice here?
> > + PHY_RESERVED)) &&
> > + ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > + PHY_POWER_GOOD) ==
> PHY_POWER_GOOD)), 100)) {
> > DRM_ERROR("timeout during PHY%d power on\n", phy);
> > + }
> >
> > for (port = (phy == DPIO_PHY0 ? PORT_B : PORT_A);
> > port <= (phy == DPIO_PHY0 ? PORT_C : PORT_A); port++) {
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/fbc: enable FBC on SKL too
Em Ter, 2016-03-22 às 12:16 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:58PM -0300, Paulo Zanoni wrote:
> >
> > Now that we're more protected against user space doing frontbuffer
> > mmap rendering, the last - how many times did I say this before? -
> > SKL problem seems to be solved. So let's give it a try.
> >
> > If you reached this commit through git bisect or if you just want
> > more
> > information about FBC, please see:
> > commit a98ee79317b4091cafb502b4ffdbbbe1335e298c
> > Author: Paulo Zanoni
> > Date: Tue Feb 16 18:47:21 2016 -0200
> > drm/i915/fbc: enable FBC by default on HSW and BDW
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 718ac38..67f8810 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1270,7 +1270,8 @@ void intel_fbc_init(struct drm_i915_private
> > *dev_priv)
> > * know what's going on. */
> > if (i915.enable_fbc < 0) {
> > i915.enable_fbc = IS_HASWELL(dev_priv) ||
> > - IS_BROADWELL(dev_priv);
> > + IS_BROADWELL(dev_priv) ||
> > + IS_SKYLAKE(dev_priv);
> Can we just future-proof this and enable on everything gen8+ where we
> have
> fbc? Apparently bsw/bxt simply lack this ...
This can be done, but I'm not sure if it's a good idea, given FBC's
never-ending history of platform-specific workarounds. We'd force
people to have to have FBC working right from the start. Hmmm, that
could actually be a good thing, enforcing people to make features work.
> -Daniel
>
> >
> > DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
> > i915.enable_fbc);
> > }
> > --
> > 2.7.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC
Em Ter, 2016-03-22 às 12:29 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:57PM -0300, Paulo Zanoni wrote:
> >
> > FBC and the frontbuffer tracking infrastructure were designed
> > assuming
> > that user space applications would follow a specific set of rules
> > regarding frontbuffer management and mmapping. I recently
> > discovered
> > that current user space is not exactly following these rules: my
> > investigation led me to the conclusion that the generic backend
> > from
> > SNA - used by SKL and the other new platforms without a specific
> > backend - is not issuing sw_finish/dirty_fb IOCTLs when using the
> > CPU
> > and WC mmaps. I discovered this when running lightdm: I would type
> > the
> > password and nothing would appear on the screen unless I moved the
> > mouse over the place where the letters were supposed to appear.
> >
> > Since we can't detect whether the current DRM master is a well-
> > behaved
> > application or not, let's use the sledgehammer approach and assume
> > that every user space client on every gen is bad by disabling FBC
> > when
> > the frontbuffer is CPU/WC mmapped. This will allow us to enable
> > FBC
> > on SKL, moving its FBC-related power savings from "always 0%" to ">
> > 0%
> > in some cases".
> >
> > There's also some additional code to disable the workaround for
> > frontbuffers that ever received a sw_finish or dirty_fb IOCTL,
> > since
> > the current bad user space never issues those calls. This should
> > help
> > for some specific cases and our IGT tests, but won't be enough for
> > a
> > new xf86-video-intel using TearFree.
> >
> > Notice that we may need an equivalent commit for PSR too. We also
> > need
> > to investigate whether PSR needs to be disabled on GTT mmaps: if
> > that's the case, we'll have problems since we seem to always have
> > GTT
> > mmaps on our current user space, so we would end up keeping PSR
> > disabled forever.
> >
> > v2:
> > - Rename some things.
> > - Disable the WA on sw_finish/dirty_fb (Daniel).
> > - Fix NULL obj checking.
> > - Restric to Gen 9.
> >
> > Cc: Rodrigo Vivi
> > Cc: Daniel Vetter
> > Cc: Chris Wilson
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 9 +
> > drivers/gpu/drm/i915/i915_gem.c | 19 +++---
> > drivers/gpu/drm/i915/intel_display.c | 1 +
> > drivers/gpu/drm/i915/intel_drv.h | 3 +++
> > drivers/gpu/drm/i915/intel_fbc.c | 33
> >
> > drivers/gpu/drm/i915/intel_frontbuffer.c | 31
> > ++
> > 6 files changed, 89 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index efca534..45e31d2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -873,6 +873,13 @@ enum fb_op_origin {
> > ORIGIN_DIRTYFB,
> > };
> >
> > +enum fb_mmap_wa_flags {
> > + FB_MMAP_WA_CPU =1 << 0,
> > + FB_MMAP_WA_GTT =1 << 1,
> > + FB_MMAP_WA_DISABLE = 1 << 2,
> > + FB_MMAP_WA_FLAG_COUNT = 3,
> > +};
> > +
I'll do the change to macros you/Jani mentioned in the other emails.
> > struct intel_fbc {
> > /* This is always the inner lock when overlapping with
> > struct_mutex and
> > * it's the outer lock when overlapping with stolen_lock.
> > */
> > @@ -910,6 +917,7 @@ struct intel_fbc {
> > unsigned int stride;
> > int fence_reg;
> > unsigned int tiling_mode;
> > + unsigned int mmap_wa_flags;
> > } fb;
> > } state_cache;
> >
> > @@ -2143,6 +2151,7 @@ struct drm_i915_gem_object {
> > unsigned int cache_dirty:1;
> >
> > unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
> > + unsigned int fb_mmap_wa_flags:FB_MMAP_WA_FLAG_COUNT;
> >
> > unsigned int pin_display;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 8588c83..d44f27e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1692,6 +1692,8 @@ i915_gem_sw_finish_ioctl(struct drm_device
> > *dev, void *data,
> > goto unlock;
> > }
> >
> > + intel_fb_obj_mmap_wa(obj, FB_MMAP_WA_DISABLE);
> > +
> > /* Pinned buffers may be scanout, so flush the cache */
> > if (obj->pin_display)
> > i915_gem_object_flush_cpu_write_domain(obj);
> > @@ -1724,7 +1726,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> > void *data,
> > struct drm_file *file)
> > {
> > struct drm_i915_gem_mmap *args = data;
> > - struct drm_gem_object *obj;
> > + struct drm_i915_gem_object *obj;
> > unsigned long addr;
> >
> > if (args->flags & ~(I915_MMAP_WC))
> > @@ -1733,19 +1735,19 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> > void *data,
> > if (args->flags & I915_MMAP_WC && !cpu_has_
Re: [Intel-gfx] [RFC xf86-video-intel] sna: Call dirtyfb for all non-tear-free cases
Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu: > On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote: > > > > The sna_mode_wants_tear_free() function tries to detect FBC and PSR > > based on Kernel module parameters. Currently it fails to detect FBC > > due to the default enable_fbc value being -1. While this can easily > > be > > fixed in the Kernel, I had a conversation with Daniel and he > > expressed > > unhappiness with that solution, claiming that yet another different > > code path just for a feature that should be transparent is not a > > good > > way to go, and that we should do proper frontbuffer rendering. > > > > So with this patch, we'll have the DDX issuing dirtyfb calls even > > if > > TearFree is not enabled, fixing FBC when i915.enable_fbc=-1. > > > > This fixes a bug that happens on SKL with FBC enabled: if you run > > lightdm, your login/password won't appear as you type on your > > keyboard. You have to move the mouse over the input box for them to > > be > > displayed. > > > > Cc: Chris Wilson > > Signed-off-by: Paulo Zanoni > I thought we need this anyway to get the kernel to allow fbc, since > SNA > ends up mmap some of the drm_framebuffer. Even when they're not > frontbuffers. If we merge patch 2/4, we won't need this one since TearFree will be in use, and it seems TearFree doesn't touch frontbuffers, so we'll always get the flush calls during page flips. > -Daniel > > > > > --- > > src/sna/sna_driver.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c > > index b245594..84e8e55 100644 > > --- a/src/sna/sna_driver.c > > +++ b/src/sna/sna_driver.c > > @@ -654,7 +654,7 @@ static Bool sna_pre_init(ScrnInfoPtr scrn, int > > probe) > > } > > scrn->currentMode = scrn->modes; > > > > - if (!setup_tear_free(sna) && > > sna_mode_wants_tear_free(sna)) > > + if (!setup_tear_free(sna)) > > sna->kgem.needs_dirtyfb = sna->kgem.has_dirtyfb; > > > > xf86SetGamma(scrn, zeros); > > -- > > 2.7.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbc: update busy_bits even for GTT and flip flushes
Em Ter, 2016-03-22 às 12:13 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:54PM -0300, Paulo Zanoni wrote:
> >
> > We ignore ORIGIN_GTT because the hardware tracking can recognize
> > GTT
> > writes and take care of them. We also ignore ORIGIN_FLIP because we
> > deal with flips without relying on the frontbuffer tracking
> > infrastructure. On the other hand, a flush is a flush and means
> > we're
> > good to go, so we need to update busy_bits in order to reflect
> > that,
> > even if we're not going to do anything else about it.
> >
> > How to reproduce the bug fixed by this patch:
> > - boot SKL up to the desktop environment
> > - stop the display manager
> > - run any of the igt/kms_frontbuffer_tracking/*fbc*onoff* subtests
> > - the tests will fail
> >
> > The steps above will create the right conditions for us to lose
> > track
> > of busy_bits. If you, for example, run the full set of FBC tests,
> > the
> > onoff subtests will succeed.
> >
> > Also notice that the "bug" is that we'll just keep FBC disabled on
> > cases where it could be enabled, so it's not something the users
> > can
> > perceive, it just affects power consumption numbers on properly
> > configured machines.
> >
> > Signed-off-by: Paulo Zanoni
> Is this covered by your nasty igt test suite? Kernel side looks good,
> so
> with appropriate Testcase: tag added:
I mentioned the tests in the middle of the commit message, but forgot
the Testcase tags. I'll add them.
>
> Reviewed-by: Daniel Vetter
Thanks!
>
> >
> > ---
> > drivers/gpu/drm/i915/intel_fbc.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 2e571f5..b8ba79c 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -996,13 +996,13 @@ void intel_fbc_flush(struct drm_i915_private
> > *dev_priv,
> > if (!fbc_supported(dev_priv))
> > return;
> >
> > - if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
> > - return;
> > -
> > mutex_lock(&fbc->lock);
> >
> > fbc->busy_bits &= ~frontbuffer_bits;
> >
> > + if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
> > + goto out;
> > +
> > if (!fbc->busy_bits && fbc->enabled &&
> > (frontbuffer_bits &
> > intel_fbc_get_frontbuffer_bit(fbc))) {
> > if (fbc->active)
> > @@ -1011,6 +1011,7 @@ void intel_fbc_flush(struct drm_i915_private
> > *dev_priv,
> > __intel_fbc_post_update(fbc->crtc);
> > }
> >
> > +out:
> > mutex_unlock(&fbc->lock);
> > }
> >
> > --
> > 2.7.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/guc: always reset GuC before loading firmware
On 22/03/2016 13:32, Arun Siluvery wrote:
On 21/03/2016 10:16, Dave Gordon wrote:
After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loaded the GuC with
firmware, which will then cause this kernel's attempt to (re)load the
firmware to fail (GuC program memory is write-once!).
So here we choose to always reset the GuC just before (re)loading the
firmware, so the hardware should then be in a well-known state, and we
may even avoid some of the issues arising from unpredictable timing.
Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.
Signed-off-by: Dave Gordon
Cc: Arun Siluvery
Cc: Alex Dai
Please add bugzilla reference.
https://bugs.freedesktop.org/show_bug.cgi?id=94390
regards
Arun
---
drivers/gpu/drm/i915/i915_guc_reg.h | 12 --
drivers/gpu/drm/i915/intel_guc_loader.c | 40
-
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 94ceee5..80786d9 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -27,10 +27,12 @@
/* Definitions of GuC H/W registers, bits, etc */
#define GUC_STATUS_MMIO(0xc000)
-#define GS_MIA_IN_RESET(1 << 0)
+#define GS_RESET_SHIFT0
+#define GS_MIA_IN_RESET (0x01 << GS_RESET_SHIFT)
#define GS_BOOTROM_SHIFT1
#define GS_BOOTROM_MASK (0x7F << GS_BOOTROM_SHIFT)
#define GS_BOOTROM_RSA_FAILED (0x50 << GS_BOOTROM_SHIFT)
+#define GS_BOOTROM_JUMP_PASSED (0x76 << GS_BOOTROM_SHIFT)
#define GS_UKERNEL_SHIFT8
#define GS_UKERNEL_MASK (0xFF << GS_UKERNEL_SHIFT)
#define GS_UKERNEL_LAPIC_DONE (0x30 << GS_UKERNEL_SHIFT)
@@ -38,7 +40,13 @@
#define GS_UKERNEL_READY (0xF0 << GS_UKERNEL_SHIFT)
#define GS_MIA_SHIFT16
#define GS_MIA_MASK (0x07 << GS_MIA_SHIFT)
-#define GS_MIA_CORE_STATE (1 << GS_MIA_SHIFT)
+#define GS_MIA_CORE_STATE (0x01 << GS_MIA_SHIFT)
+#define GS_MIA_HALT_REQUESTED (0x02 << GS_MIA_SHIFT)
+#define GS_MIA_ISR_ENTRY (0x04 << GS_MIA_SHIFT)
+#define GS_AUTH_STATUS_SHIFT30
+#define GS_AUTH_STATUS_MASK (0x03 << GS_AUTH_STATUS_SHIFT)
+#define GS_AUTH_STATUS_BAD (0x01 << GS_AUTH_STATUS_SHIFT)
+#define GS_AUTH_STATUS_GOOD (0x02 << GS_AUTH_STATUS_SHIFT)
#define SOFT_SCRATCH(n)_MMIO(0xc180 + (n) * 4)
#define SOFT_SCRATCH_COUNT16
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index a07c228..a875936 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -387,7 +387,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
-int err = 0;
+int retries, err = 0;
if (!i915.enable_guc_submission)
return 0;
@@ -441,29 +441,26 @@ int intel_guc_ucode_load(struct drm_device *dev)
* steppings also so this is extended as well.
*/
/* WaEnableGuCBootHashCheckNotSet:skl,bxt */
-err = guc_ucode_xfer(dev_priv);
-if (err) {
-int retries = 3;
-
-DRM_ERROR("GuC fw load failed, err=%d, attempting reset and
retry\n", err);
-
-while (retries--) {
-err = i915_reset_guc(dev_priv);
-if (err)
-break;
-
-err = guc_ucode_xfer(dev_priv);
-if (!err) {
-DRM_DEBUG_DRIVER("GuC fw reload succeeded after
reset\n");
-break;
-}
-DRM_DEBUG_DRIVER("GuC fw reload retries left: %d\n",
retries);
-}
-
+for (retries = 3; ; ) {
+/*
+ * Always reset the GuC just before (re)loading, so
+ * that the state and timing are fairly predictable
+ */
+err = i915_reset_guc(dev_priv);
if (err) {
-DRM_ERROR("GuC fw reload attempt failed, ret=%d\n", err);
+DRM_ERROR("GuC reset failed, err %d\n", err);
goto fail;
}
+
+err = guc_ucode_xfer(dev_priv);
+if (!err)
+break;
+
+if (--retries == 0)
+goto fail;
+
+DRM_INFO("GuC fw load failed, err %d; will reset and "
+"retry %d more time(s)\n", err, retries);
}
guc_fw->guc_fw_load_status = GUC_FIRMWARE_SUCCESS;
@@ -485,6 +482,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
return 0;
fail:
+DRM_ERROR("GuC firmware load failed, err %d\n", err);
if (guc_fw->guc_fw_load_status == GUC_FIRMWARE_PENDING)
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Shrink i915_gem_request_add_to_client
On Tue, Mar 22, 2016 at 05:16:53PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We do not need to check twice for the same conditions. > > Results in clearer code and smaller binary. The checks are entirely garbage. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Cache elsp submit register
On 22/03/16 17:29, Ville Syrjälä wrote: On Tue, Mar 22, 2016 at 05:16:52PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Since we write four times to the same register, caching the mmio register saves a tiny amount of generated code. The compiler can't figure this out on its own? Nope, at least gcc 4.84 I am running here can't. :( And this only solves one part of the things it can't figure out in that code. It still recalculates one part, can't remember which one is which now without revisiting the generated assembly. It used to be for times in a row: load register, add 0x230, displace 0x78, store[0-4]. This only solves the add 0x230 redundancy. But working around that would possibly be a bit too low level. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Cache elsp submit register
== Series Details == Series: series starting with [1/2] drm/i915: Cache elsp submit register URL : https://patchwork.freedesktop.org/series/4761/ State : failure == Summary == Series 4761v1 Series without cover letter 2016-03-22T16:54:47.686093 http://patchwork.freedesktop.org/api/1.0/series/4761/revisions/1/mbox/ Applying: drm/i915: Cache elsp submit register Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/intel_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c Patch failed at 0001 drm/i915: Cache elsp submit register ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
On Tue, Mar 22, 2016 at 02:10:47AM -0700, Deak, Imre wrote: > On ke, 2016-03-16 at 18:06 -0700, Dongwon Kim wrote: > > For BXT, description of polarities of PORT_PLL_REF_SEL > > has been reversed for newer Gen9LP steppings according to the > > recent update in Bspec. This bit now should be set for > > "Non-SSC" mode for all Gen9LP starting from B0 stepping. > > > > v2: Only B0 and newer stepping should be affected by this > > change. > > What is this stepping information based on? It's not in BSpec, could > you file a change request to get it added there? > > --Imre That information is actually missing in Bspec and has to be added. I got this info from the owner of the HSD sighting directly. I will file a change request in Bspec. > > > > > Signed-off-by: Dongwon Kim > > --- > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 10 +- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c > > index 4b636c4..c84589e 100644 > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c > > @@ -1285,7 +1285,15 @@ static void bxt_ddi_pll_enable(struct > > drm_i915_private *dev_priv, > > enum port port = (enum port)pll->id;/* 1:1 port->PLL > > mapping */ > > > > temp = I915_READ(BXT_PORT_PLL_ENABLE(port)); > > - temp &= ~PORT_PLL_REF_SEL; > > + /* > > + * Definition of each bit polarity has been changed > > + * after A1 stepping > > + */ > > + if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) > > + temp &= ~PORT_PLL_REF_SEL; > > + else > > + temp |= PORT_PLL_REF_SEL; > > + > > /* Non-SSC reference */ > > I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp); > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915: Move execlists irq handler to a bottom half
From: Tvrtko Ursulin
Doing a lot of work in the interrupt handler introduces huge
latencies to the system as a whole.
Most dramatic effect can be seen by running an all engine
stress test like igt/gem_exec_nop/all where, when the kernel
config is lean enough, the whole system can be brought into
multi-second periods of complete non-interactivty. That can
look for example like this:
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143]
Modules linked in: [redacted for brevity]
CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ #183
Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1
Workqueue: i915 gen6_pm_rps_work [i915]
task: 8800aae88000 ti: 8800aae9 task.ti: 8800aae9
RIP: 0010:[] [] __do_softirq+0x72/0x1d0
RSP: :88014f403f38 EFLAGS: 0206
RAX: 8800aae94000 RBX: RCX: 06e0
RDX: 0020 RSI: 04208060 RDI: 00215d80
RBP: 88014f403f80 R08: 000b1b42c180 R09: 0022
R10: 0004 R11: R12: a030
R13: 0082 R14: 8800aa4d0080 R15: 0082
FS: () GS:88014f40() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7fa53b90c000 CR3: 01a0a000 CR4: 001406f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Stack:
042080601b33869f 8800aae94000 fffc2678 8801000a
a030 5302 8800aa4d0080
0206 88014f403f90 8104a716 88014f403fa8
Call Trace:
[] irq_exit+0x86/0x90
[] smp_apic_timer_interrupt+0x3d/0x50
[] apic_timer_interrupt+0x7c/0x90
[] ? gen8_write64+0x1a0/0x1a0 [i915]
[] ? _raw_spin_unlock_irqrestore+0x9/0x20
[] gen8_write32+0x104/0x1a0 [i915]
[] ? n_tty_receive_buf_common+0x372/0xae0
[] gen6_set_rps_thresholds+0x1be/0x330 [i915]
[] gen6_set_rps+0x70/0x200 [i915]
[] intel_set_rps+0x25/0x30 [i915]
[] gen6_pm_rps_work+0x10d/0x2e0 [i915]
[] ? finish_task_switch+0x72/0x1c0
[] process_one_work+0x139/0x350
[] worker_thread+0x126/0x490
[] ? rescuer_thread+0x320/0x320
[] kthread+0xc4/0xe0
[] ? kthread_create_on_node+0x170/0x170
[] ret_from_fork+0x3f/0x70
[] ? kthread_create_on_node+0x170/0x170
I could not explain, or find a code path, which would explain
a +20 second lockup, but from some instrumentation it was
apparent the interrupts off proportion of time was between
10-25% under heavy load which is quite bad.
By moving the GT interrupt handling to a tasklet in a most
simple way, the problem above disappears completely.
Also, gem_latency -n 100 shows 25% better throughput and CPU
usage, and 14% better latencies.
I did not find any gains or regressions with Synmark2 or
GLbench under light testing. More benchmarking is certainly
required.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 19 +--
drivers/gpu/drm/i915/intel_lrc.h| 1 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
4 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8f3e3309c3ab..e68134347007 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1324,7 +1324,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir, int test_shift)
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
notify_ring(engine);
if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift))
- intel_lrc_irq_handler(engine);
+ tasklet_schedule(&engine->irq_tasklet);
}
static irqreturn_t gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6916991bdceb..283426c02f8b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -538,21 +538,23 @@ get_context_status(struct intel_engine_cs *engine,
unsigned int read_pointer,
/**
* intel_lrc_irq_handler() - handle Context Switch interrupts
- * @ring: Engine Command Streamer to handle.
+ * @engine: Engine Command Streamer to handle.
*
* Check the unread Context Status Buffers and manage the submission of new
* contexts to the ELSP accordingly.
*/
-void intel_lrc_irq_handler(struct intel_engine_cs *engine)
+void intel_lrc_irq_handler(unsigned long data)
{
+ struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct drm_i915_private *dev_priv = engine->dev->dev_private;
u32 status_pointer;
unsigned int read_pointer, write_pointer;
u32 csb[GEN8_CSB_ENTRIES][2];
unsigned int csb_read = 0, i;
unsigned int s
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Cache elsp submit register
On Tue, Mar 22, 2016 at 05:16:52PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Since we write four times to the same register, caching
> the mmio register saves a tiny amount of generated code.
The compiler can't figure this out on its own?
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index e733795b57e0..6916991bdceb 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -362,6 +362,7 @@ static void execlists_elsp_write(struct
> drm_i915_gem_request *rq0,
>
> struct intel_engine_cs *engine = rq0->engine;
> struct drm_i915_private *dev_priv = rq0->i915;
> + i915_reg_t elsp_reg = RING_ELSP(engine);
> uint64_t desc[2];
>
> if (rq1) {
> @@ -375,12 +376,12 @@ static void execlists_elsp_write(struct
> drm_i915_gem_request *rq0,
> rq0->elsp_submitted++;
>
> /* You must always write both descriptors in the order below. */
> - I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[1]));
> - I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[1]));
> + I915_WRITE_FW(elsp_reg, upper_32_bits(desc[1]));
> + I915_WRITE_FW(elsp_reg, lower_32_bits(desc[1]));
>
> - I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[0]));
> + I915_WRITE_FW(elsp_reg, upper_32_bits(desc[0]));
> /* The context is automatically loaded after the following */
> - I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[0]));
> + I915_WRITE_FW(elsp_reg, lower_32_bits(desc[0]));
>
> /* ELSP is a wo register, use another nearby reg for posting */
> POSTING_READ_FW(RING_EXECLIST_STATUS_LO(engine));
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/core: Fix ordering in drm_mode_config_cleanup.
== Series Details == Series: drm/core: Fix ordering in drm_mode_config_cleanup. URL : https://patchwork.freedesktop.org/series/4758/ State : success == Summary == Series 4758v1 drm/core: Fix ordering in drm_mode_config_cleanup. http://patchwork.freedesktop.org/api/1.0/series/4758/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (byt-nuc) Subgroup basic-rte: pass -> DMESG-WARN (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1679/ 83ed25fa1b956275542da63eb98dc8fd2291329d drm-intel-nightly: 2016y-03m-22d-15h-20m-55s UTC integration manifest 2fb96a0c0489a7c3c751ae69e7d13bf503d2ce25 drm/core: Fix ordering in drm_mode_config_cleanup. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] tests/gem_exec_mem_huge.c: New test to stress eviction
From: Piotr Luc
The aim of the test is to stress i915 memory eviction mechanism.
The test runs many processes, each of it executes NOP batch
which has attached really big data buffers chain.
While this is unusual use case, rather it doesn't occur in
normal games or applications, it possible to imagine that an
offending application can use the weakness of low memory handler
and i915 buffer eviction mechanism to conduct DoS attack.
Note that achieving this goal on standard PC could be difficult,
it may be easy in a system with limited capabilities (little memory,
lack of swap, a small number of cores).
Signed-off-by: Piotr Luc
---
tests/Makefile.sources| 1 +
tests/gem_exec_mem_huge.c | 196 ++
2 files changed, 197 insertions(+)
create mode 100644 tests/gem_exec_mem_huge.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 43f232f..b265f19 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -137,6 +137,7 @@ TESTS_progs = \
gem_ctx_thrash \
gem_double_irq_loop \
gem_exec_big \
+ gem_exec_mem_huge \
gem_exec_blt \
gem_exec_lut_handle \
gem_fd_exhaustion \
diff --git a/tests/gem_exec_mem_huge.c b/tests/gem_exec_mem_huge.c
new file mode 100644
index 000..58fb83b
--- /dev/null
+++ b/tests/gem_exec_mem_huge.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright ?? 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Piotr Luc
+ *
+ */
+
+/*
+ * Testcase: run a nop batch which has attached really big data buffers chain.
+ *
+ * Stress-test the low memory handler and buffer eviction interaction.
+ *
+ * Expectation:
+ * The test doesn't hang HW or SW on systems with swap; the run may take a
long
+ * time, but finally, the test finishes. On the system without swap but with
+ * low memory killer (like Android) the test process should be killed quickly
+ * but the system should remain functional.
+ */
+
+#include "igt.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "drm.h"
+#include
+
+IGT_TEST_DESCRIPTION("Run a small batch with large data BO to stress test the"
+"low memory killer handling");
+
+#define MAX_PROCESSES 256
+#define MAX_DATA_BUF (2*4)
+#define DATA_BUF_SIZE (256 * 1024 * 1024/2)
+
+#ifdef ANDROID
+#define NUMBER_OF_INITIAL_PROCESSES 2
+#define MT_FACTOR 1
+#else
+/* Linux systems have swap memory and usually many cores that can allow the
+ * first test process to finish before next processes start stressing memory.
+ * The bigger number of processes allows reach OOM state more likely.
+ */
+#define NUMBER_OF_INITIAL_PROCESSES 2
+#define MT_FACTOR 1
+#endif
+
+static void exec1(int fd, uint32_t handle, uint32_t *dhandles, unsigned count)
+{
+ struct drm_i915_gem_execbuffer2 execbuf = {0};
+ struct drm_i915_gem_exec_object2 gem_exec[MAX_DATA_BUF + 1] = {0};
+ unsigned i = 0;
+
+ for (i = 0; i != count && i < MAX_DATA_BUF; ++i) {
+ gem_exec[i].handle = dhandles[i];
+ }
+ gem_exec[i].handle = handle;
+
+ execbuf.buffers_ptr = (uintptr_t)gem_exec;
+ execbuf.buffer_count = i + 1;
+ execbuf.batch_start_offset = 0;
+ execbuf.batch_len = 8; // Just BB_END
+ execbuf.cliprects_ptr = 0;
+ execbuf.num_cliprects = 0;
+ execbuf.DR1 = 0;
+ execbuf.DR4 = 0;
+ execbuf.flags = 0;
+ i915_execbuffer2_set_context_id(execbuf, 0);
+ execbuf.rsvd2 = 0;
+
+ gem_execbuf(fd, &execbuf);
+ gem_sync(fd, handle);
+}
+
+static void run_test(unsigned pn)
+{
+ int fd;
+ uint32_t handle;
+ uint32_t batch[2] = {MI_BATCH_BUFFER_END, MI_BATCH_BUFFER_END};
+ uint32_t dhandles[MAX_DATA_BUF];
+ unsigned count = 0;
+
+
[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_core.c: Add new parameter to prevent disabling LMK
From: Piotr Luc
The 'keep-lmk-working' parameter added to prevent disabling the
Low Memory Killer.
Signed-off-by: Piotr Luc
---
lib/igt_core.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 1f9be7d..734457a 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -228,6 +228,7 @@
static unsigned int exit_handler_count;
const char *igt_interactive_debug;
+static bool igt_disable_memory_killer = true;
/* subtests helpers */
static bool list_subtests = false;
@@ -257,6 +258,7 @@ enum {
OPT_DESCRIPTION,
OPT_DEBUG,
OPT_INTERACTIVE_DEBUG,
+ OPT_KEEP_LOW_MEM_KILLER_WORKING,
OPT_HELP = 'h'
};
@@ -514,7 +516,9 @@ bool igt_exit_called;
static void common_exit_handler(int sig)
{
if (!igt_only_list_subtests()) {
- low_mem_killer_disable(false);
+ if (igt_disable_memory_killer) {
+ low_mem_killer_disable(false);
+ }
}
/* When not killed by a signal check that igt_exit() has been properly
@@ -551,6 +555,7 @@ static void print_usage(const char *help_str, bool
output_on_stderr)
" --run-subtest \n"
" --debug[=log-domain]\n"
" --interactive-debug[=domain]\n"
+ " --keep-lmk-working\n"
" --help-description\n"
" --help\n");
if (help_str)
@@ -584,6 +589,7 @@ static int common_init(int *argc, char **argv,
{"help-description", 0, 0, OPT_DESCRIPTION},
{"debug", optional_argument, 0, OPT_DEBUG},
{"interactive-debug", optional_argument, 0,
OPT_INTERACTIVE_DEBUG},
+ {"keep-lmk-working", optional_argument, 0,
OPT_KEEP_LOW_MEM_KILLER_WORKING},
{"help", 0, 0, OPT_HELP},
{0, 0, 0, 0}
};
@@ -699,6 +705,9 @@ static int common_init(int *argc, char **argv,
print_test_description();
ret = -1;
goto out;
+ case OPT_KEEP_LOW_MEM_KILLER_WORKING:
+ igt_disable_memory_killer = false;
+ break;
case OPT_HELP:
print_usage(help_str, false);
ret = -1;
@@ -738,7 +747,9 @@ out:
print_version();
oom_adjust_for_doom();
- low_mem_killer_disable(true);
+ if (igt_disable_memory_killer) {
+ low_mem_killer_disable(true);
+ }
}
/* install exit handler, to ensure we clean up */
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 0/2] New test to stress eviction
From: Piotr Luc The aim of the test is to stress i915 memory eviction mechanism on Android. It seems that Android systems, which usually don't have a swap file, experience some problems with killing offending processes that use a large amount of GFX memory. Linux systems seem to be more robust in this case and kill such processes because swap file allows to accept more memory requests, and also they are more distributed in time. However, Linux system with swap disabled behaves similar to Android. This test was developed to help replicate the OOM situation where system ends up with continuously repeated message: "Unable to purge GPU memory due lock contention." This state lasts long time, counted in minutes or hours, and Android systems seems to be unable to recover from it quickly, as it would be expected. I believe it could be treated as a kind of DoS attack caused by a malicious GFX application and need more investigation, thus this set of patches. The gem_exec_mem_huge test should be run with enabled low memory killer; the first patch adds a new parameter to prevent disabling LMK. Piotr Luc (2): lib/igt_core.c: Add new parameter to prevent disabling LMK tests/gem_exec_mem_huge.c: New test to stress eviction lib/igt_core.c| 15 +++- tests/Makefile.sources| 1 + tests/gem_exec_mem_huge.c | 196 ++ 3 files changed, 210 insertions(+), 2 deletions(-) create mode 100644 tests/gem_exec_mem_huge.c -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: add lspcon vbt bit parsing
Regards
Shashank
On 3/22/2016 10:35 PM, Ville Syrjälä wrote:
On Tue, Mar 22, 2016 at 10:20:33PM +0530, Sharma, Shashank wrote:
Thanks for the review, Jani.
Regards
Shashank
On 3/22/2016 9:24 PM, Jani Nikula wrote:
On Tue, 22 Mar 2016, Shashank Sharma wrote:
LSPCON can be configured on a port using VBT entry.
This patch adds code to parse VBT and detect presence of
LSPCON for a ddi port.
Signed-off-by: Akashdeep Sharma
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 42
+++
drivers/gpu/drm/i915/intel_vbt_defs.h | 1 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f330a53..cbd40de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3373,6 +3373,7 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
port);
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
+bool intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..a04ab5c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1588,3 +1588,45 @@ bool intel_bios_is_dsi_present(struct drm_i915_private
*dev_priv,
return false;
}
+
Please add kernel-doc comment like all the other intel_bios_is_*
functions have.
Ok,
+bool
+intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port)
You mean is *present*?
Well, this is embarrassing :) yes it was supposed to be present.
Please pass struct drm_i915_private *dev_priv instead of dev.
Ok
+{
+ unsigned char i;
+ enum port dvo_port = 0;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /* LSPCON is supported only for GEN 9 */
+ if (!IS_GEN9(dev))
+ return false;
+
+ /* Check if lspcon is supported in VBT */
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ if (!dev_priv->vbt.child_dev[i].common.lspcon)
I think to be defensive we should also check for bdb version >=
192. That we could check before the loop along with the gen check.
Yes, this can be done.
+ continue;
+
+ switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+ case DVO_PORT_DPB:
+ dvo_port = PORT_B;
+ break;
+
+ case DVO_PORT_DPC:
+ dvo_port = PORT_C;
+ break;
+
+ case DVO_PORT_DPD:
+ dvo_port = PORT_D;
+ break;
+
+ default:
+ continue;
+ }
+
+ if (dvo_port == port) {
+ DRM_DEBUG_DRIVER("LSPCON configured on port %c\n",
+ port_name(port));
+ return true;
+ }
+ }
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..0066b24 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -276,6 +276,7 @@ struct common_child_dev_config {
u8 flags_1;
u8 not_common3[13];
u8 iboost_level;
+ u8 lspcon:1;
Huh? AFAICT from the spec, lspcon is bit 2 in flags_1. You could define
flags_1 in terms of bitfields, including IBOOST_ENABLE.
I am not sure about this, let me go to VBT spec again, if there is a
recent change. Will update you on this.
There was a patch [1] posted recently which added the lspcon bit and others,
and that at least matches the spec at the time when I looked at it (or I
made a mistake). The patch just needs a rebase and it should be good to
go I think, though someone else double checking wouldn't hurt.
[1] https://lists.freedesktop.org/archives/intel-gfx/2016-March/089759.html
Thanks for pointing this out.
I almost forgot about this patch, which Durga/Siva added.
Will sync up on this patch first, and if a rebase is the only thing
required, we can proceed on this one.
} __packed;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Shrink i915_gem_request_add_to_client
From: Tvrtko Ursulin
We do not need to check twice for the same conditions.
Results in clearer code and smaller binary.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8588c83abb35..f7051df781d2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1372,12 +1372,7 @@ int i915_gem_request_add_to_client(struct
drm_i915_gem_request *req,
{
struct drm_i915_file_private *file_priv;
- WARN_ON(!req || !file || req->file_priv);
-
- if (!req || !file)
- return -EINVAL;
-
- if (req->file_priv)
+ if (WARN_ON(!req || !file || req->file_priv))
return -EINVAL;
file_priv = file->driver_priv;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Cache elsp submit register
From: Tvrtko Ursulin
Since we write four times to the same register, caching
the mmio register saves a tiny amount of generated code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e733795b57e0..6916991bdceb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -362,6 +362,7 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
struct intel_engine_cs *engine = rq0->engine;
struct drm_i915_private *dev_priv = rq0->i915;
+ i915_reg_t elsp_reg = RING_ELSP(engine);
uint64_t desc[2];
if (rq1) {
@@ -375,12 +376,12 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
rq0->elsp_submitted++;
/* You must always write both descriptors in the order below. */
- I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[1]));
- I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[1]));
+ I915_WRITE_FW(elsp_reg, upper_32_bits(desc[1]));
+ I915_WRITE_FW(elsp_reg, lower_32_bits(desc[1]));
- I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[0]));
+ I915_WRITE_FW(elsp_reg, upper_32_bits(desc[0]));
/* The context is automatically loaded after the following */
- I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[0]));
+ I915_WRITE_FW(elsp_reg, lower_32_bits(desc[0]));
/* ELSP is a wo register, use another nearby reg for posting */
POSTING_READ_FW(RING_EXECLIST_STATUS_LO(engine));
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: add lspcon vbt bit parsing
On Tue, Mar 22, 2016 at 10:20:33PM +0530, Sharma, Shashank wrote:
> Thanks for the review, Jani.
>
> Regards
> Shashank
>
> On 3/22/2016 9:24 PM, Jani Nikula wrote:
> > On Tue, 22 Mar 2016, Shashank Sharma wrote:
> >> LSPCON can be configured on a port using VBT entry.
> >> This patch adds code to parse VBT and detect presence of
> >> LSPCON for a ddi port.
> >>
> >> Signed-off-by: Akashdeep Sharma
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.h | 1 +
> >> drivers/gpu/drm/i915/intel_bios.c | 42
> >> +++
> >> drivers/gpu/drm/i915/intel_vbt_defs.h | 1 +
> >> 3 files changed, 44 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index f330a53..cbd40de 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -3373,6 +3373,7 @@ bool intel_bios_is_tv_present(struct
> >> drm_i915_private *dev_priv);
> >> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> >> *i2c_pin);
> >> bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> >> port);
> >> bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum
> >> port *port);
> >> +bool intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port);
> >>
> >> /* intel_opregion.c */
> >> #ifdef CONFIG_ACPI
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> >> b/drivers/gpu/drm/i915/intel_bios.c
> >> index 083003b..a04ab5c 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/intel_bios.c
> >> @@ -1588,3 +1588,45 @@ bool intel_bios_is_dsi_present(struct
> >> drm_i915_private *dev_priv,
> >>
> >>return false;
> >> }
> >> +
> >
> > Please add kernel-doc comment like all the other intel_bios_is_*
> > functions have.
> >
> Ok,
> >> +bool
> >> +intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port)
> >
> > You mean is *present*?
> >
> Well, this is embarrassing :) yes it was supposed to be present.
> > Please pass struct drm_i915_private *dev_priv instead of dev.
> >
> Ok
> >> +{
> >> + unsigned char i;
> >> + enum port dvo_port = 0;
> >> + struct drm_i915_private *dev_priv = dev->dev_private;
> >> +
> >> + /* LSPCON is supported only for GEN 9 */
> >> + if (!IS_GEN9(dev))
> >> + return false;
> >> +
> >> + /* Check if lspcon is supported in VBT */
> >> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> >> + if (!dev_priv->vbt.child_dev[i].common.lspcon)
> >
> > I think to be defensive we should also check for bdb version >=
> > 192. That we could check before the loop along with the gen check.
> >
> Yes, this can be done.
> >> + continue;
> >> +
> >> + switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
> >> + case DVO_PORT_DPB:
> >> + dvo_port = PORT_B;
> >> + break;
> >> +
> >> + case DVO_PORT_DPC:
> >> + dvo_port = PORT_C;
> >> + break;
> >> +
> >> + case DVO_PORT_DPD:
> >> + dvo_port = PORT_D;
> >> + break;
> >> +
> >> + default:
> >> + continue;
> >> + }
> >> +
> >> + if (dvo_port == port) {
> >> + DRM_DEBUG_DRIVER("LSPCON configured on port %c\n",
> >> + port_name(port));
> >> + return true;
> >> + }
> >> + }
> >> + return false;
> >> +}
> >> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> >> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> >> index 749dcea..0066b24 100644
> >> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> >> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> >> @@ -276,6 +276,7 @@ struct common_child_dev_config {
> >>u8 flags_1;
> >>u8 not_common3[13];
> >>u8 iboost_level;
> >> + u8 lspcon:1;
> >
> > Huh? AFAICT from the spec, lspcon is bit 2 in flags_1. You could define
> > flags_1 in terms of bitfields, including IBOOST_ENABLE.
> >
> I am not sure about this, let me go to VBT spec again, if there is a
> recent change. Will update you on this.
There was a patch [1] posted recently which added the lspcon bit and others,
and that at least matches the spec at the time when I looked at it (or I
made a mistake). The patch just needs a rebase and it should be good to
go I think, though someone else double checking wouldn't hurt.
[1] https://lists.freedesktop.org/archives/intel-gfx/2016-March/089759.html
> >> } __packed;
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Add lspcon support
== Series Details == Series: Add lspcon support URL : https://patchwork.freedesktop.org/series/4756/ State : warning == Summary == Series 4756v1 Add lspcon support http://patchwork.freedesktop.org/api/1.0/series/4756/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-load-detect: pass -> SKIP (snb-x220t) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) dmesg-warn -> PASS (byt-nuc) Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:157 dwarn:0 dfail:0 fail:1 skip:34 Results at /archive/results/CI_IGT_test/Patchwork_1678/ 83ed25fa1b956275542da63eb98dc8fd2291329d drm-intel-nightly: 2016y-03m-22d-15h-20m-55s UTC integration manifest 64d449abc86294f211a783404fb465e9f0bff70a drm/i915: Add lspcon hpd handler fdb8600c1166c8470954b518290cd35e08b02ae4 drm/i915: Add lspcon core functions 84fa946647056c440ab3197af2ad4c0a23e4c8c7 drm/i915: Add and register lspcon connector functions 507927d0999eb123b75abf62e302d53c63bf7e52 drm/i915: Add and initialize lspcon connector db55bf34f70937801eddd1279de9500f95477035 drm/i915: Add new lspcon file dab4018dab24476b7b50d131af2eaf4a7fe51fc3 drm/i915: Add lspcon data structures 2f098d39591a36161629e7cc8359bc88c1cbe033 drm/i915: add lspcon vbt bit parsing ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: add lspcon vbt bit parsing
Thanks for the review, Jani.
Regards
Shashank
On 3/22/2016 9:24 PM, Jani Nikula wrote:
On Tue, 22 Mar 2016, Shashank Sharma wrote:
LSPCON can be configured on a port using VBT entry.
This patch adds code to parse VBT and detect presence of
LSPCON for a ddi port.
Signed-off-by: Akashdeep Sharma
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 42 +++
drivers/gpu/drm/i915/intel_vbt_defs.h | 1 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f330a53..cbd40de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3373,6 +3373,7 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
port);
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
+bool intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..a04ab5c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1588,3 +1588,45 @@ bool intel_bios_is_dsi_present(struct drm_i915_private
*dev_priv,
return false;
}
+
Please add kernel-doc comment like all the other intel_bios_is_*
functions have.
Ok,
+bool
+intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port)
You mean is *present*?
Well, this is embarrassing :) yes it was supposed to be present.
Please pass struct drm_i915_private *dev_priv instead of dev.
Ok
+{
+ unsigned char i;
+ enum port dvo_port = 0;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /* LSPCON is supported only for GEN 9 */
+ if (!IS_GEN9(dev))
+ return false;
+
+ /* Check if lspcon is supported in VBT */
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ if (!dev_priv->vbt.child_dev[i].common.lspcon)
I think to be defensive we should also check for bdb version >=
192. That we could check before the loop along with the gen check.
Yes, this can be done.
+ continue;
+
+ switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+ case DVO_PORT_DPB:
+ dvo_port = PORT_B;
+ break;
+
+ case DVO_PORT_DPC:
+ dvo_port = PORT_C;
+ break;
+
+ case DVO_PORT_DPD:
+ dvo_port = PORT_D;
+ break;
+
+ default:
+ continue;
+ }
+
+ if (dvo_port == port) {
+ DRM_DEBUG_DRIVER("LSPCON configured on port %c\n",
+ port_name(port));
+ return true;
+ }
+ }
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..0066b24 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -276,6 +276,7 @@ struct common_child_dev_config {
u8 flags_1;
u8 not_common3[13];
u8 iboost_level;
+ u8 lspcon:1;
Huh? AFAICT from the spec, lspcon is bit 2 in flags_1. You could define
flags_1 in terms of bitfields, including IBOOST_ENABLE.
I am not sure about this, let me go to VBT spec again, if there is a
recent change. Will update you on this.
} __packed;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] Add lspcon support
Thanks Ville. I will have a look at the series you posted, and if that's the case, will try to merge this implementation on top of yours. Regards Shashank On 3/22/2016 9:50 PM, Ville Syrjälä wrote: On Tue, Mar 22, 2016 at 07:55:01PM +0530, Shashank Sharma wrote: LSPCON is essentially an active DP-HDMI convertor. It has two modes of operations: - ls mode (for upto HDMI 1.4 outputs, 4k@30 resoution / 297MHz) - pcon mode (for upto HDMI 2.0 outputs, 4k@60 resolution / 600 MHz) This patch set adds support for LS mode of operation for GEN9 platforms. It adds a new connector for lspcon, whcih is a mix and match of DP and HDMI connectors, matching dual personality of lspcon devices. Notes: - Daniel Vetter gave a review comment on LSPCON design, to make it a separate encoder. This patch set tries to match that expectations with a separate connector, as DDI encoder already fulfills all the requirements of a lspcon_encoder. - This patch set tagrets LS mode of operations only. - PCON mode of operation will be added later, based on the requirements. This is to primarily unbloc Linux devices with LSPCON port. - This patch set is tested with BXT RVP + drm-nightly - As we redesigned this code, to meet the review comments, this is a working patch set, but not upto commercial quality yet. Quick glance tells me this is more or less just an in driver implementation of the DP dual mode standard at this point. I recently posted some patches [1] that implement dual mode support as a helper. So you should check it out and try to layer whatever lspcon specifics on top of that. The only thing missing from my patches was basically using i2c-over-aux instead of gmbus for type2 adapters, but that's mostly just a matter of passing the right i2c adapter to places. [1] https://lists.freedesktop.org/archives/dri-devel/2016-February/101494.html Shashank Sharma (7): drm/i915: add lspcon vbt bit parsing drm/i915: Add lspcon data structures drm/i915: Add new lspcon file drm/i915: Add and initialize lspcon connector drm/i915: Add and register lspcon connector functions drm/i915: Add lspcon core functions drm/i915: Add lspcon hpd handler drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_bios.c | 42 +++ drivers/gpu/drm/i915/intel_ddi.c | 6 + drivers/gpu/drm/i915/intel_dp.c | 31 ++ drivers/gpu/drm/i915/intel_drv.h | 35 +- drivers/gpu/drm/i915/intel_hdmi.c | 25 +- drivers/gpu/drm/i915/intel_hotplug.c | 2 +- drivers/gpu/drm/i915/intel_lspcon.c | 620 ++ drivers/gpu/drm/i915/intel_vbt_defs.h | 1 + 10 files changed, 759 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices
On Tue, Mar 15, 2016 at 04:47:46PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 15, 2016 at 06:43:53PM +0530, Shubhangi Shrivastava wrote:
> > This patch adds new fields that are not yet added in drm code
> > in child devices struct
> >
> > Signed-off-by: Sivakumar Thulasimani
> > Signed-off-by: Durgadoss R
> > Signed-off-by: Shubhangi Shrivastava
> > ---
> > drivers/gpu/drm/i915/intel_bios.c | 15 ++-
> > drivers/gpu/drm/i915/intel_bios.h | 16 +++-
> > 2 files changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index bf62a19..a26d4b4 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1124,7 +1124,7 @@ static void parse_ddi_port(struct drm_i915_private
> > *dev_priv, enum port port,
> > }
> >
> > /* Parse the I_boost config for SKL and above */
> > - if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
> > + if (bdb->version >= 196 && child->common.iboost) {
> > info->dp_boost_level =
> > translate_iboost(child->common.iboost_level & 0xF);
> > DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
> > port_name(port), info->dp_boost_level);
> > @@ -1250,6 +1250,19 @@ parse_device_mapping(struct drm_i915_private
> > *dev_priv,
> > */
> > memcpy(child_dev_ptr, p_child,
> >min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
> > +
> > + /*
> > +* copied full block, now init values when they are not
> > +* available in current version
> > +*/
> > + if (bdb->version < 196) {
> > + /* Set default values for bits added from v196 */
> > + child_dev_ptr->common.iboost = 0;
> > + child_dev_ptr->common.hpd_invert = 0;
> > + }
> > +
> > + if (bdb->version < 192)
> > + child_dev_ptr->common.lspcon = 0;
> > }
> > return;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > b/drivers/gpu/drm/i915/intel_bios.h
> > index 350d4e0..2898323 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.h
> > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > @@ -250,9 +250,6 @@ struct old_child_dev_config {
> > * versions. Notice that the meaning of the contents contents may still
> > change,
> > * but at least the offsets are consistent. */
> >
> > -/* Definitions for flags_1 */
> > -#define IBOOST_ENABLE (1<<3)
> > -
> > struct common_child_dev_config {
> > u16 handle;
> > u16 device_type;
> > @@ -261,8 +258,17 @@ struct common_child_dev_config {
> > u8 not_common2[2];
> > u8 ddc_pin;
> > u16 edid_ptr;
> > - u8 obsolete;
> > - u8 flags_1;
> > + u8 dvo_cfg; /* See DEVICE_CFG_* above */
> > + u8 efp_routed:1;
> > + u8 lane_reversal:1;
> > + u8 lspcon:1;
> > + u8 iboost:1;
> > + u8 hpd_invert:1;
> > + u8 flag_reserved:3;
> > + u8 hdmi_support:1;
> > + u8 dp_support:1;
> > + u8 tmds_support:1;
> > + u8 support_reserved:5;
>
> I think we should probably annotate each of these with a version
> comment. Otherwise you always have to dig up the spec to see which
> version added which field.
>
> Anyways these look to match the spec, so
> Reviewed-by: Ville Syrjälä
I tried to apply this, but the code changed underneath so it won't
actually apply. Can you pls rebase and resend?
>
> > u8 not_common3[13];
> > u8 iboost_level;
> > } __packed;
> > --
> > 2.6.1
>
> --
> Ville Syrjälä
> Intel OTC
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] scripts/run-test.sh: Piglit overwrite option.
Quoting Vivi, Rodrigo (2016-03-21 19:00:10) > On Mon, 2016-03-21 at 12:53 +0200, Marius Vlad wrote: > > Isn't this as https://patchwork.freedesktop.org/series/4177/? > > > > On Fri, Mar 18, 2016 at 07:02:11AM -0700, Rodrigo Vivi wrote: > > > The following piglit commit adds one option to overwrite files: > > > > > > commit ec317ece07afdf9c8a26de04bdec8a94e5d7b2db > > > Author: Dylan Baker > > > Date: Mon Feb 1 15:08:23 2016 -0800 > > > > > > framework/programs/run.py: Add option for overwriting files > > > > > > So our run-script.sh test that creates the directory before > > > executing > > > the tests were failing with: > > > > > > "Fatal Error: Cannot overwrite existing folder w/o the -o /- > > > -overwrite option being sent" > > > > > > I believe it took a while to notice that because many of us never > > > upgrade the piglit. But also the risk with this patch is to have an > > > environment > > > with the old piglit so the result will be: > > > piglit: error: unrecognized arguments: --overwrite > > > > Maybe we can test against piglit version and use it accordingly. > > Yeah, I wondered that... but apparently piglit doesn't return the > version... > The ugly way that came to my mind was something like: > > $PIGLIT run --help | grep overwrite > /dev/null > if [ $? -eq 0 ]; then > # use overwwrite > else > # keep the old > fi > > any non-ugly idea? > I was just thinking that it was stupid that piglit doesn't have a version of any kind. I'm planning to add one although it will only be a git sha and maybe a date since piglit intentionally doesn't have major or minor version numbers. Dylan signature.asc Description: signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Wait until after wm optimization to drop runtime PM reference
On Tue, 22 Mar 2016, Imre Deak wrote: > [ text/plain ] > On ti, 2016-03-22 at 08:56 -0700, Matt Roper wrote: >> On Tue, Mar 22, 2016 at 04:17:58PM +0200, Imre Deak wrote: >> > On ti, 2016-03-22 at 15:51 +0200, Jani Nikula wrote: >> > > On Tue, 22 Mar 2016, Imre Deak wrote: >> > > > [ text/plain ] >> > > > On ti, 2016-03-08 at 09:26 -0800, Matt Roper wrote: >> > > > > On Mon, Mar 07, 2016 at 11:47:51AM +, Patchwork wrote: >> > > > > > == Series Details == >> > > > > > >> > > > > > Series: drm/i915: Wait until after wm optimization to drop >> > > > > > runtime >> > > > > > PM reference >> > > > > > URL : https://patchwork.freedesktop.org/series/4135/ >> > > > > > State : failure >> > > > > > >> > > > > > == Summary == >> > > > > > >> > > > > > Series 4135v1 drm/i915: Wait until after wm optimization to >> > > > > > drop >> > > > > > runtime PM reference >> > > > > > http://patchwork.freedesktop.org/api/1.0/series/4135/revisi >> > > > > > ons/ >> > > > > > 1/mb >> > > > > > ox/ >> > > > > > >> > > > > > Test kms_flip: >> > > > > > Subgroup basic-flip-vs-wf_vblank: >> > > > > > fail -> PASS (bsw-nuc-2) >> > > > > > Subgroup basic-plain-flip: >> > > > > > dmesg-warn -> PASS (hsw-gt2) >> > > > > > Test kms_force_connector_basic: >> > > > > > Subgroup force-load-detect: >> > > > > > pass -> SKIP (ivb-t430s) >> > > > > >> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93769 >> > > > > >> > > > > > Test kms_pipe_crc_basic: >> > > > > > Subgroup read-crc-pipe-c: >> > > > > > dmesg-warn -> PASS (hsw-gt2) >> > > > > > Subgroup suspend-read-crc-pipe-a: >> > > > > > dmesg-warn -> PASS (skl-i5k-2) >> > > > > > skip -> PASS (hsw-brixbox) >> > > > > > Subgroup suspend-read-crc-pipe-c: >> > > > > > pass -> DMESG-WARN (bsw-nuc-2) >> > > > > >> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93294 >> > > > > >> > > > > > pass -> INCOMPLETE (hsw-gt2) >> > > > > >> > > > > Seems like the machine just died completely? No >> > > > > stdout/stderr/command/dmesg output available from CI and time >> > > > > is >> > > > > given >> > > > > as 0:00:00. Doesn't seem like it could be related to this >> > > > > patch. >> > > > > >> > > > > >> > > > > > Test pm_rpm: >> > > > > > Subgroup basic-pci-d3-state: >> > > > > > dmesg-warn -> PASS (snb-dellxps) >> > > > > > Subgroup basic-rte: >> > > > > > pass -> DMESG-WARN (bsw-nuc-2) >> > > > > >> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=94164 >> > > > > >> > > > > >> > > > > Matt >> > > > >> > > > Pushed to -dinq, thanks for the patch and the review. >> > > > >> > > > I had to rebase it on top of Ville's recent >> > > > s/crtc_state/old_crtc_state/ change, please double check it. >> > > > >> > > > Jani, this is for -fixes. >> > > >> > > Surely you added either >> > > >> > > Cc: drm-intel-fi...@lists.freedesktop.org >> > > >> > > or >> > > >> > > Cc: sta...@vger.kernel.org >> > > >> > > in the commit when you pushed, then? >> > >> > No, I haven't will do that in the future. Btw, what's the rule for >> > deciding that something is for -fixes or stable only after it's >> > been >> > pushed? Just ping you in case for -fixes and resend it in case of >> > stable? >> > >> > --Imre >> >> Are you sure we need this for -fixes? The patch that introduced the >> regression isn't in drm-next/4.6 as far as I know. > > The regressing commit ed4a6a7ca853 is in drm-intel-next, so I think we > do need it for -fixes. Ah. It's not in 4.5 and it's not on its way to 4.6. Not fixes material. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: fix lut value extraction function
== Series Details == Series: drm: fix lut value extraction function URL : https://patchwork.freedesktop.org/series/4753/ State : warning == Summary == Series 4753v1 drm: fix lut value extraction function http://patchwork.freedesktop.org/api/1.0/series/4753/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1677/ 83ed25fa1b956275542da63eb98dc8fd2291329d drm-intel-nightly: 2016y-03m-22d-15h-20m-55s UTC integration manifest 6b24ccdc61e6e5e6326582acfe1e58d3212f8b4b drm: fix lut value extraction function ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Wait until after wm optimization to drop runtime PM reference
On ti, 2016-03-22 at 08:56 -0700, Matt Roper wrote: > On Tue, Mar 22, 2016 at 04:17:58PM +0200, Imre Deak wrote: > > On ti, 2016-03-22 at 15:51 +0200, Jani Nikula wrote: > > > On Tue, 22 Mar 2016, Imre Deak wrote: > > > > [ text/plain ] > > > > On ti, 2016-03-08 at 09:26 -0800, Matt Roper wrote: > > > > > On Mon, Mar 07, 2016 at 11:47:51AM +, Patchwork wrote: > > > > > > == Series Details == > > > > > > > > > > > > Series: drm/i915: Wait until after wm optimization to drop > > > > > > runtime > > > > > > PM reference > > > > > > URL : https://patchwork.freedesktop.org/series/4135/ > > > > > > State : failure > > > > > > > > > > > > == Summary == > > > > > > > > > > > > Series 4135v1 drm/i915: Wait until after wm optimization to > > > > > > drop > > > > > > runtime PM reference > > > > > > http://patchwork.freedesktop.org/api/1.0/series/4135/revisi > > > > > > ons/ > > > > > > 1/mb > > > > > > ox/ > > > > > > > > > > > > Test kms_flip: > > > > > > Subgroup basic-flip-vs-wf_vblank: > > > > > > fail -> PASS (bsw-nuc-2) > > > > > > Subgroup basic-plain-flip: > > > > > > dmesg-warn -> PASS (hsw-gt2) > > > > > > Test kms_force_connector_basic: > > > > > > Subgroup force-load-detect: > > > > > > pass -> SKIP (ivb-t430s) > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93769 > > > > > > > > > > > Test kms_pipe_crc_basic: > > > > > > Subgroup read-crc-pipe-c: > > > > > > dmesg-warn -> PASS (hsw-gt2) > > > > > > Subgroup suspend-read-crc-pipe-a: > > > > > > dmesg-warn -> PASS (skl-i5k-2) > > > > > > skip -> PASS (hsw-brixbox) > > > > > > Subgroup suspend-read-crc-pipe-c: > > > > > > pass -> DMESG-WARN (bsw-nuc-2) > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93294 > > > > > > > > > > > pass -> INCOMPLETE (hsw-gt2) > > > > > > > > > > Seems like the machine just died completely? No > > > > > stdout/stderr/command/dmesg output available from CI and time > > > > > is > > > > > given > > > > > as 0:00:00. Doesn't seem like it could be related to this > > > > > patch. > > > > > > > > > > > > > > > > Test pm_rpm: > > > > > > Subgroup basic-pci-d3-state: > > > > > > dmesg-warn -> PASS (snb-dellxps) > > > > > > Subgroup basic-rte: > > > > > > pass -> DMESG-WARN (bsw-nuc-2) > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=94164 > > > > > > > > > > > > > > > Matt > > > > > > > > Pushed to -dinq, thanks for the patch and the review. > > > > > > > > I had to rebase it on top of Ville's recent > > > > s/crtc_state/old_crtc_state/ change, please double check it. > > > > > > > > Jani, this is for -fixes. > > > > > > Surely you added either > > > > > > Cc: drm-intel-fi...@lists.freedesktop.org > > > > > > or > > > > > > Cc: sta...@vger.kernel.org > > > > > > in the commit when you pushed, then? > > > > No, I haven't will do that in the future. Btw, what's the rule for > > deciding that something is for -fixes or stable only after it's > > been > > pushed? Just ping you in case for -fixes and resend it in case of > > stable? > > > > --Imre > > Are you sure we need this for -fixes? The patch that introduced the > regression isn't in drm-next/4.6 as far as I know. The regressing commit ed4a6a7ca853 is in drm-intel-next, so I think we do need it for -fixes. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] Add lspcon support
On Tue, Mar 22, 2016 at 07:55:01PM +0530, Shashank Sharma wrote: > LSPCON is essentially an active DP-HDMI convertor. It has > two modes of operations: > - ls mode (for upto HDMI 1.4 outputs, 4k@30 resoution / 297MHz) > - pcon mode (for upto HDMI 2.0 outputs, 4k@60 resolution / 600 MHz) > > This patch set adds support for LS mode of operation for GEN9 > platforms. It adds a new connector for lspcon, whcih is a mix > and match of DP and HDMI connectors, matching dual personality > of lspcon devices. > > Notes: > - Daniel Vetter gave a review comment on LSPCON design, to make > it a separate encoder. This patch set tries to match that expectations > with a separate connector, as DDI encoder already fulfills all the > requirements of a lspcon_encoder. > - This patch set tagrets LS mode of operations only. > - PCON mode of operation will be added later, based on the requirements. > This is to primarily unbloc Linux devices with LSPCON port. > - This patch set is tested with BXT RVP + drm-nightly > - As we redesigned this code, to meet the review comments, this is a working > patch set, but not upto commercial quality yet. Quick glance tells me this is more or less just an in driver implementation of the DP dual mode standard at this point. I recently posted some patches [1] that implement dual mode support as a helper. So you should check it out and try to layer whatever lspcon specifics on top of that. The only thing missing from my patches was basically using i2c-over-aux instead of gmbus for type2 adapters, but that's mostly just a matter of passing the right i2c adapter to places. [1] https://lists.freedesktop.org/archives/dri-devel/2016-February/101494.html > > Shashank Sharma (7): > drm/i915: add lspcon vbt bit parsing > drm/i915: Add lspcon data structures > drm/i915: Add new lspcon file > drm/i915: Add and initialize lspcon connector > drm/i915: Add and register lspcon connector functions > drm/i915: Add lspcon core functions > drm/i915: Add lspcon hpd handler > > drivers/gpu/drm/i915/Makefile | 3 +- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/intel_bios.c | 42 +++ > drivers/gpu/drm/i915/intel_ddi.c | 6 + > drivers/gpu/drm/i915/intel_dp.c | 31 ++ > drivers/gpu/drm/i915/intel_drv.h | 35 +- > drivers/gpu/drm/i915/intel_hdmi.c | 25 +- > drivers/gpu/drm/i915/intel_hotplug.c | 2 +- > drivers/gpu/drm/i915/intel_lspcon.c | 620 > ++ > drivers/gpu/drm/i915/intel_vbt_defs.h | 1 + > 10 files changed, 759 insertions(+), 7 deletions(-) > create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Iris pro broadwell power issue
Hello, Our application uses intel HD graphics and media hardware. To date we have been successfully using ivy bridge and haswell processors. Recently we have been evaluating iris pro broadwell in the form of E3-1265Lv4 and to our surprise have found that it seems to use much more energy (~5-10x) for the same amount of work done compared to other devices, e.g. ivy bridge i7 or non-iris pro broadwell. We see the same in various test cases e.g. a simple EU shader that copies rectangular video, the H264 HW decode, or surface scaling (through vaapi). Here is a graph showing power usage for H264 video decode, i.e. we are comparing the power usage of the two devices vs workload: http://picpaste.com/pics/decoder_power-xpY94kKI.1458660426.jpg Increased power is seen for the PP1/GPU domain only (read with MSRs, confirmed with turbostat). No issue with CPU workloads. We are using the same code with Ubuntu 15.10 in all cases. Our current assumption is that there must be some configuration issue with the iris pro broadwell xeon as it's very hard to conceive that adding the L4 cache should suddenly 10x the power... Wondering if anyone has any ideas of what could be causing this (badly set MSRs/GPU regs, or L4 cache config, maybe?) Cheers, Joe ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Wait until after wm optimization to drop runtime PM reference
On Tue, Mar 22, 2016 at 04:17:58PM +0200, Imre Deak wrote: > On ti, 2016-03-22 at 15:51 +0200, Jani Nikula wrote: > > On Tue, 22 Mar 2016, Imre Deak wrote: > > > [ text/plain ] > > > On ti, 2016-03-08 at 09:26 -0800, Matt Roper wrote: > > > > On Mon, Mar 07, 2016 at 11:47:51AM +, Patchwork wrote: > > > > > == Series Details == > > > > > > > > > > Series: drm/i915: Wait until after wm optimization to drop > > > > > runtime > > > > > PM reference > > > > > URL : https://patchwork.freedesktop.org/series/4135/ > > > > > State : failure > > > > > > > > > > == Summary == > > > > > > > > > > Series 4135v1 drm/i915: Wait until after wm optimization to > > > > > drop > > > > > runtime PM reference > > > > > http://patchwork.freedesktop.org/api/1.0/series/4135/revisions/ > > > > > 1/mb > > > > > ox/ > > > > > > > > > > Test kms_flip: > > > > > Subgroup basic-flip-vs-wf_vblank: > > > > > fail -> PASS (bsw-nuc-2) > > > > > Subgroup basic-plain-flip: > > > > > dmesg-warn -> PASS (hsw-gt2) > > > > > Test kms_force_connector_basic: > > > > > Subgroup force-load-detect: > > > > > pass -> SKIP (ivb-t430s) > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93769 > > > > > > > > > Test kms_pipe_crc_basic: > > > > > Subgroup read-crc-pipe-c: > > > > > dmesg-warn -> PASS (hsw-gt2) > > > > > Subgroup suspend-read-crc-pipe-a: > > > > > dmesg-warn -> PASS (skl-i5k-2) > > > > > skip -> PASS (hsw-brixbox) > > > > > Subgroup suspend-read-crc-pipe-c: > > > > > pass -> DMESG-WARN (bsw-nuc-2) > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93294 > > > > > > > > > pass -> INCOMPLETE (hsw-gt2) > > > > > > > > Seems like the machine just died completely? No > > > > stdout/stderr/command/dmesg output available from CI and time is > > > > given > > > > as 0:00:00. Doesn't seem like it could be related to this patch. > > > > > > > > > > > > > Test pm_rpm: > > > > > Subgroup basic-pci-d3-state: > > > > > dmesg-warn -> PASS (snb-dellxps) > > > > > Subgroup basic-rte: > > > > > pass -> DMESG-WARN (bsw-nuc-2) > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=94164 > > > > > > > > > > > > Matt > > > > > > Pushed to -dinq, thanks for the patch and the review. > > > > > > I had to rebase it on top of Ville's recent > > > s/crtc_state/old_crtc_state/ change, please double check it. > > > > > > Jani, this is for -fixes. > > > > Surely you added either > > > > Cc: drm-intel-fi...@lists.freedesktop.org > > > > or > > > > Cc: sta...@vger.kernel.org > > > > in the commit when you pushed, then? > > No, I haven't will do that in the future. Btw, what's the rule for > deciding that something is for -fixes or stable only after it's been > pushed? Just ping you in case for -fixes and resend it in case of > stable? > > --Imre Are you sure we need this for -fixes? The patch that introduced the regression isn't in drm-next/4.6 as far as I know. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: add lspcon vbt bit parsing
On Tue, 22 Mar 2016, Shashank Sharma wrote:
> LSPCON can be configured on a port using VBT entry.
> This patch adds code to parse VBT and detect presence of
> LSPCON for a ddi port.
>
> Signed-off-by: Akashdeep Sharma
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 42
> +++
> drivers/gpu/drm/i915/intel_vbt_defs.h | 1 +
> 3 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f330a53..cbd40de 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3373,6 +3373,7 @@ bool intel_bios_is_tv_present(struct drm_i915_private
> *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
> bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
> *port);
> +bool intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 083003b..a04ab5c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1588,3 +1588,45 @@ bool intel_bios_is_dsi_present(struct drm_i915_private
> *dev_priv,
>
> return false;
> }
> +
Please add kernel-doc comment like all the other intel_bios_is_*
functions have.
> +bool
> +intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port)
You mean is *present*?
Please pass struct drm_i915_private *dev_priv instead of dev.
> +{
> + unsigned char i;
> + enum port dvo_port = 0;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + /* LSPCON is supported only for GEN 9 */
> + if (!IS_GEN9(dev))
> + return false;
> +
> + /* Check if lspcon is supported in VBT */
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + if (!dev_priv->vbt.child_dev[i].common.lspcon)
I think to be defensive we should also check for bdb version >=
192. That we could check before the loop along with the gen check.
> + continue;
> +
> + switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
> + case DVO_PORT_DPB:
> + dvo_port = PORT_B;
> + break;
> +
> + case DVO_PORT_DPC:
> + dvo_port = PORT_C;
> + break;
> +
> + case DVO_PORT_DPD:
> + dvo_port = PORT_D;
> + break;
> +
> + default:
> + continue;
> + }
> +
> + if (dvo_port == port) {
> + DRM_DEBUG_DRIVER("LSPCON configured on port %c\n",
> + port_name(port));
> + return true;
> + }
> + }
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 749dcea..0066b24 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -276,6 +276,7 @@ struct common_child_dev_config {
> u8 flags_1;
> u8 not_common3[13];
> u8 iboost_level;
> + u8 lspcon:1;
Huh? AFAICT from the spec, lspcon is bit 2 in flags_1. You could define
flags_1 in terms of bitfields, including IBOOST_ENABLE.
> } __packed;
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Increase context alignment requirement for Sandybridge
== Series Details == Series: drm/i915: Increase context alignment requirement for Sandybridge URL : https://patchwork.freedesktop.org/series/4752/ State : failure == Summary == Series 4752v1 drm/i915: Increase context alignment requirement for Sandybridge http://patchwork.freedesktop.org/api/1.0/series/4752/revisions/1/mbox/ Test drv_module_reload_basic: pass -> INCOMPLETE (ilk-hp8440p) Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (bsw-nuc-2) bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:153 dwarn:2 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:65 pass:45 dwarn:0 dfail:0 fail:0 skip:19 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1676/ 94c7a2ce8a4f659840625a318b1d3d8832f4ca46 drm-intel-nightly: 2016y-03m-22d-12h-51m-12s UTC integration manifest d6a9942faa9647c387860fe3f17cda92d2579a10 drm/i915: Increase context alignment requirement for Sandybridge ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 6/7] drm/i915: refactor duplicate object vmap functions (the final rework?)
On 08/03/16 09:43, Tvrtko Ursulin wrote:
On 02/03/16 15:40, Dave Gordon wrote:
On 02/03/16 12:08, Chris Wilson wrote:
On Tue, Mar 01, 2016 at 04:33:58PM +, Dave Gordon wrote:
This is essentially Chris Wilson's patch of a similar name, reworked on
top of Alex Dai's recent patch:
| drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
Chris' original commentary said:
| We now have two implementations for vmapping a whole object, one for
| dma-buf and one for the ringbuffer. If we couple the vmapping into
| the obj->pages lifetime, then we can reuse an obj->vmapping for both
| and at the same time couple it into the shrinker.
|
| v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala)
| v3: Call unpin_vmap from the right dmabuf unmapper
v4: reimplements the same functionality, but now as wrappers round the
recently-introduced i915_gem_object_vmap_range() from Alex's patch
mentioned above.
v5: separated from two minor but unrelated changes [Tvrtko Ursulin];
this is the third and most substantial portion.
Decided not to hold onto vmappings after the pin count goes to
zero.
This may reduce the benefit of Chris' scheme a bit, but does avoid
any increased risk of exhausting kernel vmap space on 32-bit
kernels
[Tvrtko Ursulin]. Potentially, the vunmap() could be deferred
until
the put_pages() stage if a suitable notifier were written, but
we're
not doing that here. Nonetheless, the simplification of both
dmabuf
and ringbuffer code makes it worthwhile in its own right.
v6: change BUG_ON() to WARN_ON(). [Tvrtko Ursulin]
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Alex Dai
---
drivers/gpu/drm/i915/i915_drv.h | 22 ++-
drivers/gpu/drm/i915/i915_gem.c | 39
+
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 36
--
drivers/gpu/drm/i915/intel_ringbuffer.c | 9
4 files changed, 65 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index b3ae191..f1ad3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2172,10 +2172,7 @@ struct drm_i915_gem_object {
struct scatterlist *sg;
int last;
} get_page;
-
-/* prime dma-buf support */
-void *dma_buf_vmapping;
-int vmapping_count;
+void *vmapping;
/** Breadcrumb of last rendering to the buffer.
* There can only be one writer, but we allow for multiple
readers.
@@ -2980,7 +2977,22 @@ static inline void
i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
static inline void i915_gem_object_unpin_pages(struct
drm_i915_gem_object *obj)
{
BUG_ON(obj->pages_pin_count == 0);
-obj->pages_pin_count--;
+if (--obj->pages_pin_count == 0 && obj->vmapping) {
+/*
+ * Releasing the vmapping here may yield less benefit than
+ * if we kept it until put_pages(), but on the other hand
Yields no benefit. Makes the patch pointless.
Plus there is also pressure to enable WC vmaps.
-Chris
The patch is not pointless -- at the very least, it:
+ reduces the size of "struct drm_i915_gem_object" (OK, only by 4 bytes)
+ replaces special-function code for dmabufs with more generic code that
can be reused for other objects (for now, ringbuffers; next GuC-shared
objects -- see Alex's patch "drm/i915/guc: Simplify code by keeping vmap
of guc_client object" which will eliminate lot of short-term
kmap_atomics with persistent kmaps).
+ provides a shorthand for the sequence of { get_pages(), pin_pages(),
vmap() } so we don't have to open-code it (and deal with all the error
paths) in several different places
Thus there is an engineering benefit even if this version doesn't
provide any performance benefit. And if, as the next step, you want to
extend the vmap lifetime, you just have to remove those few lines in
i915_gem_object_unpin_pages() and incorporate the notifier that you
prototyped earlier -- if it actually provides any performance boost.
So Chris do you ack on this series on the basis of the above - that it
consolidates the current code and following GuC patch will be another
user of the pin_vmap API?
Regards,
Tvrtko
I see that Chris has posted a patch to add a vmap notifier, although it
hasn't yet got its R-B. So I suggest we merge this patch series now, and
then update it by moving the vunmap() into put_pages() when Chris has
the notifier finalised. IIRC you wanted Daniel to merge the new DRM bits
(patches 3 and 7, which already have their R-Bs) ?
Or we can merge 1-5+7, all of which already have R-Bs, and I can turn
6 into a GuC-private version, without the benefit of simplifying and
unifying the corresponding object-mapping management in the DMAbuf and
ringbuffer code.
Or I can repost just the bits that don't rely on drm_malloc_gfp() and
exclude the final patch so that we can
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Initialize MIPI DSI for BXT (rev2)
On Tue, 22 Mar 2016, Patchwork wrote: > [ text/plain ] > == Series Details == > > Series: drm/i915/bxt: Initialize MIPI DSI for BXT (rev2) > URL : https://patchwork.freedesktop.org/series/3522/ > State : failure > > == Summary == > > Series 3522v2 drm/i915/bxt: Initialize MIPI DSI for BXT > http://patchwork.freedesktop.org/api/1.0/series/3522/revisions/2/mbox/ > > Test kms_flip: > Subgroup basic-flip-vs-dpms: > dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE > Subgroup basic-flip-vs-wf_vblank: > pass -> DMESG-WARN (hsw-brixbox) > Subgroup basic-plain-flip: > dmesg-warn -> PASS (bdw-ultra) > Test kms_pipe_crc_basic: > Subgroup read-crc-pipe-b: > pass -> DMESG-WARN (snb-x220t) > Test pm_rpm: > Subgroup basic-pci-d3-state: > fail -> DMESG-FAIL (snb-x220t) > Subgroup basic-rte: > dmesg-warn -> PASS (snb-x220t) All unrelated, pushed to drm-intel-next-queued with Daniel's IRC ack. BR, Jani. > > bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 > bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 > hsw-brixbox total:192 pass:169 dwarn:1 dfail:0 fail:0 skip:22 > ilk-hp8440p total:192 pass:129 dwarn:0 dfail:0 fail:0 skip:63 > ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 > skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 > skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 > snb-dellxps total:192 pass:157 dwarn:1 dfail:0 fail:0 skip:34 > snb-x220ttotal:192 pass:157 dwarn:1 dfail:1 fail:0 skip:33 > > Results at /archive/results/CI_IGT_test/Patchwork_1672/ > > 4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: > 2016y-03m-21d-18h-43m-18s UTC integration manifest > 370a68ac8bb2e8c1be065f71f3a61ca4a39b468a drm/i915/bxt: Initialize MIPI DSI > for BXT > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/core: Fix ordering in drm_mode_config_cleanup.
Op 22-03-16 om 15:58 schreef Ville Syrjälä: > On Tue, Mar 22, 2016 at 03:42:14PM +0100, Maarten Lankhorst wrote: >> __drm_atomic_helper_plane_destroy_state calls >> drm_framebuffer_unreference, which means that if drm_framebuffer_free >> is called before plane->destroy freed memory will be accessed. >> >> A similar case happens for the blob list, which was freed before the >> crtc state was, resulting in the unreference_blob from crtc_destroy_state >> pointing to garbage memory causing another opportunity for a GPF. >> >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/drm_crtc.c | 18 +- >> 1 file changed, 9 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c >> index 51c5a00ffdff..5a13b1afccbe 100644 >> --- a/drivers/gpu/drm/drm_crtc.c >> +++ b/drivers/gpu/drm/drm_crtc.c >> @@ -5958,6 +5958,15 @@ void drm_mode_config_cleanup(struct drm_device *dev) >> drm_property_destroy(dev, property); >> } > And what about props? Any chance of explosion due to those being gone? > Not as far as I'm aware of. If you use something like a crtc_x property, only the value gets written to crtc_state, the value is an int that would still be valid. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Render decompression support for Gen9 and above
I thought we had concluded previously that this change was acceptable, which is why I'm surprised that it's come up yet again. The performance cost of creating two fb objects per buffer is irrelevant - it will be a one shot hit on buffer creation, and from that point forward it's just selecting which of the two fb's to use at any point in time. Given that I'm told that the memory cost kernel side per fb is small, the number isn't a big deal either. Hence, I'm not sure why you were expecting a performance analysis. The two things I object to are: 1) Having to tell the kernel that there is no aux buffer on an allocation that actually has an aux buffer in order to indicate that at this point in time the buffer is uncompressed. This is completely non intuitive from a caller perspective - especially as it's called an aux buffer, not a compression buffer. 2) Having to use a fb object to manage dynamic state. The fb for a particular buffer will change over the course of a frame. Any debug for a frame at entry to the HWC will have a different fb to the debug at frame exit which makes it hard to track. Thanks Gary -Original Message- From: Daniel Stone [mailto:dan...@fooishbar.org] Sent: Tuesday, March 22, 2016 1:37 PM To: Smith, Gary K Cc: Kannan, Vandana ; intel-gfx ; Daniel Vetter Subject: Re: [PATCH 2/2] drm/i915: Render decompression support for Gen9 and above On 22 March 2016 at 13:30, Daniel Stone wrote: > Exactly the same as the last time we discussed it I should add that I understand your previous objection that creating framebuffers on the fly is not performant enough, and you object to the effort of managing 100 rather than 50 framebuffers upfront (though honestly, if you get to 50 framebuffers you're already having to do some clever setup/management anyway). But in the last thread, Daniel Vetter asked for some performance numbers to bear out your objection that framebuffer creation is too costly, leading to getting it fixed if this is in fact the case (since other userspace relies on it being fast), but this performance analysis never arrived. I'd still be interested in seeing that. Cheers, Daniel - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/core: Fix ordering in drm_mode_config_cleanup.
On Tue, Mar 22, 2016 at 03:42:14PM +0100, Maarten Lankhorst wrote:
> __drm_atomic_helper_plane_destroy_state calls
> drm_framebuffer_unreference, which means that if drm_framebuffer_free
> is called before plane->destroy freed memory will be accessed.
>
> A similar case happens for the blob list, which was freed before the
> crtc state was, resulting in the unreference_blob from crtc_destroy_state
> pointing to garbage memory causing another opportunity for a GPF.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_crtc.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 51c5a00ffdff..5a13b1afccbe 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5958,6 +5958,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> drm_property_destroy(dev, property);
> }
And what about props? Any chance of explosion due to those being gone?
>
> + list_for_each_entry_safe(plane, plt, &dev->mode_config.plane_list,
> + head) {
> + plane->funcs->destroy(plane);
> + }
> +
> + list_for_each_entry_safe(crtc, ct, &dev->mode_config.crtc_list, head) {
> + crtc->funcs->destroy(crtc);
> + }
> +
> list_for_each_entry_safe(blob, bt, &dev->mode_config.property_blob_list,
>head_global) {
> drm_property_unreference_blob(blob);
> @@ -5976,15 +5985,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> drm_framebuffer_free(&fb->refcount);
> }
>
> - list_for_each_entry_safe(plane, plt, &dev->mode_config.plane_list,
> - head) {
> - plane->funcs->destroy(plane);
> - }
> -
> - list_for_each_entry_safe(crtc, ct, &dev->mode_config.crtc_list, head) {
> - crtc->funcs->destroy(crtc);
> - }
> -
> ida_destroy(&dev->mode_config.connector_ida);
> idr_destroy(&dev->mode_config.tile_idr);
> idr_destroy(&dev->mode_config.crtc_idr);
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Clean up ironlake clock computation code (rev4)
== Series Details == Series: Clean up ironlake clock computation code (rev4) URL : https://patchwork.freedesktop.org/series/4367/ State : success == Summary == Series 4367v4 Clean up ironlake clock computation code http://patchwork.freedesktop.org/api/1.0/series/4367/revisions/4/mbox/ Test drv_hangman: Subgroup error-state-basic: fail -> PASS (ilk-hp8440p) Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ilk-hp8440p) UNSTABLE Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (byt-nuc) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:192 pass:127 dwarn:1 dfail:0 fail:1 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1675/ 94c7a2ce8a4f659840625a318b1d3d8832f4ca46 drm-intel-nightly: 2016y-03m-22d-12h-51m-12s UTC integration manifest ea35ece59759aa200a53adfb9ed6cda48f1750e3 drm/i915: Split PNV version of crtc_compute_clock() ede2843aabc6eec8e77f11bf3b21a543e8af5388 drm/i915: Split g4x_crtc_compute_clock() a2cfa5150683dd0e6560bab55aed9d1eccc1f952 drm/i915: Split i8xx_crtc_compute_clock() a0830177a2490f7dbb7816c53a2fb533a3e07d8a drm/i915: Split CHV and VLV specific crtc_compute_clock() hooks 70fbc459af4e0425d36030496f7e245a2cca1d93 drm/i915: Merge ironlake_compute_clocks() and ironlake_crtc_compute_clock() a125eb27a18cb4f8995e6d6e4f0e3a4d8ede8363 drm/i915: Move fp divisor calculation into ironlake_compute_dpll() e362025b9c2151c7378aaf74917c47b56dde3877 drm/i915: Pass crtc_state->dpll directly to ->find_dpll() e453ab21b391ea55070a6524d3a8259fbeca0998 drm/i915: Simplify ironlake_crtc_compute_clock() CPU eDP case 0d9416317f7171a10ffc60f84d9cbc4c77a86e7f drm/i915: Remove PCH type checks from ironlake_crtc_compute_clock() 3cf3d010e9a301d57880cbef2087dbe35bb2f198 drm/i915: Don't calculate a new clock in ILK+ code if it is already set 679167339e291b18fcd965cf45a3a6ff10dcc900 drm/i915: Simplify ironlake reduced clock logic a bit bae0742ed14038f2d8881c05496832ce839ae197 drm/i915: Call g4x_find_best_dpll() directly from ILK+ code 4660c0dbc8111d8202fb32b42c6815f0482935d8 drm/i915: Fold intel_ironlake_limit() into clock computation function 8c843b6a2e9bc4f2b4b4d6352d2ed504ab414346 drm/i915: Merge ironlake_get_refclk() into its only caller e9cb4da98edb60650f68cd0e0954f0f1e450ae70 drm/i915: Remove checks for cloned config with LVDS in dpll code ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/drm-misc
Hi Dave, Bunch of small fixupes all over. Plus a dma-buf patch that Sumit asked me to cherry-pick since that's the only one he had in his tree. There's a sparse issue outstanding in the color mgr stuff, but Lionel is still working on something that actually appeases sparse. Cheers, Daniel The following changes since commit c1f415c9acb5877c408d9311eb837d7d50636a68: drm: atomic helper: do not unreference error pointer (2016-03-13 19:39:54 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-03-22 for you to fetch changes up to b47bcb93bbf201e9c5af698945755efeb60c0bc8: dma-buf/fence: fix fence_is_later v2 (2016-03-21 09:26:50 +0100) Andrzej Hajda (2): drm/atomic: use helper to get crtc state drm/atmel-hlcdc: use helper to get crtc state Chris Wilson (1): dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access() Christian König (1): dma-buf/fence: fix fence_is_later v2 Daniel Vetter (1): dma-buf: Update docs for SYNC ioctl Luis de Bethencourt (1): drm: remove excess description Documentation/dma-buf-sharing.txt | 11 ++- drivers/dma-buf/dma-buf.c | 19 --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +- drivers/gpu/drm/drm_atomic.c| 1 - drivers/gpu/drm/drm_atomic_helper.c | 14 -- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 15 +-- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +++-- drivers/gpu/drm/udl/udl_fb.c| 4 ++-- drivers/staging/android/ion/ion.c | 6 -- include/linux/dma-buf.h | 6 +++--- include/linux/fence.h | 2 +- 11 files changed, 45 insertions(+), 40 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/core: Fix ordering in drm_mode_config_cleanup.
__drm_atomic_helper_plane_destroy_state calls
drm_framebuffer_unreference, which means that if drm_framebuffer_free
is called before plane->destroy freed memory will be accessed.
A similar case happens for the blob list, which was freed before the
crtc state was, resulting in the unreference_blob from crtc_destroy_state
pointing to garbage memory causing another opportunity for a GPF.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_crtc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 51c5a00ffdff..5a13b1afccbe 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5958,6 +5958,15 @@ void drm_mode_config_cleanup(struct drm_device *dev)
drm_property_destroy(dev, property);
}
+ list_for_each_entry_safe(plane, plt, &dev->mode_config.plane_list,
+head) {
+ plane->funcs->destroy(plane);
+ }
+
+ list_for_each_entry_safe(crtc, ct, &dev->mode_config.crtc_list, head) {
+ crtc->funcs->destroy(crtc);
+ }
+
list_for_each_entry_safe(blob, bt, &dev->mode_config.property_blob_list,
head_global) {
drm_property_unreference_blob(blob);
@@ -5976,15 +5985,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
drm_framebuffer_free(&fb->refcount);
}
- list_for_each_entry_safe(plane, plt, &dev->mode_config.plane_list,
-head) {
- plane->funcs->destroy(plane);
- }
-
- list_for_each_entry_safe(crtc, ct, &dev->mode_config.crtc_list, head) {
- crtc->funcs->destroy(crtc);
- }
-
ida_destroy(&dev->mode_config.connector_ida);
idr_destroy(&dev->mode_config.tile_idr);
idr_destroy(&dev->mode_config.crtc_idr);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 105/190] drm/i915: Pad GTT views of exec objects up to user specified size
On Mon, Jan 11, 2016 at 10:44:49AM +, Chris Wilson wrote:
> Our GPUs impose certain requirements upon buffers that depend upon how
> exactly they are used. Typically this is expressed as that they require
> a larger surface than would be naively computed by pitch * height.
> Normally such requirements are hidden away in the userspace driver, but
> when we accept pointers from strangers and later impose extra conditions
> on them, the original client allocator has no idea about the
> monstrosities in the GPU and we require the userspace driver to inform
> the kernel how many padding pages are required beyond the client
> allocation.
>
> v2: Long time, no see
> v3: Try an anonymous union for uapi struct compatability
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Reviewed-by: Tvrtko Ursulin
Testcase: gem_mmap_gtt --run-subtest huge-bo-tiledX
Tested-by: David Weinehall
This patch fixes an OOPS on gen8+ triggered by the mentioned testcase.
> ---
> drivers/gpu/drm/i915/i915_drv.h| 6 ++-
> drivers/gpu/drm/i915/i915_gem.c| 79
> +++---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 16 +-
> include/uapi/drm/i915_drm.h| 8 ++-
> 4 files changed, 64 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4ada625b751e..49b126e4191e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2694,11 +2694,13 @@ void i915_gem_free_object(struct drm_gem_object *obj);
> int __must_check
> i915_gem_object_pin(struct drm_i915_gem_object *obj,
> struct i915_address_space *vm,
> + uint64_t size,
> uint32_t alignment,
> uint64_t flags);
> int __must_check
> i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
>const struct i915_ggtt_view *view,
> + uint64_t size,
>uint32_t alignment,
>uint64_t flags);
>
> @@ -2931,8 +2933,8 @@ i915_gem_obj_ggtt_pin(struct drm_i915_gem_object *obj,
> uint32_t alignment,
> unsigned flags)
> {
> - return i915_gem_object_pin(obj, i915_obj_to_ggtt(obj),
> -alignment, flags | PIN_GLOBAL);
> + return i915_gem_object_pin(obj, i915_obj_to_ggtt(obj), 0, alignment,
> +flags | PIN_GLOBAL);
> }
>
> static inline int
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a82a06a61262..2f14d2da75a5 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1440,7 +1440,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct
> vm_fault *vmf)
> }
>
> /* Now pin it into the GTT if needed */
> - ret = i915_gem_object_ggtt_pin(obj, &view, 0, PIN_MAPPABLE);
> + ret = i915_gem_object_ggtt_pin(obj, &view, 0, 0, PIN_MAPPABLE);
> if (ret)
> goto unlock;
>
> @@ -2746,20 +2746,20 @@ static struct i915_vma *
> i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
> struct i915_address_space *vm,
> const struct i915_ggtt_view *ggtt_view,
> +uint64_t size,
> unsigned alignment,
> uint64_t flags)
> {
> struct drm_device *dev = obj->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 fence_alignment, unfenced_alignment;
> - u32 search_flag, alloc_flag;
> u64 start, end;
> - u64 size, fence_size;
> + u32 search_flag, alloc_flag;
> struct i915_vma *vma;
> int ret;
>
> if (i915_is_ggtt(vm)) {
> - u32 view_size;
> + u32 fence_size, fence_alignment, unfenced_alignment;
> + u64 view_size;
>
> if (WARN_ON(!ggtt_view))
> return ERR_PTR(-EINVAL);
> @@ -2777,21 +2777,22 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
> *obj,
> view_size,
>
> obj->tiling_mode,
> false);
> - size = flags & PIN_MAPPABLE ? fence_size : view_size;
> + size = max(size, view_size);
> + if (flags & PIN_MAPPABLE)
> + size = max_t(u64, size, fence_size);
> +
> + if (alignment == 0)
> + alignment = flags & PIN_MAPPABLE ? fence_alignment :
> + unfenced_alignment;
> + if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
> + DRM_DEBUG("Invalid object (view type=%u) alignment
> requested %u\n",
> + ggtt_view ? ggtt_vi
[Intel-gfx] [PATCH 4/7] drm/i915: Add and initialize lspcon connector
lspcon is a tricky device which acts as DP in some cases
and as HDMI in some. Here is how:
- lspcon needs DP for all the i2c_ove_aux read/write transitions
so it needs to have some DP level initializations
- lspcon is detected by userspace/sink as HDMI device, so
it needs to be detectd as HDMI device.
This patch adds a custom connector for lspcon device, which
can pick and chose what it wants from existing functionality.
This patch also adds functions to init dp and hdmi to the
minimum need, and then play around with them.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c| 6
drivers/gpu/drm/i915/intel_dp.c | 31
drivers/gpu/drm/i915/intel_drv.h| 8 +
drivers/gpu/drm/i915/intel_hdmi.c | 17 +
drivers/gpu/drm/i915/intel_lspcon.c | 72 +
5 files changed, 134 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 91654ff..f68c257 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2169,6 +2169,12 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
+ /* Check if LSPCON is configured on this port */
+ if (intel_bios_is_lspcon_preset(dev, intel_dig_port->port)) {
+ intel_lspcon_init_connector(intel_dig_port);
+ return;
+ }
+
if (init_dp) {
if (!intel_ddi_init_dp_connector(intel_dig_port))
goto err;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3ff8f1d..6005c26 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5895,6 +5895,37 @@ fail:
return false;
}
+int intel_dp_init_minimum(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *intel_connector)
+{
+ int ret;
+ enum port port = intel_dig_port->port;
+ struct intel_dp *intel_dp = &intel_dig_port->dp;
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ intel_dig_port->dp.output_reg = DDI_BUF_CTL(port);
+ if (WARN(intel_dig_port->max_lanes < 1,
+"Not enough lanes (%d) for DP on port %c\n",
+intel_dig_port->max_lanes, port_name(port)))
+ return -EINVAL;
+
+ intel_dp->pps_pipe = INVALID_PIPE;
+ intel_dp->get_aux_clock_divider = skl_get_aux_clock_divider;
+ intel_dp->get_aux_send_ctl = skl_get_aux_send_ctl;
+ intel_dp->prepare_link_retrain = intel_ddi_prepare_link_retrain;
+ intel_dp->DP = I915_READ(intel_dp->output_reg);
+ intel_dp->attached_connector = intel_connector;
+ INIT_DELAYED_WORK(&intel_dp->panel_vdd_work,
+ edp_panel_vdd_work);
+
+ ret = intel_dp_aux_init(intel_dp, intel_connector);
+ if (ret)
+ DRM_ERROR("Aux init for LSPCON failed\n");
+
+ return ret;
+}
+
void
intel_dp_init(struct drm_device *dev,
i915_reg_t output_reg, enum port port)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f3e7e52..09273d5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1327,6 +1327,9 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, int
port_clock,
bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
bool
intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
link_status[DP_LINK_STATUS_SIZE]);
+int intel_dp_init_minimum(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *intel_connector);
+
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
@@ -1339,6 +1342,9 @@ void intel_dsi_init(struct drm_device *dev);
void intel_dvo_init(struct drm_device *dev);
+/* intel_lspcon.c */
+void intel_lspcon_init_connector(struct intel_digital_port *intel_dig_port);
+
/* legacy fbdev emulation in intel_fbdev.c */
#ifdef CONFIG_DRM_FBDEV_EMULATION
extern int intel_fbdev_init(struct drm_device *dev);
@@ -1392,6 +1398,8 @@ void intel_fbc_cleanup_cfb(struct drm_i915_private
*dev_priv);
void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port
port);
void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector);
+int intel_hdmi_init_minimum(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *intel_connector);
struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i9
[Intel-gfx] [PATCH 5/7] drm/i915: Add and register lspcon connector functions
This patch adds various lspcon connector functions. Some
of the functions are newly written, to meet the specific
needs of lspcon HW, whereas few of them are just an
abstraction layer on existing HDMI connector functions.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 11 +-
drivers/gpu/drm/i915/intel_hdmi.c| 8 +-
drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
drivers/gpu/drm/i915/intel_lspcon.c | 238 ++-
4 files changed, 251 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 09273d5..7b19a2c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1403,7 +1403,12 @@ int intel_hdmi_init_minimum(struct intel_digital_port
*intel_dig_port,
struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config);
-
+int intel_hdmi_get_modes(struct drm_connector *connector);
+int intel_hdmi_set_property(struct drm_connector *connector,
+ struct drm_property *property, uint64_t val);
+void intel_hdmi_destroy(struct drm_connector *connector);
+void intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
+ struct drm_connector *connector);
/* intel_lvds.c */
void intel_lvds_init(struct drm_device *dev);
@@ -1492,6 +1497,10 @@ bool intel_display_power_get_if_enabled(struct
drm_i915_private *dev_priv,
void intel_display_power_put(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
+/* intel_hotplug.c */
+bool intel_hpd_irq_event(struct drm_device *dev,
+ struct drm_connector *connector);
+
static inline void
assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
{
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9fcbbdf..b67bb30 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1447,7 +1447,7 @@ intel_hdmi_force(struct drm_connector *connector)
hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
}
-static int intel_hdmi_get_modes(struct drm_connector *connector)
+int intel_hdmi_get_modes(struct drm_connector *connector)
{
struct edid *edid;
@@ -1471,7 +1471,7 @@ intel_hdmi_detect_audio(struct drm_connector *connector)
return has_audio;
}
-static int
+int
intel_hdmi_set_property(struct drm_connector *connector,
struct drm_property *property,
uint64_t val)
@@ -1996,7 +1996,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
}
}
-static void intel_hdmi_destroy(struct drm_connector *connector)
+void intel_hdmi_destroy(struct drm_connector *connector)
{
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
@@ -2025,7 +2025,7 @@ static const struct drm_encoder_funcs
intel_hdmi_enc_funcs = {
.destroy = intel_encoder_destroy,
};
-static void
+void
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
intel_attach_force_audio_property(connector);
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index bee6730..11a3e02 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -226,7 +226,7 @@ static void intel_hpd_irq_storm_reenable_work(struct
work_struct *work)
intel_runtime_pm_put(dev_priv);
}
-static bool intel_hpd_irq_event(struct drm_device *dev,
+bool intel_hpd_irq_event(struct drm_device *dev,
struct drm_connector *connector)
{
enum drm_connector_status old_status;
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 9d5ed0c..e64abd3 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -39,6 +39,8 @@
#define DP_TYPE2_ADAPTER 0xA0
#define ADAPTER_TYPE_MASK 0xF0
#define LSPCON_MODE_MASK 0x1
+#define DDC_SEGMENT_ADDR 0x30
+#define DDC_ADDR 0x50
struct intel_digital_port *lspcon_to_dig_port(struct intel_lspcon *lspcon)
{
@@ -57,6 +59,11 @@ struct intel_lspcon *enc_to_lspcon(struct drm_encoder
*encoder)
return &intel_dig_port->lspcon;
}
+struct intel_lspcon *intel_attached_lspcon(struct drm_connector *connector)
+{
+ return enc_to_lspcon(&intel_attached_encoder(connector)->base);
+}
+
int lspcon_ioa_read(struct i2c_adapter *adapter, u8 *buffer,
u8 address, u8 offset, u8 no_of_bytes)
{
@@ -113,6 +120,214 @@ int lspcon_ioa_write(struct i2c_adapter *adapter, u8
*buffer,
return err;
}
+static int lspcon_get_edid_over_aux(void *data,
+
[Intel-gfx] [PATCH 7/7] drm/i915: Add lspcon hpd handler
This patch adds a new hpd handler for lspcon.
As lspcon has its own way of reading EDID and detecting
the device, it wont be efficient to use the existing hpd
functions to handle the hot_plug scenarios. This new function
reads the EDID and checks the status of the sink device.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_lspcon.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 6ef320b..0c064b9 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -278,6 +278,38 @@ bool lspcon_device_init(struct intel_lspcon *lspcon)
return true;
}
+enum irqreturn
+lspcon_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
+{
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct intel_encoder *intel_encoder = &intel_dig_port->base;
+ struct intel_connector *intel_connector;
+ bool changed = false;
+
+ mutex_lock(&dev->mode_config.mutex);
+ if (intel_encoder->hot_plug)
+ intel_encoder->hot_plug(intel_encoder);
+
+ for_each_intel_connector(dev, intel_connector) {
+ if (intel_connector->encoder == intel_encoder) {
+ struct drm_connector *connector =
+ &intel_connector->base;
+
+ DRM_DEBUG_DRIVER("Hptplug: Connector %s (pin %i).\n",
+ connector->name, intel_encoder->hpd_pin);
+ if (intel_hpd_irq_event(dev, connector))
+ changed = true;
+ }
+ }
+ mutex_unlock(&dev->mode_config.mutex);
+
+ if (changed) {
+ DRM_DEBUG_DRIVER("Sending event for change\n");
+ drm_kms_helper_hotplug_event(dev);
+ }
+ return IRQ_HANDLED;
+}
+
static int lspcon_get_edid_over_aux(void *data,
u8 *buf, unsigned int block, size_t len)
{
@@ -516,6 +548,9 @@ void intel_lspcon_init_connector(struct intel_digital_port
*intel_dig_port)
intel_connector->get_hw_state = intel_ddi_connector_get_hw_state;
i915_debugfs_connector_add(connector);
+ /* HPD handler */
+ intel_dig_port->hpd_pulse = lspcon_hpd_pulse;
+
/* init DP */
if (intel_dp_init_minimum(intel_dig_port, intel_connector)) {
DRM_ERROR("DP init for LSPCON failed\n");
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Add lspcon support
LSPCON is essentially an active DP-HDMI convertor. It has two modes of operations: - ls mode (for upto HDMI 1.4 outputs, 4k@30 resoution / 297MHz) - pcon mode (for upto HDMI 2.0 outputs, 4k@60 resolution / 600 MHz) This patch set adds support for LS mode of operation for GEN9 platforms. It adds a new connector for lspcon, whcih is a mix and match of DP and HDMI connectors, matching dual personality of lspcon devices. Notes: - Daniel Vetter gave a review comment on LSPCON design, to make it a separate encoder. This patch set tries to match that expectations with a separate connector, as DDI encoder already fulfills all the requirements of a lspcon_encoder. - This patch set tagrets LS mode of operations only. - PCON mode of operation will be added later, based on the requirements. This is to primarily unbloc Linux devices with LSPCON port. - This patch set is tested with BXT RVP + drm-nightly - As we redesigned this code, to meet the review comments, this is a working patch set, but not upto commercial quality yet. Shashank Sharma (7): drm/i915: add lspcon vbt bit parsing drm/i915: Add lspcon data structures drm/i915: Add new lspcon file drm/i915: Add and initialize lspcon connector drm/i915: Add and register lspcon connector functions drm/i915: Add lspcon core functions drm/i915: Add lspcon hpd handler drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_bios.c | 42 +++ drivers/gpu/drm/i915/intel_ddi.c | 6 + drivers/gpu/drm/i915/intel_dp.c | 31 ++ drivers/gpu/drm/i915/intel_drv.h | 35 +- drivers/gpu/drm/i915/intel_hdmi.c | 25 +- drivers/gpu/drm/i915/intel_hotplug.c | 2 +- drivers/gpu/drm/i915/intel_lspcon.c | 620 ++ drivers/gpu/drm/i915/intel_vbt_defs.h | 1 + 10 files changed, 759 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Add lspcon core functions
This patch adds lspcon's internal functions, which work
on the probe layer, and indicate the working status of
lspcon, which are mostly:
probe: A lspcon device is probed only once, during boot
time, as its always present with the device, next to port.
So the i2c_over_aux channel is alwyas read/writeable if DC is
powered on. If VBT says that this port contains lspcon, we
check and probe the HW to verify and initialize it.
get_mode: This function indicates the current mode of operation
of lspcon (ls or pcon mode)
change_mode: This function can change the lspcon's mode of
operation to desired mode.
Signed-off-by: Shashank Sharma
Signed-off-by: Akashdeep Sharma
---
drivers/gpu/drm/i915/intel_lspcon.c | 165
1 file changed, 165 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index e64abd3..6ef320b 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -120,6 +120,164 @@ int lspcon_ioa_write(struct i2c_adapter *adapter, u8
*buffer,
return err;
}
+enum lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
+{
+ u8 data;
+ int err = 0;
+ struct intel_digital_port *dig_port = lspcon_to_dig_port(lspcon);
+ struct i2c_adapter *adapter = &dig_port->dp.aux.ddc;
+
+ /* Read Status: i2c over aux */
+ err = lspcon_ioa_read(adapter, &data, LSPCON_I2C_ADDRESS,
+ LSPCON_MODE_CHECK_OFFSET, 1);
+ if (err < 0) {
+ DRM_ERROR("LSPCON read mode ioa (0x80, 0x41) failed\n");
+ return lspcon_mode_invalid;
+ }
+
+ DRM_DEBUG_DRIVER("LSPCON mode (0x80, 0x41) = %x\n", (unsigned int)data);
+ return data & LSPCON_MODE_MASK ? lspcon_mode_pcon : lspcon_mode_ls;
+}
+
+int lspcon_change_mode(struct intel_lspcon *lspcon,
+ enum lspcon_mode mode, bool force)
+{
+ u8 data;
+ int err;
+ int time_out = 200;
+ enum lspcon_mode current_mode;
+ struct intel_digital_port *dig_port = lspcon_to_dig_port(lspcon);
+
+ current_mode = lspcon_get_current_mode(lspcon);
+ if (current_mode == lspcon_mode_invalid) {
+ DRM_ERROR("Failed to get current LSPCON mode\n");
+ return -EFAULT;
+ }
+
+ if (current_mode == mode && !force) {
+ DRM_DEBUG_DRIVER("Current mode = desired LSPCON mode\n");
+ return 0;
+ }
+
+ if (mode == lspcon_mode_ls)
+ data = ~LSPCON_MODE_MASK;
+ else
+ data = LSPCON_MODE_MASK;
+
+ /* Change mode */
+ err = lspcon_ioa_write(&dig_port->dp.aux.ddc, &data, LSPCON_I2C_ADDRESS,
+ LSPCON_MODE_CHANGE_OFFSET, 1);
+ if (err < 0) {
+ DRM_ERROR("LSPCON mode change failed\n");
+ return err;
+ }
+
+ /*
+ * Confirm mode change by reading the status bit.
+ * Sometimes, it takes a while to change the mode,
+ * so wait and retry until time out or done.
+ */
+ while (time_out) {
+ current_mode = lspcon_get_current_mode(lspcon);
+ if (current_mode != mode) {
+ mdelay(10);
+ time_out -= 10;
+ } else {
+ lspcon->mode_of_op = mode;
+ DRM_DEBUG_DRIVER("LSPCON mode changed to %s\n",
+ mode == lspcon_mode_ls ? "LS" : "PCON");
+ return 0;
+ }
+ }
+
+ DRM_ERROR("LSPCON mode change timed out\n");
+ return -EFAULT;
+}
+
+bool lspcon_detect_identifier(struct intel_lspcon *lspcon)
+{
+ int err = 0;
+ u8 sign[LSPCON_IDENTIFIER_LENGTH + 1] = {'\0', };
+ struct intel_digital_port *dig_port = lspcon_to_dig_port(lspcon);
+ struct i2c_adapter *adapter = &dig_port->dp.aux.ddc;
+
+ /*
+* Identifier: First 15 bytes are ascii for "DP-HDMI ADAPTOR". The 16th
+* byte defines if thats a LSPCON or any other dongle. If byte 16 =0xa8
+* its LSPCON
+*/
+
+ /* Read 16 bytes from I2C reg 0x80, offset 0x0 I2C-over-aux */
+ err = lspcon_ioa_read(adapter, sign, LSPCON_I2C_ADDRESS,
+ LSPCON_ADAPTER_SIGN_OFFSET, LSPCON_IDENTIFIER_LENGTH);
+ if (err < 0) {
+ DRM_ERROR("Error reading lspcon sign (0x80, 0x0)\n");
+ return false;
+ }
+
+ /* Check sign */
+ if (strncmp((void *)sign, "DP-HDMI ADAPTOR",
+ LSPCON_IDENTIFIER_LENGTH - 1)) {
+ DRM_ERROR("Cant detect adaptor sign, its %s\n", sign);
+ return false;
+ }
+
+ /* Identify LSPCON */
+ if (sign[LSPCON_IDENTIFIER_OFFSET] != LSPCON_ADAPTER) {
+ DRM_ERROR("Found non LSPCON adaptor\n");
+ return false;
+ }
+
+ /* yay ... found a LSPCON */
+ DRM_DEBUG_DRIVER("LSPCO
[Intel-gfx] [PATCH 1/7] drm/i915: add lspcon vbt bit parsing
LSPCON can be configured on a port using VBT entry.
This patch adds code to parse VBT and detect presence of
LSPCON for a ddi port.
Signed-off-by: Akashdeep Sharma
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 42 +++
drivers/gpu/drm/i915/intel_vbt_defs.h | 1 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f330a53..cbd40de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3373,6 +3373,7 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
+bool intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..a04ab5c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1588,3 +1588,45 @@ bool intel_bios_is_dsi_present(struct drm_i915_private
*dev_priv,
return false;
}
+
+bool
+intel_bios_is_lspcon_preset(struct drm_device *dev, enum port port)
+{
+ unsigned char i;
+ enum port dvo_port = 0;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /* LSPCON is supported only for GEN 9 */
+ if (!IS_GEN9(dev))
+ return false;
+
+ /* Check if lspcon is supported in VBT */
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ if (!dev_priv->vbt.child_dev[i].common.lspcon)
+ continue;
+
+ switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+ case DVO_PORT_DPB:
+ dvo_port = PORT_B;
+ break;
+
+ case DVO_PORT_DPC:
+ dvo_port = PORT_C;
+ break;
+
+ case DVO_PORT_DPD:
+ dvo_port = PORT_D;
+ break;
+
+ default:
+ continue;
+ }
+
+ if (dvo_port == port) {
+ DRM_DEBUG_DRIVER("LSPCON configured on port %c\n",
+ port_name(port));
+ return true;
+ }
+ }
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..0066b24 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -276,6 +276,7 @@ struct common_child_dev_config {
u8 flags_1;
u8 not_common3[13];
u8 iboost_level;
+ u8 lspcon:1;
} __packed;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: Add new lspcon file
This patch adds a new file for lspcon with
some basic stuff like:
- Some read/wrire addresses for lspcon device
- Basic read/write functions, using i2c over aux channel
- Utility functions to get lspcon/encoder/connector
Signed-off-by: Shashank Sharma
Signed-off-by: Akashdeep Sharma
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/intel_lspcon.c | 114
2 files changed, 116 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5558a03..00a531a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -90,7 +90,8 @@ i915-y += dvo_ch7017.o \
intel_lvds.o \
intel_panel.o \
intel_sdvo.o \
- intel_tv.o
+ intel_tv.o \
+ intel_lspcon.o
# virtual gpu code
i915-y += i915_vgpu.o
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
new file mode 100644
index 000..f5c91db
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Akashdeep Sharma
+ *
+ */
+#include
+#include
+#include "intel_drv.h"
+
+#define LSPCON_I2C_ADDRESS 0x80
+#define LSPCON_MODE_CHANGE_OFFSET 0x40
+#define LSPCON_MODE_CHECK_OFFSET 0x41
+#define LSPCON_ADAPTER_SIGN_OFFSET 0x00
+#define LSPCON_IDENTIFIER_OFFSET 0x10
+#define LSPCON_IDENTIFIER_LENGTH 0x10
+#define LSPCON_ADAPTER 0xA8
+#define DP_TYPE2_ADAPTER 0xA0
+#define ADAPTER_TYPE_MASK 0xF0
+#define LSPCON_MODE_MASK 0x1
+
+struct intel_digital_port *lspcon_to_dig_port(struct intel_lspcon *lspcon)
+{
+ return container_of(lspcon, struct intel_digital_port, lspcon);
+}
+
+struct intel_hdmi *lspcon_to_hdmi(struct intel_lspcon *lspcon)
+{
+ return &lspcon_to_dig_port(lspcon)->hdmi;
+}
+
+struct intel_lspcon *enc_to_lspcon(struct drm_encoder *encoder)
+{
+ struct intel_digital_port *intel_dig_port =
+ container_of(encoder, struct intel_digital_port, base.base);
+ return &intel_dig_port->lspcon;
+}
+
+int lspcon_ioa_read(struct i2c_adapter *adapter, u8 *buffer,
+ u8 address, u8 offset, u8 no_of_bytes)
+{
+ int err = 0;
+
+ struct i2c_msg msgs[] = {
+ {
+ .addr = address >> 1,
+ .flags = 0,
+ .len= 1,
+ .buf= &offset,
+ }, {
+ .addr = address >> 1,
+ .flags = I2C_M_RD,
+ .len= no_of_bytes,
+ .buf= buffer,
+ }
+ };
+
+ /* I2C over AUX here */
+ err = adapter->algo->master_xfer(adapter, msgs, 2);
+ if (err < 0)
+ DRM_ERROR("LSPCON: Failed I2C over Aux read(addr=0x%x)\n",
+ (unsigned int)offset);
+
+ return err;
+}
+
+int lspcon_ioa_write(struct i2c_adapter *adapter, u8 *buffer,
+ u8 address, u8 offset, u8 no_of_bytes)
+{
+ int err = 0;
+
+ struct i2c_msg msgs[] = {
+ {
+ .addr = address >> 1,
+ .flags = 0,
+ .len= 1,
+ .buf= &offset,
+ }, {
+ .addr = address >> 1,
+ .flags = 0,
+ .len
[Intel-gfx] [PATCH 2/7] drm/i915: Add lspcon data structures
This patch adds lspcon structure in intel_dig_port.
These strucres will be used to check runtime status
of LSPCON device.
Signed-off-by: Shashank Sharma
Signed-off-by: Akashdeep Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5136eef..f3e7e52 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -855,12 +855,28 @@ struct intel_dp {
bool compliance_test_active;
};
+/* LSPCON possibe modes of operation */
+enum lspcon_mode {
+ /* Invalid */
+ lspcon_mode_invalid,
+ /* level shifter mode */
+ lspcon_mode_ls,
+ /* protocol converter mode */
+ lspcon_mode_pcon,
+};
+
+struct intel_lspcon {
+ bool active;
+ enum lspcon_mode mode_of_op;
+};
+
struct intel_digital_port {
struct intel_encoder base;
enum port port;
u32 saved_port_bits;
struct intel_dp dp;
struct intel_hdmi hdmi;
+ struct intel_lspcon lspcon;
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
uint8_t max_lanes;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/kms_rotation_crc: exercise invalid rotations
Hi Ville, Is this what you had in mind for patches 1-2? Regards, Matt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Wait until after wm optimization to drop runtime PM reference
On ti, 2016-03-22 at 15:51 +0200, Jani Nikula wrote: > On Tue, 22 Mar 2016, Imre Deak wrote: > > [ text/plain ] > > On ti, 2016-03-08 at 09:26 -0800, Matt Roper wrote: > > > On Mon, Mar 07, 2016 at 11:47:51AM +, Patchwork wrote: > > > > == Series Details == > > > > > > > > Series: drm/i915: Wait until after wm optimization to drop > > > > runtime > > > > PM reference > > > > URL : https://patchwork.freedesktop.org/series/4135/ > > > > State : failure > > > > > > > > == Summary == > > > > > > > > Series 4135v1 drm/i915: Wait until after wm optimization to > > > > drop > > > > runtime PM reference > > > > http://patchwork.freedesktop.org/api/1.0/series/4135/revisions/ > > > > 1/mb > > > > ox/ > > > > > > > > Test kms_flip: > > > > Subgroup basic-flip-vs-wf_vblank: > > > > fail -> PASS (bsw-nuc-2) > > > > Subgroup basic-plain-flip: > > > > dmesg-warn -> PASS (hsw-gt2) > > > > Test kms_force_connector_basic: > > > > Subgroup force-load-detect: > > > > pass -> SKIP (ivb-t430s) > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93769 > > > > > > > Test kms_pipe_crc_basic: > > > > Subgroup read-crc-pipe-c: > > > > dmesg-warn -> PASS (hsw-gt2) > > > > Subgroup suspend-read-crc-pipe-a: > > > > dmesg-warn -> PASS (skl-i5k-2) > > > > skip -> PASS (hsw-brixbox) > > > > Subgroup suspend-read-crc-pipe-c: > > > > pass -> DMESG-WARN (bsw-nuc-2) > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93294 > > > > > > > pass -> INCOMPLETE (hsw-gt2) > > > > > > Seems like the machine just died completely? No > > > stdout/stderr/command/dmesg output available from CI and time is > > > given > > > as 0:00:00. Doesn't seem like it could be related to this patch. > > > > > > > > > > Test pm_rpm: > > > > Subgroup basic-pci-d3-state: > > > > dmesg-warn -> PASS (snb-dellxps) > > > > Subgroup basic-rte: > > > > pass -> DMESG-WARN (bsw-nuc-2) > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=94164 > > > > > > > > > Matt > > > > Pushed to -dinq, thanks for the patch and the review. > > > > I had to rebase it on top of Ville's recent > > s/crtc_state/old_crtc_state/ change, please double check it. > > > > Jani, this is for -fixes. > > Surely you added either > > Cc: drm-intel-fi...@lists.freedesktop.org > > or > > Cc: sta...@vger.kernel.org > > in the commit when you pushed, then? No, I haven't will do that in the future. Btw, what's the rule for deciding that something is for -fixes or stable only after it's been pushed? Just ping you in case for -fixes and resend it in case of stable? --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject non-canonical rotations
Hi Daniel, >> I thought we do normalize this somewhere. I did write an i-g-t test which submits such a rotation value and it is not rejected. >> Your patch lacks motivation As in I haven't properly conveyed the motivation behind the patch in the commit message? >> Yes I can usually guess when it's due to static analyzer checks, but you need to explain that. And you need to explain what exactly the analyzer is complaining about. erm, no static analyser, for this patch or any prior, promise, but duly noted ;) Joonas actually suggested this patch, and some of the preceding ones as beginner tasks for me. Regards, Matt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: fix lut value extraction function
When extracting the value at full precision (16 bits), no need to
round the value.
This was spotted by Jani when running sparse. Unfortunately this fix
doesn't get rid of the warning.
Signed-off-by: Lionel Landwerlin
Reported-by: Jani Nikula
Cc: Daniel Stone
Cc: Daniel Vetter
Cc: Matt Roper
Cc: dri-de...@lists.freedesktop.org
Fixes: 5488dc16fde7 ("drm: introduce pipe color correction properties")
---
include/drm/drm_crtc.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e0170bf..da63b4d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2600,10 +2600,14 @@ static inline struct drm_property
*drm_property_find(struct drm_device *dev,
static inline uint32_t drm_color_lut_extract(uint32_t user_input,
uint32_t bit_precision)
{
- uint32_t val = user_input + (1 << (16 - bit_precision - 1));
+ uint32_t val = user_input;
uint32_t max = 0x >> (16 - bit_precision);
- val >>= 16 - bit_precision;
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 16) {
+ val += 1UL << (16 - bit_precision - 1);
+ val >>= 16 - bit_precision;
+ }
return clamp_val(val, 0, max);
}
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Increase context alignment requirement for Sandybridge
In bugzilla, there are some very weird bugs on SNB GT1 whereby the seqno stop being written, but the GPU is otherwise functional, well the command streamer at least! However, since the seqno were not being updated any waits upon rendering results hung, triggering the GPU hang detector. I found a very similar hang when running igt/gem_exec_whisper on a SNB GT1 and after playing around came to the conclusion that: (a) it depends on timing, enabling debug and other slowdowns masks the bug; (b) it was not context size, as increasing the allocation to 128KiB made no difference; (c) it depended upon placement as restricting the binding to the mappable region works; (d) it depended upon alignment of the context binding, though the bspec still only lists the restriction as 4k Changing the alignment constrainst seems to be least intrusive, and though I have not been able to reproduce this on snb-gt2 and all the recent bugs to the best of my knowledge have been snb-gt1, it is safer to apply the constraint to all snb. Though I am still a little wary that is merely a side-effect that is papering over the issue (for example, it may be placement of the context next to another object that is causng the issue, or it may be finding the new alignment slows down context switches enough etc). Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1 References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262 Signed-off-by: Chris Wilson Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 394e525e55f1..f0883a968e11 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -94,7 +94,7 @@ * I've seen in a spec to date, and that was a workaround for a non-shipping * part. It should be safe to decrease this, but it's more future proof as is. */ -#define GEN6_CONTEXT_ALIGN (64<<10) +#define GEN6_CONTEXT_ALIGN (256<<10) #define GEN7_CONTEXT_ALIGN 4096 static size_t get_context_alignment(struct drm_device *dev) -- 2.8.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC
On Tue, 22 Mar 2016, Daniel Vetter wrote:
> [ text/plain ]
> On Tue, Mar 22, 2016 at 12:28:20PM +0200, Jani Nikula wrote:
>> On Mon, 21 Mar 2016, Paulo Zanoni wrote:
>> > +enum fb_mmap_wa_flags {
>> > + FB_MMAP_WA_CPU =1 << 0,
>> > + FB_MMAP_WA_GTT =1 << 1,
>> > + FB_MMAP_WA_DISABLE =1 << 2,
>> > + FB_MMAP_WA_FLAG_COUNT = 3,
>> > +};
>>
>> Drive-by review, adding bit flags as enums doesn't feel like what enums
>> should be used for. I'd go for macros instead.
>
> Pretty established convention, some like it since it allows gdb&friends to
> decode your bitflags for you. So abusing enums as flag set is imo ok.
Bah, prevents GCC and friends from giving you sensible warnings on
switch cases etc. :p
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Wait until after wm optimization to drop runtime PM reference
On Tue, 22 Mar 2016, Imre Deak wrote: > [ text/plain ] > On ti, 2016-03-08 at 09:26 -0800, Matt Roper wrote: >> On Mon, Mar 07, 2016 at 11:47:51AM +, Patchwork wrote: >> > == Series Details == >> > >> > Series: drm/i915: Wait until after wm optimization to drop runtime >> > PM reference >> > URL : https://patchwork.freedesktop.org/series/4135/ >> > State : failure >> > >> > == Summary == >> > >> > Series 4135v1 drm/i915: Wait until after wm optimization to drop >> > runtime PM reference >> > http://patchwork.freedesktop.org/api/1.0/series/4135/revisions/1/mb >> > ox/ >> > >> > Test kms_flip: >> > Subgroup basic-flip-vs-wf_vblank: >> > fail -> PASS (bsw-nuc-2) >> > Subgroup basic-plain-flip: >> > dmesg-warn -> PASS (hsw-gt2) >> > Test kms_force_connector_basic: >> > Subgroup force-load-detect: >> > pass -> SKIP (ivb-t430s) >> >> https://bugs.freedesktop.org/show_bug.cgi?id=93769 >> >> > Test kms_pipe_crc_basic: >> > Subgroup read-crc-pipe-c: >> > dmesg-warn -> PASS (hsw-gt2) >> > Subgroup suspend-read-crc-pipe-a: >> > dmesg-warn -> PASS (skl-i5k-2) >> > skip -> PASS (hsw-brixbox) >> > Subgroup suspend-read-crc-pipe-c: >> > pass -> DMESG-WARN (bsw-nuc-2) >> >> https://bugs.freedesktop.org/show_bug.cgi?id=93294 >> >> > pass -> INCOMPLETE (hsw-gt2) >> >> Seems like the machine just died completely? No >> stdout/stderr/command/dmesg output available from CI and time is >> given >> as 0:00:00. Doesn't seem like it could be related to this patch. >> >> >> > Test pm_rpm: >> > Subgroup basic-pci-d3-state: >> > dmesg-warn -> PASS (snb-dellxps) >> > Subgroup basic-rte: >> > pass -> DMESG-WARN (bsw-nuc-2) >> >> https://bugs.freedesktop.org/show_bug.cgi?id=94164 >> >> >> Matt > > Pushed to -dinq, thanks for the patch and the review. > > I had to rebase it on top of Ville's recent > s/crtc_state/old_crtc_state/ change, please double check it. > > Jani, this is for -fixes. Surely you added either Cc: drm-intel-fi...@lists.freedesktop.org or Cc: sta...@vger.kernel.org in the commit when you pushed, then? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [MIPI CABC 2/2] drm/i915: CABC support for backlight control
On Tue, 22 Mar 2016, Deepak M wrote:
> In CABC (Content Adaptive Brightness Control) content grey level
> scale can be increased while simultaneously decreasing
> brightness of the backlight to achieve same perceived brightness.
>
> The CABC is not standardized and panel vendors are free to follow
> their implementation. The CABC implementaion here assumes that the
> panels use standard SW register for control.
>
> In this design there will be no PWM signal from the SoC and DCS
> commands are sent to enable and control the backlight brightness.
>
> v2: Moving the CABC bkl functions to new file.(Jani)
>
> v3: Rebase
>
> v4: Rebase
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Yetunde Adebisi
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_dsi.c | 19 +++-
> drivers/gpu/drm/i915/intel_dsi.h | 4 +
> drivers/gpu/drm/i915/intel_dsi_cabc.c | 179
> ++
> drivers/gpu/drm/i915/intel_panel.c| 4 +
> 6 files changed, 206 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7ffb51b..065c410 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -83,6 +83,7 @@ i915-y += dvo_ch7017.o \
> intel_dp_mst.o \
> intel_dp.o \
> intel_dsi.o \
> + intel_dsi_cabc.o \
> intel_dsi_panel_vbt.o \
> intel_dsi_pll.o \
> intel_dvo.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 050d860..d196404 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3489,7 +3489,7 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
> u16 reg, u32 value,
>enum intel_sbi_destination destination);
> u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -
> +int intel_dsi_cabc_init_backlight_funcs(struct intel_connector
> *intel_connector);
This probably fits better in intel_drv.h under a /* intel_dsi_cabc.c */
comment, see the file for examples.
> int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
> int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 456676c..7aa707f 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1209,10 +1209,25 @@ void intel_dsi_init(struct drm_device *dev)
> else
> intel_encoder->crtc_mask = BIT(PIPE_B);
>
> - if (dev_priv->vbt.dsi.config->dual_link)
> + if (dev_priv->vbt.dsi.config->dual_link) {
> intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
> - else
> + switch (dev_priv->vbt.dsi.config->dl_cabc_port) {
> + case CABC_PORT_A:
> + intel_dsi->bkl_dcs_ports = BIT(PORT_A);
> + break;
> + case CABC_PORT_C:
> + intel_dsi->bkl_dcs_ports = BIT(PORT_C);
> + break;
> + case CABC_PORT_A_AND_C:
> + intel_dsi->bkl_dcs_ports = BIT(PORT_A) | BIT(PORT_C);
> + break;
> + default:
> + DRM_ERROR("Unknown MIPI ports for sending DCS\n");
> + }
> + } else {
> intel_dsi->ports = BIT(port);
> + intel_dsi->bkl_dcs_ports = BIT(port);
> + }
>
> /* Create a DSI host (and a device) for each port. */
> for_each_dsi_port(port, intel_dsi->ports) {
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 0e758f1..5c07d59 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -34,6 +34,10 @@
> #define DSI_DUAL_LINK_FRONT_BACK 1
> #define DSI_DUAL_LINK_PIXEL_ALT 2
>
> +#define CABC_PORT_A 0x00
> +#define CABC_PORT_C 0x01
> +#define CABC_PORT_A_AND_C 0x02
> +
> struct intel_dsi_host;
>
> struct intel_dsi {
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cabc.c
> b/drivers/gpu/drm/i915/intel_dsi_cabc.c
> new file mode 100644
> index 000..d14a669
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_dsi_cabc.c
> @@ -0,0 +1,179 @@
> +/*
> + * Copyright © 2006-2010 Intel Corporation
2016
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Render decompression support for Gen9 and above
On 22 March 2016 at 13:30, Daniel Stone wrote: > Exactly the same as the last time we discussed it I should add that I understand your previous objection that creating framebuffers on the fly is not performant enough, and you object to the effort of managing 100 rather than 50 framebuffers upfront (though honestly, if you get to 50 framebuffers you're already having to do some clever setup/management anyway). But in the last thread, Daniel Vetter asked for some performance numbers to bear out your objection that framebuffer creation is too costly, leading to getting it fixed if this is in fact the case (since other userspace relies on it being fast), but this performance analysis never arrived. I'd still be interested in seeing that. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/15] drm/i915: Split i8xx_crtc_compute_clock()
Split a GEN2 specific version from i9xx_crtc_compute_clock(). With this
there is no need for i9xx_get_refclk() anymore, and the differences
between platforms become more obvious.
v2: Use i8xx as prefix instead of gen2. (Ville and Daniel)
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 91 +---
1 file changed, 53 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dca5b15..1e08667 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -595,7 +595,7 @@ intel_limit(struct intel_crtc_state *crtc_state, int refclk)
const intel_limit_t *limit;
if (IS_BROXTON(dev) || IS_CHERRYVIEW(dev) || IS_VALLEYVIEW(dev) ||
- HAS_PCH_SPLIT(dev))
+ HAS_PCH_SPLIT(dev) || IS_GEN2(dev))
limit = NULL;
if (IS_G4X(dev)) {
@@ -610,13 +610,6 @@ intel_limit(struct intel_crtc_state *crtc_state, int
refclk)
limit = &intel_limits_i9xx_lvds;
else
limit = &intel_limits_i9xx_sdvo;
- } else {
- if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS))
- limit = &intel_limits_i8xx_lvds;
- else if (intel_pipe_will_have_type(crtc_state,
INTEL_OUTPUT_DVO))
- limit = &intel_limits_i8xx_dvo;
- else
- limit = &intel_limits_i8xx_dac;
}
WARN_ON(limit == NULL);
@@ -7102,27 +7095,6 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
&& !(dev_priv->quirks & QUIRK_LVDS_SSC_DISABLE);
}
-static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state)
-{
- struct drm_device *dev = crtc_state->base.crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- int refclk;
-
- WARN_ON(!crtc_state->base.state);
-
- if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
- intel_panel_use_ssc(dev_priv)) {
- refclk = dev_priv->vbt.lvds_ssc_freq;
- DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n", refclk);
- } else if (!IS_GEN2(dev)) {
- refclk = 96000;
- } else {
- refclk = 48000;
- }
-
- return refclk;
-}
-
static uint32_t pnv_dpll_compute_fp(struct dpll *dpll)
{
return (1 << dpll->n) << 16 | dpll->m2;
@@ -7877,14 +7849,50 @@ static void i9xx_set_pipeconf(struct intel_crtc
*intel_crtc)
POSTING_READ(PIPECONF(intel_crtc->pipe));
}
+static int i8xx_crtc_compute_clock(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const intel_limit_t *limit;
+ int refclk = 48000;
+
+ memset(&crtc_state->dpll_hw_state, 0,
+ sizeof(crtc_state->dpll_hw_state));
+
+ if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
+ if (intel_panel_use_ssc(dev_priv)) {
+ refclk = dev_priv->vbt.lvds_ssc_freq;
+ DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
refclk);
+ }
+
+ limit = &intel_limits_i8xx_lvds;
+ } else if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_DVO)) {
+ limit = &intel_limits_i8xx_dvo;
+ } else {
+ limit = &intel_limits_i8xx_dac;
+ }
+
+ if (!crtc_state->clock_set &&
+ !i9xx_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
+refclk, NULL, &crtc_state->dpll)) {
+ DRM_ERROR("Couldn't find PLL settings for mode!\n");
+ return -EINVAL;
+ }
+
+ i8xx_compute_dpll(crtc, crtc_state, NULL);
+
+ return 0;
+}
+
static int i9xx_crtc_compute_clock(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- int refclk;
bool ok;
const intel_limit_t *limit;
+ int refclk = 96000;
memset(&crtc_state->dpll_hw_state, 0,
sizeof(crtc_state->dpll_hw_state));
@@ -7892,9 +7900,13 @@ static int i9xx_crtc_compute_clock(struct intel_crtc
*crtc,
if (crtc_state->has_dsi_encoder)
return 0;
- if (!crtc_state->clock_set) {
- refclk = i9xx_get_refclk(crtc_state);
+ if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
+ intel_panel_use_ssc(dev_priv)) {
+ refclk = dev_priv->vbt.lvds_ssc_freq;
+ DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n", refclk);
+ }
+
Re: [Intel-gfx] [PATCH 2/7] drm/i915/guc: always reset GuC before loading firmware
On 21/03/2016 10:16, Dave Gordon wrote:
After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loaded the GuC with
firmware, which will then cause this kernel's attempt to (re)load the
firmware to fail (GuC program memory is write-once!).
So here we choose to always reset the GuC just before (re)loading the
firmware, so the hardware should then be in a well-known state, and we
may even avoid some of the issues arising from unpredictable timing.
Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.
Signed-off-by: Dave Gordon
Cc: Arun Siluvery
Cc: Alex Dai
Please add bugzilla reference.
---
drivers/gpu/drm/i915/i915_guc_reg.h | 12 --
drivers/gpu/drm/i915/intel_guc_loader.c | 40 -
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 94ceee5..80786d9 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -27,10 +27,12 @@
/* Definitions of GuC H/W registers, bits, etc */
#define GUC_STATUS_MMIO(0xc000)
-#define GS_MIA_IN_RESET (1 << 0)
+#define GS_RESET_SHIFT 0
+#define GS_MIA_IN_RESET(0x01 << GS_RESET_SHIFT)
#define GS_BOOTROM_SHIFT1
#define GS_BOOTROM_MASK (0x7F << GS_BOOTROM_SHIFT)
#define GS_BOOTROM_RSA_FAILED (0x50 << GS_BOOTROM_SHIFT)
+#define GS_BOOTROM_JUMP_PASSED (0x76 << GS_BOOTROM_SHIFT)
#define GS_UKERNEL_SHIFT8
#define GS_UKERNEL_MASK (0xFF << GS_UKERNEL_SHIFT)
#define GS_UKERNEL_LAPIC_DONE (0x30 << GS_UKERNEL_SHIFT)
@@ -38,7 +40,13 @@
#define GS_UKERNEL_READY (0xF0 << GS_UKERNEL_SHIFT)
#define GS_MIA_SHIFT16
#define GS_MIA_MASK (0x07 << GS_MIA_SHIFT)
-#define GS_MIA_CORE_STATE (1 << GS_MIA_SHIFT)
+#define GS_MIA_CORE_STATE (0x01 << GS_MIA_SHIFT)
+#define GS_MIA_HALT_REQUESTED (0x02 << GS_MIA_SHIFT)
+#define GS_MIA_ISR_ENTRY (0x04 << GS_MIA_SHIFT)
+#define GS_AUTH_STATUS_SHIFT 30
+#define GS_AUTH_STATUS_MASK(0x03 << GS_AUTH_STATUS_SHIFT)
+#define GS_AUTH_STATUS_BAD (0x01 << GS_AUTH_STATUS_SHIFT)
+#define GS_AUTH_STATUS_GOOD(0x02 << GS_AUTH_STATUS_SHIFT)
#define SOFT_SCRATCH(n) _MMIO(0xc180 + (n) * 4)
#define SOFT_SCRATCH_COUNT16
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index a07c228..a875936 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -387,7 +387,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
- int err = 0;
+ int retries, err = 0;
if (!i915.enable_guc_submission)
return 0;
@@ -441,29 +441,26 @@ int intel_guc_ucode_load(struct drm_device *dev)
* steppings also so this is extended as well.
*/
/* WaEnableGuCBootHashCheckNotSet:skl,bxt */
- err = guc_ucode_xfer(dev_priv);
- if (err) {
- int retries = 3;
-
- DRM_ERROR("GuC fw load failed, err=%d, attempting reset and
retry\n", err);
-
- while (retries--) {
- err = i915_reset_guc(dev_priv);
- if (err)
- break;
-
- err = guc_ucode_xfer(dev_priv);
- if (!err) {
- DRM_DEBUG_DRIVER("GuC fw reload succeeded after
reset\n");
- break;
- }
- DRM_DEBUG_DRIVER("GuC fw reload retries left: %d\n",
retries);
- }
-
+ for (retries = 3; ; ) {
+ /*
+* Always reset the GuC just before (re)loading, so
+* that the state and timing are fairly predictable
+*/
+ err = i915_reset_guc(dev_priv);
if (err) {
- DRM_ERROR("GuC fw reload attempt failed, ret=%d\n",
err);
+ DRM_ERROR("GuC reset failed, err %d\n", err);
goto fail;
}
+
+ err = guc_ucode_xfer(dev_priv);
+ if (!err)
+ break;
+
+ if (--retries == 0)
+ goto fail;
+
+ DRM_INFO("GuC fw load failed, err %d; will reset and "
+
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Render decompression support for Gen9 and above
Hi Gary, On 21 March 2016 at 12:20, Smith, Gary K wrote: > What are the objections to this change? Exactly the same as the last time we discussed it: that you're abusing plane properties to contain fundamental properties of the buffer you want to scan out, i.e. that which naturally belongs in the framebuffer object rather than a separate plane property. And doing it in a way which is prone to failure when userspace is unaware of these properties too. That being said, I hadn't noticed that this had moved to being a purely Intel-private property, rather than touching Android core at all, so if you can get it past the Intel DRM maintainers, then fine. I was primarily watching out for core DRM. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/15] drm/i915: Move fp divisor calculation into ironlake_compute_dpll()
On Tue, 2016-03-22 at 14:49 +0200, Ville Syrjälä wrote:
> On Mon, Mar 21, 2016 at 06:00:11PM +0200, Ander Conselvan de Oliveira wrote:
> > Follow what is done in i8xx_compute_dpll() and i9xx_compute_dpll() and
> > move the lower level details of setting crtc_state->dpll_hw_state into
> > the _compute_dpll() function.
>
> Missing sob.
Oops,
Signed-off-by: Ander Conselvan de Oliveira
> Reviewed-by: Ville Syrjälä
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 45 ++---
> > ---
> > 1 file changed, 22 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 0b6eabf..b6541a0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8821,10 +8821,9 @@ static bool ironlake_needs_fb_cb_tune(struct dpll
> > *dpll, int factor)
> > return i9xx_dpll_compute_m(dpll) < factor * dpll->n;
> > }
> >
> > -static uint32_t ironlake_compute_dpll(struct intel_crtc *intel_crtc,
> > - struct intel_crtc_state *crtc_state,
> > - u32 *fp,
> > - intel_clock_t *reduced_clock, u32
> > *fp2)
> > +static void ironlake_compute_dpll(struct intel_crtc *intel_crtc,
> > + struct intel_crtc_state *crtc_state,
> > + intel_clock_t *reduced_clock)
> > {
> > struct drm_crtc *crtc = &intel_crtc->base;
> > struct drm_device *dev = crtc->dev;
> > @@ -8833,7 +8832,7 @@ static uint32_t ironlake_compute_dpll(struct
> > intel_crtc *intel_crtc,
> > struct drm_connector *connector;
> > struct drm_connector_state *connector_state;
> > struct intel_encoder *encoder;
> > - uint32_t dpll;
> > + u32 dpll, fp, fp2;
> > int factor, i;
> > bool is_lvds = false, is_sdvo = false;
> >
> > @@ -8866,11 +8865,19 @@ static uint32_t ironlake_compute_dpll(struct
> > intel_crtc *intel_crtc,
> > } else if (crtc_state->sdvo_tv_clock)
> > factor = 20;
> >
> > + fp = i9xx_dpll_compute_fp(&crtc_state->dpll);
> > +
> > if (ironlake_needs_fb_cb_tune(&crtc_state->dpll, factor))
> > - *fp |= FP_CB_TUNE;
> > + fp |= FP_CB_TUNE;
> > +
> > + if (reduced_clock) {
> > + fp2 = i9xx_dpll_compute_fp(reduced_clock);
> >
> > - if (fp2 && (reduced_clock->m < factor * reduced_clock->n))
> > - *fp2 |= FP_CB_TUNE;
> > + if (reduced_clock->m < factor * reduced_clock->n)
> > + fp2 |= FP_CB_TUNE;
> > + } else {
> > + fp2 = fp;
> > + }
> >
> > dpll = 0;
> >
> > @@ -8912,14 +8919,17 @@ static uint32_t ironlake_compute_dpll(struct
> > intel_crtc *intel_crtc,
> > else
> > dpll |= PLL_REF_INPUT_DREFCLK;
> >
> > - return dpll | DPLL_VCO_ENABLE;
> > + dpll |= DPLL_VCO_ENABLE;
> > +
> > + crtc_state->dpll_hw_state.dpll = dpll;
> > + crtc_state->dpll_hw_state.fp0 = fp;
> > + crtc_state->dpll_hw_state.fp1 = fp2;
> > }
> >
> > static int ironlake_crtc_compute_clock(struct intel_crtc *crtc,
> >struct intel_crtc_state *crtc_state)
> > {
> > intel_clock_t reduced_clock;
> > - u32 dpll = 0, fp = 0, fp2 = 0;
> > bool has_reduced_clock = false;
> > struct intel_shared_dpll *pll;
> >
> > @@ -8941,19 +8951,8 @@ static int ironlake_crtc_compute_clock(struct
> > intel_crtc *crtc,
> > return -EINVAL;
> > }
> >
> > - fp = i9xx_dpll_compute_fp(&crtc_state->dpll);
> > - if (has_reduced_clock)
> > - fp2 = i9xx_dpll_compute_fp(&reduced_clock);
> > - else
> > - fp2 = fp;
> > -
> > - dpll = ironlake_compute_dpll(crtc, crtc_state,
> > -&fp, &reduced_clock,
> > -has_reduced_clock ? &fp2 : NULL);
> > -
> > - crtc_state->dpll_hw_state.dpll = dpll;
> > - crtc_state->dpll_hw_state.fp0 = fp;
> > - crtc_state->dpll_hw_state.fp1 = fp2;
> > + ironlake_compute_dpll(crtc, crtc_state,
> > + has_reduced_clock ? &reduced_clock : NULL);
> >
> > pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
> > if (pll == NULL) {
> > --
> > 2.4.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Make __i915_printk debug output behave the same as DRM_DEBUG_DRIVER
On ti, 2016-03-22 at 08:04 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Make __i915_printk debug output behave the same as > DRM_DEBUG_DRIVER > URL : https://patchwork.freedesktop.org/series/4713/ > State : warning > > == Summary == > > Series 4713v1 drm/i915: Make __i915_printk debug output behave the > same as DRM_DEBUG_DRIVER > http://patchwork.freedesktop.org/api/1.0/series/4713/revisions/1/mbox > / > > Test gem_exec_suspend: > Subgroup basic-s3: > pass -> DMESG-WARN (bsw-nuc-2) Unrelated, lockdep issue among ggtt_bind_vma/stop_machine, mmap, kernfs_fop_write, device_unregister: https://bugs.freedesktop.org/show_bug.cgi?id=94350 > Test kms_flip: > Subgroup basic-flip-vs-wf_vblank: > pass -> FAIL (ilk-hp8440p) UNSTABLE Unrelated, 1 frame long inter-vblank ts jitter with seq_step=10: https://bugs.freedesktop.org/show_bug.cgi?id=94294 > Subgroup basic-plain-flip: > pass -> DMESG-WARN (hsw-brixbox) Unrelated, watermark programming while device off, should be fixed now in -nightly. > dmesg-warn -> PASS (bdw-ultra) > Test kms_force_connector_basic: > Subgroup prune-stale-modes: > pass -> SKIP (ivb-t430s) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > dmesg-warn -> PASS (bsw-nuc-2) > Test pm_rpm: > Subgroup basic-pci-d3-state: > fail -> DMESG-FAIL (snb-x220t) > pass -> DMESG-WARN (snb-dellxps) Both of the above, the same watermark programming problem as above. > pass -> DMESG-WARN (bsw-nuc-2) Unrelated, unclaimed access prior to suspending, pm_rpm@basic-pci-d3-st ate: https://bugs.freedesktop.org/show_bug.cgi?id=94164 > Subgroup basic-rte: > dmesg-warn -> PASS (snb-x220t) > dmesg-warn -> PASS (byt-nuc) UNSTABLE Not on the above list, I don't know why: - igt@kms_flip@basic-flip-vs-dpms: FIFO underrun on ilk-hp8440p: Unrelated, https://bugs.freedesktop.org/show_bug.cgi?id=93787 I pushed the patch to -dinq, thanks for the review. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Gen8 Engine reset preparatory patches
Arun Siluvery writes: > [ text/plain ] > First batch of prep patches for Engine reset feature available from Gen8 > onwards. The reset code is recently prep'd to support this feature, now > others can follow now. > > Arun Siluvery (2): > drm/i915/tdr: Prepare error handler to accept mask of hung engines > drm/i915: Update i915.reset to handle engine resets > > Tomas Elf (1): > drm/i915/tdr: Initialize hangcheck struct for each engine > Patches 1/3 [v2] and 2/3 pushed. Thanks for patches and review. -Mika > drivers/gpu/drm/i915/i915_dma.c | 12 > drivers/gpu/drm/i915/i915_drv.h | 5 +++-- > drivers/gpu/drm/i915/i915_gpu_error.c | 8 > drivers/gpu/drm/i915/i915_irq.c | 16 > drivers/gpu/drm/i915/i915_params.c | 6 +++--- > drivers/gpu/drm/i915/i915_params.h | 2 +- > drivers/gpu/drm/i915/intel_lrc.c| 2 +- > drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++- > 8 files changed, 38 insertions(+), 20 deletions(-) > > -- > 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Wait until after wm optimization to drop runtime PM reference
On ti, 2016-03-08 at 09:26 -0800, Matt Roper wrote: > On Mon, Mar 07, 2016 at 11:47:51AM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Wait until after wm optimization to drop runtime > > PM reference > > URL : https://patchwork.freedesktop.org/series/4135/ > > State : failure > > > > == Summary == > > > > Series 4135v1 drm/i915: Wait until after wm optimization to drop > > runtime PM reference > > http://patchwork.freedesktop.org/api/1.0/series/4135/revisions/1/mb > > ox/ > > > > Test kms_flip: > > Subgroup basic-flip-vs-wf_vblank: > > fail -> PASS (bsw-nuc-2) > > Subgroup basic-plain-flip: > > dmesg-warn -> PASS (hsw-gt2) > > Test kms_force_connector_basic: > > Subgroup force-load-detect: > > pass -> SKIP (ivb-t430s) > > https://bugs.freedesktop.org/show_bug.cgi?id=93769 > > > Test kms_pipe_crc_basic: > > Subgroup read-crc-pipe-c: > > dmesg-warn -> PASS (hsw-gt2) > > Subgroup suspend-read-crc-pipe-a: > > dmesg-warn -> PASS (skl-i5k-2) > > skip -> PASS (hsw-brixbox) > > Subgroup suspend-read-crc-pipe-c: > > pass -> DMESG-WARN (bsw-nuc-2) > > https://bugs.freedesktop.org/show_bug.cgi?id=93294 > > > pass -> INCOMPLETE (hsw-gt2) > > Seems like the machine just died completely? No > stdout/stderr/command/dmesg output available from CI and time is > given > as 0:00:00. Doesn't seem like it could be related to this patch. > > > > Test pm_rpm: > > Subgroup basic-pci-d3-state: > > dmesg-warn -> PASS (snb-dellxps) > > Subgroup basic-rte: > > pass -> DMESG-WARN (bsw-nuc-2) > > https://bugs.freedesktop.org/show_bug.cgi?id=94164 > > > Matt Pushed to -dinq, thanks for the patch and the review. I had to rebase it on top of Ville's recent s/crtc_state/old_crtc_state/ change, please double check it. Jani, this is for -fixes. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915: Split PNV version of crtc_compute_clock()
On Mon, Mar 21, 2016 at 06:00:16PM +0200, Ander Conselvan de Oliveira wrote:
> Split a pnv_crtc_compute_clock(), so the differences between platforms
> become more obvious.
>
> With this, there are no more users of intel_limit() or the ->find_dpll()
> hook, so get rid of them.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 18 -
> drivers/gpu/drm/i915/intel_display.c | 134
> +--
> 2 files changed, 79 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index efca534..83ee8d7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -575,24 +575,6 @@ struct dpll;
> struct drm_i915_display_funcs {
> int (*get_display_clock_speed)(struct drm_device *dev);
> int (*get_fifo_size)(struct drm_device *dev, int plane);
> - /**
> - * find_dpll() - Find the best values for the PLL
> - * @limit: limits for the PLL
> - * @crtc: current CRTC
> - * @target: target frequency in kHz
> - * @refclk: reference clock frequency in kHz
> - * @match_clock: if provided, @best_clock P divider must
> - * match the P divider from @match_clock
> - * used for LVDS downclocking
> - * @best_clock: best PLL values found
> - *
> - * Returns true on success, false on failure.
> - */
> - bool (*find_dpll)(const struct intel_limit *limit,
> - struct intel_crtc_state *crtc_state,
> - int target, int refclk,
> - struct dpll *match_clock,
> - struct dpll *best_clock);
> int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
> int (*compute_intermediate_wm)(struct drm_device *dev,
> struct intel_crtc *intel_crtc,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 552fd4c..4d7c29a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -566,33 +566,6 @@ static bool intel_pipe_will_have_type(const struct
> intel_crtc_state *crtc_state,
> return false;
> }
>
> -static const intel_limit_t *
> -intel_limit(struct intel_crtc_state *crtc_state, int refclk)
> -{
> - struct drm_device *dev = crtc_state->base.crtc->dev;
> - const intel_limit_t *limit;
> -
> - if (IS_BROXTON(dev) || IS_CHERRYVIEW(dev) || IS_VALLEYVIEW(dev) ||
> - HAS_PCH_SPLIT(dev) || IS_G4X(dev) || IS_GEN2(dev))
> - limit = NULL;
> -
> - if (IS_PINEVIEW(dev)) {
> - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS))
> - limit = &intel_limits_pineview_lvds;
> - else
> - limit = &intel_limits_pineview_sdvo;
> - } else if (!IS_GEN2(dev)) {
> - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS))
> - limit = &intel_limits_i9xx_lvds;
> - else
> - limit = &intel_limits_i9xx_sdvo;
> - }
> -
> - WARN_ON(limit == NULL);
> -
> - return limit;
> -}
> -
> /*
> * Platform specific helpers to calculate the port PLL loopback- (clock.m),
> * and post-divider (clock.p) values, pre- (clock.vco) and post-divided fast
> @@ -723,6 +696,16 @@ i9xx_select_p2_div(const intel_limit_t *limit,
> }
> }
>
> +/*
> + * Returns a set of divisors for the desired target clock with the given
> + * refclk, or FALSE. The returned values represent the clock equation:
> + * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
> + *
> + * Target and reference clocks are specified in kHz.
> + *
> + * If match_clock is provided, then best_clock P divider must match the P
> + * divider from @match_clock used for LVDS downclocking.
> + */
> static bool
> i9xx_find_best_dpll(const intel_limit_t *limit,
> struct intel_crtc_state *crtc_state,
> @@ -770,6 +753,16 @@ i9xx_find_best_dpll(const intel_limit_t *limit,
> return (err != target);
> }
>
> +/*
> + * Returns a set of divisors for the desired target clock with the given
> + * refclk, or FALSE. The returned values represent the clock equation:
> + * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
> + *
> + * Target and reference clocks are specified in kHz.
> + *
> + * If match_clock is provided, then best_clock P divider must match the P
> + * divider from @match_clock used for LVDS downclocking.
> + */
> static bool
> pnv_find_best_dpll(const intel_limit_t *limit,
> struct intel_crtc_state *crtc_state,
> @@ -819,6 +812,11 @@ pnv_find_best_dpll(const intel_limit_t *limit,
> * Returns a set of divisors for the desired target clock with the given
> * refclk, or FALSE. The returned values represent the clock equation:
> * reflck * (5 * (m1 + 2)
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Reject non-canonical rotations
== Series Details == Series: drm/i915: Reject non-canonical rotations URL : https://patchwork.freedesktop.org/series/4746/ State : warning == Summary == Series 4746v1 drm/i915: Reject non-canonical rotations http://patchwork.freedesktop.org/api/1.0/series/4746/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Subgroup basic-plain-flip: pass -> DMESG-WARN (hsw-brixbox) dmesg-warn -> PASS (bdw-ultra) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: pass -> DMESG-WARN (snb-x220t) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (snb-x220t) dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:169 dwarn:1 dfail:0 fail:0 skip:22 ilk-hp8440p total:192 pass:129 dwarn:0 dfail:0 fail:0 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:156 dwarn:2 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:157 dwarn:1 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1673/ 4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: 2016y-03m-21d-18h-43m-18s UTC integration manifest 8fb43d81a892947726fdeff37e1ffbd524ab8154 drm/i915: Reject non-canonical rotations ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: Split g4x_crtc_compute_clock()
On Mon, Mar 21, 2016 at 06:00:15PM +0200, Ander Conselvan de Oliveira wrote:
> Split a G4X specific version from i9xx_crtc_compute_clock(). With this
> the differences between platforms become more obvious.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 82
> +++-
> 1 file changed, 53 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 245d6c6..552fd4c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -567,40 +567,16 @@ static bool intel_pipe_will_have_type(const struct
> intel_crtc_state *crtc_state,
> }
>
> static const intel_limit_t *
> -intel_g4x_limit(struct intel_crtc_state *crtc_state)
> -{
> - struct drm_device *dev = crtc_state->base.crtc->dev;
> - const intel_limit_t *limit;
> -
> - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
> - if (intel_is_dual_link_lvds(dev))
> - limit = &intel_limits_g4x_dual_channel_lvds;
> - else
> - limit = &intel_limits_g4x_single_channel_lvds;
> - } else if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_HDMI) ||
> -intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_ANALOG)) {
> - limit = &intel_limits_g4x_hdmi;
> - } else if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_SDVO)) {
> - limit = &intel_limits_g4x_sdvo;
> - } else /* The option is for other outputs */
> - limit = &intel_limits_i9xx_sdvo;
> -
> - return limit;
> -}
> -
> -static const intel_limit_t *
> intel_limit(struct intel_crtc_state *crtc_state, int refclk)
> {
> struct drm_device *dev = crtc_state->base.crtc->dev;
> const intel_limit_t *limit;
>
> if (IS_BROXTON(dev) || IS_CHERRYVIEW(dev) || IS_VALLEYVIEW(dev) ||
> - HAS_PCH_SPLIT(dev) || IS_GEN2(dev))
> + HAS_PCH_SPLIT(dev) || IS_G4X(dev) || IS_GEN2(dev))
> limit = NULL;
>
> - if (IS_G4X(dev)) {
> - limit = intel_g4x_limit(crtc_state);
> - } else if (IS_PINEVIEW(dev)) {
> + if (IS_PINEVIEW(dev)) {
> if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS))
> limit = &intel_limits_pineview_lvds;
> else
> @@ -7885,6 +7861,49 @@ static int gen2_crtc_compute_clock(struct intel_crtc
> *crtc,
> return 0;
> }
>
> +static int g4x_crtc_compute_clock(struct intel_crtc *crtc,
> + struct intel_crtc_state *crtc_state)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + const intel_limit_t *limit;
> + int refclk = 96000;
> +
> + memset(&crtc_state->dpll_hw_state, 0,
> +sizeof(crtc_state->dpll_hw_state));
> +
> + if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
> + if (intel_panel_use_ssc(dev_priv)) {
> + refclk = dev_priv->vbt.lvds_ssc_freq;
> + DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> refclk);
> + }
> +
> + if (intel_is_dual_link_lvds(dev))
> + limit = &intel_limits_g4x_dual_channel_lvds;
> + else
> + limit = &intel_limits_g4x_single_channel_lvds;
> + } else if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_HDMI) ||
> +intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_ANALOG)) {
> + limit = &intel_limits_g4x_hdmi;
> + } else if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_SDVO)) {
> + limit = &intel_limits_g4x_sdvo;
> + } else {
> + /* The option is for other outputs */
> + limit = &intel_limits_i9xx_sdvo;
> + }
> +
> + if (!crtc_state->clock_set &&
> + !g4x_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
> + refclk, NULL, &crtc_state->dpll)) {
> + DRM_ERROR("Couldn't find PLL settings for mode!\n");
> + return -EINVAL;
> + }
> +
> + i9xx_compute_dpll(crtc, crtc_state, NULL);
> +
> + return 0;
> +}
> +
> static int i9xx_crtc_compute_clock(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state)
> {
> @@ -14906,9 +14925,7 @@ static const struct drm_mode_config_funcs
> intel_mode_funcs = {
> */
> void intel_init_display_hooks(struct drm_i915_private *dev_priv)
> {
> - if (HAS_PCH_SPLIT(dev_priv) || IS_G4X(dev_priv))
> - dev_priv->display.find_dpll = g4x_find_best_dpll;
> - else if (IS_PINEVIEW(dev_priv))
> + if (IS_PINEVIEW(dev_priv))
> dev_priv->display.find_dpll = pnv_find_best_dpll;
> else
> dev_priv->display.find_dpll = i9xx_find_best_dpll;
>
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Merge ironlake_compute_clocks() and ironlake_crtc_compute_clock()
On Mon, Mar 21, 2016 at 06:00:12PM +0200, Ander Conselvan de Oliveira wrote:
> Merge ironlake_compute_clocks() into ironlake_crtc_compute_clock() so
> the clock computation logic is all in one place. The resulting function
> is still quite simple. Follow up patches will make the similar code for
> GMCH platforms look similar.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 86
> ++--
> 1 file changed, 33 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b6541a0..13b509e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -848,6 +848,11 @@ pnv_find_best_dpll(const intel_limit_t *limit,
> return (err != target);
> }
>
> +/*
> + * Returns a set of divisors for the desired target clock with the given
> + * refclk, or FALSE. The returned values represent the clock equation:
> + * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
> + */
> static bool
> g4x_find_best_dpll(const intel_limit_t *limit,
> struct intel_crtc_state *crtc_state,
> @@ -8756,55 +8761,6 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
> }
> }
>
> -static bool ironlake_compute_clocks(struct drm_crtc *crtc,
> - struct intel_crtc_state *crtc_state,
> - intel_clock_t *clock,
> - bool *has_reduced_clock,
> - intel_clock_t *reduced_clock)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - int refclk;
> - const intel_limit_t *limit;
> - bool ret;
> -
> - refclk = 12;
> -
> - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
> - if (intel_panel_use_ssc(dev_priv)) {
> - DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> - dev_priv->vbt.lvds_ssc_freq);
> - refclk = dev_priv->vbt.lvds_ssc_freq;
> - }
> -
> - if (intel_is_dual_link_lvds(dev)) {
> - if (refclk == 10)
> - limit = &intel_limits_ironlake_dual_lvds_100m;
> - else
> - limit = &intel_limits_ironlake_dual_lvds;
> - } else {
> - if (refclk == 10)
> - limit = &intel_limits_ironlake_single_lvds_100m;
> - else
> - limit = &intel_limits_ironlake_single_lvds;
> - }
> - } else {
> - limit = &intel_limits_ironlake_dac;
> - }
> -
> - /*
> - * Returns a set of divisors for the desired target clock with the given
> - * refclk, or FALSE. The returned values represent the clock equation:
> - * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
> - */
> - ret = g4x_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
> - refclk, NULL, clock);
> - if (!ret)
> - return false;
> -
> - return true;
> -}
> -
> int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp)
> {
> /*
> @@ -8929,9 +8885,13 @@ static void ironlake_compute_dpll(struct intel_crtc
> *intel_crtc,
> static int ironlake_crtc_compute_clock(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state)
> {
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> intel_clock_t reduced_clock;
> bool has_reduced_clock = false;
> struct intel_shared_dpll *pll;
> + const intel_limit_t *limit;
> + int refclk = 12;
>
> memset(&crtc_state->dpll_hw_state, 0,
> sizeof(crtc_state->dpll_hw_state));
> @@ -8942,11 +8902,31 @@ static int ironlake_crtc_compute_clock(struct
> intel_crtc *crtc,
> if (!crtc_state->has_pch_encoder)
> return 0;
>
> + if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
> + if (intel_panel_use_ssc(dev_priv)) {
> + DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> + dev_priv->vbt.lvds_ssc_freq);
> + refclk = dev_priv->vbt.lvds_ssc_freq;
> + }
> +
> + if (intel_is_dual_link_lvds(dev)) {
> + if (refclk == 10)
> + limit = &intel_limits_ironlake_dual_lvds_100m;
> + else
> + limit = &intel_limits_ironlake_dual_lvds;
> + } else {
> + if (refclk == 10)
> + limit = &intel_limits_ironlake_single_lvds_
Re: [Intel-gfx] [PATCH 10/15] drm/i915: Move fp divisor calculation into ironlake_compute_dpll()
On Mon, Mar 21, 2016 at 06:00:11PM +0200, Ander Conselvan de Oliveira wrote:
> Follow what is done in i8xx_compute_dpll() and i9xx_compute_dpll() and
> move the lower level details of setting crtc_state->dpll_hw_state into
> the _compute_dpll() function.
Missing sob.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 45
> ++--
> 1 file changed, 22 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0b6eabf..b6541a0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8821,10 +8821,9 @@ static bool ironlake_needs_fb_cb_tune(struct dpll
> *dpll, int factor)
> return i9xx_dpll_compute_m(dpll) < factor * dpll->n;
> }
>
> -static uint32_t ironlake_compute_dpll(struct intel_crtc *intel_crtc,
> - struct intel_crtc_state *crtc_state,
> - u32 *fp,
> - intel_clock_t *reduced_clock, u32 *fp2)
> +static void ironlake_compute_dpll(struct intel_crtc *intel_crtc,
> + struct intel_crtc_state *crtc_state,
> + intel_clock_t *reduced_clock)
> {
> struct drm_crtc *crtc = &intel_crtc->base;
> struct drm_device *dev = crtc->dev;
> @@ -8833,7 +8832,7 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc
> *intel_crtc,
> struct drm_connector *connector;
> struct drm_connector_state *connector_state;
> struct intel_encoder *encoder;
> - uint32_t dpll;
> + u32 dpll, fp, fp2;
> int factor, i;
> bool is_lvds = false, is_sdvo = false;
>
> @@ -8866,11 +8865,19 @@ static uint32_t ironlake_compute_dpll(struct
> intel_crtc *intel_crtc,
> } else if (crtc_state->sdvo_tv_clock)
> factor = 20;
>
> + fp = i9xx_dpll_compute_fp(&crtc_state->dpll);
> +
> if (ironlake_needs_fb_cb_tune(&crtc_state->dpll, factor))
> - *fp |= FP_CB_TUNE;
> + fp |= FP_CB_TUNE;
> +
> + if (reduced_clock) {
> + fp2 = i9xx_dpll_compute_fp(reduced_clock);
>
> - if (fp2 && (reduced_clock->m < factor * reduced_clock->n))
> - *fp2 |= FP_CB_TUNE;
> + if (reduced_clock->m < factor * reduced_clock->n)
> + fp2 |= FP_CB_TUNE;
> + } else {
> + fp2 = fp;
> + }
>
> dpll = 0;
>
> @@ -8912,14 +8919,17 @@ static uint32_t ironlake_compute_dpll(struct
> intel_crtc *intel_crtc,
> else
> dpll |= PLL_REF_INPUT_DREFCLK;
>
> - return dpll | DPLL_VCO_ENABLE;
> + dpll |= DPLL_VCO_ENABLE;
> +
> + crtc_state->dpll_hw_state.dpll = dpll;
> + crtc_state->dpll_hw_state.fp0 = fp;
> + crtc_state->dpll_hw_state.fp1 = fp2;
> }
>
> static int ironlake_crtc_compute_clock(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state)
> {
> intel_clock_t reduced_clock;
> - u32 dpll = 0, fp = 0, fp2 = 0;
> bool has_reduced_clock = false;
> struct intel_shared_dpll *pll;
>
> @@ -8941,19 +8951,8 @@ static int ironlake_crtc_compute_clock(struct
> intel_crtc *crtc,
> return -EINVAL;
> }
>
> - fp = i9xx_dpll_compute_fp(&crtc_state->dpll);
> - if (has_reduced_clock)
> - fp2 = i9xx_dpll_compute_fp(&reduced_clock);
> - else
> - fp2 = fp;
> -
> - dpll = ironlake_compute_dpll(crtc, crtc_state,
> - &fp, &reduced_clock,
> - has_reduced_clock ? &fp2 : NULL);
> -
> - crtc_state->dpll_hw_state.dpll = dpll;
> - crtc_state->dpll_hw_state.fp0 = fp;
> - crtc_state->dpll_hw_state.fp1 = fp2;
> + ironlake_compute_dpll(crtc, crtc_state,
> + has_reduced_clock ? &reduced_clock : NULL);
>
> pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
> if (pll == NULL) {
> --
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Initialize MIPI DSI for BXT (rev2)
== Series Details == Series: drm/i915/bxt: Initialize MIPI DSI for BXT (rev2) URL : https://patchwork.freedesktop.org/series/3522/ State : failure == Summary == Series 3522v2 drm/i915/bxt: Initialize MIPI DSI for BXT http://patchwork.freedesktop.org/api/1.0/series/3522/revisions/2/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-wf_vblank: pass -> DMESG-WARN (hsw-brixbox) Subgroup basic-plain-flip: dmesg-warn -> PASS (bdw-ultra) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: pass -> DMESG-WARN (snb-x220t) Test pm_rpm: Subgroup basic-pci-d3-state: fail -> DMESG-FAIL (snb-x220t) Subgroup basic-rte: dmesg-warn -> PASS (snb-x220t) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 hsw-brixbox total:192 pass:169 dwarn:1 dfail:0 fail:0 skip:22 ilk-hp8440p total:192 pass:129 dwarn:0 dfail:0 fail:0 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:157 dwarn:1 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:157 dwarn:1 dfail:1 fail:0 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1672/ 4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: 2016y-03m-21d-18h-43m-18s UTC integration manifest 370a68ac8bb2e8c1be065f71f3a61ca4a39b468a drm/i915/bxt: Initialize MIPI DSI for BXT ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/tdr: Prepare error handler to accept mask of hung engines
Arun Siluvery writes:
> [ text/plain ]
> In preparation for engine reset, the wedged argument of i915_handle_error()
> is extended to reflect as a mask of engines that are hung. This is further
> passed down to error state capture functions which are also updated.
>
> Engine reset recovery mechanism uses this mask and schedules recovery work
> for those particular engines.
>
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> Signed-off-by: Tomas Elf
> Signed-off-by: Arun Siluvery
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> drivers/gpu/drm/i915/i915_gpu_error.c | 8
> drivers/gpu/drm/i915/i915_irq.c | 16
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 549a232..49ac065 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2735,7 +2735,7 @@ bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port
> *port);
> /* i915_irq.c */
> void i915_queue_hangcheck(struct drm_device *dev);
> __printf(3, 4)
> -void i915_handle_error(struct drm_device *dev, bool wedged,
> +void i915_handle_error(struct drm_device *dev, u32 engine_mask,
> const char *fmt, ...);
>
> extern void intel_irq_init(struct drm_i915_private *dev_priv);
> @@ -3321,7 +3321,7 @@ static inline void i915_error_state_buf_release(
> {
> kfree(eb->buf);
> }
> -void i915_capture_error_state(struct drm_device *dev, bool wedge,
> +void i915_capture_error_state(struct drm_device *dev, u32 engine_mask,
> const char *error_msg);
> void i915_error_state_get(struct drm_device *dev,
> struct i915_error_state_file_priv *error_priv);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index db8600a..1f8ff06 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1301,7 +1301,7 @@ static void i915_capture_reg_state(struct
> drm_i915_private *dev_priv,
>
> static void i915_error_capture_msg(struct drm_device *dev,
> struct drm_i915_error_state *error,
> -bool wedged,
> +u32 engine_mask,
> const char *error_msg)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -1324,7 +1324,7 @@ static void i915_error_capture_msg(struct drm_device
> *dev,
> scnprintf(error->error_msg + len, sizeof(error->error_msg) - len,
> ", reason: %s, action: %s",
> error_msg,
> - wedged ? "reset" : "continue");
> + engine_mask ? "reset" : "continue");
> }
>
> static void i915_capture_gen_state(struct drm_i915_private *dev_priv,
> @@ -1347,7 +1347,7 @@ static void i915_capture_gen_state(struct
> drm_i915_private *dev_priv,
> * out a structure which becomes available in debugfs for user level tools
> * to pick up.
> */
> -void i915_capture_error_state(struct drm_device *dev, bool wedged,
> +void i915_capture_error_state(struct drm_device *dev, u32 engine_mask,
> const char *error_msg)
> {
> static bool warned;
> @@ -1375,7 +1375,7 @@ void i915_capture_error_state(struct drm_device *dev,
> bool wedged,
> error->overlay = intel_overlay_capture_error_state(dev);
> error->display = intel_display_capture_error_state(dev);
>
> - i915_error_capture_msg(dev, error, wedged, error_msg);
> + i915_error_capture_msg(dev, error, engine_mask, error_msg);
> DRM_INFO("%s\n", error->error_msg);
>
> spin_lock_irqsave(&dev_priv->gpu_error.lock, flags);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 8f3e330..a55a7cc 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2653,14 +2653,14 @@ static void i915_report_and_clear_eir(struct
> drm_device *dev)
> /**
> * i915_handle_error - handle a gpu error
> * @dev: drm device
> - *
> + * @engine_mask: mask representing engines that are hung
> * Do some basic checking of register state at error time and
> * dump it to the syslog. Also call i915_capture_error_state() to make
> * sure we get a record and make it available in debugfs. Fire a uevent
> * so userspace knows something bad happened (should trigger collection
> * of a ring dump etc.).
> */
> -void i915_handle_error(struct drm_device *dev, bool wedged,
> +void i915_handle_error(struct drm_device *dev, u32 engine_mask,
> const char *fmt, ...)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -2671,10 +2671,10 @@ void i915_handle_error(struct drm_device *dev, bool
> wedged,
> vscnprintf(error_msg, sizeof(error_msg), fmt, args);
> va_end(args);
>
> - i915_capture_error_state(dev, wedged, error_msg);
> + i
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/core: Do not preserve framebuffer on rmfb, v2.
== Series Details == Series: drm/core: Do not preserve framebuffer on rmfb, v2. URL : https://patchwork.freedesktop.org/series/4743/ State : failure == Summary == Series 4743v1 drm/core: Do not preserve framebuffer on rmfb, v2. http://patchwork.freedesktop.org/api/1.0/series/4743/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (byt-nuc) Subgroup basic-plain-flip: dmesg-warn -> PASS (bdw-ultra) Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (snb-x220t) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (snb-dellxps) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (snb-x220t) dmesg-warn -> PASS (snb-dellxps) dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:153 dwarn:2 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:155 dwarn:1 dfail:0 fail:1 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 ilk-hp8440p total:192 pass:129 dwarn:0 dfail:0 fail:0 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:157 dwarn:1 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:157 dwarn:1 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1671/ 4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: 2016y-03m-21d-18h-43m-18s UTC integration manifest 0584a277f33ed99384ba7395a504a778f827faf1 drm/core: Do not preserve framebuffer on rmfb, v2. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915: tidy up a few more references to engine[]
Now that we have a name for the previously anonymous per-engine structure
embedded inside the intel_context for the benefit of execlist mode, we
can optimise a few more places that access this array of structures.
This may improve the compiler's ability to avoid redundant dereference
and index operations.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 13 +
drivers/gpu/drm/i915/i915_guc_submission.c | 17 +
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ccdca2c..ce3b5e9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1966,16 +1966,13 @@ static int i915_context_status(struct seq_file *m, void
*unused)
if (i915.enable_execlists) {
seq_putc(m, '\n');
for_each_engine(engine, dev_priv, i) {
- struct drm_i915_gem_object *ctx_obj =
- ctx->engine[i].state;
- struct intel_ringbuffer *ringbuf =
- ctx->engine[i].ringbuf;
+ struct intel_engine_ctx *ectx = &ctx->engine[i];
seq_printf(m, "%s: ", engine->name);
- if (ctx_obj)
- describe_obj(m, ctx_obj);
- if (ringbuf)
- describe_ctx_ringbuf(m, ringbuf);
+ if (ectx->state)
+ describe_obj(m, ectx->state);
+ if (ectx->ringbuf)
+ describe_ctx_ringbuf(m, ectx->ringbuf);
seq_putc(m, '\n');
}
} else {
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ae1f58d..7352023 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -392,6 +392,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
for_each_engine(engine, dev_priv, i) {
struct guc_execlist_context *lrc = &desc.lrc[engine->guc_id];
+ struct intel_engine_ctx *ectx = &ctx->engine[i];
struct drm_i915_gem_object *obj;
uint64_t ctx_desc;
@@ -402,7 +403,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
* for now who owns a GuC client. But for future owner of GuC
* client, need to make sure lrc is pinned prior to enter here.
*/
- obj = ctx->engine[i].state;
+ obj = ectx->state;
if (!obj)
break; /* XXX: continue? */
@@ -415,7 +416,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
(engine->guc_id << GUC_ELC_ENGINE_OFFSET);
- obj = ctx->engine[i].ringbuf->obj;
+ obj = ectx->ringbuf->obj;
lrc->ring_begin = i915_gem_obj_ggtt_offset(obj);
lrc->ring_end = lrc->ring_begin + obj->base.size - 1;
@@ -987,19 +988,19 @@ int intel_guc_suspend(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = &dev_priv->guc;
- struct intel_context *ctx;
+ struct intel_engine_ctx *ectx;
u32 data[3];
if (!i915.enable_guc_submission)
return 0;
- ctx = dev_priv->kernel_context;
+ ectx = &dev_priv->kernel_context->engine[RCS];
data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
/* first page is shared data with GuC */
- data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+ data[2] = i915_gem_obj_ggtt_offset(ectx->state);
return host2guc_action(guc, data, ARRAY_SIZE(data));
}
@@ -1013,18 +1014,18 @@ int intel_guc_resume(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = &dev_priv->guc;
- struct intel_context *ctx;
+ struct intel_engine_ctx *ectx;
u32 data[3];
if (!i915.enable_guc_submission)
return 0;
- ctx = dev_priv->kernel_context;
+; ectx = &dev_priv->kernel_context->engine[RCS];
data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
/* first page is shared data with GuC */
- data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+ data[2] = i915_gem_obj_ggtt_offset(ectx->state);
return host2guc_action(guc, data, ARRAY_SIZE(data));
}
--
[Intel-gfx] [PATCH v3 1/2] drm/i915: name the anonymous per-engine context struct
Introduce a name for the previously anonymous per-engine structure
embedded inside the intel_context, and use local pointers to the
relevant element of this array to simplify various execlist functions.
This may improve the compiler's ability to avoid redundant dereference-
and index operations.
This version is derived from an original by Chris Wilson, detached
from the original set of patches in which it was posted and rebased
to current nightly.
Then it was updated by Tvrtko Ursulin ,
who noted:
This anonymous struct was causing a good amount of overly verbose
code. Also, if we name it and cache the pointer locally when there
are multiple accesses to it, not only the code is more readable,
but the compiler manages to generate smaller binary.
Along the way I also shortened access to dev_priv and eliminated some
unused variables and cached some where I spotted the opportunity.
This version uses the name "struct intel_engine_ctx" in accordance with
the English (and German) convention that the concrete noun goes at the
end of a noun-sequence, with earlier ones acting as adjectives i.e. an
"engine-context" is the context of an engine, whereas a "context-engine"
would be some sort of engine that processes contexts. Since object and
structure names are noun-like, it's more consistent to name them this way.
Originally-by: Chris Wilson
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 122 +++
2 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00c41a4..be3709f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -840,7 +840,7 @@ struct intel_context {
} legacy_hw_ctx;
/* Execlists */
- struct {
+ struct intel_engine_ctx {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
int pin_count;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f727822..a054a32 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -316,16 +316,16 @@ int intel_sanitize_enable_execlists(struct drm_device
*dev, int enable_execlists
intel_lr_context_descriptor_update(struct intel_context *ctx,
struct intel_engine_cs *engine)
{
+ struct intel_engine_ctx *ectx = &ctx->engine[engine->id];
uint64_t lrca, desc;
- lrca = ctx->engine[engine->id].lrc_vma->node.start +
- LRC_PPHWSP_PN * PAGE_SIZE;
+ lrca = ectx->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
- desc = engine->ctx_desc_template; /* bits
0-11 */
+ desc = engine->ctx_desc_template; /* bits 0-11 */
desc |= lrca; /* bits 12-31 */
desc |= (lrca >> PAGE_SHIFT) << GEN8_CTX_ID_SHIFT; /* bits 32-51 */
- ctx->engine[engine->id].lrc_desc = desc;
+ ectx->lrc_desc = desc;
}
uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
@@ -361,8 +361,7 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
{
struct intel_engine_cs *engine = rq0->engine;
- struct drm_device *dev = engine->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = rq0->i915;
uint64_t desc[2];
if (rq1) {
@@ -468,11 +467,8 @@ static void execlists_context_unqueue__locked(struct
intel_engine_cs *engine)
* resubmit the request. See gen8_emit_request() for where we
* prepare the padding after the end of the request.
*/
- struct intel_ringbuffer *ringbuf;
-
- ringbuf = req0->ctx->engine[engine->id].ringbuf;
req0->tail += 8;
- req0->tail &= ringbuf->size - 1;
+ req0->tail &= req0->ringbuf->size - 1;
}
execlists_submit_requests(req0, req1);
@@ -669,7 +665,8 @@ static int logical_ring_invalidate_all_caches(struct
drm_i915_gem_request *req)
static int execlists_move_to_gpu(struct drm_i915_gem_request *req,
struct list_head *vmas)
{
- const unsigned other_rings = ~intel_engine_flag(req->engine);
+ struct intel_engine_cs *engine = req->engine;
+ const unsigned other_rings = ~intel_engine_flag(engine);
struct i915_vma *vma;
uint32_t flush_domains = 0;
bool flush_chipset = false;
@@ -679,7 +676,7 @@ static int execlists_move_to_gpu(struct
drm_i915_gem_request *req,
struct drm_i915_gem_object *obj = vma->obj;
if (obj->active & other_rings) {
- ret = i915_gem_object_sync(obj, req->engine, &req);
+
[Intel-gfx] [PATCH igt] lib: Add a GPU error detector
If we listen to the uevents from the kernel, we can detect when the GPU
hangs. This requires us to fork a helper process to do so and send a
signal back to the parent.
Signed-off-by: Chris Wilson
---
benchmarks/Makefile.am | 2 +-
debugger/Makefile.am | 2 +-
demos/Makefile.am| 2 +-
lib/Makefile.am | 12 +--
lib/igt_aux.c| 82
lib/igt_aux.h| 3 ++
tests/Makefile.am| 3 +-
tests/gem_exec_whisper.c | 4 +++
tools/Makefile.am| 2 +-
9 files changed, 104 insertions(+), 8 deletions(-)
diff --git a/benchmarks/Makefile.am b/benchmarks/Makefile.am
index c67f472..2c2d100 100644
--- a/benchmarks/Makefile.am
+++ b/benchmarks/Makefile.am
@@ -3,7 +3,7 @@ include Makefile.sources
AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/lib
AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(CAIRO_CFLAGS) $(LIBUNWIND_CFLAGS)
-LDADD = $(top_builddir)/lib/libintel_tools.la $(DRM_LIBS) $(PCIACCESS_LIBS)
$(CAIRO_LIBS) $(LIBUNWIND_LIBS) $(TIMER_LIBS) -lm
+LDADD = $(top_builddir)/lib/libintel_tools.la
benchmarks_LTLIBRARIES = gem_exec_tracer.la
gem_exec_tracer_la_LDFLAGS = -module -avoid-version -no-undefined
diff --git a/debugger/Makefile.am b/debugger/Makefile.am
index 5a523f5..9d231d3 100644
--- a/debugger/Makefile.am
+++ b/debugger/Makefile.am
@@ -15,4 +15,4 @@ AM_CFLAGS = \
$(LIBUNWIND_CFLAGS) \
$(CWARNFLAGS)
-LDADD = $(top_builddir)/lib/libintel_tools.la $(DRM_LIBS) $(PCIACCESS_LIBS)
$(CAIRO_LIBS) $(LIBUNWIND_LIBS) $(TIMER_LIBS)
+LDADD = $(top_builddir)/lib/libintel_tools.la
diff --git a/demos/Makefile.am b/demos/Makefile.am
index d18a705..e6fbb3b 100644
--- a/demos/Makefile.am
+++ b/demos/Makefile.am
@@ -4,4 +4,4 @@ bin_PROGRAMS = \
AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/lib
AM_CFLAGS = $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS) $(CAIRO_CFLAGS)
$(LIBUNWIND_CFLAGS)
-LDADD = $(top_builddir)/lib/libintel_tools.la $(DRM_LIBS) $(PCIACCESS_LIBS)
$(CAIRO_LIBS) $(LIBUNWIND_LIBS) $(TIMER_LIBS)
+LDADD = $(top_builddir)/lib/libintel_tools.la
diff --git a/lib/Makefile.am b/lib/Makefile.am
index a8a1eb6..d2f2e16 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -15,12 +15,20 @@ if HAVE_VC4
endif
AM_CPPFLAGS = -I$(top_srcdir)
-AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(LIBUNWIND_CFLAGS) $(DEBUG_CFLAGS) \
+AM_CFLAGS = $(CWARNFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS)
$(LIBUNWIND_CFLAGS) $(DEBUG_CFLAGS) \
-DIGT_SRCDIR=\""$(abs_top_srcdir)/tests"\" \
-DIGT_DATADIR=\""$(pkgdatadir)"\" \
-DIGT_LOG_DOMAIN=\""$(subst _,-,$*)"\" \
-pthread
-LDADD = $(CAIRO_LIBS) $(LIBUNWIND_LIBS) $(TIMER_LIBS) -lm
AM_CFLAGS += $(CAIRO_CFLAGS)
+libintel_tools_la_LIBADD = \
+ $(DRM_LIBS) \
+ $(PCIACCESS_LIBS) \
+ $(CAIRO_LIBS) \
+ $(LIBUDEV_LIBS) \
+ $(LIBUNWIND_LIBS) \
+ $(TIMER_LIBS) \
+ -lm
+
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 7deaf2f..d8f72fb 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -360,6 +361,87 @@ void igt_stop_signal_helper(void)
sig_stat = 0;
}
+#if HAVE_UDEV
+#include
+
+static struct igt_helper_process hang_detector;
+static void __attribute__((noreturn))
+hang_detector_process(pid_t pid, dev_t rdev)
+{
+ struct udev_monitor *mon =
+ udev_monitor_new_from_netlink(udev_new(), "kernel");
+ struct pollfd pfd;
+
+ udev_monitor_filter_add_match_subsystem_devtype(mon, "drm", NULL);
+ udev_monitor_enable_receiving(mon);
+
+ pfd.fd = udev_monitor_get_fd(mon);
+ pfd.events = POLLIN;
+
+ while (poll(&pfd, 1, -1) > 0) {
+ struct udev_device *dev = udev_monitor_receive_device(mon);
+ dev_t devnum;
+
+ if (dev == NULL)
+ break;
+
+ devnum = udev_device_get_devnum(dev);
+ if (memcmp(&rdev, &devnum, sizeof(dev_t)) == 0) {
+ const char *str;
+
+ str = udev_device_get_property_value(dev, "ERROR");
+ if (str && atoi(str) == 1)
+ kill(pid, SIGRTMAX);
+ }
+
+ udev_device_unref(dev);
+ if (kill(pid, 0)) /* Parent has died, so must we. */
+ break;
+ }
+
+ exit(0);
+}
+
+static void sig_abort(int sig)
+{
+ igt_assert(!"GPU hung");
+}
+
+void igt_fork_hang_detector(int fd)
+{
+ struct stat st;
+
+ if (igt_only_list_subtests())
+ return;
+
+ igt_assert(fstat(fd, &st) == 0);
+
+ signal(SIGRTMAX, sig_abort);
+ igt_fork_helper(&hang_detector)
+ hang_detector_process(getppid(), st.st_rdev);
+}
+
+void igt_stop_hang_detector(void)
+{
+ if (igt_only_list_subtests())
+
Re: [Intel-gfx] [PATCH v2] drm/i915: Name the anonymous per-engine context struct
On 22/03/16 11:20, Dave Gordon wrote:
On 22/03/16 09:28, Chris Wilson wrote:
On Mon, Mar 21, 2016 at 03:23:57PM +, Dave Gordon wrote:
On 18/03/16 17:26, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This anonymous struct was causing a good amount of overly
verbose code. Also, if we name it and cache the pointer locally
when there are multiple accesses to it, not only the code is
more readable, but the compiler manages to generate smaller
binary.
Along the way I also shortened access to dev_priv and eliminated
some unused variables and cached some where I spotted the
opportunity.
Name for the structure, intel_context_engine, and the local
variable name were borrowed from a similar patch by Chris Wilson.
v2: Hate the engine->dev surprises, really do.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 94
+---
2 files changed, 50 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 00c41a4bde2a..480639c39543 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -840,7 +840,7 @@ struct intel_context {
} legacy_hw_ctx;
/* Execlists */
-struct {
+struct intel_context_engine {
Good idea, I had a version of this too, derived from Chris' patch
[157/190] drm/i915: Tidy execlists by using intel_context_engine locals.
The only thing to disagree with is the actual name; it should be
"intel_engine_context" (or some abbreviation thereof), because in
We have been using object_subobject.
-Chris
No we haven't. Examples of the above convention for structs include:
* "struct intel_device_info" - information about an intel device
* "struct i915_ctx_hang_stats" - statistics about hangs, per context
* "struct intel_uncore_funcs" - functions exported from uncore
* "struct i915_power_well_ops" - operations on power wells
* "struct i915_suspend_saved_registers" - registers saved at suspend
and for instance names:
* "struct list_head request_list" - a list of requests
* "struct i915_vma *lrc_vma" - the VMA for an LRC
* "uint32_t *lrc_reg_state" - the state of the registers in an LRC
Indeed it's quite difficult to find any compound names that do *not*
follow this convention. Maybe your version would be more natural in a
language where adjectives (or possessives) normally follow the noun they
describe?
One example is maybe:
struct drm_i915_error_state {
struct drm_i915_error_ring
So per-ring state of the total error state, which sounds equivalent to
per-engine state of a context.
Or:
struct intel_fbc {
struct intel_fbc_state_cache {
More verbose version like "struct intel_context_engine_state"?
"struct intel_engine_context" reads like a context of an engine to me,
which sounds opposite to what it should be - state of an engine for a
context.
?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC xf86-video-intel] sna: Call dirtyfb for all non-tear-free cases
On Tue, Mar 22, 2016 at 12:31:09PM +0100, Daniel Vetter wrote: > On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote: > > The sna_mode_wants_tear_free() function tries to detect FBC and PSR > > based on Kernel module parameters. Currently it fails to detect FBC > > due to the default enable_fbc value being -1. While this can easily be > > fixed in the Kernel, I had a conversation with Daniel and he expressed > > unhappiness with that solution, claiming that yet another different > > code path just for a feature that should be transparent is not a good > > way to go, and that we should do proper frontbuffer rendering. > > > > So with this patch, we'll have the DDX issuing dirtyfb calls even if > > TearFree is not enabled, fixing FBC when i915.enable_fbc=-1. > > > > This fixes a bug that happens on SKL with FBC enabled: if you run > > lightdm, your login/password won't appear as you type on your > > keyboard. You have to move the mouse over the input box for them to be > > displayed. > > > > Cc: Chris Wilson > > Signed-off-by: Paulo Zanoni > > I thought we need this anyway to get the kernel to allow fbc, since SNA > ends up mmap some of the drm_framebuffer. Even when they're not > frontbuffers. Nope. FBC => sna_mode_wants_tear_free() is true. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject non-canonical rotations
On Tue, Mar 22, 2016 at 12:59:19PM +0200, Ville Syrjälä wrote: > On Tue, Mar 22, 2016 at 10:48:41AM +, Matthew Auld wrote: > > As in the drm core? Not as far as I could tell... > > A good time to add it then I guess ;) I thought we do normalize this somewhere. In other words your static code analyser didn't read the code well enough probably ;-) On that topic: Your patch lacks motivation. Yes I can usually guess when it's due to static analyzer checks, but you need to explain that. And you need to explain what exactly the analyzer is complaining about. There's some conflicting opinions about whether you're allowed to name the tool itself, I personally don't care much but would appreciate those details too. But the details of what the static analyzer discovered and _must_ be in the commit message. Otherwise no way to review whether your patch fixes the problem in a reasonable way. This means please resend your entire pile of recent submission. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC xf86-video-intel] sna: Call dirtyfb for all non-tear-free cases
On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote: > The sna_mode_wants_tear_free() function tries to detect FBC and PSR > based on Kernel module parameters. Currently it fails to detect FBC > due to the default enable_fbc value being -1. While this can easily be > fixed in the Kernel, I had a conversation with Daniel and he expressed > unhappiness with that solution, claiming that yet another different > code path just for a feature that should be transparent is not a good > way to go, and that we should do proper frontbuffer rendering. > > So with this patch, we'll have the DDX issuing dirtyfb calls even if > TearFree is not enabled, fixing FBC when i915.enable_fbc=-1. > > This fixes a bug that happens on SKL with FBC enabled: if you run > lightdm, your login/password won't appear as you type on your > keyboard. You have to move the mouse over the input box for them to be > displayed. > > Cc: Chris Wilson > Signed-off-by: Paulo Zanoni I thought we need this anyway to get the kernel to allow fbc, since SNA ends up mmap some of the drm_framebuffer. Even when they're not frontbuffers. -Daniel > --- > src/sna/sna_driver.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c > index b245594..84e8e55 100644 > --- a/src/sna/sna_driver.c > +++ b/src/sna/sna_driver.c > @@ -654,7 +654,7 @@ static Bool sna_pre_init(ScrnInfoPtr scrn, int probe) > } > scrn->currentMode = scrn->modes; > > - if (!setup_tear_free(sna) && sna_mode_wants_tear_free(sna)) > + if (!setup_tear_free(sna)) > sna->kgem.needs_dirtyfb = sna->kgem.has_dirtyfb; > > xf86SetGamma(scrn, zeros); > -- > 2.7.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC
On Mon, Mar 21, 2016 at 04:26:57PM -0300, Paulo Zanoni wrote:
> FBC and the frontbuffer tracking infrastructure were designed assuming
> that user space applications would follow a specific set of rules
> regarding frontbuffer management and mmapping. I recently discovered
> that current user space is not exactly following these rules: my
> investigation led me to the conclusion that the generic backend from
> SNA - used by SKL and the other new platforms without a specific
> backend - is not issuing sw_finish/dirty_fb IOCTLs when using the CPU
> and WC mmaps. I discovered this when running lightdm: I would type the
> password and nothing would appear on the screen unless I moved the
> mouse over the place where the letters were supposed to appear.
>
> Since we can't detect whether the current DRM master is a well-behaved
> application or not, let's use the sledgehammer approach and assume
> that every user space client on every gen is bad by disabling FBC when
> the frontbuffer is CPU/WC mmapped. This will allow us to enable FBC
> on SKL, moving its FBC-related power savings from "always 0%" to "> 0%
> in some cases".
>
> There's also some additional code to disable the workaround for
> frontbuffers that ever received a sw_finish or dirty_fb IOCTL, since
> the current bad user space never issues those calls. This should help
> for some specific cases and our IGT tests, but won't be enough for a
> new xf86-video-intel using TearFree.
>
> Notice that we may need an equivalent commit for PSR too. We also need
> to investigate whether PSR needs to be disabled on GTT mmaps: if
> that's the case, we'll have problems since we seem to always have GTT
> mmaps on our current user space, so we would end up keeping PSR
> disabled forever.
>
> v2:
> - Rename some things.
> - Disable the WA on sw_finish/dirty_fb (Daniel).
> - Fix NULL obj checking.
> - Restric to Gen 9.
>
> Cc: Rodrigo Vivi
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 +
> drivers/gpu/drm/i915/i915_gem.c | 19 +++---
> drivers/gpu/drm/i915/intel_display.c | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_fbc.c | 33
>
> drivers/gpu/drm/i915/intel_frontbuffer.c | 31 ++
> 6 files changed, 89 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index efca534..45e31d2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -873,6 +873,13 @@ enum fb_op_origin {
> ORIGIN_DIRTYFB,
> };
>
> +enum fb_mmap_wa_flags {
> + FB_MMAP_WA_CPU =1 << 0,
> + FB_MMAP_WA_GTT =1 << 1,
> + FB_MMAP_WA_DISABLE =1 << 2,
> + FB_MMAP_WA_FLAG_COUNT = 3,
> +};
> +
> struct intel_fbc {
> /* This is always the inner lock when overlapping with struct_mutex and
>* it's the outer lock when overlapping with stolen_lock. */
> @@ -910,6 +917,7 @@ struct intel_fbc {
> unsigned int stride;
> int fence_reg;
> unsigned int tiling_mode;
> + unsigned int mmap_wa_flags;
> } fb;
> } state_cache;
>
> @@ -2143,6 +2151,7 @@ struct drm_i915_gem_object {
> unsigned int cache_dirty:1;
>
> unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
> + unsigned int fb_mmap_wa_flags:FB_MMAP_WA_FLAG_COUNT;
>
> unsigned int pin_display;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8588c83..d44f27e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1692,6 +1692,8 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void
> *data,
> goto unlock;
> }
>
> + intel_fb_obj_mmap_wa(obj, FB_MMAP_WA_DISABLE);
> +
> /* Pinned buffers may be scanout, so flush the cache */
> if (obj->pin_display)
> i915_gem_object_flush_cpu_write_domain(obj);
> @@ -1724,7 +1726,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> struct drm_i915_gem_mmap *args = data;
> - struct drm_gem_object *obj;
> + struct drm_i915_gem_object *obj;
> unsigned long addr;
>
> if (args->flags & ~(I915_MMAP_WC))
> @@ -1733,19 +1735,19 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void
> *data,
> if (args->flags & I915_MMAP_WC && !cpu_has_pat)
> return -ENODEV;
>
> - obj = drm_gem_object_lookup(dev, file, args->handle);
> - if (obj == NULL)
> + obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
> + if (&obj->base == NULL)
> return -ENOENT;
>
> /* prime objects have no backing filp to GEM mmap
>* pages from.
>*/
> - if
Re: [Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb.
Op 22-03-16 om 12:09 schreef Daniel Vetter:
> On Tue, Mar 22, 2016 at 11:53:53AM +0100, Maarten Lankhorst wrote:
>> Op 22-03-16 om 11:50 schreef Daniel Vetter:
>>> On Tue, Mar 22, 2016 at 10:32:32AM +0100, Maarten Lankhorst wrote:
Op 21-03-16 om 18:37 schreef Daniel Vetter:
> On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote:
>> It turns out that preserving framebuffers after the rmfb call breaks
>> vmwgfx userspace. This was originally introduced because it was thought
>> nobody relied on the behavior, but unfortunately it seems there are
>> exceptions.
>>
>> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
>> is impossible. There is no way to remove the framebuffer from the lists
>> and active planes without introducing a race because of the different
>> locking requirements. Instead call drm_framebuffer_remove from a
>> workqueue, which is unaffected by signals.
>>
>> Cc: sta...@vger.kernel.org #v4.4+
>> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing
>> it.")
>> Testcase: kms_flip.flip-vs-rmfb-interruptible
>> References:
>> https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
>> Cc: Thomas Hellstrom
>> Cc: David Herrmann
>> ---
>> drivers/gpu/drm/drm_crtc.c | 20 +++-
>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index e08f962288d9..b7d0b959f088 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
>> return 0;
>> }
>>
>> +struct drm_mode_rmfb_work {
>> + struct work_struct work;
>> + struct drm_framebuffer *fb;
>> +};
>> +
>> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
>> +{
>> + struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
>> +
>> + drm_framebuffer_remove(arg->fb);
> drm_framebuffer_remove still has the problem of not working correctly with
> atomic since atomic commit will complain if we try to do more than 1
> commit per ww_acquire_ctx. I think we still need an atomic version of
> this. Also probably a more nasty igt testcase which uses the same fb on
> more than one plane to be able to hit this case.
That's true, but a separate bug. :)
>>> Atm we only use drm_framebuffer_remove in atomic drivers to nuke the fbdev
>>> one at unload. With your patch userspace can't get there easily, and hence
>>> it must be fixed. Maybe separate prep patch (also cc: stable) upfront?
>>>
>> Something like this?
>>
>> Unfortunately I need to collect acks first.
> Oh dear, we're back to that discussion about how to pull this off :( I
> forgot about all that, silly me ...
>
> For a much more minimal fix, what about a default rmfb helper which
> implements the right thing automatically depending upon DRIVER_ATOMIC,
> plus the hook only for i915 to get atomic behaviour? With that we only
> need ack for drm core + i915, which we can get fast ;-)
>
> Would then also mean that drm_atomic_remove_framebuffer() would need to be
> in drm_atomic.c probably, so that drm_crtc.c can call it.
>
> if (dev->driver->remove_fb)
> ret = dev->driver->remove_fb(fb);
> else if (drm_core_check_feature(dev, DRIVER_ATOMIC))
> ret = drm_atomic_remove_fb(fb);
> else
> ret = legacy_remove_fb(fb);
>
> Besides this, need some minimal kerneldoc from
> drm_atomic_remove_framebuffer().
>
Would work, also means less cruft. :) After i915 is converted it could go away..
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Name the anonymous per-engine context struct
On 22/03/16 09:28, Chris Wilson wrote:
On Mon, Mar 21, 2016 at 03:23:57PM +, Dave Gordon wrote:
On 18/03/16 17:26, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This anonymous struct was causing a good amount of overly
verbose code. Also, if we name it and cache the pointer locally
when there are multiple accesses to it, not only the code is
more readable, but the compiler manages to generate smaller
binary.
Along the way I also shortened access to dev_priv and eliminated
some unused variables and cached some where I spotted the
opportunity.
Name for the structure, intel_context_engine, and the local
variable name were borrowed from a similar patch by Chris Wilson.
v2: Hate the engine->dev surprises, really do.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 94 +---
2 files changed, 50 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00c41a4bde2a..480639c39543 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -840,7 +840,7 @@ struct intel_context {
} legacy_hw_ctx;
/* Execlists */
- struct {
+ struct intel_context_engine {
Good idea, I had a version of this too, derived from Chris' patch
[157/190] drm/i915: Tidy execlists by using intel_context_engine locals.
The only thing to disagree with is the actual name; it should be
"intel_engine_context" (or some abbreviation thereof), because in
We have been using object_subobject.
-Chris
No we haven't. Examples of the above convention for structs include:
* "struct intel_device_info" - information about an intel device
* "struct i915_ctx_hang_stats" - statistics about hangs, per context
* "struct intel_uncore_funcs" - functions exported from uncore
* "struct i915_power_well_ops" - operations on power wells
* "struct i915_suspend_saved_registers" - registers saved at suspend
and for instance names:
* "struct list_head request_list" - a list of requests
* "struct i915_vma *lrc_vma" - the VMA for an LRC
* "uint32_t *lrc_reg_state" - the state of the registers in an LRC
Indeed it's quite difficult to find any compound names that do *not*
follow this convention. Maybe your version would be more natural in a
language where adjectives (or possessives) normally follow the noun they
describe?
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/fbc: enable FBC on SKL too
On Mon, Mar 21, 2016 at 04:26:58PM -0300, Paulo Zanoni wrote:
> Now that we're more protected against user space doing frontbuffer
> mmap rendering, the last - how many times did I say this before? -
> SKL problem seems to be solved. So let's give it a try.
>
> If you reached this commit through git bisect or if you just want more
> information about FBC, please see:
> commit a98ee79317b4091cafb502b4ffdbbbe1335e298c
> Author: Paulo Zanoni
> Date: Tue Feb 16 18:47:21 2016 -0200
> drm/i915/fbc: enable FBC by default on HSW and BDW
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 718ac38..67f8810 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1270,7 +1270,8 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
>* know what's going on. */
> if (i915.enable_fbc < 0) {
> i915.enable_fbc = IS_HASWELL(dev_priv) ||
> - IS_BROADWELL(dev_priv);
> + IS_BROADWELL(dev_priv) ||
> + IS_SKYLAKE(dev_priv);
Can we just future-proof this and enable on everything gen8+ where we have
fbc? Apparently bsw/bxt simply lack this ...
-Daniel
> DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
> i915.enable_fbc);
> }
> --
> 2.7.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC
On Tue, Mar 22, 2016 at 12:28:20PM +0200, Jani Nikula wrote:
> On Mon, 21 Mar 2016, Paulo Zanoni wrote:
> > +enum fb_mmap_wa_flags {
> > + FB_MMAP_WA_CPU =1 << 0,
> > + FB_MMAP_WA_GTT =1 << 1,
> > + FB_MMAP_WA_DISABLE =1 << 2,
> > + FB_MMAP_WA_FLAG_COUNT = 3,
> > +};
>
> Drive-by review, adding bit flags as enums doesn't feel like what enums
> should be used for. I'd go for macros instead.
Pretty established convention, some like it since it allows gdb&friends to
decode your bitflags for you. So abusing enums as flag set is imo ok.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbc: update busy_bits even for GTT and flip flushes
On Mon, Mar 21, 2016 at 04:26:54PM -0300, Paulo Zanoni wrote:
> We ignore ORIGIN_GTT because the hardware tracking can recognize GTT
> writes and take care of them. We also ignore ORIGIN_FLIP because we
> deal with flips without relying on the frontbuffer tracking
> infrastructure. On the other hand, a flush is a flush and means we're
> good to go, so we need to update busy_bits in order to reflect that,
> even if we're not going to do anything else about it.
>
> How to reproduce the bug fixed by this patch:
> - boot SKL up to the desktop environment
> - stop the display manager
> - run any of the igt/kms_frontbuffer_tracking/*fbc*onoff* subtests
> - the tests will fail
>
> The steps above will create the right conditions for us to lose track
> of busy_bits. If you, for example, run the full set of FBC tests, the
> onoff subtests will succeed.
>
> Also notice that the "bug" is that we'll just keep FBC disabled on
> cases where it could be enabled, so it's not something the users can
> perceive, it just affects power consumption numbers on properly
> configured machines.
>
> Signed-off-by: Paulo Zanoni
Is this covered by your nasty igt test suite? Kernel side looks good, so
with appropriate Testcase: tag added:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 2e571f5..b8ba79c 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -996,13 +996,13 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
> if (!fbc_supported(dev_priv))
> return;
>
> - if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
> - return;
> -
> mutex_lock(&fbc->lock);
>
> fbc->busy_bits &= ~frontbuffer_bits;
>
> + if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
> + goto out;
> +
> if (!fbc->busy_bits && fbc->enabled &&
> (frontbuffer_bits & intel_fbc_get_frontbuffer_bit(fbc))) {
> if (fbc->active)
> @@ -1011,6 +1011,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
> __intel_fbc_post_update(fbc->crtc);
> }
>
> +out:
> mutex_unlock(&fbc->lock);
> }
>
> --
> 2.7.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] drm/i915: Split gen2_crtc_compute_clock()
On Tue, Mar 22, 2016 at 12:24:27PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 21, 2016 at 06:00:14PM +0200, Ander Conselvan de Oliveira wrote:
> > Split a GEN2 specific version from i9xx_crtc_compute_clock(). With this
> > there is no need for i9xx_get_refclk() anymore, and the differences
> > between platforms become more obvious.
> >
> > Signed-off-by: Ander Conselvan de Oliveira
> >
>
> Let's call it i8xx shall we. That's the more typical convention in the
> modeset code.
Yeah, wanted to drop the same bikeshed - genX is generally what we use for
render side stuff, whereas product names are more used for modeset, simply
because that tends to be the splits along which IP blocks are reused.
-Daniel
>
> Otherwise looks OK, so with that
> Reviewed-by: Ville Syrjälä
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 91
> > +---
> > 1 file changed, 53 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index dca5b15..245d6c6 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -595,7 +595,7 @@ intel_limit(struct intel_crtc_state *crtc_state, int
> > refclk)
> > const intel_limit_t *limit;
> >
> > if (IS_BROXTON(dev) || IS_CHERRYVIEW(dev) || IS_VALLEYVIEW(dev) ||
> > - HAS_PCH_SPLIT(dev))
> > + HAS_PCH_SPLIT(dev) || IS_GEN2(dev))
> > limit = NULL;
> >
> > if (IS_G4X(dev)) {
> > @@ -610,13 +610,6 @@ intel_limit(struct intel_crtc_state *crtc_state, int
> > refclk)
> > limit = &intel_limits_i9xx_lvds;
> > else
> > limit = &intel_limits_i9xx_sdvo;
> > - } else {
> > - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS))
> > - limit = &intel_limits_i8xx_lvds;
> > - else if (intel_pipe_will_have_type(crtc_state,
> > INTEL_OUTPUT_DVO))
> > - limit = &intel_limits_i8xx_dvo;
> > - else
> > - limit = &intel_limits_i8xx_dac;
> > }
> >
> > WARN_ON(limit == NULL);
> > @@ -7102,27 +7095,6 @@ static inline bool intel_panel_use_ssc(struct
> > drm_i915_private *dev_priv)
> > && !(dev_priv->quirks & QUIRK_LVDS_SSC_DISABLE);
> > }
> >
> > -static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state)
> > -{
> > - struct drm_device *dev = crtc_state->base.crtc->dev;
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - int refclk;
> > -
> > - WARN_ON(!crtc_state->base.state);
> > -
> > - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> > - intel_panel_use_ssc(dev_priv)) {
> > - refclk = dev_priv->vbt.lvds_ssc_freq;
> > - DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n", refclk);
> > - } else if (!IS_GEN2(dev)) {
> > - refclk = 96000;
> > - } else {
> > - refclk = 48000;
> > - }
> > -
> > - return refclk;
> > -}
> > -
> > static uint32_t pnv_dpll_compute_fp(struct dpll *dpll)
> > {
> > return (1 << dpll->n) << 16 | dpll->m2;
> > @@ -7877,14 +7849,50 @@ static void i9xx_set_pipeconf(struct intel_crtc
> > *intel_crtc)
> > POSTING_READ(PIPECONF(intel_crtc->pipe));
> > }
> >
> > +static int gen2_crtc_compute_clock(struct intel_crtc *crtc,
> > + struct intel_crtc_state *crtc_state)
> > +{
> > + struct drm_device *dev = crtc->base.dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + const intel_limit_t *limit;
> > + int refclk = 48000;
> > +
> > + memset(&crtc_state->dpll_hw_state, 0,
> > + sizeof(crtc_state->dpll_hw_state));
> > +
> > + if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
> > + if (intel_panel_use_ssc(dev_priv)) {
> > + refclk = dev_priv->vbt.lvds_ssc_freq;
> > + DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> > refclk);
> > + }
> > +
> > + limit = &intel_limits_i8xx_lvds;
> > + } else if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_DVO)) {
> > + limit = &intel_limits_i8xx_dvo;
> > + } else {
> > + limit = &intel_limits_i8xx_dac;
> > + }
> > +
> > + if (!crtc_state->clock_set &&
> > + !i9xx_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
> > +refclk, NULL, &crtc_state->dpll)) {
> > + DRM_ERROR("Couldn't find PLL settings for mode!\n");
> > + return -EINVAL;
> > + }
> > +
> > + i8xx_compute_dpll(crtc, crtc_state, NULL);
> > +
> > + return 0;
> > +}
> > +
> > static int i9xx_crtc_compute_clock(struct intel_crtc *crtc,
> >struct intel_crtc_state *crtc_state)
> > {
> > struct drm_device *dev = crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > - int refclk;
> > bool ok;
> > const
Re: [Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb.
On Tue, Mar 22, 2016 at 11:53:53AM +0100, Maarten Lankhorst wrote:
> Op 22-03-16 om 11:50 schreef Daniel Vetter:
> > On Tue, Mar 22, 2016 at 10:32:32AM +0100, Maarten Lankhorst wrote:
> >> Op 21-03-16 om 18:37 schreef Daniel Vetter:
> >>> On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
>
> Cc: sta...@vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing
> it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References:
> https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
> Cc: Thomas Hellstrom
> Cc: David Herrmann
> ---
> drivers/gpu/drm/drm_crtc.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e08f962288d9..b7d0b959f088 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
> return 0;
> }
>
> +struct drm_mode_rmfb_work {
> + struct work_struct work;
> + struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> + struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> + drm_framebuffer_remove(arg->fb);
> >>> drm_framebuffer_remove still has the problem of not working correctly with
> >>> atomic since atomic commit will complain if we try to do more than 1
> >>> commit per ww_acquire_ctx. I think we still need an atomic version of
> >>> this. Also probably a more nasty igt testcase which uses the same fb on
> >>> more than one plane to be able to hit this case.
> >> That's true, but a separate bug. :)
> > Atm we only use drm_framebuffer_remove in atomic drivers to nuke the fbdev
> > one at unload. With your patch userspace can't get there easily, and hence
> > it must be fixed. Maybe separate prep patch (also cc: stable) upfront?
> >
> Something like this?
>
> Unfortunately I need to collect acks first.
Oh dear, we're back to that discussion about how to pull this off :( I
forgot about all that, silly me ...
For a much more minimal fix, what about a default rmfb helper which
implements the right thing automatically depending upon DRIVER_ATOMIC,
plus the hook only for i915 to get atomic behaviour? With that we only
need ack for drm core + i915, which we can get fast ;-)
Would then also mean that drm_atomic_remove_framebuffer() would need to be
in drm_atomic.c probably, so that drm_crtc.c can call it.
if (dev->driver->remove_fb)
ret = dev->driver->remove_fb(fb);
else if (drm_core_check_feature(dev, DRIVER_ATOMIC))
ret = drm_atomic_remove_fb(fb);
else
ret = legacy_remove_fb(fb);
Besides this, need some minimal kerneldoc from
drm_atomic_remove_framebuffer().
Cheers, Daniel
>
> commit ed242f92c2e7571a6a5f649c2a67031debc73e44
> Author: Maarten Lankhorst
> Date: Thu Mar 17 13:42:08 2016 +0100
>
> drm/atomic: Add remove_fb function pointer.
>
> Use this in drm_framebuffer_remove, this is to remove the fb in an atomic
> way.
>
> Signed-off-by: Maarten Lankhorst
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 56b829f97699..50ba6adb74e8 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -324,6 +324,7 @@ static struct drm_driver hdlcd_driver = {
> .dumb_create = drm_gem_cma_dumb_create,
> .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> .dumb_destroy = drm_gem_dumb_destroy,
> + .remove_fb = drm_atomic_helper_remove_fb,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_export = drm_gem_prime_export,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 3d8d16402d07..5d357f729114 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -711,6 +711,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
> .dumb_create = drm_gem_cma_dumb_create,
> .dumb_map_offset = drm_gem_cma_dumb_m
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Support to enable TRTT on GEN9 (rev9)
== Series Details == Series: drm/i915: Support to enable TRTT on GEN9 (rev9) URL : https://patchwork.freedesktop.org/series/2321/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/e1000e/ethtool.o LD drivers/pnp/pnpacpi/pnp.o LD drivers/pnp/pnpacpi/built-in.o LD drivers/pnp/built-in.o CC [M] drivers/net/usb/smsc75xx.o CC [M] drivers/net/ethernet/intel/e1000e/netdev.o CC [M] drivers/net/usb/smsc95xx.o LD drivers/md/dm-mod.o LD drivers/md/built-in.o CC [M] drivers/net/ethernet/intel/e1000e/ptp.o CC [M] drivers/net/usb/mcs7830.o CC [M] drivers/net/usb/usbnet.o CC [M] drivers/net/ethernet/intel/e1000/e1000_param.o CC [M] drivers/net/usb/cdc_ncm.o CC [M] drivers/net/ethernet/intel/igb/e1000_82575.o CC [M] drivers/net/ethernet/intel/igb/e1000_mac.o CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M] drivers/net/ethernet/intel/igb/e1000_phy.o CC [M] drivers/net/ethernet/intel/igb/e1000_mbx.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o CC [M] drivers/net/ethernet/intel/igb/igb_ptp.o CC [M] drivers/net/ethernet/intel/igb/igb_hwmon.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o Makefile:950: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Use to_i915() instead of guc_to_i915()
On Tue, Mar 22, 2016 at 10:55:40AM +, Dave Gordon wrote:
> On 18/03/16 21:16, Chris Wilson wrote:
> >-for_each_engine(engine, dev_priv, i) {
> >+for_each_engine(engine, guc, i) {
>
> ... but not this (see earlier mail), although, the objection is less
> here because the GuC is singular and associated with all engines, so
> there isn't much else that we could expect to iterate over.
>
> OTOH this may actually be less efficient, because the conversion of
> the "struct intel_guc" to the thing(s) actually needed for the
> iteration will (or at least may) occur on each iteration of the
> loop. Generally I'd prefer to pull all such conversions out to the
> head of the function, as the original code did.
It's an init func, the question is simply which is more readable.
> > struct guc_execlist_context *lrc = &desc.lrc[engine->guc_id];
> > struct drm_i915_gem_object *obj;
> > uint64_t ctx_desc;
> >@@ -772,7 +771,6 @@ err:
> >
> > static void guc_create_log(struct intel_guc *guc)
> > {
> >-struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > struct drm_i915_gem_object *obj;
> > unsigned long offset;
> > uint32_t size, flags;
> >@@ -791,7 +789,7 @@ static void guc_create_log(struct intel_guc *guc)
> >
> > obj = guc->log_obj;
> > if (!obj) {
> >-obj = gem_allocate_guc_obj(dev_priv->dev, size);
> >+obj = gem_allocate_guc_obj(to_i915(guc)->dev, size);
>
> Should we have to_dev(any) as well as to_i915()?
>
> > if (!obj) {
> > /* logging will be off */
> > i915.guc_log_level = -1;
> >@@ -835,7 +833,6 @@ static void init_guc_policies(struct guc_policies
> >*policies)
> >
> > static void guc_create_ads(struct intel_guc *guc)
> > {
> >-struct drm_i915_private *dev_priv = guc_to_i915(guc);
>
> This dev_priv is used more than once (in fact, it's used in a
> for_each_engine() loop below), so I'd think it worth keeping -- and
> therefore none of the changes below would be applicable.
There's a later change to fix that since these functions are attrocious,
in terms of layering name and paramter abuse.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Wait until after wm optimization to drop runtime PM reference
On Fri, Mar 04, 2016 at 03:59:39PM -0800, Matt Roper wrote:
> At the end of an atomic commit, we currently wait for vblanks to
> complete, call put() on the various runtime PM references, and then try
> to optimize our watermarks (on platforms that need two-step watermark
> programming). This can lead to watermark registers being programmed
> while the power well is powered down. We need to wait until after
> watermark optimization is complete before dropping our runtime power
> references.
>
> Note that in the future the watermark optimization is probably going to
> move to an asynchronous workqueue task that happens at some arbitrary
> point after vblank. When we make that change, we'll no longer
> necessarily be operating under the power reference held here, so we'll
> need to wrap the watermark register programmin in a call to
> intel_runtime_pm_get_if_in_use() or similar.
>
> Cc: arun.siluv...@linux.intel.com
> Cc: ville.syrj...@linux.intel.com
> Cc: maarten.lankho...@linux.intel.com
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94349
> Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming
> (v11)")
> Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 62d36a7..0af08d7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13789,16 +13789,6 @@ static int intel_atomic_commit(struct drm_device
> *dev,
> if (!state->legacy_cursor_update)
> intel_atomic_wait_for_vblanks(dev, dev_priv, crtc_vblank_mask);
>
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - intel_post_plane_update(to_intel_crtc(crtc));
> -
> - if (put_domains[i])
> - modeset_put_power_domains(dev_priv, put_domains[i]);
> - }
> -
> - if (intel_state->modeset)
> - intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> -
> /*
>* Now that the vblank has passed, we can go ahead and program the
>* optimal watermarks on platforms that need two-step watermark
> @@ -13813,6 +13803,16 @@ static int intel_atomic_commit(struct drm_device
> *dev,
> dev_priv->display.optimize_watermarks(intel_cstate);
> }
>
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + intel_post_plane_update(to_intel_crtc(crtc));
> +
> + if (put_domains[i])
> + modeset_put_power_domains(dev_priv, put_domains[i]);
> + }
> +
> + if (intel_state->modeset)
> + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> +
> mutex_lock(&dev->struct_mutex);
> drm_atomic_helper_cleanup_planes(dev, state);
> mutex_unlock(&dev->struct_mutex);
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject non-canonical rotations
On Tue, Mar 22, 2016 at 10:48:41AM +, Matthew Auld wrote: > As in the drm core? Not as far as I could tell... A good time to add it then I guess ;) -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: intel_audio clear eld buf when disconnecting monitor
On Tue, Mar 22, 2016 at 08:15:42AM +0100, Takashi Iwai wrote: > On Tue, 22 Mar 2016 02:47:14 +0100, > Yang, Libin wrote: > > > > Hi Takashi, > > > > > -Original Message- > > > From: Takashi Iwai [mailto:ti...@suse.de] > > > Sent: Monday, March 21, 2016 11:30 PM > > > To: Yang, Libin > > > Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; > > > conselv...@gmail.com; jani.nik...@linux.intel.com; > > > ville.syrj...@linux.intel.com; Vetter, Daniel > > > Subject: Re: [PATCH] drm/i915: intel_audio clear eld buf when > > > disconnecting monitor > > > > > > On Mon, 21 Mar 2016 16:19:31 +0100, > > > Takashi Iwai wrote: > > > > > > > > On Mon, 21 Mar 2016 16:12:05 +0100, > > > > Takashi Iwai wrote: > > > > > > > > > > On Mon, 21 Mar 2016 16:00:21 +0100, > > > > > Takashi Iwai wrote: > > > > > > > > > > > > On Mon, 21 Mar 2016 15:17:37 +0100, > > > > > > Yang, Libin wrote: > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Takashi Iwai [mailto:ti...@suse.de] > > > > > > > > Sent: Monday, March 21, 2016 6:45 PM > > > > > > > > To: libin.y...@linux.intel.com > > > > > > > > Cc: intel-gfx@lists.freedesktop.org; conselv...@gmail.com; > > > > > > > > jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com; > > > > > > > > Vetter, > > > Daniel; > > > > > > > > ti...@suse.de; Yang, Libin > > > > > > > > Subject: Re: [PATCH] drm/i915: intel_audio clear eld buf when > > > > > > > > disconnecting monitor > > > > > > > > > > > > > > > > On Mon, 21 Mar 2016 06:03:29 +0100, > > > > > > > > libin.y...@linux.intel.com wrote: > > > > > > > > > > > > > > > > > > From: Libin Yang > > > > > > > > > > > > > > > > > > When disconnecting monitor, dev_priv->dig_port_map[port] > > > > > > > > > will be set NULL, which causes eld will not be updated in > > > > > > > > > i915_audio_component_get_eld(). > > > > > > > > > > > > > > > > > > This patch clears the eld buf when dev_priv- > > > >dig_port_map[port] > > > > > > > > > is NULL. > > > > > > > > > > > > > > > > > > Signed-off-by: Libin Yang > > > > > > > > > > > > > > > > While this isn't certainly bad, I don't think it's mandatory. > > > > > > > > The > > > > > > > > function returns zero, i.e. no data is copied. So the caller > > > > > > > > shouldn't expect that the buffer is cleared in this case. > > > > > > > > > > > > > > Without the patch, we find when unplug the monitor, the eld info > > > > > > > will not be updated. The means the eld info in the procfs still > > > remains > > > > > > > the old info after the monitor is disconnected. > > > > > > > > > > > > Well, it's not about zero-clear but rather because the function > > > > > > returns an error (-EINVAL), and the caller takes it too seriously. > > > > > > Upon receiving an error code, the HDA driver doesn't read ELD at > > > > > > all, > > > > > > so it won't help even if you do zero-clear there. > > > > > > > > > > > > The alternative fix patch is below. > > > > > > > > > > ... or we can fix it in HDA side like below, too. > > > > > > > > This patch won't be applied cleanly on the upstream tree as I wrote it > > > > on the my working tree, sorry. Below is the revised one that is > > > > applicable to upstream tree. > > > > > > Gah, a typo was included in this patch, too. Sorry, the correct one > > > is attached below. > > > > Yes. The patch seems more reasonable than mine. > > > > Do we still need the patch to set i915_audio_component_get_eld() > > return value to 0? It seems -EINVAL makes sense. > > Yes, we can drop i915 change. I queued my fix for HD-audio side for > the next pull request. Awesome, thx everyone for tracking this down. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Pipe level color management
On Mon, Mar 21, 2016 at 11:55:34AM -0700, Matt Roper wrote: > On Wed, Mar 16, 2016 at 10:57:13AM +, Lionel Landwerlin wrote: > > This series introduces pipe level color management for Intel platforms > > on CherryView and Broadwell on. > > > > This series is based of a previous set of patches by Shashank Sharma. > > > > Cheers, > > > > Lionel > > > > v9: Rebase on nightly > > > > v10: Mask GAMMA_MODE register value (Matt Roper) > > Cleanup legacy LUT helper (Emil Velikov) > > > > v11: Rebase on drm-nightly > > The only issues raised by CI were a sporadic error that we already have > a bug (and fix) for at > https://bugs.freedesktop.org/show_bug.cgi?id=94349 > > Everything looks good, so merged these to dinq and merged the > corresponding igt tests as well. Thanks for the patches. Can we please, please fast-track this bugfix instead of piling ever more features on? That ilk wm warning has been seriously annoying everyone for a long time ... And imo it's totally fine if the bugfix isn't perfect, as long as it's not clearly a bad idea and a reasonable (first/minor/whatever) step towards the real solution. -Daniel > > > Matt > > > > > Lionel Landwerlin (4): > > drm/i915: Extract out gamma table and CSC to their own file > > drm/i915: Do not read GAMMA_MODE register > > drm/i915: Implement color management on bdw/skl/bxt/kbl > > drm/i915: Implement color management on chv > > > > Documentation/DocBook/gpu.tmpl | 6 +- > > drivers/gpu/drm/i915/Makefile| 1 + > > drivers/gpu/drm/i915/i915_drv.c | 27 +- > > drivers/gpu/drm/i915/i915_drv.h | 8 + > > drivers/gpu/drm/i915/i915_reg.h | 53 > > drivers/gpu/drm/i915/intel_color.c | 556 > > +++ > > drivers/gpu/drm/i915/intel_display.c | 184 +++- > > drivers/gpu/drm/i915/intel_drv.h | 12 + > > drivers/gpu/drm/i915/intel_fbdev.c | 8 + > > 9 files changed, 695 insertions(+), 160 deletions(-) > > create mode 100644 drivers/gpu/drm/i915/intel_color.c > > > > -- > > 2.7.0 > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Matt Roper > Graphics Software Engineer > IoTG Platform Enabling & Development > Intel Corporation > (916) 356-2795 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Use to_i915() instead of guc_to_i915()
On 18/03/16 21:16, Chris Wilson wrote:
The convenience of saving a few characters by using a consistent
interface to obtain our drm_i915_private struct from intel_guc.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 4 +++-
drivers/gpu/drm/i915/i915_guc_submission.c | 23 ++-
2 files changed, 13 insertions(+), 14 deletions(-)
Generally: I don't mind this, though I don't think there's any huge
advantage ...
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 92365f047e53..d5fa42c96110 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1982,7 +1982,7 @@ static inline struct drm_i915_private *dev_to_i915(struct
device *dev)
return __to_i915(dev_get_drvdata(dev));
}
-static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+static inline struct drm_i915_private *__guc_to_i915(struct intel_guc *guc)
{
return container_of(guc, struct drm_i915_private, guc);
}
@@ -2463,6 +2463,8 @@ struct drm_i915_cmd_table {
__p = __to_i915((struct drm_device *)p); \
else if (__builtin_types_compatible_p(typeof(*p), struct
drm_i915_gem_object)) \
__p = __obj_to_i915((struct drm_i915_gem_object *)p); \
+ else if (__builtin_types_compatible_p(typeof(*p), struct intel_guc)) \
+ __p = __guc_to_i915((struct intel_guc *)p); \
... so yes, this is OK ...
else \
BUILD_BUG(); \
__p; \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ae1f58d073f2..850aee78c40f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -77,7 +77,7 @@ static inline bool host2guc_action_response(struct
drm_i915_private *dev_priv,
static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_private *dev_priv = to_i915(guc);
... and these ...
u32 status;
int i;
int ret;
@@ -152,7 +152,7 @@ static int host2guc_release_doorbell(struct intel_guc *guc,
static int host2guc_sample_forcewake(struct intel_guc *guc,
struct i915_guc_client *client)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_private *dev_priv = to_i915(guc);
struct drm_device *dev = dev_priv->dev;
u32 data[2];
@@ -254,7 +254,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
static void guc_disable_doorbell(struct intel_guc *guc,
struct i915_guc_client *client)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_private *dev_priv = to_i915(guc);
struct guc_doorbell_info *doorbell;
void *base;
i915_reg_t drbreg = GEN8_DRBREGL(client->doorbell_id);
@@ -376,7 +376,6 @@ static void guc_init_proc_desc(struct intel_guc *guc,
static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_guc_client *client)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct intel_engine_cs *engine;
struct intel_context *ctx = client->owner;
struct guc_context_desc desc;
@@ -390,7 +389,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
- for_each_engine(engine, dev_priv, i) {
+ for_each_engine(engine, guc, i) {
... but not this (see earlier mail), although, the objection is less
here because the GuC is singular and associated with all engines, so
there isn't much else that we could expect to iterate over.
OTOH this may actually be less efficient, because the conversion of the
"struct intel_guc" to the thing(s) actually needed for the iteration
will (or at least may) occur on each iteration of the loop. Generally
I'd prefer to pull all such conversions out to the head of the function,
as the original code did.
struct guc_execlist_context *lrc = &desc.lrc[engine->guc_id];
struct drm_i915_gem_object *obj;
uint64_t ctx_desc;
@@ -772,7 +771,6 @@ err:
static void guc_create_log(struct intel_guc *guc)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct drm_i915_gem_object *obj;
unsigned long offset;
uint32_t size, flags;
@@ -791,7 +789,7 @@ static void guc_create_log(struct intel_guc *guc)
obj = guc->log_obj;
if (!obj) {
- obj = gem_allocate_guc_obj(dev_priv->dev, size);
+ obj = gem_allocate_guc_obj(to_i915(guc)->dev, size);
Should we have to_dev(any) as well as to_i915()?
if (!obj) {
/* logging will be off */
i915.guc_log_level =
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only (rev2)
== Series Details == Series: drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only (rev2) URL : https://patchwork.freedesktop.org/series/3496/ State : warning == Summary == Series 3496v2 drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only http://patchwork.freedesktop.org/api/1.0/series/3496/revisions/2/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Subgroup basic-plain-flip: pass -> DMESG-WARN (snb-x220t) dmesg-warn -> PASS (bdw-ultra) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> DMESG-WARN (bdw-ultra) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (snb-dellxps) Subgroup basic-rte: dmesg-warn -> PASS (snb-x220t) pass -> DMESG-WARN (bsw-nuc-2) dmesg-warn -> PASS (snb-dellxps) dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:170 dwarn:1 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 ilk-hp8440p total:192 pass:128 dwarn:1 dfail:0 fail:0 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:157 dwarn:1 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:157 dwarn:1 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1669/ 4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: 2016y-03m-21d-18h-43m-18s UTC integration manifest 4cf35a584e45c7b79ec93be893a10380567d86b7 drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb.
Op 22-03-16 om 11:50 schreef Daniel Vetter:
> On Tue, Mar 22, 2016 at 10:32:32AM +0100, Maarten Lankhorst wrote:
>> Op 21-03-16 om 18:37 schreef Daniel Vetter:
>>> On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote:
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.
Cc: sta...@vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing
it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References:
https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom
Cc: David Herrmann
---
drivers/gpu/drm/drm_crtc.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e08f962288d9..b7d0b959f088 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
return 0;
}
+struct drm_mode_rmfb_work {
+ struct work_struct work;
+ struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+ struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+ drm_framebuffer_remove(arg->fb);
>>> drm_framebuffer_remove still has the problem of not working correctly with
>>> atomic since atomic commit will complain if we try to do more than 1
>>> commit per ww_acquire_ctx. I think we still need an atomic version of
>>> this. Also probably a more nasty igt testcase which uses the same fb on
>>> more than one plane to be able to hit this case.
>> That's true, but a separate bug. :)
> Atm we only use drm_framebuffer_remove in atomic drivers to nuke the fbdev
> one at unload. With your patch userspace can't get there easily, and hence
> it must be fixed. Maybe separate prep patch (also cc: stable) upfront?
>
Something like this?
Unfortunately I need to collect acks first.
commit ed242f92c2e7571a6a5f649c2a67031debc73e44
Author: Maarten Lankhorst
Date: Thu Mar 17 13:42:08 2016 +0100
drm/atomic: Add remove_fb function pointer.
Use this in drm_framebuffer_remove, this is to remove the fb in an atomic
way.
Signed-off-by: Maarten Lankhorst
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 56b829f97699..50ba6adb74e8 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -324,6 +324,7 @@ static struct drm_driver hdlcd_driver = {
.dumb_create = drm_gem_cma_dumb_create,
.dumb_map_offset = drm_gem_cma_dumb_map_offset,
.dumb_destroy = drm_gem_dumb_destroy,
+ .remove_fb = drm_atomic_helper_remove_fb,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 3d8d16402d07..5d357f729114 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -711,6 +711,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.dumb_create = drm_gem_cma_dumb_create,
.dumb_map_offset = drm_gem_cma_dumb_map_offset,
.dumb_destroy = drm_gem_dumb_destroy,
+ .remove_fb = drm_atomic_helper_remove_fb,
.fops = &fops,
.name = "atmel-hlcdc",
.desc = "Atmel HLCD Controller DRM",
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4befe25c81c7..eb3b413560df 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1960,6 +1960,72 @@ commit:
return 0;
}
+int drm_atomic_helper_remove_fb(struct drm_framebuffer *fb)
+{
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_device *dev = fb->dev;
+ struct drm_atomic_state *state;
+ struct drm_plane *plane;
+ int ret = 0;
+ unsigned plane_mask;
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return -ENOMEM;
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+retry:
+ plane_mask = 0;
+ ret = drm_modeset_lock_all_ctx(dev, &ctx);
+ if (ret)
+ goto unlock;
+
+ drm_for_each_plane(plane, dev) {
+ struct drm
