Re: [Intel-gfx] [PATCH 2/2] drm/i915: fully apply WaSkipStolenMemoryFirstPage
On Wed, Dec 14, 2016 at 05:55:39PM -0200, Paulo Zanoni wrote:
> Don't even tell the mm allocator to handle the first page of stolen on
> the affected platforms. This means that we won't inherit the FB in
> case the BIOS decides to put it at the start of stolen. But the BIOS
> should not be putting it at the start of stolen since it's going to
> get corrupted. I suppose the bug here is that some pixels at the very
> top of the screen will be corrupted, so it's not exactly easy to
> notice.
>
> We have confirmation that the first page of stolen does actually get
> corrupted, so I really think we should do this in order to avoid any
> possible future headaches, even if that means losing BIOS framebuffer
> inheritance. Let's not use the HW in a way it's not supposed to be
> used.
>
> v2: don't even put the first page on the mm (Chris).
> v3: drm_mm_init() takes size instead of end as argument (Ville).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
> Cc: Chris Wilson
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.h| 1 +
> drivers/gpu/drm/i915/i915_gem_stolen.c | 34
> +-
> drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> 3 files changed, 17 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 8965bbb..aefc968 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -316,6 +316,7 @@ struct i915_ggtt {
> struct io_mapping mappable; /* Mapping to our CPU mappable region */
>
/* Stolen memory is segmented in hardware with different portions
* offlimits to certain functions.
*
* The drm_mm is initialised to the total accessible range, as found
* from the PCI config. On Broadwell+, this is further restricted to
* avoid the first page! The upper end of stolen memory is reserved for
* hardware functions (such as intermediate encodings and compression)
* and similarly removed from the accessible range.
*/
> size_t stolen_size; /* Total size of stolen memory */
> + size_t stolen_usable_start; /* First page may be unusable. */
> size_t stolen_usable_size; /* Total size minus BIOS reserved */
> size_t stolen_reserved_base;
> size_t stolen_reserved_size;
Aside: Why are these hw values using size_t?
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index b1c8897..56d7e0b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -54,12 +54,6 @@ int i915_gem_stolen_insert_node_in_range(struct
> drm_i915_private *dev_priv,
> if (!drm_mm_initialized(&dev_priv->mm.stolen))
> return -ENODEV;
>
> - /* See the comment at the drm_mm_init() call for more about this check.
> - * WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
> - */
> - if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
> - start = 4096;
> -
> mutex_lock(&dev_priv->mm.stolen_lock);
> ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size,
> alignment, start, end,
> @@ -74,10 +68,11 @@ int i915_gem_stolen_insert_node(struct drm_i915_private
> *dev_priv,
> unsigned alignment)
> {
> struct i915_ggtt *ggtt = &dev_priv->ggtt;
> + u64 start = ggtt->stolen_usable_start;
> + u64 end = start + ggtt->stolen_usable_size;
>
> return i915_gem_stolen_insert_node_in_range(dev_priv, node, size,
> - alignment, 0,
> - ggtt->stolen_usable_size);
? The range is already restricted, you cannot get anything before
stolen_usable_start, or anything after usable_size. Just pass 0,
U64_MAX.
> + alignment, start, end);
> }
>
> void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
> @@ -489,20 +484,17 @@ int i915_gem_init_stolen(struct drm_i915_private
> *dev_priv)
> ggtt->stolen_size >> 10,
> (ggtt->stolen_size - reserved_total) >> 10);
>
> - ggtt->stolen_usable_size = ggtt->stolen_size - reserved_total;
> + ggtt->stolen_usable_start = 0;
> + /* WaSkipStolenMemoryFirstPage:bdw+ */
> + if (INTEL_GEN(dev_priv) >= 8)
> + ggtt->stolen_usable_start = 4096;
>
> - /*
> - * Basic memrange allocator for stolen space.
> - *
> - * TODO: Notice that some platforms require us to not use the first page
> - * of the stolen memory but their BIOSes may still put the framebuffer
> - * on the first page. So we don't reserve this page for now because of
> - * that. Our current solution is to just prevent new nodes from being
> - * inserted on the first page - see the check we have at
> - * i915_gem
Re: [Intel-gfx] [PATCH 11/34] drm: kselftest for drm_mm_insert_node_in_range()
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > Exercise drm_mm_insert_node_in_range(), check that we only allocate from > the specified range. > > Signed-off-by: Chris Wilson With the stylistic changes I proposed to whole series; Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very small delays
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> usleep_range() is intended for delays in the 10us to 10ms range that need
> good precision. a useleep_range(1, will effectively be no more than an
> imprecise udelay with some added cache disruption as it will fire more or
> less immediately - use udelay() here.
>
> Fixes: commit be4fc046bed3 ("drm/i915: add VLV DSI PLL Calculations")
> Signed-off-by: Nicholas Mc Guire
> ---
>
> Problem located by coccinelle
>
> The requirement of waiting at least 0.5 us is assured with the udelay(1)
> here which should be more effective than a usleep_range() - would
> ndelay(500) make sense here ?
This is in the modeset path, i.e. pretty slow anyway. In this case, the
point is not to try hard to minimize the wait, the point is to guarantee
"at least 0.5 us" has passed. If the CPU can do something else,
including dozing off, in the mean time, great. I think we should stick
with usleep_range().
I think the question is, how do we express this in code? IMO udelay() is
not the answer.
And why doesn't usleep_range() kernel-doc mention anything about the
ranges?
BR,
Jani.
>
> Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915)
>
> Patch is against 4.9.0 (localvrsion-next is next-20161214)
>
> drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index 56eff60..0ec040e 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -157,7 +157,7 @@ static void vlv_enable_dsi_pll(struct intel_encoder
> *encoder,
> config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
>
> /* wait at least 0.5 us after ungating before enabling VCO */
> - usleep_range(1, 10);
> + udelay(1);
>
> vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, config->dsi_pll.ctrl);
--
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/i915: use udelay for very small delays
On Thu, 15 Dec 2016, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> usleep_range() is intended for delays in the 10us to 10ms range that need
>> good precision. a useleep_range(1, will effectively be no more than an
>> imprecise udelay with some added cache disruption as it will fire more or
>> less immediately - use udelay() here.
>>
>> Fixes: commit be4fc046bed3 ("drm/i915: add VLV DSI PLL Calculations")
>> Signed-off-by: Nicholas Mc Guire
>> ---
>>
>> Problem located by coccinelle
>>
>> The requirement of waiting at least 0.5 us is assured with the udelay(1)
>> here which should be more effective than a usleep_range() - would
>> ndelay(500) make sense here ?
>
> This is in the modeset path, i.e. pretty slow anyway. In this case, the
> point is not to try hard to minimize the wait, the point is to guarantee
> "at least 0.5 us" has passed. If the CPU can do something else,
> including dozing off, in the mean time, great. I think we should stick
> with usleep_range().
>
> I think the question is, how do we express this in code? IMO udelay() is
> not the answer.
>
> And why doesn't usleep_range() kernel-doc mention anything about the
> ranges?
>
>
> BR,
> Jani.
>
>
>>
>> Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915)
>>
>> Patch is against 4.9.0 (localvrsion-next is next-20161214)
>>
>> drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
>> b/drivers/gpu/drm/i915/intel_dsi_pll.c
>> index 56eff60..0ec040e 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
>> @@ -157,7 +157,7 @@ static void vlv_enable_dsi_pll(struct intel_encoder
>> *encoder,
>>config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
>>
>> /* wait at least 0.5 us after ungating before enabling VCO */
>> -usleep_range(1, 10);
>> +udelay(1);
>>
>> vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, config->dsi_pll.ctrl);
PS. This vlv_cck_write() call will do sideband communication with
millisecond range timeouts.
--
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 12/34] drm: kselftest for drm_mm and alignment
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we can request alignment to any power-of-two or prime using a
> plain drm_mm_node_insert(), and also handle a reasonable selection of
> primes.
>
> Signed-off-by: Chris Wilson
> +static int igt_align(void *ignored)
> +{
> + struct drm_mm mm;
> + struct drm_mm_node *node, *next;
> + int ret = -EINVAL;
> + int prime;
> +
> + drm_mm_init(&mm, 1, U64_MAX - 1);
> +
> + drm_for_each_prime(prime, 8192) {
> + u64 size;
> + int err;
> +
> + node = kzalloc(sizeof(*node), GFP_KERNEL);
> + if (!node) {
> + ret = -ENOMEM;
> + goto out;
> + }
If the amount of primes would be predictable (pun intended), we could
malloc the nodes at one go.
Other than that, looks like I reviewed this already;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 1/9] drm/i915/glk: Add new bit fields in MIPI CTRL register
From: Deepak M
v2: Addressed Jani's Review comments (renamed bit field macros)
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 90685d2..8e47b59 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8672,6 +8672,21 @@ enum {
#define BXT_PIPE_SELECT_SHIFT 7
#define BXT_PIPE_SELECT_MASK (7 << 7)
#define BXT_PIPE_SELECT(pipe) ((pipe) << 7)
+#define GLK_PHY_STATUS_PORT_READY (1 << 31) /* RO */
+#define GLK_ULPS_NOT_ACTIVE (1 << 30) /* RO */
+#define GLK_MIPIIO_RESET_RELEASED (1 << 28)
+#define GLK_CLOCK_LANE_STOP_STATE (1 << 27) /* RO */
+#define GLK_DATA_LANE_STOP_STATE (1 << 26) /* RO */
+#define GLK_LP_WAKE (1 << 22)
+#define GLK_LP11_LOW_PWR_MODE (1 << 21)
+#define GLK_LP00_LOW_PWR_MODE (1 << 20)
+#define GLK_FIREWALL_ENABLE (1 << 16)
+#define BXT_PIXEL_OVERLAP_CNT_MASK(0xf << 10)
+#define BXT_PIXEL_OVERLAP_CNT_SHIFT 10
+#define BXT_DSC_ENABLE(1 << 3)
+#define BXT_RGB_FLIP (1 << 2)
+#define GLK_MIPIIO_PORT_POWERED (1 << 1) /* RO */
+#define GLK_MIPIIO_ENABLE (1 << 0)
#define _MIPIA_DATA_ADDRESS(dev_priv->mipi_mmio_base + 0xb108)
#define _MIPIC_DATA_ADDRESS(dev_priv->mipi_mmio_base + 0xb908)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 3/9] drm/i915/glk: Add MIPIIO Enable/disable sequence
From: Deepak M
v2: Addressed Jani's Review comments(renamed bit field macros)
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 134 +++
1 file changed, 134 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b78c686..c0697e9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -357,6 +357,134 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
return true;
}
+static void intel_dsi_disable_mipiio(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum port port;
+ u32 tmp;
+
+ /* Put the IO into reset */
+ tmp = I915_READ(MIPI_CTRL(PORT_A));
+ tmp &= ~GLK_MIPIIO_RESET_RELEASED;
+ I915_WRITE(MIPI_CTRL(PORT_A), tmp);
+
+ /* Wait for MIPI PHY status bit to unset */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ if (intel_wait_for_register(dev_priv,
+ MIPI_CTRL(port),
+ GLK_PHY_STATUS_PORT_READY, 0, 20))
+ DRM_ERROR("PHY is not turning OFF\n");
+ }
+
+ /* Clear MIPI mode */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(MIPI_CTRL(port));
+ tmp &= ~GLK_MIPIIO_ENABLE;
+ I915_WRITE(MIPI_CTRL(port), tmp);
+ }
+}
+
+static void intel_dsi_enable_mipiio(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum port port;
+ u32 tmp, val;
+
+ /* Put the IO into reset */
+ tmp = I915_READ(MIPI_CTRL(PORT_A));
+ tmp &= ~GLK_MIPIIO_RESET_RELEASED;
+ I915_WRITE(MIPI_CTRL(PORT_A), tmp);
+
+ /* Program LP Wake */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(MIPI_CTRL(port));
+ tmp &= ~GLK_LP_WAKE;
+ I915_WRITE(MIPI_CTRL(port), tmp);
+ }
+
+ /* Set the MIPI mode */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(MIPI_CTRL(port));
+ I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
+ }
+
+ /* Wait for Pwr ACK */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ if (intel_wait_for_register(dev_priv,
+ MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
+ GLK_MIPIIO_PORT_POWERED, 20))
+ DRM_ERROR("Power ACK not received\n");
+ }
+
+ /* Wait for MIPI PHY status bit to set */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ if (intel_wait_for_register(dev_priv,
+ MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
+ GLK_MIPIIO_PORT_POWERED, 20))
+ DRM_ERROR("PHY is not ON\n");
+ }
+
+ /* Get IO out of reset */
+ tmp = I915_READ(MIPI_CTRL(PORT_A));
+ I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED);
+
+ /* Get IO out of Low power state*/
+ for_each_dsi_port(port, intel_dsi->ports) {
+ if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) {
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val &= ~ULPS_STATE_MASK;
+ val |= DEVICE_READY;
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
+ usleep_range(10, 15);
+ }
+
+ /* Enter ULPS */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val &= ~ULPS_STATE_MASK;
+ val |= (ULPS_STATE_ENTER | DEVICE_READY);
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+ /* Wait for ULPS Not active */
+ if (intel_wait_for_register(dev_priv,
+ MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
+ GLK_ULPS_NOT_ACTIVE, 20))
+
+ /* Exit ULPS */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val &= ~ULPS_STATE_MASK;
+ val |= (ULPS_STATE_EXIT | DEVICE_READY);
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+ /* Enter Normal Mode */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val &= ~ULPS_STATE_MASK;
+ val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+ tmp = I915_READ(MIPI_CTRL(port));
+ tmp &= ~GLK_LP_WAKE;
+ I915_WRITE(MIPI_CTRL(port), tmp);
+ }
+
+ /* Wait for Stop state */
+ for_each_dsi_port(port, intel_d
[Intel-gfx] [GLK MIPI DSI V2 0/9] GLK MIPI DSI VIDEO MODE PATCHES
The patches in this list enable MIPI DSI video mode support for GLK platform. Tesed locally. v2: Renamed bitfields macros as per review comments(Jani) Deepak M (7): drm/i915/glk: Add new bit fields in MIPI CTRL register drm/i915/glk: Program new MIPI DSI PHY registers for GLK drm/i915/glk: Add MIPIIO Enable/disable sequence drm/i915: Set the Z inversion overlap field drm/i915/glk: Add DSI PLL divider range for glk drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT drm/i915/glk: Program txesc clock divider for GLK Madhav Chauhan (1): drm/i915/glk: Program dphy param reg for GLK Vincente Tsou (1): drm/915: Parsing the missed out DTD fields from the VBT drivers/gpu/drm/i915/i915_reg.h| 42 drivers/gpu/drm/i915/intel_bios.c | 8 +- drivers/gpu/drm/i915/intel_dsi.c | 166 - drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 33 -- drivers/gpu/drm/i915/intel_dsi_pll.c | 106 ++ drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +- 6 files changed, 327 insertions(+), 34 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 2/9] drm/i915/glk: Program new MIPI DSI PHY registers for GLK
From: Deepak M
Program the clk lane and tlpx time count registers
to configure DSI PHY.
v2: Addressed Jani's Review comments(renamed bit field macros)
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 18 ++
drivers/gpu/drm/i915/intel_dsi.c | 15 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8e47b59..03858f9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8550,6 +8550,24 @@ enum {
#define LP_BYTECLK_SHIFT 0
#define LP_BYTECLK_MASK (0x << 0)
+#define _MIPIA_TLPX_TIME_COUNT (dev_priv->mipi_mmio_base + 0xb0a4)
+#define _MIPIC_TLPX_TIME_COUNT (dev_priv->mipi_mmio_base + 0xb8a4)
+#define MIPI_TLPX_TIME_COUNT(port) _MMIO_MIPI(port,
_MIPIA_TLPX_TIME_COUNT, _MIPIC_TLPX_TIME_COUNT)
+#define GLK_DPHY_TLPX_TIME_CNT_SHIFT 0
+#define GLK_DPHY_TLPX_TIME_CNT_MASK (0xff << 0)
+
+#define _MIPIA_CLK_LANE_TIMING (dev_priv->mipi_mmio_base + 0xb098)
+#define _MIPIC_CLK_LANE_TIMING (dev_priv->mipi_mmio_base + 0xb898)
+#define MIPI_CLK_LANE_TIMING(port) _MMIO_MIPI(port,
_MIPIA_CLK_LANE_TIMING, _MIPIC_CLK_LANE_TIMING)
+#define GLK_MIPI_CLK_LANE_HS_PREP_SHIFT 0
+#define GLK_MIPI_CLK_LANE_HS_PREP_MASK(0xff << 0)
+#define GLK_MIPI_CLK_LANE_HS_ZERO_SHIFT 8
+#define GLK_MIPI_CLK_LANE_HS_ZERO_MASK(0xff00 << 0)
+#define GLK_MIPI_CLK_LANE_HS_TRAIL_SHIFT 16
+#define GLK_MIPI_CLK_LANE_HS_TRAIL_MASK (0xff << 0)
+#define GLK_MIPI_CLK_LANE_HS_EXIT_SHIFT 24
+#define GLK_MIPI_CLK_LANE_HS_EXIT_MASK(0xff00 <<
0)
+
/* bits 31:0 */
#define _MIPIA_LP_GEN_DATA (dev_priv->mipi_mmio_base + 0xb064)
#define _MIPIC_LP_GEN_DATA (dev_priv->mipi_mmio_base + 0xb864)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 6b63355..b78c686 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1123,6 +1123,7 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+ struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
const struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
enum port port;
unsigned int bpp =
mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
@@ -1278,6 +1279,20 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder,
*/
I915_WRITE(MIPI_LP_BYTECLK(port), intel_dsi->lp_byte_clk);
+ if (IS_GEMINILAKE(dev_priv)) {
+ I915_WRITE(MIPI_TLPX_TIME_COUNT(port),
+ intel_dsi->lp_byte_clk);
+ val = ((mipi_config->ths_prepare <<
+ GLK_MIPI_CLK_LANE_HS_PREP_SHIFT) |
+ (mipi_config->ths_prepare_hszero <<
+ GLK_MIPI_CLK_LANE_HS_ZERO_SHIFT) |
+ (mipi_config->ths_trail <<
+ GLK_MIPI_CLK_LANE_HS_TRAIL_SHIFT) |
+ (mipi_config->ths_exit <<
+ GLK_MIPI_CLK_LANE_HS_EXIT_SHIFT));
+ I915_WRITE(MIPI_CLK_LANE_TIMING(port), val);
+ }
+
/* the bw essential for transmitting 16 long packets containing
* 252 bytes meant for dcs write memory command is programmed in
* this register in terms of byte clocks. based on dsi transfer
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 9/9] drm/915: Parsing the missed out DTD fields from the VBT
From: Vincente Tsou
The upper bits of the vsync width, vsync offset and hsync width
were not parsed form the VBT. Parse these fields in this patch.
Signed-off-by: Madhav Chauhan
Signed-off-by: Vincente Tsou
---
drivers/gpu/drm/i915/intel_bios.c | 8 +---
drivers/gpu/drm/i915/intel_vbt_defs.h | 6 --
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index eaade27..e1d014b 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -114,16 +114,18 @@ static u32 get_blocksize(const void *block_data)
panel_fixed_mode->hsync_start = panel_fixed_mode->hdisplay +
((dvo_timing->hsync_off_hi << 8) | dvo_timing->hsync_off_lo);
panel_fixed_mode->hsync_end = panel_fixed_mode->hsync_start +
- dvo_timing->hsync_pulse_width;
+ ((dvo_timing->hsync_pulse_width_hi << 8) |
+ dvo_timing->hsync_pulse_width);
panel_fixed_mode->htotal = panel_fixed_mode->hdisplay +
((dvo_timing->hblank_hi << 8) | dvo_timing->hblank_lo);
panel_fixed_mode->vdisplay = (dvo_timing->vactive_hi << 8) |
dvo_timing->vactive_lo;
panel_fixed_mode->vsync_start = panel_fixed_mode->vdisplay +
- dvo_timing->vsync_off;
+ ((dvo_timing->vsync_off_hi << 4) | dvo_timing->vsync_off);
panel_fixed_mode->vsync_end = panel_fixed_mode->vsync_start +
- dvo_timing->vsync_pulse_width;
+ ((dvo_timing->vsync_pulse_width_hi << 4) |
+ dvo_timing->vsync_pulse_width);
panel_fixed_mode->vtotal = panel_fixed_mode->vdisplay +
((dvo_timing->vblank_hi << 8) | dvo_timing->vblank_lo);
panel_fixed_mode->clock = dvo_timing->clock * 10;
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 8886cab1..bf9d2d3 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -402,7 +402,9 @@ struct lvds_dvo_timing {
u8 hsync_pulse_width;
u8 vsync_pulse_width:4;
u8 vsync_off:4;
- u8 rsvd0:6;
+ u8 vsync_pulse_width_hi:2;
+ u8 vsync_off_hi:2;
+ u8 hsync_pulse_width_hi:2;
u8 hsync_off_hi:2;
u8 himage_lo;
u8 vimage_lo;
@@ -414,7 +416,7 @@ struct lvds_dvo_timing {
u8 digital:2;
u8 vsync_positive:1;
u8 hsync_positive:1;
- u8 rsvd2:1;
+ u8 interlaced:1;
} __packed;
struct lvds_pnp_id {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 8/9] drm/i915/glk: Program dphy param reg for GLK
For GEMINILAKE, dphy param reg values are programmed in terms of HS byte clock while for legacy platforms in terms of ddrclk Signed-off-by: Madhav Chauhan --- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 33 +++--- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index 0d8ff00..647eca4 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -668,16 +668,26 @@ struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id) /* count values in UI = (ns value) * (bitrate / (2 * 10^6)) * * Since txddrclkhs_i is 2xUI, all the count values programmed in -* DPHY param register are divided by 2 +* DPHY param register are divided by 2 except GEMINILAKE where it is +* programmed in terms of HS byte clock so divided by 8 * * prepare count */ ths_prepare_ns = max(mipi_config->ths_prepare, mipi_config->tclk_prepare); - prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * 2); + if (IS_GEMINILAKE(dev_priv)) + prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * 8); + else + prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * 2); /* exit zero count */ - exit_zero_cnt = DIV_ROUND_UP( + if (IS_GEMINILAKE(dev_priv)) + exit_zero_cnt = DIV_ROUND_UP( + (ths_prepare_hszero - ths_prepare_ns) * ui_den, + ui_num * 8 + ); + else + exit_zero_cnt = DIV_ROUND_UP( (ths_prepare_hszero - ths_prepare_ns) * ui_den, ui_num * 2 ); @@ -692,13 +702,22 @@ struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id) exit_zero_cnt += 1; /* clk zero count */ - clk_zero_cnt = DIV_ROUND_UP( - (tclk_prepare_clkzero - ths_prepare_ns) - * ui_den, 2 * ui_num); + if (IS_GEMINILAKE(dev_priv)) + clk_zero_cnt = DIV_ROUND_UP( + (tclk_prepare_clkzero - ths_prepare_ns) + * ui_den, 8 * ui_num); + else + clk_zero_cnt = DIV_ROUND_UP( + (tclk_prepare_clkzero - ths_prepare_ns) + * ui_den, 2 * ui_num); /* trail count */ tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail); - trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, 2 * ui_num); + + if (IS_GEMINILAKE(dev_priv)) + trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, 8 * ui_num); + else + trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, 2 * ui_num); if (prepare_cnt > PREPARE_CNT_MAX || exit_zero_cnt > EXIT_ZERO_CNT_MAX || -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 5/9] drm/i915/glk: Add DSI PLL divider range for glk
From: Deepak M
PLL divider range for GLK is different than that of
BXT, hence adding the GLK range check in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_dsi_pll.c | 20 ++--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 03858f9..65cac83 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8268,10 +8268,12 @@ enum {
#define BXT_DSI_PLL_PVD_RATIO_SHIFT 16
#define BXT_DSI_PLL_PVD_RATIO_MASK(3 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
#define BXT_DSI_PLL_PVD_RATIO_1 (1 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
+#define BXT_DSIC_16X_BY1 (0 << 10)
#define BXT_DSIC_16X_BY2 (1 << 10)
#define BXT_DSIC_16X_BY3 (2 << 10)
#define BXT_DSIC_16X_BY4 (3 << 10)
#define BXT_DSIC_16X_MASK (3 << 10)
+#define BXT_DSIA_16X_BY1 (0 << 8)
#define BXT_DSIA_16X_BY2 (1 << 8)
#define BXT_DSIA_16X_BY3 (2 << 8)
#define BXT_DSIA_16X_BY4 (3 << 8)
@@ -8281,6 +8283,8 @@ enum {
#define BXT_DSI_PLL_RATIO_MAX 0x7D
#define BXT_DSI_PLL_RATIO_MIN 0x22
+#define GLK_DSI_PLL_RATIO_MAX 0x6F
+#define GLK_DSI_PLL_RATIO_MIN 0x22
#define BXT_DSI_PLL_RATIO_MASK 0xFF
#define BXT_REF_CLOCK_KHZ 19200
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index cf8c1b0..6fdd08c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -428,9 +428,10 @@ static void bxt_dsi_program_clocks(struct drm_device *dev,
enum port port,
I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
}
-static int bxt_compute_dsi_pll(struct intel_encoder *encoder,
+static int gen9lp_compute_dsi_pll(struct intel_encoder *encoder,
struct intel_crtc_state *config)
{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
u8 dsi_ratio;
u32 dsi_clk;
@@ -444,11 +445,18 @@ static int bxt_compute_dsi_pll(struct intel_encoder
*encoder,
* round 'up' the result
*/
dsi_ratio = DIV_ROUND_UP(dsi_clk * 2, BXT_REF_CLOCK_KHZ);
- if (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
- dsi_ratio > BXT_DSI_PLL_RATIO_MAX) {
+
+ if (IS_BROXTON(dev_priv) && (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
+ dsi_ratio > BXT_DSI_PLL_RATIO_MAX)) {
DRM_ERROR("Cant get a suitable ratio from DSI PLL ratios\n");
return -ECHRNG;
- }
+ } else if (IS_GEMINILAKE(dev_priv) &&
+ (dsi_ratio < GLK_DSI_PLL_RATIO_MIN ||
+ dsi_ratio > GLK_DSI_PLL_RATIO_MAX)) {
+ DRM_ERROR("Cant get a suitable ratio from DSI PLL ratios\n");
+ return -ECHRNG;
+ } else
+ DRM_DEBUG_KMS("DSI PLL calculation is Done!!\n");
/*
* Program DSI ratio and Select MIPIC and MIPIA PLL output as 8x
@@ -460,7 +468,7 @@ static int bxt_compute_dsi_pll(struct intel_encoder
*encoder,
/* As per recommendation from hardware team,
* Prog PVD ratio =1 if dsi ratio <= 50
*/
- if (dsi_ratio <= 50)
+ if (IS_BROXTON(dev_priv) && dsi_ratio <= 50)
config->dsi_pll.ctrl |= BXT_DSI_PLL_PVD_RATIO_1;
return 0;
@@ -520,7 +528,7 @@ int intel_compute_dsi_pll(struct intel_encoder *encoder,
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
return vlv_compute_dsi_pll(encoder, config);
else if (IS_GEN9_LP(dev_priv))
- return bxt_compute_dsi_pll(encoder, config);
+ return gen9lp_compute_dsi_pll(encoder, config);
return -ENODEV;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 6/9] drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT
From: Deepak M
Register MIPI_CLOCK_CTRL is applicable only
for BXT platform. Future platform have other
registers to program the escape clock dividers.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 6fdd08c..f37f61f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -489,8 +489,10 @@ static void bxt_enable_dsi_pll(struct intel_encoder
*encoder,
POSTING_READ(BXT_DSI_PLL_CTL);
/* Program TX, RX, Dphy clocks */
- for_each_dsi_port(port, intel_dsi->ports)
- bxt_dsi_program_clocks(encoder->base.dev, port, config);
+ if (IS_BROXTON(dev_priv)) {
+ for_each_dsi_port(port, intel_dsi->ports)
+ bxt_dsi_program_clocks(encoder->base.dev, port, config);
+ }
/* Enable DSI PLL */
val = I915_READ(BXT_DSI_PLL_ENABLE);
@@ -554,19 +556,22 @@ void intel_disable_dsi_pll(struct intel_encoder *encoder)
bxt_disable_dsi_pll(encoder);
}
-static void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port)
+static void gen9lp_dsi_reset_clocks(struct intel_encoder *encoder,
+ enum port port)
{
u32 tmp;
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
/* Clear old configurations */
- tmp = I915_READ(BXT_MIPI_CLOCK_CTL);
- tmp &= ~(BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port));
- tmp &= ~(BXT_MIPI_RX_ESCLK_UPPER_FIXDIV_MASK(port));
- tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
- tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
- I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
+ if (IS_BROXTON(dev_priv)) {
+ tmp = I915_READ(BXT_MIPI_CLOCK_CTL);
+ tmp &= ~(BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port));
+ tmp &= ~(BXT_MIPI_RX_ESCLK_UPPER_FIXDIV_MASK(port));
+ tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
+ tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
+ I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
+ }
I915_WRITE(MIPI_EOT_DISABLE(port), CLOCKSTOP);
}
@@ -575,7 +580,7 @@ void intel_dsi_reset_clocks(struct intel_encoder *encoder,
enum port port)
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
if (IS_GEN9_LP(dev_priv))
- bxt_dsi_reset_clocks(encoder, port);
+ gen9lp_dsi_reset_clocks(encoder, port);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
vlv_dsi_reset_clocks(encoder, port);
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 4/9] drm/i915: Set the Z inversion overlap field
From: Deepak M
Dual link Z-inversion overlap field is present
in MIPI_CTRL register unlike the older platforms,
hence setting the same in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index c0697e9..588490d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -583,12 +583,21 @@ static void intel_dsi_port_enable(struct intel_encoder
*encoder)
if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
u32 temp;
-
- temp = I915_READ(VLV_CHICKEN_3);
- temp &= ~PIXEL_OVERLAP_CNT_MASK |
+ if (IS_GEN9_LP(dev_priv)) {
+ for_each_dsi_port(port, intel_dsi->ports) {
+ temp = I915_READ(MIPI_CTRL(port));
+ temp &= ~BXT_PIXEL_OVERLAP_CNT_MASK |
+ intel_dsi->pixel_overlap <<
+ BXT_PIXEL_OVERLAP_CNT_SHIFT;
+ I915_WRITE(MIPI_CTRL(port), temp);
+ }
+ } else {
+ temp = I915_READ(VLV_CHICKEN_3);
+ temp &= ~PIXEL_OVERLAP_CNT_MASK |
intel_dsi->pixel_overlap <<
PIXEL_OVERLAP_CNT_SHIFT;
- I915_WRITE(VLV_CHICKEN_3, temp);
+ I915_WRITE(VLV_CHICKEN_3, temp);
+ }
}
for_each_dsi_port(port, intel_dsi->ports) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GLK MIPI DSI V2 7/9] drm/i915/glk: Program txesc clock divider for GLK
From: Deepak M
v2: Addressed Jani's Review comments(renamed bit field macros)
Txesc clock divider is calculated and programmed
for geminilake platform.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++
drivers/gpu/drm/i915/intel_dsi_pll.c | 61 ++--
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65cac83..0ffce07 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8182,6 +8182,11 @@ enum {
#define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and C only */
#define _MMIO_MIPI(port, a, c) _MMIO(_MIPI_PORT(port, a, c))
+#define MIPIO_TXESC_CLK_DIV1 _MMIO(0x160004)
+#define GLK_TX_ESC_CLK_DIV1_MASK 0x3FF
+#define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
+#define GLK_TX_ESC_CLK_DIV2_MASK 0x3FF
+
/* BXT MIPI clock controls */
#define BXT_MAX_VAR_OUTPUT_KHZ 39500
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index f37f61f..0291b56 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -370,6 +370,53 @@ static void vlv_dsi_reset_clocks(struct intel_encoder
*encoder, enum port port)
ESCAPE_CLOCK_DIVIDER_SHIFT);
}
+static void glk_dsi_program_esc_clock(struct drm_device *dev,
+ const struct intel_crtc_state *config)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ u32 dsi_rate = 0;
+ u32 pll_ratio = 0;
+ u32 ddr_clk = 0;
+ u32 div1_value = 0;
+ u32 div2_value = 0;
+ u32 txesc1_div = 0;
+ u32 txesc2_div = 0;
+
+ pll_ratio = config->dsi_pll.ctrl & BXT_DSI_PLL_RATIO_MASK;
+
+ dsi_rate = (BXT_REF_CLOCK_KHZ * pll_ratio) / 2;
+
+ ddr_clk = dsi_rate / 2;
+
+ /* Variable divider value */
+ div1_value = DIV_ROUND_CLOSEST(ddr_clk, 2);
+
+ /* Calculate TXESC1 divider */
+ if (div1_value <= 10)
+ txesc1_div = div1_value;
+ else if ((div1_value > 10) && (div1_value <= 20))
+ txesc1_div = DIV_ROUND_UP(div1_value, 2);
+ else if ((div1_value > 20) && (div1_value <= 30))
+ txesc1_div = DIV_ROUND_UP(div1_value, 4);
+ else if ((div1_value > 30) && (div1_value <= 40))
+ txesc1_div = DIV_ROUND_UP(div1_value, 6);
+ else if ((div1_value > 40) && (div1_value <= 50))
+ txesc1_div = DIV_ROUND_UP(div1_value, 8);
+ else
+ txesc1_div = 10;
+
+ /* Calculate TXESC2 divider */
+ div2_value = DIV_ROUND_UP(div1_value, txesc1_div);
+
+ if (div2_value < 10)
+ txesc2_div = div2_value;
+ else
+ txesc2_div = 10;
+
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+}
+
/* Program BXT Mipi clocks and dividers */
static void bxt_dsi_program_clocks(struct drm_device *dev, enum port port,
const struct intel_crtc_state *config)
@@ -474,7 +521,7 @@ static int gen9lp_compute_dsi_pll(struct intel_encoder
*encoder,
return 0;
}
-static void bxt_enable_dsi_pll(struct intel_encoder *encoder,
+static void gen9lp_enable_dsi_pll(struct intel_encoder *encoder,
const struct intel_crtc_state *config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -492,6 +539,8 @@ static void bxt_enable_dsi_pll(struct intel_encoder
*encoder,
if (IS_BROXTON(dev_priv)) {
for_each_dsi_port(port, intel_dsi->ports)
bxt_dsi_program_clocks(encoder->base.dev, port, config);
+ } else {
+ glk_dsi_program_esc_clock(encoder->base.dev, config);
}
/* Enable DSI PLL */
@@ -543,7 +592,7 @@ void intel_enable_dsi_pll(struct intel_encoder *encoder,
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
vlv_enable_dsi_pll(encoder, config);
else if (IS_GEN9_LP(dev_priv))
- bxt_enable_dsi_pll(encoder, config);
+ gen9lp_enable_dsi_pll(encoder, config);
}
void intel_disable_dsi_pll(struct intel_encoder *encoder)
@@ -571,6 +620,14 @@ static void gen9lp_dsi_reset_clocks(struct intel_encoder
*encoder,
tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
+ } else {
+ tmp = I915_READ(MIPIO_TXESC_CLK_DIV1);
+ tmp &= ~GLK_TX_ESC_CLK_DIV1_MASK;
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, tmp);
+
+ tmp = I915_READ(MIPIO_TXESC_CLK_DIV2);
+
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > Even on fast systems a 2 microsecond delay is most likely more efficient > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - > change this to a udelay(2). Similar concerns as in [1]. We don't need the accuracy of udelay() here, so this boils down to which is the better use of CPU. We could probably relax the max delay more if that was helpful. But I'm not immediately sold on "is most likely more efficient" which sounds like a gut feeling. I'm sorry it's not clear in my other reply that I do appreciate addressing incorrect/silly use of usleep_range(); I'm just not (yet) convinced udelay() is the answer. BR, Jani. [1] http://lkml.kernel.org/r/8737hpr32a@intel.com > > Signed-off-by: Nicholas Mc Guire > --- > > Problem found by coccinelle: > > Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915) > > Patch is against 4.9.0 (localversion-next is next-20161214) > > drivers/gpu/drm/i915/intel_dsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 5b72c50..19fe86b 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -379,7 +379,7 @@ static void bxt_dsi_device_ready(struct intel_encoder > *encoder) > val &= ~ULPS_STATE_MASK; > val |= (ULPS_STATE_ENTER | DEVICE_READY); > I915_WRITE(MIPI_DEVICE_READY(port), val); > - usleep_range(2, 3); > + udelay(2); > > /* 3. Exit ULPS */ > val = I915_READ(MIPI_DEVICE_READY(port)); -- 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/i915: tune down the fast link training vs boot fail
On Thu, 15 Dec 2016, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 04:56:33PM +0200, Jani Nikula wrote: >> On Wed, 14 Dec 2016, Daniel Vetter wrote: >> > On Tue, Dec 13, 2016 at 10:23:05PM +0200, Ville Syrjälä wrote: >> >> On Tue, Dec 13, 2016 at 08:54:14PM +0100, Daniel Vetter wrote: >> >> > It's been unfixed since a while and no one is immediately working on >> >> > this. And we have the FIXME already. And now also a task in the DP >> >> > team's backlog. >> >> > >> >> > Cc: Linus Torvalds >> >> > Cc: sta...@vger.kernel.org >> >> > Cc: Ville Syrjälä >> >> > References: >> >> > https://lists.freedesktop.org/archives/intel-gfx/2016-July/101951.html >> >> > Signed-off-by: Daniel Vetter >> >> > --- >> >> > Hi Linus, >> >> > >> >> > Feel free to apply directly in case it annoys too much and you don't >> >> > want to wait for your presents ;-) >> >> > >> >> > Cheers, Daniel >> >> > --- >> >> > drivers/gpu/drm/i915/intel_dp.c | 4 ++-- >> >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> >> > >> >> > diff --git a/drivers/gpu/drm/i915/intel_dp.c >> >> > b/drivers/gpu/drm/i915/intel_dp.c >> >> > index db75bb924e48..6e875d42642a 100644 >> >> > --- a/drivers/gpu/drm/i915/intel_dp.c >> >> > +++ b/drivers/gpu/drm/i915/intel_dp.c >> >> > @@ -4014,8 +4014,8 @@ intel_dp_check_link_status(struct intel_dp >> >> > *intel_dp) >> >> > return; >> >> > >> >> > /* FIXME: we need to synchronize this sort of stuff with >> >> > hardware >> >> > -* readout */ >> >> > - if (WARN_ON_ONCE(!intel_dp->lane_count)) >> >> > +* readout. Currently fast link training doesn't work on >> >> > boot-up. */ >> >> >> >> s/fast link training/link retraining/ is what I'd put there. >> > >> > Adjusted ... >> >> >> >> I'm a bit sad to hide it but doesn't look like the proper solution is >> >> going to happen any time soon. >> >> >> >> Acked-by: Ville Syrjälä >> > >> > ... and merged since CI seems to approve too ;-) >> >> *sigh* you could've added debug logging at least. Now it's pretty much >> guaranteed nobody will look at this. It's not right to end up here >> without link params. :( > > I've made a JIRA internally to fix this and assigned it to Paul Parenteau > for handling with his DP folks. But I'm happy to also r-b stamp a patch > that adds some debug output here if you want that too. At least I thought > the problem is fairly well-understood, so didn't think this was needed. Oh, okay. Then it's just that *I* didn't understand the problem well. :( 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] [PATCH 12/34] drm: kselftest for drm_mm and alignment
On Thu, Dec 15, 2016 at 10:59:10AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> > Check that we can request alignment to any power-of-two or prime using a
> > plain drm_mm_node_insert(), and also handle a reasonable selection of
> > primes.
> >
> > Signed-off-by: Chris Wilson
>
>
>
> > +static int igt_align(void *ignored)
> > +{
> > + struct drm_mm mm;
> > + struct drm_mm_node *node, *next;
> > + int ret = -EINVAL;
> > + int prime;
> > +
> > + drm_mm_init(&mm, 1, U64_MAX - 1);
> > +
> > + drm_for_each_prime(prime, 8192) {
> > + u64 size;
> > + int err;
> > +
> > + node = kzalloc(sizeof(*node), GFP_KERNEL);
> > + if (!node) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
>
> If the amount of primes would be predictable (pun intended), we could
> malloc the nodes at one go.
I think I'll keep a couple of these smaller kzalloc() sites, just to
have some variety in testing. In particular, this coupled with kmemleak
(or slab debug) could catch a leak other tests might miss.
-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: use udelay for very short delays
On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > > Even on fast systems a 2 microsecond delay is most likely more efficient > > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - > > change this to a udelay(2). > > Similar concerns as in [1]. We don't need the accuracy of udelay() here, > so this boils down to which is the better use of CPU. We could probably > relax the max delay more if that was helpful. But I'm not immediately > sold on "is most likely more efficient" which sounds like a gut feeling. > > I'm sorry it's not clear in my other reply that I do appreciate > addressing incorrect/silly use of usleep_range(); I'm just not (yet) > convinced udelay() is the answer. So one reason why we unconditionally use *sleep variants is the might_sleep check. Because in the past people have used udelay and mdelay, those delays had to be increased a lot because hw, and at the same time someone added users of these functions to our irq helper, resulting in irq handling times measures in multiple ms. That's not good. So until someone can demonstrate that there's a real benefit (which let's be honest, for modeset code, will never be the case) I very highly prefer to use *sleep* functions. They prevent some silly things from happening by accident. Micro-optimizing modeset code and hampering maitainability in the process is not good. -Daniel > > BR, > Jani. > > > [1] http://lkml.kernel.org/r/8737hpr32a@intel.com > > > > > > Signed-off-by: Nicholas Mc Guire > > --- > > > > Problem found by coccinelle: > > > > Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915) > > > > Patch is against 4.9.0 (localversion-next is next-20161214) > > > > drivers/gpu/drm/i915/intel_dsi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > > b/drivers/gpu/drm/i915/intel_dsi.c > > index 5b72c50..19fe86b 100644 > > --- a/drivers/gpu/drm/i915/intel_dsi.c > > +++ b/drivers/gpu/drm/i915/intel_dsi.c > > @@ -379,7 +379,7 @@ static void bxt_dsi_device_ready(struct intel_encoder > > *encoder) > > val &= ~ULPS_STATE_MASK; > > val |= (ULPS_STATE_ENTER | DEVICE_READY); > > I915_WRITE(MIPI_DEVICE_READY(port), val); > > - usleep_range(2, 3); > > + udelay(2); > > > > /* 3. Exit ULPS */ > > val = I915_READ(MIPI_DEVICE_READY(port)); > > -- > Jani Nikula, Intel Open Source Technology Center > ___ > 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] drm/i915: use udelay for very short delays
On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote: > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: > > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > > > Even on fast systems a 2 microsecond delay is most likely more efficient > > > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - > > > change this to a udelay(2). > > > > Similar concerns as in [1]. We don't need the accuracy of udelay() here, > > so this boils down to which is the better use of CPU. We could probably > > relax the max delay more if that was helpful. But I'm not immediately > > sold on "is most likely more efficient" which sounds like a gut feeling. > > > > I'm sorry it's not clear in my other reply that I do appreciate > > addressing incorrect/silly use of usleep_range(); I'm just not (yet) > > convinced udelay() is the answer. > > So one reason why we unconditionally use *sleep variants is the > might_sleep check. Because in the past people have used udelay and mdelay, > those delays had to be increased a lot because hw, and at the same time > someone added users of these functions to our irq helper, resulting in irq > handling times measures in multiple ms. That's not good. > > So until someone can demonstrate that there's a real benefit (which let's > be honest, for modeset code, will never be the case) I very highly prefer > to use *sleep* functions. They prevent some silly things from happening by > accident. Micro-optimizing modeset code and hampering maitainability in > the process is not good. Also, the entire premise seems backwards: usleep_range is inefficient for certain parameter ranges and better replaced with udelay. That makes sense. But why exactly do we not fix udelay_range then, but instead do a cocci job crawling through all the thousands of callers? Just fix usleep(_range) to use udelay for very small values (and still keep the might_sleep check ofc) if that's more efficient! -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 13/34] drm: kselftest for drm_mm and eviction
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we add arbitrary blocks to the eviction scanner in order to
> find the first minimal hole that matches our request.
>
> Signed-off-by: Chris Wilson
> + if ((int)tmp.start % n || tmp.size != nsize ||
> tmp.hole_follows) {
> + pr_err("Inserted did not fill the eviction hole:
> size=%lld [%d], align=%d [rem=%d] (prime), start=%llx, hole-follows?=%d\n",
> + tmp.size, nsize, n, (int)tmp.start % n,
> tmp.start, tmp.hole_follows);
> +
> + drm_mm_remove_node(&tmp);
> + goto out;
> + }
> +
> + drm_mm_remove_node(&tmp);
> + list_for_each_entry(e, &evict_list, link) {
> + err = drm_mm_reserve_node(&mm, &e->node);
Using helpers, could repeat the ordering tests for reserve vs insert.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very small delays
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 10:47:57AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > usleep_range() is intended for delays in the 10us to 10ms range that need
>> > good precision. a useleep_range(1, will effectively be no more than an
>> > imprecise udelay with some added cache disruption as it will fire more or
>> > less immediately - use udelay() here.
>> >
>> > Fixes: commit be4fc046bed3 ("drm/i915: add VLV DSI PLL Calculations")
>> > Signed-off-by: Nicholas Mc Guire
>> > ---
>> >
>> > Problem located by coccinelle
>> >
>> > The requirement of waiting at least 0.5 us is assured with the udelay(1)
>> > here which should be more effective than a usleep_range() - would
>> > ndelay(500) make sense here ?
>>
>> This is in the modeset path, i.e. pretty slow anyway. In this case, the
>> point is not to try hard to minimize the wait, the point is to guarantee
>> "at least 0.5 us" has passed. If the CPU can do something else,
>> including dozing off, in the mean time, great. I think we should stick
>> with usleep_range().
>
> well in that case maybe an acceptable solution would be to set it to
> some suitable range 10,20 us ? or if not critical preferably even with a large
> upper limit.
I'd be fine with 10, 50 here. Please do send the patch, Cc: me.
>>
>> I think the question is, how do we express this in code? IMO udelay() is
>> not the answer.
>
> if the delay need to be kept short then no - then its not the answer
> but usleep_ranges(1,2) I think is effectively just an inefficient version
> of udelay(1), by the time the timer is setup and the task gives
> up the cpu the timer would fire.
>
>>
>> And why doesn't usleep_range() kernel-doc mention anything about the
>> ranges?
>>
>
> interesting - that might be part of the reason there are many findings
> Documentation/timers/timers-howto.txt does
>
> SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
> * Use usleep_range
I'd appreciate short additions to the kernel-doc documentation of each
function to document the approximate range it's appropriate for. People
will know where to look if their use doesn't fall in that range.
Thanks,
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: success for GLK MIPI DSI VIDEO MODE PATCHES (rev2)
== Series Details == Series: GLK MIPI DSI VIDEO MODE PATCHES (rev2) URL : https://patchwork.freedesktop.org/series/16542/ State : success == Summary == Series 16542v2 GLK MIPI DSI VIDEO MODE PATCHES https://patchwork.freedesktop.org/api/1.0/series/16542/revisions/2/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-t5700 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ilk-650 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:224 dwarn:3 dfail:0 fail:0 skip:20 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 c8109e51ef622698a43d4e8382a5f7fbbae6375b drm-tip: 2016y-12m-15d-07h-22m-49s UTC integration manifest 6295a9c drm/915: Parsing the missed out DTD fields from the VBT 1fb6cbb drm/i915/glk: Program dphy param reg for GLK 41cad10 drm/i915/glk: Program txesc clock divider for GLK 7672118 drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT afff049 drm/i915/glk: Add DSI PLL divider range for glk 140ad28 drm/i915: Set the Z inversion overlap field 120cc17 drm/i915/glk: Add MIPIIO Enable/disable sequence c2c81ac drm/i915/glk: Program new MIPI DSI PHY registers for GLK 5874254 drm/i915/glk: Add new bit fields in MIPI CTRL register == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3292/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/34] drm: kselftest for drm_mm and range restricted eviction
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we add arbitrary blocks to a restrited eviction scanner in
> order to find the first minimal hole that matches our request.
>
> Signed-off-by: Chris Wilson
> +static int igt_evict_range(void *ignored)
> +{
> + drm_for_each_prime(n, range_size) {
> + LIST_HEAD(evict_list);
> + struct evict_node *e, *en;
> + struct drm_mm_node tmp;
> + int nsize = (range_size - n + 1) / 2;
> + int err;
DRM_MM_BUG_ON(!nsize);
Same comment aplies about reserve vs insert (the amount of tests after
each, can be resolved with helpers).
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
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: Respect num_pipes when install or reset dispaly IRQ
The failed case is KBL hang. This patch shouldn't impact platforms that have non-zero num_pipes. So the KBL hang isn't a regression caused by this patch. According to below kernel log before hang (https://intel-gfx-ci.01.org/CI/Patchwork_3266/fi-kbl-7500u/dmesg-during.log), It should be the same issue as Bug 98670 - [BAT] WARN_ON(dev_priv->gt.awake) during drv_module_reload_basic (https://bugs.freedesktop.org/show_bug.cgi?id=98670), [ 25.000193] [ cut here ] [ 25.000227] WARNING: CPU: 3 PID: 6396 at drivers/gpu/drm/i915/i915_gem.c:4241 i915_gem_suspend+0x181/0x190 [i915] [ 25.000228] WARN_ON(dev_priv->gt.awake) [ 25.000229] Modules linked in: [ 25.000231] i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_generic coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei e1000e ptp pps_core i2c_hid [last unloaded: snd_hda_intel] [ 25.000249] CPU: 3 PID: 6396 Comm: drv_module_relo Tainted: G U 4.9.0-rc8-CI-Patchwork_3266+ #1 [ 25.000250] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016 [ 25.000252] c9547d18 81435bf5 c9547d68 [ 25.000256] c9547d58 8107e4d6 1091 880257a3 [ 25.000259] 880257a30068 a01370c0 [ 25.000263] Call Trace: [ 25.000268] [] dump_stack+0x67/0x92 [ 25.000271] [] __warn+0xc6/0xe0 [ 25.000274] [] warn_slowpath_fmt+0x4a/0x50 [ 25.000298] [] i915_gem_suspend+0x181/0x190 [i915] [ 25.000314] [] i915_driver_unload+0x1e/0x190 [i915] [ 25.000331] [] i915_pci_remove+0x14/0x20 [i915] [ 25.000334] [] pci_device_remove+0x34/0xb0 [ 25.000339] [] __device_release_driver+0x9c/0x150 [ 25.000340] [] driver_detach+0xb6/0xc0 [ 25.000343] [] bus_remove_driver+0x53/0xd0 [ 25.000345] [] driver_unregister+0x27/0x50 [ 25.000347] [] pci_unregister_driver+0x25/0x70 [ 25.000375] [] i915_exit+0x1a/0x71 [i915] [ 25.000378] [] SyS_delete_module+0x193/0x1e0 [ 25.000380] [] entry_SYSCALL_64_fastpath+0x1c/0xb1 > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Patchwork > Sent: Friday, December 9, 2016 6:53 PM > To: Wang, Elaine > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Respect num_pipes > when install or reset dispaly IRQ > > == Series Details == > > Series: drm/i915: Respect num_pipes when install or reset dispaly IRQ > URL : https://patchwork.freedesktop.org/series/16599/ > State : warning > > == Summary == > > Series 16599v1 drm/i915: Respect num_pipes when install or reset dispaly > IRQ > https://patchwork.freedesktop.org/api/1.0/series/16599/revisions/1/mbox/ > > Test kms_force_connector_basic: > Subgroup force-load-detect: > pass -> DMESG-WARN (fi-ivb-3770) > > fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 > fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 > fi-bxt-t5700 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 > fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 > fi-ilk-650 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52 > fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 > fi-ivb-3770 total:247 pass:225 dwarn:1 dfail:0 fail:0 skip:21 > fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 > fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 > fi-skl-6700k total:247 pass:224 dwarn:3 dfail:0 fail:0 skip:20 > fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 > fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 > fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 > > de43f4e755c6bf50ad53b4ccacedf9850f42eda4 drm-tip: 2016y-12m-09d-09h- > 01m-58s UTC integration manifest ef0b9fd drm/i915: Respect num_pipes > when install or reset dispaly IRQ > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3248/ > ___ > 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] drm/i915: use udelay for very short delays
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: >> > Even on fast systems a 2 microsecond delay is most likely more efficient >> > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - >> > change this to a udelay(2). >> >> Similar concerns as in [1]. We don't need the accuracy of udelay() here, >> so this boils down to which is the better use of CPU. We could probably >> relax the max delay more if that was helpful. But I'm not immediately >> sold on "is most likely more efficient" which sounds like a gut feeling. >> >> I'm sorry it's not clear in my other reply that I do appreciate >> addressing incorrect/silly use of usleep_range(); I'm just not (yet) >> convinced udelay() is the answer. > > if the delay is not critical and all that is needed > is an assurance that it is greater than X us then > usleep_range is fine with a relaxed limit. > So from what you wrote my patch proposal is wrong - the > udelay() is not the way to got. > My intent is to get rid of very small usleep_range() cases > so if usleep_range(20,50) causes no issues with this driver > and does not induce any performance penalty then that would > be the way to go I think. Okay, so I looked at the code, and I looked at our spec, and I looked at the MIPI D-PHY spec, and I cried a little. Long story short, I think usleep_range(10, 50) will be fine. 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] [PATCH] drm/i915: use udelay for very short delays
On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote: > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: > >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > >> > Even on fast systems a 2 microsecond delay is most likely more efficient > >> > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - > >> > change this to a udelay(2). > >> > >> Similar concerns as in [1]. We don't need the accuracy of udelay() here, > >> so this boils down to which is the better use of CPU. We could probably > >> relax the max delay more if that was helpful. But I'm not immediately > >> sold on "is most likely more efficient" which sounds like a gut feeling. > >> > >> I'm sorry it's not clear in my other reply that I do appreciate > >> addressing incorrect/silly use of usleep_range(); I'm just not (yet) > >> convinced udelay() is the answer. > > > > if the delay is not critical and all that is needed > > is an assurance that it is greater than X us then > > usleep_range is fine with a relaxed limit. > > So from what you wrote my patch proposal is wrong - the > > udelay() is not the way to got. > > My intent is to get rid of very small usleep_range() cases > > so if usleep_range(20,50) causes no issues with this driver > > and does not induce any performance penalty then that would > > be the way to go I think. > > Okay, so I looked at the code, and I looked at our spec, and I looked at > the MIPI D-PHY spec, and I cried a little. > > Long story short, I think usleep_range(10, 50) will be fine. Note that I really want to see a comment next to every delay like this documenting the actual hardware requirement, if the delay used by the code doesn't 100% match it. -- 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 2/7] drm/i915: Add support for audio driver notifications
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, December 14, 2016 5:21 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> louis.boss...@linux.intel.com; Ughreja, Rakesh A
>
> Subject: Re: [PATCH 2/7] drm/i915: Add support for audio driver notifications
>
> On Mon, 12 Dec 2016 19:10:38 +0100,
> Jerome Anand wrote:
> >
> > Notifiations like mode change, hot plug and edid to the audio driver
> > are added. This is inturn used by the audio driver for its
> > functionality.
> >
> > A new interface file capturing the notifications needed by the audio
> > driver is added
> >
> > Signed-off-by: Pierre-Louis Bossart
> >
> > Signed-off-by: Jerome Anand
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 3 +++
> > drivers/gpu/drm/i915/intel_audio.c | 8 ++
> > drivers/gpu/drm/i915/intel_hdmi.c | 1 +
> > drivers/gpu/drm/i915/intel_lpe_audio.c | 46
> ++
> > include/drm/intel_lpe_audio.h | 1 +
> > 5 files changed, 59 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 1317834..0dbe91a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3696,6 +3696,9 @@ int intel_lpe_audio_setup(struct
> > drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct
> > drm_i915_private *dev_priv); void intel_lpe_audio_irq_handler(struct
> > drm_i915_private *dev_priv); bool intel_lpe_audio_detect(struct
> > drm_i915_private *dev_priv);
> > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > + void *eld, int port, int tmds_clk_speed,
> > + bool connected);
> >
> > /* intel_i2c.c */
> > extern int intel_setup_gmbus(struct drm_i915_private *dev_priv); diff
> > --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 3bbc96c..77cd086 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "intel_drv.h"
> >
> > #include
> > @@ -630,6 +631,10 @@ void intel_audio_codec_enable(struct
> intel_encoder *intel_encoder,
> > if (acomp && acomp->audio_ops && acomp->audio_ops-
> >pin_eld_notify)
> > acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> >audio_ptr,
> > (int) port, (int) pipe);
> > +
> > + if (HAS_LPE_AUDIO(dev_priv))
> > + intel_lpe_audio_notify(dev_priv, connector->eld, port,
> > + crtc_state->port_clock, true);
> > }
> >
> > /**
> > @@ -663,6 +668,9 @@ void intel_audio_codec_disable(struct
> intel_encoder *intel_encoder)
> > if (acomp && acomp->audio_ops && acomp->audio_ops-
> >pin_eld_notify)
> > acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> >audio_ptr,
> > (int) port, (int) pipe);
> > +
> > + if (HAS_LPE_AUDIO(dev_priv))
> > + intel_lpe_audio_notify(dev_priv, NULL, port, 0, true);
>
> Does it still notify as connected?
>
OK - this will be changed
>
> > }
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 0bcfead..377584e1 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -36,6 +36,7 @@
> > #include
> > #include "intel_drv.h"
> > #include
> > +#include
> > #include "i915_drv.h"
> >
> > static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi
> > *intel_hdmi) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > index e12e5f7..a141a9c 100644
> > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > @@ -361,3 +361,49 @@ void intel_lpe_audio_teardown(struct
> > drm_i915_private *dev_priv)
> >
> > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); }
> > +
> > +
> > +/**
> > + * intel_lpe_audio_notify() - notify lpe audio event
> > + * audio driver and i915
> > + * @dev_priv: the i915 drm device private data
> > + * @eld : ELD data
> > + * @port: port id
> > + * @tmds_clk_speed: tmds clock frequency in Hz
> > + * @connected: hdmi connected/disconnected
> > + *
> > + * Notify lpe audio driver of eld change.
> > + */
> > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > + void *eld, int port, int tmds_clk_speed,
> > + bool connected)
> > +{
> > + unsigned long irq_flags;
> > +
> > + if (HAS_LPE_AUDIO(dev_priv)) {
>
> Just bail out here when !HAS_LPE_AUDIO(). Then the rest needs less
> indentation and will be more readable.
>
OK
> > + struct intel_hdmi_lpe_audio_pdata *pdata =
> dev_get_platdata(
> > +
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Check HAS_PCH_NOP when install or reset dispaly IRQ
Reply to correct thread. The failed case is KBL hang. This patch shouldn't impact platforms that have non-zero num_pipes. So the KBL hang isn't a regression caused by this patch. According to below kernel log before hang (https://intel-gfx-ci.01.org/CI/Patchwork_3266/fi-kbl-7500u/dmesg-during.log), It should be the same issue as Bug 98670 - [BAT] WARN_ON(dev_priv->gt.awake) during drv_module_reload_basic (https://bugs.freedesktop.org/show_bug.cgi?id=98670), [ 25.000193] [ cut here ] [ 25.000227] WARNING: CPU: 3 PID: 6396 at drivers/gpu/drm/i915/i915_gem.c:4241 i915_gem_suspend+0x181/0x190 [i915] [ 25.000228] WARN_ON(dev_priv->gt.awake) [ 25.000229] Modules linked in: [ 25.000231] i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_generic coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei e1000e ptp pps_core i2c_hid [last unloaded: snd_hda_intel] [ 25.000249] CPU: 3 PID: 6396 Comm: drv_module_relo Tainted: G U 4.9.0-rc8-CI-Patchwork_3266+ #1 [ 25.000250] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016 [ 25.000252] c9547d18 81435bf5 c9547d68 [ 25.000256] c9547d58 8107e4d6 1091 880257a3 [ 25.000259] 880257a30068 a01370c0 [ 25.000263] Call Trace: [ 25.000268] [] dump_stack+0x67/0x92 [ 25.000271] [] __warn+0xc6/0xe0 [ 25.000274] [] warn_slowpath_fmt+0x4a/0x50 [ 25.000298] [] i915_gem_suspend+0x181/0x190 [i915] [ 25.000314] [] i915_driver_unload+0x1e/0x190 [i915] [ 25.000331] [] i915_pci_remove+0x14/0x20 [i915] [ 25.000334] [] pci_device_remove+0x34/0xb0 [ 25.000339] [] __device_release_driver+0x9c/0x150 [ 25.000340] [] driver_detach+0xb6/0xc0 [ 25.000343] [] bus_remove_driver+0x53/0xd0 [ 25.000345] [] driver_unregister+0x27/0x50 [ 25.000347] [] pci_unregister_driver+0x25/0x70 [ 25.000375] [] i915_exit+0x1a/0x71 [i915] [ 25.000378] [] SyS_delete_module+0x193/0x1e0 [ 25.000380] [] entry_SYSCALL_64_fastpath+0x1c/0xb1 Thanks, Ealine > -Original Message- > From: Patchwork [mailto:patchw...@emeril.freedesktop.org] > Sent: Monday, December 12, 2016 3:53 PM > To: Wang, Elaine > Cc: intel-gfx@lists.freedesktop.org > Subject: ✗ Fi.CI.BAT: failure for drm/i915: Check HAS_PCH_NOP when install > or reset dispaly IRQ > > == Series Details == > > Series: drm/i915: Check HAS_PCH_NOP when install or reset dispaly IRQ > URL : https://patchwork.freedesktop.org/series/16678/ > State : failure > > == Summary == > > Series 16678v1 drm/i915: Check HAS_PCH_NOP when install or reset dispaly > IRQ > https://patchwork.freedesktop.org/api/1.0/series/16678/revisions/1/mbox/ > > Test drv_module_reload: > Subgroup basic-reload-inject: > pass -> INCOMPLETE (fi-kbl-7500u) > > fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 > fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 > fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 > fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 > fi-ilk-650 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52 > fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 > fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 > fi-kbl-7500u total:7pass:6dwarn:0 dfail:0 fail:0 skip:0 > fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 > fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 > fi-skl-6700k total:247 pass:224 dwarn:3 dfail:0 fail:0 skip:20 > fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 > fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 > > f6a248e2507f98d7eb1f4fec8cfcbf685a33d289 drm-tip: 2016y-12m-10d-21h- > 47m-23s UTC integration manifest 538d2ec drm/i915: Check HAS_PCH_NOP > when install or reset dispaly IRQ > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3266/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, 15 Dec 2016, Ville Syrjälä wrote: > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote: >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: >> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: >> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: >> >> > Even on fast systems a 2 microsecond delay is most likely more efficient >> >> > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - >> >> > change this to a udelay(2). >> >> >> >> Similar concerns as in [1]. We don't need the accuracy of udelay() here, >> >> so this boils down to which is the better use of CPU. We could probably >> >> relax the max delay more if that was helpful. But I'm not immediately >> >> sold on "is most likely more efficient" which sounds like a gut feeling. >> >> >> >> I'm sorry it's not clear in my other reply that I do appreciate >> >> addressing incorrect/silly use of usleep_range(); I'm just not (yet) >> >> convinced udelay() is the answer. >> > >> > if the delay is not critical and all that is needed >> > is an assurance that it is greater than X us then >> > usleep_range is fine with a relaxed limit. >> > So from what you wrote my patch proposal is wrong - the >> > udelay() is not the way to got. >> > My intent is to get rid of very small usleep_range() cases >> > so if usleep_range(20,50) causes no issues with this driver >> > and does not induce any performance penalty then that would >> > be the way to go I think. >> >> Okay, so I looked at the code, and I looked at our spec, and I looked at >> the MIPI D-PHY spec, and I cried a little. >> >> Long story short, I think usleep_range(10, 50) will be fine. > > Note that I really want to see a comment next to every delay like this > documenting the actual hardware requirement, if the delay used by the > code doesn't 100% match it. Our spec says, "Wait for 2us for ULPS to complete". That's a simplistic view wrt D-PHY, and our code doesn't even match the spec. Hence the tears. Want to propose a wording for the comment so we can apply this change, without going for a full rewrite of the sequence? 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] [PATCH 2/7] drm/i915: Add support for audio driver notifications
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, December 14, 2016 6:26 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ti...@suse.de; broo...@kernel.org; Ughreja, Rakesh A
>
> Subject: Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add support for audio driver
> notifications
>
> On Mon, Dec 12, 2016 at 11:40:38PM +0530, Jerome Anand wrote:
> > Notifiations like mode change, hot plug and edid to the audio driver
> > are added. This is inturn used by the audio driver for its
> > functionality.
> >
> > A new interface file capturing the notifications needed by the audio
> > driver is added
> >
> > Signed-off-by: Pierre-Louis Bossart
> >
> > Signed-off-by: Jerome Anand
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 3 +++
> > drivers/gpu/drm/i915/intel_audio.c | 8 ++
> > drivers/gpu/drm/i915/intel_hdmi.c | 1 +
> > drivers/gpu/drm/i915/intel_lpe_audio.c | 46
> ++
> > include/drm/intel_lpe_audio.h | 1 +
> > 5 files changed, 59 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 1317834..0dbe91a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3696,6 +3696,9 @@ int intel_lpe_audio_setup(struct
> > drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct
> > drm_i915_private *dev_priv); void intel_lpe_audio_irq_handler(struct
> > drm_i915_private *dev_priv); bool intel_lpe_audio_detect(struct
> > drm_i915_private *dev_priv);
> > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > + void *eld, int port, int tmds_clk_speed,
> > + bool connected);
> >
> > /* intel_i2c.c */
> > extern int intel_setup_gmbus(struct drm_i915_private *dev_priv); diff
> > --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 3bbc96c..77cd086 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "intel_drv.h"
> >
> > #include
> > @@ -630,6 +631,10 @@ void intel_audio_codec_enable(struct
> intel_encoder *intel_encoder,
> > if (acomp && acomp->audio_ops && acomp->audio_ops-
> >pin_eld_notify)
> > acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> >audio_ptr,
> > (int) port, (int) pipe);
> > +
> > + if (HAS_LPE_AUDIO(dev_priv))
> > + intel_lpe_audio_notify(dev_priv, connector->eld, port,
> > + crtc_state->port_clock, true);
> > }
> >
> > /**
> > @@ -663,6 +668,9 @@ void intel_audio_codec_disable(struct
> intel_encoder *intel_encoder)
> > if (acomp && acomp->audio_ops && acomp->audio_ops-
> >pin_eld_notify)
> > acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> >audio_ptr,
> > (int) port, (int) pipe);
> > +
> > + if (HAS_LPE_AUDIO(dev_priv))
> > + intel_lpe_audio_notify(dev_priv, NULL, port, 0, true);
> > }
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 0bcfead..377584e1 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -36,6 +36,7 @@
> > #include
> > #include "intel_drv.h"
> > #include
> > +#include
> > #include "i915_drv.h"
> >
> > static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi
> > *intel_hdmi) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > index e12e5f7..a141a9c 100644
> > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > @@ -361,3 +361,49 @@ void intel_lpe_audio_teardown(struct
> > drm_i915_private *dev_priv)
> >
> > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); }
> > +
> > +
> > +/**
> > + * intel_lpe_audio_notify() - notify lpe audio event
> > + * audio driver and i915
> > + * @dev_priv: the i915 drm device private data
> > + * @eld : ELD data
> > + * @port: port id
> > + * @tmds_clk_speed: tmds clock frequency in Hz
> > + * @connected: hdmi connected/disconnected
> > + *
> > + * Notify lpe audio driver of eld change.
> > + */
> > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > + void *eld, int port, int tmds_clk_speed,
> > + bool connected)
> > +{
> > + unsigned long irq_flags;
> > +
> > + if (HAS_LPE_AUDIO(dev_priv)) {
> > + struct intel_hdmi_lpe_audio_pdata *pdata =
> dev_get_platdata(
> > + &(dev_priv->lpe_audio.platdev->dev));
>
> Only noticed it here, but why again do we need to re-roll our intel-only
> hdmi/eld notification? The one we have for hda is somewhat justified since it
>
[Intel-gfx] [PATCH 1/1] drm/i915: Print forcewake domain wake counts before reading register
Since wake count is released asynchronously, *drpc_info output indicates blitter wake count to be 1. Print these wake counts before reading registers in *drpc_info. Acked-by: Chris Wilson Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_debugfs.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 7fca6b9..3493c20 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1442,6 +1442,8 @@ static int vlv_drpc_info(struct seq_file *m) struct drm_i915_private *dev_priv = node_to_i915(m->private); u32 rpmodectl1, rcctl1, pw_status; + i915_forcewake_domains(m, NULL); + intel_runtime_pm_get(dev_priv); pw_status = I915_READ(VLV_GTLC_PW_STATUS); @@ -1472,7 +1474,7 @@ static int vlv_drpc_info(struct seq_file *m) seq_printf(m, "Media RC6 residency since boot: %u\n", I915_READ(VLV_GT_MEDIA_RC6)); - return i915_forcewake_domains(m, NULL); + return 0; } static int gen6_drpc_info(struct seq_file *m) @@ -1484,6 +1486,8 @@ static int gen6_drpc_info(struct seq_file *m) unsigned forcewake_count; int count = 0, ret; + i915_forcewake_domains(m, NULL); + ret = mutex_lock_interruptible(&dev->struct_mutex); if (ret) return ret; @@ -1589,7 +1593,7 @@ static int gen6_drpc_info(struct seq_file *m) GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff))); seq_printf(m, "RC6++ voltage: %dmV\n", GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff))); - return i915_forcewake_domains(m, NULL); + return 0; } static int i915_drpc_info(struct seq_file *m, void *unused) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver
> -Original Message- > From: Takashi Iwai [mailto:ti...@suse.de] > Sent: Wednesday, December 14, 2016 6:16 PM > To: Anand, Jerome > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; > ville.syrj...@linux.intel.com; broo...@kernel.org; pierre- > louis.boss...@linux.intel.com; Ughreja, Rakesh A > > Subject: Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver > > On Mon, 12 Dec 2016 19:10:39 +0100, > Jerome Anand wrote: > > > > On Baytrail and Cherrytrail, HDaudio may be fused out or disabled by > > the BIOS. This driver enables an alternate path to the i915 display > > registers and DMA. > > > > Although there is no hardware path between i915 display and LPE/SST > > audio clusters, this HDMI capability is referred to in the > > documentation as "HDMI LPE Audio" so we keep the name for consistency. > > There is no hardware path or control dependencies with the LPE/SST DSP > functionality. > > > > The hdmi-lpe-audio driver will be probed when the i915 driver creates > > a child platform device. > > > > Since this driver is neither SoC nor PCI, a new x86 folder is added > > > > Signed-off-by: Pierre-Louis Bossart > > > > Signed-off-by: Jerome Anand > > Why do we need a "shell" and indirect calls? > This is a small driver set, so it's not utterly unacceptable, but it still > makes > things a bit more complicated than necessary, so I'd like to understand the > idea behind it. > This solution does not use component interface to talk between Audio and i915 driver. The reason for that is the HDMI audio device is created by i915 driver with only one callback pointer passed as pdata. Unlike HDA, the HDMI audio driver does not get loaded if the i915 does not create child device. Since there is only one callback needed we are not using the component interface to make things simpler. This design was co-worked with i915 folks to makes interaction simpler. > > > --- > > sound/Kconfig| 2 + > > sound/Makefile | 2 +- > > sound/x86/Kconfig| 16 + > > sound/x86/Makefile | 8 + > > sound/x86/intel_hdmi_lpe_audio.c | 622 > > +++ > > sound/x86/intel_hdmi_lpe_audio.h | 692 > > +++ > > 6 files changed, 1341 insertions(+), 1 deletion(-) create mode > > 100644 sound/x86/Kconfig create mode 100644 sound/x86/Makefile > > create mode 100644 sound/x86/intel_hdmi_lpe_audio.c create mode > > 100644 sound/x86/intel_hdmi_lpe_audio.h > > > > diff --git a/sound/Kconfig b/sound/Kconfig index 5a240e0..ee2e69a > > 100644 > > --- a/sound/Kconfig > > +++ b/sound/Kconfig > > @@ -108,6 +108,8 @@ source "sound/parisc/Kconfig" > > > > source "sound/soc/Kconfig" > > > > +source "sound/x86/Kconfig" > > + > > endif # SND > > > > menuconfig SOUND_PRIME > > diff --git a/sound/Makefile b/sound/Makefile index c41bdf5..6de45d2 > > 100644 > > --- a/sound/Makefile > > +++ b/sound/Makefile > > @@ -5,7 +5,7 @@ obj-$(CONFIG_SOUND) += soundcore.o > > obj-$(CONFIG_SOUND_PRIME) += oss/ > > obj-$(CONFIG_DMASOUND) += oss/ > > obj-$(CONFIG_SND) += core/ i2c/ drivers/ isa/ pci/ ppc/ arm/ sh/ synth/ > usb/ \ > > - firewire/ sparc/ spi/ parisc/ pcmcia/ mips/ soc/ atmel/ hda/ > > + firewire/ sparc/ spi/ parisc/ pcmcia/ mips/ soc/ atmel/ hda/ x86/ > > obj-$(CONFIG_SND_AOA) += aoa/ > > > > # This one must be compilable even if sound is configured out diff > > --git a/sound/x86/Kconfig b/sound/x86/Kconfig new file mode 100644 > > index 000..182adf3 > > --- /dev/null > > +++ b/sound/x86/Kconfig > > @@ -0,0 +1,16 @@ > > +menuconfig SND_X86 > > + tristate "X86 sound devices" > > + ---help--- > > + > > + X86 sound devices that don't fall under SoC or PCI categories > > + > > +if SND_X86 > > + > > +config HDMI_LPE_AUDIO > > + tristate "HDMI audio without HDaudio on Intel Atom platforms" > > + depends on DRM_I915 > > +default n > > +help > > + Choose this option to support HDMI LPE Audio mode > > Please fix the indentation. Also a bit more description would be more user- > friendly. > OK > > > + > > +endif # SND_X86 > > diff --git a/sound/x86/Makefile b/sound/x86/Makefile new file mode > > 100644 index 000..78b2ae1 > > --- /dev/null > > +++ b/sound/x86/Makefile > > @@ -0,0 +1,8 @@ > > +DRIVER_NAME := hdmi_lpe_audio > > + > > +ccflags-y += -Idrivers/gpu/drm/i915 > > Is it just for intel_lpe_audio.h? Then rather put intel_lpe_audio.h to > include/drm. > OK > > > +$(DRIVER_NAME)-objs += \ > > + intel_hdmi_lpe_audio.o > > + > > +obj-$(CONFIG_HDMI_LPE_AUDIO) += $(DRIVER_NAME).o > > Don't use substitution, it's rather confusing. > Also, we give "snd-" prefix for the sound driver in general. > If no big reason against it, keep this rule please. > > OK > > --- /dev/null > > +++ b/sound/x86/intel_hdmi_lpe_audio.c > (snip) > > @@ -0,0 +1,622 @@ > > +/* > > + * intel_hdmi_lpe_audio.c - Intel HDMI LPE audio driver f
Re: [Intel-gfx] [PATCH 17/34] drm: kselftest for drm_mm and color adjustment
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that after applying the driver's color adjustment, fitting of the
> node and its alignment are still correct.
>
> Signed-off-by: Chris Wilson
> +static void no_color_touching(struct drm_mm_node *node,
> + unsigned long color,
> + u64 *start,
> + u64 *end)
Function name made me think of a bool returning one.
Rather call it "{separate,space}_adjacent_colors" or so.
> +{
> + if (node->allocated && node->color != color)
> + ++*start;
> +
> + node = list_next_entry(node, node_list);
> + if (node->allocated && node->color != color)
> + --*end;
> +}
> +
> +static int igt_color(void *ignored)
> +{
> + node->start += n + 1;
> + rem = node->start;
> + rem %= n + count;
rem = div64...?
If I could keep with the loop variables, should be good;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] ALSA: x86: hdmi: Add audio support for BYT and CHT
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, December 14, 2016 6:26 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> louis.boss...@linux.intel.com; Ughreja, Rakesh A
>
> Subject: Re: [PATCH 4/7] ALSA: x86: hdmi: Add audio support for BYT and CHT
>
> On Mon, 12 Dec 2016 19:10:40 +0100,
> Jerome Anand wrote:
> >
> > Hdmi audio driver based on the child platform device created by gfx
> > driver is implemented.
> > This audio driver is derived from legacy intel hdmi audio driver.
> >
> > The interfaces for interaction between gfx and audio are updated and
> > the driver implementation updated to derive interrupts in its own
> > address space based on irq chip framework
> >
> > Signed-off-by: Pierre-Louis Bossart
> >
> > Signed-off-by: Jerome Anand
> > ---
> > sound/x86/Makefile |2 +
> > sound/x86/intel_hdmi_audio.c | 1907
> ++
> > sound/x86/intel_hdmi_audio.h | 201
> > sound/x86/intel_hdmi_audio_if.c | 551 +++
> > sound/x86/intel_hdmi_lpe_audio.c | 16 +-
> > 5 files changed, 2671 insertions(+), 6 deletions(-) create mode
> > 100644 sound/x86/intel_hdmi_audio.c create mode 100644
> > sound/x86/intel_hdmi_audio.h create mode 100644
> > sound/x86/intel_hdmi_audio_if.c
> >
> > diff --git a/sound/x86/Makefile b/sound/x86/Makefile index
> > 78b2ae1..bc074d0 100644
> > --- a/sound/x86/Makefile
> > +++ b/sound/x86/Makefile
> > @@ -3,6 +3,8 @@ DRIVER_NAME := hdmi_lpe_audio ccflags-y +=
> > -Idrivers/gpu/drm/i915
> >
> > $(DRIVER_NAME)-objs += \
> > + intel_hdmi_audio.o \
> > + intel_hdmi_audio_if.o \
> > intel_hdmi_lpe_audio.o
> >
> > obj-$(CONFIG_HDMI_LPE_AUDIO) += $(DRIVER_NAME).o diff --git
> > a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c new
> file
> > mode 100644 index 000..461b7d7
> > --- /dev/null
> > +++ b/sound/x86/intel_hdmi_audio.c
> > @@ -0,0 +1,1907 @@
> > +/*
> > + * intel_hdmi_audio.c - Intel HDMI audio driver
> > + *
> > + * Copyright (C) 2016 Intel Corp
> > + * Authors: Sailaja Bandarupalli
> > + * Ramesh Babu K V
> > + * Vaibhav Agarwal
> > + * Jerome Anand
> > + *
> >
> +~
>
> > +~
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License as published
> > +by
> > + * the Free Software Foundation; version 2 of the License.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > +but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> GNU
> > + * General Public License for more details.
> > + *
> > + *
> >
> +~
>
> > +~
> > + * ALSA driver for Intel HDMI audio
> > + */
> > +
> > +#define pr_fmt(fmt)"had: " fmt
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "intel_hdmi_audio.h"
> > +
> > +static DEFINE_MUTEX(had_mutex);
> > +
> > +/*standard module options for ALSA. This module supports only one
> > +card*/ static int hdmi_card_index = SNDRV_DEFAULT_IDX1; static char
> > +*hdmi_card_id = SNDRV_DEFAULT_STR1; static struct snd_intelhad
> > +*had_data;
> > +
> > +module_param(hdmi_card_index, int, 0444);
>
> Use module_param_named(index, hdmi_card_index, int, 0444); Ditto for id.
>
OK
> > +MODULE_PARM_DESC(hdmi_card_index,
> > + "Index value for INTEL Intel HDMI Audio controller.");
> > +module_param(hdmi_card_id, charp, 0444);
OK
> > +MODULE_PARM_DESC(hdmi_card_id,
> > + "ID string for INTEL Intel HDMI Audio controller.");
> > +
> > +/*
> > + * ELD SA bits in the CEA Speaker Allocation data block */ static int
> > +eld_speaker_allocation_bits[] = {
> > + [0] = FL | FR,
> > + [1] = LFE,
> > + [2] = FC,
> > + [3] = RL | RR,
> > + [4] = RC,
> > + [5] = FLC | FRC,
> > + [6] = RLC | RRC,
> > + /* the following are not defined in ELD yet */
> > + [7] = 0,
> > +};
> > +
> > +/*
> > + * This is an ordered list!
> > + *
> > + * The preceding ones have better chances to be selected by
> > + * hdmi_channel_allocation().
> > + */
> > +static struct cea_channel_speaker_allocation channel_allocations[] = {
> > +/*channel: 7 6543 21
> > 0 */
> > +{ .ca_index = 0x00, .speakers = { 0,0, 0, 0, 0,0, FR,
> > FL } },
> > + /* 2.1 */
> > +{ .ca_index = 0x01, .speakers = { 0,0, 0, 0, 0, LFE, FR,
> > FL } },
> > + /* Dol
Re: [Intel-gfx] [PATCH 7/7] ALSA: x86: hdmi: continue playback even when display resolution changes
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, December 14, 2016 6:31 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> louis.boss...@linux.intel.com; Ughreja, Rakesh A
>
> Subject: Re: [PATCH 7/7] ALSA: x86: hdmi: continue playback even when
> display resolution changes
>
> On Mon, 12 Dec 2016 19:10:43 +0100,
> Jerome Anand wrote:
> >
> > When the display resolution changes, the drm disables the display
> > pipes due to which audio rendering stops. At this time, we need to
> > ensure the existing audio pointers and buffers are cleared out so that
> > the playback can restarted once the display pipe is enabled with a
> > different N/CTS values
> >
> > Signed-off-by: Pierre-Louis Bossart
> >
> > Signed-off-by: Jerome Anand
> > ---
> > sound/x86/intel_hdmi_audio.c | 21 ++---
> > 1 file changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/sound/x86/intel_hdmi_audio.c
> > b/sound/x86/intel_hdmi_audio.c index 9249521..d6fd638 100644
> > --- a/sound/x86/intel_hdmi_audio.c
> > +++ b/sound/x86/intel_hdmi_audio.c
> > @@ -43,6 +43,7 @@ static DEFINE_MUTEX(had_mutex); static int
> > hdmi_card_index = SNDRV_DEFAULT_IDX1; static char *hdmi_card_id =
> > SNDRV_DEFAULT_STR1; static struct snd_intelhad *had_data;
> > +static int underrun_count;
> >
> > module_param(hdmi_card_index, int, 0444);
> > MODULE_PARM_DESC(hdmi_card_index, @@ -1114,6 +1115,7 @@ static
> int
> > snd_intelhad_open(struct snd_pcm_substream *substream)
> > intelhaddata = snd_pcm_substream_chip(substream);
> > had_stream = intelhaddata->private_data;
> > runtime = substream->runtime;
> > + underrun_count = 0;
> >
> > pm_runtime_get(intelhaddata->dev);
> >
> > @@ -1506,10 +1508,23 @@ static snd_pcm_uframes_t
> > snd_intelhad_pcm_pointer(
> >
> > buf_id = intelhaddata->curr_buf % 4;
> > had_read_register(AUD_BUF_A_LENGTH + (buf_id *
> HAD_REG_WIDTH), &t);
> > - if (t == 0) {
> > - pr_debug("discovered buffer done for buf %d\n", buf_id);
> > - /* had_process_buffer_done(intelhaddata); */
> > +
> > + if ((t == 0) || (t == ((u32)-1L))) {
> > + underrun_count++;
> > + pr_debug("discovered buffer done for buf %d, count =
> %d\n",
> > + buf_id, underrun_count);
> > +
> > + if (underrun_count > (HAD_MIN_PERIODS/2)) {
> > + pr_debug("assume audio_codec_reset, underrun =
> %d - do xrun\n",
> > + underrun_count);
> > + underrun_count = 0;
> > + return SNDRV_PCM_POS_XRUN;
> > + }
> > + } else {
> > + /* Reset Counter */
> > + underrun_count = 0;
> > }
> > +
> > t = intelhaddata->buf_info[buf_id].buf_size - t;
> >
> > if (intelhaddata->stream_info.buffer_rendered)
>
> This change itself is OK, but this made me wonder about the driver
> implementation: the current MAX_PB=1 is the hardware limitation or the
> soft limitation? That is, can't we play back two streams when we connect
> two HDMI monitors?
>
Two streams was never validated from hardware per se. So setting the limitation
in software.
>
> thanks,
>
> Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver
On Thu, 15 Dec 2016 11:55:23 +0100,
Anand, Jerome wrote:
>
>
>
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Wednesday, December 14, 2016 6:16 PM
> > To: Anand, Jerome
> > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> > ville.syrj...@linux.intel.com; broo...@kernel.org; pierre-
> > louis.boss...@linux.intel.com; Ughreja, Rakesh A
> >
> > Subject: Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver
> >
> > On Mon, 12 Dec 2016 19:10:39 +0100,
> > Jerome Anand wrote:
> > >
> > > On Baytrail and Cherrytrail, HDaudio may be fused out or disabled by
> > > the BIOS. This driver enables an alternate path to the i915 display
> > > registers and DMA.
> > >
> > > Although there is no hardware path between i915 display and LPE/SST
> > > audio clusters, this HDMI capability is referred to in the
> > > documentation as "HDMI LPE Audio" so we keep the name for consistency.
> > > There is no hardware path or control dependencies with the LPE/SST DSP
> > functionality.
> > >
> > > The hdmi-lpe-audio driver will be probed when the i915 driver creates
> > > a child platform device.
> > >
> > > Since this driver is neither SoC nor PCI, a new x86 folder is added
> > >
> > > Signed-off-by: Pierre-Louis Bossart
> > >
> > > Signed-off-by: Jerome Anand
> >
> > Why do we need a "shell" and indirect calls?
> > This is a small driver set, so it's not utterly unacceptable, but it still
> > makes
> > things a bit more complicated than necessary, so I'd like to understand the
> > idea behind it.
> >
>
> This solution does not use component interface to talk between
> Audio and i915 driver. The reason for that is the HDMI audio device is
> created
> by i915 driver with only one callback pointer passed as pdata. Unlike HDA,
> the HDMI audio
> driver does not get loaded if the i915 does not create child device.
> Since there is only one callback needed we are not using the component
> interface to make things simpler.
> This design was co-worked with i915 folks to makes interaction simpler.
The interaction between i915 and audio is simple, yes, it just exposes
a few things, mmio ptr, irq, etc. But still I don't understand why
multiple layers of indirect accesses are needed *inside* lpe audio
driver itself. For example, suspend/resume action is cascaded to yet
another ops.
I would understand if this "shell" provides a few thin accessors to
the raw i915 registers. But another layering over a single driver
implementation makes little sense in regard of abstraction. (If there
were multiple class inherits, it's a different story, of course.)
> > > +static inline struct hdmi_lpe_audio_ctx *get_hdmi_context(void) {
> > > + struct hdmi_lpe_audio_ctx *ctx;
> > > +
> > > + ctx = platform_get_drvdata(gpdev);
> > > + return ctx;
> > > +}
> >
> > Hrm... Why not storing the audio pdev in i915 pdata?
> > Then the notify callback can extract it easily.
> >
>
> The current audio driver interface implementation treats the input pdata as
> Read-only and I don't want to store any audio info in that.
Well, it's not read-only, you already write it to register the
notifier callback :)
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915: Print forcewake domain wake counts before reading register
== Series Details == Series: series starting with [1/1] drm/i915: Print forcewake domain wake counts before reading register URL : https://patchwork.freedesktop.org/series/16839/ State : success == Summary == Series 16839v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16839/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-t5700 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ilk-650 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700k total:247 pass:224 dwarn:3 dfail:0 fail:0 skip:20 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 fi-skl-6700hq failed to collect. IGT log at Patchwork_3293/fi-skl-6700hq/igt.log 31b6969819f8ecff09d37a4887b66f47b6fd36d3 drm-tip: 2016y-12m-15d-09h-37m-43s UTC integration manifest 3ccb4dd drm/i915: Print forcewake domain wake counts before reading register == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3293/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, Dec 15, 2016 at 11:51 AM, Nicholas Mc Guire wrote: > On Thu, Dec 15, 2016 at 10:27:59AM +0100, Daniel Vetter wrote: >> On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote: >> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: >> > > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: >> > > > Even on fast systems a 2 microsecond delay is most likely more >> > > > efficient >> > > > as a busy-wait loop. The overhead of a hrtimer does not seem warranted >> > > > - >> > > > change this to a udelay(2). >> > > >> > > Similar concerns as in [1]. We don't need the accuracy of udelay() here, >> > > so this boils down to which is the better use of CPU. We could probably >> > > relax the max delay more if that was helpful. But I'm not immediately >> > > sold on "is most likely more efficient" which sounds like a gut feeling. >> > > >> > > I'm sorry it's not clear in my other reply that I do appreciate >> > > addressing incorrect/silly use of usleep_range(); I'm just not (yet) >> > > convinced udelay() is the answer. >> > >> > So one reason why we unconditionally use *sleep variants is the >> > might_sleep check. Because in the past people have used udelay and mdelay, >> > those delays had to be increased a lot because hw, and at the same time >> > someone added users of these functions to our irq helper, resulting in irq >> > handling times measures in multiple ms. That's not good. >> > >> > So until someone can demonstrate that there's a real benefit (which let's >> > be honest, for modeset code, will never be the case) I very highly prefer >> > to use *sleep* functions. They prevent some silly things from happening by >> > accident. Micro-optimizing modeset code and hampering maitainability in >> > the process is not good. >> >> Also, the entire premise seems backwards: usleep_range is inefficient for >> certain parameter ranges and better replaced with udelay. That makes >> sense. >> >> But why exactly do we not fix udelay_range then, but instead do a cocci >> job crawling through all the thousands of callers? Just fix usleep(_range) >> to use udelay for very small values (and still keep the might_sleep check >> ofc) if that's more efficient! > > its actually not thousands more like a few dozen: There's 1k + usleep* calls you need to audit and teach people how to exactly use it. > usleep_range(min,max) in linux-stable 4.9.0 > > 1648 calls total > 1488 pass numeric values only (90.29%) > 27 min below 10us (1.81%) > 40 min above 10ms (2.68%) > min out of spec 4.50% > 76 preprocessor constants (4.61%) >1 min below 10us (1.31%) >8 min above 10ms (10.52%) > min out of spec 11.84% > 85 expressions (5.15%) > 1(0) min below 10us (1.50%)* > 6(2) min above 10ms (7.50%)* > min out of spec 9.0% > Errors: > 23 where min==max (1.39%) >0 where max < min (0.00%) > > Total: > Bugs: 6.48%-10.70%* > Crit: 3.09%-3.15%* (min < 10 and min==max and max < min) > Detectable by coccinelle: > Bugs: 74/103 (71.8%) > Crit: 50/52 (96.1%) > > *based on estimats as runtime values not known. > > > there is no usleep() as noted in Documentation/timers/timers-howto.txt > - Why not usleep? > On slower systems, (embedded, OR perhaps a speed- > stepped PC!) the overhead of setting up the hrtimers > for usleep *may* not be worth it. Such an evaluation > will obviously depend on your specific situation, but > it is something to be aware of. > > and it suggests to use different API for different ranges - sounds sane > to me and seems to cover the needs of drivers. git grep usleep seems to disagree, at least I see a bunch of usleep() calls. And per Rusty's api usability scale the ultimate fucntion is dwim(). It just feels to me like pushing such trade-off decisions to drivers is bad design because a) the tradeoffs depend upon the cpu you're running on b) driver writers are pretty good at getting such tradeoffs wrong in general. Aiming for a more dwim()-like api for this here makes sense, instead of an eternal fight to correct drivers that get it wrong all the time. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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/7] ALSA: add shell for Intel HDMI LPE audio driver
On Thu, Dec 15, 2016 at 12:14:30PM +0100, Takashi Iwai wrote: > The interaction between i915 and audio is simple, yes, it just exposes > a few things, mmio ptr, irq, etc. But still I don't understand why > multiple layers of indirect accesses are needed *inside* lpe audio > driver itself. For example, suspend/resume action is cascaded to yet > another ops. > I would understand if this "shell" provides a few thin accessors to > the raw i915 registers. But another layering over a single driver > implementation makes little sense in regard of abstraction. (If there > were multiple class inherits, it's a different story, of course.) We saw the same thing with the DSP code as well... signature.asc Description: PGP signature ___ 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: Add support for audio driver notifications
On Thu, Dec 15, 2016 at 10:18:13AM +, Anand, Jerome wrote: > > > > -Original Message- > > From: Takashi Iwai [mailto:ti...@suse.de] > > Sent: Wednesday, December 14, 2016 5:21 PM > > To: Anand, Jerome > > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; > > ville.syrj...@linux.intel.com; broo...@kernel.org; pierre- > > louis.boss...@linux.intel.com; Ughreja, Rakesh A > > > > Subject: Re: [PATCH 2/7] drm/i915: Add support for audio driver > > notifications > > > > On Mon, 12 Dec 2016 19:10:38 +0100, > > Jerome Anand wrote: > > > > > > Notifiations like mode change, hot plug and edid to the audio driver > > > are added. This is inturn used by the audio driver for its > > > functionality. > > > > > > A new interface file capturing the notifications needed by the audio > > > driver is added > > > > > > Signed-off-by: Pierre-Louis Bossart > > > > > > Signed-off-by: Jerome Anand > > > --- > > > drivers/gpu/drm/i915/i915_drv.h| 3 +++ > > > drivers/gpu/drm/i915/intel_audio.c | 8 ++ > > > drivers/gpu/drm/i915/intel_hdmi.c | 1 + > > > drivers/gpu/drm/i915/intel_lpe_audio.c | 46 > > ++ > > > include/drm/intel_lpe_audio.h | 1 + > > > 5 files changed, 59 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > > b/drivers/gpu/drm/i915/i915_drv.h index 1317834..0dbe91a 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.h > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > @@ -3696,6 +3696,9 @@ int intel_lpe_audio_setup(struct > > > drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct > > > drm_i915_private *dev_priv); void intel_lpe_audio_irq_handler(struct > > > drm_i915_private *dev_priv); bool intel_lpe_audio_detect(struct > > > drm_i915_private *dev_priv); > > > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, > > > + void *eld, int port, int tmds_clk_speed, > > > + bool connected); > > > > > > /* intel_i2c.c */ > > > extern int intel_setup_gmbus(struct drm_i915_private *dev_priv); diff > > > --git a/drivers/gpu/drm/i915/intel_audio.c > > > b/drivers/gpu/drm/i915/intel_audio.c > > > index 3bbc96c..77cd086 100644 > > > --- a/drivers/gpu/drm/i915/intel_audio.c > > > +++ b/drivers/gpu/drm/i915/intel_audio.c > > > @@ -24,6 +24,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include "intel_drv.h" > > > > > > #include > > > @@ -630,6 +631,10 @@ void intel_audio_codec_enable(struct > > intel_encoder *intel_encoder, > > > if (acomp && acomp->audio_ops && acomp->audio_ops- > > >pin_eld_notify) > > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops- > > >audio_ptr, > > >(int) port, (int) pipe); > > > + > > > + if (HAS_LPE_AUDIO(dev_priv)) > > > + intel_lpe_audio_notify(dev_priv, connector->eld, port, > > > + crtc_state->port_clock, true); > > > } > > > > > > /** > > > @@ -663,6 +668,9 @@ void intel_audio_codec_disable(struct > > intel_encoder *intel_encoder) > > > if (acomp && acomp->audio_ops && acomp->audio_ops- > > >pin_eld_notify) > > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops- > > >audio_ptr, > > >(int) port, (int) pipe); > > > + > > > + if (HAS_LPE_AUDIO(dev_priv)) > > > + intel_lpe_audio_notify(dev_priv, NULL, port, 0, true); > > > > Does it still notify as connected? > > > > OK - this will be changed The entire 'connected' parameter seems superfluous. Also why aren't we passing 'pipe' along here? How is the audio driver supposed to find the right thing to use? > > > > > > } > > > > > > /** > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > > b/drivers/gpu/drm/i915/intel_hdmi.c > > > index 0bcfead..377584e1 100644 > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > > @@ -36,6 +36,7 @@ > > > #include > > > #include "intel_drv.h" > > > #include > > > +#include > > > #include "i915_drv.h" > > > > > > static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi > > > *intel_hdmi) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c > > > b/drivers/gpu/drm/i915/intel_lpe_audio.c > > > index e12e5f7..a141a9c 100644 > > > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c > > > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c > > > @@ -361,3 +361,49 @@ void intel_lpe_audio_teardown(struct > > > drm_i915_private *dev_priv) > > > > > > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); } > > > + > > > + > > > +/** > > > + * intel_lpe_audio_notify() - notify lpe audio event > > > + * audio driver and i915 > > > + * @dev_priv: the i915 drm device private data > > > + * @eld : ELD data > > > + * @port: port id > > > + * @tmds_clk_speed: tmds clock frequency in Hz > > > + * @connected: hdmi connected/disconnected > > > + * > > > + * Notify lpe audio driver of eld change. > > > + */ > > > +void i
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote: >> On Thu, 15 Dec 2016, Ville Syrjälä wrote: >> > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote: >> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: >> >> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: >> >> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: >> >> >> > Even on fast systems a 2 microsecond delay is most likely more >> >> >> > efficient >> >> >> > as a busy-wait loop. The overhead of a hrtimer does not seem >> >> >> > warranted - >> >> >> > change this to a udelay(2). >> >> >> >> >> >> Similar concerns as in [1]. We don't need the accuracy of udelay() >> >> >> here, >> >> >> so this boils down to which is the better use of CPU. We could probably >> >> >> relax the max delay more if that was helpful. But I'm not immediately >> >> >> sold on "is most likely more efficient" which sounds like a gut >> >> >> feeling. >> >> >> >> >> >> I'm sorry it's not clear in my other reply that I do appreciate >> >> >> addressing incorrect/silly use of usleep_range(); I'm just not (yet) >> >> >> convinced udelay() is the answer. >> >> > >> >> > if the delay is not critical and all that is needed >> >> > is an assurance that it is greater than X us then >> >> > usleep_range is fine with a relaxed limit. >> >> > So from what you wrote my patch proposal is wrong - the >> >> > udelay() is not the way to got. >> >> > My intent is to get rid of very small usleep_range() cases >> >> > so if usleep_range(20,50) causes no issues with this driver >> >> > and does not induce any performance penalty then that would >> >> > be the way to go I think. >> >> >> >> Okay, so I looked at the code, and I looked at our spec, and I looked at >> >> the MIPI D-PHY spec, and I cried a little. >> >> >> >> Long story short, I think usleep_range(10, 50) will be fine. >> > >> > Note that I really want to see a comment next to every delay like this >> > documenting the actual hardware requirement, if the delay used by the >> > code doesn't 100% match it. >> >> Our spec says, "Wait for 2us for ULPS to complete". That's a simplistic >> view wrt D-PHY, and our code doesn't even match the spec. Hence the >> tears. Want to propose a wording for the comment so we can apply this >> change, without going for a full rewrite of the sequence? >> > is that suitable or am I overdoing it ? > > - usleep_range(2, 3); > + /* delay for at least 2us - relaxed to 10-50 to allow > +* hrtimer subsystem to optimize uncritical timer handling > +*/ > + usleep_range(10, 50); I'm fine with that. Or maybe just make it "relaxed to allow" without the values. Jani. > > thx! > hofrat -- 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] [PATCH v2 3/6] drm/atomic: Clean up wait_for_vblanks, v2.
Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
crtc_state after commit. Move it to atomic_state->crtcs.
Also stop re-using new_crtc_state->enable, we can now simply set a
bitmask with crtc_crtc_mask.
Changes since v1:
- Keep last_vblank_count in __drm_crtc_state.
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d19563651e07..88c0986d226a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1110,19 +1110,19 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
int i, ret;
+ unsigned crtc_mask = 0;
- for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
- /* No one cares about the old state, so abuse it for tracking
-* and store whether we hold a vblank reference (and should do a
-* vblank wait) in the ->enable boolean. */
- old_crtc_state->enable = false;
+/*
+ * Legacy cursor ioctls are completely unsynced, and userspace
+ * relies on that (by doing tons of cursor updates).
+ */
+ if (old_state->legacy_cursor_update)
+ return;
- if (!crtc->state->active)
- continue;
+ for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+ struct drm_crtc_state *new_crtc_state = crtc->state;
- /* Legacy cursor ioctls are completely unsynced, and userspace
-* relies on that (by doing tons of cursor updates). */
- if (old_state->legacy_cursor_update)
+ if (!new_crtc_state->active)
continue;
if (!drm_atomic_helper_framebuffer_changed(dev,
@@ -1133,16 +1133,16 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
if (ret != 0)
continue;
- old_crtc_state->enable = true;
- old_crtc_state->last_vblank_count = drm_crtc_vblank_count(crtc);
+ crtc_mask |= drm_crtc_mask(crtc);
+ old_state->crtcs[i].last_vblank_count =
drm_crtc_vblank_count(crtc);
}
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
- if (!old_crtc_state->enable)
+ if (!(crtc_mask & drm_crtc_mask(crtc)))
continue;
ret = wait_event_timeout(dev->vblank[i].queue,
- old_crtc_state->last_vblank_count !=
+ old_state->crtcs[i].last_vblank_count !=
drm_crtc_vblank_count(crtc),
msecs_to_jiffies(50));
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d6d241f63b9f..617f095e31ba 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -145,6 +145,7 @@ struct __drm_crtcs_state {
struct drm_crtc_state *state;
struct drm_crtc_commit *commit;
s64 __user *out_fence_ptr;
+ unsigned last_vblank_count;
};
struct __drm_connnectors_state {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 946672f97e1e..e03d194be086 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -93,8 +93,6 @@ struct drm_plane_helper_funcs;
* @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
* @connector_mask: bitmask of (1 << drm_connector_index(connector)) of
attached connectors
* @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached
encoders
- * @last_vblank_count: for helpers and drivers to capture the vblank of the
- * update to ensure framebuffer cleanup isn't done too early
* @adjusted_mode: for use by helpers and drivers to compute adjusted mode
timings
* @mode: current mode timings
* @mode_blob: &drm_property_blob for @mode
@@ -140,9 +138,6 @@ struct drm_crtc_state {
u32 connector_mask;
u32 encoder_mask;
- /* last_vblank_count: for vblank waits before cleanup */
- u32 last_vblank_count;
-
/* adjusted_mode: for use by helpers and drivers */
struct drm_display_mode adjusted_mode;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, Dec 15, 2016 at 10:34:00AM +, Nicholas Mc Guire wrote: > On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote: > > On Thu, 15 Dec 2016, Ville Syrjälä wrote: > > > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote: > > >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > > >> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: > > >> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > > >> >> > Even on fast systems a 2 microsecond delay is most likely more > > >> >> > efficient > > >> >> > as a busy-wait loop. The overhead of a hrtimer does not seem > > >> >> > warranted - > > >> >> > change this to a udelay(2). > > >> >> > > >> >> Similar concerns as in [1]. We don't need the accuracy of udelay() > > >> >> here, > > >> >> so this boils down to which is the better use of CPU. We could > > >> >> probably > > >> >> relax the max delay more if that was helpful. But I'm not immediately > > >> >> sold on "is most likely more efficient" which sounds like a gut > > >> >> feeling. > > >> >> > > >> >> I'm sorry it's not clear in my other reply that I do appreciate > > >> >> addressing incorrect/silly use of usleep_range(); I'm just not (yet) > > >> >> convinced udelay() is the answer. > > >> > > > >> > if the delay is not critical and all that is needed > > >> > is an assurance that it is greater than X us then > > >> > usleep_range is fine with a relaxed limit. > > >> > So from what you wrote my patch proposal is wrong - the > > >> > udelay() is not the way to got. > > >> > My intent is to get rid of very small usleep_range() cases > > >> > so if usleep_range(20,50) causes no issues with this driver > > >> > and does not induce any performance penalty then that would > > >> > be the way to go I think. > > >> > > >> Okay, so I looked at the code, and I looked at our spec, and I looked at > > >> the MIPI D-PHY spec, and I cried a little. > > >> > > >> Long story short, I think usleep_range(10, 50) will be fine. > > > > > > Note that I really want to see a comment next to every delay like this > > > documenting the actual hardware requirement, if the delay used by the > > > code doesn't 100% match it. > > > > Our spec says, "Wait for 2us for ULPS to complete". That's a simplistic > > view wrt D-PHY, and our code doesn't even match the spec. Hence the > > tears. Want to propose a wording for the comment so we can apply this > > change, without going for a full rewrite of the sequence? > > > is that suitable or am I overdoing it ? > > - usleep_range(2, 3); > + /* delay for at least 2us - relaxed to 10-50 to allow > +* hrtimer subsystem to optimize uncritical timer handling > +*/ That's entirely too verbose IMO, and the reason for using usleep_range() is pretty obvious without spelling it out. All we really want to know is what the spec says is the minimum acceptable delay. > + usleep_range(10, 50); > > thx! > hofrat -- 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 33/34] drm: Fix drm_mm search and insertion
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficiently, we create a secondary index
> for the holes using either their size or their address. This index
> allows us to find the smallest hole or the hole at the bottom or top of
> the range efficiently, whilst keeping the hole stack to rapidly service
> evictions.
>
> Signed-off-by: Chris Wilson
> +static void rm_hole(struct drm_mm_node *node)
> +{
> + if (!node->hole_size)
> + return;
I've actively tried to remove conditions that cause asymmetry between
add_/rm_, create_/destroy_ etc. So I think this should be
DRM_MM_BUG_ON() too.
> +static struct drm_mm_node *best_hole(struct drm_mm *mm, u64 size)
> {
> - struct drm_mm *mm = hole_node->mm;
> - u64 hole_start = drm_mm_hole_node_start(hole_node);
> - u64 hole_end = drm_mm_hole_node_end(hole_node);
> - u64 adj_start = hole_start;
> - u64 adj_end = hole_end;
> + struct rb_node *best = NULL;
> + struct rb_node **link = &mm->holes_size.rb_node;
> + while (*link) {
> + struct rb_node *rb = *link;
> + if (size <= rb_hole_size(rb))
> + link = &rb->rb_left, best = rb;
Single assignment per line, by coding style. And
link = &(best = rb)->rb_left is not better :P
> -int drm_mm_insert_node_in_range_generic(struct drm_mm *mm, struct
> drm_mm_node *node,
> +int drm_mm_insert_node_in_range_generic(struct drm_mm * const mm,
> + struct drm_mm_node * const node,
I really have no stance on the const's, I'll defer to higher powers on
this.
> +void drm_mm_remove_node(struct drm_mm_node *node)
> {
> - return best;
> + rm_hole(prev_node);
> + add_hole(prev_node);
update_hole?
> @@ -799,7 +706,7 @@ bool drm_mm_scan_add_block(struct drm_mm_scan *scan,
> if (adj_end <= adj_start || adj_end - adj_start < scan->size)
> return false;
>
> - if (scan->flags == DRM_MM_CREATE_TOP)
> + if (scan->flags == DRM_MM_INSERT_HIGH)
Flags are usually checked with & if somebody wants to add them later.
Otherwise you could call it "mode".
Somebody else could give this a glance too.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/34] drm/i915: Build DRM range manager selftests for CI
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > Build the struct drm_mm selftests so that we can trivially run them > within our CI. > > Signed-off-by: Chris Wilson "Enable debug, become developer." Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2 06/12] lib/igt_kms: Add support for the IN_FENCE_FD property
On 2016-12-14 11:04 AM, Brian Starkey wrote:
Hi,
On Wed, Dec 14, 2016 at 04:05:03AM -0500, Robert Foss wrote:
Add support dor the IN_FENCE_FD property to enable setting in fences
for atomic
commits.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 20
lib/igt_kms.h | 5 +
2 files changed, 25 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 8aaff5b8..8ca49d86 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -164,6 +164,7 @@ const char
*igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"CRTC_H",
"FB_ID",
"CRTC_ID",
+"IN_FENCE_FD",
"type",
"rotation"
};
@@ -1426,6 +1427,7 @@ void igt_display_init(igt_display_t *display,
int drm_fd)
n_planes++;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+plane->fence_fd = -1;
if (is_atomic == 0) {
display->is_atomic = 1;
@@ -1712,6 +1714,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t
*plane, igt_pipe_t *pipe,
plane->index,
fb_id);
+if (plane->fence_fd >= 0) {
+uint64_t fence_fd = (int64_t) plane->fence_fd;
+igt_atomic_populate_plane_req(req, plane,
IGT_PLANE_IN_FENCE_FD, fence_fd);
Should you reset plane->fence_fd to -1 here? Or tests should
explicitly clear it for each commit?
Resetting it to -1 seems like a good idea to me, if anyone has other
preferences, just give me a shout.
Cheers,
Brian
+}
+
if (plane->fb_changed) {
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID,
fb_id ? crtc_id : 0);
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID,
fb_id);
@@ -2522,6 +2529,19 @@ void igt_plane_set_fb(igt_plane_t *plane,
struct igt_fb *fb)
plane->size_changed = true;
}
+/**
+ * igt_plane_set_fence_fd:
+ * @plane: plane
+ * @fence_fd: fence fd, disable fence_fd by setting it to -1
+ *
+ * This function sets a fence fd to enable a commit to wait for some
event to
+ * occur before completing.
+ */
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd)
+{
+plane->fence_fd = fence_fd;
+}
+
void igt_plane_set_position(igt_plane_t *plane, int x, int y)
{
igt_pipe_t *pipe = plane->pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index dbe81bcb..9766807c 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -225,6 +225,7 @@ enum igt_atomic_plane_properties {
IGT_PLANE_FB_ID,
IGT_PLANE_CRTC_ID,
+ IGT_PLANE_IN_FENCE_FD,
IGT_PLANE_TYPE,
IGT_PLANE_ROTATION,
IGT_NUM_PLANE_PROPS
@@ -284,6 +285,9 @@ typedef struct {
uint32_t src_h;
igt_rotation_t rotation;
+
+/* in fence fd */
+int32_t fence_fd;
uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS];
} igt_plane_t;
@@ -367,6 +371,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe,
void *ptr, size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd);
void igt_plane_set_position(igt_plane_t *plane, int x, int y);
void igt_plane_set_size(igt_plane_t *plane, int w, int h);
void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Check HAS_PCH_NOP when install or reset dispaly IRQ
On ma, 2016-12-12 at 14:57 +0800, Wang Elaine wrote: > From: Elaine Wang > > Some platforms don't have display. To avoid accessing the > non-existent registers, check HAS_PCH_NOP before invoking > display IRQ install or reset function. > > Cc: Chris Wilson > Cc: Joonas Lahtinen > Signed-off-by: Elaine Wang Reviewed-by: Joonas Lahtinen Unless there are objections from Ville or Chris, I'll merge the patch. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 33/34] drm: Fix drm_mm search and insertion
On Thu, Dec 15, 2016 at 02:28:32PM +0200, Joonas Lahtinen wrote: > On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > > @@ -799,7 +706,7 @@ bool drm_mm_scan_add_block(struct drm_mm_scan *scan, > > if (adj_end <= adj_start || adj_end - adj_start < scan->size) > > return false; > > > > - if (scan->flags == DRM_MM_CREATE_TOP) > > + if (scan->flags == DRM_MM_INSERT_HIGH) > > Flags are usually checked with & if somebody wants to add them later. > Otherwise you could call it "mode". Once upon a time, they were intended to be flags. They have since devolved back into a mode. The only suitable argument for my laziness was what if I wanted to add a flag later! -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 v3] drm/i915: Check HAS_PCH_NOP when install or reset dispaly IRQ
On Mon, Dec 12, 2016 at 02:57:44PM +0800, Wang Elaine wrote:
> From: Elaine Wang
>
> Some platforms don't have display. To avoid accessing the
> non-existent registers, check HAS_PCH_NOP before invoking
> display IRQ install or reset function.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by: Elaine Wang
> ---
> drivers/gpu/drm/i915/i915_irq.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 0b119b9..369a038 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2990,8 +2990,10 @@ static void gen8_irq_reset(struct drm_device *dev)
> POWER_DOMAIN_PIPE(pipe)))
> GEN8_IRQ_RESET_NDX(DE_PIPE, pipe);
>
> - GEN5_IRQ_RESET(GEN8_DE_PORT_);
> - GEN5_IRQ_RESET(GEN8_DE_MISC_);
> + if (!HAS_PCH_NOP(dev_priv)) {
> + GEN5_IRQ_RESET(GEN8_DE_PORT_);
> + GEN5_IRQ_RESET(GEN8_DE_MISC_);
> + }
Hmm. These are north side registers so looking at PCH_NOP feels
questionable.
> GEN5_IRQ_RESET(GEN8_PCU_);
>
> if (HAS_PCH_SPLIT(dev_priv))
> @@ -3414,7 +3416,9 @@ static int gen8_irq_postinstall(struct drm_device *dev)
> ibx_irq_pre_postinstall(dev);
>
> gen8_gt_irq_postinstall(dev_priv);
> - gen8_de_irq_postinstall(dev_priv);
> +
> + if (!HAS_PCH_NOP(dev_priv))
> + gen8_de_irq_postinstall(dev_priv);
>
> if (HAS_PCH_SPLIT(dev_priv))
> ibx_irq_postinstall(dev);
> --
> 1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: fully apply WaSkipStolenMemoryFirstPage
Don't even tell the mm allocator to handle the first page of stolen on
the affected platforms. This means that we won't inherit the FB in
case the BIOS decides to put it at the start of stolen. But the BIOS
should not be putting it at the start of stolen since it's going to
get corrupted. I suppose the bug here is that some pixels at the very
top of the screen will be corrupted, so it's not exactly easy to
notice.
We have confirmation that the first page of stolen does actually get
corrupted, so I really think we should do this in order to avoid any
possible future headaches, even if that means losing BIOS framebuffer
inheritance. Let's not use the HW in a way it's not supposed to be
used.
Notice that now ggtt->stolen_usable_size won't reflect the ending
address of the stolen usable range anymore, so we have to fix the
places that rely on this. To simplify, we'll just use U64_MAX.
v2: don't even put the first page on the mm (Chris)
v3: drm_mm_init() takes size instead of end as argument (Ville)
v4: add a comment explaining the reserved ranges (Chris)
use 0 for start and U64_MAX for end when possible (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
Cc: Chris Wilson
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_gem_gtt.h| 10 +-
drivers/gpu/drm/i915/i915_gem_stolen.c | 36 --
drivers/gpu/drm/i915/intel_fbc.c | 2 +-
3 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8965bbb..0055b85 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -315,8 +315,16 @@ struct i915_ggtt {
struct i915_address_space base;
struct io_mapping mappable; /* Mapping to our CPU mappable region */
+ /* Stolen memory is segmented in hardware with different portions
+* offlimits to certain functions.
+*
+* The drm_mm is initialised to the total accessible range, as found
+* from the PCI config. On Broadwell+, this is further restricted to
+* avoid the first page! The upper end of stolen memory is reserved for
+* hardware functions and similarly removed from the accessible range.
+*/
size_t stolen_size; /* Total size of stolen memory */
- size_t stolen_usable_size; /* Total size minus BIOS reserved */
+ size_t stolen_usable_size; /* Total size minus reserved ranges */
size_t stolen_reserved_base;
size_t stolen_reserved_size;
u64 mappable_end; /* End offset that we can CPU map */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index b1c8897..cbbfc64 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -54,12 +54,6 @@ int i915_gem_stolen_insert_node_in_range(struct
drm_i915_private *dev_priv,
if (!drm_mm_initialized(&dev_priv->mm.stolen))
return -ENODEV;
- /* See the comment at the drm_mm_init() call for more about this check.
-* WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
-*/
- if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
- start = 4096;
-
mutex_lock(&dev_priv->mm.stolen_lock);
ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size,
alignment, start, end,
@@ -73,11 +67,8 @@ int i915_gem_stolen_insert_node(struct drm_i915_private
*dev_priv,
struct drm_mm_node *node, u64 size,
unsigned alignment)
{
- struct i915_ggtt *ggtt = &dev_priv->ggtt;
-
return i915_gem_stolen_insert_node_in_range(dev_priv, node, size,
- alignment, 0,
- ggtt->stolen_usable_size);
+ alignment, 0, U64_MAX);
}
void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
@@ -410,7 +401,7 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
{
struct i915_ggtt *ggtt = &dev_priv->ggtt;
unsigned long reserved_total, reserved_base = 0, reserved_size;
- unsigned long stolen_top;
+ unsigned long stolen_usable_start, stolen_top;
mutex_init(&dev_priv->mm.stolen_lock);
@@ -489,20 +480,17 @@ int i915_gem_init_stolen(struct drm_i915_private
*dev_priv)
ggtt->stolen_size >> 10,
(ggtt->stolen_size - reserved_total) >> 10);
- ggtt->stolen_usable_size = ggtt->stolen_size - reserved_total;
+ stolen_usable_start = 0;
+ /* WaSkipStolenMemoryFirstPage:bdw+ */
+ if (INTEL_GEN(dev_priv) >= 8)
+ stolen_usable_start = 4096;
- /*
-* Basic memrange allocator for stolen space.
-*
-*
Re: [Intel-gfx] [PATCH 2/2] drm/i915: fully apply WaSkipStolenMemoryFirstPage
On Thu, Dec 15, 2016 at 11:23:55AM -0200, Paulo Zanoni wrote:
> Don't even tell the mm allocator to handle the first page of stolen on
> the affected platforms. This means that we won't inherit the FB in
> case the BIOS decides to put it at the start of stolen. But the BIOS
> should not be putting it at the start of stolen since it's going to
> get corrupted. I suppose the bug here is that some pixels at the very
> top of the screen will be corrupted, so it's not exactly easy to
> notice.
>
> We have confirmation that the first page of stolen does actually get
> corrupted, so I really think we should do this in order to avoid any
> possible future headaches, even if that means losing BIOS framebuffer
> inheritance. Let's not use the HW in a way it's not supposed to be
> used.
>
> Notice that now ggtt->stolen_usable_size won't reflect the ending
> address of the stolen usable range anymore, so we have to fix the
> places that rely on this. To simplify, we'll just use U64_MAX.
>
> v2: don't even put the first page on the mm (Chris)
> v3: drm_mm_init() takes size instead of end as argument (Ville)
> v4: add a comment explaining the reserved ranges (Chris)
> use 0 for start and U64_MAX for end when possible (Chris)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
> Cc: Chris Wilson
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.h| 10 +-
> drivers/gpu/drm/i915/i915_gem_stolen.c | 36
> --
> drivers/gpu/drm/i915/intel_fbc.c | 2 +-
> 3 files changed, 22 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 8965bbb..0055b85 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -315,8 +315,16 @@ struct i915_ggtt {
> struct i915_address_space base;
> struct io_mapping mappable; /* Mapping to our CPU mappable region */
>
> + /* Stolen memory is segmented in hardware with different portions
> + * offlimits to certain functions.
> + *
> + * The drm_mm is initialised to the total accessible range, as found
> + * from the PCI config. On Broadwell+, this is further restricted to
> + * avoid the first page! The upper end of stolen memory is reserved for
> + * hardware functions and similarly removed from the accessible range.
> + */
> size_t stolen_size; /* Total size of stolen memory */
> - size_t stolen_usable_size; /* Total size minus BIOS reserved */
> + size_t stolen_usable_size; /* Total size minus reserved ranges */
> size_t stolen_reserved_base;
> size_t stolen_reserved_size;
> u64 mappable_end; /* End offset that we can CPU map */
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index b1c8897..cbbfc64 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -54,12 +54,6 @@ int i915_gem_stolen_insert_node_in_range(struct
> drm_i915_private *dev_priv,
> if (!drm_mm_initialized(&dev_priv->mm.stolen))
> return -ENODEV;
>
> - /* See the comment at the drm_mm_init() call for more about this check.
> - * WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
> - */
> - if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
> - start = 4096;
> -
> mutex_lock(&dev_priv->mm.stolen_lock);
> ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size,
> alignment, start, end,
> @@ -73,11 +67,8 @@ int i915_gem_stolen_insert_node(struct drm_i915_private
> *dev_priv,
> struct drm_mm_node *node, u64 size,
> unsigned alignment)
> {
> - struct i915_ggtt *ggtt = &dev_priv->ggtt;
> -
> return i915_gem_stolen_insert_node_in_range(dev_priv, node, size,
> - alignment, 0,
> - ggtt->stolen_usable_size);
> + alignment, 0, U64_MAX);
Just i915_gem_stolen_insert_node() then?
> }
>
> void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
> @@ -410,7 +401,7 @@ int i915_gem_init_stolen(struct drm_i915_private
> *dev_priv)
> {
> struct i915_ggtt *ggtt = &dev_priv->ggtt;
> unsigned long reserved_total, reserved_base = 0, reserved_size;
> - unsigned long stolen_top;
> + unsigned long stolen_usable_start, stolen_top;
>
> mutex_init(&dev_priv->mm.stolen_lock);
>
> @@ -489,20 +480,17 @@ int i915_gem_init_stolen(struct drm_i915_private
> *dev_priv)
> ggtt->stolen_size >> 10,
> (ggtt->stolen_size - reserved_total) >> 10);
>
> - ggtt->stolen_usable_size = ggtt->stolen_size - reserved_total;
> + stolen_
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Optimise VMA lookup slightly (rev2)
On 13/12/2016 17:23, Patchwork wrote: == Series Details == Series: drm/i915: Optimise VMA lookup slightly (rev2) URL : https://patchwork.freedesktop.org/series/16740/ State : warning == Summary == Series 16740v2 drm/i915: Optimise VMA lookup slightly https://patchwork.freedesktop.org/api/1.0/series/16740/revisions/2/mbox/ Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-bsw-n3050) WARN_ON(dev_priv->gt.awake) https://bugs.freedesktop.org/show_bug.cgi?id=98670 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2600) fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:207 dwarn:1 dfail:0 fail:0 skip:39 fi-bxt-t5700 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ilk-650 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:224 dwarn:3 dfail:0 fail:0 skip:20 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 c596a6521837b06a740e894030d11024f391bd6e drm-tip: 2016y-12m-13d-15h-48m-22s UTC integration manifest ee25c15 drm/i915: Optimise VMA lookup slightly Pushed, thanks for the review! Regards, Tvrtko ___ 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: fully apply WaSkipStolenMemoryFirstPage
On Thu, Dec 15, 2016 at 03:26:59PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 15, 2016 at 11:23:55AM -0200, Paulo Zanoni wrote:
> > Don't even tell the mm allocator to handle the first page of stolen on
> > the affected platforms. This means that we won't inherit the FB in
> > case the BIOS decides to put it at the start of stolen. But the BIOS
> > should not be putting it at the start of stolen since it's going to
> > get corrupted. I suppose the bug here is that some pixels at the very
> > top of the screen will be corrupted, so it's not exactly easy to
> > notice.
> >
> > We have confirmation that the first page of stolen does actually get
> > corrupted, so I really think we should do this in order to avoid any
> > possible future headaches, even if that means losing BIOS framebuffer
> > inheritance. Let's not use the HW in a way it's not supposed to be
> > used.
> >
> > Notice that now ggtt->stolen_usable_size won't reflect the ending
> > address of the stolen usable range anymore, so we have to fix the
> > places that rely on this. To simplify, we'll just use U64_MAX.
> >
> > v2: don't even put the first page on the mm (Chris)
> > v3: drm_mm_init() takes size instead of end as argument (Ville)
> > v4: add a comment explaining the reserved ranges (Chris)
> > use 0 for start and U64_MAX for end when possible (Chris)
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
> > Cc: Chris Wilson
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.h| 10 +-
> > drivers/gpu/drm/i915/i915_gem_stolen.c | 36
> > --
> > drivers/gpu/drm/i915/intel_fbc.c | 2 +-
> > 3 files changed, 22 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > index 8965bbb..0055b85 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > @@ -315,8 +315,16 @@ struct i915_ggtt {
> > struct i915_address_space base;
> > struct io_mapping mappable; /* Mapping to our CPU mappable region */
> >
> > + /* Stolen memory is segmented in hardware with different portions
> > +* offlimits to certain functions.
> > +*
> > +* The drm_mm is initialised to the total accessible range, as found
> > +* from the PCI config. On Broadwell+, this is further restricted to
> > +* avoid the first page! The upper end of stolen memory is reserved for
> > +* hardware functions and similarly removed from the accessible range.
> > +*/
> > size_t stolen_size; /* Total size of stolen memory */
> > - size_t stolen_usable_size; /* Total size minus BIOS reserved */
> > + size_t stolen_usable_size; /* Total size minus reserved ranges */
> > size_t stolen_reserved_base;
> > size_t stolen_reserved_size;
> > u64 mappable_end; /* End offset that we can CPU map */
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index b1c8897..cbbfc64 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -54,12 +54,6 @@ int i915_gem_stolen_insert_node_in_range(struct
> > drm_i915_private *dev_priv,
> > if (!drm_mm_initialized(&dev_priv->mm.stolen))
> > return -ENODEV;
> >
> > - /* See the comment at the drm_mm_init() call for more about this check.
> > -* WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
> > -*/
> > - if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
> > - start = 4096;
> > -
> > mutex_lock(&dev_priv->mm.stolen_lock);
> > ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size,
> > alignment, start, end,
> > @@ -73,11 +67,8 @@ int i915_gem_stolen_insert_node(struct drm_i915_private
> > *dev_priv,
> > struct drm_mm_node *node, u64 size,
> > unsigned alignment)
> > {
> > - struct i915_ggtt *ggtt = &dev_priv->ggtt;
> > -
> > return i915_gem_stolen_insert_node_in_range(dev_priv, node, size,
> > - alignment, 0,
> > - ggtt->stolen_usable_size);
> > + alignment, 0, U64_MAX);
>
> Just i915_gem_stolen_insert_node() then?
This is stolen_insert_node() :)
Could be turned into an inline later.
Reviewed-by: Chris Wilson
-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 v2 00/37] drm: Deduplicate fb format information (v2)
On Wed, Dec 14, 2016 at 11:37:46PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 18, 2016 at 09:52:36PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Second installment of my effort to remove the duplicated
> > depth/bpp/pixel_format from drm_framebuffer and just use
> > struct drm_format_info instead.
> >
> > I tried to address all of the review feedback, and collect
> > up all the r-bs I already got. Thanks for the review, guys.
> >
> > Changes since the last version are roughly:
> > * drm_framebuffer_init() now fails if the fb isn't properly prepared
> > * Applied mode cocciry all over to use fb->format more extensively
> > * Dropped a few i915 specific patches that were taken care of the
> > previous item
> > * Took up Laurent's idea that we can just compare the fb->format
> > pointers instead of comparing the fb->format->format values
> > * Added a new .get_format_info() hooks for drivers to provide custom
> > format information + an quick example patch how we'd hook it up
> > for i915 render compression support
> >
> > Link to the previous version:
> > https://lists.freedesktop.org/archives/dri-devel/2016-November/124135.html
> >
> > Entire series is available here:
> > git://github.com/vsyrjala/linux.git fb_format_dedup_2
> >
> > Cc: Alex Deucher
> > Cc: Alexey Brodkin
> > Cc: Ben Skeggs
> > Cc: Ben Widawsky
> > Cc: Brian Starkey
> > Cc: "Christian König"
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: Laurent Pinchart
> > Cc: linux-graphics-maintai...@vmware.com
> > Cc: Liviu Dudau
> > Cc: Mali DP Maintainers
> > Cc: Patrik Jakobsson
> > Cc: Paulo Zanoni
> > Cc: Sinclair Yeh
> > Cc: Thomas Hellstrom
> >
> > Ville Syrjälä (37):
> > drm/i915: Add local 'fb' variables
> > drm/radeon: Add local 'fb' variables
> > drm/radeon: Use DIV_ROUND_UP()
> > drm/mgag200: Add local 'fb' variable
> > drm/ast: Add local 'fb' variables
> > drm/gma500: Add some local 'fb' variables
> > drm/cirrus: Add some local 'fb' variables
> > drm/arcpgu: Add local 'fb' variables
> > drm/arm: Add local 'fb' variables
> > drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail
> > drm/nouveau: Add local 'fb' variables
>
> I've pushed up to here to drm-misc-next. Thanks for the reviews.
>
> I re-ran spatch to regenerate some of the later patches as there had
> been a bit of churn in the code. I've reposted the changed patches,
> and if no one screams I'll be pushing the rest tomorrowish.
>
> > drm/vmwgfx: Populate fb->dev before drm_framebuffer_init()
> > drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
> > drm/vmwgfx: Populate fb->pixel_format
> > drm/qxl: Call drm_helper_mode_fill_fb_struct() before
> > drm_framebuffer_init()
> > drm/virtio: Call drm_helper_mode_fill_fb_struct() before
> > drm_framebuffer_init()
> > drm/i915: Set fb->dev early on for inherited fbs
> > drm: Populate fb->dev from drm_helper_mode_fill_fb_struct()
> > drm: Store a pointer to drm_format_info under drm_framebuffer
> > drm/vmwgfx: Populate fb->format correctly
> > drm/i915: Populate fb->format early for inherited fbs
> > drm: Reject fbs w/o format info in drm_framebuffer_init()
> > drm: Replace drm_format_num_planes() with fb->format->num_planes
> > drm/i915: Eliminate the ugly 'fb?:' constructs from the ilk/skl wm
> > code
> > drm: Replace drm_format_plane_cpp() with fb->format->cpp[]
> > drm/fb_cma_helper: Replace drm_format_info() with fb->format
> > drm/nouveau: Use fb->format rather than drm_format_info()
> > drm/i915: Store a pointer to the pixel format info for fbc
> > drm: Add drm_framebuffer_plane_{width,height}()
> > drm/i915: Use drm_framebuffer_plane_{width,height}() where possible
> > drm: Nuke fb->depth
> > drm: Nuke fb->bits_per_pixel
> > drm: Nuke fb->pixel_format
> > drm: Replace 'format->format' comparisons to just 'format' comparisons
> > drm: Eliminate the useless "non-RGB fb" debug message
And I've just pushed up to here (minus the vmvgfx patches which dropped
out due to Daniel's earlier refactorin).
> > drm: Add mode_config .get_format_info() hook
> > drm/i915: Implement .get_format_info() hook for CCS
I'll hang on to these until we get the i915 CCS thing into shape.
Thanks for the reviews everyone.
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 +-
> > drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +-
> > drivers/gpu/drm/arm/hdlcd_crtc.c| 18 ++--
> > drivers/gpu/drm/arm/malidp_planes.c | 10 +--
> > drivers/gpu/drm/armada/armada_crtc.c| 6 +-
> > drivers/gpu/drm/armada/ar
Re: [Intel-gfx] [PATCH 2/2] drm/i915: fully apply WaSkipStolenMemoryFirstPage
On Thu, Dec 15, 2016 at 01:40:15PM +, Chris Wilson wrote:
> On Thu, Dec 15, 2016 at 03:26:59PM +0200, Ville Syrjälä wrote:
> > On Thu, Dec 15, 2016 at 11:23:55AM -0200, Paulo Zanoni wrote:
> > > Don't even tell the mm allocator to handle the first page of stolen on
> > > the affected platforms. This means that we won't inherit the FB in
> > > case the BIOS decides to put it at the start of stolen. But the BIOS
> > > should not be putting it at the start of stolen since it's going to
> > > get corrupted. I suppose the bug here is that some pixels at the very
> > > top of the screen will be corrupted, so it's not exactly easy to
> > > notice.
> > >
> > > We have confirmation that the first page of stolen does actually get
> > > corrupted, so I really think we should do this in order to avoid any
> > > possible future headaches, even if that means losing BIOS framebuffer
> > > inheritance. Let's not use the HW in a way it's not supposed to be
> > > used.
> > >
> > > Notice that now ggtt->stolen_usable_size won't reflect the ending
> > > address of the stolen usable range anymore, so we have to fix the
> > > places that rely on this. To simplify, we'll just use U64_MAX.
> > >
> > > v2: don't even put the first page on the mm (Chris)
> > > v3: drm_mm_init() takes size instead of end as argument (Ville)
> > > v4: add a comment explaining the reserved ranges (Chris)
> > > use 0 for start and U64_MAX for end when possible (Chris)
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
> > > Cc: Chris Wilson
> > > Signed-off-by: Paulo Zanoni
> > > ---
> > > drivers/gpu/drm/i915/i915_gem_gtt.h| 10 +-
> > > drivers/gpu/drm/i915/i915_gem_stolen.c | 36
> > > --
> > > drivers/gpu/drm/i915/intel_fbc.c | 2 +-
> > > 3 files changed, 22 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > index 8965bbb..0055b85 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > @@ -315,8 +315,16 @@ struct i915_ggtt {
> > > struct i915_address_space base;
> > > struct io_mapping mappable; /* Mapping to our CPU mappable region */
> > >
> > > + /* Stolen memory is segmented in hardware with different portions
> > > + * offlimits to certain functions.
> > > + *
> > > + * The drm_mm is initialised to the total accessible range, as found
> > > + * from the PCI config. On Broadwell+, this is further restricted to
> > > + * avoid the first page! The upper end of stolen memory is reserved for
> > > + * hardware functions and similarly removed from the accessible range.
> > > + */
> > > size_t stolen_size; /* Total size of stolen memory */
> > > - size_t stolen_usable_size; /* Total size minus BIOS reserved */
> > > + size_t stolen_usable_size; /* Total size minus reserved ranges */
> > > size_t stolen_reserved_base;
> > > size_t stolen_reserved_size;
> > > u64 mappable_end; /* End offset that we can CPU map */
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > index b1c8897..cbbfc64 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > @@ -54,12 +54,6 @@ int i915_gem_stolen_insert_node_in_range(struct
> > > drm_i915_private *dev_priv,
> > > if (!drm_mm_initialized(&dev_priv->mm.stolen))
> > > return -ENODEV;
> > >
> > > - /* See the comment at the drm_mm_init() call for more about this check.
> > > - * WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
> > > - */
> > > - if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
> > > - start = 4096;
> > > -
> > > mutex_lock(&dev_priv->mm.stolen_lock);
> > > ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size,
> > > alignment, start, end,
> > > @@ -73,11 +67,8 @@ int i915_gem_stolen_insert_node(struct
> > > drm_i915_private *dev_priv,
> > > struct drm_mm_node *node, u64 size,
> > > unsigned alignment)
> > > {
> > > - struct i915_ggtt *ggtt = &dev_priv->ggtt;
> > > -
> > > return i915_gem_stolen_insert_node_in_range(dev_priv, node, size,
> > > - alignment, 0,
> > > - ggtt->stolen_usable_size);
> > > + alignment, 0, U64_MAX);
> >
> > Just i915_gem_stolen_insert_node() then?
>
> This is stolen_insert_node() :)
/me goes get some coffee...
> Could be turned into an inline later.
>
> Reviewed-by: Chris Wilson
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailma
[Intel-gfx] [drm-tip:drm-tip 902/918] drivers/gpu/drm/drm_fb_cma_helper.c:312:20: error: 'struct drm_framebuffer' has no member named 'fomat'; did you mean 'format'?
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 067324d26ea0a913b18737a702eded1db4b255d0
commit: ca984a998ad3a3b6bf8bf0d89861a6537551aaf2 [902/918] drm/fb_cma_helper:
Replace drm_format_info() with fb->format
config: i386-randconfig-s1-201650 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout ca984a998ad3a3b6bf8bf0d89861a6537551aaf2
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_fb_cma_helper.c: In function 'drm_fb_cma_describe':
>> drivers/gpu/drm/drm_fb_cma_helper.c:312:20: error: 'struct drm_framebuffer'
>> has no member named 'fomat'; did you mean 'format'?
for (i = 0; i < fb->fomat->num_planes; i++) {
^~
vim +312 drivers/gpu/drm/drm_fb_cma_helper.c
306 struct drm_fb_cma *fb_cma = to_fb_cma(fb);
307 int i;
308
309 seq_printf(m, "fb: %dx%d@%4.4s\n", fb->width, fb->height,
310 (char *)&fb->pixel_format);
311
> 312 for (i = 0; i < fb->fomat->num_planes; i++) {
313 seq_printf(m, " %d: offset=%d pitch=%d, obj: ",
314 i, fb->offsets[i], fb->pitches[i]);
315 drm_gem_cma_describe(fb_cma->obj[i], m);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm: Resurrect atomic rmfb code.
There were some issues in i915 preventing rmfb from working correctly. A lot of them are related to hw readout, some others due to keeping crtc active during driver unload: https://intel-gfx-ci.01.org/CI/Trybot_394/ I fixed the POWER_DOMAIN_AUDIO issue because it was easy to do so, but ignored the other failures by disabling all crtc's during driver unload. Daniel Vetter (1): drm: Resurrect atomic rmfb code, v2 Maarten Lankhorst (3): drm/atomic: Delete wrong comment. drm/i915: Fix POWER_DOMAIN_AUDIO refcounting. drm/i915: Disable all crtcs during driver unload. drivers/gpu/drm/drm_atomic.c | 68 +--- drivers/gpu/drm/drm_crtc_internal.h | 1 + drivers/gpu/drm/drm_framebuffer.c| 7 drivers/gpu/drm/i915/i915_drv.c | 5 +++ drivers/gpu/drm/i915/intel_ddi.c | 14 ++-- drivers/gpu/drm/i915/intel_display.c | 4 +++ drivers/gpu/drm/i915/intel_dp_mst.c | 9 ++--- 7 files changed, 85 insertions(+), 23 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Fix POWER_DOMAIN_AUDIO refcounting.
If the crtc was brought up with audio before the driver loads,
then crtc_disable will remove a refcount to audio that doesn't exist
before.
Fortunately we already set power domains on readout, so we can just add
the power domain handling to get_crtc_power_domains, which will update
the power domains correctly in all cases.
This was found when testing module reload on CI with the crtc enabled,
which resulted in the following warn after module reload + modeset:
[ 24.197041] [ cut here ]
[ 24.197075] WARNING: CPU: 0 PID: 99 at
drivers/gpu/drm/i915/intel_runtime_pm.c:1790
intel_display_power_put+0x134/0x140 [i915]
[ 24.197076] Use count on domain AUDIO is already zero
[ 24.197098] CPU: 0 PID: 99 Comm: kworker/u8:2 Not tainted
4.9.0-CI-Trybot_393+ #1
[ 24.197099] Hardware name: /NUC6i5SYB, BIOS
SYSKLi35.86A.0042.2016.0409.1246 04/09/2016
[ 24.197102] Workqueue: events_unbound async_run_entry_fn
[ 24.197105] c93c7688 81435b35 c93c76d8
[ 24.197107] c93c76c8 8107e4d6 06fe5dc36f28
88025dc30054
[ 24.197109] 88025dc36f28 88025dc3 88025dc3
0015
[ 24.197110] Call Trace:
[ 24.197113] [] dump_stack+0x67/0x92
[ 24.197116] [] __warn+0xc6/0xe0
[ 24.197118] [] warn_slowpath_fmt+0x4a/0x50
[ 24.197149] [] intel_display_power_put+0x134/0x140 [i915]
[ 24.197187] [] intel_disable_ddi+0x4d/0x80 [i915]
[ 24.197223] [] intel_encoders_disable.isra.74+0x7f/0x90
[i915]
[ 24.197257] [] haswell_crtc_disable+0x55/0x170 [i915]
[ 24.197292] [] intel_atomic_commit_tail+0x108/0xfd0 [i915]
[ 24.197295] [] ? __lock_is_held+0x66/0x90
[ 24.197330] [] intel_atomic_commit+0x429/0x560 [i915]
[ 24.197332] []
?drm_atomic_add_affected_connectors+0x56/0xf0
[ 24.197334] [] drm_atomic_commit+0x46/0x50
[ 24.197336] [] restore_fbdev_mode+0x147/0x270
[ 24.197337] []
drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70
[ 24.197339] [] drm_fb_helper_set_par+0x28/0x50
[ 24.197374] [] intel_fbdev_set_par+0x13/0x70 [i915]
[ 24.197376] [] fbcon_init+0x57a/0x600
[ 24.197379] [] visual_init+0xd1/0x130
[ 24.197381] [] do_bind_con_driver+0x1bc/0x3a0
[ 24.197384] [] do_take_over_console+0x111/0x180
[ 24.197386] [] do_fbcon_takeover+0x52/0xb0
[ 24.197387] [] fbcon_event_notify+0x723/0x850
[ 24.197390] [] ?__blocking_notifier_call_chain+0x30/0x70
[ 24.197392] [] notifier_call_chain+0x34/0xa0
[ 24.197394] [] __blocking_notifier_call_chain+0x48/0x70
[ 24.197397] [] blocking_notifier_call_chain+0x11/0x20
[ 24.197398] [] fb_notifier_call_chain+0x16/0x20
[ 24.197400] [] register_framebuffer+0x24c/0x330
[ 24.197402] [] drm_fb_helper_initial_config+0x219/0x3c0
[ 24.197436] [] intel_fbdev_initial_config+0x13/0x30 [i915]
[ 24.197438] [] async_run_entry_fn+0x34/0x140
[ 24.197440] [] process_one_work+0x1ec/0x6b0
[ 24.197442] [] ? process_one_work+0x166/0x6b0
[ 24.197445] [] worker_thread+0x49/0x490
[ 24.197447] [] ? process_one_work+0x6b0/0x6b0
[ 24.197448] [] kthread+0xeb/0x110
[ 24.197451] [] ? kthread_park+0x60/0x60
[ 24.197453] [] ret_from_fork+0x27/0x40
[ 24.197476] ---[ end trace bda64b683b8e8162 ]---
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_ddi.c | 14 ++
drivers/gpu/drm/i915/intel_display.c | 4
drivers/gpu/drm/i915/intel_dp_mst.c | 9 ++---
3 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d808a2ccc29e..8c9ce850760b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1835,8 +1835,6 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder,
struct drm_connector_state *conn_state)
{
struct drm_encoder *encoder = &intel_encoder->base;
- struct drm_crtc *crtc = encoder->crtc;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
@@ -1863,10 +1861,8 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder,
intel_edp_drrs_enable(intel_dp, pipe_config);
}
- if (intel_crtc->config->has_audio) {
- intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
+ if (pipe_config->has_audio)
intel_audio_codec_enable(intel_encoder, pipe_config,
conn_state);
- }
}
static void intel_disable_ddi(struct intel_encoder *intel_encoder,
@@ -1874,16 +1870,10 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder,
struct drm_connector_state *old_conn_state)
{
struct drm_encoder *encoder = &intel_encoder->base;
- struct drm_crtc *crtc = encoder->crtc;
- struc
[Intel-gfx] [PATCH 3/4] drm/i915: Disable all crtcs during driver unload.
We may keep the crtc's enabled when userspace unsets all framebuffers but keeps the crtc active. This exposes a WARN in fbc_global disable, and a lot of bugs in our hardware readout code. Solve this by disabling all crtc's for now. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 6428588518aa..bb0d7517b678 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -43,6 +43,7 @@ #include #include +#include #include #include "i915_drv.h" @@ -1282,6 +1283,10 @@ void i915_driver_unload(struct drm_device *dev) intel_display_power_get(dev_priv, POWER_DOMAIN_INIT); + drm_modeset_lock_all(dev); + drm_atomic_helper_disable_all(dev, dev->mode_config.acquire_ctx); + drm_modeset_unlock_all(dev); + i915_driver_unregister(dev_priv); drm_vblank_cleanup(dev); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/atomic: Delete wrong comment.
drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
different from commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 60697482b94c..d1d252261bf1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2195,10 +2195,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
goto out;
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
- /*
-* Unlike commit, check_only does not clean up state.
-* Below we call drm_atomic_state_put for it.
-*/
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_nonblocking_commit(state);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm: Resurrect atomic rmfb code, v2
From: Daniel Vetter
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied from Maarten's patch, but with the slight change to
just use dev->mode_config.funcs->atomic_commit to decide whether to
use the atomic path or not.
v2:
- Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
- Add WARN_ON when atomic_remove_fb fails.
- Always call drm_atomic_state_put.
Signed-off-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c| 64 +
drivers/gpu/drm/drm_crtc_internal.h | 1 +
drivers/gpu/drm/drm_framebuffer.c | 7
3 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d1d252261bf1..23a3845542e1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2059,6 +2059,70 @@ static void complete_crtc_signaling(struct drm_device
*dev,
kfree(fence_state);
}
+int drm_atomic_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);
+ state->acquire_ctx = &ctx;
+
+retry:
+ plane_mask = 0;
+ ret = drm_modeset_lock_all_ctx(dev, &ctx);
+ if (ret)
+ goto unlock;
+
+ drm_for_each_plane(plane, dev) {
+ struct drm_plane_state *plane_state;
+
+ if (plane->state->fb != fb)
+ continue;
+
+ plane_state = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto unlock;
+ }
+
+ drm_atomic_set_fb_for_plane(plane_state, NULL);
+ ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+ if (ret)
+ goto unlock;
+
+ plane_mask |= BIT(drm_plane_index(plane));
+
+ plane->old_fb = plane->fb;
+ }
+
+ if (plane_mask)
+ ret = drm_atomic_commit(state);
+
+unlock:
+ if (plane_mask)
+ drm_atomic_clean_old_fb(dev, plane_mask, ret);
+
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(&ctx);
+ goto retry;
+ }
+
+ drm_atomic_state_put(state);
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+
+ return ret;
+}
+
int drm_mode_atomic_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index cdf6860c9d22..121e250853d2 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -178,6 +178,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
struct drm_property *property, uint64_t *val);
int drm_mode_atomic_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
+int drm_atomic_remove_fb(struct drm_framebuffer *fb);
/* drm_plane.c */
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index cbf0c893f426..c358bf8280a8 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -770,6 +770,12 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
* in this manner.
*/
if (drm_framebuffer_read_refcount(fb) > 1) {
+ if (dev->mode_config.funcs->atomic_commit) {
+ int ret = drm_atomic_remove_fb(fb);
+ WARN(ret, "atomic remove_fb failed with %i\n", ret);
+ goto out;
+ }
+
drm_modeset_lock_all(dev);
/* remove from any CRTC */
drm_for_each_crtc(crtc, dev) {
@@ -787,6 +793,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
drm_modeset_unlock_all(dev);
}
+out:
drm_framebuffer_unreference(fb);
}
EXPORT_SYMBOL(drm_framebuffer_remove);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > > Even on fast systems a 2 microsecond delay is most likely more efficient > > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - > > change this to a udelay(2). > > Similar concerns as in [1]. We don't need the accuracy of udelay() here, > so this boils down to which is the better use of CPU. We could probably > relax the max delay more if that was helpful. But I'm not immediately > sold on "is most likely more efficient" which sounds like a gut feeling. > > I'm sorry it's not clear in my other reply that I do appreciate > addressing incorrect/silly use of usleep_range(); I'm just not (yet) > convinced udelay() is the answer. if the delay is not critical and all that is needed is an assurance that it is greater than X us then usleep_range is fine with a relaxed limit. So from what you wrote my patch proposal is wrong - the udelay() is not the way to got. My intent is to get rid of very small usleep_range() cases so if usleep_range(20,50) causes no issues with this driver and does not induce any performance penalty then that would be the way to go I think. thx! hofrat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote: > On Thu, 15 Dec 2016, Ville Syrjälä wrote: > > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote: > >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > >> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: > >> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > >> >> > Even on fast systems a 2 microsecond delay is most likely more > >> >> > efficient > >> >> > as a busy-wait loop. The overhead of a hrtimer does not seem > >> >> > warranted - > >> >> > change this to a udelay(2). > >> >> > >> >> Similar concerns as in [1]. We don't need the accuracy of udelay() here, > >> >> so this boils down to which is the better use of CPU. We could probably > >> >> relax the max delay more if that was helpful. But I'm not immediately > >> >> sold on "is most likely more efficient" which sounds like a gut feeling. > >> >> > >> >> I'm sorry it's not clear in my other reply that I do appreciate > >> >> addressing incorrect/silly use of usleep_range(); I'm just not (yet) > >> >> convinced udelay() is the answer. > >> > > >> > if the delay is not critical and all that is needed > >> > is an assurance that it is greater than X us then > >> > usleep_range is fine with a relaxed limit. > >> > So from what you wrote my patch proposal is wrong - the > >> > udelay() is not the way to got. > >> > My intent is to get rid of very small usleep_range() cases > >> > so if usleep_range(20,50) causes no issues with this driver > >> > and does not induce any performance penalty then that would > >> > be the way to go I think. > >> > >> Okay, so I looked at the code, and I looked at our spec, and I looked at > >> the MIPI D-PHY spec, and I cried a little. > >> > >> Long story short, I think usleep_range(10, 50) will be fine. > > > > Note that I really want to see a comment next to every delay like this > > documenting the actual hardware requirement, if the delay used by the > > code doesn't 100% match it. > > Our spec says, "Wait for 2us for ULPS to complete". That's a simplistic > view wrt D-PHY, and our code doesn't even match the spec. Hence the > tears. Want to propose a wording for the comment so we can apply this > change, without going for a full rewrite of the sequence? > is that suitable or am I overdoing it ? - usleep_range(2, 3); + /* delay for at least 2us - relaxed to 10-50 to allow +* hrtimer subsystem to optimize uncritical timer handling +*/ + usleep_range(10, 50); thx! hofrat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very small delays
On Thu, Dec 15, 2016 at 10:47:57AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > usleep_range() is intended for delays in the 10us to 10ms range that need
> > good precision. a useleep_range(1, will effectively be no more than an
> > imprecise udelay with some added cache disruption as it will fire more or
> > less immediately - use udelay() here.
> >
> > Fixes: commit be4fc046bed3 ("drm/i915: add VLV DSI PLL Calculations")
> > Signed-off-by: Nicholas Mc Guire
> > ---
> >
> > Problem located by coccinelle
> >
> > The requirement of waiting at least 0.5 us is assured with the udelay(1)
> > here which should be more effective than a usleep_range() - would
> > ndelay(500) make sense here ?
>
> This is in the modeset path, i.e. pretty slow anyway. In this case, the
> point is not to try hard to minimize the wait, the point is to guarantee
> "at least 0.5 us" has passed. If the CPU can do something else,
> including dozing off, in the mean time, great. I think we should stick
> with usleep_range().
well in that case maybe an acceptable solution would be to set it to
some suitable range 10,20 us ? or if not critical preferably even with a large
upper limit.
>
> I think the question is, how do we express this in code? IMO udelay() is
> not the answer.
if the delay need to be kept short then no - then its not the answer
but usleep_ranges(1,2) I think is effectively just an inefficient version
of udelay(1), by the time the timer is setup and the task gives
up the cpu the timer would fire.
>
> And why doesn't usleep_range() kernel-doc mention anything about the
> ranges?
>
interesting - that might be part of the reason there are many findings
Documentation/timers/timers-howto.txt does
SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
* Use usleep_range
thx!
hofrat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: skip the first 4k of stolen memory on everything >= gen8 (rev3)
== Series Details == Series: series starting with [1/2] drm/i915: skip the first 4k of stolen memory on everything >= gen8 (rev3) URL : https://patchwork.freedesktop.org/series/16800/ State : warning == Summary == Series 16800v3 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16800/revisions/3/mbox/ Test drv_module_reload: Subgroup basic-reload-inject: pass -> DMESG-WARN (fi-ilk-650) fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ilk-650 total:247 pass:194 dwarn:1 dfail:0 fail:0 skip:52 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:224 dwarn:3 dfail:0 fail:0 skip:20 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 64353e762935a7ad82867be0e4e80ff2f7bc97e4 drm-tip: 2016y-12m-15d-13h-31m-53s UTC integration manifest 081ddab drm/i915: fully apply WaSkipStolenMemoryFirstPage f4ae312 drm/i915: skip the first 4k of stolen memory on everything >= gen8 == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3294/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: use udelay for very small delays
usleep_range() is intended for delays in the 10us to 10ms range that need
good precision. a useleep_range(1, will effectively be no more than an
imprecise udelay with some added cache disruption as it will fire more or
less immediately - use udelay() here.
Fixes: commit be4fc046bed3 ("drm/i915: add VLV DSI PLL Calculations")
Signed-off-by: Nicholas Mc Guire
---
Problem located by coccinelle
The requirement of waiting at least 0.5 us is assured with the udelay(1)
here which should be more effective than a usleep_range() - would
ndelay(500) make sense here ?
Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915)
Patch is against 4.9.0 (localvrsion-next is next-20161214)
drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 56eff60..0ec040e 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -157,7 +157,7 @@ static void vlv_enable_dsi_pll(struct intel_encoder
*encoder,
config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
/* wait at least 0.5 us after ungating before enabling VCO */
- usleep_range(1, 10);
+ udelay(1);
vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, config->dsi_pll.ctrl);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
Even on fast systems a 2 microsecond delay is most likely more efficient as a busy-wait loop. The overhead of a hrtimer does not seem warranted - change this to a udelay(2). Signed-off-by: Nicholas Mc Guire --- Problem found by coccinelle: Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915) Patch is against 4.9.0 (localversion-next is next-20161214) drivers/gpu/drm/i915/intel_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 5b72c50..19fe86b 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -379,7 +379,7 @@ static void bxt_dsi_device_ready(struct intel_encoder *encoder) val &= ~ULPS_STATE_MASK; val |= (ULPS_STATE_ENTER | DEVICE_READY); I915_WRITE(MIPI_DEVICE_READY(port), val); - usleep_range(2, 3); + udelay(2); /* 3. Exit ULPS */ val = I915_READ(MIPI_DEVICE_READY(port)); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use udelay for very short delays
On Thu, Dec 15, 2016 at 10:27:59AM +0100, Daniel Vetter wrote: > On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote: > > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote: > > > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote: > > > > Even on fast systems a 2 microsecond delay is most likely more efficient > > > > as a busy-wait loop. The overhead of a hrtimer does not seem warranted - > > > > change this to a udelay(2). > > > > > > Similar concerns as in [1]. We don't need the accuracy of udelay() here, > > > so this boils down to which is the better use of CPU. We could probably > > > relax the max delay more if that was helpful. But I'm not immediately > > > sold on "is most likely more efficient" which sounds like a gut feeling. > > > > > > I'm sorry it's not clear in my other reply that I do appreciate > > > addressing incorrect/silly use of usleep_range(); I'm just not (yet) > > > convinced udelay() is the answer. > > > > So one reason why we unconditionally use *sleep variants is the > > might_sleep check. Because in the past people have used udelay and mdelay, > > those delays had to be increased a lot because hw, and at the same time > > someone added users of these functions to our irq helper, resulting in irq > > handling times measures in multiple ms. That's not good. > > > > So until someone can demonstrate that there's a real benefit (which let's > > be honest, for modeset code, will never be the case) I very highly prefer > > to use *sleep* functions. They prevent some silly things from happening by > > accident. Micro-optimizing modeset code and hampering maitainability in > > the process is not good. > > Also, the entire premise seems backwards: usleep_range is inefficient for > certain parameter ranges and better replaced with udelay. That makes > sense. > > But why exactly do we not fix udelay_range then, but instead do a cocci > job crawling through all the thousands of callers? Just fix usleep(_range) > to use udelay for very small values (and still keep the might_sleep check > ofc) if that's more efficient! its actually not thousands more like a few dozen: usleep_range(min,max) in linux-stable 4.9.0 1648 calls total 1488 pass numeric values only (90.29%) 27 min below 10us (1.81%) 40 min above 10ms (2.68%) min out of spec 4.50% 76 preprocessor constants (4.61%) 1 min below 10us (1.31%) 8 min above 10ms (10.52%) min out of spec 11.84% 85 expressions (5.15%) 1(0) min below 10us (1.50%)* 6(2) min above 10ms (7.50%)* min out of spec 9.0% Errors: 23 where min==max (1.39%) 0 where max < min (0.00%) Total: Bugs: 6.48%-10.70%* Crit: 3.09%-3.15%* (min < 10 and min==max and max < min) Detectable by coccinelle: Bugs: 74/103 (71.8%) Crit: 50/52 (96.1%) *based on estimats as runtime values not known. there is no usleep() as noted in Documentation/timers/timers-howto.txt - Why not usleep? On slower systems, (embedded, OR perhaps a speed- stepped PC!) the overhead of setting up the hrtimers for usleep *may* not be worth it. Such an evaluation will obviously depend on your specific situation, but it is something to be aware of. and it suggests to use different API for different ranges - sounds sane to me and seems to cover the needs of drivers. thx! hofrat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Check HAS_PCH_NOP when install or reset dispaly IRQ
On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> On Mon, Dec 12, 2016 at 02:57:44PM +0800, Wang Elaine wrote:
>> From: Elaine Wang
>>
>> Some platforms don't have display. To avoid accessing the
>> non-existent registers, check HAS_PCH_NOP before invoking
>> display IRQ install or reset function.
>>
>> Cc: Chris Wilson
>> Cc: Joonas Lahtinen
>> Signed-off-by: Elaine Wang
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 0b119b9..369a038 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -2990,8 +2990,10 @@ static void gen8_irq_reset(struct drm_device *dev)
>> POWER_DOMAIN_PIPE(pipe)))
>> GEN8_IRQ_RESET_NDX(DE_PIPE, pipe);
>>
>> -GEN5_IRQ_RESET(GEN8_DE_PORT_);
>> -GEN5_IRQ_RESET(GEN8_DE_MISC_);
>> +if (!HAS_PCH_NOP(dev_priv)) {
>> +GEN5_IRQ_RESET(GEN8_DE_PORT_);
>> +GEN5_IRQ_RESET(GEN8_DE_MISC_);
>> +}
>
> Hmm. These are north side registers so looking at PCH_NOP feels
> questionable.
Indeed, num_pipes == 0 isn't exactly the same thing as HAS_PCH_NOP.
Jani.
>
>> GEN5_IRQ_RESET(GEN8_PCU_);
>>
>> if (HAS_PCH_SPLIT(dev_priv))
>> @@ -3414,7 +3416,9 @@ static int gen8_irq_postinstall(struct drm_device *dev)
>> ibx_irq_pre_postinstall(dev);
>>
>> gen8_gt_irq_postinstall(dev_priv);
>> -gen8_de_irq_postinstall(dev_priv);
>> +
>> +if (!HAS_PCH_NOP(dev_priv))
>> +gen8_de_irq_postinstall(dev_priv);
>>
>> if (HAS_PCH_SPLIT(dev_priv))
>> ibx_irq_postinstall(dev);
>> --
>> 1.9.1
--
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 01/14] drm/i915: Track visible planes in a bitmask
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> In a lot of place we wish to know which planes on the crtc are actually
> visible, or how many of them there are. Let's start tracking that in a
> bitmask in the crtc state.
>
> We already track enabled planes (ie. ones with an fb and crtc specified by
> the user) but that's not quite the same thing as enabled planes may
> still end up being invisible due to clipping and whatnot.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 6 +++
> drivers/gpu/drm/i915/intel_display.c | 79
> +--
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> 3 files changed, 64 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index dbe9fb41ae53..7ec12edda4d4 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -181,6 +181,12 @@ static int intel_plane_atomic_check(struct drm_plane
> *plane,
> if (ret)
> return ret;
>
> + /* FIXME pre-g4x don't work like this */
> + if (intel_state->base.visible)
> + crtc_state->active_planes |= BIT(intel_plane->id);
> + else
> + crtc_state->active_planes &= ~BIT(intel_plane->id);
> +
> return intel_plane_atomic_calc_changes(&crtc_state->base, state);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bc1af87789bc..3f027341b0f3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2741,6 +2741,29 @@ update_state_fb(struct drm_plane *plane)
> }
>
> static void
> +intel_set_plane_visible(struct intel_crtc_state *crtc_state,
> + struct intel_plane_state *plane_state,
> + bool visible)
> +{
> + struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> +
> + plane_state->base.visible = visible;
> +
> + /* FIXME pre-g4x don't work like this */
> + if (visible) {
> + crtc_state->base.plane_mask |=
> BIT(drm_plane_index(&plane->base));
> + crtc_state->active_planes |= BIT(plane->id);
> + } else {
> + crtc_state->base.plane_mask &=
> ~BIT(drm_plane_index(&plane->base));
> + crtc_state->active_planes &= ~BIT(plane->id);
> + }
> +
> + DRM_DEBUG_KMS("%s active planes 0x%x\n",
> + crtc_state->base.crtc->name,
> + crtc_state->active_planes);
> +}
> +
> +static void
> intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
>struct intel_initial_plane_config *plane_config)
> {
> @@ -2798,8 +2821,9 @@ intel_find_initial_plane_obj(struct intel_crtc
> *intel_crtc,
>* simplest solution is to just disable the primary plane now and
>* pretend the BIOS never had it enabled.
>*/
> - to_intel_plane_state(plane_state)->base.visible = false;
> - crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
> + intel_set_plane_visible(to_intel_crtc_state(crtc_state),
> + to_intel_plane_state(plane_state),
> + false);
> intel_pre_disable_primary_noatomic(&intel_crtc->base);
> intel_plane->disable_plane(primary, &intel_crtc->base);
>
> @@ -2826,7 +2850,11 @@ intel_find_initial_plane_obj(struct intel_crtc
> *intel_crtc,
> drm_framebuffer_reference(fb);
> primary->fb = primary->state->fb = fb;
> primary->crtc = primary->state->crtc = &intel_crtc->base;
> - intel_crtc->base.state->plane_mask |= (1 << drm_plane_index(primary));
> +
> + intel_set_plane_visible(to_intel_crtc_state(intel_crtc->base.state),
> + to_intel_plane_state(primary->state),
> + true);
> +
> atomic_or(to_intel_plane(primary)->frontbuffer_bit,
> &obj->frontbuffer_bits);
> }
> @@ -12440,11 +12468,11 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc_state);
> struct drm_crtc *crtc = crtc_state->crtc;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct drm_plane *plane = plane_state->plane;
> + struct intel_plane *plane = to_intel_plane(plane_state->plane);
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_plane_state *old_plane_state =
> - to_intel_plane_state(plane->state);
> + to_intel_plane_state(plane->base.state);
> bool mode_changed = needs_modeset(crtc_state);
> bool was_crtc_enabled = crtc->state->active;
> bool is_crtc_enabled = crtc_state->active;
> @@ -12452,7 +12480,7 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc
Re: [Intel-gfx] [PATCH 02/14] drm/i915: Track plane fifo sizes under intel_crtc
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Track the plane fifo sizes under intel_crtc instead of under each
> intel_plane. Avoids looping over the planes in a bunch of places,
> and later we'll move this tracking into the crtc state properly.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_drv.h | 7 ++-
> drivers/gpu/drm/i915/intel_pm.c | 115
> ---
> 2 files changed, 54 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 20ba8f48bc3b..69b6f45e3eed 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -683,6 +683,10 @@ struct vlv_wm_state {
> bool cxsr;
> };
>
> +struct vlv_fifo_state {
> + uint16_t plane[I915_MAX_PLANES];
> +};
> +
> struct intel_crtc {
> struct drm_crtc base;
> enum pipe pipe;
> @@ -732,6 +736,8 @@ struct intel_crtc {
>
> /* allow CxSR on this pipe */
> bool cxsr_allowed;
> +
> + struct vlv_fifo_state fifo_state;
> } wm;
>
> int scanline_offset;
> @@ -765,7 +771,6 @@ struct intel_plane_wm_parameters {
> bool scaled;
> u64 tiling;
> unsigned int rotation;
> - uint16_t fifo_size;
> };
intel_plane_wm_parameters can be removed entirely, fifo_size was the only
member still being used there.
> struct intel_plane {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 06e55967f180..26af87f82608 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -393,15 +393,14 @@ static const int pessimal_latency_ns = 5000;
> #define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
> dsparb) >> (lo_shift)) & 0xff) | dsparb2) >> (hi_shift)) & 0x1)
> << 8))
>
> -static int vlv_get_fifo_size(struct intel_plane *plane)
> +static void vlv_get_fifo_size(struct intel_crtc *crtc)
> {
> - struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - int sprite0_start, sprite1_start, size;
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + struct vlv_fifo_state *fifo_state = &crtc->wm.fifo_state;
> + enum pipe pipe = crtc->pipe;
> + int sprite0_start, sprite1_start;
>
> - if (plane->id == PLANE_CURSOR)
> - return 63;
> -
> - switch (plane->pipe) {
> + switch (pipe) {
> uint32_t dsparb, dsparb2, dsparb3;
> case PIPE_A:
> dsparb = I915_READ(DSPARB);
> @@ -422,26 +421,21 @@ static int vlv_get_fifo_size(struct intel_plane *plane)
> sprite1_start = VLV_FIFO_START(dsparb3, dsparb2, 8, 20);
> break;
> default:
> - return 0;
> + MISSING_CASE(pipe);
> + return;
> }
>
> - switch (plane->id) {
> - case PLANE_PRIMARY:
> - size = sprite0_start;
> - break;
> - case PLANE_SPRITE0:
> - size = sprite1_start - sprite0_start;
> - break;
> - case PLANE_SPRITE1:
> - size = 512 - 1 - sprite1_start;
> - break;
> - default:
> - return 0;
> - }
> -
> - DRM_DEBUG_KMS("%s FIFO size: %d\n", plane->base.name, size);
> + fifo_state->plane[PLANE_PRIMARY] = sprite0_start;
> + fifo_state->plane[PLANE_SPRITE0] = sprite1_start - sprite0_start;
> + fifo_state->plane[PLANE_SPRITE1] = 511 - sprite1_start;
> + fifo_state->plane[PLANE_CURSOR] = 63;
>
> - return size;
> + DRM_DEBUG_KMS("Pipe %c FIFO size: %d/%d/%d/%d\n",
> + pipe_name(pipe),
> + fifo_state->plane[PLANE_PRIMARY],
> + fifo_state->plane[PLANE_SPRITE0],
> + fifo_state->plane[PLANE_SPRITE1],
> + fifo_state->plane[PLANE_CURSOR]);
> }
>
> static int i9xx_get_fifo_size(struct drm_i915_private *dev_priv, int plane)
> @@ -1019,8 +1013,9 @@ static uint16_t vlv_compute_wm_level(const struct
> intel_crtc_state *crtc_state,
>
> static void vlv_compute_fifo(struct intel_crtc *crtc)
> {
> - struct drm_device *dev = crtc->base.dev;
> struct vlv_wm_state *wm_state = &crtc->wm_state;
> + struct vlv_fifo_state *fifo_state = &crtc->wm.fifo_state;
> + struct drm_device *dev = crtc->base.dev;
> struct intel_plane *plane;
> unsigned int total_rate = 0;
> const int fifo_size = 512 - 1;
> @@ -1030,7 +1025,7 @@ static void vlv_compute_fifo(struct intel_crtc *crtc)
> struct intel_plane_state *state =
> to_intel_plane_state(plane->base.state);
>
> - if (plane->base.type == DRM_PLANE_TYPE_CURSOR)
> + if (plane->id == PLANE_CURSOR)
> continue;
>
> if (state->base.visible) {
> @@ -1044,19 +1039,19 @@ static void vlv_compute_fifo(struct intel_crtc *crtc)
>
Re: [Intel-gfx] [PATCH 01/14] drm/i915: Track visible planes in a bitmask
On Thu, Dec 15, 2016 at 03:56:03PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > In a lot of place we wish to know which planes on the crtc are actually
> > visible, or how many of them there are. Let's start tracking that in a
> > bitmask in the crtc state.
> >
> > We already track enabled planes (ie. ones with an fb and crtc specified by
> > the user) but that's not quite the same thing as enabled planes may
> > still end up being invisible due to clipping and whatnot.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 6 +++
> > drivers/gpu/drm/i915/intel_display.c | 79
> > +--
> > drivers/gpu/drm/i915/intel_drv.h | 3 ++
> > 3 files changed, 64 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > index dbe9fb41ae53..7ec12edda4d4 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > @@ -181,6 +181,12 @@ static int intel_plane_atomic_check(struct drm_plane
> > *plane,
> > if (ret)
> > return ret;
> >
> > + /* FIXME pre-g4x don't work like this */
> > + if (intel_state->base.visible)
> > + crtc_state->active_planes |= BIT(intel_plane->id);
> > + else
> > + crtc_state->active_planes &= ~BIT(intel_plane->id);
> > +
> > return intel_plane_atomic_calc_changes(&crtc_state->base, state);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bc1af87789bc..3f027341b0f3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2741,6 +2741,29 @@ update_state_fb(struct drm_plane *plane)
> > }
> >
> > static void
> > +intel_set_plane_visible(struct intel_crtc_state *crtc_state,
> > + struct intel_plane_state *plane_state,
> > + bool visible)
> > +{
> > + struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > +
> > + plane_state->base.visible = visible;
> > +
> > + /* FIXME pre-g4x don't work like this */
> > + if (visible) {
> > + crtc_state->base.plane_mask |=
> > BIT(drm_plane_index(&plane->base));
> > + crtc_state->active_planes |= BIT(plane->id);
> > + } else {
> > + crtc_state->base.plane_mask &=
> > ~BIT(drm_plane_index(&plane->base));
> > + crtc_state->active_planes &= ~BIT(plane->id);
> > + }
> > +
> > + DRM_DEBUG_KMS("%s active planes 0x%x\n",
> > + crtc_state->base.crtc->name,
> > + crtc_state->active_planes);
> > +}
> > +
> > +static void
> > intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
> > struct intel_initial_plane_config *plane_config)
> > {
> > @@ -2798,8 +2821,9 @@ intel_find_initial_plane_obj(struct intel_crtc
> > *intel_crtc,
> > * simplest solution is to just disable the primary plane now and
> > * pretend the BIOS never had it enabled.
> > */
> > - to_intel_plane_state(plane_state)->base.visible = false;
> > - crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
> > + intel_set_plane_visible(to_intel_crtc_state(crtc_state),
> > + to_intel_plane_state(plane_state),
> > + false);
> > intel_pre_disable_primary_noatomic(&intel_crtc->base);
> > intel_plane->disable_plane(primary, &intel_crtc->base);
> >
> > @@ -2826,7 +2850,11 @@ intel_find_initial_plane_obj(struct intel_crtc
> > *intel_crtc,
> > drm_framebuffer_reference(fb);
> > primary->fb = primary->state->fb = fb;
> > primary->crtc = primary->state->crtc = &intel_crtc->base;
> > - intel_crtc->base.state->plane_mask |= (1 << drm_plane_index(primary));
> > +
> > + intel_set_plane_visible(to_intel_crtc_state(intel_crtc->base.state),
> > + to_intel_plane_state(primary->state),
> > + true);
> > +
> > atomic_or(to_intel_plane(primary)->frontbuffer_bit,
> > &obj->frontbuffer_bits);
> > }
> > @@ -12440,11 +12468,11 @@ int intel_plane_atomic_calc_changes(struct
> > drm_crtc_state *crtc_state,
> > struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc_state);
> > struct drm_crtc *crtc = crtc_state->crtc;
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > - struct drm_plane *plane = plane_state->plane;
> > + struct intel_plane *plane = to_intel_plane(plane_state->plane);
> > struct drm_device *dev = crtc->dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct intel_plane_state *old_plane_state =
> > - to_intel_plane_state(plane->state);
> > + to_intel_plane_state(plane->base.state);
> > bool mode_changed = needs_modeset(crtc_sta
Re: [Intel-gfx] [PATCH i-g-t] tests: Add kms_plane_blinker
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > Add a test to try out all the different plane enable/disable > order permutations. > > Signed-off-by: Ville Syrjälä Didn't look through the test, but sounds like kms_atomic_transitions.plane-*-transition-* ? Although that one tests a few more edge cases like modeset disable and nonblocking updates.. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/atomic: Delete wrong comment.
On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
> different from commit.
>
> Signed-off-by: Maarten Lankhorst
I think it'd be good to update the kerneldoc for the atomic_commit
callback to mention that drivers should grab their own references using
drm_atomic_state_get() when they need it.
Applied this one meanwhile, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 60697482b94c..d1d252261bf1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2195,10 +2195,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> goto out;
>
> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> - /*
> - * Unlike commit, check_only does not clean up state.
> - * Below we call drm_atomic_state_put for it.
> - */
> ret = drm_atomic_check_only(state);
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_nonblocking_commit(state);
> --
> 2.7.4
>
> ___
> 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 i-g-t] tests: Add kms_plane_blinker
On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote: > Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > Add a test to try out all the different plane enable/disable > > order permutations. > > > > Signed-off-by: Ville Syrjälä > Didn't look through the test, but sounds like > > kms_atomic_transitions.plane-*-transition-* ? > > Although that one tests a few more edge cases like modeset disable and > nonblocking updates.. I don't immediately see where it would try all the permutations, nor can I see any crc_nonblock() stuff so doesn't seem like it could even spot transient errors. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/4] lib/debugfs: Check if debufs is already mounted before attempting to mount it
From: Ville Syrjälä
mount("/sys/kernel/debug") will return an error if something is already
mounted there. So let's check for that before calling mount(). This
allows many of the tools (eg. intel_reg) to work even when no drm
drivers are loaded since the earlier "/sys/kernel/debug/dri" & co.
path checks will fail in that case and we will fall back to attempting
to mount debugfs ourselves.
Signed-off-by: Ville Syrjälä
---
lib/igt_debugfs.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 3d92c6a10a41..5b3167581054 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -89,6 +89,22 @@ typedef struct {
char dri_path[128];
} igt_debugfs_t;
+static bool is_mountpoint(const char *path)
+{
+ char buf[strlen(path) + 4];
+ dev_t dot_dev, dotdot_dev;
+ struct stat st;
+
+ igt_assert_lt(snprintf(buf, sizeof(buf), "%s/.", path), sizeof(buf));
+ igt_assert_eq(stat(buf, &st), 0);
+ dot_dev = st.st_dev;
+
+ igt_assert_lt(snprintf(buf, sizeof(buf), "%s/..", path), sizeof(buf));
+ igt_assert_eq(stat(buf, &st), 0);
+ dotdot_dev = st.st_dev;
+
+ return dot_dev != dotdot_dev;
+}
/**
* igt_debugfs_mount:
@@ -109,8 +125,9 @@ const char *igt_debugfs_mount(void)
if (stat("/sys/kernel/debug/dri", &st) == 0)
return "/sys/kernel/debug";
- igt_assert(stat("/sys/kernel/debug", &st) == 0);
- igt_assert(mount("debug", "/sys/kernel/debug", "debugfs", 0, 0) == 0);
+ igt_assert(is_mountpoint("/sys/kernel/debug") ||
+ mount("debug", "/sys/kernel/debug", "debugfs", 0, 0) == 0);
+
return "/sys/kernel/debug";
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/4] tools/intel_reg: Dump some interesting CCK regs on VLV/CHV
From: Ville Syrjälä
CCK houses various important clock related registers. Let's
dump those as well.
Signed-off-by: Ville Syrjälä
---
tools/registers/cherryview | 1 +
tools/registers/valleyview | 1 +
tools/registers/vlv_cck.txt | 11 +++
3 files changed, 13 insertions(+)
create mode 100644 tools/registers/vlv_cck.txt
diff --git a/tools/registers/cherryview b/tools/registers/cherryview
index 9b94d026b584..47d79acf9c79 100644
--- a/tools/registers/cherryview
+++ b/tools/registers/cherryview
@@ -6,4 +6,5 @@ chv_display_base.txt
chv_dpio_phy_x2.txt
chv_dpio_phy_x1.txt
vlv_dsi.txt
+vlv_cck.txt
gen7_other.txt
diff --git a/tools/registers/valleyview b/tools/registers/valleyview
index 2611a982a7ef..a4722f54f8eb 100644
--- a/tools/registers/valleyview
+++ b/tools/registers/valleyview
@@ -4,4 +4,5 @@ vlv_display_base.txt
vlv_dpio_phy.txt
vlv_dsi.txt
vlv_flisdsi.txt
+vlv_cck.txt
gen7_other.txt
diff --git a/tools/registers/vlv_cck.txt b/tools/registers/vlv_cck.txt
new file mode 100644
index ..60bcdc7f17ba
--- /dev/null
+++ b/tools/registers/vlv_cck.txt
@@ -0,0 +1,11 @@
+('CCK_FUSE_0', '0x08', 'CCK')
+('CCK_DSI_PLL_FUSE', '0x44', 'CCK')
+('CCK_DSI_PLL_CONTROL','0x48', 'CCK')
+('CCK_DSI_PLL_DIVIDER','0x4c', 'CCK')
+('CCK_CZ_CLOCK_CONTROL', '0x62', 'CCK')
+('CCK_GPLL_CLOCK_CONTROL', '0x67', 'CCK')
+('CCK_DISPLAY_CLOCK_CONTROL', '0x6b', 'CCK')
+('CCK_DISPLAY_REF_CLOCK_CONTROL', '0x6c', 'CCK')
+('CCK_MIPI_ESCAPE_CONTROL','0x6d', 'CCK')
+('CCK_DSI0_CONTROL', '0x6e', 'CCK')
+('CCK_DSI1_CONTROL', '0x6f', 'CCK')
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/4] tools/intel_bios_reader: Dump the DSI video transfer mode and pixel overlap
From: Ville Syrjälä
Knowing how were trasmitting the data is pretty important, so let's
dump out the video transfer mode and pixel overlap for DSI.
Signed-off-by: Ville Syrjälä
---
tools/intel_bios.h| 3 ++-
tools/intel_bios_reader.c | 8 ++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index 324ef4a759b4..ca0d2c587120 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -743,7 +743,8 @@ struct mipi_config {
/* 2 byte Port Description */
uint16_t dual_link:2;
uint16_t lane_cnt:2;
- uint16_t rsvd3:12;
+ uint16_t pixel_overlap:3;
+ uint16_t rsvd3:9;
/* 2 byte DSI COntroller params */
/* 0 - Using DSI PHY, 1 - TE usage */
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index d5297e27c3e7..3455296bc008 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -1046,12 +1046,16 @@ static void dump_mipi_config(struct context *context,
printf("RGB888\n");
printf("\t\t PPS GPIO Pins: %s \n", config->pwm_blc ? "Using SOC" :
"Using PMIC");
printf("\t\t CABC Support: %s\n", config->cabc ? "supported" : "not
supported");
- //insert video mode type
printf("\t\t Mode: %s\n", config->cmd_mode ? "COMMAND" : "VIDEO");
+ printf("\t\t Video transfer mode: %s (0x%x)\n",
+ config->vtm == 1 ? "non-burst with sync pulse" :
+ config->vtm == 2 ? "non-burst with sync events" :
+ config->vtm == 3 ? "burst" : "",
+ config->vtm);
printf("\t\t Dithering: %s\n", config->dithering ? "done in Display
Controller" : "done in Panel Controller");
printf("\tPort Desc\n");
- //insert pixel overlap count
+ printf("\t\t Pixel overlap: %d\n", config->pixel_overlap);
printf("\t\t Lane Count: %d\n", config->lane_cnt + 1);
printf("\t\t Dual Link Support: ");
if (config->dual_link == 0)
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/4] tools/intel_display_poller: Allow the tool to be used without i915 loaded
From: Ville Syrjälä
We don't need the drm fd to find out the PCI device ID. So let's drop
the drm stuff, which allows the tool to work without i915 loaded.
Signed-off-by: Ville Syrjälä
---
tools/intel_display_poller.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/intel_display_poller.c b/tools/intel_display_poller.c
index eab17c52428e..2129c613652d 100644
--- a/tools/intel_display_poller.c
+++ b/tools/intel_display_poller.c
@@ -961,7 +961,7 @@ static void __attribute__((noreturn)) usage(const char
*name)
int main(int argc, char *argv[])
{
- int fd, i;
+ int i;
int pipe = 0, bit = 0, target_scanline = 0, target_fuzz = 1;
bool test_pixelcount = false;
uint32_t devid;
@@ -1045,9 +1045,7 @@ int main(int argc, char *argv[])
}
}
- fd = drm_open_driver(DRIVER_INTEL);
- devid = intel_get_drm_devid(fd);
- close(fd);
+ devid = intel_get_pci_device()->device_id;
/*
* check if the requires registers are
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/14] drm/i915: Compute vlv/chv wms the atomic way
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Start computing the vlv/chv watermarks the atomic way, from the
> .compute_pipe_wm() hook. We'll recompute the actual watermarks
> for only planes that are part of the state, the other planes will
> keep their watermark from the last time it was computed.
>
> And the actual watermark programming will happen from the
> .initial_watermarks() hook. For now we'll just compute the
> optimal watermarks, and we'll hook up the intermediate
> watermarks properly later.
>
> The DSPARB registers responsible for the FIFO paritioning are
> double buffered, so they will be programming from
> intel_begin_crtc_commit().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8 +
> drivers/gpu/drm/i915/intel_display.c | 21 ++-
> drivers/gpu/drm/i915/intel_drv.h | 2 -
> drivers/gpu/drm/i915/intel_pm.c | 327
> +++
> 4 files changed, 238 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20bc04d5e617..f23698f99685 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -493,6 +493,14 @@ struct i915_hotplug {
> for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
> for_each_if ((1 << (domain)) & (mask))
>
> +#define for_each_intel_plane_in_state(__state, plane, plane_state, __i) \
> + for ((__i) = 0; \
> + (__i) < (__state)->base.dev->mode_config.num_total_plane && \
> + ((plane) =
> to_intel_plane((__state)->base.planes[__i].ptr), \
> + (plane_state) =
> to_intel_plane_state((__state)->base.planes[__i].state), 1); \
> + (__i)++) \
> + for_each_if (plane_state)
> +
> struct drm_i915_private;
> struct i915_mm_struct;
> struct i915_mmu_object;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3f027341b0f3..8d80873b6643 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6736,6 +6736,8 @@ static void valleyview_modeset_commit_cdclk(struct
> drm_atomic_state *old_state)
> static void valleyview_crtc_enable(struct intel_crtc_state *pipe_config,
> struct drm_atomic_state *old_state)
> {
> + struct intel_atomic_state *old_intel_state =
> + to_intel_atomic_state(old_state);
> struct drm_crtc *crtc = pipe_config->base.crtc;
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -6780,7 +6782,8 @@ static void valleyview_crtc_enable(struct
> intel_crtc_state *pipe_config,
>
> intel_color_load_luts(&pipe_config->base);
>
> - intel_update_watermarks(intel_crtc);
> + dev_priv->display.initial_watermarks(old_intel_state,
> + pipe_config);
> intel_enable_pipe(intel_crtc);
>
> assert_vblank_disabled(crtc);
> @@ -6897,6 +6900,9 @@ static void i9xx_crtc_disable(struct intel_crtc_state
> *old_crtc_state,
>
> if (!IS_GEN2(dev_priv))
> intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
> +
> + if (!dev_priv->display.initial_watermarks)
> + intel_update_watermarks(intel_crtc);
> }
>
> static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
> @@ -12980,10 +12986,13 @@ static bool check_digital_port_conflicts(struct
> drm_atomic_state *state)
> static void
> clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
> {
> + struct drm_i915_private *dev_priv =
> + to_i915(crtc_state->base.crtc->dev);
> struct drm_crtc_state tmp_state;
> struct intel_crtc_scaler_state scaler_state;
> struct intel_dpll_hw_state dpll_hw_state;
> struct intel_shared_dpll *shared_dpll;
> + struct intel_crtc_wm_state wm_state;
> bool force_thru;
>
> /* FIXME: before the switch to atomic started, a new pipe_config was
> @@ -12996,6 +13005,8 @@ clear_intel_crtc_state(struct intel_crtc_state
> *crtc_state)
> shared_dpll = crtc_state->shared_dpll;
> dpll_hw_state = crtc_state->dpll_hw_state;
> force_thru = crtc_state->pch_pfit.force_thru;
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + wm_state = crtc_state->wm;
>
> memset(crtc_state, 0, sizeof *crtc_state);
>
> @@ -13004,6 +13015,8 @@ clear_intel_crtc_state(struct intel_crtc_state
> *crtc_state)
> crtc_state->shared_dpll = shared_dpll;
> crtc_state->dpll_hw_state = dpll_hw_state;
> crtc_state->pch_pfit.force_thru = force_thru;
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + crtc_state->wm = wm_state;
Is this required? In skl we throw away everything and rebuild using
drm_atomic_crtc_state_for_each_plane_state.
>
> static int
> @@ -14497,
Re: [Intel-gfx] [PATCH i-g-t] tests: Add kms_plane_blinker
Op 15-12-16 om 16:23 schreef Ville Syrjälä: > On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote: >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: >>> From: Ville Syrjälä >>> >>> Add a test to try out all the different plane enable/disable >>> order permutations. >>> >>> Signed-off-by: Ville Syrjälä >> Didn't look through the test, but sounds like >> >> kms_atomic_transitions.plane-*-transition-* ? >> >> Although that one tests a few more edge cases like modeset disable and >> nonblocking updates.. > I don't immediately see where it would try all the permutations, nor can > I see any crc_nonblock() stuff so doesn't seem like it could even spot > transient errors. > I haven't done any crc test there yet, but the double loop in run_transition_test handles all combinations of planes. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-tip:drm-tip 891/920] htmldocs: drivers/gpu/drm/drm_modeset_helper.c:74: warning: No description found for parameter 'dev'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: f720625c665f237616e3320255a89cdf394d2451 commit: a3f913ca98925d7e5bae725e9b2b38408215a695 [891/920] drm: Pass 'dev' to drm_helper_mode_fill_fb_struct() reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. include/linux/init.h:1: warning: no structured comments found include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found include/linux/device.h:1: warning: no structured comments found drivers/base/core.c:1: warning: no structured comments found drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/drm/drm_drv.h:409: warning: No description found for parameter 'load' include/drm/drm_drv.h:409: warning: No description found for parameter 'firstopen' include/drm/drm_drv.h:409: warning: No description found for parameter 'open' include/drm/drm_drv.h:409: warning: No description found for parameter 'preclose' include/drm/drm_drv.h:409: warning: No description found for parameter 'postclose' include/drm/drm_drv.h:409: warning: No description found for parameter 'lastclose' include/drm/drm_drv.h:409: warning: No description found for parameter 'unload' include/drm/drm_drv.h:409: warning: No description found for parameter 'dma_ioctl' include/drm/drm_drv.h:409: warning: No description found for parameter 'dma_quiescent' include/drm/drm_drv.h:409: warning: No description found for parameter 'context_dtor' include/drm/drm_drv.h:409: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:409: warning: No description found for parameter 'irq_handler' include/drm/drm_drv.h:409: warning: No description found for parameter 'irq_preinstall' include/drm/drm_drv.h:409: warning: No description found for parameter 'irq_postinstall' include/drm/drm_drv.h:409: warning: No description found for parameter 'irq_uninstall' include/drm/drm_drv.h:409: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:409: warning: No description found for parameter 'debugfs_cleanup' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:409: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:409: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:409: warning: No description found for parameter 'vgaarb_irq' include/drm/drm_drv.h:409: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:409: warning: No description found for parameter 'major' include/drm/drm_drv.h:409: warning: No description found for parameter 'minor' include/drm/drm_drv.h:409: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:409: warning: No description found for parameter 'name' include/drm/drm_drv.h:409: warning: No description found for parameter 'desc' include/drm/drm_drv.h:409: warning: No description found for parameter 'date' include/drm/drm_drv.h:409: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:409: warning: No description found for parameter 'dev_priv_size' include/drm/drm_drv.h:409: warning: No description found for parameter 'ioctls' include/drm/drm_drv.h:409: warning: No description found for parameter 'num_ioctls' include/drm/drm_drv.h:409: warning: No description found for parameter 'fops' include/drm/drm_drv.h:409: warning: No description found for parameter 'legacy_dev_list' >> drivers/gpu/drm/drm_modeset_helper.c:74: warning: No description found for >> parameter 'dev' drivers/gpu/drm/drm_modeset_helper.c:75: warning: No description fou
Re: [Intel-gfx] [PATCH 13/14] drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
> lead to an underrun. This only happens when sprite0 FIFO size is zero
> prior to enabling it. Hence an effective workaround is to always
> allocate at least one cacheline for sprite0 when sprite1 is active.
>
> I've not observed this sort of failure during any other type of plane
> enable/disable sequence.
>
> Testcase: igt/kms_plane_blinker
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fa882cdcac52..75a5bde43723 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1006,6 +1006,12 @@ static uint16_t vlv_compute_wm_level(const struct
> intel_crtc_state *crtc_state,
> return min_t(int, wm, USHRT_MAX);
> }
>
> +static bool vlv_need_sprite0_fifo_workaround(unsigned int active_planes)
> +{
> + return (active_planes & (BIT(PLANE_SPRITE0) |
> + BIT(PLANE_SPRITE1))) == BIT(PLANE_SPRITE1);
> +}
> +
> static int vlv_compute_fifo(struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> @@ -1016,12 +1022,25 @@ static int vlv_compute_fifo(struct intel_crtc_state
> *crtc_state)
> int num_active_planes = hweight32(active_planes);
> const int fifo_size = 511;
> int fifo_extra, fifo_left = fifo_size;
> + int sprite0_fifo_extra = 0;
> unsigned int total_rate;
> enum plane_id plane_id;
>
> + /*
> + * When enabling sprite0 after sprite1 has already been enabled
> + * we tend to get an underrun unless sprite0 already has some
> + * FIFO space allcoated. Hence we always allocate at least one
> + * cacheline for sprite0 whenever sprite1 is enabled.
> + *
> + * All other plane enable sequences appear immune to this problem.
> + */
> + if (vlv_need_sprite0_fifo_workaround(active_planes))
> + sprite0_fifo_extra = 1;
I don't think you need crtc_state->active_planes just for this, it adds a lot
of tracking for something that could be done by
if (noninverted->plane[SPRITE1] && !noninverted->plane[SPRITE0])
/* allocate 1 for sprite 0 */
Maybe drop that patch?
> total_rate = noninverted->plane[PLANE_PRIMARY] +
> noninverted->plane[PLANE_SPRITE0] +
> - noninverted->plane[PLANE_SPRITE1];
> + noninverted->plane[PLANE_SPRITE1] +
> + sprite0_fifo_extra;
>
> if (total_rate > fifo_size)
> return -EINVAL;
> @@ -1042,6 +1061,9 @@ static int vlv_compute_fifo(struct intel_crtc_state
> *crtc_state)
> fifo_left -= fifo_state->plane[plane_id];
> }
>
> + fifo_state->plane[PLANE_SPRITE0] += sprite0_fifo_extra;
> + fifo_left -= sprite0_fifo_extra;
> +
> fifo_state->plane[PLANE_CURSOR] = 63;
>
> fifo_extra = DIV_ROUND_UP(fifo_left, num_active_planes ?: 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] tests: Add kms_plane_blinker
On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote: > Op 15-12-16 om 16:23 schreef Ville Syrjälä: > > On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote: > >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: > >>> From: Ville Syrjälä > >>> > >>> Add a test to try out all the different plane enable/disable > >>> order permutations. > >>> > >>> Signed-off-by: Ville Syrjälä > >> Didn't look through the test, but sounds like > >> > >> kms_atomic_transitions.plane-*-transition-* ? > >> > >> Although that one tests a few more edge cases like modeset disable and > >> nonblocking updates.. > > I don't immediately see where it would try all the permutations, nor can > > I see any crc_nonblock() stuff so doesn't seem like it could even spot > > transient errors. > > > I haven't done any crc test there yet, but the double loop in > run_transition_test handles all combinations of planes. permutations > combinations -- 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 08/14] drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed
Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Check whether anything relevant has actually change when we compute new
> watermarks for each plane in the state. If the watermarks for no
> primary/sprite planes changed we don't have to recompute the FIFO split
> or reprogram the DSBARB registers. And even the cursor watermarks didn't
> change we can skip the merge+invert step between all the planes on
> the pipe as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/intel_drv.h| 1 +
> drivers/gpu/drm/i915/intel_pm.c | 73
> +
> 3 files changed, 60 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index c5a166752eda..df33f270b459 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -99,6 +99,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> crtc_state->update_wm_pre = false;
> crtc_state->update_wm_post = false;
> crtc_state->fb_changed = false;
> + crtc_state->fifo_changed = false;
> crtc_state->wm.need_postvbl_update = false;
> crtc_state->fb_bits = 0;
This flag is only used in intel_pm.c, maybe put it in
crtc_state->wm.vlv.fifo_changed, and clear it in the beginning of the wm
recalculation?
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8c18a47a..a92857864ee8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -560,6 +560,7 @@ struct intel_crtc_state {
> bool disable_cxsr;
> bool update_wm_pre, update_wm_post; /* watermarks are updated */
> bool fb_changed; /* fb on any of the planes is changed */
> + bool fifo_changed; /* FIFO split is changed */
>
> /* Pipe source size (ie. panel fitter input size)
>* All planes will be positioned inside this space,
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f68b46eed224..c7cc62cf51f6 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1103,31 +1103,36 @@ static u16 vlv_invert_wm_value(u16 wm, u16 fifo_size)
> }
>
> /* starting from 'level' set all higher levels to 'value' */
> -static void vlv_plane_wm_set(struct intel_crtc_state *crtc_state,
> +static bool vlv_plane_wm_set(struct intel_crtc_state *crtc_state,
>int level, enum plane_id plane_id, u16 value)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> int num_levels = vlv_num_wm_levels(dev_priv);
> + bool dirty = false;
>
> for (; level < num_levels; level++) {
> struct vlv_pipe_wm *noninverted =
> &crtc_state->wm.vlv.noninverted[level];
>
> + dirty |= noninverted->plane[plane_id] != value;
> noninverted->plane[plane_id] = value;
> }
> +
> + return dirty;
> }
>
> -static void vlv_plane_wm_compute(struct intel_crtc_state *crtc_state,
> +static bool vlv_plane_wm_compute(struct intel_crtc_state *crtc_state,
>const struct intel_plane_state *plane_state)
> {
> struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> enum plane_id plane_id = plane->id;
> int num_levels = vlv_num_wm_levels(to_i915(plane->base.dev));
> int level;
> + bool dirty = false;
>
> if (!plane_state->base.visible) {
> - vlv_plane_wm_set(crtc_state, 0, plane_id, 0);
> - return;
> + dirty |= vlv_plane_wm_set(crtc_state, 0, plane_id, 0);
> + goto out;
> }
>
> for (level = 0; level < num_levels; level++) {
> @@ -1143,17 +1148,22 @@ static void vlv_plane_wm_compute(struct
> intel_crtc_state *crtc_state,
> if (wm > max_wm)
> break;
>
> + dirty |= noninverted->plane[plane_id] != wm;
> noninverted->plane[plane_id] = wm;
> }
>
> /* mark all higher levels as invalid */
> - vlv_plane_wm_set(crtc_state, level, plane_id, USHRT_MAX);
> + dirty |= vlv_plane_wm_set(crtc_state, level, plane_id, USHRT_MAX);
>
> - DRM_DEBUG_KMS("%s wms: [0]=%d,[1]=%d,[2]=%d\n",
> - plane->base.name,
> -
> crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_PM2].plane[plane_id],
> -
> crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_PM5].plane[plane_id],
> -
> crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_DDR_DVFS].plane[plane_id]);
> +out:
> + if (dirty)
> + DRM_DEBUG_KMS("%s wms: [0]=%d,[1]=%d,[2]=%d\n",
> + plane->base.name,
> +
> crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_PM2].plane[plane_id],
> +
> crtc_s
Re: [Intel-gfx] [PATCH 07/14] drm/i915: Compute vlv/chv wms the atomic way
On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Start computing the vlv/chv watermarks the atomic way, from the
> > .compute_pipe_wm() hook. We'll recompute the actual watermarks
> > for only planes that are part of the state, the other planes will
> > keep their watermark from the last time it was computed.
> >
> > And the actual watermark programming will happen from the
> > .initial_watermarks() hook. For now we'll just compute the
> > optimal watermarks, and we'll hook up the intermediate
> > watermarks properly later.
> >
> > The DSPARB registers responsible for the FIFO paritioning are
> > double buffered, so they will be programming from
> > intel_begin_crtc_commit().
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 8 +
> > drivers/gpu/drm/i915/intel_display.c | 21 ++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 -
> > drivers/gpu/drm/i915/intel_pm.c | 327
> > +++
> > 4 files changed, 238 insertions(+), 120 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 20bc04d5e617..f23698f99685 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -493,6 +493,14 @@ struct i915_hotplug {
> > for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
> > for_each_if ((1 << (domain)) & (mask))
> >
> > +#define for_each_intel_plane_in_state(__state, plane, plane_state, __i) \
> > + for ((__i) = 0; \
> > +(__i) < (__state)->base.dev->mode_config.num_total_plane && \
> > +((plane) =
> > to_intel_plane((__state)->base.planes[__i].ptr), \
> > + (plane_state) =
> > to_intel_plane_state((__state)->base.planes[__i].state), 1); \
> > +(__i)++) \
> > + for_each_if (plane_state)
> > +
> > struct drm_i915_private;
> > struct i915_mm_struct;
> > struct i915_mmu_object;
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 3f027341b0f3..8d80873b6643 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6736,6 +6736,8 @@ static void valleyview_modeset_commit_cdclk(struct
> > drm_atomic_state *old_state)
> > static void valleyview_crtc_enable(struct intel_crtc_state *pipe_config,
> >struct drm_atomic_state *old_state)
> > {
> > + struct intel_atomic_state *old_intel_state =
> > + to_intel_atomic_state(old_state);
> > struct drm_crtc *crtc = pipe_config->base.crtc;
> > struct drm_device *dev = crtc->dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > @@ -6780,7 +6782,8 @@ static void valleyview_crtc_enable(struct
> > intel_crtc_state *pipe_config,
> >
> > intel_color_load_luts(&pipe_config->base);
> >
> > - intel_update_watermarks(intel_crtc);
> > + dev_priv->display.initial_watermarks(old_intel_state,
> > +pipe_config);
> > intel_enable_pipe(intel_crtc);
> >
> > assert_vblank_disabled(crtc);
> > @@ -6897,6 +6900,9 @@ static void i9xx_crtc_disable(struct intel_crtc_state
> > *old_crtc_state,
> >
> > if (!IS_GEN2(dev_priv))
> > intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
> > +
> > + if (!dev_priv->display.initial_watermarks)
> > + intel_update_watermarks(intel_crtc);
> > }
> >
> > static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
> > @@ -12980,10 +12986,13 @@ static bool check_digital_port_conflicts(struct
> > drm_atomic_state *state)
> > static void
> > clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
> > {
> > + struct drm_i915_private *dev_priv =
> > + to_i915(crtc_state->base.crtc->dev);
> > struct drm_crtc_state tmp_state;
> > struct intel_crtc_scaler_state scaler_state;
> > struct intel_dpll_hw_state dpll_hw_state;
> > struct intel_shared_dpll *shared_dpll;
> > + struct intel_crtc_wm_state wm_state;
> > bool force_thru;
> >
> > /* FIXME: before the switch to atomic started, a new pipe_config was
> > @@ -12996,6 +13005,8 @@ clear_intel_crtc_state(struct intel_crtc_state
> > *crtc_state)
> > shared_dpll = crtc_state->shared_dpll;
> > dpll_hw_state = crtc_state->dpll_hw_state;
> > force_thru = crtc_state->pch_pfit.force_thru;
> > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > + wm_state = crtc_state->wm;
> >
> > memset(crtc_state, 0, sizeof *crtc_state);
> >
> > @@ -13004,6 +13015,8 @@ clear_intel_crtc_state(struct intel_crtc_state
> > *crtc_state)
> > crtc_state->shared_dpll = shared_dpll;
> > crtc_state->dpll_hw_state = dpll_hw_state;
> > crtc_state->pch_pfit.force_thru = force_thru;
> > + if (IS_VALLEYVIEW(dev_priv
Re: [Intel-gfx] [PATCH i-g-t] tests: Add kms_plane_blinker
Op 15-12-16 om 16:36 schreef Ville Syrjälä: > On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote: >> Op 15-12-16 om 16:23 schreef Ville Syrjälä: >>> On Thu, Dec 15, 2016 at 04:17:45PM +0100, Maarten Lankhorst wrote: Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > Add a test to try out all the different plane enable/disable > order permutations. > > Signed-off-by: Ville Syrjälä Didn't look through the test, but sounds like kms_atomic_transitions.plane-*-transition-* ? Although that one tests a few more edge cases like modeset disable and nonblocking updates.. >>> I don't immediately see where it would try all the permutations, nor can >>> I see any crc_nonblock() stuff so doesn't seem like it could even spot >>> transient errors. >>> >> I haven't done any crc test there yet, but the double loop in >> run_transition_test handles all combinations of planes. > permutations > combinations > It permutates too, I used it for some basic wm testing before. :) ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/14] drm/i915: Compute vlv/chv wms the atomic way
Op 15-12-16 om 16:38 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote:
>> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> Start computing the vlv/chv watermarks the atomic way, from the
>>> .compute_pipe_wm() hook. We'll recompute the actual watermarks
>>> for only planes that are part of the state, the other planes will
>>> keep their watermark from the last time it was computed.
>>>
>>> And the actual watermark programming will happen from the
>>> .initial_watermarks() hook. For now we'll just compute the
>>> optimal watermarks, and we'll hook up the intermediate
>>> watermarks properly later.
>>>
>>> The DSPARB registers responsible for the FIFO paritioning are
>>> double buffered, so they will be programming from
>>> intel_begin_crtc_commit().
>>>
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> drivers/gpu/drm/i915/i915_drv.h | 8 +
>>> drivers/gpu/drm/i915/intel_display.c | 21 ++-
>>> drivers/gpu/drm/i915/intel_drv.h | 2 -
>>> drivers/gpu/drm/i915/intel_pm.c | 327
>>> +++
>>> 4 files changed, 238 insertions(+), 120 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index 20bc04d5e617..f23698f99685 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -493,6 +493,14 @@ struct i915_hotplug {
>>> for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
>>> for_each_if ((1 << (domain)) & (mask))
>>>
>>> +#define for_each_intel_plane_in_state(__state, plane, plane_state, __i) \
>>> + for ((__i) = 0; \
>>> +(__i) < (__state)->base.dev->mode_config.num_total_plane && \
>>> +((plane) =
>>> to_intel_plane((__state)->base.planes[__i].ptr), \
>>> + (plane_state) =
>>> to_intel_plane_state((__state)->base.planes[__i].state), 1); \
>>> +(__i)++) \
>>> + for_each_if (plane_state)
>>> +
>>> struct drm_i915_private;
>>> struct i915_mm_struct;
>>> struct i915_mmu_object;
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 3f027341b0f3..8d80873b6643 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -6736,6 +6736,8 @@ static void valleyview_modeset_commit_cdclk(struct
>>> drm_atomic_state *old_state)
>>> static void valleyview_crtc_enable(struct intel_crtc_state *pipe_config,
>>>struct drm_atomic_state *old_state)
>>> {
>>> + struct intel_atomic_state *old_intel_state =
>>> + to_intel_atomic_state(old_state);
>>> struct drm_crtc *crtc = pipe_config->base.crtc;
>>> struct drm_device *dev = crtc->dev;
>>> struct drm_i915_private *dev_priv = to_i915(dev);
>>> @@ -6780,7 +6782,8 @@ static void valleyview_crtc_enable(struct
>>> intel_crtc_state *pipe_config,
>>>
>>> intel_color_load_luts(&pipe_config->base);
>>>
>>> - intel_update_watermarks(intel_crtc);
>>> + dev_priv->display.initial_watermarks(old_intel_state,
>>> +pipe_config);
>>> intel_enable_pipe(intel_crtc);
>>>
>>> assert_vblank_disabled(crtc);
>>> @@ -6897,6 +6900,9 @@ static void i9xx_crtc_disable(struct intel_crtc_state
>>> *old_crtc_state,
>>>
>>> if (!IS_GEN2(dev_priv))
>>> intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
>>> +
>>> + if (!dev_priv->display.initial_watermarks)
>>> + intel_update_watermarks(intel_crtc);
>>> }
>>>
>>> static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
>>> @@ -12980,10 +12986,13 @@ static bool check_digital_port_conflicts(struct
>>> drm_atomic_state *state)
>>> static void
>>> clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
>>> {
>>> + struct drm_i915_private *dev_priv =
>>> + to_i915(crtc_state->base.crtc->dev);
>>> struct drm_crtc_state tmp_state;
>>> struct intel_crtc_scaler_state scaler_state;
>>> struct intel_dpll_hw_state dpll_hw_state;
>>> struct intel_shared_dpll *shared_dpll;
>>> + struct intel_crtc_wm_state wm_state;
>>> bool force_thru;
>>>
>>> /* FIXME: before the switch to atomic started, a new pipe_config was
>>> @@ -12996,6 +13005,8 @@ clear_intel_crtc_state(struct intel_crtc_state
>>> *crtc_state)
>>> shared_dpll = crtc_state->shared_dpll;
>>> dpll_hw_state = crtc_state->dpll_hw_state;
>>> force_thru = crtc_state->pch_pfit.force_thru;
>>> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>>> + wm_state = crtc_state->wm;
>>>
>>> memset(crtc_state, 0, sizeof *crtc_state);
>>>
>>> @@ -13004,6 +13015,8 @@ clear_intel_crtc_state(struct intel_crtc_state
>>> *crtc_state)
>>> crtc_state->shared_dpll = shared_dpll;
>>> crtc_state->dpll_hw_state = dpll_hw_state;
>>> crtc_state->pch_pfit.force_thru =
Re: [Intel-gfx] [PATCH 13/14] drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun
On Thu, Dec 15, 2016 at 04:34:58PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
> > lead to an underrun. This only happens when sprite0 FIFO size is zero
> > prior to enabling it. Hence an effective workaround is to always
> > allocate at least one cacheline for sprite0 when sprite1 is active.
> >
> > I've not observed this sort of failure during any other type of plane
> > enable/disable sequence.
> >
> > Testcase: igt/kms_plane_blinker
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 24 +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index fa882cdcac52..75a5bde43723 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -1006,6 +1006,12 @@ static uint16_t vlv_compute_wm_level(const struct
> > intel_crtc_state *crtc_state,
> > return min_t(int, wm, USHRT_MAX);
> > }
> >
> > +static bool vlv_need_sprite0_fifo_workaround(unsigned int active_planes)
> > +{
> > + return (active_planes & (BIT(PLANE_SPRITE0) |
> > +BIT(PLANE_SPRITE1))) == BIT(PLANE_SPRITE1);
> > +}
> > +
> > static int vlv_compute_fifo(struct intel_crtc_state *crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > @@ -1016,12 +1022,25 @@ static int vlv_compute_fifo(struct intel_crtc_state
> > *crtc_state)
> > int num_active_planes = hweight32(active_planes);
> > const int fifo_size = 511;
> > int fifo_extra, fifo_left = fifo_size;
> > + int sprite0_fifo_extra = 0;
> > unsigned int total_rate;
> > enum plane_id plane_id;
> >
> > + /*
> > +* When enabling sprite0 after sprite1 has already been enabled
> > +* we tend to get an underrun unless sprite0 already has some
> > +* FIFO space allcoated. Hence we always allocate at least one
> > +* cacheline for sprite0 whenever sprite1 is enabled.
> > +*
> > +* All other plane enable sequences appear immune to this problem.
> > +*/
> > + if (vlv_need_sprite0_fifo_workaround(active_planes))
> > + sprite0_fifo_extra = 1;
> I don't think you need crtc_state->active_planes just for this, it adds a lot
> of tracking for something that could be done by
>
> if (noninverted->plane[SPRITE1] && !noninverted->plane[SPRITE0])
> /* allocate 1 for sprite 0 */
>
> Maybe drop that patch?
We'll want it for other things outside of the vlv watermark code as
well. So figured this is a good excuse for getting the ball rolling,
> > total_rate = noninverted->plane[PLANE_PRIMARY] +
> > noninverted->plane[PLANE_SPRITE0] +
> > - noninverted->plane[PLANE_SPRITE1];
> > + noninverted->plane[PLANE_SPRITE1] +
> > + sprite0_fifo_extra;
> >
> > if (total_rate > fifo_size)
> > return -EINVAL;
> > @@ -1042,6 +1061,9 @@ static int vlv_compute_fifo(struct intel_crtc_state
> > *crtc_state)
> > fifo_left -= fifo_state->plane[plane_id];
> > }
> >
> > + fifo_state->plane[PLANE_SPRITE0] += sprite0_fifo_extra;
> > + fifo_left -= sprite0_fifo_extra;
> > +
> > fifo_state->plane[PLANE_CURSOR] = 63;
> >
> > fifo_extra = DIV_ROUND_UP(fifo_left, num_active_planes ?: 1);
>
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915/guc: Extract param logic form guc_init
Let intel_guc_init() focus on determining and fetching the correct
firmware.
This patch introduces intel_sanitize_uc_params() that is called from
intel_uc_init().
Then, if we have GuC, we can call intel_guc_init() conditionally and we
do not have to do internal checks.
It can be easily extended to support HuC case as well.
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_guc_loader.c | 19 +--
drivers/gpu/drm/i915/intel_uc.c | 23 ++-
2 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index b76b556..0bb5fd1 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -617,7 +617,7 @@ static void guc_fw_fetch(struct drm_i915_private *dev_priv,
}
/**
- * intel_guc_init() - define parameters and fetch firmware
+ * intel_guc_init() - determine and fetch firmware
* @dev_priv: i915 device private
*
* Called early during driver load, but after GEM is initialised.
@@ -630,17 +630,6 @@ void intel_guc_init(struct drm_i915_private *dev_priv)
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
const char *fw_path;
- if (!HAS_GUC(dev_priv)) {
- i915.enable_guc_loading = 0;
- i915.enable_guc_submission = 0;
- } else {
- /* A negative value means "use platform default" */
- if (i915.enable_guc_loading < 0)
- i915.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
- if (i915.enable_guc_submission < 0)
- i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
- }
-
if (!HAS_GUC_UCODE(dev_priv)) {
fw_path = NULL;
} else if (IS_SKYLAKE(dev_priv)) {
@@ -663,13 +652,7 @@ void intel_guc_init(struct drm_i915_private *dev_priv)
guc_fw->guc_fw_fetch_status = GUC_FIRMWARE_NONE;
guc_fw->guc_fw_load_status = GUC_FIRMWARE_NONE;
- /* can't enable guc submission without guc */
- if (!i915.enable_guc_loading)
- i915.enable_guc_submission = 0;
-
/* Early (and silent) return if GuC loading is disabled */
- if (!i915.enable_guc_loading)
- return;
if (fw_path == NULL)
return;
if (*fw_path == '\0')
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 4e184edb..e72f784 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -25,6 +25,24 @@
#include "i915_drv.h"
#include "intel_uc.h"
+static void intel_sanitize_uc_params(struct drm_i915_private *dev_priv)
+{
+ if (!HAS_GUC(dev_priv)) {
+ i915.enable_guc_loading = 0;
+ i915.enable_guc_submission = 0;
+ } else {
+ /* A negative value means "use platform default" */
+ if (i915.enable_guc_loading < 0)
+ i915.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
+ if (i915.enable_guc_submission < 0)
+ i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
+ }
+
+ /* can't enable guc submission without guc */
+ if (!i915.enable_guc_loading)
+ i915.enable_guc_submission = 0;
+}
+
void intel_uc_init_early(struct drm_i915_private *dev_priv)
{
mutex_init(&dev_priv->guc.send_mutex);
@@ -32,7 +50,10 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
void intel_uc_init(struct drm_i915_private *dev_priv)
{
- intel_guc_init(dev_priv);
+ intel_sanitize_uc_params(dev_priv);
+
+ if (i915.enable_guc_loading)
+ intel_guc_init(dev_priv);
}
int intel_uc_load(struct drm_i915_private *dev_priv)
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/guc: Simplify guc_fw_path
Currently guc_fw_path values can represent one of three possible states:
1) NULL - device without GuC
2) '\0' - device with GuC but no known firmware
3) else - device with GuC and known firmware
Second case is used only to WARN at the later stage.
We can WARN right away and merge cases 1 and 2 for later handling.
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_guc_loader.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 0bb5fd1..075a103 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -460,12 +460,8 @@ int intel_guc_load(struct drm_i915_private *dev_priv)
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
if (fw_path == NULL) {
- /* Device is known to have no uCode (e.g. no GuC) */
+ /* We do not have uCode for the device */
return -ENXIO;
- } else if (*fw_path == '\0') {
- /* Device has a GuC but we don't know what f/w to load? */
- WARN(1, "No GuC firmware known for this platform!\n");
- return -ENODEV;
}
/* Fetch failed, or already fetched but failed to load? */
@@ -628,11 +624,9 @@ static void guc_fw_fetch(struct drm_i915_private *dev_priv,
void intel_guc_init(struct drm_i915_private *dev_priv)
{
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
- const char *fw_path;
+ const char *fw_path = NULL;
- if (!HAS_GUC_UCODE(dev_priv)) {
- fw_path = NULL;
- } else if (IS_SKYLAKE(dev_priv)) {
+ if (IS_SKYLAKE(dev_priv)) {
fw_path = I915_SKL_GUC_UCODE;
guc_fw->guc_fw_major_wanted = SKL_FW_MAJOR;
guc_fw->guc_fw_minor_wanted = SKL_FW_MINOR;
@@ -644,24 +638,22 @@ void intel_guc_init(struct drm_i915_private *dev_priv)
fw_path = I915_KBL_GUC_UCODE;
guc_fw->guc_fw_major_wanted = KBL_FW_MAJOR;
guc_fw->guc_fw_minor_wanted = KBL_FW_MINOR;
- } else {
- fw_path = ""; /* unknown device */
+ } else if (HAS_GUC_UCODE(dev_priv)) {
+ WARN(1, "No GuC firmware known for platform with GuC!\n");
}
guc_fw->guc_fw_path = fw_path;
guc_fw->guc_fw_fetch_status = GUC_FIRMWARE_NONE;
guc_fw->guc_fw_load_status = GUC_FIRMWARE_NONE;
- /* Early (and silent) return if GuC loading is disabled */
+ /* Early return if we do not have firmware to fetch */
if (fw_path == NULL)
return;
- if (*fw_path == '\0')
- return;
guc_fw->guc_fw_fetch_status = GUC_FIRMWARE_PENDING;
DRM_DEBUG_DRIVER("GuC firmware pending, path %s\n", fw_path);
+
guc_fw_fetch(dev_priv, guc_fw);
- /* status must now be FAIL or SUCCESS */
}
/**
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915/guc: Rename _setup() to _load()
GuC historically has two "startup" functions called _init() and _setup()
Then HuC came with it's _init() and _load().
To make naming more consistent this commit renames intel_guc_setup() to
intel_guc_load() as it it seams more fitting (it's in intel_guc_loader.c
after all).
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_guc_loader.c | 12 ++--
drivers/gpu/drm/i915/intel_uc.h | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f86a71d9..6af4e85 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4412,7 +4412,7 @@ i915_gem_init_hw(struct drm_i915_private *dev_priv)
intel_mocs_init_l3cc_table(dev_priv);
/* We can't enable contexts until all firmware is loaded */
- ret = intel_guc_setup(dev_priv);
+ ret = intel_guc_load(dev_priv);
if (ret)
goto out;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 21db697..f8b28b1 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -436,19 +436,19 @@ static int guc_hw_reset(struct drm_i915_private *dev_priv)
}
/**
- * intel_guc_setup() - finish preparing the GuC for activity
+ * intel_guc_load() - finish preparing the GuC for activity
* @dev_priv: i915 device private
*
- * Called from gem_init_hw() during driver loading and also after a GPU reset.
+ * Called during driver loading and also after a GPU reset.
*
* The main action required here it to load the GuC uCode into the device.
* The firmware image should have already been fetched into memory by the
- * earlier call to intel_guc_init(), so here we need only check that worked,
- * and then transfer the image to the h/w.
+ * earlier call to intel_guc_init(), so here we need only check that
+ * worked, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
-int intel_guc_setup(struct drm_i915_private *dev_priv)
+int intel_guc_load(struct drm_i915_private *dev_priv)
{
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
const char *fw_path = guc_fw->guc_fw_path;
@@ -717,7 +717,7 @@ static void guc_fw_fetch(struct drm_i915_private *dev_priv,
* Called early during driver load, but after GEM is initialised.
*
* The firmware will be transferred to the GuC's memory later,
- * when intel_guc_setup() is called.
+ * when intel_guc_load() is called.
*/
void intel_guc_init(struct drm_i915_private *dev_priv)
{
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 11f5608..7222e6c 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -179,7 +179,7 @@ int intel_guc_log_control(struct intel_guc *guc, u32
control_val);
/* intel_guc_loader.c */
extern void intel_guc_init(struct drm_i915_private *dev_priv);
-extern int intel_guc_setup(struct drm_i915_private *dev_priv);
+extern int intel_guc_load(struct drm_i915_private *dev_priv);
extern void intel_guc_fini(struct drm_i915_private *dev_priv);
extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status);
extern int intel_guc_suspend(struct drm_i915_private *dev_priv);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/guc: Simplify intel_guc_load()
Current version of intel_guc_load() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_load(), which now
cares about the above.
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_guc_loader.c | 126 +---
drivers/gpu/drm/i915/intel_uc.c | 83 +
drivers/gpu/drm/i915/intel_uc.h | 8 ++
4 files changed, 110 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6af4e85..76b52c6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4412,7 +4412,7 @@ i915_gem_init_hw(struct drm_i915_private *dev_priv)
intel_mocs_init_l3cc_table(dev_priv);
/* We can't enable contexts until all firmware is loaded */
- ret = intel_guc_load(dev_priv);
+ ret = intel_uc_load(dev_priv);
if (ret)
goto out;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index f8b28b1..b76b556 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -97,7 +97,7 @@ const char *intel_guc_fw_status_repr(enum intel_guc_fw_status
status)
}
};
-static void guc_interrupts_release(struct drm_i915_private *dev_priv)
+void guc_interrupts_release(struct drm_i915_private *dev_priv)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -115,7 +115,7 @@ static void guc_interrupts_release(struct drm_i915_private
*dev_priv)
I915_WRITE(GUC_WD_VECS_IER, 0);
}
-static void guc_interrupts_capture(struct drm_i915_private *dev_priv)
+void guc_interrupts_capture(struct drm_i915_private *dev_priv)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -334,7 +334,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
*dev_priv,
return ret;
}
-static u32 guc_wopcm_size(struct drm_i915_private *dev_priv)
+u32 guc_wopcm_size(struct drm_i915_private *dev_priv)
{
u32 wopcm_size = GUC_WOPCM_TOP;
@@ -417,7 +417,7 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
return ret;
}
-static int guc_hw_reset(struct drm_i915_private *dev_priv)
+int guc_hw_reset(struct drm_i915_private *dev_priv)
{
int ret;
u32 guc_status;
@@ -452,75 +452,37 @@ int intel_guc_load(struct drm_i915_private *dev_priv)
{
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
const char *fw_path = guc_fw->guc_fw_path;
- int retries, ret, err;
+ int ret;
DRM_DEBUG_DRIVER("GuC fw status: path %s, fetch %s, load %s\n",
fw_path,
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
- /* Loading forbidden, or no firmware to load? */
- if (!i915.enable_guc_loading) {
- err = 0;
- goto fail;
- } else if (fw_path == NULL) {
+ if (fw_path == NULL) {
/* Device is known to have no uCode (e.g. no GuC) */
- err = -ENXIO;
- goto fail;
+ return -ENXIO;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
WARN(1, "No GuC firmware known for this platform!\n");
- err = -ENODEV;
- goto fail;
+ return -ENODEV;
}
/* Fetch failed, or already fetched but failed to load? */
if (guc_fw->guc_fw_fetch_status != GUC_FIRMWARE_SUCCESS) {
- err = -EIO;
- goto fail;
+ return -EIO;
} else if (guc_fw->guc_fw_load_status == GUC_FIRMWARE_FAIL) {
- err = -ENOEXEC;
- goto fail;
+ return -ENOEXEC;
}
- guc_interrupts_release(dev_priv);
- gen9_reset_guc_interrupts(dev_priv);
-
guc_fw->guc_fw_load_status = GUC_FIRMWARE_PENDING;
- DRM_DEBUG_DRIVER("GuC fw status: fetch %s, load %s\n",
- intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
- intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
-
- err = i915_guc_submission_init(dev_priv);
- if (err)
- goto fail;
-
- /*
-* WaEnableuKernelHeaderValidFix:skl,bxt
-* For BXT, this is only upto B0 but below WA is required for later
-* steppings also so this is extended as well.
-*/
/* WaEnableGuCBootHashCheckNotSet:skl,bxt */
- for (retries = 3; ; ) {
- /*
-* Always reset the GuC just before (re)loading, so
-* that the state and timing are fairly predictable
-*/
- err = guc_hw_reset(
[Intel-gfx] [drm-intel:drm-intel-nightly 902/919] drivers/gpu/drm/drm_fb_cma_helper.c:312:20: error: 'struct drm_framebuffer' has no member named 'fomat'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 64353e762935a7ad82867be0e4e80ff2f7bc97e4
commit: ca984a998ad3a3b6bf8bf0d89861a6537551aaf2 [902/919] drm/fb_cma_helper:
Replace drm_format_info() with fb->format
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ca984a998ad3a3b6bf8bf0d89861a6537551aaf2
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_fb_cma_helper.c: In function 'drm_fb_cma_describe':
>> drivers/gpu/drm/drm_fb_cma_helper.c:312:20: error: 'struct drm_framebuffer'
>> has no member named 'fomat'
for (i = 0; i < fb->fomat->num_planes; i++) {
^
vim +312 drivers/gpu/drm/drm_fb_cma_helper.c
306 struct drm_fb_cma *fb_cma = to_fb_cma(fb);
307 int i;
308
309 seq_printf(m, "fb: %dx%d@%4.4s\n", fb->width, fb->height,
310 (char *)&fb->pixel_format);
311
> 312 for (i = 0; i < fb->fomat->num_planes; i++) {
313 seq_printf(m, " %d: offset=%d pitch=%d, obj: ",
314 i, fb->offsets[i], fb->pitches[i]);
315 drm_gem_cma_describe(fb_cma->obj[i], m);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] GuC Scrub vol. 1
General GuC cleanup simplifying logic, and moving chooks around either for simplification or cleaner HuC accommodation. A lot of logic were extracted from intel_guc_load() to other functions - it not only did handle the actual loading but had WA implementations and submission enabling code baked it. This is first the part of effort to clean it up. Arkadiusz Hiler (5): drm/i915/guc: Rename _setup() to _load() drm/i915/guc: Introduce intel_uc_init() drm/i915/guc: Simplify intel_guc_load() drm/i915/guc: Extract param logic form guc_init drm/i915/guc: Simplify guc_fw_path drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/intel_guc_loader.c | 169 +--- drivers/gpu/drm/i915/intel_uc.c | 109 drivers/gpu/drm/i915/intel_uc.h | 11 ++- 5 files changed, 148 insertions(+), 145 deletions(-) -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/guc: Introduce intel_uc_init()
We will be able to bulk call all firmware _init() function from single
point and offset some general logic there.
Cc: Anusha Srivatsa
Cc: Jeff McGee
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 5 +
drivers/gpu/drm/i915/intel_uc.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6428588..55a5546c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -600,7 +600,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
- intel_guc_init(dev_priv);
+ intel_uc_init(dev_priv);
ret = i915_gem_init(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 8ae6795..8eec035 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -30,6 +30,11 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
mutex_init(&dev_priv->guc.send_mutex);
}
+void intel_uc_init(struct drm_i915_private *dev_priv)
+{
+ intel_guc_init(dev_priv);
+}
+
/*
* Read GuC command/status register (SOFT_SCRATCH_0)
* Return true if it contains a response rather than a command
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 7222e6c..ec1a5b2 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -170,6 +170,7 @@ struct intel_guc {
/* intel_uc.c */
void intel_uc_init_early(struct drm_i915_private *dev_priv);
+void intel_uc_init(struct drm_i915_private *dev_priv);
bool intel_guc_recv(struct drm_i915_private *dev_priv, u32 *status);
int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len);
int intel_guc_sample_forcewake(struct intel_guc *guc);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/6] drm/atomic: Clean up wait_for_vblanks, v2.
On Thu, Dec 15, 2016 at 12:51:42PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
> crtc_state after commit. Move it to atomic_state->crtcs.
>
> Also stop re-using new_crtc_state->enable, we can now simply set a
> bitmask with crtc_crtc_mask.
>
> Changes since v1:
> - Keep last_vblank_count in __drm_crtc_state.
Just noticed: sob is missing.
With that fixed Reviewed-by: Daniel Vetter
> ---
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d19563651e07..88c0986d226a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1110,19 +1110,19 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state;
> int i, ret;
> + unsigned crtc_mask = 0;
>
> - for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> - /* No one cares about the old state, so abuse it for tracking
> - * and store whether we hold a vblank reference (and should do a
> - * vblank wait) in the ->enable boolean. */
> - old_crtc_state->enable = false;
> + /*
> + * Legacy cursor ioctls are completely unsynced, and userspace
> + * relies on that (by doing tons of cursor updates).
> + */
> + if (old_state->legacy_cursor_update)
> + return;
>
> - if (!crtc->state->active)
> - continue;
> + for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> + struct drm_crtc_state *new_crtc_state = crtc->state;
>
> - /* Legacy cursor ioctls are completely unsynced, and userspace
> - * relies on that (by doing tons of cursor updates). */
> - if (old_state->legacy_cursor_update)
> + if (!new_crtc_state->active)
> continue;
>
> if (!drm_atomic_helper_framebuffer_changed(dev,
> @@ -1133,16 +1133,16 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> if (ret != 0)
> continue;
>
> - old_crtc_state->enable = true;
> - old_crtc_state->last_vblank_count = drm_crtc_vblank_count(crtc);
> + crtc_mask |= drm_crtc_mask(crtc);
> + old_state->crtcs[i].last_vblank_count =
> drm_crtc_vblank_count(crtc);
> }
>
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> - if (!old_crtc_state->enable)
> + if (!(crtc_mask & drm_crtc_mask(crtc)))
> continue;
>
> ret = wait_event_timeout(dev->vblank[i].queue,
> - old_crtc_state->last_vblank_count !=
> + old_state->crtcs[i].last_vblank_count !=
> drm_crtc_vblank_count(crtc),
> msecs_to_jiffies(50));
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index d6d241f63b9f..617f095e31ba 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -145,6 +145,7 @@ struct __drm_crtcs_state {
> struct drm_crtc_state *state;
> struct drm_crtc_commit *commit;
> s64 __user *out_fence_ptr;
> + unsigned last_vblank_count;
> };
>
> struct __drm_connnectors_state {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 946672f97e1e..e03d194be086 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -93,8 +93,6 @@ struct drm_plane_helper_funcs;
> * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
> * @connector_mask: bitmask of (1 << drm_connector_index(connector)) of
> attached connectors
> * @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached
> encoders
> - * @last_vblank_count: for helpers and drivers to capture the vblank of the
> - * update to ensure framebuffer cleanup isn't done too early
> * @adjusted_mode: for use by helpers and drivers to compute adjusted mode
> timings
> * @mode: current mode timings
> * @mode_blob: &drm_property_blob for @mode
> @@ -140,9 +138,6 @@ struct drm_crtc_state {
> u32 connector_mask;
> u32 encoder_mask;
>
> - /* last_vblank_count: for vblank waits before cleanup */
> - u32 last_vblank_count;
> -
> /* adjusted_mode: for use by helpers and drivers */
> struct drm_display_mode adjusted_mode;
>
>
--
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/5] drm/i915/guc: Rename _setup() to _load()
On Thu, Dec 15, 2016 at 04:47:04PM +0100, Arkadiusz Hiler wrote: > GuC historically has two "startup" functions called _init() and _setup() > > Then HuC came with it's _init() and _load(). > > To make naming more consistent this commit renames intel_guc_setup() to > intel_guc_load() as it it seams more fitting (it's in intel_guc_loader.c > after all). Or init_hw as that is the initialisation phase it is called from. -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
[Intel-gfx] [PATCH] drm: Convert all helpers to drm_connector_list_iter
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing best to just wrap the entire thing up in one critical
section.
v3: Bail out after iter_put (Harry).
Cc: Harry Wentland
Reviewed-by: Harry Wentland
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 39
drivers/gpu/drm/drm_crtc_helper.c| 49
drivers/gpu/drm/drm_fb_helper.c | 12 ++---
drivers/gpu/drm/drm_modeset_helper.c | 2 ++
drivers/gpu/drm/drm_plane_helper.c | 5 +++-
drivers/gpu/drm/drm_probe_helper.c | 18 -
6 files changed, 92 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 23767df72615..e2e15a9903a9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -94,9 +94,10 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
{
struct drm_connector_state *conn_state;
struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
struct drm_encoder *encoder;
unsigned encoder_mask = 0;
- int i, ret;
+ int i, ret = 0;
/*
* First loop, find all newly assigned encoders from the connectors
@@ -144,7 +145,8 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
* and the crtc is disabled if no encoder is left. This preserves
* compatibility with the legacy set_config behavior.
*/
- drm_for_each_connector(connector, state->dev) {
+ drm_connector_list_iter_get(state->dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
struct drm_crtc_state *crtc_state;
if (drm_atomic_get_existing_connector_state(state, connector))
@@ -160,12 +162,15 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
connector->state->crtc->base.id,
connector->state->crtc->name,
connector->base.id, connector->name);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
conn_state = drm_atomic_get_connector_state(state, connector);
- if (IS_ERR(conn_state))
- return PTR_ERR(conn_state);
+ if (IS_ERR(conn_state)) {
+ ret = PTR_ERR(conn_state);
+ goto out;
+ }
DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s],
disabling [CONNECTOR:%d:%s]\n",
encoder->base.id, encoder->name,
@@ -176,19 +181,21 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
if (ret)
- return ret;
+ goto out;
if (!crtc_state->connector_mask) {
ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
NULL);
if (ret < 0)
- return ret;
+ goto out;
crtc_state->active = false;
}
}
+out:
+ drm_connector_list_iter_put(&conn_iter);
- return 0;
+ return ret;
}
static void
@@ -2442,6 +2449,7 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
{
struct drm_atomic_state *state;
struct drm_connector *conn;
+ struct drm_connector_list_iter conn_iter;
int err;
state = drm_atomic_state_alloc(dev);
@@ -2450,7 +2458,8 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
state->acquire_ctx = ctx;
- drm_for_each_connector(conn, dev) {
+ drm_connector_list_iter_get(dev, &conn_iter);
+ drm_for_each_connector_iter(conn, &conn_iter) {
struct drm_crtc *crtc = conn->state->crtc;
struct drm_crtc_state *crtc_state;
@@ -2468,6 +2477,7 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
err = drm_atomic_commit(state);
free:
+ drm_connector_list_iter_put(&conn_iter);
drm_atomic_state_put(state);
return err;
}
@@ -2840,6 +2850,7 @@ int drm_atomic_helper_connector_dpms(struct drm_connector
*connector,
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
struct drm_connector *tmp_connector;
+ struct drm_connector_list_iter conn_iter;
int ret;
